GoConqr has a new look! Let us know what you think.

Notes

Workflows de Análisis, Diseño e Implementación

Giselle Craig EFIP II EFIP II Spanish 4 pages

Content of the notes (4)

Page 1

Workflows

Se define Workflow al flujo de trabajo a seguir para la consecución de una tarea o trabajo determinado. El flujo de trabajo determina como se estructuran las tareas, cómo se realizan, cuál es su orden correlativo cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas.

Organiza y controla tareas, recursos y reglas necesarias para completar el proceso de negocio.

La importancia del workflow consiste en buscar la máxima automatización de los procesos de trabajo y el control total de las diferentes etapas.

La principal limitación asociada a los Sistemas de Información (S.I.) tradicionales es que, no contemplan los procedimientos, organización y métodos de trabajo del sistema real.

Problemas:

Necesidad de adaptar los procedimientos organizativos al sistema de información

Posibilidad de conflicto entre los procedimientos organizativos y los módulos funcionales

Falta de control sobre las actividades de la organización como un todo

Los objetivos de un sistema de Workflow son:

Reflejar, automatizar y mecanizar los métodos y su organización en el sistema de información

Establecer los mecanismos de control y de seguimiento de los procedimientos organizativos

Independizar el método y flujo de trabajo de las personas que lo ejecutan

Soportar procesos de reingeniería de negocio

En un Workflow se pueden distinguir tres tipos de actividades:

Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio de datos para obtener un resultado común

Actividades cooperativas: Trabajan sobre su propio conjunto particular, estableciendo los mecanismos de cooperación entre ellos.

Actividades de coordinación: se establece cómo será el trabajo cooperativo entre los individuos.

Workflows de Análisis, Diseño e Implementación

Componentes del proceso

Acciones

Personas responsables de realizar las acciones

Materiales

Equipamiento

Procedimientos

Documentación

Page 2

¿Cómo se construye un proceso de desarrollo de software?

Se construye a partir de los lineamientos de la teoría de procesos, la cual puede incluir la visión de Workflow.

Proceso de desarrollo de software: Conjunto estructurado de actividades para desarrollar un sistema de software

¿Qué se espera de un proceso de software?

Se espera que sea capaz de evolucionar y que durante su evolución se limite por:

la tecnología

las herramientas

la gente

los patrones organizacionales

El proceso de software debería comportarse de una manera definida y dinámica, permitiendo:

Utilizarse con una variedad de ciclos de vida.

Seleccionar los artefactos a producir.

Definir actividades y personas participantes.

Modelar conceptos.

¿Cuál es el criterio que se debe tener para definir un proceso de desarrollo de software?

Propósito: ¿Por qué se realizó el proceso?

Entrada: ¿Qué productos de trabajo se utilizan?

Salida: ¿Qué productos de trabajo se generan?

Rol: ¿Quién o qué realiza la actividad definida en el proceso?

Actividad: ¿Qué se hace?

Criterio de entrada:¿Cuándo puede iniciarse el proceso?

Criterio de salida: ¿Cuándo puede considerarse un proceso completo?

Procedimiento: ¿Cómo son implementadas las actividades?

Page 3

Etapas del proceso de desarrollo

Las 4 actividades o etapas básicas del proceso se organizan de forma distinta en diferentes procesos. Estas son:

Especificación

Desarrollo

Validación

Evolución

En el enfoque en cascada se organizan de manera secuencial, mientras que en el desarrollo evolutivo se entrelazan

Etapa de Especificación del Software

Es el proceso de comprensión del problema y definición de los servicios que requiere el sistema, como así también la identificación de las restricciones de funcionamiento y de desarrollo.

Se realiza la captura de los requerimientos y el análisis de los mismos.

Existen 4 fases principales en el proceso de Ingeniería de requerimientos

Estudio de viabilidad: se estima si las necesidades del cliente se pueden satisfacer

Obtención y análisis de requerimientos: se utilizan distintas técnicas de recolección de datos e información que luego es analizada.

Especificación de requerimientos: se describe la lista de requerimientos en un documento.

Validación del requerimiento: se comprueba con el cliente si la lista de requerimientos es correcta.

Etapa de diseño e implementación del software

Incluye a los procesos de diseño y construcción del software. En un enfoque en cascada se implementará un ejecutable que contiene el total de las especificaciones diseñadas y programadas, mientras que en un enfoque evolutivo implicará un refinamiento de las especificaciones del software.

El diseño involucra a los datos, subsistemas, componentes e interfaces, tanto internas como externas que requiere la especificación de los requerimientos. Las actividades específicas del proceso de diseño son:

Diseño arquitectónico: intervienen los subsistemas y componentes que forman el sistema y sus relaciones, identificándolas y documentándolas.

Especificación abstracta: se abstraen los servicios y restricciones bajo las cuales debe funcionar el sistema.

Diseño de interfaz: para cada subsistema se diseña y documenta su interfaz con otros subsistemas. También se diseñan los prototipos de interfaz con el usuario.

Diseño de componentes: se asignan servicios a los componentes y se diseñan sus interfaces.

Diseño de la estructura de datos: se diseña la base de datos a utilizar y la relación con las estructuras ya existentes.

Diseño de algoritmos: se realiza el diseño detallado de los algoritmos a utilizar.

Etapa de Desarrollo

El desarrollo del software es el proceso de codificación en un lenguaje de computación, de los requerimientos definidos, analizados y diseñados.

Al programador le llega la documentación de los requerimientos y es su responsabilidad transformarlos en un programa ejecutable.

Al finalizar la programación es necesario que se realice la comprobación del funcionamiento del programa y del cumplimiento con las especificaciones.

En caso de encontrar errores, es el mismo programador el que los depura hasta llegar a una versión confiable.

Etapa de Validación del software

Se conoce también como V & V (verificación y validación) se utiliza para mostrar que el sistema se ajusta a su especificación y que cumple las expectativas del cliente.

Las etapas del proceso de prueba son:

Prueba de componentes: se prueban los componentes individuales para verificar que funcionan correctamente

Prueba del sistema: se realiza la prueba del sistema integrando todos los componentes

Prueba de aceptación: se prueba con los datos proporcionados por el cliente, antes de su aceptación final.

Etapa de Evolución del software

Una vez entregado el producto de software al cliente se comienza a usar; esta etapa es muy importante ya que el cliente se dará cuenta si hay algún requerimiento para refinar, agregar o cambiar, estos sucesos hacen a la evolución del software.

Si el software fue entregado al cliente con errores significa que no cumplió con las etapas del proceso correctamente, sobre todo la de prueba de software, lo cual lleva a muchos problemas:

Cliente desconforme

Producto que no es de calidad

Tiempo perdido en recodificación del software

Gasto operativo que se incrementa sin poder medir las pérdidas

No se puede cobrar al cliente el costo de la resolución de errores.

Nuevamente crisis del software.

Page 4

El Proceso Unificado de Desarrollo de Software

Proceso Unificado de Desarrollo de Software está asociado con “El Proceso Unificado de Racional” (RUP) que es un ejemplo de modelo de proceso moderno que proviene del UML (Lenguaje de Modelado Unificado).

R.U.P. (Proceso Unificado de Rational)

Se describe desde 3 perspectivas:

Perspectiva dinámica: Muestra las fases del modelo en el tiempo

Perspectiva estática: muestra las actividades del proceso.

Perspectiva práctica: buenas prácticas a utilizar durante el proceso

El RUP es un modelo en fases que identifica cuatro fases diferentes en el proceso de software

Inicio: su objetivo es establecer un caso de negocio para el sistema, identificando todas las entidades externas que interactúan con el sistema.

Elaboración: su objetivo es presentar el dominio del sistema, establecer un marco de trabajo arquitectónico, desarrollar el plan del proyecto e identificar los riesgos.

Construcción: comprende desde el diseño a la programación y las pruebas del sistema

Transición: comprende la actividad de instalar el sistema en un entorno real para su uso. Pasa del entorno del programador al del usuario final.

Como no se cuenta con el 100% de los requerimientos, estas fases se presentan de forma iterativa e incremental.

La vista estática se centra en las actividades que realizan en la etapa de desarrollo, denominándose “flujos de trabajo”, apoyados por los diagramas de UML.

La vista dinámica acompaña a la estática presentando os flujos de trabajo en el tiempo, haciendo que ambas no estén asociadas a flujos de trabajo específicos.

Las buenas prácticas que presenta RUP

Desarrolle el software de forma iterativa,

Gestione los requerimientos

Utilice arquitecturas basadas en componentes

Modelo de forma visual el software

Verifique la calidad del software,

Controle los cambios del software,

UML y el Proceso Unificado de Desarrollo de Software

El proceso unificado está basado en componentes, por lo que el software está sustentado en componentes de software interconectados a través de interfaces.

El Proceso Unificado está diseñado para la flexibilidad y la extensibilidad dadas por las siguientes características:

Permite una variedad de ciclos de vida.

Selecciona qué artefactos producir.

Define las actividades y sus actores.

Modela conceptos.

Un Artefacto, es una pieza de información que es producida, modificada o usada por un proceso.

Características del Proceso de Desarrollo Unificado

Dirigido por casos de uso

Centrado en la arquitectura

Iterativo e incremental.

Dirigido por casos de uso:

Es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Estos casos de uso representan los requisitos funcionales, todos los casos de uso juntos constituyen el Modelo de casos de uso, el cual describe la funcionalidad total del sistema.

Una funcionalidad del sistema debe responder a la pregunta ¿Qué debe hacer el sistema?. Cuando lo planteamos como caso de uso la pregunta es: ¿Qué debe hacer el sistema para cada usuario?

Los UC no sólo representan las funcionalidades sino que también guían el proceso de desarrollo

Centrado en la Arquitectura

La arquitectura en un sistema de software incluye los aspectos estáticos y dinámicos del sistema.

Existen otros factores que influyen en la arquitectura:

La plataforma donde debe funcionar

Los componentes reutilizables de que se dispone

Sistemas heredados

Requisitos no funcionales

La actividad de diseño permite al arquitecto centrarse en los objetivos adecuados como:

La comprensibilidad

La capacidad de adaptación al cambio

La reutilización.

La arquitectura no es independiente de los casos de uso, están interrelacionados, ya que cada producto consta de una función y una forma, donde la función corresponde a los casos de uso y la forma a la arquitectura.

El proceso es Iterativo e Incremental

Cada miniproyecto es una iteración que resulta que resulta en un incremento. Las iteraciones hacen referencia a los pasos del flujo de trabajo y los incrementos, al crecimiento del producto.

Los desarrolladores basan la selección de lo que se implementará en una iteración, en dos factores:

Un conjunto de UC que juntos amplían el producto.

Una nueva iteración se construye sobre los artefactos de desarrollo tal como quedaron en la iteración anterior.

¿Cómo sabemos que es un ciclo iterativo e incremental?

Es planificado y controlado.

Es predicable

Acomoda los cambios a los requerimientos con menos alteraciones.

Está basado en prototipos ejecutables que evolucionan, no en la documentación.

Involucra a clientes y usuarios a lo largo del proceso.

Es conducido por los riesgos.

Persona, Proyecto, Producto y proceso en el Desarrollo de Software

El resultado final de un proyecto de software es un producto que va tomando forma durante el proceso gracias a la intervención de muchos tipos distintos de personas, cada una tiene su nivel de esfuerzo y con un flujo de trabajo asociado

Personas

Proyecto: es el elemento organizativo

Producto: son los artefactos que se crean durante la vida del proyecto,

Proceso: definición de un conjunto de actividades necesarias para transformar los requisitos de usuario en producto.

Conceptos básicos en el proceso unificado y de los workflows del Proceso

El proceso unificado produce modelos durante su desarrollo, estos modelos son:

Modelo de negocio

Modelo de dominio

Modelo de casos de uso

Modelo de análisis

Modelo de diseño

Modelo de proceso

Modelo de despliegue

Modelo de implementación

Modelo de prueba.

Workflows de Análisis, Diseño e Implementación

En la gráfica anterior se identifican los Workflow que son parte del proceso unificado

Modelo de negocio

Requerimientos

Análisis

Diseño

Implementación

Prueba.

Workflow de captura de requerimientos

Tiene como objetivo lograr la lista de requerimientos, para ello se deben realizar actividades relacionadas con los modelos o artefactos resultantes:

Listar los requerimientos necesarios,

Comprender el contexto del sistema

Capturar requerimientos funcionales

Capturar requerimientos no funcionales

La captura de requerimientos se realiza en las 4 fases del proceso, siendo de mayor trabajo en las fases de inicio y elaboración

Workflow de análisis

Tiene como objetivo realizar el análisis de los requerimientos. Sus ventajas son:

Permite una especificación más precisa de los requerimientos.

Se describe en lenguaje técnico, del programador.

Le da estructura a los requerimientos.

Puede verse como un primer corte de los requerimientos.

El análisis se realiza en las tres primeras fases del proceso (inicio, elaboración y construcción)

Workflow de diseño

Su objetivo es obtener el diseño completo del sistema para lograr:

Una comprensión completa de los requerimientos y sus restricciones.

Refinar los requerimientos obteniendo clases e interfaces individuales

Descomponer el trabajo de implementación en piezas entendibles y manejables por distintos actores del proceso

Capturar las interfaces de relación entre sistemas

Crear una abstracción de la implementación del sistema

Workflow de implementación

Su objetivo es lograr la implementación de un producto ejecutable. Para ello se realizan las siguientes actividades:

Se planean las implementaciones de cada iteración

Se distribuyen los componentes en los nodos donde se implementan

Se implementa el diseño de clases y subsistemas

Se realizan las primeras pruebas de unidad de componentes

Se realiza la integración de los componentes en un ejecutable

La actividad de implementación se relaciona con las fases de elaboración, construcción y transición.

Workflow de prueba

Su objetivo es probar el producto final garantizando que es de calidad. Tareas:

Realiza la planificación de las pruebas necesarias para cada iteración

Diseña e implementa las pruebas, diseñando los casos de uso de prueba

Realiza los test necesarios, documentando los resultados

Automatiza los tests de prueba que pueden ser reutilizados.

Information

Description
EFIP II EFIP II (Ingeniería de Software) Note on Workflows de Análisis, Diseño e Implementación, created by Giselle Craig on 03/03/2019.
Created by
Giselle Craig · Mar 2019
Updated
Mar 4, 2019
Views
3
Rating

Feedback

What is it about?

What do you think of the new look?

How do you like it?