Clase1.ppt

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
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
 ¿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
 ¿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
 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
 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
 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
 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
 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
 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
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
 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
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
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
 ¿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
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
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
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
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
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
buenos? (cont.)
 Interfase (interface) Definida
 Encapsulación (encapsulation) Módulos
 abstracción (abstraction)
 Componente (component) Insertable, reusable
 Acoplamiento (coupling) Bajo

22
 ¿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
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
sistemas?
Usar un almacén de CONOCIMIENTOS,
ARQUITECTURAS y COMPONENTES
relevantes.
Hacer un uso sensible de herramientas.

25
 Proceso de desarrollo
Método tradicional para el desarrollo de
Sistemas (Cascada / Waterfall)
Análisis
Diseño
Implementación
Pruebas
Mantenimiento

26
Cada fase se realiza hasta que se completó la
anterior. Supone que no se vuelve a entrar en
las fases terminadas.
Análisis
Diseño
Implementación
Pruebas
Mantenimiento

27
 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
 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.
Análisis
Diseño
Construcción Transición

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

Clase1.ppt

Más contenido relacionado

Similar a Clase1.ppt (20)

Último (20)

Clase1.ppt