Administración de Requerimientos

Administración de
Requerimientos
1
Agenda
Software Requirements
Knowledge Areas.
Requirement Statement.
Requirement Specification.
Agreement and Expectation Mgmt..
Las 5 dimensiones.
Change Request Managment
SRM Process
Change Control Board
Requerimientos y gestión de riesgos
Ciclos de vida y riesgo.
Ingeniería de Software II
Software Requirement Management
2
2
Software Requirements
Qué es?
Una condición o capacidad necesaria para un
usuario para resolver un problema o alcanzar un
objetivo.
Una condición o capacidad que se debe alcanzar o
debe poseer un sistema o componente para
satisfacer un contrato, estándar, especificación u
otra formalidad impuesta.
Una representación documentada de alguna
condición o capacidad descrita en los dos puntos
anteriores.
Ingeniería de Software II
Software Requirement Management
3
3
Proceso “Esencial” de Software
Real World
System
Tiempo de exposición 2’
Proceso esencial de software concebido bajo Tech Orientacion a objetos y la
creacion de aplicaciones monoliticas.
•Ausencia de requerimientos de integracion up-front
Transicion: Esto nos lleva a una integracion Add-hoc
4
Software Requirements - Areas de Conocimiento
Requirement Engineering
Requirement
Development
Requirement
Management
Elicitation
Analysis
Specification
Validation
Ingeniería de Software II
Software Requirement Management
5
5
Requirements Statement Characteristics
Complete
Correct
Feasible
Necessary
Prioritized
Unambiguous
Verfiable
Ingeniería de Software II
Software Requirement Management
6
6
Requirements Specification Characteristics
Complete
Consistent
Modifiable
Traceable
Ingeniería de Software II
Software Requirement Management
7
7
Software Requirements - Areas de Conocimiento
Requirement Engineering
Requirement
Development
Requirement
Management
Project Agreement
Elicitation
Analysis
Specification
Validation
Ingeniería de Software II
Software Requirement Management
8
8
Agenda
Software Requirements
Knowledge Areas.
Requirement Statement.
Requirement Specification.
Agreement and Expectation Mgmt..
Las 5 dimensiones.
Change Request Managment
SRM Process
Change Control Board
Requerimientos y gestión de riesgos
Ciclos de vida y riesgo.
Ingeniería de Software II
Software Requirement Management
9
9
Acuerdo: por qué? para qué? Cuándo?
Para cumplir nuestros objetivos.
Para encontrar mejores objetivos.
A lo largo del proyecto, negociando
Distintas cosas.
En distintos niveles.
En distintos procesos.
De distinta manera.
Con objetivos distintos.
Ingeniería de Software II
Software Requirement Management
10
10
La negociación es distinta en
distintos procesos
Ingeniería de Software II
Software Requirement Management
11
11
Para lo que nos interesa aquí nos
centramos...
En la Iniciación
“La iniciación es el proceso de autorizar formalmente un
nuevo proyecto o la de permitir que un proyecto ya existente
continúe en su fase siguiente. Esta iniciación formal vincula
el proyecto con el trabajo continuo de la organización
ejecutante.”
¿Qué forma parte de la “Gestión del Alcance del
Proyecto”?
“La gestión del alcance del proyecto incluye los procesos
para asegurar que el proyecto incluya todo el trabajo
requerido, y solamente el trabajo requerido, de manera tal de
completar exitosamente el mismo..”
Ingeniería de Software II
Software Requirement Management
12
12
Negociar: ¿Que cosas? Las 5
dimensiones
Funcionalidades
Recursos
Humanos
Calidad
Tiempo
Ingeniería de Software II
Costo
Software Requirement Management
13
13
Relación entre las dimensiones
No son independientes entre sí
No se relacionan linealmente
Cada proyecto es crítico en algunas
dimensiones y es mas libre en otras
Cumplir con los objetivos requiere “balancear”
las dimensiones
Ingeniería de Software II
Software Requirement Management
14
14
No todos las dimensiones son
iguales
Hay aspectos que nos limitan fuertemente y que
no podemos controlar: restricción (constraint)
Hay aspectos en los que tenemos objetivos que
alcanzar: Conductor (driver)
Hay aspectos que no son ni uno ni otro: Grado
de libertad
Esto define las prioridades relativas en el
balance entre las dimensiones
Ingeniería de Software II
Software Requirement Management
15
15
Diagrama de Kiviat
Al centro (restringido) <-> Afuera (libre)
Funcionalidades
Recursos
Humanos
Calidad
Tiempo
Ingeniería de Software II
Costo
Software Requirement Management
16
16
“Houston, we have a problem”
Funcionalidades
Recursos
Humanos
Calidad
Tiempo
Ingeniería de Software II
Costo
Software Requirement Management
17
17
Ser millonario y hippie
Funcionalidades
Recursos
Humanos
Calidad
Tiempo
Ingeniería de Software II
Costo
Software Requirement Management
18
18
Sistema de información interno
Funcionalidades
Recursos
Humanos
Calidad
Tiempo
Ingeniería de Software II
Costo
Software Requirement Management
19
19
Aplicación comercial competitiva
Funcionalidades
Recursos
Humanos
Calidad
Tiempo
Ingeniería de Software II
Costo
Software Requirement Management
20
20
Sistemas “Quality Driven”
Funcionalidades
Recursos
Humanos
Calidad
Tiempo
Ingeniería de Software II
Costo
Software Requirement Management
21
21
Lo importante
Merece especial atención la negociación sobre el alcance del
proyecto: es de las primeras cosas que se negocia... Y está
en tensión todo el proyecto.
Cuando cambia la realidad (e.g. Requerimientos, RR HH...)
sirve para ver como hay que cambiar el proyecto.
Las dimensiones sirven para pensar, negociar objetivos y
tomar decisiones realistas.
Para cada restricción: cuál es su valor límite?
Para cada conductor: cuál es el objetivo?
Para cada grado de libertad: cuáles son sus límites?
El dibujo es sólo una ayuda gráfica.
Ingeniería de Software II
Software Requirement Management
22
22
Agenda
Software Requirements
Knowledge Areas.
Requirement Statement.
Requirement Specification.
Agreement and Expectation Mgmt..
Las 5 dimensiones.
Change Request Managment
SRM Process
Change Control Board
Requerimientos y gestión de riesgos
Ciclos de vida y riesgo.
Ingeniería de Software II
Software Requirement Management
23
23
Change Request Management
Change Request Management es el
almacenamiento, seguimiento y emisión de reportes
de requerimientos provenientes de cualquier
stakeholder para cambiar un sistema de software.
Ingeniería de Software II
Software Requirement Management
24
Change Request Management
Change Request Management es el almacenamiento, seguimiento y emisión de reportes de
requerimientos provenientes de cualquier stakeholder para cambiar un sistema de software.
Esto incluye el proceso de toma de decisión en cuanto a que cambios realizar y el proceso
de resolución utilizado para hacer esto posible.
Sin almacenamiento, los requerimientos de cambio podrían ser perdidos o permanecer
desconocidos por parte del team. Sin seguimiento, los cambios se saldrán de schedule o
permanecerán indireccionados.
24
¿Qué
Qué es Change Request?
Change Request es un término general utilizado
para identificar cualquier requerimiento
proveniente de un stakeholder para cambiar un
artifact o proceso.
La documentación requerida para acompañar un
requerimiento de cambio, es el origen y el
impacto del problema, la solución propuesta y una
evaluación de su costo.
Ingeniería de Software II
Software Requirement Management
25
Change Request Management
Change Request es un término general utilizado para identificar cualquier requerimiento
proveniente de un stakeholder para cambiar un artifact o proceso.
La documentación requerida para acompañar un requerimiento de cambio es el origen y el
impacto del problema, la solución propuesta y una evaluación de su costo.
25
Change Request
Los requerimientos de cambio son divididos en
dos categorías: enhancements y defects.
Los Enhancement Requests especifican funciones
nuevas o cambios en el diseño del
comportamiento del sistema.
Los Defects en cambio, son anomalías en el
producto entregado, un error en el software
generará un tema a ser seguido hasta ser resuelto.
Ingeniería de Software II
Software Requirement Management
26
Change Request Management
Change Request
Los requerimientos de cambio son divididos en dos categorías: mejoras y errores
(enhancements and defects).
Los Enhancement Requests especifican funciones nuevas o cambios en el diseño del
comportamiento del sistema.
Los errores (Defect) en cambio, son anomalías en el producto entregado, un error en el
software generará un tema a ser seguido hasta ser resuelto.
Indicar que la información recolectada es esencialmente distinta para cada uno de los casos.
26
CRM - Proceso
El proceso de monitoreo de los change requests
está representado en la mayoría de las
herramientas de CRM como un workflow
Ingeniería de Software II
Software Requirement Management
27
Change Request Management
Proceso
El proceso está representado a través de un workflow que refleja el estado del Change
Request en todos sus puntos de tratamiento.
27
CRM - Proceso
is
m
b
u
n
sio
Submitted
s
Change
Request
Complete
Ingeniería de Software II
n
tio
a
u
al
Evaluated
ev
n
io
et
l
p
m
co
Verified
Software Requirement Management
d
n
io
s
i
ec
ve
Revised
n
tio
a
ic
rif
to t
d men
n
Se lop
ve
de
In Process
28
Change Request Management
Proceso
Además de esto, las actividades podrían finalizar en la clausura del CR sin completarlo. Este
esquema presentado es el ideal donde el CR es recibido, aceptado, categorizado, implementado,
verificado y cerrado sin tener en cuenta el tratamiento de excepciones.
28
CRM - Proceso
Registro del CR
su
Change
Request
n
io
iss Submitted
bm
Complete
Ingeniería de Software II
n
io
at
u
al
Evaluated
ev
p
m
co
n
io
let
Verified
Software Requirement Management
d
on
isi
c
e
ve
Revised
n
tio
a
ic
rif
to t
d men
n
Se lop
ve
de
In Process
29
Change Request Management
Proceso
Registrado (Submitted)
En esta etapa los cambios requeridos son registrados. Defect y Enhancements Requests
difieren en el tipo de información que debe ser registrada.
Para el caso de enhancements se necesita conocer la importancia del requerimiento para el
cliente, con todo el detalle posible acerca del cambio, las restricciones de tiempo impuestas
desde fuera de la compañía e identificar al solicitante inicial.
En caso de defects, es de suma importancia identificar el modo en el cual han sido descubiertos
los errores, como puede reproducirse el error, la severidad del mismo y quien lo ha descubierto.
Existe el concepto de shortcut para los casos donde el cambio sea de emergencia. En estos
casos el proceso presentado en estos slides alcanza directamente la fase de In Process
proviniendo del Configuration Control Board.
En resumen, defects y enhancement requests comparten los mismos datos claves, tendiendo en
el caso de los defects la información asociada de severidad, usuario referente que identificó el
error, y la versión de software que estaba siendo ejecutada.
29
Evaluación, categorización y
establecimiento de prioridad
CRM - Proceso
su
Change
Request
n
io
iss Submitted
bm
Complete
Ingeniería de Software II
n
io
at
u
al
Evaluated
ev
p
m
co
n
io
let
Verified
Software Requirement Management
d
on
isi
c
e
ve
Revised
n
tio
a
ic
rif
to t
d men
n
Se lop
ve
de
In Process
30
Change Request Management
Proceso
Evaluated):
Evaluado (
Durante la evaluación alguien deberá revisar los nuevos cambios requeridos y determinar la
severidad, duplicidad, determinar si efectivamente se trata de una mejora o un error y si el error
puede efectivamente ser reproducido.
Todo error debe ser reproducido y confirmado en esta etapa. La prioridad también será
establecida en esta etapa basándose en la severidad del caso y en la importancia de que sea
resuelta.
Las mejoras requeridas no necesitan ser confirmadas, en este caso se establece simplemente
la prioridad en relación con los demás requerimientos de mejora existentes.
30
CRM - Proceso
su
Change
Request
n
io
iss Submitted
bm
Complete
Ingeniería de Software II
e
Qué y cuando
implementar
n
io
at
u
l
va
Evaluated
p
m
co
n
io
let
Verified
d
on
isi
c
e
ve
Revised
n
tio
a
ic
rif
Software Requirement Management
to t
d men
n
Se lop
ve
de
In Process
31
Change Request Management
Proceso
Revisado (Revised):
Aquí se decide cuando un cambio es implementado, si debe ser pospuesto o directamente
rechazado.
Los enhancement requests y defects son tratados en forma diferente.
La implementación de los requerimientos de mejora es decidida por el gerente de producto o el
analista. Todos estos requerimientos son medidos en forma conjunta para determinar en que
release serán liberados, cuando deberían ser realizados basados en la información obtenida
durante la etapa de evaluación.
El tratamiento de los errores depende de la etapa del ciclo de vida en la cual han sido
detectados y el tamaño del esfuerzo de desarrollo para corregirlos. En etapas iniciales del ciclo
de vida los errores son resueltos de manera informal.
En cambio, a medida que nos acercamos al final del ciclo de vida, queremos restringir los
cambios solo a los casos en que sea estrictamente necesario hacerlos. Cambios sin control
sobre el final del ciclo de desarrollo afectan el orden y seguimiento del proyecto, introducen
nuevos riesgos y generalmente causan encarecimiento del costo y desviación de la agenda del
proyecto.
31
Decision Configuration Control Board
“el comité que monitorea el proceso de cambio consiste
en representantes de todas las partes interesadas,
incluyendo clientes, desarrolladores, y usuarios. En
proyectos pequeños una sola persona, como por ejemplo
el gerente de proyecto o el arquitecto de software, podría
jugar dicho role”.
Ingeniería de Software II
Software Requirement Management
32
Change Request Management
Proceso
Revisado (Revised):
Configuration Control Board
Organizaciones de mayor envergadura cuentan usualmente con procesos de revisión formal
sobre los requerimientos de cambio realizados por una estructura de control llamada
Change/Configuration Control Board.
CCB está estructurada regularmente en forma matricial (abarca roles funcionales y de IS) y
balancea en los casos que existe litigio entre el área de calidad y agenda del proyecto durante
el desarrollo.
Se puede definir como “el equipo que monitorea el proceso de cambio consiste en
representantes de todas las partes interesadas, incluyendo clientes, desarolladores, y usuarios.
En proyectos pequeños una sola persona, como por ejemplo el gerente de proyecto o el
arquitecto de software, podría jugar dicho role”.
“the board that oversees the change process consisting of representatives from all interested parties, including customers, developers, and
users. In a small project a single person, such as the project manager or software arquitect, may play this role”
[White 2000, page 260]
CCB difiere enormemente de acuerdo al tipo de proyecto, la compañía y el tamaño y costo del
programa. Sin embargo, en todos los casos donde encontremos CCB que no sean
“unipersonales” deberemos contar con una estructura CCB.
32
Configuration Control Board Estructura
CCB del
Proyecto
CCB
Funcional
CCB
Módulo FI
CCB
Módulo
MM
Ingeniería de Software II
CCB Basis
CCB
Módulo
WM
CCB
Hardware
Software Requirement Management
CCB Tech
Support
CCB App.
Servers
33
Change Request Management
Proceso
Revisado (Revised):
Configuration Control Board
CCB Structure
Estas estructuras normalmente conforman una especie de modelo de cascada donde contamos
con un número bastante grande de CBs en los niveles inferiores que van siendo consolidados
por niveles superiores en forma de pirámide hasta alcanzar un único CB.
Los cambios generalmente son generados en los niveles inferiores donde la actividad de
programación los genera. En otros casos, el camino inverso es tomado cuando un
requerimiento de un cliente o un gerente de proyecto.
Debería existir una ruta alternativa preparada para administrar cambios de emergencia de modo
que la integridad de todo el proceso no se vea afectada por este tipo de situaciones.
Dentro de la estructura jerárquica del CCB, la decisión final recae sobre una única persona. El
nivel superior decide cuando un parche de emergencia debe ser implementado o una CR
autorizado, en muchos casos donde los cambios son mínimos, esta decisión es delegada a los
niveles inferiores de la estructura.
33
CRM - Proceso
su
Change
Request
n
io
iss Submitted
bm
Complete
n
io
at
u
al
Evaluated
ev
p
m
co
n
io
let
Verified
d
on
isi
c
e
ve
Revised
n
tio
a
ic
rif
to t
d men
n
Se lop
ve
de
In Process
System Artifact son
modificados o creados. La
documentación es actualizada.
Ingeniería de Software II
Software Requirement Management
34
Change Request Management
Proceso
En Proceso (In Process):
Durante esta etapa los artifacts son modificados o creados en busca de satisfacer el
requerimiento de cambio.
En esta etapa las diferencias entre enhancement request y defect son mas significativas dado
que el primer caso contempla una nueva funcionalidad que puede implicar un nuevo diseño.
Defects en cambio, requieren que sea reproducido el entorno en el cual el error se presentó
para poder reproducir el mismo y probar la solución implementada.
34
CRM - Proceso
su
Change
Request
n
io
iss Submitted
bm
Complete
n
io
at
u
al
Evaluated
ev
p
m
co
n
io
let
Verified
d
on
isi
c
e
ve
Revised
n
tio
a
ic
rif
to t
d men
n
Se lop
ve
de
In Process
El CR es usado para
verificar que la nueva
versión cumple con el CR.
Ingeniería de Software II
Software Requirement Management
35
Change Request Management
Proceso
Verificado (Verified):
En esta etapa se verifica que la solución cumple con el CR.
Para el caso de mejoras en el producto es simplemente verificar que el comportamiento del
producto es el especificado por el CR con lo cual es suficiente con la ejecución del plan de test
funcional. Para la verificación se trabaja exclusivamente sobre el nuevo release.
En caso de errores, se debe poder reproducir el error en la versión anterior a los efectos de
garantizar que el mismo a sido corregido.
35
CRM - Proceso
su
Change
Request
n
io
iss Submitted
bm
Complete
n
io
at
u
al
Evaluated
ev
p
m
co
n
io
let
Verified
d
on
isi
c
e
ve
Revised
n
tio
a
ic
rif
to t
d men
n
Se lop
ve
de
In Process
El solicitante es notificado y
la información acerca de
costos es almacenada.
Ingeniería de Software II
Software Requirement Management
36
Change Request Management
Proceso
Cerrado (Complete):
El principal paso aquí es cerrar el tema abierto con el stakeholder que inicio el requerimiento
de cambio.
Dependiendo el nivel de madurez de la organización es en esta etapa que se dispara un
nuevo proceso interno donde se intenta identificar los motivos del error y los nuevos errores
que estos motivos puedan estar causando (defect prevention).
La estadística de costo real y esfuerzo en encontrar la solución debe ser registrada para
alimentar la experiencia del equipo del proyecto.
36
Agenda
Software Requirements
Knowledge Areas.
Requirement Statement.
Requirement Specification.
Agreement and Expectation Mgmt..
Las 5 dimensiones.
Change Request Managment
SRM Process
Change Control Board
Requerimientos y gestión de riesgos
Ciclos de vida y riesgo.
Ingeniería de Software II
Software Requirement Management
37
37
Ciclo de Vida
Es el conjunto y la disposición de las actividades
que suceden desde la concepción del sistema
hasta que el mismo es desinstalado de la última
maquina del usuario.
Tiene como función establecer el criterio bajo el
cual proceder de un tipo de tareas a otro.
Ingeniería de Software II
Software Requirement Management
38
Ciclo de Vida
Dependiendo del ciclo de vida que uno elija, es posible mejorar la velocidad del desarrollo,
mejorar la calidad, facilitar el seguimiento, reducir la exposición a riesgos o mejorar el
contacto con el cliente. La elección errónea puede producir reducción en la productividad, retrabajo y frustración.
38
Code and Fix
Release
Especificación
del sistema
(Tal vez
exista)
Ingeniería de Software II
(Tal vez)
Software Requirement Management
39
Ciclo de Vida – Code and Fix
Este ciclo de vida es raramente útil pero sin embargo altamente utilizado. Si no se ha
explícitamente elejido un ciclo de vida probablemente sea éste el que esté siendo usado.
El ciclo comienza con una idea general sobre lo que debe ser construido. Es posible que
exista una especificación, sin ser la misma necesaria para comenzar a construir. Luego se
comienza a usar cualquier combinación de metodologías de diseño informal, codificación y
testing hasta que el producto está listo para ser liberado.
39
Code and Fix
Release
Especific
ación del
sistema
(Tal vez
exista)
(Tal vez)
Puede llegar a ser útil para pequeños
proyectos donde se sabe de
antemano que el producto será
rápidamente descartado.
Dos ventajas:
No posee overhead.
No requiere ningún tipo de conocimiento.
Muchas desventajas, entre otras:
No tenemos forma de asegurar que existe progreso alguno.
No tenemos forma de controlar la calidad ni de identificar riesgos.
Es muy probable que se alcancen puntos en el proyecto donde sea
necesario descartar absolutamente todo lo realizado.
Ingeniería de Software II
Software Requirement Management
40
Ciclo de Vida – Code and Fix
El modelo tiene dos ventajas. Primero, no posee overhead: uno salta directamente a
codificar, uno cree que posee inmediatamente signos de progreso. Segundo, no requiere
ningún tipo de conocimiento excepto saber programar: cualquiera puede usarlo.
Para pequeños proyectos que uno sabe que serán descartados rápidamente luego de ser
usados, este modelo puede llegar a ser útil (programas de conversión de datos para una
migración, pruebas de concepto en general, etc.).
Para cualquier otro projecto este modelo es peligroso. Puede ser que no tenga overhead
pero tampoco tenemos forma de asegurar que existe progreso alguno. Uno codifica hasta
que el producto se considera listo (“listo” no tiene métrica asociada tampoco). No tenemos
forma de controlar la calidad ni de identificar riesgos. Es muy probable aquí que se alcancen
puntos en el proyecto donde sea necesario descartar absolutamente todo lo realizado
justamente por no estar el objetivo bien definido y comprendido.
40
Pure Waterfall
Concepto
Análisis de
Requerimientos
Diseño
Arquitectónico
Diseño
Detallado
Codificación y
Debugging
Prueba de
Sistema
Ingeniería de Software II
Software Requirement Management
41
Ciclo de Vida – Pure Waterfall
Bajo este ciclo de vida el proyecto progresa a través de una secuencia ordenada de pasos
desde la concepción inicial del Software.
El proyecto contempla una revisión al final de cada paso para determinar si se pasará al
siguiente. Esto hace que sea posible permanecer por un tiempo indeterminado sobre uno de
los pasos si dicha revisión no es alcanzada.
El modelo waterfall es orientado a la documentación lo que significa que la gran mayoría de
los productos de software que son intercambiados entre etapas son documentación. Las
etapas no se solapan en este modelo.
41
Pure Waterfall – Salmon’s Model
Ingeniería de Software II
Software Requirement Management
42
Ciclo de Vida – Pure Waterfall – Salmon’s Model
“Es posible retroceder en las fases pero esto puede costarnos el proyecto”
42
Pure Waterfall
Concepto
Análisis de
Requerimientos
Diseño
Arquitectónico
Diseño
Detallado
Codificación y
Debugging
Prueba de
Sistema
Muy útil cuando los requerimientos de
calidad dominan el costo y el cronograma.
Debo conocer muy bien los requerimientos y
los mètodos a ser usados.
Ventajas
Produce Sistemas Confiables y de alta calidad.
Minimiza el overhead de planning.
Desventajas
Dificultad de obtener requerimientos completamente especificados al
inicio del proyecto.
La visualización de resultados se presenta al finalizar el proyecto.
No es flexible.
No apropiado para desarrollos rápidos por cantidad de documentación.
Ingeniería de Software II
Software Requirement Management
43
Ciclo de Vida – Pure Waterfall
En proyectos donde hay alta estabilidad funciona bien. La estabilidad se relaciona con un
gran conocimiento de los requerimientos y de los métodos que serán usados.
En estos casos no sólo es un modelo eficiente sino que es el correcto a usar puesto que
tenemos la oportunidad de encontrar errores de alto impacto en etapas tempranas y de bajo
costo.
El modelo contribuye a minimizar el overhead en la planificación porque es posible hacer la
actividad de planificación al inicio. Por otra parte, no tenemos resultados tangibles hasta el
fin del proyecto. El avance debe ser entonces medido a partir de la documentación generada
durante las etapas.
Funciona bien cuando los requerimientos de calidad dominan el costo y el cronograma.
Las desventajas del modelo radican en la dificultad de conocer los requerimientos al 100%
antes de comenzar a diseñar.
43
Sashimi (Waterfall + Overlapping)
Concepto
Análisis de
Requerimientos
Diseño
Arquitectónico
Diseño
Detallado
Codificación y
Debugging
Prueba de
Sistema
Ingeniería de Software II
Software Requirement Management
44
Ciclo de Vida – Sashimi
En el modelo puro Waterfall, la documentación ideal es la que es pasada “de mano en mano”
entre los equipos de trabajo que operan en las diferentes fases. La pregunta es “¿Por qué?”.
Si el equipo de trabajo es el mismo que opera en cada una de las fases, entonces no es
necesaria la documentación creada para transmitir el conocimiento entre fases. Este cambio
reduce la documentación a la necesaria para el posterior mantenimiento del Software.
44
Sashimi (Waterfall + Overlapping)
Concepto
Diseño
Arquitectónico
Diseño
Detallado
Codificación y
Debugging
Prueba de
Sistema
Aplicable en condiciones similares al
pure waterfall pero con equipos más
pequeños.
Asumimos que el mismo equipo
realiza actividades en más de una
fase.
Análisis de
Requerimientos
Ventajas
Reduce la documentación necesaria en el purewaterfall.
Mismas ventajas que el purewaterfall.
Desventajas
Mismas dificultades que el pure waterfall.
Adicionalmente el solapamiento puede ocasionar conflictos
relacionados con la comunicación entre fases solapadas.
Ingeniería de Software II
Software Requirement Management
45
Ciclo de Vida – Sashimi
Como existe solpamiento entre fases, los milestones son más ambiguos y esto hace más
difícil realizar el seguimiento con cierto nivel de seguridad.
Efectuar actividades en paralelo requiere que las actividades solapadas estén bien
comunicadas, estamos expuestos a que cambios o novedades en actividades “viejas” no
sean comunicadas a las actividades “nuevas” y por ende exista inconsistencia a lo largo del
ciclo.
45
Waterfall with Subprojects
Diseño
Detallado
Concepto
Codificación y
Debugging
Análisis de
Requerimientos
Prueba de
SubSistema
Diseño
Arquitectónico
Diseño
Detallado
Codificación y
Debugging
Prueba de
SubSistema
Diseño
Detallado
Codificación y
Debugging
Integración
Prueba de
SubSistema
Prueba de
Sistema
Ingeniería de Software II
Software Requirement Management
46
Ciclo de Vida – Waterfall with Subprojects
Otro problema con el modelo waterfall puro es que se supone que debemos completar el
100% del diseño arquitectónico antes de comenzar con el diseño detallado, y que a su vez
debemos completar el 100% del diseño detallado antes de comenzar a codificar. .
Los sistemas tienen ciertas áreas donde existen sorpresas de diseño, pero también existen
áreas donde la tarea es simple e incluso en algunos casos conocida. ¿Por qué entonces
retrasar el comienzo de los subsistemas simples a causa de la complejidad de parte de la
arquitectura?.
Si es posible partir la arquitectura en subsistemas lógicamente independientes se pueden
obtener subproyectos que sean tratados independientemente y en paralelo hasta llegar al
momento de integrarlos.
46
Waterfall with Subprojects
Diseño
Detallado
Concepto
Codificación y
Debugging
Análisis de
Requerimientos
Prueba de
SubSistema
Diseño
Arquitectónico
Diseño
Detallado
Codificación y
Debugging
Prueba de
SubSistema
Diseño
Detallado
Codificación y
Debugging
Integración
Aplicable en condiciones similares al
pure waterfall pero donde es posible
identificar subsistemas independientes.
El equipo de trabajo es suficientemente
grande como para paralelizar el trabajo.
Prueba de
SubSistema
Ventajas
Prueba de
Sistema
Permite construir los subsistemas en paralelo.
Mismas ventajas que el purewaterfall.
Desventajas
Posibles problemas de integración por interdependencias
no identificadas.
Ingeniería de Software II
Software Requirement Management
47
Ciclo de Vida – Waterfall with Subprojects
El mayor riesgo de esto es que existan interdependencias no previstas que generen
problemas de integración. Este riesgo es posible mitigarlo con una actividad de arquitectura
más intenso que en el caso del pure waterfall, pero nunca podremos eliminarlo por completo.
47
Waterfall with Risk Reduction
Concepto
Análisis de
Requerimientos
Prototipación
Diseño
Arquitectónico
Diseño
Detallado
Codificación y
Debugging
Prueba de
Sistema
Ingeniería de Software II
Software Requirement Management
48
Ciclo de Vida – Waterfall with Risk Reduction
Otro de los problemas del waterfall puro es que es necesario tener una precisa definición de
los requerimientos antes de comenzar con el diseño arquitectónico. Esta necesidad no solo
se encuentra en los requerimientos sino que es necesario para ingresar en un fase contar
con gran estabilidad en la anterior y con el total de los productos requeridos para ingresar en
la nueva fase.
Una posible modificación leve al pure waterfall es la propuesta por “Risk Reduction”, donde
se incorpora una actividad de prototipado de interfaz o de aquellos componentes de mayor
riesgo por la incertidumbre natural al desarrollo de Software. Esta actividad no
necesariamente debe centrarse en los requerimientos sino que es posible extenderla al
diseño e incluso a la codificación.
48
Waterfall with Risk Reduction
Lo aplico en los casos donde es
posible identificar aquellas áreas
donde hace falta mayor conocimiento.
(*) Esto no siempre es posible.
Concepto
Análisis de
Requerimientos
Prototipación
Diseño
Arquitectónico
Diseño
Detallado
Codificación y
Debugging
Prueba de
Sistema
Ventajas
Reduce el riesgo con respecto al pure waterfall proveniente de los
requerimientos incompletos o mal definidos.
Mismas ventajas que el purewaterfall.
Desventajas
Debo poder identificar las áreas donde sea necesaria mayor definición.
Ingeniería de Software II
Software Requirement Management
49
Ciclo de Vida – Waterfall with Risk Reduction
La actividad de prototipado es generalmente beneficiosa aunque existe la posibilidad de no
poder recolectar mayor información incurriendo en gastos que no tienen rédito en el
proyecto.
Dado que luego de la actividad de prototipado el ciclo es idéntico al pure waterfall estamos
frente a las mismas dificultades que en dicho modelo.
49
Spiral
Objetivos
Riesgos
Planificación
Desarrollo
Profundidad: 1ero: análisis, 2do: diseño, 3ero construcción, 4to implementación
Ingeniería de Software II
Software Requirement Management
50
Ciclo de Vida – Spiral
El ciclo de vida spiral es un modelo orientado a riesgos, donde el proyecto es dividido en
mini-proyectos. Cada uno de los mini-proyectos atiende a uno a más riesgos “importantes”
hasta que finalmente todos los riesgos con alta exposición han sido atendidos.
El concepto de riesgo es el visto en clase, se refiere a requerimientos pobremente
entendidos, a arquitectura pobremente definida o comprendida, problemas potenciales de
performance, problemas en la tecnología subyacente, y demás temas del proyecto donde
sea requerido mayor conocimiento.
Una vez que los riesgos han sido atendidos el ciclo de vida finaliza como el pure waterefall.
La idea detrás del modelo es que uno comienza con un alcance reducido en el centro de la
espiral, explora los riesgos ç, construye el plan para atender los riesgos encontrados, y luego
planea el siguiente ciclo. Cada iteración mueve el proyecto hacia un alcance más extenso.
50
Spiral
Identificar y
resolver riesgos
Evaluar
alternativas
lis
is
de
R
ies
go
s
Determinar objetivos,
alternativas y restricciones
A
ná
Inicio
Plan de
Desarrollo
Plan
d
Prueb e
a
n
dació
Vali eq uer.
de R
Plan de
Integración
Planificar la
siguiente iteración
Ingeniería de Software II
Simul
Plan de Req.,
Plan de Ciclo
de Vida
Release
3
1, ..
tipo
Proto ional
c
Opera
acione Modelos
s
R
de eq u
So er .
ft .
Revisión
tipo
Proto
D
i
Pr señ
od o d
uc e
to
Compromiso
para la siguiente
iteración
Ben
chm
a rks
Diseño
Detallado
e
d
Code
o
Diseñ V
Prueba
V&
Integr. Unidad
y
Prueba
Prueba
Acept.
Construir el
entregable de la
iteración y verificar
que es correcto.
Software Requirement Management
51
Ciclo de Vida – Spiral
Cada iteración comprende 6 pasos representados en los cuadros que rodean la espiral del
slide.
1. Determinar objetivos, alternativas y restricciones.
2. Identificar y resolver riesgos.
3. Evaluar alternativas.
4. Desarrollar los entregables de la iteración y verificar que son correctos.
5. Planificar la siguiente iteración.
6. Si se decide continuar, obtener compromiso para la siguiente iteraciòn.
51
Spiral
Objetivos
Riesgos
Planificación
Desarrollo
Modelo orientado a manejo de riesgos. A
medida que avanza el tiempo y dinero
invertidos, la exposición al riesgo
disminuye.
Ventajas
Equilibrio óptimo entre exposición al riesgo e inversión.
Mayor o equivalente control que en el modelo pure waterfall.
Desventajas
Requiere gran conocimiento de gestión por parte de quien dirige el
proyecto.
Es posible que si en un momento del proyecto la exposición al riesgo es
baja, el modelo se vuelva innecesariamente caro.
Ingeniería de Software II
Software Requirement Management
52
Ciclo de Vida – Spiral
En el modelo espiral las etapas tempranas son las más económicas. Uno gasta menos
desarrollando el concepto de operación del Software de los que gasta en la ingeniería de
requerimientos, y menos en los requerimientos de lo que gasta en el diseño, desarrollando el
producto y probándolo.
Una de las ventajas más importantes del modelo es que el costo aumenta a medida que el
riesgo decrece. A mayor tiempo y dinero invertido, menor la exposición al riesgo. Esto es
justamente uno de los atributos más buscados en un proyecto de Software.
El modelo espiral provee igual o mayor control en la gestión del proyecto de la provista por el
modelo tradicional pure waterfall. Uno cuenta con puntos de control al finalizar cada
iteración. Si el proyecto es inviable debido a razones técnicas o funcionales, es descubierto
ésto en forma temprana.
La única desventaja del modelo radica en su complejidad.
Requiere de quién gestiona el proyecto conciencia, atención y conocimiento en gestión.
Puede llegar a ser difícil definir milestones objetivos y verificables, que indiquen cuando uno
está en condiciones de agregar una nueva iteración.
En algunos casos el producto alcanzado es suficiente, y los riesgos a los que estamos
expuesto moderados lo suficiente como para que no sea requerido continuar “pensando en
riesgos”, con lo que el modelo orientado a riesgos propuesto por el ciclo de vida espiral se
vuelve redundante.
52
Evolutionary Delivery
Concepto
Inicial
Diseño e
implementación
del prototipo
Inicial.
Ingeniería de Software II
Refinamiento
del prototipo
Hasta que sea
aceptable
Completar y
lanzar el
prototipo
Software Requirement Management
53
Ciclo de Vida – Evolutionary Delivery
En este modelo uno desarrolla el concepto del sistema a medida que avanzo sobre el
proyecto.
Usualmente comenzamos desarrollando los aspectos más visibles del sistema. El resultado
es mostrado al cliente y el producto evoluciona en base a la información obtenido por parte
de éste. En determinado momento el cliente indica que el prototipo es “suficientemente
bueno”, se completan las tareas remanentes, especialmente las relacionadas con
performance, y el prototipo se convierte así en el release.
53
Evolutionary Delivery
Concepto
Inicial
Diseño e
implementación
del prototipo
Inicial.
Refinamiento
del prototipo
Hasta que sea
aceptable
Completar y
lanzar el
prototipo
Modelo orientado a proyectos
donde no existe una buena
definición de requerimientos
Ventajas
Extracción de requerimientos incremental y buena
interacción con el cliente.
Desventajas
Peligro de que se convierta en Code & Fix.
Puede no converger a una solución.
Ingeniería de Software II
Software Requirement Management
54
Ciclo de Vida – Evolutionary Delivery
Este modelo es especialmetne útil cuando los requerimientos son dinámicos o pobremente
definidos. También es útil cuando el cliente no tiene la capacidad o voluntad para
comprometerse con un requerimiento mejor definido, o no existe nadie que conozca bien el
dominio de problema.
La mayor desventaja de este modelo radica en que no es posible saber en qué momento el
producto convergerá a la solución. Uno desconoce cuantas iteraciones deberán ser
necesarias para obtener finalmente el producto.
Otra desventaja es que el modelo fácilmente se convierte en Code & Fix. Distinguimos
“evolutionary delivery” de “code & fix” principalmente porque la actividad de especificación y
diseño existen en el primer modelo.
54
Staged Delivery
Concepto
Análisis de
Requerimientos
Diseño
Arquitectónico
Etapa 1:
Diseño detallado, Codificación, Prueba, entrega.
Etapa 2:
Diseño detallado, Codificación, Prueba, entrega.
Etapa n:
Diseño detallado, Codificación, Prueba, entrega.
Ingeniería de Software II
Software Requirement Management
55
Ciclo de Vida – Staged Delivery
El ciclo de vida staged delivery es un modelo en el cual uno muestra el producto al cliente en
etapas sucesivas, aumentando en cada una el nivel de refinamiento. En este modelo uno
conoce exactamente lo que va a construir desde el comienzo, pero planifica la entrega en
etapas (diferencia con el modelo evolutionary delivery).
55
Staged Delivery
Concepto
Análisis de
Requerimientos
Diseño
Arquitectónico
Etapa 1:
Diseño detallado, Codificación, Prueba, entrega.
Etapa 2:
Diseño detallado, Codificación, Prueba, entrega.
Modelo orientado a dividir el
requerimiento y realizar un
despliegue incremental.
Etapa n:
Diseño detallado, Codificación, Prueba, entrega.
Ventajas
Las funciones principales sen entregan antes.
El feed-back del cliente aumenta a medida que la función es más
esencial para el producto...
Signos tempranos y tangibles de avance.
Desventajas
Posibles interdependencias entre etapas no identificadas.
Ingeniería de Software II
Software Requirement Management
56
Ciclo de Vida – Staged Delivery
A nivel de gerenciamiento, se debe estar seguro que las etapas tienen sentido con respecto
al uso que el cliente le dará, y que el entregable de cada una de ellas está “autocontenido”
A nivel técnico, se debe asegurar que las dependencias entre los entregables de las etapas
no impiden que el producto sea construido independientemente.
La ventaja principal del modelo radica en que nos permite entregar la funcionalidad pricipal al
principio del proyecto. Si las etapas son planeadas con cuidado, podemos reducir el riesgo
en los puntos centrales del Software entregándolos primero y pudiendo así obtener feedback operacional antes del fin del proyecto, cuando aún podemos toamar medidas
correctivas. Otra ventaja es que provee signos tangibles de avance desde etapas tempranas,
lo que facilita el control sobre presión que pueda ejercer el cliente.
56
Conclusiones
El acuerdo de proyecto es la “bisagra” entre el
desarrollo de requerimientos o construccion del SRS y
la gestión de cambios.
La gestión de cambios debe considerar a todos los
stakeholders pero debe considerar la agilidad del
negocio. (CCB)
El ciclo de vida de software se debe ajustar a la
incertidumbre del proyecto a fin de gestionar el riesgo
de cambios en los requerimientos.
Ingeniería de Software II
Software Requirement Management
57
57
Fin
Muchas gracias!
58