Ingeniería de Software

Prof. Maria A. Pérez de Ovalles

mariapovalles@gmail.com
Objetivo
¡ Identificar, describir y establecer
relaciones entre los elementos
complejos del proceso de
desarrollo del software
Contenido
¡  Crisis de la Ingenieria de Software.
¡  Posibles causas.
¡  Razones de Exito
¡  Caracteristicas del Software como producto
¡  Roles en el proceso de desarrollo del Software
¡  Preguntas Frecuentes
¡  Mejores Practicas en el proceso de desarrollo de
software
¡  Calidad del Software
Crisis de la Ingenieria de
Software
¡  Nadie pone en duda la capacidad del ser humano para
desarrollar proyectos de ingeniería en general, con éxito.

¡  Por ejemplo, en USA, se planificó que el hombre llegara a

la luna en un plan de 10 años. Lo logró en 9.

¡  Durante esos años se desarrollaron 10.000 proyectos de

ingeniería.

¡  Ellos generaron mucho conocimiento al mundo. Por

ejemplo se desarrolla en toda su amplitud el estado
solido.

¡  En fin, estamos rodeados de muchos productos

(computadoras, vehículos, internet, metro, etc) que se
obtuvieron gracias al desarrollo de proyectos exitosos.
Crisis de la Ingenieria de
Software
¡  Sin embargo…..

¡  Con los proyectos de desarrollo de software, la

situación no ha sido tan exitosa….

¡  Veamos las cifras que nos da el Standish Group.

¡  Esta organización se dedica a hacer estudios

estadísticos sobre las organizaciones que
desarrollan software.

¡  Obviamente en países considerados del primer

mundo.
Crisis de la Ingenieria de Software
Estudio del Standish Group 2016

2011 2012 2013 2014 2915

Exitosos 29 27 31 28 29
Modificado 49 56 50 55 52
s
Fallaron 22 17 19 17 19

Fuente: Standish CHAOS Summary Report 2016

Crisis de la Ingenieria de
Software
¡  Saben lo que significa un éxito
del 29%???? 2915
Exitosos 29
¡  Imagínense que Ustedes se van
Modificado 52
a operar con un cirujano y le s
p r e g u n t a n : D r. C u a n t a s
operaciones suyas han sido Fallaron 19
exitosa? Y les responde un 29%

¡  Se operarían con ese Doctor?

¡  Esto es grave!
Crisis de la Ingenieria de
Software
¡  Están Ustedes conscientes de
que por cada proyecto que 2915
inicien, tiene solo un 29% de Exitosos 29
probabilidad de que lo Modificado 52
terminen de manera exitosa??? s

¡  Ojo estas son cifras del primer Fallaron 19

mundo!!!!

¡  E s p o r e l l o q u e n u e s t r a
profesión es altamente
estresante¡¡¡
Crisis de la Ingenieria de
Software
¡ Por qué sucede esto???
¡ El mismo Standish Group nos da
algunas pistas.
¡ Veamos sus estadísticas
 Posibles Causas
Razones de Fracaso

Especificaciones Incompletas 13.1

Falta de compromiso del Usuario 12,4
Falta de recursos 10,6
Expectativas no reales 9,9
Ausencia de soporte de la Alta Gerencia 9,3
Requerimientos Cambiantes 8,7
Ausencia de Planificación 8,1
Ausencia de Gestión de TI 6,2
Analfabetismo tecnológico 4,3

Fuente: Standish CHAOS Summary Report 2014

 Posibles Causas
Razones de Fracaso Nuevamente, si no
“especificamos” muy
Especificaciones Incompletas 13.1
bien que es lo que se
Falta de compromiso del Usuario 12,4
quiere construir.
Falta de recursos 10,6
Expectativas no reales 9,9
Desarrollamos los que
Ausencia de soporte de la Alta Gerencia 9,3 nos parece a nosotros.
Requerimientos Cambiantes 8,7 Ningún ingeniero civil
Ausencia de Planificación 8,1 construye un puente, si no
Ausencia de Gestión de TI 6,2 hace previamente todos
Analfabetismo tecnológico 4,3 los planos necesarios para
Fuente: Standish CHAOS Summary Report 2014
ello.
 Posibles Causas
Razones de Fracaso
Bueno el usuario tampoco
Especificaciones Incompletas 13.1 ayuda.
El cree que con darnos unas
Falta de compromiso del Usuario 12,4
“ideas” estamos listo.
Falta de recursos 10,6
Y por ello le cuesta colaborar.
Expectativas no reales 9,9 Debe estar comprometido con
Ausencia de soporte de la Alta Gerencia 9,3 el proyecto.
Requerimientos Cambiantes 8,7 En algunas organizaciones el
Ausencia de Planificación 8,1 Líder del Proyecto es el
Ausencia de Gestión de TI 6,2 usuario, para que le duela si el
Analfabetismo tecnológico 4,3 proyecto no sale a tiempo y
bien.
Fuente: Standish CHAOS Summary Report 2014
 Posibles Causas
Razones de Fracaso Nosotros tenemos mucha
culpa de esto.
Especificaciones Incompletas 13.1
Nos llama el cliente
Falta de compromiso del Usuario 12,4
pidiéndonos un sistema
Falta de recursos 10,6
Expectativas no reales 9,9
para llevar el control de
Ausencia de soporte de la Alta Gerencia 9,3 los pagos de una
Requerimientos Cambiantes 8,7 guardería.
Ausencia de Planificación 8,1 Y nosotros le proponemos
Ausencia de Gestión de TI 6,2 además una conexión on
Analfabetismo tecnológico 4,3 line para que los padres
Fuente: Standish CHAOS Summary Report 2014
puedan ver a sus bebes en
tiempo real (¿?)
 Posibles Causas
Razones de Fracaso

Especificaciones Incompletas 13.1

Si el cliente, alta gerencia
Falta de compromiso del Usuario 12,4
no le interesa el proyecto.
Falta de recursos 10,6
Expectativas no reales 9,9
El proyecto esta
Ausencia de soporte de la Alta Gerencia 9,3
condenado al fracaso.
Requerimientos Cambiantes 8,7 Ni lo intenten!!!
Ausencia de Planificación 8,1 Lo dice las cifras!!!
Ausencia de Gestión de TI 6,2
Analfabetismo tecnológico 4,3
Fuente: Standish CHAOS Summary Report 2014
Razones de Exito

¡ Pero el mismo Standish Group

nos dice que puede hacer que
el proyecto sea exitoso

¡ Veamos algunas cifras….

 Razones de Exito

Apoyo alta gerencia 15

Madurez Emocional 15
Requerimientos claros 13
Compromiso del usuario 15
Recursos calificados 10
Arquitectura Estándar 8
Proceso Ágil 7
Experiencia en Gestión 5
Staff trabajador 2,4
Objetivos del Negocio 5
claros
Fuente: Standish CHAOS Summary Report 2016
 Razones de Exito

Apoyo alta gerencia 15

Madurez Emocional 15 Obviamente, si
Requerimientos claros 13 La alta gerencia
Compromiso del usuario 15 quiere el proyecto
Recursos calificados 10 el proyecto va y
Arquitectura Estándar 8
tendrá todos los
recursos necesarios
Proceso Ágil 7
Experiencia en Gestión 5
Staff trabajador 2,4
Objetivos del Negocio claros 5

Fuente: Standish CHAOS Summary Report 2016

 Razones de Exito

Apoyo alta gerencia 15

Hay que especificar
Madurez Emocional 15 los requerimientos.
Requerimientos claros 13 Dedicaremos
Compromiso del usuario 15 muuuchas sesiones
Recursos calificados 10 para aprender a
Arquitectura Estándar 8 hacer esto bien.
Y lo llevaremos a la
Proceso Ágil 7
practica en los
Experiencia en Gestión 5
proyecto
Staff trabajador 2,4
Objetivos del Negocio 5
claros
Fuente: Standish CHAOS Summary Report 2016
 Razones de Exito

Apoyo alta gerencia 15

Atención con esto!!!
Madurez Emocional 15 El proyecto lo
Requerimientos claros 13 desarrollaremos de
Compromiso del usuario 15 manera ágil!!!
Recursos calificados 10 Es decir de manera
Arquitectura Estándar 8 iterativa, iterando.
En su debido
Proceso Ágil 7
momento explico
Experiencia en Gestión 5
esto
Staff trabajador 2,4
Objetivos del Negocio claros 5

Fuente: Standish CHAOS Summary Report 2016

¡  También influye en todo esto, que no estamos haciendo
hamburguesas…….

¡  Estamos construyendo un producto altamente

complejo…

¡  De un trabajo altamente intelectual….

¡  Y con la participación de personas que tienen diferentes

perspectivas de lo que se debe construir.

¡  Cliente, usuario, desarrollador, probador, líder del

proyecto, etc.
Caracteristicas del Software

¡  El Softwre es abstracto e intangible.

¡  Complejo

¡  El software se desarrolla no se fabrica en el sentido

clasico

¡  El software no se estropea

¡  La mayoría del software se construye a la medida,

en lugar de ensamblarse por componentes
¡  Como señale antes, cuando se construye un software se
compone un equipo de personas.

¡  Cada una tiene una responsabilidad y por lo tanto desea

que esa parte que le toca sea todo un éxito.

¡  Mas si el equipo no se comunica, no colabora y no

coopera, no hay éxito
Roles
Se necesita que alguien:

¡ Analize la aplicación que se desea desarrollar para

identificar los requerimientos que debe satisfacer.
Registre estos requerimientos de manera precisa y
bien documentada
¡ Diseñe la configuración del sistema determinando
funciones que implementará tanto el HW como el
SW. Seleccione los componentes básicos tanto de
HW como de SW.
Roles
¡ Analize el desempeño del sistema
propuesto para estar seguro que el
sistema cumplirá con los requerimientos
¡ Diseñe la estructura básica del software.
Lo dividira en componentes, definira las
interfaces de estos componentes y su
estructura interna
 Roles
¡ Implemente el software
¡ Integre el nuevo software con los existentes
¡ Ejecute pruebas sistemáticas del software y de todo
el sistema
¡ Revise y mejore los sistemas existentes manteniendo
su integridad y llevando la documentación exacta y
completa
¡ Sea responsable de la usabilidad, seguridad y
confiabilidad del software.
¡ Liderice el proyecto
Preguntas Frecuentes

¿Que es el Producto del software??

Programas más documentación

Preguntas Frecuentes

¿Cuáles son los atributos de

un buen software?

Debe proveer el desempeño deseado por el usuario

Desempeño, viene de la traducción de performance.

Performace es un calificativo holístico, sistémico integral.
Como cuando uno dice ese chico es buena persona
Preguntas Frecuentes

¿Que es la Ingenieria de Software?

Una disciplina de la ingeniería que se ocupa de la

producción de software
Preguntas Frecuentes

¿Cuáles son los mayores costos en la Ingeniería de

Software ?

60% desarrollo y 40% pruebas

Tipos de Software
¡ Aplicaciones (stand alone,
transaccionales, etc.)
¡ Embebidos
¡ Juegos, entretenimiento
¡ Simulación
¡ Expertos, inteligencia Artificial, analíticos
¡ Aplicaciones moviles etc.
¡ Ahora bien!.
¡ Durante estas cinco décadas de
desarrollo del software se ha concluido
que para construir un software exitoso se
deben seguir unas MEJORES PRACTICAS
¡ En esta materia aprenderemos algunas
de ellas y las pondremos en practica.
¡ Eso es hacer ingeniería de software!!!
Mejores Prácticas
¡  Desarrollar Software Iterativamente.
¡  Gestión de los Requerimientos.
¡  Usar arquitecturas basadas en
componentes.
¡  Modelar el software visualmente.
¡  Verificación continua de la calidad.
¡  Gestión de los cambios.
 Desarrollar Software Iterativamente
¡  Los malos entendidos se detectan al inicio.
¡  Facilita el feedback para elicitar requerimientos.
¡  El equipo se concentra en lo esencial.
¡  Evaluaciones continuas dan un estatus del proyecto
mas exacto.
¡  Las inconsistencias entre análisis, diseño e
implementación se detectan tempranamente.
¡  Permite una mejor gestión de los riesgos.
¡  Se aplican las lecciones aprendidas.
¡  El cliente ve resultados a corto plazo.
Gestión de Requerimientos
¡  Las comunicaciones se basan en
requerimientos definidos.
¡  Los requerimientos se priorizan y filtran.
¡  Se hace posible una evaluación de la
funcionalidad deseada.
¡  Se especifican muy bien los requerimientos
 Usar arquitecturas basadas en
componentes
¡  Conlleva a la modularidad.
¡  Facilita el uso de frameworks estándares (CORBA,
DOM, EJB, TOGAF).
¡  Uso de patrones de diseño
¡  Contribuye con el control de cambios.
¡  Existen herramientas que soportan la construcción
basada en componentes.
¡  Arquitecturas libres de errores.
 Modelar el Software Visualmente

¡  Disminuyen la ambigüedad.
¡  Los detalles no necesarios se ocultan.
¡  Se identifican arquitecturas no modulares e
inflexibles.
¡  Un gráfico dice mas que 1000 palabras.
 Verificación continua de la calidad
¡  Se hace una evaluación objetiva del estatus del
proyecto.
¡  Se detectan inconsistencias entre análisis, diseño
e implementación.
¡  Las pruebas se concentran en los aspectos de
mayor riesgo.
¡  Los defectos se identifican claramente, se
reducen los costos de su depuración.
 Gestión de los cambios
¡  Las solicitudes de cambios se logran con buena
comunicación.
¡  Las tasas de cambios arrojan información sobre el
desempeño del proceso.
¡  La propagación del cambio es controlada.
¡  Se mantiene una arquitectura robusta.
¡ Para cerrar, lo que queremos es
que ustedes aprendan a
construir software de calidad.

¡ Y c ó m o s e p r o d u c e u n
software de calidad???
Calidad del Software
¡ Cuando un proceso eficaz de
construcción de software se
aplica de manera que crea un
producto útil que proporciona
valor medible a quienes lo
producen y quienes lo utilizan
Calidad del Software

¡ C u a n d o u n p r o c e s o e f i c a z d e
construcción de software se aplica de
manera que crea un producto útil que
proporciona valor medible a quienes lo
producen y quienes lo utilizan
Calidad del Software
¡ C uando un proceso eficaz de
construcción de software se aplica de
manera que crea un producto útil
que proporciona valor medible a
quienes lo producen y quienes lo
utilizan
Calidad del Software
¡ Cuando un proceso eficaz de
construcción de software se
aplica de manera que crea un
producto útil que proporciona
valor medible a quienes lo
producen y quienes lo utilizan
Resumen
¡  Se explicó como es la situación de los PROYECTOS DE
DESARROLLO DE SOFTWARE

¡  Las CAUSAS DE SUS FRACASOS Y RAZONES que pueden

influir en su éxito.

¡  Se analizo un poco las CARACTERÍSTICAS que tiene el

software como producto.

¡  También se describió diferentes ROLES presentes en el

desarrollo de un software

¡  Se presentaron las MEJORES PRACTICAS, algunas de ellas

las aprenderemos en este curso

¡  Y se cerro con la definición de SOFTWARE DE CALIDAD