Conceptos GeneralesDiseno de Sistemas
2014-1
UNMSM-EAPIS
El DiseoLic. David Espinoza.
Concepto General
El diseo se define como el proceso previo de configuracin mental, "pre-figuracin", en la bsqueda de una solucin en cualquier campo. Utilizado habitualmente en el contexto de la industria, ingeniera, arquitectura, comunicacin y otras disciplinas creativas.
Etimolgicamente deriva del trmino italiano disegno dibujo, designio, signare, signado "lo por venir.
lo hecho es la obra, lo por hacer es el proyecto
el acto de disear como prefiguracin es el proceso previo en la bsqueda de una solucin o conjunto de las mismas.
. Plasmar el pensamiento de la solucin o las alternativas mediante esbozos, dibujos, bocetos o esquemas trazados en cualquiera de los soportes, durante o posteriores a un proceso de observacin de alternativas o investigacin
El acto intuitivo de disear podra llamarse creatividad como acto de creacin o innovacin si el objeto no existe o se modifica algo existente inspiracin abstraccin, sntesis, ordenacin y transformacin.
El acto humano de disear no es un hecho artstico en s mismo, aunque puede valerse de los mismos procesos en pensamiento y los mismos medios de expresin como resultado
Al disear un objeto, el diseador ordena y dispone los elementos estructurales y formales, as como dota al producto de significado en su contexto social.
El verbo "disear" se refiere al proceso de creacin y desarrollo para producir un nuevo objeto o medio de comunicacin (objeto, proceso, servicio, conocimiento o entorno) para uso humano.
El sustantivo "diseo" se refiere al plan final o proposicin determinada fruto del proceso de disear: dibujo, proyecto, planoo descripcin tcnica, maqueta al resultado de poner ese plan final en prctica (la imagen, el objeto a fabricar o construir).
Disear requiere principalmente consideraciones funcionales, estticas y simblicas.
El proceso necesita numerosas fases como: observacin, investigacin, anlisis, testado, ajustes, modelados (fsicos o virtuales mediante programas de diseo informticos en dos o tres dimensiones).
Adems abarca varias disciplinas y oficios conexos, dependiendo del objeto a disear y de la participacin en el proceso de una o varias personas.
Disear es una tarea compleja, dinmica e intrincada. Es la integracin de requisitos tcnicos, sociales y econmicos, necesidades biolgicas, ergonoma con efectos psicolgicos y materiales, forma, color, volumen y espacio, todo ello pensado e interrelacionado con el medio ambiente que rodea a la humanidad
ARTE u OFICIO
Durante dcadas los asuntos del Diseo se debaten entre investigadores y expertos.
El diseo guarda relacin con la actividad artstica en la medida que emplea un lenguaje similar, pero es un fenmeno de naturaleza ms compleja y enteramente vinculado a la actividad productiva y al comercio.
Como subrayaba Renato de Fusco, (Arquitecto catedrtico de Historia de la Arquitectura de la U. de Npoles)a diferencia del arte y la arquitectura donde el protagonista son los artefactos, el proceso histrico del diseo no se basa slo en los proyectistas, porque al menos un peso similar tienen los productores, los vendedores y el mismo pblico.
Se suele confundir con frecuencia a los diseadores y a los artistas, aunque nicamente tienen en comn la creatividad.
El diseador proyecta el diseo en funcin de un encargo, y ha de pensar tanto en el cliente como en el usuario final, justificando sus propuestas. A diferencia del artista que es ms espontneo y sus acciones pueden no estar justificadas.
El diseador
Quien disea, acta y proyecta objetos funcionales, herramientas ergonmicas, mobiliario, accesorios tiles, vestimenta, espacios fsicos o virtuales webs, multimedia, informacin, seales, mensajes no verbales sgnicos, simblicos y sistemas, ordena elementos grficos e imgenes, clasifica tipologas, crea o modifica tipografas.
Su campo de actuacin tiene relacin con la industria, el comercio y todas las actividades culturales.
su perfil y educacin puede tener orientacin tcnica en la ingeniera de procesos industriales o constructivos (arquitectura de interiores).
DEFINICIONES.
Las definiciones sobre diseo son tantas y tan variadas como las actividades que han dado pie a esta actividad.
Toms Maldonado sealaba que el diseo industrial es una actividad proyectual que consiste en determinar las prioridades formales de los objetos producidos industrialmente
Diseo es un proceso de adecuacin formal, a veces no consciente, de los objetos.
Segn Joseph Edward Shigley y Charles R. Mishke, en su obra Diseo en ingeniera mecnica(Mechanical Engineering Design), publicada en 1989, "diseo es formular un plan para satisfacer una necesidad humana".
Para el arquitecto Damiano Franco, el diseo se encuentra hasta en la parte ms nfima de la vida del ser humano. Qu sera de la vida cotidiana sin un diseo apropiado para cada una de las cosas y objetos? Un caos.
A lo que refiere Mariano Maddio, disear es proyectar nuevas ideas desde nuestra propia mirada, en donde el diseo al igual que toda obra de arte es captada primeramente por nuestra vista y reflejada en nosotros mismos.
Gui Bonsiepe define al diseo como: "Hacer disponible un objeto para una accin eficaz.
su objetivo est orientado a estructurar y configurar contenidos que permitan ser utilizados para ofrecer satisfacciones a necesidades especficas de los seres humanos.
La banalizacin actual del diseo
Hoy en da se usa el termino Diseo inadecuadamente.
Por ser un termino relativamente nuevo.
Por otra parte la superficialidad y falta de seriedad
con la que se trata el Diseo.
Es por ello que muchas veces la falta de informacin lleva al empleo del trmino diseo incorrectamente.
Ejemplos como: mucho diseo y poco contenido son comunes en medios de comunicacin, discursos etc.
Sin embargo, el buen diseo, se caracteriza por su buena usabilidad y no siempre por su originalidad o esttica
el diseo es la organizacin de materiales y procesos de la forma ms productiva, en un sentido econmico, con un equilibrado balance de todos los elementos necesarios para cumplir una funcin.
No es una limpieza de la fachada, o una nueva apariencia externa; ms bien es la esencia de productos e instituciones.
Fases del proceso del diseo
El proceso de disear, suele implicar las siguientes fases:
1. Observar y analizar el medio en el cual se desenvuelve el ser humano, descubriendo alguna necesidad.
2. Evaluar, mediante la organizacin y prioridad de las necesidades identificadas.
3. Planear y proyectar proponiendo un modo de solucionar esta necesidad, por medio de planos y maquetas, tratando de descubrir la posibilidad y viabilidad de la(s) solucin(es).
4. Construir y ejecutar llevando a la vida real la idea inicial, por medio de materiales y procesos productivos
Estos cuatro actos, se van haciendo uno tras otro, y a veces continuamente.
Hoy por hoy, y debido al mejoramiento del trabajo del diseador (gracias a mejores procesos de produccin y recursos informticos), podemos destacar otro acto fundamental en el proceso:
Disear como acto cultural implica conocer criterios de diseo como presentacin, produccin, significacin, socializacin, costos, mercadeo, entre otros.
Analisis y Diseno OO
Anlisis y Diseo Orientado a Objetos
Hubo una ola de mtodos de Anlisis y Diseo Orientado a Objetos (A&D OO) a finales de los 80s, principios de los 90La mayora de estos mtodos consistan en un lenguaje de modelamiento grfico y un proceso a manera de consejo en que pasos se deban llevar a cabo para realizar el desarrollo de sistemas. Ej. Anlisis, diseo e implementacin. En la prctica cuando la gente deca que segua un mtodo, se refera a que usaban una notacin. Diferentes procesos son buenos para diferentes clientes y diferentes sistemas. La guerra de mtodos no es necesaria. Es molestoso cuando conceptos similares tienen notaciones diferentes y viceversa. La estandarizacin de la notacin es algo til
Lenguaje Unificado de Modelamiento
El lenguaje unificado de modelamiento (UML) unifica las notaciones de Booch, Rumbaugh (OMT) y Jacobson (OOSE)
Notacin es la representacin grfica de diferentes modelos, es la sintaxis del lenguaje de modelamiento.
El UML es un estndar aprobado por la OMG y es ampliamente aceptado en la industria.
UML es un lenguaje de modelamiento, no un proceso de desarrollo de software; su intencin es ayudar a las diferentes acercamientos para la produccin de software OO.
Para que A&D OO?
El cambio a OO no es fcil, los lenguajes de modelamiento OO ayudan de alguna manera para que el cambio de paradigma sea un poco ms sencillo.
Uno de los grandes retos en el desarrollo es construir el sistema correcto. Los lenguajes de modelamiento OO ayudan a lograr buena comunicacin con los clientes y los expertos en el dominio.
Anlisis Orientado a ObjetosPara construir un modelo de Anlisis Orientado a Objetos, se usan cinco principios bsicos:
1. Se modela el dominio de la informacin
2. Se describe la funcin.
3. Se representa el comportamiento del modelo.
Anlisis Orientado a Objetos
4. Los modelos de datos funcional y de comportamiento se dividen para mostrar ms detalles.
5. Los modelos iniciales representan la esencia del problema mientras que los ltimos aportan detalles de la implementacin.
Anlisis Orientado a Objetos
Para realizar la Ingeniera de Requerimientos se siguen los siguientes pasos:
1. Los requisitos bsicos del usuario deben comunicarse entre el cliente y el ingeniero de software.
2. Identificar las clases (es decir, definir atributos y mtodos).
Anlisis Orientado a Objetos
3. Se debe especificar una jerarqua de clases.
4. Representan las relaciones objeto a objeto
5. Modelar el comportamiento del objeto.
Repetir iterativamente las tareas de la 1 a la 5 hasta completar el modelo.
Anlisis Orientado a Objetos
Los diagramas de clase son muy tiles en esta etapa para encontrar un buen modelo de solucin.
Los diagramas de caso de uso son tiles para definir el entorno en donde se ejecutar la aplicacin.
Diseo Orientados a Objetos
Consiste en representar un modelo de datos que pueda ser fcilmente implantable con algn lenguaje de programacin orientado a objetos.
Los objetos son componentes potencialmente reutilizables, lo que hace que el software sea ms fcil de mantener.
Diseo Orientado a Objeto
El proceso general para el diseo orientado a objetos tiene varias etapas:
1.Comprender y definir el contexto y los modos de utilizacin del sistema.
2.Disear la arquitectura del sistema.
3.Identificar los objetos principales en el sistema.
Diseo Orientado a Objetos
4. Desarrollar los modelos de diseo.
5. Especificar las interfaces de los objetos.
No es un proceso sistematizado al 100%, por lo que necesita refinarse con varias iteraciones.
Diseo Orientado a Objetos
El primer paso consiste en identificar los tipos de relaciones definidos en el sistema, los cuales pueden ser internos y externos. Estas relaciones pueden ser dos:
El contexto del sistema: es un modelo esttico que describe a los otros sistemas en ese entorno.
Diseo Orientado a Objetos El modelo que el sistema utiliza: es un modelo
dinmico que describe cmo interacta el sistema con su entorno.
Con el diseo de contexto se puede crear fcilmente el diseo arquitectnico de la aplicacin.
Diseo Orientado a Objetos
Existen diversas tcnicas para identificar objetos:
Utilizar un anlisis gramatical de la descripcin en lenguaje natural de un sistema.
Utilizar entidades tangibles (cosas).
Utilizar un enfoque de comportamiento.
Utilizar un anlisis basado en escenarios.
Diseo Orientado a Objetos
Existen dos tipos de modelos de diseo para describir un diseo orientado a objetos:
Modelos Estticos.
Modelos Dinmicos.
Diseo Orientado a Objetos
Ejemplos de algunos modelos:
Los modelos de subsistemas
Los modelos de secuencia
Los modelos de mquinas de estado
La encapsulacin de las clases hace que los sistemas evolucionen de forma rpida y sencilla.
Mtodos Orientado a Objetos
Existen diversas metodologas para la realizacin de anlisis y diseo orientado a objetos como:
Mtodo de Booch: abarca un microproceso de desarrollo y un macroproceso de desarrollo.
Mtodo OMT (Rumbaugh)
Objectory (Jacobson)
Mtodo de Coad-Yourdon
Mtodos Orientado a Obejtos
Mtodo UML:
Anlisis: tiene 5 diferentes vistas con diferentes diagramas en cada una de ellas.
1. Vista usuario: representa el sistema (producto) desde la perspectiva del usuario. Se suele utilizar diagramas de casos de uso.
2. Vista estructural: modela los datos y la funcionalidad del sistema; es decir, la estructura esttica (clases, objetos y relaciones).
Mtodos Orientado a Objetos3. Vista del comportamiento: representa los aspectos
dinmicos o de comportamiento del sistema. Tambin muestra las interacciones o colaboraciones entre los diversos elementos estructurales descritos en vistas anteriores.
4. Vista de implementacin Los aspectos estructurales y de comportamiento se representan aqu tal y como van a ser implementados.
5. Vista del entorno: aspectos estructurales de comportamiento en el que el sistema a implementar se representa.
Mtodos Orientado a Objetos
En cuestin de diseo se tienen dos actividades principales:
Diseo de sistema.
Diseo de objetos.
Proceso de Desarrollo de Software
Dominio del problema y de la solucin
Mtodo de Ingeniera
Diseo del sistema
Actividad: Anlisis del problema
Descomposicin en partes
Seleccin de estrategias para disear el sistema
Seleccin del diseo detallado para cada una de las partes
Resultado: Modelo del dominio de la solucin
Bsqueda de soluciones; eleccin de la solucin ms adecuada
Implementacin
Actividad: Trasladar el modelo del dominio de la solucin en representaciones ejecutables
Especificacin de la solucin
Recoleccin y anlisis de requisitos
Actividad: Formulacin del problema con el cliente
Resultado: Modelo del dominio del problema
Formulacin y anlisis del problema
Que queremos decir con proceso de desarrollo?
Deseos, necesidades, Especificaciones,
Software
Qu es un proceso software?
Es un conjunto de actividades y resultados asociados que producen un producto de software.
Es uno de los componentes de un mtodo de desarrollo de software.
Existen 4 actividades fundamentales de proceso, comunes para todos los procesos de software:
Especificacin del software
Desarrollo del software
Validacin del software
Evolucin del software
Qu es un proceso software?. Ciclo de vida
Alternativamente, a veces se usan los trminos :
Ciclo de vida, y
Modelo de ciclo de vida
Sucesin de etapas por las que atraviesa un producto software a lo largo de su existencia (durante su desarrollo y explotacin)
Qu es un proceso software?. Ciclo de vida
Ciclo de vida Ciclo de desarrollo
Desde el anlisis hasta la entrega al usuario
Toda la vida del sistema:
desde la concepcin hasta el fin de uso
Fases Genricas
La Fase de Definicin Qu?La Fase de Desarrollo Cmo?La Fase de Mantenimiento - Cambio
Proceso de Desarrollo de Software
Fases y Actividades Genricas o estructurales
La Fase de Definicin Qu? Anlisis Planificacin
La Fase de Desarrollo Cmo? Diseo Codificacin Pruebas
La Fase de Mantenimiento Cambio Preventivo Correctivo Adaptativo Perfectivo
Proceso de Desarrollo de Software
El Proceso Visin Genrica
Ing. Sistemas Planificacin Anlisis de req.
Diseo G. de Cdigo Prueba
Definicin(QUE)
Desarrollo(COMO)
Soporte(CAMBIOS)
Mant. Correctivo Mant. Adaptativo Mant. Perfectivo Mant. Preventivo o
Reingeniera del Software
Qu es un Modelo de Proceso de Software?
Es una estrategia de desarrollo que los
ingenieros de software deben emplear
para resolver problemas de la industria de
software
Modelo de Proceso de Software
DEFINICION:
54
Modelos de Procesos de Software
Lineal Secuencial
Construccin de
Prototipos
DRA
Incremental
Espiral
Desarrollo
Concurrente
Ensamblaje de Componentes
RUP
XP
SCRUM
Modelos de Procesos de Software
El problema es seleccionar
el modelo de proceso de
software apropiado que
debe aplicar el equipo de
proyecto
?
56
57
Modelo Lineal Secuencial
Ciclo de vida clsico, modelo en cascada + antiguo, + usado Enfoque sistemtico secuencial Dirigido por documentos
Anlisis
Diseo
Codif.Prueba
Mant.
Ing. Sist.
Investigacinpreliminar
DeterminacinDe
requerimientos
DesarrolloDel sistemaprototipo
Diseo delsistema
Prueba delsistema
Puesta enmarcha
Modelo Lineal Secuencial
Crticas:
Proyectos reales raras veces se ajustan.
Raras veces cliente expone todos los req. de entrada.
Producto operativo al final => Paciencia (cliente) alta.
Ventajas
Fcil administrar, comprender
Todos lo conocen
Consejo: Cundo usar?Usar cuando todos los requerimientos han sido establecidos claramente de entrada.
60
Modelo de Construccin de Prototipos
No estn claros los reqs. de entrada
Iterativo. Hasta cuando se itera?
Working prototype, desechar y
empezar con desarrollo de sistema.
Establecer
objetivos
prototipo
Evaluar
prototipo
Desarrollar
prototipo
Definir
funcionalidad
prototipo
Plan
prototipo
Reporte
eveluacin
Prototipo
ejecutable
Definicin
prototipo
Proceso Genrico del Prototipeo
61
Modelo de Construccin de PrototiposCrticas:
Cliente cree que es el sistema.
Peligro de familiarizacin con malas elecciones iniciales (quick and dirty).
Difcil administrar: se necesita mucha experiencia
Costo
Ventajas Se detectan malos entendidos entre los desarrolladores y los usuarios
Se detectan servicios no detectados antes
Dificultades de uso o servicios confusos pueden ser identificados y refinados
Staff de desarrollo de software puede encontrar requerimientos incompletos o inconsistentes con el desarrollo del prototipo
El prototipo sirve como una base de la especificacin para la produccin de un sistema de calidad
Consejo:Cundo usar? Usar cuando inicialmente no estn claros los requerimientos.
Definir claramente de entrada las reglas de juego con el cliente.
No ceder a presin del cliente.
62
Modelo Prototipo Evolutivo
Bosquejo de la Descripcin
EspecificacinVersin Inicial
Versiones IntermediasDesarrollo
Validacin Versin Final
63
Modelo Prototipo Evolutivo
Ventajas Desarrollo rpido cuando no se conocen bien los requerimientos.
Cuando el usuario/desarrollador no sabe bien lo que quiere: acierta/falla.
Adecuado para sistemas pequeos y de vida corta.
Desventajas Requiere tcnicas y herramientas especiales, para un desarrollo rpido.
Los cambios continuos tienden a corromper la estructura del sistema haciendo el mantenimiento futuro muy difcil.
Es imprescindible la pericia de un experto en prototipeo en el equipo de desarrollo.
La organizacin debe estar consciente que el tiempo de vida de los sistemas desarrollados as es corto.
Cundo usar? Es recomendable usar para sistemas pequeos o de vida corta. Cuando es difcil
conocer bien los requerimientos.
64
Modelo de Desarrollo Rpido de Aplicaciones (DRA)
Lineal secuencial con ciclo extremadamente corto.
Candidatos: sistemas que se pueden modularizar =>
equipos de desarrollo paralelos.
Basado en el uso de componentes y T4G.
Equipo # 1
Modelo de
Negocio
Modelo de
Datos
Modelo de
Proceso
Generacin
de
Aplicacin
Prueba y
Entrega
Equipo # 2
Modelo de
Negocio
Modelo de
Datos
Modelo de
Proceso
Generacin
de Aplic.
Prueba y
Entrega
Equipo # n
Modelo de
Negocio
Modelo de
Datos
Modelo de
Proceso
Generacin
de Aplic.
Prueba y
Entrega
Tiempo
Qu informacin?Quin la genera?A dnde va?
Descripciones de procesos de
negocio para ABM de objetos de MD
T4G + Reusabilidad de
Componentes
Prueba de Comp. Nuevos e interfaces.
Identificacin de
Objetos y relaciones
Modelo DRA
65
66
Modelo DRA
Crticas:
Proyectos grandes => gran nro. de personas.
Alto compromiso en tiempo.
No apto para todo tipo de sistema (ej. no modularizable, bajo reuso de componentes).
Desaconsejable cuando existen riesgos tecnolgicos altos o alta interoperatividad con programas ya existentes.
67
Modelos Evolutivos
Se adaptan ms fcilmente a los cambios introducidos a lo largo del desarrollo.
Iterativos En cada iteracin se obtienen versiones ms completas del
SW. Modelos Evolutivos:
Modelo Incremental (*) Modelo en Espiral (*) Modelo de Desarrollo Basado en Componentes (*) Modelo WINWIN Modelo de Desarrollo Concurrente
68
Modelo Incremental
Iteracin de Lineal Secuencial.
Cada iteracin devuelve un Incremento o versin operativa.
til cuando no se est seguro de cumplir con plazos de tiempo o se tiene una fecha imposible de cambiar.
Modelo Incremental
Anlisi
s
Diseo PruebaCodif.Entrega 1er
IncrementoInc1
Anlisi
s
Diseo PruebaCodif. Entrega 2do
Incremento
Inc2
Anlisi
s
Diseo PruebaCodif.Entrega 3er
IncrementoInc3
Tiempo
Modelo Incremental
Establecer
entregas del
sistema Especificar
incremento del
sistema
Costruir
incremento del
sistema
Validacin
incremento
Entrega sistema
completo
Integracin del
Incremento
Sistema
completo?
no
Validacin del
Sistemasi
70
71
Modelo Incremental
Ventajas:
Ofrece retroalimentacin
Disminuye progresivamente el nmero de errores en las partes que faltan
Disminuye el riesgo del desarrollo, errores se corrigen progresivamente
Disminuye el tiempo de entrenamiento al usuario, que es progresivo
El usuario no tiene que esperar hasta el final para hacer uso del sistema
Problemas:
Definicin del contrato, porque se planifica en forma detallada por incremento
Los planes y documentacin se entregan con cada incremento del sistema
Una vez que una parte es entregada sus interfaces son congeladas e incrementos posteriores deben adaptarse a estas
Nota: Una evolucin de este enfoque se conoce como Programacin Extrema(XP-Extreme Programming).
72
Modelo en Espiral
73
Modelo en Espiral Ventajas:
til para proyectos grandes.
Permite usar el prototipado en todas las etapas de la evolucin para reducir el riesgo.
Mantiene el enfoque sistemtico de los pasos sugeridos por el lineal secuencial, pero lo incorpora dentro de un marco iterativo ms real.
Crticas:
Difcil de convencer a los clientes de que es controlable.
Requiere mucha habilidad para el anlisis de riesgos y de esta habilidad depende su xito.
No ha sido utilizado tanto como el lineal secuencial o el de prototipos.
Se necesita mucha experiencia
74
Desarrollo Basado en Componentes
Basado en modelo en Espiral (evolutivo e iterativo) + Tecnologas de Objetos.
Enfatiza la Reusabilidad.
Planificacin Anlisis de Riesgos
Ingeniera,
Construccin y
Entrega
Evaluacin
del Cliente
Comunicacin
con el Cliente
Ident. Comps. candidatos
Buscar Comps. en biblioteca
Construir Extraer
Colocar en
biblioteca
Construir iteracin
VF
Modelo de Mtodos Formales
Usan notacin rigurosa.
Buen nivel de manejo de Lgica y Algebra.
Ventajas Demostraciones formales de propiedades.
Especificaciones sin ambigedades: Consistencia
Utiles para sistemas crticos.
Crticas Dificulta validacin con cliente => combinacin con otras tcnicas semi-
formales.
La ejecucin de este tipo de modelos requiere mucho tiempo y esfuerzo.
Pocos desarrolladores dominan de algebra y matemicas para especificacin.
Tcnicas de Cuarta Generacin (T4G)
Herramientas que facilitan la realizacin de especificaciones a alto nivel -> cdigo fuente.
Basadas en Lenguajes de 4ta Generacin (L4G) y uso de herramientas CASE
Ventajas: Reduccin en tiempo de desarrollo.
Generador de
PantallasPlanillas de Clculo
Generador de
Informes
Sistema de Administracin de Base de Datos
Un entorno de desarrollo de
software basado en Tcnicas de 4ta
Generacin
Generador de
CdigoLenguage de
consulta a BD
77
Tcnicas de Cuarta Generacin (T4G)
Crticas:
Cdigo ineficiente.
No mas fciles de usar que L3G.
Mantenimiento cuestionable.
Consejo:
En sistemas grandes, aunque se usen T4G se debe
hacer anlisis, diseo y pruebas.
LAS METODOLOGIAS AGILES
79
En marzo de 2001, 17 crticos de estos modelos, convocados por Kent Beck, que acababa de definir una nueva metodologa denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre los modelos de desarrollo de software.
En la reunin se acu el trmino Mtodos giles para definir a aquellos que estaban surgiendo como alternativa a las metodologas formales, (CMM-SW, PMI, SPICE) a las que consideraban excesivamente pesadas y rgidas por su carcter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo.
Los integrantes de la reunin resumieron en cuatro postulados lo que ha quedado denominado como Manifiesto gil, que compendia el espritu en el que se basan estos mtodos.
Aunque como se ver ms adelante, en la actualidad hay aproximaciones que combinan lo mejor de ambos enfoques (formal y gil), hasta 2010, en cada lado sus defensores adoptaron posturas radicales, quiz ms ocupadas en descalificar a la contraria que en estudiarla y conocerla para mejorar la propia.
Origen de los mtodos giles
Manifiesto gil (2001)
80
Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interaccin
de los procesos y las herramientas
por encima
El software que funciona de la documentacin exhaustiva
por encima
La colaboracin con el cliente la negociacin contractualpor encima
La respuesta al cambio seguimiento de un planpor encima
Aunque hay valor en los elementos de la derecha, valoramos ms los de la izquierda
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
http://agilemanifesto.org/
Manifiesto gil (2001)
81
1959
MIL-Q 9858
1979
BS 5750
1987
ISO 9000
1997
TickIT
1991
ISO 9000-3Adapta
cio
nes
para
soft
w.
1995
ISO 12207
1995
Proy. SPICE
1993
CMM-SW
Modelo
s e
specfic
os
para
soft
ware
.2003-05
ISO 15504
2001
CMMI
Modelos
CMM
TR 15504Modelo
s y
est
ndare
s
de c
alid
ad
Modelos genricos Modelos para software
Trillium
Bootstrap
DSDM
SCRUM
CRYSTAL
XP
ASD
PP
AM
ISD
1995
2000
Manifiesto
gil
Tcnic
as y
mto
dos
gile
s
Mtodos Agiles
5. Procesos primarios
7. Procesos organizacionales
5.1 Adquisicin
5.2 Suministro
5.3
Desarrollo
5.3
Operacin
5.3
Mantenimiento
6.1 Documentacin
6.2 Gestin de la configuracin
6.3 Control de calidad
6.4 Verificacin
6.5 Validacin
6.6 Reuniones
6.7 Auditora
6.8 Resolucin de problemas
7.1 Gestin
7.3 Mejora
7.2 Infraestructura
7.4 Formacin
5. Procesos de soporte Recogen tcnicas, buenas
prcticas contrastadas por profesionales reconocidos.
Cada una tiene sus caractersticas propias y cubre
un rango de reas de procesos
ms o menos amplia:
Tendencia a combinarlas para dar mayor cobertura
en el ciclo de vida
Han surgido de entornos reales de desarrollo de software
Responden mejor a la realidad del software y las
diferencias con produccin
industrial.
Mtodos Agiles
Este es el mtodo que ms popularidad ha alcanzado entre las metodologas giles, y posiblemente sea tambin el ms transgresor de la ortodoxia basada en procesos.
Su creador, Kent Beck fue el alma mater del Manifiesto gil.
Extreme Programming (XP) se irgue sobre la suposicin de que es posible desarrollar software de gran calidad a pesar, o incluso como consecuencia del cambio continuo. Su principal asuncin es que con un poco de planificacin, un poco de codificacin y unas pocas pruebas se puede decidir si se est siguiendo un camino acertado o equivocado, evitando as tener que echar marcha atrs demasiado tarde.
Valores que inspiran XP
FEEDBACK CORAJE COMUNICACINSIMPLICIDAD
Extreme Programming
XP pone en comunicacin directa y continua a clientes y desarrolladores. El cliente se integra en el equipo para establecer prioridades y resolver dudas. De esta forma ve el avance da a da, y es posible ajustar la agenda y las funcionalidades de forma consecuente
Comunicacin
Una metodologa basada en el desarrollo incremental de pequeas partes, con entregas y pruebas frecuentes y continuas, proporciona un flujo de retro-informacin valioso para detectar los problemas o desviaciones.
De esta forma fallos se localizan muy pronto.
La planificacin no puede evitar algunos errores, que slo se evidencian al desarrollar el sistema.
La retro-informacin es la herramienta que permite reajustar la agenda y los planes.
Feedback rpido y continuo
Extreme Programming
La simplicidad consiste en desarrollar slo el sistema que realmente se necesita. Implica resolver en cada momento slo las necesidades actuales.
Con este principio de simplicidad, junto con la comunicacin y el feedback resulta ms fcil conocer las necesidades reales
Simplicidad
El coraje implica saber tomar decisiones difciles. Reparar un error cuando se detecta. Mejorar el cdigo siempre que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora.
Tratar rpidamente con el cliente los desajustes de agendas para decidir qu partes y cundo se van a entregar.
Coraje
Los costes y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al futuro.
Extreme Programming
XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de 12 prcticas que se complementan unas a otras y deben implementarse en un entorno de desarrollo cuya cultura se base en los cuatro valores citados
Las 12 prcticas de XP
PRCTICAS DE CODIFICACIN
1.- Simplicidad de cdigo y de diseo para producir software fcil de modificar.
2.- Reingeniera continua para lograr que el cdigo tenga un diseo ptimo.
3.- Desarrollar estndares de codificacin, para comunicar ideas con claridad a travs del cdigo.
4.- Desarrollar un vocabulario comn, para comunicar las ideas sobre el cdigo con claridad.
PRCTICAS DE DESARROLLO
1.- Adoptar un mtodo de desarrollo basado en las pruebas para asegurar que el cdigo secomporta segn lo esperado.
2.- Programacin por parejas, para incrementar el conocimiento, la experiencia y las ideas.
3.- Asumir la propiedad colectiva del cdigo, para que todo el equipo sea responsable de l.
4.- Integracin continua, para reducir el impacto de la incorporacin de nuevas funcionalidades.
Extreme Programming
Las 12 prcticas de XP
PRCTICAS DE NEGOCIO
1.- Integracin de un representante del cliente en el equipo, para encauzar las cuestiones de negocio del sistema de forma directa, sin retrasos o prdidas por intermediacin.
2.- Adoptar el juego de la planificacin para centrar en la agenda el trabajo ms importante.
3.- Entregas regulares y frecuentes para satisfacer la inversin del cliente.
4.- Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.
Extreme Programming
Scrum define mtodos de gestin y control para complementar la aplicacin de otros mtodos giles como XP que, centrados en prcticas de tipo tcnico, carecen de ellas.
Los principios de Scrum son:
Equipos autogestionados.
Una vez dimensionadas las tareas no es posible agregarles trabajo extra.
Reuniones diarias en las que los miembros del equipo se plantean 3 cuestiones:
Qu has hecho desde la ltima revisin?
Qu obstculos te impiden cumplir la meta?
Qu vas a hacer antes de la prxima reunin?
Iteraciones de desarrollo de frecuencia inferior a un mes, al final de las cuales se presenta el resultado a los externos del equipo de desarrollo, y se realiza una planificacin de la siguiente iteracin, guiada por cliente.
Scrum
Scrum
Familia de mtodos Crystal
La familia de metodologas Crystal ofrece diferentes mtodos para seleccionar el ms apropiado para cada proyecto.
Crystal identifica con colores diferentes cada mtodo, y su eleccin debe ser consecuencia del tamao y criticidad del proyecto, de forma que los de mayor tamao, o aquellos en los que la presencia de errores o desbordamiento de agendas implique consecuencias graves, deben adoptar metodologas ms pesadas.
Los mtodos Crystal no prescriben prcticas concretas
ASD (Adaptative Software Development)
Mtodo que como alternativa a los procedimientos formales, aborda el desarrollo de grandes sistemas con el uso de tcnicas propias de las metodologas giles.
No se trata de una metodologa, sino de la implantacin de una cultura en la empresa, basada en la adaptabilidad.
Otros mtodos agiles
PP (Pragmatic Programming)
Pragmatic Programming es la coleccin de 70 prcticas de programacin, comunes a otros mtodos giles, cuya aplicacin resulta til para solucionar los problemas cotidianos. Surge del libro The Pragmatic Programmer de Dave Thomas y Andres Hunt.
AM (Agile Modeling)
Agile Modeling es la presentacin de un nuevo enfoque para realizar el modelado de sistemas,(diseo) y basado en los principios de los mtodos giles remarca la conveniencia de reducir el volumen de la documentacin. (Amber S. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process)
ISD Internet Speed Development
Surge de las conclusiones del coloquio celebrado en Octubre de 2001, promovido por SEI que reuni a especialistas de las universidades Carneige Mellon, Georgia y Copenhagen.
Sienta bases de gestin para abordar el desarrollo de sistemas de software, de tamao pequeo que requieren tiempos de desarrollo muy rpidos.
FDD (Feature Driven Development)
Prescribe un proceso iterativo de 5 pasos, con iteraciones de dos semanas.
El punto de referencia son las caractersticas que debe reunir el software, y se centra en las fases de diseo e implementacin del sistema
Otros mtodos agiles
MSF es la metodologa empleada por Microsoft para el desarrollo de software.
Hasta su versin 3 (principios de 2005) MSF se defina como un marco de desarrollo flexible para adaptarse a las necesidades de cada proyecto, en oposicin a lo que sera una metodologa prescriptiva; porque parte de la base de que no hay una estructura de procesos ptima para las necesidades de todos los entornos de desarrollo posibles.
El marco MSF se asienta sobre unos Principios Fundamentales que definen la cultura del entorno de desarrollo:
Fomento de la comunicacin abierta.
Trabajo en torno a una visin compartida.
Apoderar a los integrantes del equipo (empowerment)
Establecimiento de responsabilidades claras y compartidas.
Centrar el objetivo en la entrega de valor para el negocio.
Permanecer giles y esperar e cambio.
Invertir en calidad.
Aprender de la experiencia.
MSF: PRINCIPIOS FUNDAMENTALES
Modelos de propiedad Comercial: MSF
Elementos que componen el modelo
Principios fundamentales
Modelos
Disciplinas
Conceptos clave
Prcticas contrastadas
Recomendaciones
Principios bsicos en los que se basa todo el modelo (los 8 de la pg. ant.)
Mapas mentales de organizacin. Hay 2: De equipo y de procesos
reas de trabajo en las que se usan mtodos determinados (Gestin de proyecto, de riesgos y de la mejora del talento)
Ideas que dan soporte a los principios y disciplinas de MSF y se muestrana travs de prcticas especficas contrastadas.
Prcticas que han demostrado su efectividad en proyectos en diferentes condiciones de entornos reales
Prcticas opcionales, sugeridas por el modelo.
Modelos de propiedad Comercial: MSF
94
Relacin entre los componentes del modelo
Este diagrama es un ejemplo para mostrar la interconexin y relacin entre los componentes de Microsoft Solutions Framework
Aprender de las
experiencias
Modelo de procesos
Disposicin al aprendizaje
Hitos de revisin
Uso de facilitadores
externos
Permanecer gil y esperar
el cambio
Gestin de riesgos
Evaluacin continua de
riesgos
Definir y monitorizar disparadores de riesgos
Creacin de una BD de
riesgos
Principio
Fundamental
Modelo o
Disciplina
Concepto
Clave
Prctica
ContrastadaRecomendac.
Est relacionado
En 2005, el desarrollo del nuevo producto de Microsoft Visual Studio 2005 Team System ha ganerado la evolucin de MSF hacia la nueva versin 4.0 con dos lneas paralelas:
Microsoft Solutions Framework (MSF) for Agile Software Development.
Microsoft Solutions Framework (MSF) for CMMI Process Improvement.
Modelos de propiedad Comercial: MSF
Rational Unified Process
Es un proceso de Ingeniera del Software que proporciona una visin disciplinada para la asignacin de tareas y responsabilidades en las organizaciones de desarrollo de software.
RUP es un modelo-producto desarrollado y mantenido por Racional Software, integrado en su conjunto de herramientas de desarrollo, y distribuido por IBM.
RUP integra un conjunto de buenas prcticas para el desarrollo de software en un marco de procesos vlido para un rango amplio de tipos de proyectos y organizaciones.
Desarrollo iterativo.
Gestin de requisitos.
Uso de arquitecturas basadas en componentes.
Uso de tcnicas de modelado visual.
Verificacin continua de la calidad.
Gestin y control de cambios.
RUP: Buenas Prcticas
Modelos de propiedad Comercial: RUP
96
Rational Unified Process: Visin esttica
En su visin esttica, el modelo RUP est compuesto por:
Roles: analista de sistemas, diseador, diseador de pruebas, roles de gestin y roles de administracin.
Actividades: RUP determina el trabajo de cada rol a travs de actividades. Cada actividad del proyecto debe tener un propsito claro, y se asigna a un rol especfico. Las actividades pueden tener duracin de horas o de algunos das; y son elementos base de planificacin y progreso.
Artefactos: Son los elementos de entrada y salida de las actividades. Son productos tangibles del proyecto. Las cosas que el proyecto produce o usa para componer el producto final (modelos, documentos, cdigo, ejecutables)
Disciplinas: son contenedores empleados para organizar las actividades del proceso. RUP comprende 6 disciplinas tcnicas y 3 de soporte.Tcnicas: modelado del negocio, requisitos, anlisis y diseo, implementacin, pruebas y desarrollo.Soprte: gestin de proyecto, gestin de configuracin y cambio, y entorno.
Flujos de trabajo: son el pegamentode los roles, actividades, artefactos y disciplinas, y constituyen la secuencia de actividades que producen resultados visibles.
Modelos de propiedad Comercial: RUP
97
Rational Unified Process: Visin dinmica
En su visin dinmica, la visin de la estructura del ciclo de vida RUP se basa en un desarrollo iterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo.
Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP:
1.- Inicio. Es la fase de la idea, de la visin inicial de producto, su alcance. El esbozo de una arquitectura posible y las primeras estimaciones. Concluye con el hito de objetivo.
2.- Elaboracin. Comprende la planificacin de las actividades y del equipo necesario. La especificacin de las necesidades y el diseo de la arquitectura. Termina con el hito de Arquitectura.
3.- Construccin. Desarrollo del producto hasta que se encuentra disponible para su entrega a los usuarios. Termina con el hito del inicio de la capacidad operativa.
4.- Transicin. Traspaso del producto a los usuarios. Incluye: manufactura, envo, formacin, asistencia y el mantenimiento hasta lograr la satisfaccin de los usuarios. Termina con el hito de entrega del producto.
Modelos de propiedad Comercial: RUP
98
Factor Discriminadores giles Discriminadores formales
Tamao
Dependencia y escalabilidad limitada por el porcentaje alto de conocimiento tcito.
Apropiado para equipos y productos pequeos.
Escalabilidad y conocimiento explcito.
Apropiado para productos y equipos grandes. Duro de mantener en pequeos proyectos.
Criticidad
La simplicidad en la documentacin y el diseo dificulta los planes de pruebas.
No aconsejado para sistemas con niveles de criticidad altos (IEEE 1012)
Rigor de requisitos y diseo adecuados para procesos de pruebas, verificacin y validacin.
Duros de gestionar en proyectos de escasa criticidad
Dinamismo
Re-factorizar desde un diseo bsico hasta el producto final es un mtodo ideal para entornos dinmicos e in-novadores, pero muy caro por el re-trabajo para entornos estables o conocidos
En sistemas estables y conocidos, partir de requisitos completos y diseos detallados permite trazar y seguir un plan completo y hacerlo bien a la primera.
Personal
Los mtodos de trabajo giles requieren una masa crtica de tcnicos con niveles de experiencia medios-altos, capaces de comprender y adaptar los mtodos y las tcnicas empleadas.
Aunque es aconsejable contar con personas expertas en las fases de definicin del proyecto, luego pueden ejecutarse con menor masa crtica de expertos.
CulturaMs apropiado para culturas de empowerment responsabilidad y horquilla de decisin y libertad personal.
Ms apropiado en culturas en las que las personas se sienten seguras con un marco de tareas y responsabilidades bien definido.
Adaptado de Barry Bohem y Richard TurnerBalancing Agility and Discipline
Factores Claves en los Proyectos
99
Enfoque formal o gil?
Personal
Criticidad
Dinamismo
Tamao
Cultura
% Junior % Senior y Master
Prdidas posibles
Nmero de personas
% Modific. Requisitos / mes
% adaptacin a entornos caticos
1
5
10
30
50
10
30
50
70
90
300
100
30
10
3
0
10
20
30
40
35
30
25
20
15