INTRODUCCIN A INGENIERA DE SOFTWARE

& MODELOS DE PROCESOS

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 Requiere: Modelado mnimo Proceso simple

Vs.
Construido eficientemente y en un
tiempo razonable por un equipo
Requiere: Modelado (de Patricio Lettelier) Proceso bien definido
4

Herramientas simples

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

2.

3.

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

1,5 6x 1x

Definicin

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

Relacin de la calidad con el Software

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 Mant. Correctivo Mant. Adaptativo Mant. Perfectivo Mant. Preventivo o Reingeniera del Software
23

Desarrollo
(COMO)

Soporte
(CAMBIOS)

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 DRA Desarrollo Concurrente Construccin de Prototipos Incremental

Espiral
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:

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.

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 objetiv os prototipo Def inir f uncionalidad prototipo Desarrollar prototipo Ev aluar prototipo

Plan prototipo

Def inicin prototipo

Prototipo ejecutable

Reporte ev eluacin

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

Versin Inicial Especificacin

Bosquejo de la

Versiones Desarrollo

Descripcin

Intermedias

Validacin

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

Modelo DRA
Equipo # 1
Qu informacin? Quin la genera? A dnde va? Identificacin de Objetos y relaciones Descripciones de procesos de negocio para ABM de objetos de MD

Equipo # n Modelo de Negocio

Equipo # 2 Modelo de Negocio

Modelo de Datos Modelo de Proceso Generacin de Aplic. Prueba y Entrega

Modelo de Negocio

Modelo de Datos Modelo de Proceso

Modelo de Datos

Generacin de Aplic. Prueba y Entrega

Modelo de Proceso

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

Generacin de Aplicacin 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
Anlisi s Diseo Codif. Prueba
Entrega 1er Incremento

Inc1

Inc2

Anlisi s

Diseo

Codif.

Prueba

Entrega 2do Incremento

Inc3

Anlisi s

Diseo

Codif.

Prueba
Tiempo

Entrega 3er Incremento

41

 Modelo Incremental

Establecer entregas del sistema

Especif icar incremento del sistema no

Costruir incremento del sistema

Validacin incremento

Entrega sistema completo

si

Sistema completo?

Validacin del Sistema

Integracin del Incremento

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 Comunicacin con el Cliente Anlisis de Riesgos

Ident. Comps. candidatos Buscar Comps. en biblioteca

F

Ingeniera, Construccin y Entrega Evaluacin del Cliente

Construir
Colocar en biblioteca

Extraer

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.

Generador de Pantallas Planillas de Clculo Generador de Informes Generador de Cdigo

Lenguage de consulta a BD

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 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 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 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 interaccin El software que funciona La colaboracin con el cliente La respuesta al cambio

por encima por encima por encima por encima

de los procesos y las herramientas de la documentacin exhaustiva la negociacin contractual 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
51

http://agilemanifesto.org/

Mtodos Agiles
eXtreme Programming (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 Programming (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 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 en 53 controlar los cambios en los requisitos.

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

Mtodos Agiles: SCRUM

BackLog

Research Diseo Verificacin de consistencia&redundancia Codificacin Probar

Sprint

Pila de Sprint

BackLog
Determina las prioridades Una sola persona Gestiona y Facilita la ejecucin del proceso 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

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

Facilitador

Construye el producto

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

Asesoran y observan

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

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)

error: Socializar

Backlog=Requerimientos aceptados que sirven para generar el sprint

Sprint= Requerimientos comprometidos para el desarrollo

63
Juan Palacio

MODELO Anlisis LINEAL

Diseo

Cdigo

Prueba

Conclusiones& Resumen
A
Construir y revisar la maqueta

D A

C D A A

P C D D

Entrega 1 P C C Entrega 2 P P Ent.3

Escuchar al cliente

Ent4

MODELO DE CONSTRUCCION DE PROTOTIPOS

El cliente prueba la maqueta

NUEVO: MODELO AGIL

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