ingenieria de sofware

1. Ingeniería de Software
Principios de la
Ingeniería de Software

2. Principios básicos
 Rigor y formalidad
 Partición de decisiones
 Modularidad
 Abstracción
 Flexibilidad
 Generalidad
 Incrementabilidad
 Rastreabilidad
 Detección de errores
 Reproducibilidad

3. Rigor y formalidad
 Sin rigor es imposible reproducir el diseño y
difícil mantener el sistema.
 La formalidad implica rigor.
 Es necesario determinar qué mecanismos
conviene formalizar.

4. Partición de decisiones
 Permite afrontar diferentes aspectos del
mismo problema.
 Es la base para separar responsabilidades
entre los participantes.

5. Modularidad
 Permite aislar las partes del sistema para
analizarlas detalladamente.
 Se trabajan los detalles de cada parte sin
importar el resto.

6. Abstracción
 Permite concentrarse en los detalles
importantes y eliminar la información
irrelevante.
 Nos permite construir los modelos.

7. Flexibilidad
 Anticipación al cambio.
 El sistema debe adecuarse a nuevos
requerimientos.
 La metodología debe adecuarse rápidamente
a un nuevo requerimiento.

8. Generalidad
 Si es más general, la solución tiene más
potencial para ser reutilizada.
 Puede ser más costosa.
 Es una forma de anticiparse al cambio.

9. Incrementabilidad
 Define la producción de software como un
proceso evolutivo.
 Es importante la documentación en cada
paso.

10. Rastreabilidad
 Es necesario conocer el por qué de una
solución en particular.
 Permite “navegar” el proceso de desarrollo.

11. Detección de errores
 Un error puede permanecer latente y
evidenciarse en etapas posteriores del
desarrollo.
 Es indispensable detectar los errores lo antes
posible.

12. Reproducibilidad
 La fuerza de una metodología es el
aprendizaje sobre la solución planteada.
 Si no puedo reproducir, la metodología está
sobrando.

13. Ingeniería de Software
El desarrollo de Software
como proceso industrial

14. Características del software
 Se desarrolla, no se fabrica.
 Caduca, no se desgasta.
 No tiene historia.
 Puede ser desarrollado sin conocimientos de
ingeniería.
 Difícil interacción de los que participan en el
desarrollo.

15. El desarrollo de software
Herramientas
Proceso
Método
Arquitectura

16. Arquitectura (1 de 2)
 Es un conjunto de técnicas y conceptos.
 Define la estructura característica del
producto que se obtiene.

17. Arquitectura (2 de 2)
 Define el tipo de modelos a construir.
 Define las características que esos modelos
tendrán.

18. Método
 Explicita los pasos a seguir para obtener el
producto.
 Permite aplicar la Arquitectura en un
proyecto particular.
 Es concebido en función de la Arquitectura.

19. Proceso
 NO es lo mismo que el Método.
 Permite escalar el Método para aplicarlo en
proyectos con muchas partes involucradas.
 Es la proyección del Método en una
organización particular.

20. Herramientas
 Soportan diferentes aspectos del proyecto.
 Facilitan la aplicación del Método, para
obtener la estructura definida por la
Arquitectura.
 Apoyan la ejecución del Proceso.

21. Ingeniería de Software
Los modelos en la
Ingeniería de Software

22. Modelo
 Es una abstracción de algo que se extrae de
la realidad.
 Enfatiza las características mas interesantes.
 Omite los detalles no esenciales.

23. Abstracción (1 de 2)
 Es una capacidad humana.
 Es un examen selectivo de ciertos detalles
de un problema.
 Puede haber muchas abstracciones para una
misma cosa.

24. Abstracción (2 de 2)
 Para obtener una abstracción es
imprescindible un objetivo.
 Todas las abstracciones son incompletas e
imprecisas.
 Nos permiten limitar el universo a estudiar.

25. Por que modelamos?
 Para probar entidades físicas inmanejables.
 Para comunicarnos.
 Para visualizar una idea y depurarla.
 Para reducir la complejidad y los costos

26. Pruebas
 Muchas veces es imposible construir algo
para probar.
 Con un modelo es más factible controlar las
pruebas.
 Se pueden realizar pruebas tantas veces
como se quiera.

27. Comunicación
 Los modelos permiten utilizar un lenguaje
común.
 Formalizan la comunicación entre pares o
entre niveles de una organización.
 Sirven como documentación de las ideas.

28. Visualización
 Los modelos permiten corregir defectos
antes de construir el producto.
 Es posible descubrir detalles que se pasaron
por alto en el planteo original de la idea.

29. Reducción de costos
 Los modelos son mas baratos de construir.
 Se pueden deshechar sin problemas.
 Son mas simples que el producto final.

30. Lo que el usuario necesita

31. Lo que el usuario pide

32. Lo que el líder entiende

33. Lo que se diseña

34. El enfoque de programación

35. Recomendación de
consultores

36. El soporte operativo

37. El presupuesto

38. La implantación

39. La documentación

40. Conclusiones
 Es mas sencillo manipular modelos que las
entidades originales.
 Capturan lo esencial del problema y omiten
lo irrelevante.
 No existe un único modelo, existen modelos
adecuados e inadecuados.