![¿Qué es la Ingeniería de Software?
“La Ingeniería de Software es el área de las
ciencias de la computación que trata con la
construcción de sistemas de software, los
cuales son tan grandes y complejos que se
construyen con equipos de ingenieros”
[Ghezzi 91].
“Construcción multi-persona de software
multi-versiones” [Parnas 87].
Implica el uso de técnicas y prácticas
ingenieriles para alcanzar un resultado
previsible, en términos de proyecto y de
producto...](https://image.slidesharecdn.com/2-introduccionalaingdesoftware-120412105643-phpapp01/85/2-introduccion-a-la_ing_de_software-5-320.jpg)
2. introduccion a la_ing_de_software
- 1. Introducción
- 2. 1- Generalidades de la Ingeniería de Software. 2- Problemas con la Ejecución de Proyectos Grandes. 3- ¿Qué se Requiere?. 4- Características de la Ingeniería de Software. 5- Conclusiones.
- 3. - Si usted quiere contratar la construcción de su casa: ¿Qué le exigiría al Producto (casa)? ¿Qué le exigiría al Proyecto?
- 4. - ¿Eso es válido para cualquier casa? - Ingeniería de Software no es sinónimo de Desarrollo de Software....
- 5. ¿Qué es la Ingeniería de Software? “La Ingeniería de Software es el área de las ciencias de la computación que trata con la construcción de sistemas de software, los cuales son tan grandes y complejos que se construyen con equipos de ingenieros” [Ghezzi 91]. “Construcción multi-persona de software multi-versiones” [Parnas 87]. Implica el uso de técnicas y prácticas ingenieriles para alcanzar un resultado previsible, en términos de proyecto y de producto...
- 6. “ Es un proceso definido paso a paso, que facilita la especificación, el diseño, la implementación y las pruebas de una solución de software, para un conjunto de requisitos explícitos, de modo eficiente y eficaz” Esto requiere que al empezar el proceso se tengan: - Objetivos claros. - Planes para lograr los objetivos. - Procedimientos que implementan los planes. - Procedimientos de monitoreo y control de los planes. - Un ambiente conducente al logro de los objetivos.
- 7. Solucionar un problema de manera EFICAZ,…. y ojalá eficiente (en términos de costo y tiempo). Problema a Resolver: Saciar mi hambre cuando estoy en mi casa de campo…. 2.Júntense de a 2 personas y propongan una solución…. Tienen 5 minutos para eso. 3.Tres grupos presentarán la solución al curso.
- 8. Debemos analizar el problema antes de plantear una solución. No se debe plantear una solución en busca de un problema…. Escenario común. Debemos separar los problemas complejos en sub-problemas más simples. ◦ Asegurarse que las relaciones entre los sub- problemas están acotadas. No evitemos el cambio, administrémoslo.
- 9. Especifiquemos y controlemos la calidad del producto que se está desarrollando. Hay que desarrollar una visión compartida del proyecto… entre todos los involucrados. No perdamos de vista a los usuarios y a los clientes. Identifiquémoslos y modelémoslos (casos de uso) y validemos en forma permanente con ellos…. eso nos dará una comprensión completa y válida del problema. Guiemos el Proceso…. No vayamos a la deriva.
- 10. Tengamos en cuenta: Los objetivos y necesidades de los usuarios y de los clientes. La dedicación de los usuarios/clientes al proyecto (contraparte). El feedback periódico que el usuario/cliente espera tener, de parte del equipo desarrollador. Que distintos usuarios y/o clientes pueden tener requisitos encontrados (contradictorios), y que requieren ser alineados. Los temores/desconfianza del usuario…. El esfuerzo* de probar… Se requiere tiempo de los usuarios… y a veces se requieren “pruebas masivas”. El esfuerzo de aprender y de usar (incluir las actividades sin computador). El agrado/desagrado de uso del software. Esfuerzo*: Costo y tiempo (asociado al desarrollador y/o cliente) vinculado a la realización de una tarea.
- 11. Diseñemos algo implementable: ◦ Con tecnología accesible/disponible. ◦ Con costos aceptables. ◦ Con plazos adecuados. ◦ Con una buena relación “costo/beneficio”. El diseño casi siempre requiere de una contraparte válida (cliente y/o usuario) que opine sobre: ◦ Modelo de negocio que se propone con la solución de software. ◦ Factibilidad (técnica/social/económica/operativa) de ponerlo en producción en las instalaciones del cliente.
- 12. 1- Generalidades de la Ingeniería de Software. 2- Problemas con la Ejecución de Proyectos Grandes. 3- ¿Qué se Requiere?. 4- Características de la Ingeniería de Software. 5- Conclusiones.
- 13. La Ingeniería de Software tiene que ver principalmente con el desarrollo y evolución de sistemas grandes o complejos, donde: ◦ Software debe ser terminado a tiempo y dentro del presupuesto. ◦ Software debe tener niveles de desempeño, uptime y usabilidad aceptables. ◦ Software debe ser correcto, confiable, mantenible, escalable, flexible y robusto. La parte difícil es lograr todo esto en proyectos grandes o complejos, usualmente donde hay: ◦ Rotación de personal (en ambos bandos). ◦ Requisitos cambiantes. ◦ Cambios de tecnologías. ◦ Etc.
- 14. ¿Qué es un Proyecto Grande? • Windows NT 4.0 tiene entre 6 y 10 millones de líneas de código. • El Software del bombardero B2 tiene 3.5 millones. • Un switch telefónico típico tiene 2 millones. Para tener una idea de lo que es 1 millón de líneas de código (1MLOC): • 13.000 páginas (75 líneas por página). • 26 tomos de 500 páginas c/u. Para contratar a sus programadores, Microsoft les pide que hayan escrito código (que esté en producción) de al menos 20.000 líneas. Comprender y administrar soluciones de esa magnitud requiere de ayuda extra, requiere de Ing. de Software.
- 15. ¿Qué es un Proyecto Grande? • Windows Vista: - 1.200 desarrolladores aprox. - 2.400 testers aprox. Coordinar a un equipo de desarrollo de esa magnitud es un esfuerzo no trivial.
- 16. A pesar de que la industria del software es hoy en día uno de los motores de la economía mundial, numerosos problemas aún persisten... • El desarrollo del hardware siempre aventaja al software asociado a él. • La demanda por nuevos productos no puede ser satisfecha (diversidad de escenarios donde deben proveer servicio). • El software no es confiable por naturaleza (y somos cada vez más dependientes de él). • Los proyectos raramente terminan en las fechas previstas. • Los proyectos raramente terminan costando lo previsto. • Proyectos terminados que jamás se usan. • Proyectos que se usan pero usuarios altamente insatisfechos. • Costo exorbitante de mantenimiento.
- 17. Desarrollar Software NO ES FACIL. En casos extremos ... • Quiebra del productor del software. • Quiebra de los clientes que dependen del producto. • Pérdida de vidas humanas. Historias de Horror.... • El Bank of America proyectó US$23 M para un proyecto a 5 años. Se terminó gastando mas de US$60 M para finalmente abandonar el proyecto. Pérdidas totales estimadas en más de US$1000 M. • El bombardero B1 requirió US$ 1000 M más de lo proyectado para mejorar sus sistemas de defensa.
- 18. • AllState (seguros) comenzó en 1982 un proyecto de automatización integral de sus operaciones de 5 años de duración y US$8 M de presupuesto. Fue abandonado en 1993 después de gastar US$100 M. • Blue Cross (isapre norteamericana) perdió más de US$60 M en pagos incorrectos debido a un error en el software por el que habían pagado mas de US$200 M. • El 4 de Julio de 1996 un cohete Ariadne se desvió de su curso y explotó a 3700 m de altura. Causa: error de software. Parte de las conclusiones de la comisión investigadora afirma ... “... In the failure scenario, the primary technical causes are the Operand Error when converting the horizontal bias variable BH, and the lack of protection of this conversion which caused the SRI computer to stop”.
- 19. • Entre 1987 y 1995 a lo menos 6 pacientes fueron severamente heridos o muertos por un error en los sistemas del Therac-25 (acelerador lineal usado para administración de radioterapia). • Hay casos similares en Chile… Lamentablemente, los nombres de los implicados no pueden hacerse públicos.
- 20. Escala: Una sola persona no puede entenderlo todo. Complejidad: ◦ Requiere trabajo de equipo. ◦ Problemas de manejo de gente, coordinación, egos, motivación, recambios de personal (en ambos lados), cambios de expectativas (en ambos lados), etc. Cambio: Durante y después del desarrollo inicial. Vida: Años y décadas. Especificaciones Imprecisas: Ambigüedad, contradicciones, requisitos cambiantes.
- 21. 1- Generalidades de la Ingeniería de Software. 2- Problemas con la Ejecución de Proyectos Grandes. 3- ¿Qué se Requiere? 4- Características de la Ingeniería de Software. 5- Conclusiones.
- 22. • Burocracia (útil y efectiva, tediosa pero vital) – Manejo formal del proceso de desarrollo. – Documentación formal detallada tanto interna como externa: • puede pensarse en términos de contratos cliente/productor, etc. – Trazabilidad. • ¿de quién es este código? • ¿cuándo se agregó esta parte? – Manejo de configuración y control de versiones.
- 23. • Análisis cuidadoso del problema. – interactuando con el usuario • Diseño cuidadoso usando principios que han demostrado ser útiles. – abstracción, ocultamiento, modularización, etc. • Implementación cuidadosa. • Pruebas rigurosas. – procedimientos bien definidos de antemano • Planificación de largo plazo (mantenimiento)
- 24. Más que código: En un proyecto de software se genera, además del código, muchos otros documentos ... • Requisitos formales • Diseño de alto nivel • Diseño detallado • Plan y baterías de pruebas (tests) • Documentación de usuario • Documentación de desarrolladores • Estudios de factibilidad • Informes de marketing • Planes de mantenimiento • Informes de errores y correcciones • etc.
- 25. Ingeniero de Procesos Ingeniero de Calidad Analista de Requisitos Diseñador de Software Programador Verificador-Téster Gerente de Proyecto Gestor de Configuración del Software
- 26. 1- Generalidades de la Ingeniería de Software. 2- Problemas con la Ejecución de Proyectos Grandes. 3- ¿Qué se Requiere?. 4- Características de la Ingeniería de Software. 5- Conclusiones.
- 27. • Ataca problemas prácticos reales – La gente realmente quiere o necesita resolver estos problemas. • Genera soluciones razonables – En términos de eficacia, eficiencia, tiempos de desarrollo, costos, etc. • Tiene su base en la ciencia – Sus resultados son “o deberían ser” repetibles. – Usa modelos matemáticos. – Es área técnica bien entendida.
- 28. • Codifica el conocimiento – La experiencia de generaciones se escribe en enormes manuales (ej. Perry’s Handbook) y se organiza para ser reutilizada. • Establece responsabilidad profesional – Código de conducta. – Ética profesional. – Acreditación y monitoreo por parte de una sociedad profesional.
- 29. No es posible aplicar directamente metodologías usadas en la ingeniería de otros productos, porque hay varias diferencias importantes ... • El software no se manufactura, sino que se desarrolla o crea. – Control de calidad de distinta naturaleza. – Recursos humanos de distinta naturaleza. – Estructura de costos radicalmente distinta. • El software no se desgasta (idealmente)... ... pero sufre de envejecimiento.
- 30. • La mayoría de los proyectos implica partir casi de cero (no hay catálogos de componentes a disposición de los ingenieros). • Falencias más importantes (detectadas): – Procesos no son repetibles. – Modelos no aportan descripciones precisas. – Existe poca confiabilidad, tanto en el proceso como en el producto. – No se comparte la experiencia (codificación y reuso). – Hay una falta de entrenamiento continuo de los profesionales.
- 31. • Proceso de desarrollo de software – Para mejorar la situación es necesario mejorar el proceso. – Para mejorar el proceso es necesario hacerlo visible, definirlo y medirlo. - …. La IS tiene mucho que decir acá. • Administración y control de proyectos de software involucra: – Uso de métricas, recursos y tiempos. – Manejo del riesgo. – Manejo de los cambios (Software Configuration Management). – Control de la calidad.
- 32. • Análisis y especificación de requisitos – No queremos software que no se use. – No queremos usuarios descontentos. • Diseño de software - Queremos diseños que respeten los requisitos. - Queremos diseños realistas. • Verificación y validación – Queremos productos confiables. – Queremos productos que satisfagan las especificaciones. • Apoyo del computador – Queremos hacer todo esto de la manera más eficaz y eficiente posible.