Introduccin A La Ingeniera de Softwarequ Es Un Buen Sistema13

1
Introduccin a la
Ingeniera de Software:
Qu es un Buen Sistema?
Adaptado de http://comunidad.uach.mx/fmarisc/analisis/Analisis.ppt
2
Ingeniera de Software
Qu es un BUEN SISTEMA?
Un buen sistema (o uno de alta calidad) es
aqul que cumple con las necesidades del
cliente. El sistema debe ser:
UTIL y UTILIZABLE: Un buen software hace ms fcil o
mejor la vida a las personas.
CONFIABLE: Un buen software tiene pocos errores.
FLEXIBLE: Las necesidades cambian con el tiempo, an
cuando el software se est desarrollando, entonces es
importante poder hacer cambios posteriores al software.
Debe podrsele dar mantenimiento despus de liberado.
3
Qu es un BUEN SISTEMA?
FLEXIBLE: Las necesidades cambian con el tiempo, an
cuando el software se est desarrollando, entonces es
importante poder hacer cambios posteriores al software.
Debe podrsele dar mantenimiento despus de liberado.
ACCESIBLE: tanto para comprar como para mantener. Debe
ser razonablemente fcil y rpido 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, bsqueda
de informacin, 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
tcnicas.
Generalmente, los sistemas no estn
actualizados ni cuando se estn diseando.

6
Problemas:
An existe el error de la computadora como
excusa a un mal servicio a los clientes.
La mayora de los usuarios de PCs esperan
que sus aplicaciones y an 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 tambin resulta
evidente, como lo muestran el problema del
milenio y la adecuacin 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 ms alto
costo asociado con el software

9
Problemas an ms drsticos.
A veces las fallas en algunos de los atributos
deseables de los sistemas han provocado
catstrofes 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 prdidas (1993)
10
Manejo de maletas de Denver: Fallas del sistema
y el alto costo de corregirlo, no permita al
aeropuerto abrir a tiempo.
Sistema de Ambulancias de Londres: Fallas de
diseo y de ejecucin provocaron la muerte de
gente por falta de ambulancias (1992)
Therac-25: Sobredosis radioactivas por fallas en el
software de la mquina a varias personas (1987)
11
Segn W. Wayt Gibbs en Softwares chronic
crisis. Scientific American (International Ed.)
pp 72-81, Sep. 1994. dice:
En promedio, los proyectos grandes toman 50%
ms 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 tecnologa promete reducir los
tiempos de desarrollo e incrementar los
promedios de xito de los proyectos.
Todos lo dudamos.
13
Promesas, promesas
Segn Frederick P. Brooks (The mythical
man-month, Addison-Wesley 1975/1995),
mientras ms grande sea el proyecto, mayor
ser la proporcin del costo y tiempo del
proyecto gastado en la comunicacin entre la
gente del proyecto, porque cada persona
tiene ms gente con quin comunicarse.
Cuando un proyecto empieza a quedarse
atrs en el tiempo, el poner ms gente por lo
general falla.
14
Promesas, promesas
El Departamento de Defensa de EU, intent
resolver la crisis del software y comision el
diseo del lenguaje de programacin ADA, el
cual se estandariz en 1983, el cual
soportaba lo mejor de los conceptos de
anlisis, diseo y programacin
estructurados, la modularidad y la
encapsulacin fueron conceptos clave en el
diseo del lenguaje, pero an esta enorme
inversin ha fracasado.
15
Cmo son los sistemas considerados
buenos?
El problema fundamental para comprenderlos
es:
Hay un lmite de cunto puede entender un
humano en un momento dado
16
buenos?
Los sistemas pequeos, son realizados
mediante programacin heroica en la cual
una sola persona pretende recordar todo lo
relevante acerca del sistema. Pero en general
esto es imposible.
17
buenos?
La evolucin del entendimiento de un
problema seria como sigue:
1.- Los sistemas son muy complejos y no se
puede centrar solo en el cdigo cercano al cambio
por realizar sino que se debe entender partes ms
lejanas.
18
buenos?
2.- Un sistema es un conjunto de mdulos y
existen algunas dependencias entre ellos. En el
sentido ms general, un mdulo puede ser
cualquier bit identificable de un sistema por lo
cual tiene sentido considerarlo en forma separada.
19
buenos?
Los mdulos pueden ser:
Archivos
Subrutinas
Funciones de biblioteca
Clases, en un lenguaje orientado a objetos.
Otras partes conocidas como mdulos o similares
Programas o subsistemas independientes o semi-
independientes.
20
buenos? (cont.)
Caractersticas de los mdulos para que el
desarrollo y mantenimiento del sistema sea lo
ms fcil, barato y confiable posible:
dependencia (dependency)
cohesin (cohesion) Alta
21
buenos? (cont.)
interfase (interface) Definida
Encapsulacin (encapsulation) Mdulos
abstraccin (abstraction)
Componente (component) Insertable,
reusable
Acoplamiento (coupling) Bajo

22
Si El mdulo A depende del mdulo B si un
cambio en el mdulo B significa que el
mdulo A tambin necesita ser modificado.
La dependencia es conocida a veces como
acoplamiento. Un sistema con muchas
dependencias tiene un acoplamiento grande.
Los sistemas buenos tienen un acoplamiento
bajo, porque los cambios a una parte del
sistema son menos propensos a propagarse
a travs del sistema
23
Encapsulamiento: Acoplamiento bajo
Queremos minimizar el numero de casos en
los cuales un cambio a un mdulo genera un
cambio en otro mdulo.
Tenemos que conocer cuales cambios dentro
de un mdulo pueden afectar el resto del
sistema.

24
Para tomar ventaja del acoplamiento bajo de
un sistema, es importante ser capaz de
identificar cuales mdulos estn acoplados,
de otra forma se tendr que gastar esfuerzo
verificando si hay que hacer cambios a un
mdulo, lo cual es un costo an cuando no
fue necesario el cambio. Nos gustara tener
certeza sobre los cambios.
25
Una vez que las fronteras entre los mdulos
de nuestro sistema estn definidas, hay dos
clases de informacin que puede ser til:
1.- Qu suposiciones de un mdulo dado pueden
los clientes hacer acerca de l? Contestando, nos
permitir conocer que clase de cambios a un
mdulo pueden ser peligrosos (servicios que
provee?)
26
2.- Cules mdulos son clientes de un mdulo
dado? Contestando, nos dice cules mdulos
tendrn que cambiar, si hacemos un cambio
peligroso a un mdulo.
27
(Cont.)
Interfases
Una interfase a un mdulo define algunas
caractersticas del mdulo sobre las cules sus
clientes pueden depender.
28
(Cont.)
Interfases
El resto del sistema solo puede usar el mdulo en
formas permitidas por las interfases; esto es, una
interfase ENCAPSULA el conocimiento acerca de
los mdulos. Las conexiones entre mdulos son
las suposiciones que hacen los mdulos unos
acerca de otros
29
(Cont.)
Interfases
Cualquier suposicin que un cliente hace acerca
de un servidor corre el riesgo de ser incorrecta;
entonces debemos documentar tales suposiciones
en interfases y verificar su validez.

30
(Cont.)
Interfases
Si documentamos bien todas las suposiciones en
la interfase, seremos capaces de decir: Si un
mdulo cambia internamente sin cambiar su
interfase, este cambio no necesitar otros cambios
en otras partes del sistema.
31
(Cont.)
Interfases
Idealmente debera haber una verificacin
automtica de que otros mdulos no hacen
suposiciones que no estn documentadas en esta
interfase, y tambin de que el mdulo siempre
justifica las suposiciones que estn
documentadas.
32
(Cont.)
Interfases
En un lenguaje de programacin, mientras ms
permita que esas verificaciones sean automticas,
se dice que ms soporta la modularidad y la
encapsulacin.
33
(Cont.)
Dependencias del contexto
Existen varias razones para querer conocer no
solo qu dependencias pudieran existir (esto es,
qu caractersticas estn documentadas en las
interfases de los mdulos del sistema) sino
tambin qu dependencias existen realmente.
34
(Cont.)
Sabemos que un cambio en un mdulo puede
afectar a sus clientes; sus clientes (por definicin)
son aquellos mdulos que pueden necesitar un
cambio, entonces es importante ser capaz de decir
cules son ellos.
35
(Cont.)
Suponga que quiere reusar un mdulo. Es
necesario saber no solo qu servicios provee (cual
es su interfase) sino tambin qu servicios
requiere para trabajar. Los servicios que un
mdulo requiere son llamados sus dependencias
de contexto. Ellos pueden a su vez ser expresados
en trminos de interfases; el mdulo puede
garantizar que si ciertas interfases le son
provistas, entonces l a su vez proveer sus
propias interfases.
36
(Cont.)
Entre ellos, las dependencias de contexto de un
mdulo y la propia interfase del mdulo garantiza
que proveer los servicios descritos en su
interfase.
37
(Cont.)
Beneficios de la modularidad con interfases
definidas.
An una interfase muy pobre para un mdulo
incorrectamente seleccionado puede hacer a un
sistema ms fcil de entender y modificar.
Porqu?

38
Encapsulamiento: Acoplamiento bajo (Cont.)
Cualquier elemento que reduzca lo que tiene que ser
conocido acerca de un mdulo es benfico en varias
formas:
En un equipo de desarrollo, la gente desarrollando cdigo
que usa un mdulo, solo deber entender la interfase del
mdulo, no cmo trabaja, entonces seran ms productivos.
Debido a que los desarrolladores pueden ignorar en forma
segura algunos aspectos del sistema, tendrn un mejor
entendimiento de los aspectos que s necesitan conocer,
entonces se introducirn menos errores.
39
(Cont.)
Los errores debern ser ms fciles de encontrar (en
desarrollo y mantenimiento), porque se evitar el examinar
mdulos irrelevantes.
Una vez que existe un mdulo, con documentacin de lo
que provee y lo que requiere, es posible considerar
reusarlo.
El reto real, es definir buenos mdulos con las cosas
correctas en sus interfases. Solo entonces se
pueden lograr los beneficios completos.
40
(Cont.)
Un mdulo puede tener varias interfases
A veces es necesario documentar los servicios
que un mdulo provee con varias y diferentes
interfases, de un modo que podamos ser ms
precisos acerca de que servicios un cliente dado
necesita. Esto es a la vez til para el
mantenimiento y para el reuso.
41
(Cont.)
Ya tenemos una respuesta parcial a la pregunta
de Cmo son los sistemas considerados
buenos?

Un buen sistema consiste de mdulos
encapsulados
42
Abstraccin: Alta Cohesin.
Los buenos mdulos tienen la propiedad de que sus
interfases proveen una abstraccin de alguna cosa
que se entiende intuitivamente la cual sin embargo
puede ser compleja de implantar. Tales mdulos se
dice que tienen una alta cohesin.
La interfase realiza una abstraccin de las cosas que
el desarrollador no tiene que entender para usar el
mdulo, dejando una figura coherente de lo que el
usuario de un mdulo quiere conocer.
43
El desarrollador est protegido de informacin
irrelevante acerca de cmo el mdulo hace lo que
hace. Esta preocupacin de permitir al desarrollador
concentrarse en lo esencial es ligeramente diferente
a la preocupacin de encapsulacin para lograr un
acoplamiento bajo, lo cual va dirigido a la prevencin
de que el desarrollador use informacin escondida.
44
Abstraccin es cuando un cliente de un mdulo
no necesita saber ms de lo que est en la
interfase.
45
Encapsulacin es cuando un cliente de un
mdulo no es capaz de conocer ms de lo que
est en la interfase.
Si un mdulo, de cualquier tamao y complejidad, es
una buena abstraccin (tiene una alta cohesin y un
acoplamiento bajo) puede ser factible de reusarlo en
posteriores sistemas, o de reemplazo en sistemas ya
existentes.
Estaramos hablando de un componente insertable o
conectable (pluggable component)
46
Arquitectura y componentes
La arquitectura donde se desarrolla y aquella
dnde se va a usar.
En los 80s y principios de los 90s, la
tecnologa orientada a objetos iba a ser la
solucin a la crisis en desarrollo de software.
47
Componente
Es una cosa que se puede reusar o reemplazar
Desarrollo Basado en Componentes (CBD,
Component Based Development)
Un mdulo con propiedades que lo hacen
reusable y reemplazable.
48
Qu determina cuando un mdulo es reusable?
Tiene una cohesin alta
Acoplamiento bajo con el resto del sistema
Interfase bien definida
Abstraccin encapsulada de una cosa bien entendida
49
Si un mdulo es reusable depende del contexto en
que se desarroll y en el cual va a ser reusado.
Ejemplo de un factor no tcnico de reuso:
Recompensar al programador por el nmero de
lneas que escriben.
Los factores tcnicos involucran decisiones de
arquitectura y ms alto nivel.
50
Diseo basado en componentes:
Insertabilidad, conectabilidad (pluggability)
La forma ideal de construir un nuevo sistema
es tomar algunos componentes existentes y
juntarlos.
51
Los componentes tienen que ser partes que
llenan o cumplen necesidades en un sistema
completo.
Las partes tienen que ser compatibles unas
con otras y eso depende de la presencia de
una arquitectura adecuada.
52
Las decisiones importantes acerca de la
arquitectura:
Deben ser tomadas lo ms pronto en el proyecto.
Son afectadas por la naturaleza de los
componentes en la arquitectura
Pueden ser influenciadas por el medio ambiente
del proyecto
53
Cmo 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)
54
sistemas?
Preocuparse por cumplir con un conjunto
claro de requerimientos, que se definen tan
pronto como sea posible
Preocuparse por formas de verificacin y
validacin, tan esenciales como construir el
producto en s mismo.
55
sistemas?
Usar un almacn de CONOCIMIENTOS,
ARQUITECTURAS y COMPONENTES
relevantes.
Hacer un uso sensible de herramientas.
56
Proceso de desarrollo
Mtodo tradicional para el desarrollo de
Sistemas (Cascada / Waterfall)

Anlisis
Diseo
Implementacin
Pruebas
Mantenimiento
57

Cada fase se realiza hasta que se complet la
anterior. Supone que no se vuelve a entrar en
las fases terminadas.

Anlisis
Diseo
Implementacin
Pruebas
Mantenimiento
58
Administracin de riesgos implica:
1.- Cada vez que se toma una decisin se tiene el riesgo de
que sea incorrecta. Mientras ms se tarde en detectar un error
ms difcil es corregirlo. Evaluaciones frecuentes ayudan a
corregir.
2.- Un riesgo mayor es que los desarrolladores malinterpreten
los requerimientos. La elaboracin de prototipos permite
reafirmarlos.
59
Espiral de desarrollo:

Metodologa Unificada.
Gran cantidad de metodologas orientadas a objetos han
salido a la luz y las de Grady Booch, James Rumbaugh, Ivar
Jacobson se unieron para formar el Lenguaje de Modelacin
Unificado (UML) y fue adoptado por el Object Management
Group (OMG) como el estndar para cuestiones orientadas a
objetos.
Anlisis
Diseo
Construccin
Transicin
60
Bibliografa
Bibliografa
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 Edicin 1999
Advanced Object-Oriented
Analysis & Design Using UML
James J. Odell Cambridge University Press. 1998
UML y Patrones. Introduccin al
anlisis y diseo orientado a
objetos.
Craig Larman Prentice Hall. 1999
Anlisis y Diseo de Sistemas Kendall & Kendall Prentice Hall. Pearson Educacin. Tercera
Edicin. 1995
UML gota a gota Martin Fowler con
Kendal Scott
Addison Wesley. Pearson. 1999

Introduccin A La Ingeniera de Softwarequ Es Un Buen Sistema13

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduccin A La Ingeniera de Softwarequ Es Un Buen Sistema13

Uploaded by

Copyright:

Available Formats

1

You might also like