lOMoAR cPSD| 4269609 P1-TA-6 - Lectura Capítulo 1 , 2 ( Proceso Unificado DE Desarrollo DE Software) Desarrollo de Software III (Universidad de las Américas Ecuador) Descargado por SAMIR ALONSO CRISTANCHO CACERES (sacristancho52@misena.edu.co) lOMoAR cPSD| 4269609 StuDocu no está patrocinado ni avalado por ningún colegio o universidad. Descargado por SAMIR ALONSO CRISTANCHO CACERES (sacristancho52@misena.edu.co) lOMoAR cPSD| 4269609 UNIVERSIDAD DE LAS AMÉRICAS EL PROCESO UNIFICADO DEL DESARROLLO DE SOFTWARE Kevin Soto 717763 Capítulo 1 A medida que pasa el tiempo y debido al gran avance tecnológico que va surgiendo, las necesidades de los usuarios son cada vez más estrictas, se requieren sistemas que se adapten alas necesidades que van surgiendo y por ende son sistemas más complejos. Pero no siendo esto suficiente, se requieren que estos sistemas sean desarrollados rápidamente, para que puedan ser distribuidos tempranamente y tener un puesto más importante en el mercado. Para poder conseguir esto se requiere dejar de usar metodologías viejas, debido que estas se enfrentan a varios problemas que hacen que la obtención del resultado final sea más lenta. Es por esto que se necesita un método que cumpla con las siguientes condiciones: • Proporcione una guía para ordenar las actividades de un equipo. • Dirija las tareas de cada desarrollador por separado y del equipo como un todo. • Especifique los artefactos que deben desarrollarse. • Ofrezca criterios para el control y la medición de los productos y actividades del proyecto. Teniendo en cuenta todas estas necesidades se decidió desarrollar el proceso Unificado, lo cual sirve como solución a los problemas anteriores. El Proceso Unificado es un marco de trabajo genérico de actividades necesarias para transformar los requisitos de un usuario en un sistema software, este puede especializarse en varias áreas, tipos de sistemas, organizaciones y tamaños de proyectos. El Proceso Unificado se basa en componentes los cuales al final forman un todo y están comunicados entre sí. Para poder lograr esto se utiliza el Lenguaje Unificado Modelado (UML), el cual prepara todos los esquemas del sistema que se realizará. Los hace único al Proceso Unificado son los siguientes aspectos: • Dirigido por Casos de Uso. • Centrado en la arquitectura. • Es iterativo e incremental. A continuación, describiremos cada uno de estos aspectos para que puedan ser entendidos. Él Proceso Unificado está dirigido por Casos de Uso. Para poder entender los requerimientos que los usuarios necesitan y desean, entendiendo que por usuarios nos referimos también a otros sistemas, necesitamos realizar casos de uso, ya que estos representan un fragmento de la funcionalidad del sistema, lo cual proporciona al usuario un resultado importante y al desarrollador una guía del funcionamiento del sistema. Para poder realizar un caso de uso se debe realizar la siguiente pregunta “¿Qué debe hacer el sistema para cada usuario?”. Los casos de uso sirven también como una guía para el diseño, implementación Descargado por SAMIR ALONSO CRISTANCHO CACERES (sacristancho52@misena.edu.co) lOMoAR cPSD| 4269609 y pruebas del sistema. Para el correcto desarrollo de un caso de uso es necesario especificarlos para luego diseñarlos. A pesar de que los casos de uso son una guía para el desarrollo del sistema, estos se van desarrollando paralelamente, influyendo uno con el otro. El Proceso Unificado está centrado en la arquitectura. La arquitectura en un sistema de software se describe mediante diferentes vistas del sistema en construcción. Esta describe los aspectos estáticos y dinámicos más importantes de un sistema. Esto surge de las necesidades de la empresa, como las perciben los usuarios y los invasores, y son reflejados en los casos de uso. Sin embargo, también se ve influida por muchos otros factores, como la plataforma en la que tiene que funcionar el software, los bloques de construcción, consideraciones de implementación, sistemas heredados, y requisitos no funcionales. Debe haber interacción entre los casos de uso y la arquitectura para poder desarrollar un sistema correcto, los casos de uso deben encajar en la arquitectura cuando se llevan a cabo. Por otro lado, la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, ahora y en el futuro. Habiendo dicho esto la arquitectura debe diseñarse de tal manera que permita que el sistema pueda evolucionar. Entonces el arquitecto se debe encargar de lo siguiente: • Crear un esquema en borrador de la arquitectura, comenzando por la parte de la arquitectura que no es específica de los casos de uso. Aunque por esta parte de la arquitectura es independiente de los casos de uso, el arquitecto debe poseer una comprensión general de los casos de uso antes de comenzar la creación del esquema arquitectónico. • A continuación, el arquitecto trabaja con un subconjunto de los casos de uso especificados, con aquellos que representen las funciones clave del sistema en desarrollo. Cada caso de uso seleccionado en detalle y se realiza en términos de subsistemas, clases y componentes. • A medida que los casos de uso se especifiquen y maduran, se descubre más de la arquitectura. Esto, a su vez, lleva a la maduración de más casos de uso. El Proceso Unificado es iterativo e incremental. Debido a que los sistemas pueden tardar varios meses o incluso años en desarrollarse es práctico dividir el sistema en pequeños subsistemas. Cada uno de estos es una iteración y la suma de todas las iteraciones debe ser el proyecto completo. Para poder seleccionar los requerimientos que se trataran en cada iteración se debe tomar en cuenta lo siguiente. Primero cada iteración debe ampliar la utilidad de las iteraciones anteriores. Segundo, se debe priorizar los requerimientos más importantes del sistema. Y, por último, estas deben terminar siendo un código ejecutable. Cuando una iteración no cumple sus objetivos se debe hacer una retroalimentación de lo sucedido y probar con un nuevo enfoque. Entre los beneficios del proceso iterativo tenemos: • La iteración controlada reduce el coste de riesgo a los costees de un solo incremento. Si los desarrolladores tienen que repetir la iteración, la organización solo pierde el esfuerzo mal empleado de la iteración, no el valor del producto entero. Descargado por SAMIR lOMoAR cPSD| 4269609 • La iteración controlada reduce el riesgo de no sacar al mercado el producto en el calendario previsto. Mediante la identificación de riesgos en fases tempranas del desarrollo, el tiempo que se gasta en resolverlos se emplea al principio de la planificación, cuando la gente está mendos presionada por cumplir los plazos. • La iteración controlada acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan de manera más eficiente para obtener resultados claros a corto plazo, en lugar de tener un calendario largo. • La iteración controlada reconoce que las necesidades del usuario y sus requisitos no pueden definirse completamente al principio. Una vez presentados estos conceptos claves, pasaremos a definir al proceso en su totalidad, sus ciclos de vida, artefactos, flujos de trabajo, fases e iteraciones. La vida del Proceso Unificado. La vida del proceso unificado consta de varios ciclos y cada ciclo representa a una versión del producto. Cada ciclo tiene cuatro fases: inicio, elaboración, construcción y transición. Cada fase se subdivide en iteraciones. Figura 1.3. Un Ciclo con sus fases e iteraciones. Cada ciclo produce una nueva versión del sistema y cada versión es un producto preparado para su entrega. Este debe poder ajustarse a las necesidades de todas las personas que vayan a usar el sistema. El producto final debe incluir todos los elementos que hemos mencionado anteriormente. Este puede cambiar a medida que pasa el tiempo, esto con la finalidad de adaptarse a nuevos requerimientos o a cambios dentro e la empresa, para poder realizar estos cambios en nuevo ciclo los desarrolladores necesitan lo siguiente: • Un modelo de casos de uso con todos los casos de uso y su relación con los usuarios. • Un modelo de análisis. • Un modelo de diseño que defina la estructura estática, clases e interfaces y los casos de uso. • Un modelo de implementación que incluya componentes y la correspondencia de las clases con los componentes. • Un modelo de despliegue que defina los nodos físicos y la correspondencia de los componentes con esos nodos. • Un modelo de prueba. Descargado por SAMIR ALONSO CRISTANCHO CACERES (sacristancho52@misena.edu.co) lOMoAR cPSD| 4269609 • Una representación de la arquitectura. En cada ciclo se desarrollan cuatro fases, las cuales pueden descomponerse en iteraciones. Cada fase termina con un hito. Los hitos tienen varios objetivos, uno de los principales es brindar información para la toma de decisiones antes de empezar la siguiente fase o para otros proyectos. Las fases dentro de un ciclo son: Descargado por SAMIR lOMoAR cPSD| 4269609 • Fase de Inicio: En esta fase se identifican y priorizan los riesgos más importantes, y se desarrolla una descripción del producto final. • Fase de Elaboración: Se especifican en detalle la mayoría de los casos de uso del producto y la arquitectura del sistema. Al final de esta fase el director del proyecto debe tener lo necesario para planificar las actividades y estimar los recursos necesarios para terminar el proyecto. • Fase de construcción: En esta fase se crea el proyecto. Al final de esta fase, el producto contiene todos los casos de uso que la dirección y el cliente acordaron para la versión. • Fase de Transición: Cubre el periodo en la que el producto se convierte en versión beta. En esta fase se instruye al cliente y se encuentran y corrigen los defectos del producto. Conclusiones y Recomendaciones del Capítulo 1. Una vez expuestos todos los hechos mencionados anteriormente podemos concluir que: • El Proceso Unificado surgió como respuesta a las necesidades del usuario de obtener un sistema óptimo y de calidad en periodos de tiempo cortos. Es necesario que este proceso no puede ser usado para todo tipo de proyectos, ya que existen proyectos críticos que tomarán grandes cantidades de tiempo y en los cuales las pautas a seguir del Proceso Unificado no puedan aplicar. • Los casos de uso son algo necesario para el Proceso Unificado, ya que estos nos muestran el camino a seguir durante el desarrollo del sistema, y también nos muestra de que manera debe comportarse nuestro sistema, teniendo así una pauta para que, durante las pruebas, se pueda determinar si el sistema responde de la manera correcta o si hay algún tipo de error. • La arquitectura del software y los casos de uso están fuertemente ligados ya que, los casos de uso representan a las funciones y la arquitectura representa la forma del sistema en que se desarrollan estas funciones. Debido a esto tanto los casos de uso como la arquitectura deben desarrollarse y evolucionar simultáneamente. • Las iteraciones son pequeños avances del sistema, en cada iteración se resuelven una cantidad de casos de uso, empezando por los más importantes. Cabe recalcar que cada iteración es un sistema ejecutable y que el resultado de la suma de todas las iteraciones deberá ser el sistema final. • Tanto los casos de uso, como la arquitectura y las iteraciones están fuertemente ligadas y si se flaquea en una de ellas las otras también tendrán problemas. De igual manera se recomienda lo siguiente: • Ser muy cuidadoso durante la elaboración de los casos de uso, ya que un error en estos puede representar en varios errores a futuro. • También se recomienda trabajar con los usuarios ya que la retroalimentación es algo importante en el Proceso Unificado, así se evita la pérdida de tiempo innecesaria. Descargado por SAMIR ALONSO CRISTANCHO CACERES (sacristancho52@misena.edu.co) lOMoAR cPSD| 4269609 • Se recomienda que la entrega de cada iteración no sea muy larga y que cada una de estas pueda añadir un valor importante al avance del proyecto. Capítulo 2 Durante el desarrollo del sistema hay varios aspectos que se deben tomar en cuenta, entre estos están las cuatro P’s (Personas, proyecto, producto y proceso) y las herramientas. • Personas: Las personas son las que desarrollarán y usarán el sistema que se realiza, estos son seres humanos y no simplemente trabajadores. • Proyecto: Elemento organizativo a través del cual se gestiona el desarrollo de software. El resultado de un proyecto es una versión de un producto. • Producto: Artefactos que se crean durante la vida del proyecto, como los modelos, código fuente, ejecutables y documentación. • Proceso: Conjunto completo de actividades necesarias para transformar los requisitos de usuario en un producto. Es una plantilla para crear proyectos. • Herramientas: Software que se utiliza para automatizar las actividades definidas en el proceso. Figura 2. Las cuatro “P” en el desarrollo de software. Personas Las personas están constantemente implicadas en el desarrollo de un software, estas desde el inicio hasta luego de la entrega. Por lo tanto, el proceso que guía el desarrollo debe orientarse a las personas que lo utilizarán. Las distintas formas en que se organiza y gestionan un proyecto afecta de una manera significativa a las personas, por lo tanto, tenemos que tener en cuenta los siguientes conceptos: • Viabilidad del proyecto: Un proyecto que parece imposible puede afectar a la moral de los desarrolladores, es por esto que los proyectos que no son viables deben desecharse en una fase temprana. Descargado por SAMIR lOMoAR cPSD| 4269609 • • Gestión del riesgo: Las personas pueden llegar a sentirse incómodos si sienten que puede haber muchos riesgos en el desarrollo del proyecto, para esto se debe explorar los riesgos significativos en fases tempranas del proyecto. • Estructura de los equipos: La gente tiende a trabajar mejor en grupos pequeños, de entre seis y ocho miembros. • Planificación del proyecto: La gente tiende a no querer trabajar cuando saben que por mucho que lo intenten no obtendrán los resultados deseados. Facilidad de comprensión del proyecto: A la gente le gusta saber lo que está haciendo, hay que tener una arquitectura clara para que los desarrolladores tengan una visión general del proyecto. • Sensación de cumplimiento: La retroalimentación frecuente y las conclusiones obtenidas aceleran el ritmo de trabajo. Como se dijo anteriormente, a medida que el tiempo avanza la tecnología evoluciona y es por esto que los usuarios cada vez piden sistemas más complejos. Para esto se necesita que los procesos estén soportados por herramientas y UML. Para poder comprender y dar soporte a estos procesos más complejos las personas deberán trabajar con más personas. En años siguientes las personas serán decisivas en el desarrollo de software. El problema radica en hacerlas eficaces y permitir que se dediquen a lo que sólo los seres humanos pueden hacer. Una de las tareas esenciales de las organizaciones es convertir a sus recursos “latentes” en “trabajadores”. Se denomina trabajador a los puestos a los cuales se pueden asignar personas y los cuales esas personas aceptan. Cada trabajador es responsable de un conjunto de actividades para el desarrollo de un sistema. Para esto necesitan comprender sus roles y necesitan tener las herramientas para desarrollarlos. Así mismo un trabajador también puede representar a un conjunto de personas. Una persona puede ser muchos trabajadores durante la vida de un proyecto. Proyectos. Cada proyecto da como resultado una versión del producto. A través de su ciclo de vida, un equipo de proyecto debe preocuparse del cambio, las iteraciones, y el patrón organizativo dentro del cual se conduce el proyecto: • Una secuencia de cambios: A lo largo del proceso se realizarán varios cambios hasta llegar al producto deseado. En cada iteración se verá al sistema desde otra perspectiva, y cada ciclo representará una nueva versión del sistema. • Una serie de iteraciones: Cada iteración implementa un conjunto de casos de uso relacionados o atenúa algunos riesgos. En una iteración los desarrolladores progresan a través de una serie de flujos de trabajo. Es por esto que cada iteración puede ser tomada como un miniproyecto. • Un patrón organizativo: La gente que trabaja en el proyecto debe tener una plantilla, que indique a las personas los tipos de trabajadores que el proyecto necesita y los artefactos por los cuales trabajar. Producto. Descargado por SAMIR ALONSO CRISTANCHO CACERES (sacristancho52@misena.edu.co) lOMoAR cPSD| 4269609 En el Proceso Unificado un producto no es sólo al código que se entrega si o al sistema entero. Un sistema de software es todos los artefactos que se necesitan para representarlo en una forma comprensible por máquinas u hombres, tanto trabajadores como los interesados. Los artefactos son cualquier tipo de información creada, producida, cambiada o utilizada por los trabajadores en el desarrollo del sistema. Existen dos tipos de artefactos, artefactos de ingeniería y artefactos de gestión. Los artefactos de gestión son aquellos que tienen un tiempo de vida corto. El tipo de artefacto más usado en el Proceso Unificado es el modelo. Los modelos son las perspectivas de los trabajadores del sistema. Un usuario de un modelo no debe necesitar información de otros modelos para interpretarlo. La mayoría de los modelos de ingeniería se definen median un subconjunto de UML cuidadosamente seleccionado. Un sistema completo contiene todas las relaciones y restricciones entre elementos incluidos en diferentes modelos. Por lo tanto, un sistema es también como se relacionan todos sus modelos. El hecho de que los elementos en dos modelos estén conectados no cambia lo que hacen en los modelos a los que pertenecen. Procesos. Los procesos son los conjuntos de actividades necesarias para convertir los requisitos de usuario en un conjunto consistente de artefactos que forman el producto. Un proceso no cubre solo el primer ciclo de desarrollo, a medida que surgen cambios en los requisitos surgen cambios en los artefactos y por ende se añaden nuevos procesos. Podemos dividir el proceso entero en flujos de trabajo, en el cual los trabajadores y los artefactos son los participantes. Figura 3. Un flujo de trabajo con trabajadores y actividades en “calles”. Un proceso de desarrollo de software del mundo real debe ser adaptable y configurable para cumplir con las necesidades reales de un proyecto y/o organización concreta. Los factores que influyen en como se diferenciará el proceso son: • Factores organizativos: Reglas de la empresa, así como herramientas disponibles por la misma. Descargado por SAMIR lOMoAR cPSD| 4269609 • • Factores del dominio: El dominio de la aplicación, procesos de negocio que se deben soportar, la comunidad de usuarios y ofertas disponibles por la competencia. • Factores del ciclo de vida: El tiempo en salida al mercado, el tiempo de vida esperado, la experiencia de los desarrolladores. • Factores técnicos: Lenguajes de programación, herramientas de desarrollo, base de datos, marcos de trabajo, comunicaciones y distribución. Entre los méritos del proceso tenemos: • Todo el mundo en el equipo de desarrollo puede comprender lo que tiene que hacer. • Los desarrolladores pueden comprender mejor que lo que el resto está haciendo. • Los supervisores y directores pueden comprender lo que los desarrolladores están haciendo gracias a los esquemas de la arquitectura. Los desarrolladores, supervisores y los directores pueden cambiar de proyecto o de división sin tener que aprender un nuevo proceso. • La formación puede estandarizarse dentro de la empresa. • El devenir del desarrollo de software es repetible, es decir, puede planificarse y estimarse en coste con suficiente exactitud como para cumplir las expectativas. Herramientas. Las herramientas son soportes para los procesos de desarrollo de software modernos. Es por esto que las herramientas son esenciales en los procesos. Estas sirven para automatizar procesos repetitivos, mantener las cosas estructuradas y gestionar grandes cantidades de información, incluso sirven como guías en un camino de desarrollo concreto. Las herramientas están ahí para automatizar tanto como sea posible al proceso. Las herramientas que implementan un proceso deben ser fáciles de usar, sencilla de comprender y deben proporcionar un incremento de productividad sustancial. Solo si cumplen esto valdrá la pena implementarlas. Debe existir un equilibrio entre proceso y herramientas. Los procesos dirigen el desarrollo de herramientas, pero al mismo tiempo las herramientas dirigen el desarrollo del proceso. El proceso de poder aprender de las herramientas y las herramientas deben soportar un proceso bien pensado. Hay herramientas que soportan todos los aspectos del ciclo de vida del software: • Gestión de requisitos: Se utiliza para almacenar, examinar y revisar, hacer el seguimiento y navegar por los diferentes requisitos de un proyecto software. • Modelado visual: Se utiliza para automatizar el uso de UML, es decir, para modelar y ensamblar una aplicación visualmente. • Herramientas de programación: Editores, compiladores, depuradores, detectores de errores y analizadores de rendimiento. • Aseguramiento de la calidad: Prueba las aplicaciones y sus componentes. Descargado por SAMIR ALONSO CRISTANCHO CACERES (sacristancho52@misena.edu.co) lOMoAR cPSD| 4269609 Conclusiones y Recomendaciones del Capítulo 2. Habiendo analizado los hechos anteriores, podemos llegar a las siguientes conclusiones: • En el Proceso Unificado tenemos varios elementos, los cuales son muy importantes en todas las faces del desarrollo de un sistema, si uno de estos no está bien implementado, correctamente definido o no trabaja correctamente, podrá causar varios problemas o incluso podría causar el mal desarrollo de un sistema. • Dentro del Proceso Unificado, las personas son muy importantes, tanto los clientes como los desarrolladores, los clientes porque son los que recibirán el producto y los desarrolladores deberán tener un buen ambiente laboral y toda la seguridad en el proyecto para poder realizarlo efectivamente. • Un producto no es solo el sistema finalizado, si no también todos los elementos necesarios para asegurarnos que el sistema pueda ser utilizable por el usuario, así como los artefactos que se utilizaron para el desarrollo del sistema. • Los procesos y las herramientas están fuertemente vinculadas, ya que las herramientas nos ayudan a reducir esfuerzo y recursos durante los procesos, pero estas deben evolucionar paralelamente ya que una herramienta no puede ser creada si no se tiene bien definido a que proceso va a ayudar. De igual manera podemos recomendar: • Tomar en cuenta todos los factores que puedan afectar la moral de los trabajadores, ya que de estos depende el desarrollo del sistema. • No comprometerse a realizar proyectos que sean imposibles de realizar, ya que la moral de los trabajadores se verá afecta, y asegurarse de que se cubran todos los riesgos al momento de presentar el proyecto a los trabajadores. • Saber utilizar las herramientas que se implementarán en los distintos procesos, ya que de igual manera que estas pueden ayudar automatizar procesos, implementadas de la manera incorrecta o en procesos incorrectos pueden llegar a producir errores. Descargado por SAMIR
