Procesos de desarrollo de software y Proceso

UnificadoMarcelo 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 para el siguiente proyecto● No procesos

No se prepara para algún proyecto posterior

Confía en la improvisaciónEl 90% de los programadoresde este tipo, lucha con problemas que ellos mismosse 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 /= ManualesLa 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íaLos 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

M3

M2

M1

M0 Ejecución/observación en el Mundo real

Descripción del proceso

Descripción del modeloque siguen los procesos

Descripción de la infraestructura de los modelos de procesos

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 1er Intento

Bueno no es tan malo! Procesos 2do 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 automáticos

● Procesos no son completos 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.

+ Abstracto -AbstractoIdeas,Requerimientos Producto de Software

Análisis Diseño Implementación

ADF, DFDs, Diccionario,

Pseudocódigo

DEP,DTE,Pseudocódigo

SQL,C, Ada,Fox

Caso del método Estructurado

... continuación

.+ Abstracto -AbstractoIdeas,Requerimientos Producto de Software

Análisis Diseño Implementación

Diag. ObjetosDTE, DTrEven,

DFD-OO,Pseudocódigo

SQL,C,C++, Pascal Object, Java, etc.

Caso OMT

ObjetoDinámicoFuncional

Pseudocodigo, Diag. Objetos,

(ERD),DTE,DTrEven

SistemaObjeto

... continuación

.

+ Abstracto -AbstractoIdeas,Requerimientos Producto de Software

Aná

lisis

Dis

eño

Impl

emen

taci

ón

Caso Proceso Unificado

Bus

ines

s M

odel

ing

Req

uerim

ient

os

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 que usa el diagrama de casos de uso paraFlujo de eventos, es un huEVO podrido

Casos de Uso vs. Casos de Mal uso (CLOSE)

Definitivamenteesto es surrealismo!

Más sobre el arteMuseo de Madrid 1970, Museo de arte rupestre Museo de Ciencias de la

de Nuena York 1973 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

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.

‹‹Boundary››

‹‹Control››

‹‹Entity››

Nombre de claseNombre de clase

Nombre de clase Nombre de clase

Nombre de claseNombre de clase

¿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

● Mediante la observación de las relaciones de los objetos.

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

● Package Sistema de registro;

● Public interface Inscripciones {

● Public RegistrarInscripcion(estudiante,plan, asignatura, grupo);}

Sistema de

registroInscripciones

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 2001a. Manifesto for Agile Software development● Agile Alliance 2001b. 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