INGENIERÍA DE

SOFTWARE

Implementación de Sistemas
¿PROBLEMAS?

I N G .
P E R C Y
C A L I Z A Y A
• FAA Advanced Automation System [$3-6B]

• IRS Modernization Program [$4B]

• Denver Baggage System [$200M] 2

U N I
• Mars Program losses

F I I S
• Hubble and Webb space telescopes

• Dreamliner (Boeing 787)

• Obamacare website at rollout

• B737 MAX
D I F I C U LTA D E S D E L S O F T WA R E

I N G .
P E R C Y
C A L I Z A Y A
• Jefe del Comando de Sistemas AF: “El software es el talón de Aquiles del desarrollo de
armas”.

• 7 de cada 10 programas principales de desarrollo de armas se encuentran con problemas 3

de software y la tasa está aumentando.

U N I
• La tasa de falla o cancelación de grandes proyectos de software es más del 20%.

F I I S
• El 65 % de los grandes proyectos de software (más de 1 000 000 LOC) se cancelan antes
de completarse.

• En EE.UU. en promedio un proyecto cancelado tiene un año de retraso y ha consumido el

200 % del presupuesto esperado.
D I F I C U LTA D E S D E L S O F T WA R E

I N G .
P E R C Y
C A L I Z A Y A
• De los proyectos completados:
• 2/3 experimentan retrasos en el cronograma y sobrecostos (¿malas estimaciones?)
• 2/3 experimentan problemas de baja confiabilidad y calidad en el primer año de implementación
4

U N I
F I I S
P R E G U N TA S

I N G .
P E R C Y
C A L I Z A Y A
• ¿Alguna vez ha estado en un proyecto en el que el software nunca se terminó o usó?

• ¿Ha estado en un proyecto de ingeniería de sistemas que tuvo serias dificultades?

5

U N I
F I I S
A L G U N OS FACTO R E S C I TA D OS C O N
FRECUENCIA (1/2)

I N G .
P E R C Y
C A L I Z A Y A
• Sub-estimar la complejidad

• No establecer un control adecuado sobre los requisitos y/o el alcance

6
• Comunicación inadecuada

U N I
• No involucrar a las partes interesadas

F I I S
• Pruebas inadecuadas

• Falta de supervisión o mala gestión del proyecto

• Implementaciones de mala calidad

A L G U N OS FACTO R E S C I TA D OS C O N
FRECUENCIA (2/2)

I N G .
P E R C Y
C A L I Z A Y A
• Falta de gestión de riesgos

• No especificar/abordar los requisitos de desempeño

• Transiciones mal planificadas/gestionadas 7

U N I
• Proceso excesivo para prevenir problemas anteriores

F I I S
T I P OS D E P ROY E CTOS P RO B L E M ÁT I C OS

I N G .
P E R C Y
C A L I Z A Y A
• Misión imposible
Probabilidades de éxito, trabajadores felices

• Feo 8
Probabilidad de éxito, trabajadores descontentos

U N I
Kamikaze

F I I S
•
Es poco probable que tenga éxito, trabajadores felices

• Suicidio
Es poco probable que tenga éxito, trabajadores descontentos
PROYECTOS DE SOFTWARE CON MARCHA DE
LA MUERTE

I N G .
P E R C Y
C A L I Z A Y A
• Requerimientos complejos
• Sumisión del proyecto a otros proyectos o áreas
• Problemas de integración 9

• Sobre escritura del código fuente (problemas de gestión de la configuración)

U N I
F I I S
• Reestimación constante
• Rediseño y reescritura durante la prueba.
• No hay documentación de las decisiones de diseño.
• Etc.
 OBJETIVOS DE LA CLASE

I N G .
P E R C Y
• Los estudiantes podrán evaluar técnicas y enfoques de Ingeniería de Software

C A L I Z A Y A
“Es importante que los estudiantes traigan cierta irreverencia de andrajoso descalzo a sus estudios.
No están aquí para adorar lo conocido, sino para cuestionarlo.” Jacob Bronowski, The Ascent of Man
“Las teorías desarrolladas... rara vez se han sometido a pruebas empíricas, por lo que su valor sigue
10
siendo desconocido. Brindan a los fanáticos la oportunidad de comercializar una serie de seminarios
y cursos y de inundar la literatura con artículos que defienden las nuevas tecnologías. Cuando las

U N I
teorías se someten a prueba, la poca evidencia que se ha obtenido a veces sugiere que los supuestos

F I I S
beneficios, de hecho, pueden no existir.” Vessey and Weber

• Los argumentos pueden implicar:

Prueba intentar ser visto como efectivo, en palabra
Hipótesis no respaldadas
Falsas analogías
OBJETIVOS DE LA CLASE

I N G .
P E R C Y
C A L I Z A Y A
• Los argumentos pueden implicar:
Prueba por agitar vigorosamente la mano
Hipótesis no respaldadas
11
Falsas analogías

U N I
• Los estudiantes podrán ejercer su juicio profesional al seleccionar un enfoque para un

F I I S
proyecto en particular.
ASIGNACIONES

I N G .
P E R C Y
C A L I Z A Y A
• Sin programación ni proyectos de clase.

• Resúmenes de lectura semanales (2-3 páginas por artículo)

• Ideas principales o temas 12
• Evaluación crítica (tu opinión!!!)

U N I
• Cualquier pensamiento adicional

F I I S
 13

I N G . P E R C Y C A L I Z A Y A U N I F I I S
GRACIAS!
¿Por qué el software es
tan difícil?
 Preguntas de
discusión

• ¿Qué porcentaje del tiempo cree que se dedica a codificar en un

proyecto de software?

• ¿Es necesario mantener el software? No se “desgasta” como el

hardware, entonces, ¿por qué necesita mantenimiento?

Ing. Percy Calizaya UNI | FIIS 2

 Comprendiendo el
problema
Análisis
Diseño
Código
Pruebas
Mantenimiento

Los costos de desarrollo son como la punta

Ing. Percy Calizaya UNI | FIIS del iceberg 3
 Comprendiendo el
problema

COSTOS DEL DESARROLLO Planeamiento 1/3 Planeamiento

1/6 Código
Código
1/4 Pruebas de componentes
1/4 Pruebas del sistema
Pruebas

Ing. Percy Calizaya UNI | FIIS 4

 Comprendiendo el
problema II
Código
Planeamiento

Mantenimiento de software:
20% corrección de errores Pruebas
20% adaptaciones
60% mejoras Mantenimiento

La mayoría de los errores de software

detectados provienen de los
requisitos, no de su implementación
Ing. Percy Calizaya UNI | FIIS 5
 Leyes de
Mantenimiento
(Belady y Lehman)

• El software cambiará continuamente.

• El software se volverá cada vez más desestructurado a

medida que cambia.

Ing. Percy Calizaya UNI | FIIS 6

Costos de retrabajo por
defectos de software
médico
Fase del Proyecto Costo de búsqueda /
corrección defectos
Diseño – especificación $250
Código – integración 1,500
Pruebas de aceptación 45,000
Post producción 450,000

Ing. Percy Calizaya UNI | FIIS 7

 Preguntas de
discusión
• ¿Por qué crees que la ingeniería de software es difícil?

• ¿Es la ingeniería de software más difícil que la ingeniería de

hardware?

• ¿Por qué si o por qué no?

Ing. Percy Calizaya UNI | FIIS 8

 La revolución
informática
• Diseño separado de la representación física; el diseño se convirtió en un
concepto completamente abstracto.
Máquinas de Máquina de
Software propósito especial
propósito general
• Las máquinas que eran físicamente imposibles o poco prácticas de
construir se volvieron factibles
• El diseño se puede cambiar sin reequipamiento o remanufactura
• Énfasis en los pasos a lograr sin preocuparse de cómo se realizarán
físicamente los pasos

Ing. Percy Calizaya UNI | FIIS 9

 Preguntas de
discusión
• Si el software es solo diseño, ¿por qué no podemos encontrar
todos los errores de diseño de antemano mediante inspección
o prueba?

Ing. Percy Calizaya UNI | FIIS 10

 ¿Qué falló aquí?
• Los aviones de la Marina transportaban misiles de un lugar a otro.
• Un piloto ejecutó una prueba planificada apuntando a un avión al frente
y disparando un misil ficticio.
• Ninguno de los involucrados sabía que el software estaba diseñado para
sustituir un misil diferente si el que se ordenó disparar no estaba en una
buena posición.
• En este caso, había una antena entre el misil ficticio y el objetivo, por lo
que el software decidió disparar un misil real ubicado en una posición
diferente (mejor).

Ing. Percy Calizaya UNI | FIIS 11

¿Qué falló aquí?
• Cada componente funcionó según lo
previsto. Nada "falló".
• El problema estaba en el
diseño/requisitos del sistema.

Ing. Percy Calizaya UNI | FIIS 12

 Otro accidente sin fallas de
componentes
Módulo de aterrizaje polar de Marte
• Tienes que reducir la velocidad de la nave espacial para aterrizar de
manera segura
• Usar atmósfera marciana, paracaídas, motores de descenso (controlados
por software)
• El software sabe aterrizar debido a sensores sensibles en las patas de
aterrizaje. Apaga los motores cuando aterriza.
• Pero cierto “ruido” (señales falsas) generado por sensores cuando se abren
las piernas. No estaba en los requisitos de software.
• Se supone que el software no debe estar funcionando en ese momento,
pero los ingenieros de software decidieron comenzar temprano para
equilibrar la carga en el procesador.
• El software pensó que la nave espacial había aterrizado y apagó los
Ing. Percy Calizaya motoresUNIde
| FIISdescenso mientras aún se encontraba a 40 metros
13 sobre la
superficie.
 Accidente del
A320 en Varsovia
• El software protege contra la activación de los inversores de empuje cuando está en el aire.
• El hidroplaneo y otros factores hicieron que el software no pensara que el avión había
aterrizado
• Los pilotos no pudieron activar los inversores de empuje y se salieron del extremo de la
pista hacia una pequeña colina.

Ing. Percy Calizaya UNI | FIIS 14

 Otro accidente que involucra
inversores de empuje
• Tu-204, Moscú, 2012
• Vuelo 9268 de Red Wings Airlines
• El aterrizaje suave de 1,12 g hizo
contacto con la pista un poco más
tarde de lo habitual.
• Con el viento cruzado, esto
significó que los interruptores de
peso sobre ruedas no se activaron
y el sistema de empuje-reversa no
se desplegarían.

Ing. Percy Calizaya UNI | FIIS 15

 Otro accidente que involucra
inversores de empuje
• Los pilotos creen que los
inversores de empuje se están
desplegando como siempre. Con
el espacio limitado de la pista,
activan rápidamente la potencia
del motor para detenerse más
rápido. En cambio, esto acelera el
Tu-204 hacia adelante, y
finalmente choca con un terraplén
de la carretera.

Ing. Percy Calizaya UNI | FIIS 16

 Otro accidente que involucra
inversores de empuje
• En los sistemas complejos, las
consideraciones técnicas y
humanas no deben aislarse.

Ing. Percy Calizaya UNI | FIIS 17

 Problema en el ferry del
estado de Washington
• Los coches de alquiler no se podían
sacar de los transbordadores cuando
llegaban al puerto.
• La empresa local de alquiler de
automóviles instaló un dispositivo de
seguridad para evitar robos al desactivar
los automóviles si el automóvil se movía
cuando el motor se detenía
• Cuando el transbordador se movió y los
autos el motor funcionando, los autos se
deshabilitaron.

Ing. Percy Calizaya UNI | FIIS 18

 El problema es la
complejidad
• Ya no podemos:
• Planifique, comprenda, anticipe y proteja contra todo comportamiento no deseado del sistema
• Prueba exhaustiva para detectar todos los errores de diseño.
• El diseño de la automatización está creando nuevos tipos de "errores"
humanos
• Los enfoques tradicionales para lidiar con la complejidad son
inadecuados para estos sistemas.
• Descomposición Analítica
• Estadísticas

Ing. Percy Calizaya UNI | FIIS 19

 Abstracción del
Diseño Físico
• Los ingenieros de software están haciendo diseño físico.
Experto en
Ingeniero Diseño de Piloto
piloto Requerimientos de software Automático
automático

• La mayoría de los errores de software operativo relacionados con los requisitos (en
particular, la incompletitud)
• Los "modos de falla" del software son diferentes
• Por lo general, hace exactamente lo que le dices que haga.
• Los problemas ocurren por la operación, no por la falta de operación
• Usualmente haciendo exactamente lo que querían los ingenieros de software
Ing. Percy Calizaya UNI | FIIS 20
 La maldición de la
flexibilidad
• “El software es el lugar de descanso de las ideas tardías”
• Sin restricciones físicas
• Para hacer cumplir la disciplina en el diseño, la construcción y la modificación.
• Para controlar la complejidad
• Tan flexible que comienza a trabajar con él antes de comprender
completamente lo que debe hacer
• Los no entrenados pueden obtener un éxito parcial
• “Ampliar es difícil de hacer”
• “Y miraron el software y vieron que era bueno. Pero solo tenían que
agregar otra característica..."
Ing. Percy Calizaya UNI | FIIS 21
 Otros factores
• Grandes espacios de estados • Sin información histórica de uso
discretos • Para permitir la medición,
• Matemáticas continuas vs. discretas evaluación y mejora de los
• No se puede probar diseños estándar a lo largo del
exhaustivamente tiempo.
• Construido siempre de manera
• Intangibilidad especial
• Interfaces invisibles • Usualmente haciendo cosas
• Difícil de experimentar y administrar nuevas
• Problemas difíciles de diagnosticar

Ing. Percy Calizaya UNI | FIIS 22

 1/2
• La codificación es una pequeña parte del proceso de desarrollo
de software.
• Aproximadamente la mitad del esfuerzo de ingeniería de
software está en mantenimiento
• La mayoría de los errores de software presentados provienen
de requisitos defectuosos
• Cuanto antes se detecten los errores, más barato será
corregirlos, y los costos de corregirlos crecerán
exponencialmente con el tiempo.
Ing. Percy Calizaya UNI | FIIS 23
 2/2
• El software es puro diseño, separado de su representación
física
• La mayoría de los problemas en el desarrollo de software
provienen de su flexibilidad.
• Solo se puede probar una parte muy pequeña de la
funcionalidad del software.
• Las diferencias entre el software y el hardware son la
fuente de la mayoría de los problemas en la ingeniería de
sistemas complejos. Se necesitan nuevos enfoques.
Ing. Percy Calizaya UNI | FIIS 24
 Implementación de Sistemas

Gracias!

Ing. Percy Calizaya UNI | FIIS 25