Procesos de desarrollo de

software y Proceso
Unificado
Marcelo Flores

Primera escuela de invierno 2006
Procesos, mtodos y
metodologas
Procesos vs. No procesos

The mythical man month (F. Brooks)

Procesos de desarrollo de software


Procesos vs. No procesos
Procesos
Forma sistemtica de desarrollo
Se apropia y comparte el conocimiento adquirido
Se incorpora la experiencia
Es posible afrontar proyectos grandes
No procesos
Basado en el herosmo individual
Es posible aplicar a proyectos pequeos
Sigue el estereotipo de desarrollador ermitao, que logra
realizar hazaas por si solo.
Mucha suerte
Procesos vs. No procesos
Procesos
Se prepara para el siguiente proyecto
No procesos
No se prepara para algn
proyecto posterior
Confa en la improvisacin
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 ao con 1
desarrollador. No es verdad que aadiendo 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 dnde comenzar?
Que hacer para seguir un proceso de desarrollo?
Instanciarlo por lo menos una vez de forma completa.
El 81% de los desarrolladores jams han realizado esta labor en
forma conciente.
Cuando seguir un proceso de desarrollo?
Es dificil realizar un proceso de ciruga de corazn abierto si no se es
especialista del ramo. De la misma forma es difcil construir software
de forma responsable sino hay una conciencia profesional.
Cmo escoger un proceso de desarrollo?
Respira el aire, despues decide si esto es benfico 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?
Ms sobre procesos
Procesos /= Documentacin
La gente que no hace procesos argumenta que son simple
documentacin o su resultado es la documentacin.
Procesos /= Manuales
La gente que no hace procesos indica que la obtencin de los
fastidiosamente llamados manuales tcnicos u otros, son el nico
fn de hacer procesos
Procesos /= Teora
Los ms indican que hacer procesos es pura teora....... (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 institucin humana que rechaza los
cambios, es el cementerio. H. Wilson 1967

Los procesos van de acuerdo con la tecnologa.
Una fbrica 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 ms importantes que cualquier proceso.
Buenas personas actuarn 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 realizacin trivial.
Los productos resultados de los procesos no solo contienen
smbolos del lenguaje usado sino tambin talento.
Actividad
Que tanto talento contiene un producto de
software?
Otorgue una valoracin 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
.....continuacin Actividad
Cmo es posible controlar y administrar el
talento en los procesos de software?
El talento es innato, no se ensea ni se aprende, es nico
y distinto en cada persona.
Buenas personas con talento llevarn 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
Ejecucin/observacin
en el Mundo real
Descripcin del proceso
Descripcin del modelo
que siguen los procesos
Descripcin de la infraestructura
de los modelos de procesos

Un ejemplo
Haciendo una analoga con programacin
EBNF
Un gramtica para el lenguaje P
Un programa en el lenguaje P
Ejecucin del programa P
Otro ejemplo
Haciendo una analoga con Leyes
Constitucin Poltica del Estado
Una ley sobre descentralizacin administrativa
Procedimientos, roles, artefactos sobre descentralizacin adm.
El prefecto (un rol) bombombum ejecuta la licitacin
(un procedimiento) para la compra de computadoras (artefactos)
SPEM
Software Process Engineering Metamodel
Adivinar en que nivel se encuentra
En camino de ser un estndar (OMG)
Debe ser escrito de alguna forma
Que tal si usamos un lenguaje estndar 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 representacin

Notar que el concepto de lenguaje es implcito para
cualquier representacin
Retorno de los cielos
Donde actan los procesos?
La lnea de abstraccin
+ Abstracto
-Abstracto
Ideas,Requerimientos
Producto de Software
Que lindo! Procesos 1er Intento
Bueno no es tan malo! Procesos 2do Intento
Donde actan los procesos
...Continuacin
Ouch! definitivo
SI los procesos son como una carretera, estos no son llanos ni rectos,
ni siquiera estan asfaltados y habian faltado puentes, con psimas
seales de trnsito y neblina, como slo en el cerro Siberia puede
haber.
Retornamos a los procesos
Procesos no son determinsticos
Procesos No son automticos
Procesos no son completos
Experiencia/ prctica como componente fundamental.
Procesos necesitan un lenguaje para ser definidos
Software necesita un lenguaje para ser
desarrollado
Solucin: La instanciacin de los procesos
Consideraciones sobre la lnea de
abstraccin con:
Mtodo estructurado
Object Modelling Technique
The Unified Process
Model Driven Architecture

Actividad
Incluya en el diagrama de la lnea de abstraccin, el lenguaje
usado en cada punto donde el proceso tiene un indicador.
+ Abstracto -Abstracto
Ideas,Requerimientos Producto de Software
ADF, DFDs,
Diccionario,
Pseudocdigo
DEP,DTE,
Pseudocdigo
SQL,C,
Ada,Fox
Caso del mtodo Estructurado
... continuacin
.
+ Abstracto -Abstracto
Ideas,Requerimientos Producto de Software
Diseo
Implementacin
Diag. Objetos
DTE, DTrEven,
DFD-OO,
Pseudocdigo
SQL,C,C++, Pascal
Object, Java, etc.
Caso OMT
Objeto
Dinmico
Funcional
Pseudocodigo,
Diag. Objetos,
(ERD),DTE,DTrEve
n
Sistema
Objeto
... continuacin
.
+ Abstracto -Abstracto
Ideas,Requerimientos Producto de Software
D
i
s
e

o

Caso Proceso Unificado
B
u
s
i
n
e
s
s

M
o
d
e
l
i
n
g

WARNING!
UML es el lenguaje NO es el proceso!!
Comentarios
Preguntas

HTTP://ajayu.memi.umss.edu.bo

Fin da 1
De la vida real

De la vida real

The Unified Process
Guiado en casos de uso
Mejor trabajo con el cliente
Buena visin/divisin 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

Cmo lograr un proceso iterativo
e incremental?
Cada disciplina contiene las siguientes fases:
Inicio, Elaboracin, Construccin, Transicin
Por que?. La coordinacin de las actividades no
es trivial, debe haber una administracin y un
control de cada miniproyecto
Es el mecanismo para llevar a cabo la
coordinacin de las iteraciones y los incrementos
Requerimientos
Un hito en la lnea de abstraccin

En este punto an no se puede hablar de
software...slo es el reconocimiento del problema
y su representacin

Es importante reconocer que es posible iniciar
una arquitectura de acuerdo al nivel de
representacin
Modelo de requerimientos
El modelo resultante de esta disciplina, es el
modelo de requerimientos
Crucial para la planificacin 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 porcin del problema ser observado
delimitado en un escenario.
Finito, concreto, instanciable
Difcil de ser descrito y explicado
Para lo cual se usan varias convenciones sintacticas
o lingusticas:
Texto en lenguaje natural
Texto estructurado
Diagramas de Actividades
..Crash!.Perdn, como les deca, 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
slo son elementos sintcticos 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 callejn oscuro para el que usa el diagrama de casos de uso
para mostrar Flujos de datos y habra regreso por el callejn 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)
Definitivamente
esto es
surrealismo!
Ms sobre el arte
Museo de Madrid 1970, Museo de arte rupestre Museo de Ciencias de la
de Nuena York 1973 computacin Cochabamba
2006
Actividad
Observando los diagramas de casos de uso, encuentre
una forma sistemtica de buscar y hallar las interfaces de
usuario necesarias

Que tipo de interfaces de usuario sern resultantes de
esta actividad?
Casos de uso, iteraciones e
incrementos Cual la relacin?
Miniproyectos
Planificacin menos ampulosa
Actividades y tareas con mayor independencia
Artefactos (diagramas, etc) ms 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 difcil
Mayor experiencia dar mejores resultados
Es una labor NO determinstica
Basada en mltiples factores No siempre tcnicos
Algunas tcnicas usadas
Buscar la ms complicada
Buscar la ms crucial en el negocio
Los complementos
Comentarios
Preguntas


http://atodonivel.blogspot.com
Fin da 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 an lo que contienen estos
componentes arquitecturales, pero SI se sabe que es
lo que realizarn.
Anlisis
Un hito en la lnea de abstraccin
El modelo de anlisis
La disciplina del anlisis que lleva a ese hito
Realizacin de casos de uso-anlisis-
Anlisis de arquitectura
Analisis de objetos/clases
Se resuelven los problemas de una forma Ideal
mediante la suposicin 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 (categoras)
En otras palabras, quitar los grados de libertad del
diseador para que se concentre en la solucin genrica y
no en su detalle.
Estabamos en reducir el
universo?
Concentramos la atencin en nicamente tres
tipos de clases
Cada tipo de clase tiene una semntica definida
asociado a ella
Y estos son:
Boundary
Control
Entity
Slo 3 tipos de objetos!!!
Escritos en UML




Es bueno conocer que estos tipos de clases se traducen
sintcticamente en Estereotipos en UML, lo cual es un
mecanismo de extension del lenguaje.
Boundary
Control
Entity
Nombre de clase
Nombre de clase
Nombre de clase Nombre de clase
Nombre de clase
Nombre de clase
Patrones?
Afortunadamente las categoras de objetos encontradas
para el anlisis 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 aparicin de los objetos/clases en los diagramas del
anlisis
Dar a los objetos/Clases responsabilidades definidas en el
patrn
Cmo iniciar el anlisis
Realizacin de casos de uso
Con la priorizacin determinada que da un orden a
los casos de uso, hacer:
Para cada caso de uso
Instanciar el patrn
Recrear las interacciones entre los objetos
participantes
Realizacin de casos de uso
-anlisis-
Trata especficamente con la solucin para un caso de uso
Sintcticamente se debe reflejar estas ideas en algn(nos)
diagramas UML
Cuales definidos por UML sern 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 colaboracin que realiza un caso de uso, No debe verse como
Flujo de datos.
Es bueno seguir el patron MVC, eso gua a lograr una estructura
con componentes de alta cohesin y bajo acoplamiento
No modelar las Interfaces de usuario cuando se use el
estereoptipo boundary
Arquitectura en el Anlisis
Ya no es tan simple, involucra componentes
arquitecturales que pueden no estar explcitos 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 observacin de las relaciones de los objetos.
Diseo
Un hito en la lnea de abstraccin
Es una instanciacin del modelo de anlisis
Se debe resolver muchos problemas:
Tecnologa
Lenguaje
Persistencia
Seguridad
Diseo
Se mantiene el concepto de realizacin de casos de
uso
Claro que la realizacin se hace a un nivel de
abstracin menor
Se deben detallar los objetos de diseo, de los
objetos del anlisis
Realizando una extensin o especializacin o instanciacin.
El universo es ms amplio
No se trabaja ms con objetos de las categoras
indicadas en el anlisis
Los tipos de objetos del diseo son dados por la
tecnologia, el lenguaje, el tipo de persistencia, etc.
No debe existir nada relacionado a tecnologa
perfecta.
Sobre representar el diseo
El diseo se representa con las mismas herramientas
que se representa el anlsis.
Lo que vara es el nivel de abstraccin/ 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
usarn
Realizacin de casos de Uso
Tambin existe el concepto de realizacin 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 diseo es el modelo
de anlisis
La s actividades de la disciplina de diseo tambien son las
mismas que la disciplina del anlisis
Recomendaciones
Todo el trabajo se lo hace con visin de cada caso de
uso
Esto posibilita a No realizar diagramas enormes ni
complejos, sino diagramas simples de verificacin o
validacin sin complicaciones
Tambin hace posible la implementacin simple
Tips
Notar que el diseo de mtodos viene de la necesidad de comunicacion
dada en las colaboraciones
Ma tips

actividad
Que operaciones deben implementar Venta y Pago
Warning!
Que de extrao tiene este modelo?
Ms Warnings

Y otros Warnings

Design Patterns??
Una forma inteligente de afrontar el diseo
Reduce el tiempo de diseo de una solucin
Aumenta la confianza en el diseador
Existe una librera que recopila la experiencia de
muchos desarrolladores
MVC de hecho es un patrn de diseo que se ha
extendido a otros aspectos del desarrollo.
Arquitectura en el diseo
Los componentes arquitecturales tienen ahora
responsabilidades sobre objetos/clases concretas
Las dependencias entres componentes
arquitecturales debe ser refinada e implementada
a trves de interfaces
Mas sobre el diseo
Las dependencias en el diseo van ms all del
software en desarrollo
Se toman en cuenta las dependencias con :
Librerias
Otros sistemas
Beans, etc.
Implementacin
La transformacin del diseo a un lenguaje
computable
La implementacin con proceso unificado se lo realiza
mediante componentes
Cada componente implementa sobconjuntos de
deficiones de clases/interfaces incluyendo su
caracteristicas y comportamiento
componentes

Implementacin de interfaces


Package Sistema de registro;
Public interface Inscripciones {
Public RegistrarInscripcion(estudiante,plan, asignatura, grupo);}
Sistema de
registro
Inscripciones
Arquitectura en la implementacin
Reconocimiento de nodos
Asignacin de paquetes/subsistemas a mdulos
Procesos giles
Extreme programming
Principios fundamentales
El proceso en las personas
Centrado en las cualidades personales

Bibliografa
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
... Continuacin Bibliografa
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
Anlisis 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