Introducción a la Ingeniería de Software

Introducción a la Ingeniería de Software

Introducción a la
Ingeniería de Software
Curso IIC 2143 – Ingeniería de Software
Rodrigo Sandoval 2010
Contenidos
• ¿Qué es la Ingeniería de Software?
• Procesos de Desarrollo
• Enfrentando un problema y su solución
– Análisis
– Diseño
– Enfoque iterativo
En parte basado en material de Yadran Eterovic, DCC, PUC
¿Qué es la IS?
Disciplina orientada a la
producción de Software de
Buena Calidad.
Enfoque sistemático,
disciplinado, y cuantificable
al desarrollo, operación, y
mantenimiento de software.
Una disciplina cuyo objetivo es la
producción de software sin errores,
entregado a tiempo y dentro del
presupuesto, fácil de modificar, y que
satisface las necesidades del cliente.
El Software es
Inherentemente
Complejo
•El dominio del problema
es complejo.
•El proceso de desarrollo
es difícil de gestionar.
•El software permite
muchísima flexibilidad.
•La caracterización del
comportamiento de
sistemas discretos es difícil.
Construcción de Software
• Construir software de buena calidad de
manera repetible y predecible es aún más
difícil.
• Las empresas siguen demandando mayor
productividad, mejor calidad, y desarrollos y
puestas en operación más rápidos.
• El desarrollo de software se vuelve cada vez
más intensivo en mano de obra - las personas
son el recurso más caro.
Proyectos de Software
24%
32%
Proyectos exitosos
Proyectos problemáticos
Proyectos fallidos
44%
• Standish Group Chaos Report 2009
¿Qué hace que un
(standishgroup.com)
proyecto sea exitoso y
otro falle en mayor o
menor grado?
De muestra, un botón …
DE: Germany freezes development of its employment portal
eGovernment News – 02 March 2004 – Germany – eServices for citizens
On 25 February 2004, the German Federal Labour Office (Arbeitsamt) announced it was
freezing its job portal development plans due to skyrocketing costs. Although the original
costs were evaluated at EUR 65 million, new estimates indicate the portal would cost EUR
165 million up to 2008.
Due to be one of the office's flagship projects, the new employment portal - Arbeitsagentur.de suffered from a number of technical problems since it went online in December 2003.
However, its freeze was brought about by a financial scandal, with the new head of the
German Federal Labour Office Frank-Jürgen Weise denouncing an out-of-control budget and
the public prosecutor investigating corruption suspicions. In this context, Mr Weise decided to
fire the head of the Arbeitsagentur.de project.
. . . The website, which was developed by Accenture, has been criticized for being slow,
instable and failing to deliver requested information. On 27/02/2004, a press release by
Accenture denied any corruption in the bidding procedure and stated that the second stage of
the project was running according to schedule.
. . . The portal was supposed to be further developed in the coming years, with for instance an
enhanced matching system to be implemented in May and a Service Centre for job
intermediation and consultation to be launched in August 2004.
© European Communities 2004
Arbeitsagentur.de - Análisis
Problemas:
– Preparación
• ¿Estimaciones?
• ¿Levantamiento adecuado de los requerimientos y
condiciones/restricciones?
– Desarrollo
• ¿Control de Calidad?
– Errores (estabilidad)
– Desempeño ante carga real
– No entrega la información requerida
– Administración del Proyecto
• Dimensionamiento adecuado: plazos de entrega vs.
Funcionalidades.
• Visibilidad hacia los interesados.
… y otro Botón
• FBI's Virtual Case File (VCF)
– Application de software desarrollada por el Federal Bureau
of Investigation (FBI), entre el 2000 y el 2005..
– El proyecto no estaba ni cerca de ser terminado cuando
fue abandonado en Enero 2005, habiéndose transformado
en un completo fiasco para el FBI.
– Además de haber desperdiciado al menos US$100
millones, la falla trajo una amplia y dura crítica dura al
Bureau y su director, Robert S. Mueller III.
Fuente: Wikipedia
http://en.wikipedia.org/wiki/Virtual_Case_File
Virtual Case File (FBI) - Análisis
Fallas en prácticas de Ingeniería de Software detectadas en este proyecto:
•
•
•
•
•
Falta de planos sólidos desde el
comienzo llevaron a decisiones pobres
en arquitectura.
Cambios reiterados en la
especificación.
Cambior reiterados en el
management, lo que contribuyó a los
cambios en especificaciones.
Micromanagement de los
desarrolladores.
La inclusión de mucho personal del
FBI que tenía poco o ningún
entrenamiento formal en ciencia de la
computación, como managers e
incluso como ingenieros en el
proyecto.
•
•
•
•
Problemas de alcance a medida que los
requisitios eran contínuamente
agregados al sistema, incluso frente a
atrasos en las entregas.
Problemas en el código debido al
alcance y las especificaciones
cambiantes. En un punto se estima que
el software tenía sobre 700.000 líneas
de código.
Adición de más gente y recursos al
proyecto a medida que se iba atrasando,
lo cual lo hizo atrasarse aún más (Ley de
Brooks).
Planificación de una liberación muy
drástica al final, lo cual hizo muy difícil la
adopción del sistema hasta que se fuese
perfeccionando.
Razones para fallas (en general)
• La gestión de requisitos es
ad hoc.
• La comunicación es
ambigua e imprecisa.
• Las arquitecturas de
sistemas/software son
frágiles.
• La complejidad es
abrumadora.
• Hay inconsistencias
inadvertidas en
requisitos, diseños e
implementaciones.
• Las pruebas son
insuficientes.
• La evaluación del estado
del proyecto es subjetiva.
• Se omite enfrentar los
riesgos.
• Hay propagación
descontrolada de cambios.
• La automatización es
insuficiente.
¿Y entonces, cómo se resuelve?
• La industria ha visto como varias buenas prácticas
ingenieriles han llevado al éxito en los proyectos:
–
–
–
–
–
–
Modelamiento visual
Desarrollo incremental
Administración de requerimientos
Arquitecturas basadas en componentes
Verificación continua de la calidad
Control de cambios
 Gran parte de estas se aplican en un
proceso de desarrollo de software.
Definiciones y tipos de
PROCESO DE DESARROLLO DE
SOFTWARE
Proceso de Desarrollo de Software
• Un proceso define, entre otras cosas:
– La organización de actividades del equipo.
– Los roles de los involucrados y sus respectivas
metas.
– Los artefactos que deben ser generados y cuándo.
– Los criterios para supervisar y medir los productos
y actividades del proyecto.
¿Qué pasa sin un
proceso de
desarrollo?
El equipo desarrolla de
manera ad hoc.
El éxito depende de los
esfuerzos heroicos de
unos pocos.
 No es el enfoque
de un ingeniero.
Proceso “Code and Fix”
Implementar
primera versión
Cambiar mientras
el cliente no
esté satisfecho
Mantenimiento
post entrega
Cascada
R
I
E
S
G
O
Análisis
Requisitos
Diseño
Codificación
Testing
Mantención
T I EMPO
Modelo V: Evolución de Cascada
– Puede notarse que su primera mitad es similar al Modelo en
Cascada, y la otra mitad tiene como finalidad hacer pruebas
e integración asociado
a cada una de las
etapas de la mitad
anterior.
– Ventaja:
involucra chequeos
de cada una de las
etapas del modelo
cascada.
Modelo de espiral
– Desarrollado para cubrir las mejores características tanto del ciclo de vida
clásico, como de la creación de prototipos, añadiendo al mismo tiempo un
nuevo elemento: el análisis de riesgo.
– Durante la primera vuelta alrededor de la espiral se definen los objetivos,
las alternativas y las restricciones, y se analizan e identifican los riesgos.
– Si el análisis de riesgo indica
que hay una incertidumbre en
los requisitos, se puede usar la
creación de prototipos en el
cuadrante de ingeniería para
dar asistencia tanto al
encargado de desarrollo como
al cliente.
– Con cada iteración alrededor de
la espiral (comenzando en el
centro y siguiendo hacia el
exterior), se construyen
sucesivas versiones del
software, cada vez más
completa y, al final, al propio
sistema operacional.
La realidad de Cascada
• C. Larman [“Agile and Iterative Development: A
Manager’s Guide”, Addison-Wesley 2003]
muestra que su uso ha sido una mala práctica:
– su tasa de éxito es baja (sólo un 10%);
– en promedio, el 45% de las propiedades identificadas
en la etapa de requisitos no son usadas;
– las estimaciones iniciales de costos y plazos varían
hasta en un 400% con respecto a los valores reales
finales;
– presenta menor productividad y mayores tasas de
errores que los procesos iterativos.
Supuestos y Limitaciones
• Los productos pueden ser desarrollados
completamente en una pasada.
• Los requisitos permanecerán congelados y
todos son igualmente importantes.
• Se puede hacer un diseño correcto, eficiente y
factible en papel antes de proseguir.
Enfrentando los supuestos
• El cambio es una constante en los proyectos de
software.
 Incorporar instancias para atender los cambios
• Los requisitos serán inestables en el tiempo.
 Manejar los requisitos ordenadamente,
diferenciar prioridades, entrar en detalles cuando
sea el momento.
Desarrollo Iterativo-Incremental
+
=
Procesos de Desarrollo
Proceso
Fortalezas
Prioridades
Situaciones
Serial
(Cascada)
Administra riesgo de costo.
Solidez diseño y arquitectura.
1) Funcionalidades
2) Poco defecto
3) Tiempo x release
Software embebido en hardware
o para controlar un dispositivo
crítico. Requisitos estables, alta
calidad.
Iterativo
Administra riesgo técnico.
1) Funcionalidades
2) Poco defecto
3) Tiempo x release
Productos o ideas nuevas que
requieren refinarse antes del
desarrollo.
Administra riesgo de calendario
Absorbe cambios en reqs.
1) Tiempo x release
2) Poco defecto
3) Funcionalidades
La mayoría de los proyectos,
como nuevas versiones de
productos, necesidad de
flexibilidad y compromisos de
tiempo.
Administra riesgo técnico y de
calendario
Requiere un equipo bien
afiatado.
1) Tiempo x release
2) Funcionalidades
3) Poco defecto
Productos nuevos. Requisitos
inestables. Necesidad de
experimentación y tiempo
limitado.
1) Tiempo x release
2) Funcionalidades
3) Poco defecto
Experimentos. Nada crítico.
(Espiral)
Incremental
(RUP)
IterativoIncremental
(Ágil)
Ad-hoc
(Code & Fix)
Enfrentando la Solución
ANÁLISIS Y DISEÑO EN UN
PROYECTO DE SOFTWARE
Enfrentando el proyecto
• Más allá del proceso de software
determinado, el equipo desarrolla diferentes
actividades durante el proyecto.
• Estas actividades buscan definir y entender el
problema, e imaginarse la solución.
• El modelamiento visual es una de las
herramientas más exitosas del último tiempo,
buscando utilizar elementos gráficos para
describir diferentes elementos.
Describir el problema
• Es el “cliente” quien tiene un problema que
requiere solución.
– Requisitos”  Necesidades
– No tiene conocimiento para definir una solución
en detalle.
– No siempre tiene claridad de cuál es realmente el
problema de fondo.
– No siempre es capaz de organizar estas
necesidades en una forma que facilite la
implementación de una solución.
Describir el problema
• La descripción del
problema debe usar un
lenguaje que facilite la
comunicación entre todos
los participantes.
• Por ejemplo, Casos de
Uso de UML o Historias
de Desarrollo Ágil.
Entender el Problema
• Es un analista quien muchas veces realiza esta
definición. Considerando lo siguiente:
– ¿Qué se supone que hace el producto?
– Describir los requisitos en términos técnicos
precisos  una especificación.
– Plan de gestión del proyecto de desarrollo.
Imaginarse la Solución
• Entre arquitecto y desarrolladores, tomando
el input del analista, diseñan una posible
solución.
– Diseño arquitectónico, o de alto nivel
 módulos.
– Diseño detallado,
utilizando un lenguaje
técnico como los
diagramas UML.
Enfrentando el proyecto
• El levantamiento de requisitos, el análisis
detallado, el diseño son actividades que se
realizan varias veces en un proyecto iterativo.
• Cada iteración involucra éstas y otras
actividades.
• La cantidad de tiempo de dedicación a cada
actividad puede ir cambiando en cada
iteración.
DESARROLLO
ITERATIVO-INCREMENTAL
1
2
3
4
5
6
7
8
9
10
80%
25%
10%
5%
iteración 1
33%
15%
8%
iteración 2
10%
25%
iteración 3
33
Proyecto iterativo
R
I
E
S
G
O
T I EMPO
Enfoques iterativos-incrementales
• Rational Unified Process (RUP)
• Desarrollo Ágil
– eXtreme Programming
– Scrum
– Otros …
El desarrollo iterativo: Práctica clave
en los procesos modernos
• El desarrollo es organizado en una serie de
mini-proyectos cortos y de duración fija —
iteraciones.
• Cada iteración incluye sus propias actividades
de análisis de requisitos, diseño,
implementación y testing.
• El resultado de cada iteración es un sistema
parcial ejecutable, validado e integrado —no
es un prototipo experimental o desechable.
36
Requisitos
Requisitos
Diseño
Implementación,
pruebas, integración, más diseño
Integración final,
prueba del
sistema
Una iteración, de duración
fija; p.ej., cuatro semanas
Diseño
Tiempo
Implementación,
pruebas, integración, más diseño
Integración final,
prueba del
sistema
El sistema crece
incrementalmente
37
La actitud clave:
Acoger el cambio y la adaptación
• Cambio y adaptación son motores inevitables
y hasta esenciales.
• No se trata de favorecer un proceso reactivo,
que obedece a la aparición descontrolada de
requisitos:
– p.ej., RUP balancea la necesidad de ponerse de
acuerdo y estabilizar un conjunto de requisitos,
con la realidad de requisitos cambiantes, a medida
que los interesados clarifican su visión o el
mercado cambia.
38
En cada iteración elegimos un
subconjunto pequeño de requisitos
• … y diseñamos, implementamos y verificamos
(rápidamente) un subsistema que responde a ese
subconjunto de requisitos:
– los requisitos y el diseño de las iteraciones iniciales
pueden no ser exactamente lo que finalmente
necesitamos;
– … pero el dar pasos pequeños rápidamente permite
retroalimentación igualmente rápida de los usuarios,
desarrolladores y a partir de las pruebas;
– en lugar de especular sobre los requisitos o el diseño,
se aprovecha la retroalimentación proveniente de
construir y probar de manera realista.
39
El desarrollo iterativo ofrece beneficios
en múltiples ámbitos
• Gestión de riesgos:
– podemos validar/invalidar los requisitos y
suposiciones de diseño implementando
incrementalmente partes del sistema, comenzando
por las más riesgosas.
• Economía:
– podemos revisar las prioridades frecuentemente y
tratar las inversiones como si fueran opciones —
negocios inciertos;
– las opciones se vuelven más valiosas si hay más
flexibilidad gracias a resultados tempranos y
verificaciones frecuentes.
40
• Foco:
– al agrupar el trabajo en iteraciones pequeñas, los integrantes
del equipo se enfocan mejor en ese trabajo.
• Motivación:
– es motivante para un equipo de software ver entregas
tempranas funcionando.
• Control:
– las iteraciones cortas ayudan a reducir el error de las
estimaciones y proporcionan retroalimentación rápida sobre los
planes.
• Involucramiento de los interesados:
– clientes, usuarios, etc., ven resultados antes y se involucran
más, dedicando más tiempo, perspicacia y recursos ($).
• Aprendizaje continuo:
– el equipo aprende en cada iteración acerca del producto final.
41
El desarrollo iterativo
presenta varios desafíos
• ¿Cómo hacemos converger el trabajo de las
iteraciones para convertirlo en un producto?
– ¿Cómo evitamos que cada iteración comience de
nuevo desde cero?
• ¿Cómo decidimos qué hacer en la próxima
iteración?
– ¿Cuáles requisitos y cuáles riesgos abordamos?
• ¿Cómo resolvemos los problemas
mencionados antes?
42
Las iteraciones deberían durar
entre dos y seis semanas
• Las ideas centrales en desarrollo iterativo:
– pasos pequeños, retroalimentación rápida,
adaptación.
• Las iteraciones no deben ser muy cortas:
– es difícil hacer suficiente trabajo como para tener
resultados significativos y permitir retroalimentación.
• Las iteraciones no deben ser muy largas:
– la complejidad se vuelve abrumadora, la retroalimentación se demora, aumentan los riesgos del proyecto.
43
… y su duración debería ser fija
• El sistema parcial debe estar integrado,
validado y estabilizado en la fecha
programada —no se permite mover la fecha.
• Si nos damos cuenta de que va a ser difícil
cumplir el plazo, reduzcamos el alcance de la
iteración:
– hay que quitar tareas o requisitos de la iteración, e
incluirlos en una iteración futura.
44
La planificación es guiada
por los riesgos y por el cliente
• Los objetivos de las primeras iteraciones son
de tres tipos:
– identificar y reducir los riesgos más importantes;
– construir la funcionalidad visible más importante
para el cliente;
– construir, validar y estabilizar la arquitectura
central.
• Carecer de una arquitectura sólida es un
riesgo importante.
45