introduccin al puds(proceso unificado de desarrollo de...

Cátedra de Proyecto – Ingeniería en Sistemas de la Información – 2005 –

Página 1 de 1

Introducción al PUDS(Proceso unificado de desarrollo de software) Orientación del aprendizaje En nuestros días, dada la importancia de la información como recurso estratégico que ayuda a generar ventajas competitivas para las empresas, se tiende a construir sistemas cada vez más grandes y complejos donde intervienen equipos de trabajo formados por numerosas personas con distintas funciones y roles. Tal situación nos lleva a definir mecanismos que nos ayuden a administrar esos grandes proyectos: programar las actividades en tiempo y forma, coordinar las actividades de cada integrante del equipo y entre ellos, y ofrecer criterios para permitir un control y medición de estas actividades. Un alto porcentaje de los sistemas fracasan por no contar con un adecuado proceso de desarrollo, o por su utilización inapropiada. Muchos desarrolladores se equivocan porque piensan que el desarrollo de software comienza con la programación en un lenguaje determinado, y ahí caen en una de las causantes más importantes de fracaso del sistema. Sea cual fuese el tamaño del sistema, es necesario que siempre nos apoyemos en un proceso de análisis y diseño como el que vemos a lo largo de la materia. Esta unidad nos servirá de introducción al proceso de desarrollo de software que explotamos en el resto de las unidades, vemos sus pilares y los principales conceptos en los que se apoya. Los contenidos que trabajamos en esta unidad son:

1. Ingeniería del software 1.1 ¿Qué es el ciclo de vida? 1.2 Aspectos del proceso de desarrollo 1.3 Tipos de modelo de ciclo de vida 1.4 Rol del cliente

2. Metodología de desarrollo 3. El proceso unificado de desarrollo de software

3.1 PUDS dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.

3.2 Fases y flujos de trabajo 4. Las cuatro P en el desarrollo del software 5. UML: lenguaje unificado de modelado

5.1 Modelos 5.2 Bloques básicos de construcción de UML

El siguiente esquema conceptual le presenta los ejes temáticos fundamentales y sus relaciones, y a modo anticipatorio lo orienta y ayuda a la contextualizar cada uno de los conceptos desarrollados. Esquema conceptual


Página 2 de 2

Bibliografía propuesta • JACOBSON, Ivar. El Proceso Unificado de Desarrollo. Editorial Addison Wesley. España. 2000. Capítulos 1, 2, 3, 4, 5. Bibliografía complementaria • DRUKER, Peter. Management: Tasks, Responsibilities, Practices. Editorial Harper & Row. New York. 1973 . • JACOBSON, Ivar y otros. Object Oriented Software Engineering: A Use Case Driven Approach. Editorial Addison Wesley. 1992. • KENDALL, Keneth E y KENDALL, Julie E. Análisis y Diseño de Sistemas. Tercera Edición. Editorial Prentice Hall Hispanoamericana S.A. México. 1997. • LARMAN, Craig. UML y Patrones. Primera Edición. Editorial Prentice Hall, Inc. México. 1999. • MC. MENAMIN, Steve y PALMER, John.. Essential Systems Analysis. Editorial Prentice Hall, Yourdon Press. 1984.

1. Ingeniería del software

Cuando una empresa se plantea la construcción de un nuevo software aparecen en la cabeza del líder del proyecto distintas consideraciones a tener en cuenta que serán críticas, pues de éstas dependerá el éxito o el fracaso del proyecto de desarrollo:

construir un software que cumpla con los requisitos previos planteados, construir un software que haga correctamente lo que se pidió,


Página 3 de 3

lograr un software que pueda adaptarse a los continuos cambios de toda organización actual,

cumplir con los tiempos pactados de finalización del proyecto, respetar los costos estimados en principio. No tener ésto en mente desde un principio y no darle la importancia que

merece nos puede ocasionar innumerables conflictos en las distintas etapas del desarrollo.

¿Cuáles son las causas que habitualmente generan este tipo de conflictos? No hay tiempo de recoger datos históricos. Los proyectos se llevan a cabo con descripciones vagas y con poca

comunicación con los usuarios finales. De esta forma no se recogen realmente las necesidades de los mismos.

Muchas veces sólo se analizan las necesidades de los usuarios finales, cayendo así en sus “vicios”, y de esta forma nos desviamos del objetivo final de lograr un software que cumpla con las necesidades de la organización.

Hay escaso tiempo y recursos dedicados a analizar los requerimientos y necesidades, y a documentar las mismas para utilizarlas como guía a lo largo de todo el proceso de desarrollo del software.

No se utiliza una metodología de desarrollo adecuada que nos permita lograr una aplicación que en el futuro sea adaptable a los cambios y nuevas necesidades organizacionales.

Hay veces que para adaptarse a los tiempos que se exigen para la entrega de una solución no se utiliza ninguna metodología de desarrollo y se arranca directamente con la programación de la aplicación.

Existe la dificultad que afrontan los desarrolladores para coordinar las múltiples cadenas de trabajo de un gran proyecto de software.

La solución de software obtenida posee una calidad cuestionable, funciona sin importar si lo hace de la mejor manera, y no posee una definición de estándares de calidad, lo cual nos lleva a un software difícil de mantener.

Ahora veremos de qué forma nos podemos asegurar el logro de una solución que no caiga en todos estos problemas anteriores. Para eso veremos en primera instancia el significado de la Ingeniería del Software, que va a ser nuestro “salvavidas” para no caer en todos estos errores irreversibles mencionados. La Ingeniería del Software es la aplicación de principios científicos al diseño, construcción y mantenimiento del software. ¿Cuáles son los principios científicos en los que se basa la ingeniería del software? De no existir los principios científicos la actividad de desarrollar software estaría más cerca a la artesanía que a la ingeniería, puesto que lo artesanal es en general algo único y su utilidad depende de la habilidad del artesano. ¿En qué ciencia se basa la actividad de construir software? La necesidad de dar respuesta a esta pregunta se relaciona con que se pretende producir software como producto industrial. Necesidad: producir software como objeto ingenieril, con características finales de confiabilidad y de reproducibilidad de los procedimientos utilizados para el desarrollo. Se pretende la existencia de un proceso de desarrollo de software que nos permita cubrir la necesidad planteada. 1.1 ¿Qué es el ciclo de vida? El término ciclo de vida se refiere a la idea de que un producto de software es el resultado de un proceso de desarrollo que se divide en fases. Podemos definir el término ciclo de vida como la actividad de producir y mantener Sistemas Informáticos.


Página 4 de 4

Sus funciones son las siguientes: 1- establecer un orden en el que se:

especifica realiza un prototipo diseña implementa prueba mantiene

2- determinar los criterios para pasar de una fase a otra.

El ciclo de vida está de acuerdo con la metodología que se utilice. Hay metodologías en donde el ciclo de vida tiene un comienzo, se pasa por las distintas etapas antes mencionadas y llega a un fin. En otras metodologías el ciclo de vida esta formado por diversas iteraciones, cada una recorre todas las etapas y se van logrando versiones intermedias del producto. Luego se sigue con otra iteración que pasa nuevamente por todas las etapas y se sigue así avanzando hasta que se logra el producto completo finalizado. En la definición del plan del proyecto el modelo de ciclo de vida seleccionado influye en el éxito del proyecto como cualquier otra decisión de planificación que se tome. El modelo de ciclo de vida puede orientar su proyecto y ayudarlo a asegurar que cada paso se acerca más a la consecución del objetivo. Dependiendo del ciclo de vida que se seleccione se puede:

Aumentar la velocidad del desarrollo Mejorar la calidad Mejorar el control Mejorar el seguimiento del proyecto Minimizar gastos Minimizar riesgos Mejorar las relaciones con el cliente

1.2 Aspectos del proceso de desarrollo Para llevar a cabo un proceso de desarrollo necesitamos: Modelo de proceso (ciclo de vida)

• Orden de las fases en el desarrollo de software • Criterios de transición entre las fases

Metodología de software • La navegación se hace a través de cada fase

Notación de software • Representación de elementos utilizados en cada fase

Taxonomía de modelos de proceso Enfoque secuencial

• Nunca retorna a un paso completado. • Sólo práctico para proyectos muy pequeños, no críticos.

Enfoque iterativo • Puede retornar a cualquier paso ya completado para introducir un cambio,

propagando su efecto hacia delante a lo largo del ciclo de vida. • La mayoría de los modelos de ciclo de vida son iterativos.

Mecanismo recursivo • Todo el enfoque puede ser reaplicado a los productos finales. • Todos los enfoques recursivos del ciclo de vida son iterativos, pero no todos los

enfoques iterativos son recursivos. Metodología de software Análisis y diseño estructurados

• Descomposición funcional.


Página 5 de 5

• Orientado a flujos de datos. Modelo orientado a datos

• Originado en la comunidad de bases de datos. • Se concentra en la información.

Orientación a objetos • Sitúa el dominio de un problema y su solución lógica dentro de la perspectiva

de los objetos (cosas, conceptos o entidades). Notaciones de software Diagrama de flujo de datos

• Muestra relaciones funcionales. • Gráficos cuyos nodos son procesos y las líneas son flujos de datos.

Diagrama de estado • Muestra aspectos dinámicos. • Gráficos cuyos nodos son estados y sus líneas son transiciones entre ellos

causando eventos. Diagramas de entidad-relación

• Muestra la estructura estática de los componentes de sistema y sus relaciones. • Gráficos cuyos nodos son entidades y sus líneas son relaciones entre ellas.

Diagrama de objetos • Gráficos cuyos nodos son clases de objetos y sus arcos son relaciones entre las

clases. Diagrama de clases

• Indica las características relevantes de una clase singular. Si está en condiciones de responder a las siguientes preguntas, continúe con el próximo tema. ¿Cuáles son los problemas que presenta el software? 1.3 Tipos de modelo de ciclo de vida Cascada pura Sirve de base para otros modelos. Es una secuencia ordenada de pasos en la cual se realiza una revisión al finalizar cada etapa para determinar si se pasa a la siguiente. Si no está listo permanece en la etapa actual hasta que esté completa. El producto final de los trabajos que se pasan de una etapa a otra son documentos. Esta es una de las metodologías más tradicionales y utilizadas hace unos años. Pregona que la mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno, independientemente de los objetos que interactúan dentro del sistema para proveerlos. Es bueno cuando: • se tiene definición estable del producto, • el proyecto de análisis es relativamente pequeño. Tiene varias desventajas, por lo cual poco a poco está empezando a dejar de utilizarse: • dificultad de especificar claramente los requerimientos al comienzo del proyecto, por lo cual generalmente se debe volver atrás, • genera pocos signos visibles de progreso hasta el final, • los usuarios no pueden ir viendo el avance real del proyecto, recién cuando éste está terminado pueden ver el proyecto funcionando, lo cual puede generar a esa altura disconformismos que son muy difíciles de corregir, • la vuelta atrás es posible pero complicada de realizar debido a que debemos cambiar muchas cosas para lograrla.


Página 6 de 6

cremental

e camino porque el sistema está listo para ser entregado

to de la aplicación y poco a poco lo vamos rellenando hasta lograr una lución completa.

spiral

s, los que comprenden riesgos en los requerimientos, en la tecnología, en

ía poco conocida u obsoleta, políticas no lineadas con los objetivos de la organización, etc..

e deben ser manejados:

ión de los recursos humanos para la gestión, ya que su plementación no es sencilla.

identificación y análisis de los riesgos y luego se crea un plan para controlarlos. Una vez hecho

In Este modelo se basa en realizar entregas frecuentes de software operativo a los clientes. Al realizar entregas semanales, quincenales o mensuales del producto, la comunicación es más efectiva, se reduce el riesgo dividiendo el proyecto en una serie de subproyectos más pequeños aumentando la visibilidad del progreso, proporcionando módulos terminados y operativos de un sistema grande antes de tener operativo el sistema completo. Tenemos una mayor capacidad para hacer modificaciones a mitad dmuchas veces durante el desarrollo. Cada incremento pasó por las distintas fases del desarrollo de software, con lo cual en las primeras etapas podemos hacer un análisis y mitigación de riesgos mucho más efectiva que en un ciclo en cascada, ya que no tenemos que esperar hasta las fases finales para encontrar, por ejemplo, un problema de implementación que requeriría que hagamos gran cantidad de modificaciones sobre lo que ya hemos realizado. Al ir avanzando de esta forma vamos primero armando el esqueleso E Se trata de un modelo que divide el proyecto en subproyectos más pequeños o mini proyectos, cada uno de los cuales se enfoca en controlar uno o más riesgos determinados. Es un modelo centrado en los riesgola arquitectura, etc.. Es un modelo ideal cuando: • existe poca identificación de los requerimientos, • hay riesgos importantes que deben ser tenidos en cuenta desde el principio, ya que podrían poner en peligro el proyecto, tales como tecnologa Este modelo presenta inconvenientes qu• necesita una planificación adecuada, • se necesita tiempo considerable para la gestión del proyecto, • requiere suficiente preparacim En el gráfico que se encuentra a continuación observamos que el trabajo se inicia con la


Página 7 de 7

ésto se avanza a la próxima iteración. El hito que permite el paso a la siguiente iteración es el manejo de los riesgos en un nivel que se considere aceptable para el proyecto. Las primeras iteraciones son las menos costosas, a medida que nos alejamos del centro de la espiral los costos aumentan y los riegos disminuyen, es decir, que mientras más tiempo y dinero se invierta en el desarrollo del proyecto, mayor cantidad de riesgos estarán controlados. Cada iteración implica realizar los siguientes pasos: o Definir objetivos, alternativas y límites. o Identificar y controlar riesgos. o Evaluar alternativas. o Realizar las entregas de la iteración. o Planificar la próxima iteración. o Fijar el enfoque de la siguiente iteración.

Prototipado evolutivo Este modelo comienza por desarrollar los aspectos visibles del sistema, se presenta el prototipo al cliente, se logra el acuerdo con el mismo y continúa el desarrollo. Es útil cuando: • no es posible definir con claridad los requerimientos debido a que cambian reiteradamente o no existe acuerdo con los usuarios, • el proyecto debe mostrar rápidamente y al poco tiempo signos visibles de avance, • se estima que se deberán realizar modificaciones importantes en la mitad del camino de desarrollo del proyecto. Presenta inconvenientes tales como: • no se conoce el tiempo que tomará terminar el producto, • no se sabe cuántas iteraciones se deberán realizar, • no está ligado a una planificación rigurosa.


Página 8 de 8

1.4 Rol del cliente Parte de nuestro trabajo como desarrolladores es educar a los clientes para que comprendan mejor el desarrollo de software, sin olvidarnos de que el proceso de desarrollo debe estar orientado al él. En general, los clientes no entienden que un retraso de una semana para realizar la revisión de un documento importante se puede traducir luego en un retraso de una semana en la entrega del producto. En este sentido, uno de los errores más costosos es el de desarrollar un software que sea rechazado por el usuario a último momento. En general, se suelen rechazar partes del software, ésto significa que se tiene que volver a diseñar e implementar. Entonces, el efecto global es la entrega retrasada. Usted debe evitar tener que repetir el trabajo ya realizado. Factores que pueden generar riesgos en la planificación: Clientes que: • no saben lo que quieren, • no quieren comprometerse a tener un conjunto de requerimientos escritos, • insisten en establecer nuevos requerimientos una vez realizada la planificación, • no participan en la revisión o se niegan a hacerla, • no están preparados técnicamente, • no dejan realizar el trabajo a la gente debido a que por algún motivo se oponen al nuevo proyecto, • son nuevos – desconocidos, por lo que no sabemos los riesgos que tenemos, • la comunicación con los clientes es lenta. Importancia del cliente en el desarrollo Las tres razones principales para que los proyectos: • terminen tarde, • sobrepasan el presupuesto, • tengan menos funcionalidad a la deseada, se debe a la: • deficiente comunicación con el usuario, • falta de especificación de requerimientos, • modificación de requerimientos y especificaciones. Hay dos razones principales por las que se debe prestar atención a las relaciones con el cliente. Primero, porque aumenta la velocidad del desarrollo al eliminar una fuente de errores e ineficiencia en el desarrollo. Segundo, porque mejora la percepción en el cliente de la velocidad del desarrollo haciendo posible estructurar el proyecto de manera que el usuario pueda ver el progreso y aumentar su confianza.


Página 9 de 9

Una vez que hemos hecho una introducción a la ingeniería del software comenzamos a analizar una metodología de desarrollo de software que sigue los lineamientos de los ciclos de vida incrementales. 2 Metodología de desarrollo Cabe aclarar que cuando hablamos de dominio hacemos referencia a una parte de la realidad del cliente. El problema está en un dominio, mientras que el observador está fuera de dicho dominio. Se puede construir software para satisfacer un cliente o para investigar la realidad con un modelo computacional. Para representar un dominio mediante un modelo computacional disponemos de dos enfoques: • representar de forma lo más completa posible un dominio y luego identificar aplicaciones (es un proceso lento, dos años aproximadamente), • construir aplicaciones directamente a partir de los requerimientos (es más rápido y directo). Deseamos modelar la realidad y para ello realizamos un modelo general y luego desarrollamos aplicaciones particulares de acuerdo a las necesidades del cliente (requerimientos). Si se piensa en el software como un producto, seguramente Ud. ya habrá deducido que necesitamos de un proceso de fabricación. El proceso es la visión dinámica y la metodología es la visión estática. Un método es una descripción formal de un procedimiento, un conjunto de tareas realizadas en un determinado orden para alcanzar un objetivo. Una metodología es un conjunto de métodos a aplicar en un determinado procedimiento, es un conjunto de técnicas, métodos, herramientas, productos y roles para obtener software. • Permite que se entienda el lenguaje usado. • Permite formar equipos con personas de diferentes niveles. • Está fuertemente asociada al desarrollo y al tipo de software. Así, el proceso es poner en funcionamiento una metodología.

3 El proceso unificado de desarrollo de software


Página 10 de 10

Como mencionábamos hace algunas líneas, encarar cualquier tipo de proyecto sin contar con un proceso de desarrollo puede traer infinidad de problemas antes, durante o después del desarrollo del mismo. Contar con un proceso es contar con una herramienta que nos va guiando y sirviendo de bastón de apoyo durante el ciclo de vida de un Sistema, desde sus inicios hasta el mantenimiento del mismo. Un alto porcentaje de los sistemas que fracasan es por no contar con un Proceso de Desarrollo, o a la inapropiada utilización del mismo. Muchos desarrolladores piensan que el desarrollo de software comienza con la programación del mismo en un lenguaje determinado, y ahí caen en una de las causantes más importantes de fracaso del Sistema. Sea cual sea el tamaño del Sistema es crítico que nos apoyemos en un proceso. Este proceso nos va llevando paso a paso por cada etapa del desarrollo, y va guiando y coordinando la intervención de los distintos roles involucrados en el desarrollo del mismo. De ahora en adelante veremos cómo apoyarnos en un proceso para encarar proyectos de desarrollo de software. Éste se denomina proceso unificado de desarrollo de software y abarca el conjunto de actividades necesarias para transformar los requisitos de los distintos usuarios en un Sistema Informático. El proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language - UML) para representar todos los esquemas necesarios en las distintas fases del desarrollo de software, los que veremos a medida que avancemos en el desarrollo de cada fase. 3.1 PUDS dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental. Este proceso se apoya en tres pilares alrededor de los cuales gira la totalidad de la metodología. Éstos son los casos de uso, la arquitectura y el concepto de iterativo e incremental. Casos de uso Las necesidades del cliente no son fáciles de detectar. Ésto nos lleva a que utilicemos algún modo de capturar estas necesidades de manera que posteriormente puedan comunicarse al resto de los intervinientes en el proyecto. Existen entonces dos objetivos fundamentales: encontrar los verdaderos requisitos y representar los mismos de un modo adecuado para los usuarios, clientes y desarrolladores. Un sistema debe dar solución a lo que el cliente espera, y los casos de uso nos van a permitir analizar minuciosamente esos requerimientos. Ellos han sido adoptados casi universalmente para la captura de requisitos de sistemas de información. Debemos aclarar que dichos casos de uso son mucho más que una simple herramienta de captura de requisitos, ya que dirigen el proceso de desarrollo en su totalidad. Los desarrolladores crean un modelo de análisis que utiliza el modelo de casos de uso como entrada y que es diferente del modelo de diseño porque es un modelo conceptual en lugar de ser un esquema de la implementación. Cada caso de uso en el modelo de casos de uso se traduce en una realización de caso de uso en el modelo de análisis. Tomando los casos de uso uno a uno, los desarrolladores pueden identificar las clases que participan en la realización de aquellos. Así obtenemos un conjunto de clases que juntas realizan los casos de uso. Luego los desarrolladores diseñan las clases y las realizaciones de casos de uso para aprovechar al máximo las tecnologías y productos a utilizarse. A continuación se implementan las clases diseñadas mediante un conjunto de archivos a partir de los cuales se pueden generar (ejecutables, DLL’s, JavaBeans, componentes ActiveX, páginas web, etc.). Finalmente, durante el flujo de trabajo de prueba, los ingenieros corroboran que el sistema implementa la funcionalidad descrita en los distintos casos de uso, y de esta forma se satisfacen los requerimientos para los que fue construido.


Página 11 de 11

Hemos descrito de una manera muy simplificada cómo los casos de uso guían al proceso unificado, lo hemos visto sólo con una iteración. Vemos cómo este mismo proceso se repite de manera iterativa e incremental a medida que avanzamos en el proceso de desarrollo.

Análisis, diseño e implementación para realizar los casos de uso Durante el análisis y el diseño transformamos el modelo de casos de uso desde un modelo de análisis en un modelo de diseño. El modelo de análisis va creciendo más y más en cada iteración. Por cada iteración se seleccionan determinados casos de uso y se los refleja en el modelo de análisis, se comienzan a construir clases de análisis y relaciones entre ellas. Luego, es necesario complementar este modelo de análisis con un modelo que permita plasmar la forma en que interactúan las distintas clases para llevar a cabo la realización del caso de uso. Aparecen de esta forma los diagramas de colaboración. El modelo de diseño se crea tomando como entrada principal el modelo de análisis y adaptándose al entorno de implementación elegido. Funciona como esquema para la implementación. Con ésto queremos indicar que el modelo de diseño es más “físico” por naturaleza, mientras que el modelo de análisis es más “conceptual”. De igual forma que el modelo de análisis, el modelo de diseño también define clasificadores (clases, subsistemas e interfaces). Es imposible pensar en un sistema de tamaño sin incorporar la idea de subsistemas, a través de éstos podemos hacer una organización de clases de acuerdo a funciones definidas que desempeñen las mismas. Por medio de los subsistemas podemos crear una organización de alto nivel a través de la cual podemos tener una comprensión global mucho más clara. Durante el modelo de implementación procedemos a elaborar todo lo necesario para obtener un sistema en ejecución. Este modelo está constituido por componentes (archivos ejecutables, componentes, páginas web, etc.). Estos componentes son la realización de un conjunto de interfaces y pueden ser reemplazables, siempre y cuando el nuevo componente respete y se adapte a estas interfaces previamente definidas. Estas interfaces representan la forma de comunicación con el exterior, en este caso con otros componentes (propiedades, métodos). En el caso en que se utilice un lenguaje de programación orientado a objetos existirá una relación directa entre clases de diseño y componentes de implementación. Una vez que implementamos estos componentes es necesario hacer pruebas de funcionamiento sobre los mismos antes de proceder a comenzar con la realización de pruebas de la totalidad del sistema. El objetivo de este punto es, no sólo probar el correcto funcionamiento del sistema, sino también controlar que el sistema desempeñe correctamente todas aquellas funcionalidades para las que fue creado, es decir que debemos chequear contra los casos de uso. Se utiliza un modelo compuesto por casos de prueba y procedimientos de prueba a partir del cual podemos ir chequeando la funcionalidad plasmada en los casos de uso contra los requerimientos esperados. Centrado en la arquitectura


Página 12 de 12

La arquitectura describe los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo. El objetivo número uno de la fase de elaboración es construir una arquitectura sólida para que a partir de la misma podamos arrancar con la construcción de la totalidad del sistema sin tropiezos posteriores. El rol del arquitecto es crear los aspectos más significativos del sistema en su conjunto. A la hora de ir pasando por las distintas fases del proyecto los desarrolladores utilizarán la arquitectura como guía general para situarse correctamente en el lugar en donde están parados y usarán los distintos diagramas más detallados para realizar su trabajo. Cuando hablamos de arquitectura hablamos también del concepto de vista, ya que se generan vistas sobre los distintos modelos que hemos estado viendo y que abarcan sólo aquellos casos de uso importantes en este contexto. La descripción de la arquitectura tiene cinco vistas, una para cada modelo: 1. Casos de uso 2. Análisis 3. Diseño 4. Despliegue 5. Implementación Usted en realidad se estará preguntando para qué se necesita tener definida una arquitectura. Se necesita para: • comprender el sistema, • organizar el desarrollo, • permitir la reutilización, • hacer evolucionar el sistema.

Fuente: Jacobson, Ivar. Booch, Grady. Rumbaugh, James. El Proceso Unificado de Desarrollo del Software. Ed. Addison Wesley. Madrid, 2000. En la descripción de la arquitectura no se pretende cubrir absolutamente todo, no debería inundar a los participantes con detalles minuciosos. Hay mucha información que no es necesaria tener en cuenta a la hora de describir la arquitectura. Por ejemplo, la experiencia indica que sólo el 10 % de las clases de un sistema son relevantes para la arquitectura, el 90 % restante no es significativo porque no es visible a todo el sistema.


Página 13 de 13

Así también es importante que usted comprenda que no todos los casos de uso son relevantes a la hora de definir la arquitectura, hay ciertos casos de uso arquitectónicamente relevantes y son sólo éstos los que guían la arquitectura y por lo tanto, los que se deben tener en cuenta a la hora de describirla. Ya vimos en puntos anteriores cuán crítica es la relación entre casos de uso y arquitectura, unos condicionan lo otro y viceversa. Por eso es imprescindible utilizar un mecanismo que permita ir avanzando poco a poco en el refinamiento de unos como de otros, es decir, vamos avanzando por etapas. Ésta es la clave del tercer pilar alrededor del cual gira el proceso unificado de desarrollo de software: proceso iterativo e incremental. El decir, basarnos en un proceso iterativo e incremental nos diferencia mucho con metodologías de desarrollo tradicionales en las cuales el desarrollo también se realiza por etapas, pero las mismas se van realizando en serie, una detrás de la otra sin posibilidad por ejemplo de recibir retroalimentación en alguna y volver para atrás para modificar funcionalidad. Se cumplen las etapas, se van cerrando y se avanza a la siguiente. En nuestro caso la base es que el proceso sea realmente iterativo e incremental, es decir: • planificar un poco, • especificar, diseñar e implementar un poco, • integrar, probar y ejecutar un poco cada iteración. Es decir, se divide el proyecto en un número de mini proyectos, siendo cada uno de ellos una iteración. Cada iteración está compuesta por todas las fases de un proyecto de software, es decir que cada una de ellas sería como un miniproyecto hecho con una metodología tradicional, como la de cascada. Se debe manejar con mucho cuidado el hecho de poder avanzar y recibir retroalimentación y retroceder, ya que si tomamos ésto como moneda corriente podemos caer en un terreno donde nos mantengamos siempre en un mismo lugar sin percibir avance alguno. Un párrafo del capítulo 5 de la bibliografía propuesta resume muy bien el concepto de iteración: “... la iteración controlada está muy lejos de ser aleatoria. Se planifica. Es una herramienta que pueden utilizar los directores para controlar el proyecto. Reduce, al principio del ciclo de vida, los riesgos que pueden amenazar el progreso del desarrollo. Las versiones internas tras las iteraciones posibilitan la retroalimentación de los usuarios y ésto lleva a su vez a una corrección temprana de la trayectoria del proyecto”. Para resumir, los principales objetivos de un desarrollo iterativo e incremental son: • Atenuar los riesgos. • Obtener una arquitectura robusta. • Gestionar requisitos cambiantes. • Permitir cambios tácticos. • Conseguir una integración continua. • Conseguir un aprendizaje temprano.


Página 14 de 14

¿De qué forma usted relacionaría estos puntos con los otros dos pilares alrededor de los cuales gira este proceso unificado (casos de uso y arquitectura)?. La reducción de riesgos es uno de los puntos más importantes a tener en cuenta. Esta metodología permite en las primeras fases de un proyecto, identificar, gestionar y reducir los diferentes tipos de riesgos a los que se puede ver expuesto un proyecto. A diferencia de metodologías como la de cascada, que debido a que el desarrollo pasa en un solo sentido por una serie de pasos: requisitos, análisis, diseño, implementación y prueba, los problemas pueden empezar a surgir en las etapas finales, cuando el sistema ya se está implementando o testeando, lo cual genera grandes costos y perdidas de tiempo para volver atrás y cambiar funcionalidades que ya estaban listas, terminadas y cerradas. En el desarrollo iterativo, una vez que se han identificado los riesgos, se debe optar por una de cuatro acciones posibles: • Evitarlo • Limitarlo • Atenuarlo • Controlarlo

3.2 Fases y flujos de trabajo Podemos decir que un proyecto está compuesto por un gran numero de iteraciones. Cada una es un pequeño proyecto en sí mismo, y constituye una pasada por los flujos de trabajo fundamentales. Los flujos de trabajo fundamentales son:


Página 15 de 15

• Requisitos • Análisis • Diseño • Implementación • Prueba

En el proceso unificado tenemos flujos de trabajo fundamentales y flujos de trabajo de iteración. Los primeros nos ayudan a describir los segundos, ya que los de iteración incluyen los cinco flujos de trabajo y además la planificación que precede a los flujos de trabajo y la evaluación que va detrás de ellos.

Los flujos de trabajo fundamentales serán analizados en profundidad a lo largo de las siguientes unidades.


Página 16 de 16

El primer paso hacia la división del proceso de desarrollo de software consiste en separar las partes en cuatro fases atendiendo al momento en que se realizan: • Inicio • Elaboración • Construcción • Transición En la fase de inicio se define el negocio y sus objetivos, así como la factibilidad del proyecto, se delimita el ámbito, se describe la arquitectura candidata posible y se identifican los riesgos críticos. El énfasis recae en los requerimientos. En la fase de elaboración se capturan los requerimientos restantes (aproximadamente el 80 % de los mismos), se establece la arquitectura base para la construcción y se monitorean los riesgos. Se enfoca en los requerimientos, el análisis y el diseño. En la fase de construcción se realiza el sistema según una arquitectura estable, se genera una versión beta del mismo (operativa) y se crea material de usuario. El énfasis está en la implementación y la prueba. En la fase de transición se actualiza el entorno en el que va a funcionar el sistema (sistemas operativos, hardware, etc..), se crean los manuales del sistema, se ajusta el software al entorno de trabajo, se corrigen errores y deficiencias y se genera una versión formal del sistema. Cada una de las fases se divide en una o más iteraciones. Cada una de las cuatro fases de un proyecto finaliza con un hito principal: _ Inicio: objetivos del ciclo de vida _ Elaboración: arquitectura del ciclo de vida _ Construcción: funcionalidad operativa inicial _ Transición: versión del producto Realice un gráfico donde pueda resumir cómo está estructurado un proyecto de desarrollo de software. Incluya todo lo referido a flujos de trabajo fundamentales y de iteración. Para llegar a cada hito principal se van cumpliendo hitos secundarios, los cuales constituyen las distintas iteraciones que tenemos dentro de las diferentes fases. Éstos van permitiendo alcanzar nuevos incrementos sobre los flujos de trabajo fundamentales (requisitos, análisis, diseño, implementación y prueba). 4 Las cuatro P en el desarrollo del software Dentro de todo proyecto de desarrollo de software intervienen los siguientes conceptos que serán claves para comprender el resto de los temas que tratamos en esta materia. • Personas • Proyecto • Producto • Proceso En todo proyecto participan personas que se encargan de las tareas que van desde la planificación hasta la utilización del sistema, pasando por la gestión, desarrollo, prueba etc.. Estas personas reciben el nombre de trabajadores. O sea que un trabajador es un papel que una persona o grupo de personas desempeñan en el desarrollo del software. Todo trabajador realiza actividades específicas de acuerdo a su habilidad, a la vez que tiene responsabilidades asignadas. Durante el desarrollo del proyecto se construyen productos, que son los artefactos que se crean durante la vida de dicho proyecto, puede tratarse de documentación, modelos, ejecutables, etc..


Página 17 de 17

Antes de continuar aclaremos la noción de artefacto, que es cualquier información empleada en el proyecto, por ejemplo los modelos que UML permite construir y que posibilitan a los trabajadores llevar adelante el proyecto. Un artefacto es creado, modificado y mantenido por un trabajador. En la definición anterior se empleó el concepto de modelo, un modelo es una abstracción del sistema que captura algunos elementos de dicho sistema y omite otros. Describe al sistema desde algún punto de vista o según algún aspecto. De acuerdo a ésto podríamos decir que un sistema puede ser descrito por un conjunto de modelos, cada uno de los cuales permite interpretar el sistema según una perspectiva en particular. Ejemplos pueden ser el modelo de casos de uso, el modelo de análisis, etc.. que estudiaremos en las próximas unidades. El proceso permite transformar los requerimientos recopilados en un conjunto de artefactos que constituyen el sistema. 5 UML: lenguaje unificado de modelado Veamos ahora por qué el PUDS emplea UML. UML (Unified Modeling Languaje) es un lenguaje estándar que se utiliza para realizar modelos de software. Se usa para visualizar, especificar, construir y documentar sistemas. UML es un lenguaje que brinda un vocabulario particular y reglas específicas que se focalizan en la representación conceptual y física del sistema. Este vocabulario y estas reglas dicen cómo crear y leer modelos, pero no dicen qué modelos se deben crear ni cuándo. Esta tarea le corresponde al proceso unificado de desarrollo. Para representar un sistema se necesitan múltiples modelos, los cuales están conectados unos con otros para describir y comprender dicho sistema. Para sistemas software se requiere un lenguaje que provea distintas vistas de la arquitectura del sistema y muestre cómo esa arquitectura evoluciona a través del ciclo de vida de desarrollo. Un proceso bien definido dirá qué artefactos producir, qué actividades realizar y qué personas (trabajadores) los crean, usan y administran, y cómo emplear estos artefactos para medir y controlar el proyecto como un todo. UML es: • Lenguaje de visualización: facilita la comunicación de los modelos conceptuales a otros y disminuye errores al permitir hablar el mismo lenguaje. Permite interpretar los modelos sin ambigüedades, ya que UML tiene una semántica bien definida. • Lenguaje de especificación: especificación significa construir modelos precisos, no ambiguos y completos. UML especifica las decisiones de análisis y diseño que deben llevarse a cabo, como así también las de implementación. • Lenguaje de construcción: no es un lenguaje de programación, pero sus modelos pueden ser conectados a una variedad de lenguajes de programación, como Java, C++, Visual Basic. Se puede generar código a partir de un modelo UML y aún hacer ingeniería reversa (se puede construir un modelo a partir de una implementación). UML permite ejecución de modelos y simulación de sistemas. • Lenguaje de documentación: documenta requerimientos, arquitectura, diseño, codificación, plan de proyecto, prueba, prototipo, versiones software. 5.1 Modelos


Página 18 de 18

Los modelos son simplificaciones de la realidad. Construimos modelos para comprender mejor los sistemas, porque debido a la complejidad de los mismos no es posible abordarlos en su totalidad tal como son en la realidad. A través del modelado se logran los siguientes objetivos: • ayudar a visualizar cómo es el sistema, • permitir especificar la estructura del sistema, • especificar el comportamiento del sistema, • proporcionar plantillas que guían la construcción del sistema, • documentar las decisiones adoptadas. Un modelo tiene dos aspectos esenciales: Semántica: se trata de la información o significado del modelo. Presentación visual: es la notación que muestra el modelo de una forma comprensible. Organiza la presentación del modelo. 5.2 Bloques básicos de construcción de UML Mencionaremos a continuación los elementos básicos de UML y sus relaciones, que luego en las próximas unidades utilizaremos en la construcción de artefactos. 1) Elementos: a) Estructurales (estáticos): son partes estáticas de los modelos y representan cosas conceptuales. Existen siete tipos: I) Clase: describe un conjunto de objetos.

II) Interfaz: es una colección de operaciones que especifican un servicio de na clase o componente. Describe comportamiento visible. Define un onjunto de especificaciones (no implementaciones).

III) Colaboración: define una interacción, roles y otros elementos que colaboran para llevar a cabo un comportamiento colaborativo. Las colaboraciones tienen dimensión estructural y de comportamiento.

IV) Caso de uso: expresa una interacción entre un usuario externo y el sistema.


Página 19 de 19

V) Clase activa: sus objetos tienen uno o más hitos de ejecución y pueden riginar actividades de control.

VI) Componente: es una parte física y reemplazable del sistema.

VII) Nodo: elemento físico que existe en tiempo de ejecución y representa un recurso computacional (memoria, capacidad de procesamiento, etc.). Un conjunto de componentes puede residir en un nodo y migrar a otro.

b) De comportamiento (dinámicos): partes dinámicas de los modelos UML. Son los verbos de un modelo y representan comportamiento en tiempo y espacio.

I) Interacción: conjunto de mensajes intercambiados entre un conjunto de objetos.

II) Máquina de estados: comportamiento que especifica la secuencia de estados por los

que pasa un objeto o una interacción durante su vida en respuesta a eventos.

c) De agrupamiento: son las partes organizativas de los modelos UML. Son las capas en las que puede descomponerse un modelo. Paquete: es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, de comportamiento y de agrupación se pueden incluir en un paquete. Son puramente conceptuales, no existen en tiempo de desarrollo.


Página 20 de 20

d) De anotación: son las parte explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clarificar y observar sobre cada elemento del modelo.

Nota: muestra restricciones y comentarios. 2) Relaciones a) Dependencia: relación semántica entre dos elementos. Un cambio en el elemento independiente puede provocar un cambio en el elemento dependiente.

b) Asociación: relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un tipo especial de asociación que representa una relación estructural entre el todo y sus partes.

c) Generalización: relación especialización/generalización.

d) Realización: relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Por ejemplo entre los casos de uso y las colaboraciones que los realizan.

3) Diagramas - De clases - De objetos del dominio - De casos de uso - De secuencia - De colaboración - De estados - De actividades - De componentes - De despliegue Solución a las actividades de proceso 1. La complejidad del dominio del problema se debe a:


Página 21 de 21

• gran cantidad de requerimientos funcionales, • requerimientos vagos, • falta de comunicación con los desarrolladores, • cambio en los requerimientos durante el desarrollo, • expresar requerimientos con gran cantidad de texto, • los sistemas tienden a evolucionar en el tiempo. 2. El término ciclo de vida intenta captar la idea de que un producto de software es el resultado de un proceso de desarrollo que puede dividirse en fases. Podemos definir el ciclo de vida como la actividad de producir y mantener sistemas informáticos. Su función es: • establecer un orden en el que se:

- especifica - realiza un prototipo - diseña - implementa - prueba

• establecer los criterios para pasar de una fase a otra 3. La arquitectura está influenciada por aquellos casos de uso que queremos que el sistema soporte. Los casos de uso conducen la arquitectura. También utilizamos nuestro conocimiento de la arquitectura para hacer mejor el trabajo de captura de requisitos para obtener casos de uso. La arquitectura guía los casos de uso. 4. La mejor forma de resolver este conflicto es la iteración. Primero construimos una arquitectura básica a partir de una buena comprensión del dominio, sin considerar los casos de uso detallados. Luego escogemos algunos casos de uso y ampliamos la arquitectura adaptándola para que soporte esos casos de uso. Después tomamos otros casos de uso y ampliamos todavía más la arquitectura, y así sucesivamente. Cada iteración nos va permitiendo mejorar la arquitectura. Los casos de uso que son importantes analizar para la construcción de la arquitectura son aquellos que nos ayudan a cubrir todas las funcionalidades y a mitigar los riesgos más importantes, aquellos fundamentales para los usuarios del sistema. 5. No es un desarrollo que se base en la prueba y error. Armamos y probamos, si funciona seguimos, si no, retrocedemos y cambiamos. La tercera clave del PUDS consiste en desarrollar un producto en pasos pequeños: a. Planificar un poco. b. Especificar, diseñar e implementar un poco. c. Integrar, probar y ejecutar un poco cada iteración. Una iteración no es una entidad independiente, es una etapa dentro de un proyecto, es un mini proyecto. Cada mini proyecto se parece al antiguo ciclo de vida en cascada. Cada iteración sería una mini cascada. El ciclo iterativo produce resultados tangibles en forma de versiones preliminares y cada una de ellas aporta un incremento. 6. Algunos riesgos pueden y deben evitarse quizás a través de una replanificación de requisitos. Otros deberían limitarse para que afecten a una pequeña parte del proyecto. Algunos riesgos pueden atenuarse observando si aparecen o no, y si aparecen el equipo conoce mucho ya sobre ellos y quizás podrá evitarlos, limitarlos o controlarlos. Hay riesgos que no pueden evitarse, en esos casos el equipo debe estar preparado cuando este riesgo aparezca, para lo cual deberíamos contar con un plan de contingencia.


Página 22 de 22

7. Si nosotros contáramos sólo con los flujos de trabajo fundamentales estaríamos en frente de una metodología de ciclo de vida en cascada, recordemos que la gran diferencia entre el PUDS y metodologías estructuradas de ciclo de vida en cascada es el avance iterativo e incremental que se asocia con los flujos de trabajo de iteración. Cada iteración constituye una pasada a través de los cinco flujos de trabajo fundamentales. Las distintas fases reúnen iteraciones que dan como resultado los hitos principales. 8. No, durante la fase de inicio -establece la viabilidad- y elaboración -se centra en la factibilidad- la mayoría del esfuerzo se dedica a la captura de requisitos y a un análisis y diseño preliminares. Durante la construcción -se construye el sistema- el énfasis pasa al diseño detallado, la implementación y la prueba. Y durante la fase de transición nos metemos mucho más dentro del usuario, inicia con la entrega de una versión beta y culmina con la entrega final, al medio tenemos preparación de manuales, corrección de defectos encontrados en las pruebas del beta, preparación del entorno del usuario (hardware, Sistemas operativos, protocolos de comunicaciones, etc.). 9. Al concepto de flujo de trabajo se lo asocia con el concepto de iteración. Es un conjunto de actividades, es una colaboración entre trabajadores que utilizan y producen artefactos. Para describir los flujos se utilizan los diagramas de actividad. En estos diagramas observamos los distintos trabajadores relacionados con el flujo y las actividades que éstos desarrollan. Al ejecutar estas actividades crean y modifican artefactos. Los flujos de trabajo son secuencias de actividades que están ordenadas, una actividad produce una salida que es entrada de otra actividad. En el proceso unificado tenemos flujos de trabajo fundamentales y flujos de trabajo de iteración. Los flujos de trabajo fundamentales nos ayudan a describir los flujos de trabajo de iteración, ya que los de iteración incluyen los cinco flujos de trabajo fundamentales, y además la planificación que precede a los flujos de trabajo y la evaluación que va detrás de ellos. El resultado de una iteración es un incremento.

introduccin al puds(proceso unificado de desarrollo de...

Documents