Clase DSW 2S

DESARROLLO
DE
SOFTWARE
Desarrollo de Software
Qu es Desarrollo de Software?
Es una disciplina o rea de la
informtica o ciencia de la computacin,
que ofrece conocimientos, tcnicas y
mtodos para desarrollar y mantener
software de calidad que resuelva
problemas de todo tipo.
Qu es Software de Calidad?
Software concordante con:
Los requisitos funcionales del cliente
Los estndares de desarrollo
reconocidos en la industria de software
mundial.
UN ENFOQUE DE
CALIDAD
PROCESO
MTODOS
HERRAMIENTAS
Desarrollo de Software como
Tecnologa Multicapa
Cualquier enfoque de ingeniera debe
apoyarse sobre un compromiso de
organizacin de calidad.
El fundamento de la desarrollo del software
es la capa de proceso.
Desarrollo de Software como
Tecnologa Multicapa
Los mtodos del desarrollo del software
indican cmo construir tcnicamente el
software.
Las herramientas de la ingeniera del
software proporcionan un enfoque automtico
o semi-automtico para el proceso y para los
mtodos.
Ingeniera de Software como
Tecnologa Multicapa
Qu es un Proceso de Software?
Conjunto de etapas con la
intencin de lograr un objetivo:
Proceso de Software
14
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.
15
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
hardware disponible y con el sistema operativo
disponible, etc. Debe existir y entregarse el
software prometido.
16
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.
17
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.
18
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.
19
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
20
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)
21
Problemas an ms drsticos.
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)
22
Promesas, promesas
Cada nueva tecnologa promete reducir los
tiempos de desarrollo e incrementar los
promedios de xito de los proyectos.
Todos lo dudamos.
23
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.
24
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.
25
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
26
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.
27
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.
28
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.
29
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.
30
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
31
Cmo son los sistemas considerados buenos?
(cont.)
interfase (interface)
Definida
Encapsulacin (encapsulation)
Mdulos
abstraccin (abstraction)
Componente (component)
Insertable, reusable
Acoplamiento (coupling) Bajo
32
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
33
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.
34
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.
35
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?)
36
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.
37
(Cont.)
Interfases
Una interfase a un mdulo define algunas
caractersticas del mdulo sobre las cules
sus clientes pueden depender.
38
Encapsulamiento: Acoplamiento bajo (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
39
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.
40
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.
41
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.
42
Interfases
En un lenguaje de programacin, mientras
ms permita que esas verificaciones sean
automticas, se dice que ms soporta la
modularidad y la encapsulacin.
43
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.
44
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.
45
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.
46
(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.
47
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?
48
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.
49
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.
50
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.
51
Ya tenemos una respuesta parcial a la
pregunta de Cmo son los sistemas
considerados buenos?
Un buen sistema consiste de mdulos
encapsulados
52
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.
53
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.
54
Abstraccin es cuando un cliente de un mdulo
no necesita saber ms de lo que est en la
interfase.
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)
56
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.
57
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.
58
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
59
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.
60
Diseo basado en componentes:
Insertabilidad, conectabilidad
La forma ideal de construir un nuevo sistema
es tomar algunos componentes existentes y
juntarlos.
61
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.
62
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
63
Cmo se construyen los buenos sistemas?
Desarrollar software es como construir un edificio:
hay mucho que hacer antes del verdadero
trabajo...
Planificar minuciosamente
Elegir materiales
Establecer y respetar una temporizacin
Inspeccionar frecuentemente la obra
Los errores son muy costosos de reparar
La dificultad depende del tamao
Los problemas de organizacin y gestin son tan
complicados como los problemas tcnicos
64
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)
65
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.
66
Usar un almacn de CONOCIMIENTOS,
ARQUITECTURAS y COMPONENTES
relevantes.
Hacer un uso sensible de herramientas.
Otra denominacin del Proceso de
Software
Al proceso de software tambin se le
conoce como Ciclo de Vida del Software
Proceso de Software
Fases Genricas
La Fase de Definicin Qu?
La Fase de Desarrollo Cmo?
La Fase de Mantenimiento - Cambio
Proceso de Software
Qu es un Modelo de Proceso de
Software?
Es una estrategia de desarrollo que los
ingenieros de software deben emplear
para resolver problemas de la industria de
software
Modelo de Proceso de
Software
Modelos de Procesos de Software
El problema es
seleccionar el modelo
de proceso de
software apropiado
para la ingeniera de
software que debe
aplicar el equipo de
proyecto
?
Modelos de Procesos de Software
Lineal Secuencial
Construccin de
Prototipos
RAD
Incremental
Espiral
Desarrollo
Concurrente
Ensamblaje de Componentes
D A P C
D A P C
D A P C
D A P C
Entrega 2
Entrega 1
Ent.3
Ent4
MODELO
INCREMENTAL
Construir y
revisar la
maqueta
Escuchar al
cliente
El cliente
prueba la
maqueta
MODELO DE
CONSTRUCCION
DE PROTOTIPOS
Anlisis Diseo Cdigo Prueba
MODELO
LINEAL
73
Proceso de desarrollo
Mtodo tradicional para el desarrollo de Sistemas
(Cascada / Waterfall)
Anlisis
Diseo
Implementacin
Pruebas
Mantenimiento
74
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
75
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.
76
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
FIN

Clase DSW 2S

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Clase DSW 2S

Enviado por

Direitos autorais:

Formatos disponíveis

DESARROLLO

Você também pode gostar