Está en la página 1de 99

Conceptos Generales

Diseo de Sistemas
UNMSM-EAPIS

El Diseo
Lic. 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, plano
o 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 90
La 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 Objetos


Para 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 Objetos


3. 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
Recoleccin y anlisis
de requisitos

Actividad: Anlisis del problema

Actividad: Formulacin del


problema con el cliente

Seleccin de estrategias para


disear el sistema

Resultado: Modelo del


dominio del problema

Formulacin y anlisis
del problema

Descomposicin en partes

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

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

Proceso de Desarrollo de Software


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

El Proceso Visin Genrica


Ing. Sistemas
Planificacin
Anlisis de req.

Definicin
(QUE)

Diseo
G. de Cdigo
Prueba

Desarrollo
(COMO)

Mant. Correctivo
Soporte
Mant. Adaptativo (CAMBIOS)
Mant. Perfectivo
Mant. Preventivo o
Reingeniera del Software

Modelo de Proceso de Software


DEFINICION:
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
54

Modelos de Procesos de Software


SCRUM

RUP
Lineal Secuencial
DRA

Construccin de
Prototipos
Incremental

Espiral

XP
Desarrollo
Concurrente
Ensamblaje de Componentes

Modelos de Procesos de Software

El problema es seleccionar
el modelo de proceso de
software apropiado que
debe aplicar el equipo de
proyecto

?
56

Modelo Lineal Secuencial

Ciclo de vida clsico, modelo en cascada


+ antiguo, + usado
Enfoque sistemtico secuencial
Dirigido por documentos

Ing. Sist.
Anlisis
Diseo

Codif.
Prueba

Mant.57

Investigacin
preliminar

Determinacin
De
requerimientos
Desarrollo
Del sistema
prototipo
Diseo del
sistema

Prueba del
sistema

Puesta en
marcha

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.

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

Definir
funcionalidad
prototipo

Desarrollar
prototipo

Evaluar
prototipo

Plan
prototipo

Definicin
prototipo

Prototipo
ejecutable

Reporte
eveluacin

60
Proceso Genrico del Prototipeo

Modelo de Construccin de Prototipos


Crticas:

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.

61

Modelo Prototipo Evolutivo


Versin Inicial
Especificacin

Bosquejo de la
Descripcin

Desarrollo

Validacin

Versiones
Intermedias

Versin Final
62

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.

63

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.

64

Equipo # n

Modelo DRA

Modelo de
Negocio

Equipo # 2

Modelo de
Datos

Modelo de
Negocio

Equipo # 1
Qu informacin?
Quin la genera?
A dnde va?

Modelo de
Negocio

Modelo de
Proceso

Modelo de
Datos

Generacin
de Aplic.

Modelo de
Proceso

Modelo de
Datos

Identificacin de
Objetos y relaciones
Descripciones de procesos de
negocio para ABM de objetos de MD

Prueba y
Entrega

Generacin
de Aplic.

Modelo de
Proceso

Prueba y
Entrega

Generacin
de
Aplicacin

T4G + Reusabilidad de
Componentes
Prueba de Comp. Nuevos e interfaces.

Prueba y
Entrega

65

Tiempo

<-------------------------------60-90 das------------------------>

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.

66

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

67

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.

68

Modelo Incremental
Inc1

Anlisi
s

Inc2

Diseo

Anlisi
s

Inc3

Diseo

Anlisi
s

Codif.

Codif.

Diseo

Prueba

Entrega 1er
Incremento

Prueba

Codif.

Entrega
2do
Incremento

Prueba
Tiempo

Entrega 3er
Incremento

Modelo Incremental

Establecer
entregas del
sistema

Especificar
incremento del
sistema

Costruir
incremento del
sistema

Validacin
incremento

Validacin del
Sistema

Integracin del
Incremento

no
Entrega sistema
completo

si

Sistema
completo?

70

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).

71

Modelo en Espiral

72

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
73

Desarrollo Basado en Componentes


Basado en modelo en Espiral (evolutivo e iterativo) +
Tecnologas de Objetos.
Enfatiza la Reusabilidad.

Planificacin

Anlisis de Riesgos

Comunicacin
con el Cliente

Ident. Comps. candidatos

Buscar Comps. en biblioteca


F
Ingeniera,
Construccin y
Entrega

Evaluacin
del Cliente

Construir

Extraer

Colocar en
biblioteca
Construir iteracin

74

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 semiformales.
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.


Lenguage de
consulta a BD

Generador de
Pantallas

Planillas 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
Cdigo

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.
77

LAS METODOLOGIAS
AGILES

Manifiesto gil (2001)


Origen de los mtodos giles
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.
79

Manifiesto gil (2001)


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
por encima de los procesos y las
interaccin
El software que funciona
por encima herramientas
de la documentacin
La colaboracin con el cliente

por encima

exhaustiva
la negociacin contractual

La respuesta al cambio

por encima

seguimiento de un plan

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/
80

Mtodos Agiles

Tcnicas y mtodos
giles

Adaptaciones
para softw.

Modelos para software


1997

TickIT
1991

ISO 9000-3
Trillium

1959

1979

1987

MIL-Q 9858

BS 5750

ISO 9000

Bootstrap
1995

Modelos especficos
para software.

Modelos y estndares
de calidad

Modelos genricos

ISO 12207
1995

Proy. SPICE
1993

CMM-SW

TR 15504

2003-05

ISO 15504

Modelos
CMM

2001

CMMI

DSDM
SCRUM
CRYSTAL
XP
ASD
PP
ISD
AM

1995

2000
Manifiesto
gil

81

Mtodos Agiles
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

5. Procesos primarios

5. Procesos de soporte

5.1 Adquisicin

6.1 Documentacin

5.2 Suministro

6.2 Gestin de la configuracin

6.3 Control de calidad


5.3
Operacin

6.4 Verificacin

6.5 Validacin

5.3
Desarrollo

6.6 Reuniones
5.3

Han surgido de entornos reales


de desarrollo de software
Responden mejor a la
realidad del software y las
diferencias con produccin
industrial.

Mantenimiento

6.7 Auditora

6.8 Resolucin de problemas

7. Procesos organizacionales
7.1 Gestin

7.2 Infraestructura

7.3 Mejora

7.4 Formacin

Extreme Programming

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


SIMPLICIDAD

FEEDBACK

CORAJE

COMUNICACIN

Extreme Programming
Comunicacin
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

Feedback rpido y continuo


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 retro-informacin es la herramienta que permite reajustar la agenda y los


planes.

La planificacin no puede evitar algunos errores, que slo se evidencian al


desarrollar el sistema.

Extreme Programming
Simplicidad
La simplicidad consiste en desarrollar slo el sistema que realmente se necesita. Implica resolver en
cada momento slo las necesidades actuales.
Los costes y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es
esperar al futuro.
Con este principio de simplicidad, junto con la comunicacin y el feedback resulta ms fcil conocer
las necesidades reales

Coraje
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.

Extreme Programming
Las 12 prcticas de XP
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
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 se
comporta 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.

Scrum
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

Otros mtodos agiles

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

Modelos de propiedad Comercial: MSF


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:

MSF: PRINCIPIOS FUNDAMENTALES

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.

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 muestran
a 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


Relacin entre los componentes del modelo
Este diagrama es un ejemplo para mostrar la interconexin y relacin entre los componentes de
Microsoft Solutions Framework
Principio

Modelo o

Concepto

Prctica

Fundamental

Disciplina

Clave

Contrastada

Aprender de
las
experiencias

Modelo de
procesos

Disposicin al
aprendizaje

Hitos de
revisin

Permanecer
gil y esperar
el cambio

Gestin de
riesgos

Evaluacin
continua de
riesgos

Definir y
monitorizar
disparadores
de riesgos

Recomendac.

Uso de
facilitadores
externos
Creacin de
una BD de
riesgos
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.
94

Modelos de propiedad Comercial: RUP


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.

RUP: Buenas Prcticas

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.

Modelos de propiedad Comercial: RUP


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.

96

Modelos de propiedad Comercial: RUP


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.

97

Factores Claves en los Proyectos


Factor

Tamao

Criticidad

Dinamismo

Personal

Cultura

Discriminadores giles
Dependencia y escalabilidad limitada por
el porcentaje alto de conocimiento tcito.

Apropiado para equipos y productos


pequeos.
La simplicidad en la documentacin y el
diseo dificulta los planes de pruebas.

No aconsejado para sistemas con niveles


de criticidad altos (IEEE 1012)
Re-factorizar desde un diseo bsico
hasta el producto final es un mtodo
ideal para entornos dinmicos e innovadores, pero muy caro por el retrabajo para entornos estables o
conocidos
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.
Ms apropiado para culturas de
empowerment responsabilidad y
horquilla de decisin y libertad personal.

Discriminadores formales
Escalabilidad y conocimiento explcito.
Apropiado para productos y equipos
grandes. Duro de mantener en pequeos
proyectos.
Rigor de requisitos y diseo adecuados
para procesos de pruebas, verificacin y
validacin.
Duros de gestionar en proyectos de
escasa criticidad
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.
Aunque es aconsejable contar con
personas expertas en las fases de
definicin del proyecto, luego pueden
ejecutarse con menor masa crtica de
expertos.
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 Turner
Balancing Agility and Discipline

98

Enfoque formal o gil?

Personal
% Junior

Criticidad
Prdidas posibles

% Senior y Master

40

15

30

20

20

25

10

30

Dinamismo
% Modific. Requisitos / mes
1
5

35

10
30

50

3
10

90

30
70
100

300

Tamao
Nmero de personas

50
30
10

Cultura
% adaptacin a entornos caticos

99