INTRODUCCIN A INGENIERA

DE SOFTWARE
& MODELOS DE PROCESOS

Mgr. Indira Camacho

Basado en la presentacin de Cibertec

Objetivos
Reconocer el marco de trabajo de la ingeniera de software

(ISW)
Establecer los objetivos de la ISW
Establecer el objeto de estudio de la ISW
Identificar y analizar el producto de ISW
Establecer ventajas y desventajas de los modelos de proceso.
Reconocer a RUP como un modelo importante dentro de ISW.

INGENIERA DE SOFTWARE

Qu es Ingeniera?
Construir una casa para FIDO

Puede hacerlo una sola

persona

Vs.
Construido eficientemente y en un

Requiere:

tiempo razonable por un equipo

Modelado mnimo

Requiere:

Proceso simple
Herramientas
simples

Modelado
(de Patricio Lettelier)

Proceso bien definido

Herramientas ms sofisticadas

Qu es Ingeniera?
APLICACIN de conjunto de
conocimientos y tcnicas cientficas

Qu es software?
Elemento lgico de
la computadora

Qu es Ingeniera de Software?

Definicin:

Es una disciplina tecnolgica - administrativa

dedicada a la produccin sistemtica de
productos de programacin de calidad en
tiempo y presupuesto definido.
Muchas Definiciones:
1.

Es una disciplina o rea de la informtica o ciencia de la computacin, que ofrece

conocimientos, tcnicas y mtodos para desarrollar y mantener software de calidad que
resuelva problemas de todo tipo.

2.

La aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo,

operacin y mantenimiento del software; es decir la aplicacin de la Ingeniera al software.
(Roger Pressman)

3.

La Ingeniera del Software abarca un conjunto de actividades y tcnicas cuyos objetivos

es optimizar al mximo los recursos (tiempo, dinero y persona), el proceso, el producto y la
calidad.

Qu es el Software?

Elemento lgico de la computadora

Producto que construyen y disean los Ingenieros de Software.

Componentes del software

1.
2.
3.
4.
5.

Doc.Especificacin de requerimientos
Documento de diseo
Comprende:
Cdigo
Documentacin
(descripciones,
Manual de usuario
modelos, tablas, etc.)
Manual tcnico
Programas
Datos (texto, nmeros,
imgenes, sonidos,
7
video,etc)
7

Caractersticas del Software

Producto y vehculo.
Lgico, no fsico.
Se desarrolla, no se fabrica.
No se desgasta, se deteriora.
Mayora hecho a medida, tendencia a reusar.

Aplicaciones del Software

SW de Sistemas
SW de Tiempo Real
SW de Negocio o Gestin
SW de Ingeniera o Cientfico
SW Embebido o Empotrado
SW de PC
SW de IA
SW basado en la Web

Mitos del Software

Propagaron confusin e informacin errnea.

Del administrador del proyecto

Mitos del SW

Del usuario final o cliente

Del desarrollador

10

10

Mitos del Administrador

Los estndares y procedimientos son toda la gua

que los Ing. de Software necesitan.

Si contamos con la ltima generacin de

computadoras tenemos todas las herramientas

necesarias.
Si fallamos en la planificacin, podemos aadir

ms programadores y adelantar el tiempo perdido.

La calidad cuesta dinero: es un gasto.
11

11

Mitos del Cliente

Una declaracin general de los objetivos del cliente es todo lo

necesario para empezar a programar.

Los requisitos cambian continuamente, pero los cambios pueden

acomodarse fcilmente porque el software es flexible.

60 100x
C
o
s
t
e

1x

Definicin

1,5 6x

Desarrollo

Despus de

la
Entrega

12

12

Mitos del Desarrollador

Una vez que se escribi el programa y se lo hizo funcionar,

el trabajo del Ing. de Software est terminado.

No hay forma de comprobar la calidad del software hasta

no poder ejecutarlo en alguna mquina.

Lo nico que se entrega al terminar el proyecto es el

programa funcionando.

13

13

Qu es Software de Calidad?

Relacin de la
calidad con el
Software

Definicin oficial (IEEE Std. 610-1990) Es el grado con el

que un sistema, componente o proceso cumple:
Los requisitos especificados.
Las necesidades o expectativas del cliente o usuario.
Concordancia del software producido con los requisitos funcionales y de rendimiento
explcitamente establecidos, con los estndares de desarrollo explcitamente
documentados y con las caractersticas implcitas que se espera de todo software
desarrollado profesionalmente.

Existen dos aspectos que no se deben perder de vista

Matenibilidad
Que sea usado

14

Ingeniera de Software como

Tecnologa Multicapa
HERRAMIENTAS

MTODOS
PROCESO
UN ENFOQUE DE
CALIDAD

15

Ingeniera de Software como

Tecnologa Multicapa
Cualquier enfoque de ingeniera debe
apoyarse
sobre
un
compromiso
de
organizacin de calidad. Que se materializa
en el sistema de calidad de la organizacin
de desarrollo
El fundamento de la ingeniera del software
es la capa de proceso (objeto de estudio de
la IdSW)
16

Ingeniera de Software como

Tecnologa Multicapa
Los mtodos de la ingeniera del software
indican cmo construir tcnicamente el
software.
Las herramientas de la ingeniera del
software
proporcionan
un
enfoque
automtico o semi-automtico para el
proceso y para los mtodos.
17

Objeto de Estudio de
Ingeniera de SW

Proceso de desarrollo
de Software

18

Proceso de Desarrollo de Software

Qu es el PDSW?
Conjunto de etapas con la
intencin de lograr un objetivo:

en tiempo y presupuesto definido

19

Proceso de Software
Otra denominacin del Proceso de Software
Al proceso de software tambin se le
conoce como Ciclo de Vida del Software

20

Proceso de Desarrollo de Software

Fases Genricas

La Fase de Definicin Qu?

La Fase de Desarrollo Cmo?
La Fase de Mantenimiento - Cambio

21

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
22

El Proceso Visin Genrica

Ing. Sistemas
Planificacin
Anlisis de req.

Definicin
(QUE)
Diseo
G. de Cdigo
Prueba

Desarrollo
(COMO)
Mant. Correctivo
Mant. Adaptativo
Mant. Perfectivo

Soporte
(CAMBIOS)

Mant. Preventivo o
Reingeniera del Software
23

El Proceso Visin Genrica

24

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

25

Modelo de proceso & Planificacin

Modelo de proceso
Requerimientos
de
Usuarios

Software

Plan del proyecto

26

Modelos de Procesos de Software

SCRUM
RUP
Lineal Secuencial

Construccin de
Prototipos
Incremental
Espiral

DRA
Desarrollo Concurrente

XP

Ensamblaje de Componentes
27

Modelos de Procesos de Software

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

?
28

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

Investigacin
preliminar

Determinacin
De
requerimientos
Desarrollo
Del sistema
prototipo
Diseo del
sistema

Prueba del
sistema

Puesta en
marcha
30

Modelo Lineal Secuencial

Crticas:

Ventajas

Proyectos reales raras veces se ajustan.

Raras veces cliente expone todos los req. de entrada.
Producto operativo al final => Paciencia (cliente) alta.
Fcil administrar, comprender
Todos lo conocen

Consejo: Cundo usar?

Usar cuando todos los requerimientos han sido establecidos
claramente de entrada.

31

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

Proceso Genrico del Prototipeo

32

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.

33

Modelo Prototipo Evolutivo

Especificaci
n

Bosquejo de la
Descripcin

Desarrollo

Validacin

Versin
Inicial

Versiones
Intermedias

Versin Final
34

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

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.

36

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

Tiempo

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

38

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

39

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.

40

Modelo Incremental
Inc1

Anlisis

Inc2

Anlisi
s
Inc3

Diseo

Diseo

Anlisi
s

Codif.

Codif.

Diseo

Prueba

Entrega 1er
Incremento

Prueba

Codif.

Entrega
2do
Incremento

Prueba

Entrega 3er
Incremento

Tiempo
41

 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?

42

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

43

Modelo en Espiral

44

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

45

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

46

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.

47

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

Generador de
Cdigo

Sistema de Administracin de Base de Datos

Un entorno de desarrollo de software

basado en Tcnicas de 4ta Generacin
48

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.

49

Mtodos Agiles
Manifiesto
Manifiesto gil
gil (2001)
(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 capturaba 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 2005, 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.

50

Mtodos Agiles
Manifiesto
Manifiesto gil
gil (2001)
(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
interaccin
El software que funciona

por encima
por encima

de los procesos y las

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
http://agilemanifesto.org/
Sutherland,
Dave Thomas
51

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)
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 basa 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

RESPETO

52

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)

Definicin:

(De Wikipedia, la enciclopedia libre)

Extreme Programming (XP) es una metodologa liviana para

equipos pequeos encargados de desarrollar software en
proyectos cuyos requerimientos son ambiguos o muy voltiles.
XP propone un proceso de desarrollo liviano, eficiente, de bajo
riesgo, flexible, predecible y cientfico.
Se puede considerar la programacin extrema como la adopcin de las
mejores metodologas de desarrollo de acuerdo a lo que se pretende
llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante
el ciclo de vida del software.
La programacin extrema o eXtreme Programming (XP) es un enfoque de la
ingeniera de software formulado por Kent Beck, autor del primer libro sobre la materia,
Extreme Programming Explained: Embrace Change (1999). Es el ms destacado de los
procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se
diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la
adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios
de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del
desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en
53
cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que
intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)

Principios
1. Simplicidad: simplifica el diseo. Para que sea
mantenible necesario la refactorizacin del cdigo.
simplicidad +autora colectiva del cdigo + la
programacin por parejas
ms grande el proyecto, todo el equipo
conocer ms y mejor el sistema completo.
54

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)

Principios
2. Comunicacin:
Cdigo comunica mejor mientras ms simple.
Cdigo autodocumentado ms fiable que comentarios
Pruebas unitarias muestran ejemplos concretos de como utilizar su
funcionalidad.
Programacin por parejas.
Cliente forma parte del equipo de desarrollo.
El cliente decide qu caractersticas tienen prioridad y siempre debe
estar disponible para solucionar dudas.
55

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)

Principios
3. Retroalimentacin (feedback):
Cliente integrado en el proyecto: su opinin sobre el
estado del proyecto se conoce en tiempo real.
Ciclos que muestran resultados, ayuda a los
programadores a centrarse en lo que es ms importante.
Pruebas unitarias informan sobre el estado de salud del
cdigo.

56

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)

Principios
4. Coraje o Valenta:
Programacin en parejas puede ser difcil de aceptar, parece como
si la productividad se fuese a reducir a la mitad (beneficia en calidad
sin repercutir en productividad)
Coraje para implementar las caractersticas que el cliente quiere
ahora sin caer en la tentacin de un enfoque ms flexible que permita
futuras modificaciones. No se debe emprender el desarrollo de
grandes marcos de trabajo (frameworks) mientras el cliente espera.
La forma de construir marcos de trabajo es mediante la
refactorizacin del cdigo en sucesivas aproximaciones.
57

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)

Principios
5. Respeto:
Aadido en la segunda edicin de Extreme Programming
Explained
Programadores no pueden realizar cambios que hacen
que las pruebas existentes fallen que demore el trabajo
de sus compaeros.
Los miembros respetan su trabajo, buscan alta calidad
en el producto y diseo ms ptimo para la solucin a
travs de la refactorizacin del cdigo.
58

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)

Caractersticas
Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba
antes de la codificacin. Vase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit
orientada a Delphi y NUnit para la plataforma.NET. Estas dos ltimas inspiradas en JUnit.

Programacin en parejas: dos personas en un mismo puesto. Mayor

calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se escribees ms importante que la posible prdida de productividad inmediata. Parejas
se intercambian.
Frecuente integracin del equipo de programacin con el cliente o
usuario. Se recomienda que un representante del cliente trabaje junto al
equipo de desarrollo.
Correccin de todos los errores antes de aadir nueva funcionalidad.
Hacer entregas frecuentes.

59

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)

Caractersticas
Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo
para aumentar su legibilidad y mantenibilidad pero sin modificar su
comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha introducido ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en
el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo
promueve el que todo el personal pueda corregir y extender cualquier parte
del proyecto.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen.
XP apuesta que es ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo
si se requiere, que realizar algo complicado y quizs nunca utilizarlo.

60

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)

Caractersticas (todas)
Desarrollo iterativo e incremental:

pequeas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,

incluyendo pruebas de regresin.

Programacin en parejas
Frecuente integracin del equipo de programacin con el cliente o usuario.
Correccin de todos los errores antes de aadir nueva funcionalidad.

Hacer entregas frecuentes.

Refactorizacin del cdigo

Propiedad del cdigo compartida
Simplicidad en el cdigo:

es la mejor manera de que las cosas funcionen

61

Mtodos Agiles
eXtreme
eXtreme Programming
Programming (XP)
(XP)

Conclusiones
La simplicidad y la comunicacin son
extraordinariamente complementarias.
Con ms comunicacin resulta ms fcil
identificar qu se debe y qu no se debe
hacer.
Mientras ms simple es el sistema, menos
tendr que comunicar sobre este, lo que
lleva a una comunicacin ms completa,
especialmente si se puede reducir el equipo
de programadores.
62

Research

Mtodos Agiles: SCRUM

Diseo
Verificacin de
consistencia&redundancia
Codificacin
Probar

BackLog

Sprint

Pila de Sprint

BackLog
Determina las prioridades
Una sola persona

Facilitador

Gestiona y Facilita la ejecucin del

proceso

Construye el producto

Asesoran y observan

Relacin de requisitos del producto, no es

necesario excesivo detalle. Priorizados. Lista en
evolucin y abierta a todos los roles. El propietario
del producto es su responsable y quien decide.
Requisitos comprometidos por el equipo
para el sprint con nivel de detalle suficiente
para su ejecucin

Hito de sprint
Parte del producto desarrollado en un sprint, en
condiciones de ser usada (pruebas, codificacin,
limpia y documentada.

Planificacin del Sprint

1 jornada de trabajo. El propietario del producto
explica las prioridades y dudas del equipo. El equipo
estima el esfuerzo de los requisitos prioritario y se
elabora de la pila de sprint. El SCRUM Manager
define en una frase el objetivo del sprint
15 minutos de duracin, dirigida por el SRUM
Manager, slo puede intervenir el equipo. Qu
hiciste ayer?, Cul es el trabajo para hoy?, Qu
necesitas?. Se actualiza la pila de sprint.
Informativa. Aprox 4 horas, moderada por el Scrum
Manager, presentacin del incremento, planteamiento
de sugerencias y anuncio del prximo sprint.

Ciclo de desarrollo bsico

del SCRUM. Debe durar
mximo 30 das

Empowerment y compromiso de las

personas
Foco en desarrollar lo comprometido
Transparencia y visibilidad del proyecto
Respeto entre las personas
Coraje y responsabilidad Minimizar el precio del

error: Socializar

Proceso gil de desarrollo iterativo e incremental. Origen : artculo The New Product Development Game (Takeuchi y Nonaka, 1986). Jeff Sutherland fue el 1ro en implementarlo en para desarrollo de software (1993, Ken Schwaber es su principal difusor)

Backlog=Requerimientos aceptados que sirven para generar el

Sprint= Requerimientos comprometidos

para el desarrollo

63
Juan Palacio

MODELO Anlisis
LINEAL

Diseo

Cdigo

Prueba

Conclusiones& Resumen
A

Escuchar al
cliente

Construir y
revisar la
maqueta

Entrega 1

D
A

MODELO DE
CONSTRUCCION
DE PROTOTIPOS

El cliente
prueba la
maqueta

NUEVO:
MODELO
AGIL

Entrega 2

C
D

P
C

Ent.3
P

Ent4

MODELO
INCREMENTAL
64

Conclusiones
Por qu utilizar uno de los modelos que ya existen ?
En qu se concreta el compromiso de calidad?
Planificacin?
Para planificar el proceso de desarrollo se debe instanciar
un modelo de procesos.
Este modelo puede ser propio o tomar uno de los que ya
existen.
Sin importar el modelo de proceso que utilicemos debemos
basarnos en un compromiso de calidad.
65