PresentacióN Cva Negocio

DHSB – 2010 - RUP® es una marca registrada por IBM®

MARZO DE 2012

311 223 2534 - diegosanchez2002@gmail.com Material preparado por Diego Hernan Sánchez

Ciclo de vida del software

Periodo de tiempo que
comienza al concebir la idea de

un nuevo sistema de
software, y termina cuando este
se retira y deja de funcionar.


Ciclo de vida de Aplicaciones

Proceso de análisis y
gestión de
requerimientos

Proceso de desmonte
Proceso de Diseño
de aplicativos

Gestionar ciclo de
vida de las
aplicaciones

Proceso de Proceso de
implantación construcción

Proceso de entrega
versiones a PTI Proceso de pruebas
(Release)


Por qué el ciclo

de vida de
aplicaciones?

Crisis de software

Básicamente, la crisis del software se
refiere a la dificultad en escribir
programas libres de defectos,
fácilmente comprensibles, y que sean

verificables. Las causas son, entre otras,
la complejidad que supone la tarea
de programar, y los cambios a los que se
tiene que ver sometido un programa para
ser continuamente adaptado a las
necesidades de los usuarios.

Crisis de software

Este problema se identificó por primera
vez en 1968, año en el que la OTAN
desarrolló la primera conferencia sobre

desarrollo de software, y en la que se
acuñaron los términos “crisis del
software” para definir a los problemas
que surgían en el desarrollo de
sistemas de software.

1. El problema no es nuevo.
2. No somos los primeros en tener

este tipo de problemas.
3. Existen técnicas y herramientas
para enfrentarlo.


Continuemos con

algunas cifras.


Crisis de software
Proyectos para el desarrollo de sistemas de software

2009 24% 44% 32%

2006 19% 46% 35%

2004 18% 53% 29%

2002 15% 51% 34%

2000 23% 49% 28%

1998 28% 46% 26%

1996 40% 33% 27%

1994 31% 53% 16%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

El proyecto se aborta o el sistema no se llega a utilizar

Aumento de costos, agenda. Las funcionalidades no cubren las expectativas.

Proyecto realizado en el tiempo previsto, con los costes previstos, con la
funcionalidad esperada y ofreciendo un funcionamiento correcto.
Fuente: Standish Group Survey,


Evolución
Éxito
60%
50%
40%
30%
Inferior 20%
60% 10%

50% 0%
40% 1994 1996 1998 2000 2002 2004 2006 2009
30%
20%
10%
Fracasos 0%
60% 1994 1996 1998 2000 2002 2004 2006 2009
50%
40%
30%
20%
10%
0%
1994 1996 1998 2000 2002 2004 2006 2009
CVA

Importancia de los requisitos

¿Porqué fracasan los proyectos?

 Requisitos incompletos: 13%  Expectativas no realistas: 10%  TOTAL: 52%
 Cambios en requisitos: 9%  Producto no necesario: 8%
 No implicación de usuarios: 12%


Importancia de los requisitos

100-200X

50-200X

Fase en la que se inyecta el
error

Costo de la
Requisitos 1X
corrección
Arquitectura 1X

Diseño detallado

Construcción

Requisitos Arquitectura Diseño detallado construcción Producción

Fase en la que se soluciona el error


Características / funciones usadas en un
sistema típico Siempre
7%

Frecuentemente
Nunca 13%
45%

Algunas veces
16%

Rara Vez
19%


Sus defectos repercuten en todas las fases

Los errores en los requisitos se comportan como una enfermedad contagiosa que
siempre repercute en todas las fases del proyecto.
REQUISITOS

Estimación Planificación Diseño Construcción V&V

Estimación: Planificación Diseño: Los Construcción: Validación y
No es posible : No se puede errores en Las deficiencias verificación:

estimar con confiar en la requisitos, las en los requisitos Terminado el
rigor costos y planificación modificaciones obligan a desarrollo del
recursos para el frecuentes, las programar en sistema, si las
necesarios desarrollo de deficiencias en ciclos de prueba y especificaciones
para algo que no restricciones o error que tienen errores de
desarrollar se sabe bien futuras derrochan horas y bulto, o peor
algo que no como es. evoluciones, prod paciencia de aún, no están
se conoce. ucen programación reflejadas en una
arquitecturas que sobre patrones de especificación de
más tarde se “recodificación requisitos, no será
confirmarán continua” y posible validar el
como erróneas y “programación producto con el
serán heroica”. cliente.
modificadas.

Los defectos comunes en los
requisitos y sus consecuencias.

Implicación insuficiente
del cliente Problemas en la validación
Requisitos mínimos del producto obtenido
(insuficientes)

Requisitos mínimos Error en la estimación
(insuficientes) y planificación
Requisitos crecientes Degradación de la estructura
y cambiantes y arquitectura del producto
Pérdida de tiempo en
Requisitos ambiguos
re-codificación
Requisitos
Trabajo innecesario
innecesarios
Omisión de las necesidades
Usuarios insatisfechos
de grupos de usuarios


- Tiempo del usuario final
explicando nuevamente
que es lo que necesita.
- Tiempo del analista de
Requerimientos
, ajustando los
requerimientos.

- Tiempo de los
desarrolladores, ajustand
o programas.
- Tiempo de los Analistas
de pruebas, Volviendo a
probar.
- Tiempo de los usuarios
probando.
- Impacto al negocio.
- Costo de solucionar
errores en producción.


APL

Beneficios de los buenos requisitos.
Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo
que debe realizarse.
Unos requisitos bien elaborados y validados con el cliente evitan
descubrir al terminar el proyecto que el sistema no era lo que se
pedía.

Acuerdo entre desarrolladores, clientes y usuarios sobre los
criterios que se emplearán para su validación.
Resulta muy difícil demostrar al cliente que el producto
desarrollado hace lo que el pidió si su petición no está

documentada y validada por él.
Base objetiva para la estimación de recursos (coste, personal en
número y competencias, equipos y tiempo)
Si los requisitos no comprenden necesidades reales, las
estimaciones no dejan de ser elementales apuestas. Las
estimaciones en el fondo son cálculos de probabilidad que siempre
implican un margen de error; por esta razón disponer de la mayor
información posible reduce el error.


Beneficios de los buenos requisitos.
Definición clara de los atributos de calidad
(ergonomía, mantenibilidad, etc.)
Más allá de funcionalidades precisas, los requisitos
recogen atributos de calidad necesarios que en
ocasiones son desconocidos por los
desarrolladores, produciendo finalmente sistemas
sobredimensionados o con serias deficiencias de
rendimiento.

Eficiencia en el consumo de recursos: reducción de
la re-codificación, reducción de omisiones y
malentendidos.
Tener un conocimiento preciso de lo que hay que hacer
evita la prueba y error, repetición de partes ya
desarrolladas, etc.


Importancia de las Pruebas de
Software

• Las pruebas de software son una parte importante
pero muy costosa del proceso de desarrollo de
software. Pueden llegar a representar entre el 30 y

50% del costo total del desarrollo del software
[Myers, 2004]

• Sin embargo, los costos de las fallas en un software
en operación pueden llegar a ser mucho mayores
(catastróﬁcos)


Costo de No probar

Basado en encuestas a desarrolladores de software
usuarios nacionales, los costos anuales de una
infraestructura inadecuada para las pruebas de
software se estima que oscila entre US$ 22,2 a US$
59,5 miles de millones.

Tenga en cuenta que las estimaciones de impacto no
reflejan los "costos“ asociados con el software de misión
crítica donde un fallo puede llevar a costos muy
elevados, como la pérdida de vida o una falla catastrófica. La
cuantificación de los costes esta fuera del alcance del
estudio.
The Economic Impacts of Inadequate Infrastructure for
Software Testing - May 2002


Comparación No probar Vs. Probar

The Economic Impacts of Inadequate Infrastructure for
Software Testing - May 2002


 Tiempo de afectación de clientes internos y
externos por fallas en los aplicativos y por lo tanto
el tiempo de improductividad que esto genera.

 Tiempo que los usuarios deben invertir en
pruebas de aceptación.
 Costos ocultos, como los generados por la pérdida
de tiempo de los clientes y usuarios de los
aplicativos y costos y tiempos de estabilización de
los mismos.
 Incidentes y solicitudes en la MIS relacionados
con el mal funcionamiento de los aplicativos.


Beneficios de los buenas pruebas.

Beneficios de los buenas pruebas
Detectar fallos.
Evitar software de baja calidad.
Evitar baja productividad e
insatisfacción al cliente.

Verificar que todos los requisitos se
han implementado correctamente.
Identificar y asegurar que los
defectos encontrados se han
corregido antes de entregar el
software al cliente

311 223 2534 - diegosanchez2002@gmail.com Material preparado por Diego Hernán Sánchez

PresentacióN Cva Negocio

Recomendados

Recomendados

Más contenido relacionado

Similar a PresentacióN Cva Negocio

Similar a PresentacióN Cva Negocio (20)

PresentacióN Cva Negocio