Embed Size (px)
Citation preview
El proceso unificado del desarrollo de software (Capítulos 4, 5, 6 y 7)Enviado por ezequielher
Anuncios Google:
Estudia en EspañaInfórmate ahora de nuestro programa de becas-máster. Abierto plazo | www.esic.es
Open Source Java WorkflowDownload Free Workflow Management Software | www.joget.org
Gestión de ProyectosTareas de codigo abierto, integrado con hojas de tiempo, planificación | openerp.com
Resumen del libro
Autores: Jacobson, Booch, Rumbaugh
1. Un proceso centrado en la arquitectura 2. Un proceso iterativo e incremental 3. Cap. de requisitos: de la visión a los requisitos 4. Captura de requisitos como caso de uso
CAPITULO 4
Un proceso centrado en la arquitectura
Arquitectura:
Da una perspectiva del sistema completo; todos los empleados deben estar de acuerdo con ella.
Describe los elementos más importantes del sistema.
El 1er. Objetivo de la fase de elaboración es construir una arquitectura sólida que sirva de base para construir el sistema.
1. Arquitectura en pocas palabras
1. El conjunto de todas las vistas representa a la arquitectura. Cada vista es una perspectiva diferente del sistema. Cantidad de páginas para la Descripción de arquitectura: Se recomienda que sea de entre 50 y 100
Para que los desarrolladores progresen hasta obtener una visión común (en sist. soft. grandes)
Para dividir el proyecto en clases y facilitar su reutilización (futuros cambios)
1. Compresión del sistema2. Todos las personas que trabajen en el desarrollo del sistema deben
comprenderla lo cual es un reto difícil porque: operan en entornos complejos y al dividirlos en miniproyectos es difícil coordinarlos.
Mientras más grande sea el proyecto habrá mayor sobrecarga en la comunicación entre los distintos desarrolladores; para ello se divide el sistem en subsistemas donde cada uno tendrá un responsable. También es importante tener interfaces bien definidas.
3. Organización del desarrollo
Este capitulo es un quilombo. Jacobson andate a la concha de tu madre que te parió cagando.
4. Fomento de la reutilización5. Evolución del sistema
Un sistema grande evoluciona con el tiempo incluso durante su desarrollo, o sea, sufrirá futuras modificaciones (nuevos casos de usos). Si el sistema es flexible (tolerable a cambios) dichas modificaciones no deben causar resultados inesperados. Las arquitecturas de sistemas pobres deben ser parcheadas hasta el final y su coste es grande e innecesario.
2. Por qué es necesaria la arquitectura3. Casos de uso y arquitectura
La arquitectura se ve condicionada por:
Los casos de usos más importantes (más significativos). El producto software que se desea desarrollar. Por ej.: sist.op.; base de datos; etc. Los productos de capa media que se van a utilizar. Sistemas heredados a utilizar. Estándares y políticas corporativas. Requisitos no funcionales.
La arquitectura del sistema se desarrolla en fase de elaboración juntos con los casos de usos más importantes. Una vez que se tiene una arquitectura estable se realiza el resto de los casos de uso (los menos relevantes) que por lo general se basan en los requisitos de los clientes y usuarios.
El valor de costo de nuevos casos de usos se reflejan según la arquitectura del sistema.
La arquitectura guía los casos de uso: Mientras más se conozca la arq. mejor se hará la captura de requisitos para desarrollar los casos de usos.
Los casos de uso conducen a la arquitectura: ???
Cada vez que se quiera implementar un conjunto de CU al sistema, lo ideal es ampliar la arquitectura para darles soporte. Dicha ampliación se realiza una vez por cada iteración.
Entonces, Los CU ayudan a tener una arquitectura cada vez mejor.
1. La arquitectura se desarrolla mediante un conjunto de iteraciones, principalmente en fase de elaboración. El resultado de esta fase es una línea base de la arquitectura (esqueleto del sistema) que consta de poco software.
1. Línea base de arq: sistema pequeño y flaco2. Lo mismo que el 4.4 pero con más boludeces.
La línea base del sistema es una versión interna y se basa en la descripción de la arquitectura.
Cada versión nueva de un modelo se desarrolla a partir de la versión anterior. Nunca son independientes unos de otros.
Los elementos de un mismo modelo se relacionan por medio de dependencias de trazas.
Descripción de arquitectura: Sirve para guiar a los desarrolladores durante ciclo de vida actual y como base para el futuro.
Teniendo una arquitectura estable, la descripción de ésta también será estable.
3. Utilización de patrones en la arquitectura2. Pasos hacia una arquitectura
Definición de Patrón: Solución a un problema de diseño que aparece con frecuencia.
Estos patrones están documentados en libros; en ella hay diferentes plantillas donde asignan un nombre a cada patrón y describe los problemas, qué los causa y las soluciones.
Algunos patrones de diseño: Facade, Decorator, Proxy Observer, Strategy, Visitor.
Los patrones de diseño son ideal para lenguajes con orientación a objetos. Los patrones de arquitectura son ideal para sistemas, subsistemas e interfaces.
Definición de Capa: Conjunto de subsistemas que comparten la misma generalidad y de volatilidad de interfaces: Las capas inferiores (media y de sistema) requieren de interfaces estables; las capas superiores (de aplicación) requieren interfaces menos estables.
1. Descripción de la arquitectura
Debe contener todo lo que los trabajadores necesitan para hacer sus trabajos.
Debe actualizarse en forma constante para reflejar cambios y adiciones.
También debe presentar:
Vistas de los distintos modelos. Requisitos que no figuran en los CU (NO funcionales / adicionales) Breve descripción de plataforma, sistema heredados y software comercial q se
va a utilizar.
En la DA se describen con más detalle los subsistemas que son significativos para la arquitectura que representan un aprox.10%. Los CU en su mayoría no modifican al sistema.
1. El arquitecto crea la arquitectura: que novedad
Es importante que el arquitecto tenga conocimientos sobre...
..la empresa con la que está trabajando: adquirir experiencia con usuarios. ..desarrollo de software: saber escribir códigos para comunicarse con
desarrolladores.
Puede que se necesiten más de un arq. para desarrollar sistemas grandes.
El desarrollo de arquitectura consume mucho tiempo.
1. Ejemplo pág. 722. Resumen
CAPITULO 5
Un proceso iterativo e incremental
Cada fase de desarrollo se compone por una serie de iteraciones e incrementos.
1. Iterativo e incremental en pocas palabras
3 Claves del Proceso Unificado para el desarrollo de software:
El sistema esté dirigido por casos de usos. Se centre en una arquitectura. Tenga un desarrollo iterativo e incremental.
1. Desarrollo en pequeños pasos
En las primeras iteraciones se realiza:
Determinación del ámbito del proyecto. Eliminación de riesgos críticos.
Creación de la línea base de arquitectura.
Se deben dominar los requisitos, el problema y los riesgos que pueden surgir.
En las iteraciones posteriores
Se reducen los riesgos menos graves Se implementan componentes
Se añaden incrementos hasta llegar a la versión extrema (para el cliente).
El ciclo de vida de un proyecto se divide en miniproyectos = iteraciones, cada una compuesta por sus respectivos flujos de trabajo (requisito, análisis, diseño, implementación, prueba).
Se les llama miniproyectos porque no es algo que el usuario haya pedido.
El jefe de proyecto es quien se encarga de ordenar las iteraciones.
1. No es una iteración
Si el desarrollador pasa del ciclo de inicio al de elaboración...
Sin resolver los riesgos más críticos. Sin establecer una línea base de la arquitectura. Sin implementar los casos de usos importantes.
Además de ser un choto está construyendo un proyecto no fiable y no vale la pena que siga con él.
La iteración NO es aleatoria. Sirve como herramienta; para que los directores controlen el proyecto y reduce los riesgos q puedan amenazar al principio del ciclo de vida.
1.1. Riesgo: es una variable que pone en peligro o impide el éxito del
proyecto.
"Aproximación al proceso de desarrollo dirigido por riesgos": El Proceso Unificado reconoce los riesgos más importantes en las primeras 2 fases y reduce los mismos. Los que no, pueden poner en peligro el proyecto entero.
Método cascada: El desarrollo del sistema no se divide en iteraciones. Los problemas graves pueden saltar en la fase de integración & prueba; esto obliga a contratar a desarrolladores con más experiencia, el proyecto queda parado y se retrasan las fechas.
Método iterativo: Los riesgos importantes se tratan en las primeras fases, quedando muy pocas en la de construcción. El proyecto marcha sin inconvenientes hasta el final.
2. Atenuación de riesgos
Método cascada: Es en las últimas fases donde se sabe con certeza si la arquitectura que se diseñó es la adecuada. Si no lo es, se habrá perdido mucha guita y no podremos cumplir con la fecha de entrega.
Método iterativo: Es al final de la fase de elaboración donde se evalúa la arquitectura; si aún no está madura se trabaja en una nueva iteración; esto es posible ya que es muy poco lo que se in-vierte en esta fase y las fechas aún no están definidas.
3. Obtención de una arquitectura robusta
construcción: es una versión operativa del sistema que demuestra un subconjunto de posibilidades.
Es más fácil para el usuario ver un sistema ejecutable en funcionamiento que leer cientos de páginas de documentos. Esto permite a que los usuarios opinen y sugieran modificar o agregar cosas que se nos pasó de largo. En método cascada los usuarios ven al sistema funcionando recién en la integración y prueba, y si desea cambiar algo deberán aumentar presupuesto y atrasar las fechas.
4. Gestión de requisitos cambiantes5. Permitir cambios tácticos
2. ¿Por qué un desarrollo iterativo e incremental?
Con método iterativo los directores se encargan de ver al final de cada iteración..
Si hubo un incremento y se han resueltos los problemas; entonces autorizará a los desarrolladores a seguir con la siguiente iteración.
Si el éxito fue parcial, se ampliará la iteración hasta poder cumplir con lo requerido.
Si el resultado es negativo puede llegar a cancelarse el proyecto.
1. Método cascada: Muchos errores parecen no estar presentes y el proyecto progresa con norma-lidad hasta llegar a la integración y prueba; ahí salen todos a la luz. Estas ponen en peligro al proy
Método iterativo: Ya desde un principio se hacen frecuentes construcciones, y con éstas aparecen los errores que se tratarán a lo largo de todo el proyecto. No habrá sorpresas para el final.
2. Conseguir una iteración continua
3. Conseguir un aprendizaje temprano
Se ingresa gente nueva a medida que se pasa de una iteración a otra. Puede empezar con unas 5 a 10 pers. pasar a 25 y finalmente a 100. Los nuevos tienen una formación adecuada y trabajan con gente con experiencia, rápidamente se ajustan a la velocidad adecuada.
1. La aproximación iterativa está dirigida por riesgos
Se analizan los riesgos, luego se priorizan y se organizan las iteraciones para
Tratar los requisitos pedido por los usuarios Obtener una arquitectura robusta. Tratar otros aspectos como rendimiento, disponibilidad, portabilidad: éstos se
ven cuando se implementa y se prueba el software.
Objetivo: acabar con los riesgos en una iteración temprana.
En fase de inicio y elaboración se tratan la mayoría de los riesgos.
1. Las iteraciones alivian los riesgos técnicos
Hay 4 formas de tratar a un riesgo según su prioridad:
Evitarlo: Quizás se tenga que replanificar el proyecto o hacer un cambio de requisitos.
Limitarlo: Achicarlo para que afecta una parte pequeña del proyecto. Atenuarlo: Probar repetidas veces hasta ver si aparecen o no. Controlarlo: Ver si el proyecto puede convivir con ésta. Caso contrario no se
podrá continuar: algo que no es tan malo ya que se detectó en un principio y los gastos fueron mínimos.
Se manejan por iteraciones para no tener que tratar con todos los errores a la vez.
1. Iteración genérica
1.2. Qué es una iteración
Una iteración es un miniproyecto donde se tiene como resultado una versión interna.
Está compuesto por 5 flujos de trabajos: requisitos, análisis, etc.
Los trabajadores y artefactos pueden trabajar en más de un flujo de trabajo.
Las Fases están divididas en N iteraciones. Descripción de cada fase:
Inicio: Hacer análisis del negocio y reducir los riesgos más importantes.
Elaboración: Obtener línea base de la arquitectura, capturar requisitos, reducir demás riesgos.
Construcción: Desarrollar el sistema entero. Ofrecer funcionalidad operativa a clientes.
Transición: Tener el producto preparado para la entrega. Se enseña a usuarios a utilizar el software.
Cada iteración se analiza cuando termina y se ven si cambiaron o aparecieron nuevos requisitos que modificarán a la siguiente iteración.
Prueba de regresión: Sirve para ver si no se han estropeado iteraciones anteriores. Se aplica al antes de terminar con la iteración actual.
1. Requiere de más tiempo que en el modo cascada.
En método cascada la planificación se realiza en un principio, osea, antes de tratar los riesgos importantes y tener una línea base sólida.
Método iterativo: No se planifica proyecto entero en fase de inicio, solo unos pasos. Es al final de la fase de elaboración donde se tiene una base para planificar la mayor parte.
2. Planificación de las iteraciones3. Secuencia de iteraciones
Los casos de usos establecen una meta. La arquitectura establece un patrón.
En las primeras iteraciones se conocen mejor los requisitos, riesgos y soluciones. Las iteraciones sgtes. dan como resultado incrementos aditivos que terminan en una versión externa.
La planificación y trabajo de una iteración empieza cuando la anterior se está por entregar.
1. El resultado de una iteración es un incremento
1. Definiciones de Incremento:
Diferencia entre la versión interna de la iteración anterior y la siguiente.
Diferencia entre 2 líneas bases sucesivas.
Colaboración: Es la representación de los CU más significativos para la arquitectura. Sirve para identificar subsistemas e interfaces. Luego se les da forma (implementa código).
Hay más incrementos a medida que nos acercamos a la fase de transición.
La integración del último incremento se convierte en el sistema final.
2. Iteraciones sobre el ciclo de vida
Cada una de las 4 fases termina con un hito principal.
Objetivos de cada fase: Ya están en punto 4.2
Al final de cada iteración se producen artefactos como resultado.
Hitos principales: Se dan al final de cada fase. Jefes y desarrolladores toman decisiones impor-tantes: continuar o no con el proyecto, calendario y presupuesto.
Hitos secundarios: Se dan al final de una iteración. Los jefes deciden cómo continuar en itera-ciones siguientes.
En fases inicio y elaboración es poco el grupo de gente trabajando (bajo costo).
Aumenta el número de personas en fase de construcción.
CAPITULO 6
Cap. de requisitos: de la visión a los requisitos
1. Capturas de requisitos: es el proceso de averiguar en circunstancias difíciles qué se debe construir.
Los desarrolladores no pueden escribir un código sin saber qué es lo que debe hacer. Algo que sucede en algunas ocasiones. Analistas documentaban requisitos según lo que los usuarios pedían, pero llegaba a cientos de páginas y no podían concretarse fácilmente. Los usuarios sabían bien qué debía hacer el software recién cuando el producto estaba casi terminado y para hacer los cambios pedidos no quedaba otra que postergar las fechas y aumentar presupuesto. El usuario no saben cuáles son los requisitos.
2. Por qué la captura de requisitos es complicada
Objetivo: Guiar el desarrollo hacia el sistema correcto.
Suponiendo que el usuario no es un especialista informático, debemos ser capaces de hacer entender al cliente el resultado de los requisitos; utilizando el lenguaje del cliente e introduciendo (con mucho cuidado) formalidad y estructuras.
3. Objeto de flujo del trabajo de los requisitos
Se puede comenzar con la captura de requisitos de muchas maneras: haciendo un modelo de negocio, o de dominio por ejemplo.
Flujos de trabajo arquetípicos:
Enumerar los requisitos candidatos: De aquí se obtienen características: lista de sugerencias que el usuarios va dando. Aumenta cuando se agregan elementos; se restan al convertirse en otros artefactos como casos de uso. Compuesto por un nombre corto, breve descripción y un conj. de valores:
Estado (propuesto, aprobado, validado) Coste estimado, Prioridad, Nivel de Riesgo.
Estos valores sirven para calcular tiempo que llevará el proyecto y cómo dividirlo en iteraciones.
Comprender contexto del sistema: Hay 2 aproximaciones para expresar el contexto de sist.
Modelo de dominio: Describe los objetos del dominio*, se les asignan un nombre que se pasan a un glosario para mejorar la comunicación entre la gente que trabaja. Los objetos ayudan a identificar clases.
Modelo de negocio: Es más amplio que el modelo de dominio. Describe los procesos que componen el negocio. Objetivo à Comprender cuáles son los procesos que soportará el sistema..
Capturar requisitos funcionales: Se basa en los caso de usos = Describen de qué forma el usuario va a utilizar el sistema. Cada usuario requiere de varios CU. Los analistas proponen cómo será la interfaz del sistema esbozando varias versiones para que el usuario decida.
Capturar requisitos NO funcionales: Especifica las propiedades del sistema que tienen que ver con rendimiento, velocidad, uso de memoria, plataforma. Fiabilidad: tiempo de respuesta media, defectos por miles de líneas de código. Imponen condiciones a requisitos funcionales.
Puede que no pertenezca a ningún caso de uso => se agregan como requisitos adicionales.
* objetos de dominio: Cosas o eventos que existen o suceden en el entorno donde trabaja el sistema.
4. Visión general de la captura de requisitos5. Papel de los requisitos en el ciclo de vida de software
inicio: Se identifican la mayoría de los CU para detallar los más importantes (10%)
elaboración: Se captura un 80% de requisitos para estimar tiempo de proyecto.
construcción: Se capturan e implementan los demás requisitos.
transición: No hay captura de requisitos.
1. Cómo desarrollar un modelo de negocio (2 pasos)
El modelador..
hace un modelo de CU del negocio que identifique a los actores y los CU que utilicen los actores.
Desarrolla un modelo de objetos del negocio compuesto por trabajadores, entidades del negocio y unidades de trabajo.
Una entidad del negocio representa algo que los trabajadores toman, manipulan, modifican, utilizan (una factura por ejemplo). Una unidad de trabajo es un conjunto de entidades de trabajo.
CAPITULO 7
Captura de requisitos como caso de uso
1. Los artefactos fundamentales en captura de requisitos son:
Modelos de CU: Incluye actores y casos de usos
Otros: Prototipos de interfaz de usuario.
1. Artefacto: modelo de CU2. El modelo de CU sirve para llegar a un acuerdo entre el cliente y
desarrollador sobre los requisitos que deberá tener en cuenta el sistema. Describe lo que hace el sistema para cada tipo de usuario.
Actor: Representa el entero externo al sistema.
Rol: Define lo que hace un trabajador en proceso de negocio.
Instancia: es un actor que interactua con el sistema.
3. Artefacto: actor
Interacción: Es una secuencia de acciones que el sistema lleva a cabo (interactuando con actores) para dar un resultado de valor. Descripción de CU puede incluir diagramas de actividad.
Instancia de CU: Es la realización de los CU. Son atómicas: se ejecutan todo o nada. Sin otros de por medio.
Los CU tienen atributos, valores que en su ejecución se pueden usar y modificar.
Flujos de sucesos: Especifica qué hace el sistema cuando ejecuta un determinado CU.
Flujos especiales: Describe a un grupo de requisitos no funcionales.
4. Caso de uso
Contiene una vista del modelo de CU que describe los aspectos más importantes de la arquitectura.
5. Artefacto: descripción de una arquitectura6. Artefacto: Glosario7. Artefacto: prototipo de interfaz de usuario
Mejora la interfaz de usuario y ayuda a comprender los CU.
2. Artefactos3. Trabajador
1. Representa los comportamientos, descripciones y responsabilidades del mismo.
No es lo mismo que un individuo ya que éste puede representar a varios trabajadores si es que realiza distintas actividades.
1. Analista de sistemas
Hace la captura de requisitos func. y no func. para moldearlos a los CU. Hay 1 por cada sistema.
Especificador de CU: Asiste al analista de sistema.
Diseñador de interfaz: Es responsable del prototipo de interfaz de usuario.
Arquitecto: Trabaja con la captura de requisitos para diseñar las vistas de la arq del modelo de CU.
Conjunto de actividades que están ordenados. Los trabajadores crean, ejecutan y modifican artefactos.
Cada salida de una actividad sirve como entrada para la siguiente.
Los artefactos se completan y mejoran a través de las iteraciones. Los analistas para hacer captura de requisitos requiere de la ayuda de usuarios, desarrolladores y otros analistas.
4 pasos para tener una nueva versión del modelo de CU con actores:
Encontrar los actores / CU / describir cada CU / Describir modelo de CU. No requieren de un órden.
2. Encontrar actores:
3. Es fácil hacerlo teniendo el modelo de negocio. 1 actor por c/ trabajador. 1 actor por c/ cliente.
Hay que elegir un actor candidato que represente a todos sus pares.
No pueden haber 2 o más actores que tengan los mismos roles.
El analista le asigna un nombre a cada actor y hace una breve descripción q aclare necesidades y respon.
Encontrar casos de uso:
En general empieza con un verbo e indica el objetivo del CU para cada actor.
Resultado de valor:
La ejecución satisfactoria de un CU da un resultado de valor para que el actor pueda alcanzar su objetivo.
La instancia de un CU involucra a más de un actor.
Los CU más importantes se desarrollan en primeras iteraciones.
La vista de arquitectura del modelo de CU describe los CU más significativos para la arquitectura.
4. Priorizar casos de uso5. Detallar un caso de uso
2. Flujos de trabajo
Objetivo: Describir su flujo de sucesos de cada CU. Puede hacerse en texto o diagramas.
Transacción: Secuencia de acciones q se llevan a cabo en una instancia de CU.
Desviaciones: Puede darse por que..
El actor puede tomar caminos diferentes. El sistema detecta entradas erróneas del actor.
¿Qué incluye la descripción de un CU?
Estado inicial como precondición. Cómo y cuándo comienza un CU. Orden en que se ejecutan las acciones. Cómo y cuándo termina un CU. Descripción de estado final como postcondición. Descripción de caminos alternativos. Utilización de objetos, valores y recursos. Separar las responsabilidades del sistema / actores.
Requisitos especiales: Son los requisitos no funcionales; especifica sgte. características del sistema:
velocidad, estado de memoria, tiempo de respuesta, rendimiento, disponibilidad.
Diagramas de estado: Sirve para comprender un CU complejo y largo con caminos alternativos.
1. Prototipar interfaz de usuario:
Sirve para ver cómo un usuario puede utilizar el sistema para ejecutar un CU.
Se diseña durante fases de análisis, diseño e implementación.
SECCIÓN: Ing. de software / Análisis de sistema
FASES DE TRABAJO
Fase de Inicio: Primera fase del ciclo de vida del software, en la que la idea inicial para el desarrollo es refinada hasta el punto de quedar lo suficientemente bien establecida como para garantizar la entrada en la base de elaboracion. Fase de Elaboracion: Segunda fase del ciclo de vida, en la que se define la arquitectura. Fase de Construccion: Tercera fase del ciclo de vida del software, en la que el software es desarrollado a partir de una linea base de la arquitectura ejecutable, hasta el punto en el que se esta listo para ser transmitido a las comunidades de usuarios.
Fase de Transicion: Cuarta fase del ciclo de vida del software es puesto en manos de la comunidad de usuarios.
Software de Gestión de Flujos de Trabajo (workflow)
Dirigir todos sus procesos empresariales, tanto internos como externos de forma electrónica.
Con la gestión de flujos de trabajo, usted puede reducir costes, gestionando electrónicamente sus solicitudes de compra para suministros de oficina y activo.
Además, la gestión de flujos de trabajo le permite también llegar todavía más lejos: dirigir todos sus procesos empresariales, tanto internos como externos, electrónicamente.
La gestión de flujos de trabajo o workflow le ayudará a mejorar su eficiencia gracias a:
La reducción del esfuerzo operativo de manejo de solicitudes: Las solicitudes van por vía electrónica y a través de flujos de trabajo predefinidos de la forma más breve y ajustadas a los deseos y necesidades de la organización.
La visión global de todas las solicitudes (dónde, quién, por qué y cuándo). El mantenimiento de las solicitudes de acuerdo con sus pólizas y procedimientos.
La posibilidad de definir sus propias solicitudes y flujos de trabajo para darle soporte
a su organización, y responder así a sus necesidades específicas en todo momento.
La gestión de flujos de trabajo también proporciona visiones globales e informes. A partir de esos informes está claro qué tipo de solicitudes son las que se realizan más frecuentemente:
Qué empleados manejan más solicitudes, El tiempo que tarda en procesarse y completarse una solicitud dentro de un flujo de
trabajo, Etc.
Además, una solicitud siempre permanece relacionada con el solicitante y el aprobador. El aprobador encuentra la solicitud en su flujo de trabajo y al solicitante se le mantiene siempre informado del estatus.
Flujo de trabajoDe Wikipedia, la enciclopedia libre
Saltar a navegación, búsqueda
El flujo de trabajo (workflow en inglés) es el estudio de los aspectos operacionales de una actividad de trabajo: cómo 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. Generalmente los problemas de flujo de trabajo se modelan con redes de Petri.
Si bien el concepto de flujo de trabajo no es específico a la tecnología de la información, una parte esencial del software para trabajo colaborativo (groupware) es justamente el flujo de trabajo.
Una aplicación de flujos de trabajo automatiza la secuencia de acciones, actividades o tareas utilizadas para la ejecución del proceso, incluyendo el seguimiento del estado de cada una de sus etapas y la aportación de las herramientas necesarias para gestionarlo
Se pueden distinguir tres tipos de actividad:
Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio de datos para obtener un resultado común. Tiene entidad el trabajo de cada uno de ellos en sí mismo.
Actividades cooperativas: Un conjunto de usuarios trabajan sobre su propio conjunto particular, estableciendo los mecanismos de cooperación entre ellos. No tiene entidad el trabajo de ninguno de ellos si no es visto desde el punto de vista global del resultado final.
Actividades de coordinación.
Contenido[ocultar]
1 Objetivos de un sistema de workflow 2 Sistemas de flujo de trabajo 3 Véase también
o 3.1 Lenguajes de especificación de workflow 4 Bibliografía 5 Enlaces externos
o 5.1 Organismos
[editar] Objetivos de un sistema de workflow
Reflejar, mecanizar y automatizar los métodos y organización en el sistema de información
Establecer los mecanismos de control y seguimiento de los procedimientos organizativos
Independizar el método y flujo de trabajo de las personas que lo ejecutan Facilitar la movilidad del personal Soportar procesos de reingeniería de negocio Agilizar el proceso de intercambio de información y agilizar la toma de decisiones de
una organización, empresa o institución
[editar] Sistemas de flujo de trabajo
El propósito de los sistemas de flujo de trabajo, (o BPMS, business process management systems), es acercar personas, procesos y máquinas, con el objeto de reducir tiempo y acelerar la realización de un trabajo. Estos sistemas permiten trabajar en equipo desde diferentes lugares físicos. Los sistemas de flujo de trabajo facilitan la automatización de los flujos de trabajo entre procesos y permiten integrar los procesos de la empresa, rediseñados de acuerdo con ayuda de nuevas estrategias.
Existen en el mercado varios productos como FlowMind, openEDMS, wf.com.mx, cardiff, IBM, etc. Existen muchas metodologías que culminan en la implementación de un sistema de este tipo como son diagrama de roles, BPMN, IDEF0, ciclos de trabajo, etc.
Fase de Construcción
Introducción
Se desarrolla completamente el software y los documentos necesarios que componen el sistema. El resultado de esta fase es un producto listo para que los usuarios lo puedan operar y consiste del software integrado en las plataformas adecuadas, los materiales para soporte del usuario y una descripción de la versión actual (esta versión del sistema se llama la versión “beta”).
Objetivos
Obtener la construcción completa del software. Documentación Técnica completa. Materiales para Soporte al Usuario completa. Materiales para Capacitación. Informe final de Verificación (conteniendo toda la información de la
versión). Evaluación de la calidad del producto.
Actividades críticas
Especificar los Requerimientos. Definir el Alcance del Sistema. Validar con Prototipo. Diseñar el Sistema. Especificar los Casos de Prueba. Ajustar y controlar el desarrollo. Planificar la Integración de la Iteración. Integrar el Sistema. Documentación de Usuario. Desarrollar los Materiales para Capacitación. Verificación Unitaria. Verificar el software. Verificar el Sistema. Seguimiento de la Línea Base. Seguimiento de Proyecto. Estimaciones y Mediciones. Planificar la Transición. Describir la Versión.
Actividades no críticas
Revisión Técnica Formal (Interfase de Usuario, Materiales para Soporte al Usuario, Documentación Técnica, Informes de Verificación).
Revisar el Ajuste al proceso. Documentación Técnica.
Entregables por Iteración
Iteración 1
Semana Disciplinas EntregableResponsable del Entregable Prioridad
Semana 9 Implementación Informe de Verificación Unitaria Implementador AltaSemana 9 Verificación Evaluación de la Verificación Responsable de
VerificaciónMedia
Semana 9 Verificación Reportes de Pruebas Responsable de Verificación
Alta
Semana 9 Verificación Informe de Verificación de Documento
Responsable de Verificación
Alta
Semana 9 Verificación Documento de Evaluación y Ajuste del Plan de V&V
Responsable de Verificación
Alta
Semana 9 Gestión de Proyecto
Informe de Situación del Proyecto Administrador Alta
Semana 9 Gestión de Proyecto
Plan de Desarrollo Coordinador de Desarrollo
Alta
Semana 9 Gestión de Proyecto
Documento de Riesgos Administrador Alta
Semana 9 Gestión de Proyecto
Registro de Actividades Administrador Alta
Semana 9 Gestión de Proyecto
Presentación al Director del Proyecto
Administrador Alta
Semana 9 Gestión de Proyecto
Acta de la Reunión con el Director del Proyecto
Administrador Alta
Semana 9 Gestión de Calidad Informe de Revisión de SQA Responsable de SQA
Alta
Semana 9 Gestión de Calidad Informe de RTF Responsable de SQA
Alta
Semana 9 Gestión de Configuración y Control de Cambios
Descripción de la Versión Responsable de SCM
Alta
Semana 9 Gestión de Calidad Entrega Semanal de SQA Responsable de SQA
Alta
Semana 9 Gestión de Calidad Documento de Evaluación y Ajuste del Plan de Calidad
Responsable de SQA
Alta
Semana 9 Gestión de Configuración y Control de Cambios
Informe de la Línea Base del Proyecto
Responsable de SCM
Alta
Semana 9 Implantación Plan de Implantación Especialista TécnicoAlta
Semana 9 Implantación Materiales para Soporte al Usuario Documentador de Usuario
Alta
Semana 10 Requerimientos Documento de Validación con el Cliente
Arquitecto Baja
Semana 10 Diseño Modelo de Diseño Arquitecto AltaSemana 10 Diseño Modelo de Datos Arquitecto AltaSemana 10 Implementación Informe de Integración Responsable de
IntegraciónAlta
Semana 10 Implementación Plan de Integración de la Iteración Responsable de Integración
Alta
Semana 10 Verificación Plan de Verificación de la Iteración Responsable de Verificación
Alta
Semana 10 Verificación Modelo de Casos de Prueba Responsable de Verificación
Alta
Semana 10 Gestión de Proyecto
Acta de la Reunión de Equipo Administrador Alta
Semana 10 Gestión de Proyecto
Plan de la Iteración Administrador Alta
Semana 10 Gestión de Proyecto
Informe de Situación del Proyecto Administrador Alta
Semana 10 Gestión de Proyecto
Plan de Desarrollo Coordinador de Desarrollo
Alta
Semana 10 Gestión de Proyecto
Documento de Riesgos Administrador Alta
Semana 10 Gestión de Proyecto
Registro de Actividades Administrador Alta
Semana 10 Gestión de Configuración y Control de Cambios
Notas de la Versión Responsable de SCM
Alta
Semana 10 Gestión de Calidad Entrega Semanal de SQA Responsable de SQA
Alta
Semana 10 Gestión de Configuración y Control de Cambios
Gestión de Cambios Responsable de SCM
Alta
Semana 10 Gestión de Configuración y Control de Cambios
Registro de Versiones Responsable de SCM
Alta
Semana 10 Implantación Materiales para Soporte al Usuario Documentador de Usuario
Alta
Semana 10 Implantación Materiales para Capacitación Documentador de Usuario
Alta
Semana 10 Implantación Versión “Beta” del Producto Responsable de SCM
Alta
Iteración 2
Semana Disciplinas Entregable
Responsable
Prioridad
del Entregable
Semana 11
Implementación Documentación Técnica
Implementador
Alta
Semana 11
Implementación Informe de Verificación Unitaria
Implementador
Alta
Semana 11
Verificación Documento de Evaluación y Ajuste del Plan de V&V
Responsable de Verificación
Alta
Semana 11
Verificación Informe de Verificación de Documento (Documentación Técnica)
Responsable de Verificación
Alta
Semana 11
Verificación Reportes de Pruebas Responsable de Verificación
Alta
Semana 11
Verificación Evaluación de la Verificación
Responsable de Verificación
Alta
Semana 11
Gestión de Proyecto Informe de Situación del Proyecto
Administrador
Alta
Semana 11
Gestión de Proyecto Plan de Desarrollo Coordinador de Desarrollo
Alta
Semana 11
Gestión de Proyecto Registro de Actividades
Administrador
Alta
Semana 11
Gestión de Calidad Informe de Revisión de SQA
Responsable de SQA
Alta
Semana 11
Gestión de Calidad Informe de RTF Responsable de SQA
Alta
Semana 11
Gestión de Configuración y Control de Cambios Descripción de la Versión
Responsable de SCM
Alta
Semana 11
Gestión de Calidad Entrega Semanal de SQA
Responsable de SQA
Alta
Semana 11
Gestión de Calidad Documento de Evaluación y Ajuste del Plan de Calidad
Responsable de SQA
Alta
Semana 11
Gestión de Configuración y Control de Cambios Informe de la Línea Base del Proyecto
Responsable de SCM
Alta
Semana 11
Implantación Plan de ImplantaciónEspecialista Técnico
Alta
Semana 11
Implantación Materiales para Soporte al Usuario
Documentador de Usuario
Alta
Semana 11
Implantación Materiales para Capacitación
Documentador de Usuario
Alta
Semana 12
Implementación Documentación Técnica
Implementador
Alta
Semana 12
Implementación Informe de Integración
Responsable de Integración
Alta
Semana 12
Verificación Evaluación de la Verificación
Responsable de Verificación
Alta
Semana 12
Verificación Plan de Verificación de la Iteración
Responsable de Verificación
Alta
Semana 12
Verificación Modelo de Casos de Prueba
Responsable de Verificación
Alta
Semana 12
Verificación Reportes de Pruebas Responsable de Verificación
Alta
Semana 12
Gestión de Proyecto Acta de la Reunión de Equipo
Administrador
Alta
Semana 12
Gestión de Proyecto Plan de la Iteración Administrador
Alta
Semana 12
Gestión de Proyecto Informe de Situación del Proyecto
Administrador
Alta
Semana 12
Gestión de Proyecto Plan de Desarrollo Coordinador de Desarrollo
Alta
Semana 12
Gestión de Proyecto Registro de Actividades
Administrador
Alta
Semana 12
Gestión de Proyecto Informe de Conclusiones de la Fase
Administrador
Alta
Semana 12
Gestión de Configuración y Control de Cambios Notas de la Versión Responsable de SCM
Alta
SemanGestión de Configuración y Control de Cambios Descripción de la Respon Alta
a 12 Versión sable de SCM
Semana 12
Gestión de Calidad Entrega Semanal de SQA
Responsable de SQA
Alta
Semana 12
Gestión de Configuración y Control de Cambios Gestión de Cambios Responsable de SCM
Alta
Semana 12
Gestión de Configuración y Control de Cambios Registro de Versiones
Responsable de SCM
Alta
Semana 12
Implantación Plan de ImplantaciónEspecialista Técnico
Alta
Semana 12
Implantación Materiales para Soporte al Usuario
Documentador de Usuario
Alta
Semana 12
Implantación Materiales para Capacitación
Documentador de Usuario
Alta
Semana 12
Implantación Presentación del Sistema
Administrador
Alta
Semana 12
Implantación Versión “Beta” del Producto
Responsable de SCM
Alta
