presentación cva negocio

MARZO DE 2012

311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez

DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®

mailto:[email protected]



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 del software


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




Proceso de análisis y gestión de

requerimientos

Proceso de Diseño

Proceso de construcción

Proceso de pruebasProceso de entrega

versiones a PTI (Release)

Proceso de implantación

Proceso de desmonte de aplicativos

Gestionar ciclo de vida de las

aplicaciones

Ciclo de vida de Aplicaciones


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




Por qué el ciclo

de vida de

aplicaciones?


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




Básicamente, la crisis del software serefiere a la dificultad en escribirprogramas libres de defectos,fácilmente comprensibles, y que seanverificables. Las causas son, entre otras,la complejidad que supone la tareade programar, y los cambios a los que setiene que ver sometido un programa paraser continuamente adaptado a lasnecesidades de los usuarios.

Crisis de software


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




Este problema se identificó por primeravez en 1968, año en el que la OTANdesarrolló la primera conferencia sobredesarrollo de software, y en la que seacuñaron los términos “crisis delsoftware” para definir a los problemasque surgían en el desarrollo desistemas de software.

Crisis de software


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®


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.


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




Continuemos con

algunas cifras.


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




Crisis de software

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,

Proyectos para el desarrollo de sistemas de software

31%

40%

28%

23%

15%

18%

19%

24%

53%

33%

46%

49%

51%

53%

46%

44%

16%

27%

26%

28%

34%

29%

35%

32%

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

1994

1996

1998

2000

2002

2004

2006

2009


DH

SB

–2010 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




Evolución

0%

10%

20%

30%

40%

50%

60%

1994 1996 1998 2000 2002 2004 2006 2009

Fracasos 0%

10%

20%

30%

40%

50%

60%

1994 1996 1998 2000 2002 2004 2006 2009

Inferior

0%

10%

20%

30%

40%

50%

60%

1994 1996 1998 2000 2002 2004 2006 2009

Éxito

CVA


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®


Importancia de los requisitos

¿Porqué fracasan los proyectos?

Requisitos incompletos: 13%

Cambios en requisitos: 9%

No implicación de usuarios: 12%

Expectativas no realistas: 10%

Producto no necesario: 8%

TOTAL: 52%


DH

SB

–2010 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®


Importancia de los requisitos

Fase en la que se inyecta el

error

Costo de la

correcciónRequisitos

Arquitectura

Diseño detallado

Construcción

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

50-200X

1X

Fase en la que se soluciona el error

100-200X

1X


DH

SB

–2010 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




Siempre7%

Frecuentemente13%

Algunas veces16%

Rara Vez19%

Nunca45%

Características / funciones usadas en un sistema típico


DH

SB

–2010 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




REQUISITOS

Sus defectos repercuten en todas las fases

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

Validación y

verificación:

Terminado el

desarrollo del

sistema, si las

especificaciones

tienen errores de

bulto, o peor

aún, no están

reflejadas en una

especificación de

requisitos, no será

posible validar el

producto con el

cliente.

Los errores en los requisitos se comportan como una enfermedad contagiosa que

siempre repercute en todas las fases del proyecto.

Estimación:

No es posible

estimar con

rigor costos y

recursos

necesarios

para

desarrollar

algo que no

se conoce.

Planificación

: No se puede

confiar en la

planificación

para el

desarrollo de

algo que no

se sabe bien

como es.

Diseño: Los

errores en

requisitos, las

modificaciones

frecuentes, las

deficiencias en

restricciones o

futuras

evoluciones, prod

ucen

arquitecturas que

más tarde se

confirmarán

como erróneas y

serán

modificadas.

Construcción:

Las deficiencias

en los requisitos

obligan a

programar en

ciclos de prueba y

error que

derrochan horas y

paciencia de

programación

sobre patrones de

“recodificación

continua” y

“programación

heroica”.


DH

SB

–2010 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




Los defectos comunes en los

requisitos y sus consecuencias.

Implicación insuficiente

del cliente

Requisitos crecientes

y cambiantes

Requisitos ambiguos

Requisitos

innecesarios

Requisitos mínimos

(insuficientes)

Requisitos mínimos

(insuficientes)

Omisión de las necesidades

de grupos de usuarios

Problemas en la validación

del producto obtenido

Degradación de la estructura

y arquitectura del producto

Pérdida de tiempo en

re-codificación

Trabajo innecesario

Error en la estimación

y planificación

Usuarios insatisfechos


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




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


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




APL311 223 2534 - [email protected] Material preparado por Diego Hernan Sánchez

DH

SB

–2010 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




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.


DH

SB

–2010 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




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.

Beneficios de los buenos requisitos.


DH

SB

–2010 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




• 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óficos)

Importancia de las Pruebas de

Software


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




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

Costo de No probar


DH

SB

–2010 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®


Comparación No probar Vs. Probar

The Economic Impacts of Inadequate Infrastructure for

Software Testing - May 2002


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




Tiempo de afectación de clientes internos yexternos por fallas en los aplicativos y por lo tantoel tiempo de improductividad que esto genera.

Tiempo que los usuarios deben invertir enpruebas de aceptación.

Costos ocultos, como los generados por la pérdidade tiempo de los clientes y usuarios de losaplicativos y costos y tiempos de estabilización delos mismos.

Incidentes y solicitudes en la MIS relacionadoscon el mal funcionamiento de los aplicativos.


DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




APL


DH

SB

–2010 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®




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 - [email protected] Material preparado por Diego Hernán Sánchez

DH

SB

–2

01

0 -

RU

P®

es u

na m

arc

a r

egis

trada p

or

IBM

®


presentación cva negocio

Documents