CAP4-TEORIA EVALUACION DE CAUDALES - HIDROGRAMAS.pdf
Clase1.ppt
1. 1
Introducción a la
Ingeniería de Software:
Qué es un Buen Sistema?
Profesor: MSc. José Luis Alonso
Correo: jl.alonso@ce.pucmm.edu.do
2. 2
Ingeniería de Software
¿Qué es un BUEN SISTEMA?
Un buen sistema (o uno de alta calidad) es
aquél que cumple con las necesidades del
cliente. El sistema debe ser:
UTIL y UTILIZABLE: Un buen software hace más fácil o
mejor la vida a las personas.
CONFIABLE: Un buen software tiene pocos errores.
FLEXIBLE: Las necesidades cambian con el tiempo, aún
cuando el software se está desarrollando, entonces es
importante poder hacer cambios posteriores al software.
Debe podérsele dar mantenimiento después de liberado.
3. 3
Ingeniería de Software
¿Qué es un BUEN SISTEMA?
FLEXIBLE: Las necesidades cambian con el tiempo, aún
cuando el software se está desarrollando, entonces es
importante poder hacer cambios posteriores al software.
Debe podérsele dar mantenimiento después de liberado.
ACCESIBLE: tanto para comprar como para mantener. Debe
ser razonablemente fácil y rápido poderlo desarrollar o darle
mantenimiento.
DISPONIBLE: De otra forma no importa que tan bueno es.
Debe ser capaz de ejecutarse el el hardware disponible y
con el sistema operativo disponible, etc. Debe existir y
entregarse el software prometido.
4. 4
Ingeniería de Software
¿Tenemos buenos sistemas?
Existen avances satisfactorios en sistemas de
software modernos: contabilidad, bancos, búsqueda
de información, etc. Lo que indica que estamos
haciendo las cosas correctamente.
5. 5
Ingeniería de Software
Problemas:
Hay sistemas que no cumplen con las
necesidades de los usuarios y/o tienen fallas
técnicas.
Generalmente, los sistemas no están
actualizados ni cuando se están diseñando.
6. 6
Ingeniería de Software
Problemas:
Aún existe el “error de la computadora” como
excusa a un mal servicio a los clientes.
La mayoría de los usuarios de PCs esperan
que sus aplicaciones y aún el sistema
operativo se “caiga” o “congele” de vez en
cuando.
7. 7
Ingeniería de Software
Problemas:
EL SOFTWARE NO SIEMPRE ES
UTILIZABLE, ÚTIL, CONFIABLE O
DISPONIBLE.
La falta de FLEXIBILIDAD también resulta
evidente, como lo muestran el problema del
milenio y la adecuación de todos los sistemas
viejos (legacy) a procesos de negocios
cambiantes.
8. 8
Ingeniería de Software
Problemas:
La COSTEABILIDAD se relaciona mucho con
la confiabilidad y la flexibilidad debido a que
el costo de corregir y mantener es el más alto
costo asociado con el software
9. 9
Ingeniería de Software
Problemas aún más drásticos.
A veces las fallas en algunos de los atributos
deseables de los sistemas han provocado
catástrofes como las siguientes:
Ariane 5: Fallas de software hacen explotar la
nave (1996)
Taurus: Mercado accionario londinense no
pudieron terminar proyecto de software y tuvieron
grandes pérdidas (1993)
10. 10
Ingeniería de Software
Problemas aún más drásticos.
Manejo de maletas de Denver: Fallas del sistema
y el alto costo de corregirlo, no permitía al
aeropuerto abrir a tiempo.
Sistema de Ambulancias de Londres: Fallas de
diseño y de ejecución provocaron la muerte de
gente por falta de ambulancias (1992)
Therac-25: Sobredosis radioactivas por fallas en el
software de la máquina a varias personas (1987)
11. 11
Ingeniería de Software
Problemas aún más drásticos.
Según W. Wayt Gibbs en Software’s chronic
crisis. Scientific American (International Ed.)
pp 72-81, Sep. 1994. dice:
En promedio, los proyectos grandes toman 50%
más de tiempo de lo planeado;
75% de los proyectos grandes tienen fallas
operacionales;
25% de los proyectos grandes son cancelados
12. 12
Ingeniería de Software
Promesas, promesas
Cada nueva tecnología promete reducir los
tiempos de desarrollo e incrementar los
promedios de éxito de los proyectos.
Todos lo dudamos.
13. 13
Ingeniería de Software
Promesas, promesas
Según Frederick P. Brooks (The mythical
man-month, Addison-Wesley 1975/1995),
mientras más grande sea el proyecto, mayor
será la proporción del costo y tiempo del
proyecto gastado en la comunicación entre la
gente del proyecto, porque cada persona
tiene más gente con quién comunicarse.
Cuando un proyecto empieza a quedarse
atrás en el tiempo, el poner más gente por lo
general falla.
14. 14
Ingeniería de Software
Promesas, promesas
El Departamento de Defensa de EU, intentó
resolver la crisis del software y comisionó el
diseño del lenguaje de programación ADA, el
cual se estandarizó en 1983, el cual
soportaba lo mejor de los conceptos de
análisis, diseño y programación
estructurados, la modularidad y la
encapsulación fueron conceptos clave en el
diseño del lenguaje, pero aún esta enorme
inversión ha fracasado.
15. 15
Ingeniería de Software
¿Cómo son los sistemas considerados
buenos?
El problema fundamental para comprenderlos
es:
Hay un límite de cuánto puede entender un
humano en un momento dado
16. 16
Ingeniería de Software
¿Cómo son los sistemas considerados
buenos?
Los sistemas pequeños, son realizados
mediante “programación heroica” en la cual
una sola persona pretende recordar todo lo
relevante acerca del sistema. Pero en general
esto es imposible.
17. 17
Ingeniería de Software
¿Cómo son los sistemas considerados
buenos?
La evolución del entendimiento de un
problema seria como sigue:
1.- Los sistemas son muy complejos y no se
puede centrar solo en el código cercano al cambio
por realizar sino que se debe entender partes más
lejanas.
18. 18
Ingeniería de Software
¿Cómo son los sistemas considerados
buenos?
2.- Un sistema es un conjunto de módulos y
existen algunas dependencias entre ellos. En el
sentido más general, un módulo puede ser
cualquier “bit” identificable de un sistema por lo
cual tiene sentido considerarlo en forma separada.
19. 19
Ingeniería de Software
¿Cómo son los sistemas considerados
buenos?
Los módulos pueden ser:
Archivos
Subrutinas
Funciones de biblioteca
Clases, en un lenguaje orientado a objetos.
Otras partes conocidas como módulos o similares
Programas o subsistemas independientes o semi-
independientes.
20. 20
Ingeniería de Software
¿Cómo son los sistemas considerados
buenos? (cont.)
Características de los módulos para que el
desarrollo y mantenimiento del sistema sea lo
más fácil, barato y confiable posible:
dependencia (dependency) baja
cohesión (cohesion) alta
21. 21
Ingeniería de Software
¿Cómo son los sistemas considerados
buenos? (cont.)
Interfase (interface) Definida
Encapsulación (encapsulation) Módulos
abstracción (abstraction)
Componente (component) Insertable, reusable
Acoplamiento (coupling) Bajo
22. 22
Ingeniería de Software
¿Cómo se construyen los buenos
sistemas?
Usar un PROCESO definido con FASES
claras, cada una de las cuales tiene un
PRODUCTO FINAL (puede ser un documento
o tal vez un prototipo)
23. 23
Ingeniería de Software
¿Cómo se construyen los buenos
sistemas?
Preocuparse por cumplir con un conjunto
claro de requerimientos, que se definen tan
pronto como sea posible
Preocuparse por formas de verificación y
validación, tan esenciales como construir el
producto en sí mismo.
24. 24
Ingeniería de Software
¿Cómo se construyen los buenos
sistemas?
Usar un almacén de CONOCIMIENTOS,
ARQUITECTURAS y COMPONENTES
relevantes.
Hacer un uso sensible de herramientas.
25. 25
Proceso de desarrollo
Método tradicional para el desarrollo de
Sistemas (Cascada / Waterfall)
Ingeniería de Software
Análisis
Diseño
Implementación
Pruebas
Mantenimiento
26. 26
Proceso de desarrollo
Cada fase se realiza hasta que se completó la
anterior. Supone que no se vuelve a entrar en
las fases terminadas.
Ingeniería de Software
Análisis
Diseño
Implementación
Pruebas
Mantenimiento
27. 27
Ingeniería de Software
Proceso de desarrollo
Administración de riesgos implica:
1.- Cada vez que se toma una decisión se tiene el riesgo de
que sea incorrecta. Mientras más se tarde en detectar un error
más difícil es corregirlo. Evaluaciones frecuentes ayudan a
corregir.
2.- Un riesgo mayor es que los desarrolladores malinterpreten
los requerimientos. La elaboración de prototipos permite
reafirmarlos.
28. 28
Proceso de desarrollo
Espiral de desarrollo:
Metodología Unificada.
Gran cantidad de metodologías orientadas a objetos han
salido a la luz y las de Grady Booch, James Rumbaugh, Ivar
Jacobson se unieron para formar el Lenguaje de Modelación
Unificado (UML) y fue adoptado por el Object Management
Group (OMG) como el estándar para cuestiones orientadas a
objetos.
Ingeniería de Software
Análisis
Diseño
Construcción Transición
29. 29
Bibliografía
Using UML. Software Engineering
with objects and Components
Perdita Stevens, Rob
Pooley
Addison Wesley. Updated Edition 2000.
http://www.dcs.ed.ac.uk/home/pxs/Book/
The Object-Oriented Thought
Process
Matt Weisfeld Sams Publishing, 2000
Aprendiendo UML en 24 Horas Joseph Schmuller Editorial Prentice Hall, Primera Edición 1999
Advanced Object-Oriented
Analysis & Design Using UML
James J. Odell Cambridge University Press. 1998
UML y Patrones. Introducción al
análisis y diseño orientado a
objetos.
Craig Larman Prentice Hall. 1999
Análisis y Diseño de Sistemas Kendall & Kendall Prentice Hall. Pearson Educación. Tercera
Edición. 1995
UML gota a gota Martin Fowler con
Kendal Scott
Addison Wesley. Pearson. 1999