Está en la página 1de 107

Mtodos de Desarrollo de

Software
(o bien, como desarrollar software sin morir en el intento...)

Universidad de los Andes


Demin Gutierrez
Julio 2011

mtodo?

Mtodos / Metodologas
Mtodo: Es un conjunto de herramientas,
tcnicas y procesos que brindan soporte y
facilitan el logro u obtencin de una meta

Cmo
Construir
un Reactor
Nuclear?

Mtodos / Metodologas
Mtodo: que hacer, a lo largo de todo el ciclo de
vida del software, para construir un producto
bueno, de calidad, dentro del presupuesto y a
tiempo

Cmo
Construir
un Reactor
Nuclear
software?

software

ciclo de vida?
ciclo de desarrollo?

Ciclo de Vida / Ciclo de Desarrollo

Describe la vida de un producto de software desde


su definicin, pasando por su diseo,
implementacin, verificacin, validacin, entrega, y
hasta su operacin y mantenimiento

por qu es
necesario un mtodo
para desarrollar
software?

Ciclo de Vida / Ciclo de Desarrollo

por lo complejo que resulta desarrollar software

Costo del Cambio

Ciclo de Vida / Ciclo de Desarrollo

Requerimientos / Anlisis / Diseo / Implementacin / Pruebas / Produccin


(aunque los mtodos giles pueden cambiar esta visin)
Fuente: Adaptado de Kent Beck / Extreme Programming Explained, Embrace the Change

por el costo del cambio, la naturaleza del software


y otras razones

qu aporta
un mtodo?

Mtodos / Metodologas
Productos,
Subproductos,
Insumos,
Entregable
(definicin)

Actividades
Roles,
Actores

(definicin)

Procesos
Tareas
(Genrico)
(definicin)

Guas,
Herramientas

Buenas
Prcticas

y otros elementos adicionales...


Fuente: Eclipse Process Framework Composer / April 2007 / Peter Haumer / IBM Rational Software

Mtodos / Metodologas
(Herramientas)
Casos de Uso, Plantillas de Documentos, UML:
Diagramas de Clases, de Casos de Uso, de
Actividades, de Secuencia, etctera.
Grafos de navegacin, lenguajes de programacin,
bibliotecas, armazones de aplicacin (frameworks),
entornos integrados de desarrollo (IDEs), armazones
de pruebas, etctera.
Software de gestin, herramientas de gestin,
etctera
y muchas otras...

Mtodos / Metodologas
(Buenas Prcticas)
Su empresa usa control de cdigo fuente? Control de versiones?
Se hacen compilaciones (builds) e integraciones diarias?
Se tiene algn tipo de base de datos de defectos (bugs)?
Arreglan los defectos existentes antes de escribir cdigo nuevo?
Se mantiene un calendario de proyecto actualizado?
Trabajan en base a especificaciones de algn tipo?
Los programadores tienen condiciones adecuadas y tranquilas de
trabajo?
Se utilizan las mejores herramientas que el dinero puede comprar?
Se tienen probadores? Se tienen probadores dedicados slo a las
pruebas?
Los nuevos candidatos a programadores escriben cdigo durante
su entrevista de trabajo?
Se realizan pruebas de usabilidad?

entre otras, y no necesariamente en este orden...


Fuente: Joel on Software / http://www.joelonsoftware.com/articles/fog0000000043.html

proceso?
modelo de proceso?

Mtodos / Metodologas
Qu es el Proceso?
Un proceso define quien est haciendo qu, cundo
y cmo lograr cierta meta.
The three Amigos
Un proceso es "una serie de pasos que involucra
actividades, restricciones y recursos que producen
una salida de algn tipo"
Pfleeger

...

Mtodos / Metodologas
Qu es el Proceso?

Los "procesos de desarrollo de software"


poseen reglas preestablecidas, y deben
ser aplicados en la creacin del software de
mediano y gran porte, ya que en caso
contrario lo ms seguro es que el proyecto o
no logre concluir o termine sin cumplir los
objetivos previstos, y con variedad de fallos
inaceptables (fracasan, en pocas palabras).
Tomado de:http://es.wikipedia.org/wiki/Software

...en realidad, esta definicin se refiere


a un modelo de proceso...

Mtodos / Metodologas
(Diferencia entre Proceso y Modelo de Proceso)
Un modelo de proceso de software es una
representacin abstracta de un proceso de
software.
Sommerville
Modelo de Proceso (lo que debera ocurrir)

P2

P1

...

...
Proceso Real (lo que ocurre)

Pn

Algunas Caractersticas de los Procesos


(Modelos de...)
Claridad: Es fcil de
comprender?

Visibilidad: Puedo Ver lo


que Ocurre en el Proceso?

Fiabilidad: Probabilidad
de Buen Funcionamiento

Robustez: Es Difcil de
Perturbar?

Facilidad de Soporte

Facilidad de
Mantenimiento

Aceptacin: Se vende?
Los Usuarios lo
Consideran Viable?

Rapidez: Permite
Entregar Rpido el
Producto?

Conveniencia: Es el
mtodo conveniente para
lo que vamos a hacer?

Adaptabilidad: Lo puedo
cambiar segn las
necesidades?

Procesos Livianos vs Pesados

Procesos Livianos
(O de peso liviano)
Procesos Pesados
(O de peso pesado)

entregables,
subproductos,
hitos, etc

Mtodos / Metodologas
(Hitos)
Estudio de
Viabilidad

Informe
de
Viabilidad

La definicin y
verificacin de
Hitos es una
forma de darle
visibilidad al
proceso

Perfilar
Requisitos

Definicin
de
Requisitos

Desarrollo de
Prototipos

Especificacin
de Requisitos

Especificacin
de
Requisitos

Prototipos

Informe
de
Evaluacin
de Prototipos

Fuente: Adaptado de EPS Informtica UAM (T3: 18/19)

Mtodos / Metodologas
(Hitos)
Producto intermedio enseable
Se consigue un hito cuando se ha revisado la calidad
de uno o ms productos y se han aceptado
Tras cada hito se debera generar un informe de
progreso del proyecto
Definir Qu, Quin, Cundo y Cmo se va a evaluar
Coincidiendo con el final de una fase (al menos)
Definir los productos correspondientes a cada hito
Fuente EPS Informtica UAM (T3: 18/19)

roles
actores

Mtodos / Metodologas
(Roles)

Los roles sirven para definir


quin hace que (y
probablemente cuando), son una
forma de asignar y definir
responsabilidades a personas,
sin tener que nombrar a las
personas en particular

Mtodos / Metodologas
(Roles)
Un cerdo y un pollo van caminando por la carretera. El pollo le dice al
cerdo:*
-Oye, por qu no abrimos un restaurante?
El cerdo se vuelve y le responde:
-Buena idea, cmo quieres que lo llamemos?
El pollo se lo piensa y propone:
-Por qu no lo llamamos Huevos con jamn.
Rol: Las acciones o actividades asignadas o requeridas de una persona o
grupo (La funcin del maestro, El gobierno debe de...)
Rol: Un personaje o parte escenificada por un actor; El comportamiento
esperado de un individuo en la sociedad. La funcin o posicin de algo.
-No cuentes conmigo -responde el cerdo-. En ese caso, t slo estaras
IMPLICADO, mientras que yo estara realmente COMPROMETIDO.
* Fuente: Tomado de SCRUM

Mtodos / Metodologas
(Roles)

importante
No confundir los roles en los procesos de
desarrollo con los actores o roles del
sistema o con los interesados o
stakeholders
Son dos cosas totalmente distintas!
Ej: Describir al desarrollador como actor
del sistema en el documento de casos de
uso probablemente ser un error en la
mayora de los casos

modelos bsicos
de procesos?
...modelos de procesos muy generales (algunas veces llamados paradigmas de
proceso) ... Esto es, vemos el marco de trabajo del proceso, pero no los detalles de
actividades especficas. Estos modelos generales no son descripciones definitivas
de los procesos del software. Ms bien, son abstracciones de los procesos que se
pueden usar para explicar diferentes enfoques del desarrollo de software...
Ian Sommerville

lo que
algunas veces
pasa
(y no debera)

Ciclo de Vida / Ciclo de Desarrollo


(Lo que usualmente pasa, y no debe pasar)

Anlisis

Diseo

Pruebas

Codificacin

proceso en
cascada

Proceso en Cascada?
Definicin de
Requerimientos

Diseo de Sistema
y de Software
Cliente...

se parece al
proceso de
solucin de
problemas en
ingeniera?

Implementacin
y Pruebas de
Unidades

Se hacen compromisos
en las etapas iniciales
El resultado de cada etapa son
documentos firmados y aprobados
por las partes involucradas
Altos costos, especialmente si se
requieren cambios

Integracin y
Prueba del
Sistema

Que voy a hacer?

Cmo lo voy
a hacer?

Cmo se ve
completo?
Lo hice bien?

Operacin y
Mantenimiento

Modelo en V
Operacin y
Mantenimiento

Valida Requerimientos

Definicin de
Requerimientos

Diseo de
Sistema y de
Software

Pruebas de
Aceptacin

Verifica Diseo

Verifica Diseo

Pruebas de
Sistema

Pruebas de
unidades e
integracin

Diseo de
Programa

Codificacin

Es una variacin del


modelo de cascada que
hace explcito el proceso de
Verificacin (V) en las fases
de anlisis y diseo

Proceso en Cascada?

Definicin de
Requerimientos

Diseo de Sistema
y de Software

Implementacin
y Pruebas de
Unidades

Operacin y
Mantenimiento

Por qu falla
el proceso en
cascada?

Integracin y
Prueba del
Sistema

Lo que sucede
en realidad...

Proceso en Cascada?
Es el modelo ms simple, conocido
El producto / resultado slo se ve al final (para el cliente). Si
existe algn error (diferencia) sto tiene un resultado
catastrfico
Suele ser difcil para el cliente establecer TODOS los
requisitos de manera explicita (y al principio del proceso).
Naturaleza del software: Cambio
Suele ser difcil para el cliente establecer TODA las
arquitectura del software de manera explicita al principio del
proceso.
Se producen estados de bloqueo, en los que algunos
miembros del equipo deben esperar a otros para terminar
tareas dependientes

proceso / modelo
en espiral

Modelo de Riesgos o de Espiral

En general se puede asociar cada giro a una fase del proceso de


desarrollo. Ej. 1er giro: objetivos, alternativas restricciones; 2do
giro: especificacin de requisitos; 3er giro: diseo; 4to giro:
implementacin, etctera.
Fuente; http://es.wikipedia.org/wiki/Espiral_de_Boehm

Modelo de Riesgos o de Espiral

Fuente; http://en.wikipedia.org/wiki/Spiral_model

Modelo de Riesgos o de Espiral

Incluye de forma explcita en cada giro la especificacin de


objetivos, definicin de alternativas y restricciones y
evaluacin de riesgos (verdaderamente importante)
En cada giro se construye un nuevo modelo del sistema.
Hasta los momentos, se considera el mejor modelo para el
desarrollo de sistemas grandes (El ms fiable)
No es aconsejable para sistemas pequeos debido a su alta
complejidad

procesos
iterativos
incrementales

Modelos Incrementales
(Modelo Incremental)

qu es un incremento?
(incrementar algo)
qu es una iteracin?
(iterar)

Modelos Incrementales
(Modelo Incremental)
Incrementos

...
Incremento 1

Incremento 2

Las fases se dividen en


incrementos, en cada incremento
se desarrolla una parte de la
funcionalidad y se validan los
productos resultantes

Incremento 3

Cliente

Incremento N

En general, una vez los


productos de una fase se
consideran listos, estos no se
modifican ms a lo largo de las
siguientes fases

Modelos Incrementales
(Modelo Incremental)
CU

Incremento 1
CU

CU

CU

CU

actor

Incremento 2
Incremento 3
Incremento 4

CU
actor

CU

CU

CU
actor

CU
CU
CU
actor

En general, cada incremento


aade funcionalidad nueva al
sistema, de manera que el
usuario puede ir utilizando
(validando) la funcionalidad antes
de terminar el sistema completo

Modelos Incrementales
(Modelo Incremental)
El sistema se desarrolla como una secuencia de pasos e
iteraciones una vez establecida la arquitectura global
Los usuarios pueden experimentar con los productos
resultantes de cada iteracin, y usualmente el equipo de
desarrollo puede continuar con el trabajo mientras que los
usuarios experimentan con el sistema
En general, la idea es combinar lo mejor de las estrategias
orientadas a prototipos con una buena gestin
En general, luego de que se valida y se termina un
componente, este no se cambia (o se procura no cambiarlo) a
menos que se encuentren errores (Bugs)

Modelos Incrementales
(Modelo Iterativo)
Iteraciones

...
Iteracin 1

Iteracin 2

Iteracin 3

Iteracin N

Cada iteracin refina lo realizado en la iteracin anterior. De


esta forma se produce una dinmica en la que se van mejorando
los productos (entregables) obtenidos en la iteracin anterior.
Eventualmente se realizarn todas las iteraciones planificadas, o
se llegar al nivel de refinamiento deseado

Modelos Incrementales
(Modelo Incremental)

un proceso puede ser


iterativo e incremental?
...
generalmente si

Modelos Incrementales
(Modelo Iterativo)

Cada fase
se repite
cierta
cantidad de
veces

Modelo Iterativo-Incremental
Ojo con los trminos y las confusiones en relacin a la
concepcin de los modelos iterativos, incremetales y evolutivos

Tambin se puede iterar sobre todo el proceso de desarrollo,


aunque esto est mas asociado a los procesos evolutivos que a
los procesos iterativos

Modelos Incrementales
(Modelo Incremental / UP)

Iteraciones para
cada una de las
fases

La visin de UP (Unified
Process)

White Watch,
Iterativo o Incremental?

Modelos Incrementales
(Modelo Incremental)

Excelente artculo de Alistair


Cockburn sobre desarrollo
incremental y desarrollo iterativo:
http://alistair.cockburn.us/Incremental+versus+iterative+development

Bsicamente aclara bastante la confusin


existente entre los dos trminos

Modelos Incrementales
(Modelo Incremental)
Incremental development defined
By incremental development, I specifically mean a
staging and scheduling strategy in which the various parts of the
system are developed at different times or rates, and integrated as
they are completed.
It neither implies, requires nor precludes iterative development
or waterfall development both of those are rework strategies. The
alternative to incremental development is to develop the entire
system with a big bang integration.

Incremental development helps you improve your process. Each


time around the process, you get to change and improve your work
habits.
Alistair Cockburn:
http://alistair.cockburn.us/Incremental+versus+iterative+development

Modelos Incrementales
(Modelo Incremental)
Iterative development defined
By iterative development, I specifically wish to mean a
rework scheduling strategy in which time is set aside to revise and
improve parts of the system.
It does not presuppose incremental development, but works
very well with it. As shown in the figures, the difference is that an
increment may actually ship, whereas an iteration is examined for
modification.

Iterative development helps you improve your product. Each time


around the process you get to change and improve the product itself
(and maybe some of your work habits)
Alistair Cockburn:
http://alistair.cockburn.us/Incremental+versus+iterative+development

procesos evolutivos
y
basados en
prototipos

Modelos Evolutivos
La definicin y especificacin de requerimientos y el desarrollo
de software es un proceso evolutivo que demanda la
experimentacin previa con algn componente (o la totalidad)
del Sistema Programado (Ej. Interfaz U-S, funcin o subsistema)
antes de desarrollar la totalidad del sistema.

qu es evolucionar?

Modelos Evolutivos
Logran su objetivo por medio
del desarrollo de una serie de
prototipos que van
evolucionando a medida que
se tiene realimentacin del
cliente

Bosquejo
Inicial

Especificacin
Diseo

Versin
Inicial

Desarrollo

Versiones
Intermedias

Validacin

Versin
Final

Pretende vencer las


limitaciones del modelo en
cascada debidas a la
deficiente realimentacin
entre sus fases
Fuente; Sommerville / Ingeniera del Software

Modelos Evolutivos

qu es un prototipo?

Modelos Basados en Prototipos

Prototipos Evolutivos
Poner un sistema a disposicin de los usuarios
finales. El proceso comienza con una serie de
requisitos, se desarrollan una serie de prototipos, se
exponen al usuario y se van refinando paso a paso

Prototipos Experimentales
Prototipos Desechables / Exploratorios
Se desarrollan prototipos (que luego se desecharan)
para aclarar aspectos particulares de los
requerimientos del usuario. Este conocimiento se
utilizar para especificar/disear/desarrollar la
aplicacin

Modelos Basados en Prototipos


Esta estrategia suele ser til
y prctica para sistemas
pequeos (<100K LC) y
medianos (<500K LC)

Requisitos
(Versin Inicial)
aunque esto es
muy, muy relativo
tambin

Prototipos
Evolutivo

Un prototipo se puede
ver como una
especificacin de lo que
se desea desarrollar...

Prototipos
Experimental

Sistema

Desarrollo

Prototipos
Ejecutables
+
Especificacin
Definitiva

Modelos Basados en Prototipos


(No desechable)

Necesidades
/ Validacin

Construir
Prototipo del
Sistema

Especificacin
Abstracta

NO

Entregar
el Sistema

SI

Sistema es
Adecuado?

Usar
Prototipo del
Sistema

Integracin del Proceso en Cascada y el


Desarrollo Basado en Prototipos
Anlisis de
Requerimientos

Los Prototipos
tambin se
pueden utilizar
para minimizar o
cuantificar
riesgos...

Diseo de
Sistema
Diseo de
Programa

Codificacin

Pruebas

Desarrollo de
Prototipos

Operacin y
Mantenimiento

Integracin del modelo de prototipos con el modelo de cascada


(Adaptado de Pfleeger, 1998)

Modelos Basados en Prototipos


tiles en sistemas (O aspectos de un sistema) en los que no
es posible inicialmente (o es difcil) desarrollar una
especificacin. Ej: Sistemas de Inteligencia artificial, Interfaces
de Usuario, etctera
Usualmente se basan en tcnicas que permiten obtener
versiones rpidas del sistema, que se pueden poner en
operacin tan rpido como sea posible: Rapid Application
Development (RAD)
Los requisitos no funcionales no se prueban / determinan
adecuadamente en el prototipo (Ej. seguridad, rendimiento, u
otros
Prctica generalmente para sistemas pequeos / medianos
(<100K o <500K lneas de cdigo)

Modelos Basados en Prototipos


El Proceso, la evolucin, el avance, es difcil de medir. No
siempre es fcil responder a la pregunta: Cuanto falta para
terminar el sistema? (El proceso no siempre es visible)
Los cambios continuos pueden provocar la destruccin de la
estructura del sistema
Es posible que no se puedan realizar verificaciones formales,
debido a que es posible que no exista una especificacin
formal y/o documentacin bien definida
Es difcil establecer contratos, una implementacin no tiene
carcter de contrato
Excelentes para mitigar riesgos y hacer una negociacin
justa con el cliente!

...por cierto...

Modelo de Riesgos o de Espiral

Ser el proceso en espiral incremental,


iterativo, evolutivo, etc?

procesos
basados en la
reutilizacin de
componentes

Desarrollo Basado en Reutilizacin


(Componentes)
Almacn/Catlogo de
Componentes Reutilizables

Bosquejar los
Requerimientos
del
Sistema

Buscar
Componentes
Reutilizables
(COTS)
(Ej. Aplicaciones
Listas o Casi
Listas)

Modificar
Requerimientos
Acorde a los
Componentes
Encontrados

Diseo
Arquitectnico

Buscar
Componentes
Reutilizables
(COTS)
(Ej. Libreras,
Frameworks u
otros)

Disear el
Sistema
Utilizando los
Componentes
Reutilizados

Modificar
Componentes
Encontrados

Modificar
Componentes
Encontrados

COTS: Commercial Off the Shelf


Fuente; Sommerville / Ingeniera del Software (Excepto lo rojo)

Desarrollo Basado en Reutilizacin


(Componentes)

El costo del sistema se puede reducir notablemente debido a


la reutilizacin
El sistema se construye uniendo componentes existentes
Se est limitado a los componentes existentes, es necesario
negociar los requerimientos en base a estos, o modificar los
componentes (lo que no siempre es fcil) para lograr
satisfacerlos (o ambas cosas)
Se necesita todo un armazn o un lenguaje para poder unir
los componentes

importancia de
involucrar al
usuario / cliente
en el proceso de
desarrollo

Proceso en Cascada?

Diferencia entre las


expectativas del usuario y los
resultados producidos

el precio que se paga si no se involucra al


usuario en el proceso de desarrollo

Modelos Basados en Prototipos


(Y en general, modelos iterativos)

Diferencia entre las expectativas del usuario y los resultados


producidos
(muchos mtodos giles logran esto tambin involucrando al
cliente lo ms que sea posible)

modelos giles
(XP)
http://www.agile-software-development.com/2007/05/beauty-of-not-doing-agile-development.html

Modelos giles
(XP)
XP (eXtreme Programing): Es una estratgia de
desarrollo de software creada hace aproximadamente
unos diez aos que ha causado un gran revuelo entre el
colectivo de programadores del mundo
Kent Beck, su autor, es un programador que ha
trabajado en mltiples empresas. Actualmente trabaja en
la conocida empresa automovilstica DaimlerChrysler
Con sus teoras ha conseguido el respaldo de gran parte
de la industria del software y el rechazo de otra parte
http://www.extremeprogramming.org

Modelos giles
(XP)

Historia (cuento)
de usuario

GeneracindeFactura
Versin inicial de la
arquitectura

Elusuariointroducelainformacindelcliente.Siel
clienteyaestregistradoconslointroducirlacdulase
Prototipo, prueba
debencargarsusdatos.Luegoseingresanloselementosa
o experimento
rpido pensado facturarylascantidadesdecadaelemento.
para reducir el Finalmenteelsistemaregistralafacturayescapazde
riesgo
imprimirlaenlaimpresoralocalasociadaalterminaldel
usuario

Modelos giles
(XP / Caractersticas)
1) El desarrollo del plan: Determinar rpidamente el alcance
de la siguiente iteracin / entrega en base a las prioridades
del negocio (cliente) y los estimados tcnicos. Estar
dispuestos a cambiar el plan a medida que es necesario.
2) Liberar mucho, en incrementos pequeos: Poner el
sistema en produccin los ms rpido posible (el mnimo
necesario) y desarrollar las siguientes versiones con el ciclo
lo mas corto posible.
3) Diseo simple: Mantener el diseo lo ms simple posible
(KISS: Keep it Simple Stup$%#id), concentrarse en el
presente y no en el futuro
(YAGNI: You ain't going to need it)

Modelos giles
(XP / Caractersticas)
4) Pruebas unitarias continuas: Sirven para evitar que los
programadores se equivoquen, para evitar las parcelas de
cdigo y para validar constantemente la aplicacin. Los
clientes tambin pueden escribir pruebas para validar /
demostrar ciertas caractersticas del sistema.
5) Programacin en parejas: Todo el cdigo a ponerse en
produccin es escrito en parejas. Sabe usted por que?
6) Propiedad colectiva: Nadie es dueo de ninguna clase, de
ningn artefacto, de ninguna parte del cdigo.
7) Integracin continua: Las caractersticas del sistema se
desarrollan y se integran a diario. Luego se corren las
pruebas y se verifica que la aplicacin corra correctamente.

Modelos giles
(XP / Caractersticas)

8) 40 horas a la semana: Nadie. NADIE! Trabaja horas extra.


Sabe usted porque?
9) El cliente involucrado en el ambiente de desarrollo: El
cliente (o un representante) es un miembro ms del equipo
de desarrollo.
10)Estndares de codificacin: Se definen estndares
adecuados de codificacin y se respetan. Sobre todo
aquellos que enfatizan la auto-documentacin y adecuada
documentacin del cdigo.

Modelos giles
(XP / Caractersticas)

Modelos giles
(XP / Valores)
Simplicidad: Es la base de la programacin extrema. La idea es
simplificar el diseo lo ms posible para agilizar el desarrollo y
facilitar el mantenimiento.
Comunicacin: Se realiza de diferentes formas:
1) Para los programadores el cdigo comunica mejor. La simplicidad del
cdigo hace que este sea legible. Es mejor tener cdigo
autodocumentado que cdigo con grandes cantidades de
documentacin, ya que la documentacin corre el riesgo de quedar
desfasada con el cdigo a medida que este es modificado.
2) Las pruebas unitarias comunican, ya que describen el diseo de las
clases y mtodos al mostrar ejemplos concretos de como usar su
funcionalidad.
3) Los programadores se comunican constantemente gracias a la
programacin en parejas.
4) La comunicacin con el cliente es fluida ya que el cliente es parte del
equipo.

Modelos giles
(XP / Valores)
Retroalimentacin (feedback): El cliente est integrado en el
proyecto de modo que su opinin sobre el estado del proyecto se
conoce en tiempo real. Como las iteraciones son muy cortas (2-4
semanas) se minimiza el tener que rehacer partes que no cumplen
con los requisitos y ayuda a los programadores a centrarse en lo
que es ms importante
Respeto: Todo el mundo recibe y siente el respeto que merece
como miembro valioso del equipo de desarrollo. Todos en el equipo
aportan valor, aun si es simple entusiasmo. Los desarrolladores
respetan la experiencia de sus clientes y viceversa. La gerencia
respeta el derecho del equipo de aceptar la responsabilidad y
recibir la autoridad sobre su propio trabajo
Coraje o Valenta: Para los gerentes, muchas de las prcticas de
XP pueden parecer poco intuitivas o inclusive erradas
(programacin en parejas, simplicidad, no pensar en la flexibilidad a
futuro, entre otras). Es necesario mucho coraje para aceptarlas y
vencer este prejuicio

Modelos Incrementales
(Modelo Incremental)

advertencia
La Programacin Extrema (XP) y otros
mtodos no significan desarrollar sin
mtodo
Los mtodos giles requieren en el
fondo mucha disciplina para poder
ejecutarlos y mantener el orden de
forma satisfactoria

modelos giles
(scrum)
http://www.agile-software-development.com/2007/05/beauty-of-not-doing-agile-development.html

Modelos Incrementales
(Modelo Incremental)

advertencia
las siguientes transparencias han sido
tomadas (mutiladas?) de la clase de
scrum que vimos al comienzo del
semestre, lo que viene es un simple
resumen

Modelos giles
(SCRUM / Proceso)
requisitos
features de la
aplicacin

reunin
diaria
resultado
(producto)
(entregas frecuentes)

tareas de
< 16 horas

requisitos para el
sprint (iteracin)

sprints
(iteraciones)
(cortos)

Historias de Usuarios
(SCRUM / Requisitos)
Los requisitos del producto se capturan teniendo en
cuenta la visin del cliente y del usuario
Para ello se utilizan historias de usuario, que son unas
sencillas tarjetas en las que se recoge de forma
esquemtica, sencilla y en un lenguaje claro una
interaccin entre el usuario y el sistema
GeneracindeFactura
Elusuariointroducelainformacindelcliente.Siel
clienteyaestregistradoconslointroducirlacdulase
debencargarsusdatos.Luegoseingresanloselementosa
facturarylascantidadesdecadaelemento.
Finalmenteelsistemaregistralafacturayescapazde
imprimirlaenlaimpresoralocalasociadaalterminaldel
usuario

Historias de Usuarios
(SCRUM / Requisitos)
GeneracindeFactura
Elusuariointroducelainformacindelcliente.Siel
clienteyaestregistradoconslointroducirlacdulase
debencargarsusdatos.Luegoseingresanloselementosa
facturarylascantidadesdecadaelemento.
Finalmenteelsistemaregistralafacturayescapazde
imprimirlaenlaimpresoralocalasociadaalterminaldel
usuario

Las historias de usuario sirven de recordatorio de un


grupo de caractersticas que es necesario implementar
en el sistema.
Antes de implementar una caracterstica se produce una
discusin con el usuario y se refina y extiende la
informacin de la historia de usuario

Modelos giles
(SCRUM / Requisitos)

Los requisitos del product backlog se priorizan y se


asignan a los distintos sprints planificados, es decir,
al sprint backlog de cada sprint

SCRUM
(Roles)

ese cuento ha sido


inmortalizado de
muchas formas

SCRUM
(Roles)

cerdos
(realmente
comprometidos)

pollos
(involucrados)

Modelos giles
(Gestin y Seguimiento / Reunin Diaria)
Reunin Diaria:
Es una figura fundamental en SCRUM.
Tiene que reunirse TODO el equipo y debe hacerse
segn ciertas reglas

Modelos giles
(Gestin y Seguimiento / Scrum Burn Down)

EJE Y
Trabajo restante,
horas, puntos de
funcin u otra
unidad de medida
EJE X
Da o fecha del sprint

Esto es responsabilidad
del Scrum Master

Modelos giles
(Gestin y Seguimiento / Task Boards)

http://www.mountaingoatsoftware.com/scrum/task-boards

bien... pero...

qu mtodo o proceso de desarrollo


de software debo utilizar?

Qu Mtodo o Proceso de desarrollo de


software debo utilizar?

Recuerde que no todos los proyectos y tipos de aplicaciones a


desarrollar son iguales. Use el mtodo que ms se adapte a
sus necesidades o al proyecto a enfrentar: No existen
mtodos perfectos o soluciones universales...
Evite caer en el fanatismo de mtodos: XP fans vs RUP fans
vs Scrum fans etc... (de hecho, evite caer en cualquier tipo de
fanatismo)
Si ya ha usado un mtodo anteriormente en proyectos
similares a los que debe desarrollar y ha tenido resultados
adecuados entonces vuelva a utilizar ese mtodo...

Qu Mtodo o Proceso de desarrollo de


software debo utilizar?
En proyectos pequeos / medianos los mtodos giles
pueden ser adecuados
En grandes aplicaciones empresariales el proceso unificado
puede generar los resultados adecuados
En proyectos con mucho personal los mtodos giles pueden
no ser el enfoque adecuado
Recuerde que en el fondo el mtodo NO es lo importante, el
mtodo no es el fin. El mtodo es slo una herramienta para
lograr el verdadero objetivo: terminar el proyecto a tiempo,
dentro del presupuesto y con las caractersticas requeridas.
Mantenga siempre la mira y la concentracin en el
producto, que es el verdadero objetivo!

cmo se describe
un mtodo
o proceso?
hay muchas formas, pero...

Mtodos / Metodologas
(Descripcin de Procesos)

Proceso
Tcnico 1

Proceso
Tcnico 2

...

Proceso
Tcnico N

Procesos
fundamentales
del desarrollo
de software

Proceso de gestin o de soporte 1

Proceso de gestin o de soporte 2

...

Procesos de
apoyo al
desarrollo de
software

Proceso de gestin o de soporte M

Fuente: GRAY WATCH MTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES


EMPRESARIALES / Noviembre 2008

Mtodos / Metodologas
(Descripcin de Procesos)
Grupo de
Procesos

Proceso A

...

...

Subproceso
A.1

Proceso B

...

...

Subproceso
A.n

Proceso C

...

Fuente: Adaptado de GRAY WATCH MTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES


EMPRESARIALES / Noviembre 2008

Mtodos / Metodologas
(Descripcin de Procesos)
<<regla>>

<<actor>>

<<objetivo>>

Reglas del
Negocio

Coordinador
del Proceso

Objetivo del
Proceso

<<regula>>

<<controla>>

<<persigue>>

<<recurso>>

Insumo o
Material
Requerido

<<producto>>

Salida

...

...

Proceso X

Informacin
Producida

<<producto>>

Entrada
<<ejecuta>>
<<recurso>>

Grupo o
Actor

<<apoya>>

Informacin
Requerida

<<apoya>>
<<repositorio>>

Datos

Fuente: Adaptado de GRAY WATCH MTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES


EMPRESARIALES / Noviembre 2008

Mtodos / Metodologas
(Descripcin de Procesos)
<<proceso>>
Planificacin de Alcance

<<documento>>
Documento de
Inicio del
Proyecto

Planificar la
Gestin del
Alcance del
Proyecto

Definir el
Alcance del
Proyecto

Crear la
Estructura
de
Desglose
de Trabajo

<<documento>>
Plan Integral del
Proyecto
Actualizado

Actualizar el
Plan del
Proyecto

<<documento>>
Enunciado del
Alcance del
Proyecto
<<documento>>
Plan de Gestin
de Alcance

<<documento>>
Estructura de
Desglose de
Trabajo

Fuente: Adaptado de GRAY WATCH MTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES


EMPRESARIALES / Noviembre 2008

Mtodos / Metodologas
(Descripcin de Procesos)

Los modelos de
Productos describen
todos los productos
que se utilizan o se
producen en el mtodo

Fuente: Adaptado de GRAY WATCH MTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES


EMPRESARIALES / Noviembre 2008

Mtodos / Metodologas
(Descripcin de Procesos)

El modelo de actores especifica


los actores / roles que participan
en el proceso de desarrollo y sus
respectivas responsabilidades
Fuente: Adaptado de GRAY WATCH MTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES
EMPRESARIALES / Noviembre 2008

algunos mtodos
de desarrollo?

Algunos Mtodos de Desarrollo

Extreme Programming (XP)


http://www.extremeprogramming.org/

Scrum
http://www.scrumalliance.org/

Algunos Mtodos de Desarrollo

RUP (IBM Rational Unified Process)


http://www-01.ibm.com/software/awdtools/rup/

OpenUP (Open Unified Process)


(Muy Buena Referencia)
http://epf.eclipse.org/wikis/openup/

AgileUP (Agile Unified Process)


http://www.ambysoft.com/unifiedprocess/agileUP.html

otros...

Algunos Mtodos de Desarrollo

Gray Watch
White Watch
(desarrollados aqu en la ULA)

Reflexin Final

reflexin final
Pase lo que pase, siempre procure
que el mtodo de desarrollo que use
trabaje a su favor. Si el mtodo que
est usando trabaja en su contra
entonces cambie el mtodo!
Recuerde, el mtodo no es importante,
lo importante es el cliente, el producto
y las personas involucradas en su
desarrollo

Gracias

Gracias!

También podría gustarte