Procesos de desarrollo de software y Proceso Unificado

Procesos de desarrollo de software y Proceso Unificado Marcelo Flores Primera escuela de invierno 2006

Procesos, métodos y metodologías ● Procesos vs. No procesos ● The mythical man month (F. Brooks) ● Procesos de desarrollo de software

Procesos vs. No procesos ● ● Procesos Forma sistemática de desarrollo Se apropia y comparte el conocimiento adquirido Se incorpora la experiencia Es posible afrontar proyectos grandes No procesos Basado en el heroísmo individual Es posible aplicar a proyectos pequeños Sigue el estereotipo de desarrollador ermitaño, que logra realizar hazañas por si solo. Mucha suerte

Procesos vs. No procesos ● Procesos ● Se prepara el siguiente proyecto No procesos No se prepara algún proyecto posterior Confía en la improvisación El 90% de los programadores de este tipo, lucha con problemas que ellos mismos se han creado.

THE MYTHICAL MAN MONTH ● Fred Brooks (premio A. Turing) Dado un proyecto de software que durará un año con 1 desarrollador. No es verdad que añadiendo 11 desarrolladores lo concluyan en 1 mes. Si tuvieran que arar un campo. ¿Que prefieren, dos bueyes o 1024 gallinas? Corolario: es imposible atar 1024 gallinas y que tiren del mismo lado. -S. Cray

Procesos ¿Por dónde comenzar? ● ¿Que hacer para seguir un proceso de desarrollo? Instanciarlo por lo menos una vez de forma completa. El 81% de los desarrolladores jamás han realizado esta labor en forma conciente. ● ¿Cuando seguir un proceso de desarrollo? Es dificil realizar un proceso de cirugía de corazón abierto si no se es especialista del ramo. De la misma forma es difícil construir software de forma responsable sino hay una conciencia profesional. ● ¿Cómo escoger un proceso de desarrollo? Respira el aire, despues decide si esto es benéfico para tu vida. No recuerdo el autor

Actividad ● ¿Que procesos de desarrollo conocen? ● ¿Que procesos de desarrollo han instanciado alguna vez? ● ¿Que componentes creen que tiene un proceso de software? ● ¿Que componentes tiene y cuales carece el proceso de desarrollo de su preferencia?

Más sobre procesos ● Procesos /= Documentación La gente que no hace procesos argumenta que son simple documentación o su resultado es la documentación. ● Procesos /= Manuales La gente que no hace procesos indica que la obtención de los fastidiosamente llamados manuales técnicos u otros, son el único fín de hacer procesos ● Procesos /= Teoría Los más indican que hacer procesos es pura teoría. . . . (huyen de los procesos como los machitos huyen de las cremas humectantes)

Aquel que rechaza el cambio es el arquitecto de la decadencia. La única institución humana que rechaza los cambios, es el cementerio. ● H. Wilson 1967 Los procesos van de acuerdo con la tecnología. ● Una fábrica moderna no fabrica los jabones como los fabricaba la abuela. ● Los procesos van de acuerdo con la magnitud del proyecto. ● Es impensable usar un rodillo compactador de calles si lo que se desea compactar es la corbata.

Las personas son más importantes que cualquier proceso. Buenas personas actuarán mejor que buenas personas sin procesos. ● G. Booch Los procesos van de acuerdo con el tipo de proyecto Un proyecto de sistema internacional de reserva de pasajes no se hace igual que un sistema de captura de correos por internet. (Recordar que los procesos son conjuntos de actividades, tareas, roles, realizadores, dependencias, artefactos, etc) ● Los procesos son realizados por personas. No son de realización trivial. Los productos resultados de los procesos no solo contienen símbolos del lenguaje usado sino también talento.

Actividad ● ¿Que tanto talento contiene un producto de software? Otorgue una valoración de 1 -100, donde: 1 es completamente producto del talento, confundiendose este con el arte. 100 es completamente carente de talento, tal que es posible realizar el mismo producto de software por decreto 1. . . . . 100

. . . continuación Actividad ● ¿Cómo es posible controlar y administrar el talento en los procesos de software? ● El talento es innato, no se enseña ni se aprende, es único y distinto en cada persona. ● Buenas personas con talento llevarán a cabo los procesos, mejor que buenas personas sin talento.

Procesos vistos desde los cielos ● El modelo de cuatro niveles Object management group-http: //www. omg. org M 3 Descripción de la infraestructura de los modelos de procesos M 2 Descripción del modelo que siguen los procesos M 1 M 0 Descripción del proceso Ejecución/observación en el Mundo real

Un ejemplo ● Haciendo una analogía con programación EBNF Un gramática para el lenguaje P Un programa en el lenguaje P Ejecución del programa P

Otro ejemplo ● Haciendo una analogía con Leyes Constitución Política del Estado Una ley sobre descentralización administrativa Procedimientos, roles, artefactos sobre descentralización adm. El prefecto (un rol) “bombombum” ejecuta la licitación (un procedimiento) para la compra de computadoras (artefactos)

SPEM ● Software Process Engineering Metamodel Adivinar en que nivel se encuentra En camino de ser un estándar (OMG) ● Debe ser escrito de alguna forma ● ¿Que tal si usamos un lenguaje estándar y unificado? ¿Tienen una idea de cual puede ser ese lenguaje?

Actividad ● Realizar un diagrama de cuatro niveles para mostrar la vista desde los cielos de aquello relativo a Objeto y su representación ● Notar que el concepto de lenguaje es implícito para cualquier representación

Retorno de los cielos ● Donde actúan los procesos? La línea de abstracción -Abstracto + Abstracto Ideas, Requerimientos Producto de Software Que lindo! Procesos 1 er Intento Bueno no es tan malo! Procesos 2 do Intento

Donde actúan los procesos ● . . . Continuación Ouch! definitivo SI los procesos son como una carretera, estos no son llanos ni rectos, ni siquiera estan asfaltados y habian faltado puentes, con pésimas señales de tránsito y neblina, como sólo en el cerro Siberia puede haber.

Retornamos a los procesos ● Procesos no son determinísticos ● Procesos no son completos ● ● Procesos No son automáticos Experiencia/ práctica como componente fundamental. Procesos necesitan un lenguaje para ser definidos Software necesita un lenguaje para ser desarrollado Solución: La instanciación de los procesos

Consideraciones sobre la línea de abstracción con: ● Método estructurado ● Object Modelling Technique ● The Unified Process ● Model Driven Architecture

Actividad ● Incluya en el diagrama de la línea de abstracción, el lenguaje usado en cada punto donde el proceso tiene un indicador. Producto de Software Ideas, Requerimientos + Abstracto Análisis Caso del método Estructurado Diseño ADF, DFDs, DEP, DTE, Diccionario, Pseudocódigo -Abstracto Implementación SQL, C, Ada, Fox

. . . continuación. Producto de Software Ideas, Requerimientos + Abstracto Análisis Caso OMT Diseño Objeto Sistema Dinámico Objeto -Abstracto Implementación Funcional Diag. Objetos Pseudocodigo, Diag. DTE, DTr. Even, Objetos, SQL, C, C++, Pascal DFD-OO, (ERD), DTE, DTr. Eve Object, Java, etc. Pseudocódigo n

. . . continuación. Producto de Software Diseño Análisis Caso Proceso Unificado Requerimientos Business Modeling + Abstracto -Abstracto Implementación Ideas, Requerimientos WARNING! UML es el lenguaje NO es el proceso!!

● Comentarios ● Preguntas HTTP: //ajayu. memi. umss. edu. bo Fin día 1

De la vida real

De la vida real

The Unified Process ● ● Guiado en casos de uso Mejor trabajo con el cliente Buena visión/división del proyecto Centrado en arquitectura ● Es impensable no considerar la arquitectura de forma seria en los proyectos actuales Iterativo e incremental El 40% de requerimientos aparecen o se descubren, cuando el cliente toma conciencia del producto al verlo! Repetitivo vs. Iterativo

¿Cómo lograr un proceso iterativo e incremental? ● Cada disciplina contiene las siguientes fases: ● Inicio, Elaboración, Construcción, Transición Por que? . La coordinación de las actividades no es trivial, debe haber una administración y un control de cada miniproyecto ● Es el mecanismo para llevar a cabo la coordinación de las iteraciones y los incrementos

Requerimientos ● Un hito en la línea de abstracción ● En este punto aún no se puede hablar de software. . . sólo es el reconocimiento del problema y su representación ● Es importante reconocer que es posible iniciar una arquitectura de acuerdo al nivel de representación

Modelo de requerimientos ● El modelo resultante de esta disciplina, es el modelo de requerimientos ● Crucial para la planificación del desarrollo iterativo e incremental ● Algunas de sus actividades ● Hallar casos de uso y actores ● WARNING: actores y casos de uso ● Describir casos de uso ● Modelar arquitectura ● Detallar casos de uso ● Modelar Interfaces de usuario? ? ?

. . . Y como arma contra el mal tienen aquí los 20 casos de uso ● Use Case ● Una porción del problema ser observado delimitado en un escenario. ● Finito, concreto, instanciable ● Difícil de ser descrito y explicado Para lo cual se usan varias convenciones sintacticas o linguísticas: ● Texto en lenguaje natural ● Texto estructurado ● Diagramas de Actividades

. . Crash!. Perdón, como les decía, aqui tienen los 10 casos de uso ● Nombrados e identificados con un diagrama de casos de uso Sirve para observar de forma resumida los casos de uso Tratar de descubrir relaciones entre los casos de uso Descubrir los actores de la escena WARNING: Los componentes del diagrama de casos de uso sólo son elementos sintácticos para: Nombrar e identificar (darles un nombre) a los casos de uso. No son los casos de uso en sí. (ejemplo del carnet de identidad y la persona)

Casos de uso vs. Casos de Mal uso (OBERTURE) ● WARNING: El que usa el diagrama de casos de uso para describir El menú del producto de software es un #%$·”@sn@Bush/&/

Casos de uso vs. Casos de Mal uso (PART ONE) ● WARNING: Habrá callejón oscuro para el que usa el diagrama de casos de uso para mostrar Flujos de datos y habra regreso por el callejón si el afectado intenta explosionar los casos de uso

Casos de uso vs. Casos de Mal uso(PART TWO) ● WARNING: EL que usa el diagrama de casos de uso para. Flujo de eventos, es un hu. EVO podrido

Casos de Uso vs. Casos de Mal uso (CLOSE) Definitivamente esto es surrealismo!

Más sobre el arte Museo de Madrid 1970, Museo de arte rupestre de Nuena York 1973 Museo de Ciencias de la computación Cochabamba 2006

Actividad ● Observando los diagramas de casos de uso, encuentre una forma sistemática de buscar y hallar las interfaces de usuario necesarias ● ¿Que tipo de interfaces de usuario serán resultantes de esta actividad?

Casos de uso, iteraciones e incrementos ¿Cual la relación? ● Miniproyectos ● Planificación menos ampulosa Actividades y tareas con mayor independencia Artefactos (diagramas, etc) más legibles, menos complicados, menos ampulosos ● Una de las actividades centrales del proceso unificado para esta disciplina es: ● dar prioridad a los casos de uso Adivinanza ¿De que trata esta actividad?

Priorizar casos de uso ● La llave del proceso iterativo e incremental ● Una tarea bastante difícil ● Mayor experiencia dará mejores resultados ● Es una labor NO determinística Basada en múltiples factores No siempre técnicos Algunas técnicas usadas Buscar la más complicada Buscar la más crucial en el negocio Los complementos

● Comentarios ● Preguntas http: //atodonivel. blogspot. com Fin día 2

Arquitectura en Requerimientos ● ● Es simple y minimalista Es basado en aspectos funcionales encontrados en los casos de uso Los componentes arquitecturales son llamados: sistema, subsistema, paquete No se conoce aún lo que contienen estos componentes arquitecturales, pero SI se sabe que es lo que realizarán.

Análisis ● Un hito en la línea de abstracción ● El modelo de análisis ● La disciplina del análisis que lleva a ese hito ● Realización de casos de uso-análisis- Análisis de arquitectura Analisis de objetos/clases Se resuelven los problemas de una forma Ideal mediante la suposición de un universo reducido y conveniente

Actividad ● Como reducir el universo? ? ?

¿Como reducir el Universo? ● Desde la perspectiva del paradigna OO el universo está compuesto de objetos ● Una forma de reducir el universo es sencillamente reducir los objetos ● Cantidad de objetos del universo Tipos de objetos del universo (categorías) En otras palabras, quitar los grados de libertad del diseñador para que se concentre en la solución genérica y no en su detalle.

¿Estabamos en reducir el universo? ● Concentramos la atención en únicamente tres tipos de clases ● Cada tipo de clase tiene una semántica definida asociado a ella Y estos son: ● Boundary ● Control ● Entity

Sólo 3 tipos de objetos!!! ● Escritos en UML Nombre de clase ‹‹Boundary›› Nombre de clase ‹‹Control›› Nombre de clase ‹‹Entity›› Nombre de clase Es bueno conocer que estos tipos de clases se traducen sintácticamente en Estereotipos en UML, lo cual es un mecanismo de extension del lenguaje.

¿Patrones? ● Afortunadamente las categorías de objetos encontradas para el análisis no son al azar ● Son conocidas como: Modelo, Vista, Controlador (ver Design Patterns, E. Gamma et al. ) ● Con el patron MVC podemos obtener capacidades adicionales como: ● Ordenar la aparición de los objetos/clases en los diagramas del análisis ● Dar a los objetos/Clases responsabilidades definidas en el patrón

Cómo iniciar el análisis ● Realización de casos de uso ● Con la priorización determinada que da un orden a los casos de uso, hacer: Para cada caso de uso Instanciar el patrón Recrear las interacciones entre los objetos participantes

Realización de casos de uso -análisis● Trata específicamente con la solución para un caso de uso ● Sintácticamente se debe reflejar estas ideas en algún(nos) diagramas UML ● ¿Cuales definidos por UML serán apropiados? ● ¿Que consideraciones/cuidados hay que tomar con el lenguaje en esta disciplina?

. . . some designers live their brains in the lobby, get settled behind their keyboards and get busy drawing UML diagrams because doing so is a much easier alternative than doing difficult software engineering work. Philippe Kruchten ● La colaboración que realiza un caso de uso, No debe verse como Flujo de datos. ● Es bueno seguir el patron MVC, eso guía a lograr una estructura con componentes de alta cohesión y bajo acoplamiento ● No modelar las Interfaces de usuario cuando se use el estereoptipo boundary

Arquitectura en el Análisis ● Ya no es tan simple, involucra componentes arquitecturales que pueden no estar explícitos en los casos de uso ● ● Service packages Es posible conocer que “cosas” contiene cada componente arquitectural ● Tambien es posible conocer como se relacionan los componentes arquitecturales

Diseño ● Un hito en la línea de abstracción ● Es una instanciación del modelo de análisis ● Se debe resolver muchos problemas: Tecnología Lenguaje Persistencia Seguridad

Diseño ● Se mantiene el concepto de realización de casos de uso ● Claro que la realización se hace a un nivel de abstración menor ● Se deben detallar los objetos de diseño, de los objetos del análisis Realizando una extensión o especialización o instanciación.

El universo es más amplio ● No se trabaja más con objetos de las categorías indicadas en el análisis ● Los tipos de objetos del diseño son dados por la tecnologia, el lenguaje, el tipo de persistencia, etc. ● No debe existir nada relacionado a tecnología perfecta.

Sobre representar el diseño ● El diseño se representa con las mismas herramientas que se representa el análsis. ● Lo que varía es el nivel de abstracción/ el universo de objetos sobre el cual trata Los objetos en el diseñó deben ser posibles El universo de objetos esta dado por los lenguajes que se usarán

Realización de casos de Uso ● También existe el concepto de realización de casos de uso ● En este caso lo que hacen es realizar un caso de uso en una forma menos abstracta ● La entrada para construir el modelo de diseño es el modelo de análisis ● La s actividades de la disciplina de diseño tambien son las mismas que la disciplina del análisis

Recomendaciones ● Todo el trabajo se lo hace con visión de cada caso de uso ● Esto posibilita a No realizar diagramas enormes ni complejos, sino diagramas simples de verificación o validación sin complicaciones ● También hace posible la implementación simple

Tips ● Notar que el diseño de métodos viene de la necesidad de comunicaciñon dada en las colaboraciones

Ma tips

actividad ● Que operaciones deben implementar Venta y Pago

Warning! ● Que de extraño tiene este modelo?

Más Warnings

Y otros Warnings

Design Patterns? ? ● Una forma inteligente de afrontar el diseño ● Reduce el tiempo de diseño de una solución ● Aumenta la confianza en el diseñador ● Existe una librería que recopila la experiencia de muchos desarrolladores ● MVC de hecho es un patrón de diseño que se ha extendido a otros aspectos del desarrollo.

Arquitectura en el diseño ● Los componentes arquitecturales tienen ahora responsabilidades sobre objetos/clases concretas ● Las dependencias entres componentes arquitecturales debe ser refinada e implementada a tráves de interfaces

Mas sobre el diseño ● Las dependencias en el diseño van más allá del software en desarrollo Se toman en cuenta las dependencias con : ● Librerias ● Otros sistemas ● Beans, etc.

Implementación ● La transformación del diseño a un lenguaje “computable” ● La implementación con proceso unificado se lo realiza mediante componentes ● Cada componente implementa sobconjuntos de deficiones de clases/interfaces incluyendo su caracteristicas y comportamiento

componentes

Implementación de interfaces Sistema de Inscripciones registro ● Package Sistema de registro; ● Public interface Inscripciones { ● Public Registrar. Inscripcion(estudiante, plan, asignatura, grupo); }

Arquitectura en la implementación ● Reconocimiento de nodos ● Asignación de paquetes/subsistemas a módulos

Procesos Ágiles ● Extreme programming ● Principios fundamentales El proceso en las personas Centrado en las cualidades personales

Bibliografía ● Successful Software Development, Scott E. Donaldson-Stanley G. Siegel ● The Unified Software Development Process, G. Booch, J. Rumbaugh, I. Jacobson ● The Unified Modeling language-User Guide, G. Booch, J. Rumbaugh, I. Jacobson ● The Unified Modeling language-reference Manual, G. Booch, J. Rumbaugh, I. Jacobson ● The Mythical Man Month, F. P. Brooks ● The Unified Process -Inception Phase, Scott W. Ambler-Larry L. Constantine ● The Unified Process -Elaboration Phase, Scott W. Ambler-Larry L. Constantine ● The Unified Process -Transition and Production Phases, Scott W. Ambler-Larry L. Constantine

. . . Continuación Bibliografía ● UML y patrones, Graig Larman ● Agile Alliance 2001 a. Manifesto for Agile Software development ● Agile Alliance 2001 b. Principles: The Agile Alliance ● Requirements Engineering, R. J. Wieringa ● Análisis Patterns: Reusable Object Models, M. Fowler ● The Rational Unified Process: An Introduction, Philip Kruchten ● A System of Patterns: Pattern-Oriented Software Architecture, F. Buschman, R. Meunier, H. Rohnert, P. Sommerland, M. Stal ● Design Patterns: Elements of reusable Object Oriented Software, E. Gamma, R. Helm, R. Johnson, J. Vlissides ● Software Process Engineering Metamodel-SPEM, Object Management Group. OMG ● Death by UML fever, Alex E. Bell