Ingenieria Software

Una introduccin a
la Ingeniera del
software
Ian Sommerville
Traduccin: Ing. Otoniel Silva Delgado
Ing. Ivn Pino Tellera
Captulo 1
Introduccin
12/05/16
Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera
Objetivos
Introducir
la ingeniera de software y explicar su

importancia.
Partir de las respuestas para plantear preguntas
acerca de ingeniera de software.
Introducir los problemas ticos y profesionales y
explicar por qu ellos son de preocupacin para
los ingenieros del software.
12/05/16
Temas cubiertos
FAQs
sobre la ingeniera del

software.
El profesional y la responsabilidad
tica.
12/05/16
Ingeniera de software
Las economas de TODAS
las naciones
desarrolladas son dependientes en el software.
Cada
vez ms los sistemas son software
controlados.
La ingeniera de software se preocupa por las
teoras, mtodos y herramientas para el desarrollo
del software profesional.
El gasto en el software representa una parte
significativa del PNB en todos desarroll los pases.
12/05/16
Costos del software

Los
costos del software dominan a menudo los

costos de sistema de computadora. Los costos
de software en una PC son a menudo mayores
que el costo del hardware.
El costo de mantener software es mayor que el
costo hecho para desarrollarlo. Para los sistemas
con una vida larga, los costos de mantenimiento
pueden equivaler a varios costos de tiempo de
desarrollo
La ingeniera de software se preocupa por el
desarrollo del software rentable.
12/05/16
Preguntas ms frecuentes acerca

de la ingeniera de software
Qu
es software?
Qu es ingeniera de software?
Cul es la diferencia entre ingeniera de
software e informtica?
Cul es la diferencia entre ingeniera de
software y ingeniera de sistemas?
Qu es un proceso de software?
Qu es un modelo de proceso de software?
12/05/16
Preguntas ms frecuentes acerca

de la ingeniera de software
Cules
son los costos de la ingeniera de
software?
Cules son los mtodos de la ingeniera de
software?
Qu es CASE (Competer Aided Software
Engineering = Ingeniera de Software Asistida por
Computadora)?
Cules son los atributos de un buen software?
Cules son los desafos importantes que est
enfrentando la ingeniera del software?
12/05/16
Qu es software?
Programas de computadora y documentacin asociada como

los requisitos, modelos de diseo y manuales del usuario.
Los productos del software pueden desarrollarse para un cliente
particular o pueden desarrollarse para un mercado general.
Los productos del software pueden ser
Genrico: desarrollado para ser vendido a una gama de
diferentes clientes; por ejemplo el software de PC tales como
Excel o Word.
A la medida: desarrollado para un cliente particular de
acuerdo a sus especificaciones.
El nuevo software puede crearse desarrollando nuevos
programas, configurando sistemas de software genricos o
reusando software existente.
12/05/16
Qu es ingeniera de
software?
La
ingeniera de software es una disciplina

de la ingeniera que se preocupa por todos
los aspectos de produccin del software.
Los ingenieros del software deben adoptar
un acercamiento sistemtico y organizado a
su trabajo y usar las herramientas y
tcnicas apropiadas que dependen del
problema a ser resuelto, las restricciones de
desarrollo y los recursos disponibles.
12/05/16
10
Cul es la diferencia entre ingeniera

de software e informtica?
La
informtica se preocupa por la teora y

principios; la ingeniera de software se
preocupa por las viabilidades de desarrollar
y entregar software til.
Las teoras de la informtica todava son
insuficientes para actuar como un soporte
completo para la ingeniera de software
(diferente, por ejemplo, en el caso de la
fsica y la ingeniera elctrica).
12/05/16
11
Cul es la diferencia entre ingeniera

de software y ingeniera de sistemas?
La ingeniera de sistemas se preocupa por todos
los aspectos de desarrollo de sistemas basados en
computadora incluso el hardware, software e
ingeniera del proceso. La ingeniera de software es
parte de este proceso concerniente al desarrollo
de la infraestructura del software, control,
aplicaciones y bases de datos en el sistema.
Los ingenieros de sistemas estn envueltos en la
especificacin del sistema, diseo arquitectnico,
integracin y despliegue.
12/05/16
12
Qu es un proceso de
software?
Un conjunto de actividades cuya meta es el desarrollo o
evolucin de software.
Las actividades genricas en todos los procesos del software
son:
Especificacin:
lo que el sistema debe hacer y sus
restricciones de desarrollo.
Desarrollo: la produccin del sistema de software.
Validacin: verificacin de que el software satisface las
necesidades del cliente.
Evolucin: cambio del software en respuesta a las
demandas cambiantes.
12/05/16
13
Qu es un modelo de
proceso de software?
Una representacin simplificada de un proceso del

software, presentada de una perspectiva especfica.
Los ejemplos de perspectivas del proceso son
La perspectiva de Flujo de Trabajo: la sucesin de
actividades;
La perspectiva de Flujo de Datos: el flujo de
informacin;
La perspectiva de Rol/Accin: quin hace eso.
Los modelos del proceso genricos
Cascada;
Desarrollo iterativo;
Ingeniera de software basada en componentes.
12/05/16
14
Cules son los costos de la

ingeniera de software?
Aproximadamente el 60% de los costos son costos
de desarrollo, y el 40% son los costos de prueba.
Para el software de cliente, los costos de evolucin
exceden a menudo los costos de desarrollo.
Los costos varan dependiendo del tipo de sistema
que se desarrolla y los requerimientos de los
atributos del sistema como el desempeo y fiabilidad
del sistema.
La distribucin de costos depende del modelo de
desarrollo que se usa.
12/05/16
15
Distribucin de costos
de actividad
Modelo de cascada
0
100
25
Especificacin
50
Diseo
Desarrollo
75
Integracin y pruebas
Desarrollo iterativo
0
100
25
Especificacin
50
Desarrollo iterativo
75
Prueba del sistema
Ingeniera de software basada en componentes
0
100
25
Especificacin
50
Desarrollo
75
Integracin y pruebas
Desarrollo y evolucin de costos de largo tiempo de vida
0
400
100
Desarrollo del sistema

12/05/16
200
300
Evolucin del sistema

16
Costos de desarrollo del

producto
0
25
Especificacin
12/05/16
50
Desarrollo
75
100
Prueba del sistema
17
Cules son los mtodos de

la ingeniera de software?
Los acercamientos estructurados al desarrollo del software que

incluye a modelos del sistema, notaciones, las reglas, consejos
de diseo y gua del proceso.
Descripciones del modelos
Las descripciones de modelos grficos que deben producirse;
Reglas
Restricciones aplicadas a modelos del sistema;
Recomendaciones
Consejos en una buena prctica de diseo;
Gua de proceso
Actividades a llevar a cabo.
12/05/16
18
Qu es CASE (Competer Aided Software

Engineering = Ingeniera de Software
Asistida por Computadora)?
Sistemas
del software con pensadas para prestar

soporte automatizado a las actividades de proceso
de software.
Los sistemas CASE se usan a menudo para el
soporte del mtodo.
CASE de Alto Nivel
Herramientas para apoyar las actividades tempranas del

proceso de de requerimientos y diseo;
CASE
12/05/16
de Bajo Nivel
Herramientas para apoyar las actividades tardas tales

como programacin, depuracin y pruebas.
19
Cules son los atributos

de un buen software?
12/05/16
El software debe entregar la funcionalidad requerida y desempeo

para el usuario y debe ser mantenible, fidedigno y aceptable.
Mantenibilidad
El software debe evolucionar para satisfacer las necesidades
cambiantes;
Confiabilidad
El software debe ser fidedigno;
Eficiencia
El software no debe malgastador de recursos del sistema;
Aceptabilidad
El software debe aceptado por los usuarios para los cuales fue
diseado. Esto significa que debe ser entendible, utilizable y
compatible con otros sistemas.
20
Cules son los desafos importantes que

est enfrentando la ingeniera del software?
La heterogeneidad, entrega y confianza.
Heterogeneidad
Desarrollo de tcnicas para construir software que puede
cubrir con plataformas y ambientes de la ejecucin
heterogneas;
Entrega
Desarrollo de tcnicas que llevan a la entrega ms rpida
de software;
Confianza
Desarrollo de tcnicas que demuestren que el software
puede ofrecer confianza a sus usuarios.
12/05/16
21
El profesional y la
responsabilidad tica
La
ingeniera de software involucra las

responsabilidades
ms
amplias
que
simplemente la aplicacin de habilidades
tcnicas.
Los ingenieros del software deben comportarse
en un camino honrado y ticamente y as
sern respetados como profesionales.
La conducta tica va ms all de acatar
simplemente la ley.
12/05/16
22
Los problemas de
responsabilidad profesional
Confidencialidad
Los ingenieros normalmente deben respetar la

confidencialidad de sus empleadores o clientes
independiente de que haya o no un acuerdo
formal de confidencialidad que se haya firmado.
Competencia
Los ingenieros no deben falsear su nivel de
competencia. No deben aceptar trabajos que a
sabiendas estn fuera de su competencia.
12/05/16
23
Los problemas de
responsabilidad profesional
Leyes de propiedad intelectual
Los ingenieros deben ser conscientes de las leyes de
gobierno locales que legislan sobre el uso de propiedad
intelectual como las patentes, registros la propiedad de autor,
etc. Ellos deben tener el cuidado de asegurar que la
propiedad intelectual de empleadores y clientes est
protegido.
Mal uso de la computadora
Los ingenieros del software no deben usar sus habilidades
tcnicas para mal emplear las computadoras de otras
personas. Los gama de mal uso de computadora va desde
las relativamente triviales (jugar en la mquina de un
empleador) a las sumamente serias (la diseminacin de
virus).
12/05/16
24
Cdigo ACM/IEEE de tica
Las sociedades profesionales en los EE. UU. han

cooperado para producir un cdigo de prctica tica.
Los miembros de estas organizaciones acatan el
cdigo de prctica tica cuando ellos lo suscriben.
El Cdigo contiene ocho Principios relativos a a la
conducta y decisiones hechas por ingenieros de
software profesional, incluso practicantes, educadores,
gerentes, supervisores y fabricantes de plizas, as
como los aprendices y estudiantes de la profesin.
12/05/16
25
Prembulo al Cdigo de
tica
Prembulo
La versin corta del cdigo resume las aspiraciones a un nivel alto de
abstraccin; las clusulas que son incluidas en la versin completa
dan ejemplos y detalles de que cmo estas aspiraciones cambian la
manera que actuar de nosotros como profesionales de ingeniera de
software. Sin las aspiraciones, los detalles pueden ponerse legalistas
y tediosos; sin los detalles, las aspiraciones pueden parecer altos
pero vacos; juntos, las aspiraciones y los detalles forman un cdigo
cohesivo.
Los ingenieros de software se comprometern a hacer del anlisis,
especificacin, diseo, desarrollo, pruebas y mantenimiento de
software una beneficiosa y respetada profesin. De acuerdo con su
compromiso a la salud, seguridad y bienestar del pblico, los
ingenieros del software adherirn a los siguientes Ocho Principios:
12/05/16
26
Cdigo de tica - principios

EL PUBLICO
Los ingenieros del software actuarn de forma
consistente con el inters pblico.
EL CLIENTE Y EL EMPLEADOR
Los ingenieros del software actuarn de acuerdo
a los mejores intereses de sus clientes y
empleadores consistentes con el inters pblico.
EL PRODUCTO
Los ingenieros del software asegurarn que sus
productos y las modificaciones relacionadas
cumplen las normas profesionales ms altas
posibles.
12/05/16
27
12/05/16
EL JUICIO
Los ingenieros del software mantendrn integridad e
independencia en su juicio profesional.
LA GESTION
La ingeniera software, gerentes y lderes suscribirn
y promovern un acercamiento tico a la gestin de
desarrollo del software y mantenimiento.
LA PROFESION
Los ingenieros de software mejorarn la integridad y
reputacin de la profesin consistentes con el inters
pblico.
28

LOS
COLEGAS
Los ingenieros del software sern justos y
estarn a favor de sus colegas.
UNO MISMO
Los
ingenieros del software participarn
aprendiendo de toda la vida con respecto a la
prctica de su profesin y promovern un
acercamiento tico a la prctica de la profesin.
12/05/16
29
Dilemas ticos
La
discordancia entre los principios con las

polticas de mayor direccin.
Su empleador acta de una manera inmoral y
libera un sistema de seguridad crtico sin
terminar la comprobacin del sistema.
La participacin en el desarrollo de sistemas
de armas militares o sistemas nucleares.
12/05/16
30
Puntos clave
La ingeniera de software es una disciplina de la ingeniera que

se preocupa por todos los aspectos de produccin del software.
Los productos del software consisten en programas desarrollados
y la documentacin asociada. Los atributos del producto
esenciales son mantenibilidad, confiabilidad, eficiencia y utilidad.
El proceso del software consiste en actividades que estn
envueltas en el desarrollo de los productos del software. Las
actividades bsicas son la especificacin del software, desarrollo,
validacin y evolucin.
Los mtodos son maneras organizadas de producir software.
Ellos incluyen las sugerencias para el proceso a ser seguido, las
notaciones a ser usadas, reglas que gobiernan las descripciones
del sistema que se produce y las pautas de diseo.
12/05/16
31
Puntos clave
Las herramientas CASE son sistemas de software que se

disean para apoyar las actividades rutinarias en el proceso
de software tales como la edicin de los diagramas de
diseo, verificacin de consistencia de diagramas y el
seguimiento de las pruebas de programa que se han corrido.
Los ingenieros del software tienen las responsabilidades para
la profesin de la ingeniera y la sociedad. Ellos simplemente
no deben tener relacin con los problemas tcnicos.
Las sociedades profesionales publican los cdigos de
conducta que parten de las normas de conducta esperados
de sus miembros.
12/05/16
32
Captulo 2
Los Sistemas
Socio-tcnicos
12/05/16
33
Objetivos
12/05/16
Para explicar lo que es un sistema socio-tcnico y la

distincin entre ste y un sistema basado en
computadora.
Para introducir el concepto de propiedades de
sistemas emergentes como la fiabilidad y la seguridad.
Para explicar la ingeniera de sistemas y procesos de
obtencin de sistemas.
Para explicar por qu el contexto organizacional de
un sistema afecta su diseo y uso.
Para discutir los sistemas legados y por qu stos
son crticos para muchos negocios.
34
Tpicos cubiertos
Las
propiedades
del
sistema
emergentes
La ingeniera de sistemas
Las organizaciones, las personas y
sistemas de computadora
Los sistemas legados
12/05/16
35
Qu es un sistema?
Una determinada coleccin
de componentes
interrelacionados que trabajan juntos para lograr
algn objetivo comn.
Un sistema puede incluir componentes software,
mecnico, hardware elctrico y electrnico y ser
operado por personas.
Los componentes del sistema son dependientes en
otros componentes del sistema.
Las propiedades y el comportamiento de los
componentes
del
sistema
se
entremezclan
indisolublemente
12/05/16
36
Categoras de sistemas
Los sistemas tcnicos basados en computadora
Sistemas que incluyen hardware y software pero dnde
normalmente no se considera que los operadores y los
procesos operacionales son parte del sistema. El sistema no
se conoce a si mismo.
Los sistemas Socio-tcnicos
Sistemas que incluyen los sistemas tcnicos pero tambin
los procesos operacionales y las personas que usan y
actan recprocamente con el sistema tcnico. Los sistemas
Socio-tcnicos
son
gobernados
por
polticas
organizacionales y reglas.
12/05/16
37
Caractersticas de los
sistemas Socio-tcnicos
12/05/16
Las propiedades emergentes

Las propiedades del sistema de un todo que depende
de los componentes del sistema y sus interrelaciones.
No determinsticas
Ellos no siempre producen el mismo rendimiento
cuando present con la misma entrada porque el
comportamiento de los sistemas es parcialmente
dependiente en los operadores humanos.
Las relaciones complejas con los objetivos
organizacionales
Hasta que punto el sistema que apoya los objetivos
organizacionales no depende solamente del propio
sistema.
38
Propiedades emergentes
Las propiedades del sistema en conjunto en lugar
de propiedades que pueden derivarse de las
propiedades de componentes de un sistema.
Las
propiedades
emergentes
son
una
consecuencia de las interrelaciones entre los
componentes del sistema.
Ellos pueden
por consiguiente solamente ser
evaluados y medidos una vez que los componentes
se han integrado en un sistema.
12/05/16
39
Ejemplos de propiedades
emergentes
Propiedades
Descripcin
Volumen
El volumen de un sistema (el espacio total ocupado) vara dependiendo

cmo el framework de los componentes se colocan y se conectan.
Fiabilidad
La fiabilidad del sistema depende de la fiabilidad de los componentes,

pero las interacciones inesperadas pueden causar nuevos tipos de
fallas y por consiguiente puede afectar la fiabilidad del sistema.
Seguridad
La seguridad del sistema (su habilidad de resistencia al ataque) es una

propiedad compleja que no puede medirse fcilmente. Puede idearse
los ataques que no fueron previstos por los diseadores y as poder
derrotarlos con los resguardos incorporados.
Reparabilidad
Esta propiedad refleja cuan fcil es arreglar un problema una vez que el
sistema lo ha descubierto. a menor, donde slo resultan daos
menores. Ello depende de poder diagnosticar el problema, acceder a
los componentes que son defectuosos y modificar o reemplazar los
componentes defectuosos.
utilidad
Esta propiedad refleja cuan fcil es usar un sistema. Depende de los

componentes tcnicos del sistema, sus operadores y el ambiente
donde opera.
12/05/16
40
Tipos de propiedades
emergentes
Propiedades funcionales
12/05/16
stas aparecen cuando todas las partes de un sistema trabajan

juntas para lograr algn objetivo. Por ejemplo, una bicicleta
tiene la propiedad funcional de ser un dispositivo de transporte
una vez ensamblado a partir de sus componentes.
Propiedades emergentes no funcionales

Son ejemplos la fiabilidad, desempeo, seguridad y seguridad
fsica stos se relacionan con el comportamiento del sistema en
su ambiente operacional. Ellos son a menudo crticos para los
sistemas basados en computadora tal como fallas. Ellos son a
menudo crticos para los sistemas basados en computadora tal
como fallas para lograr algn nivel definido mnimo en estas
propiedades que pueden hacer el sistema inutilizable.
41
Ingeniera de fiabilidad de
sistemas
Debido a los interdependencia de componente, las
fallas pueden propagarse a travs del sistema.
Las fallas del sistema ocurren a menudo debido a las
interrelaciones imprevistas entre los componentes.
Es probablemente imposible anticiparse a todas las
posibles interrelaciones de componente.
Las medidas de fiabilidad de software pueden dar
una falsa imagen de la fiabilidad del sistema.
12/05/16
42
Influencias en fiabililidad
Fiabilidad del hardware
Cul es la probabilidad de que un componente del
hardware est fallando y cunto tiempo toma reparar
ese componente?
Fiabilidad del software
Cun probable es que un componente de software
producir una salida incorrecta. La falla del software es
normalmente distinta desde que la falla del hardware en
ese software no lo lleva fuera.
Fiabilidad del operador
Cun
probable es que el operador de un sistema
cometer un error?
12/05/16
43
Interrelaciones de
fiabilidad
Una
falla del hardware puede generar

signos espurios que estn fuera del rango
de entradas esperadas por el software.
Los errores del software pueden causar
alarmas que al ser activadas causan
tensin en el operador y llevar a errores del
operador.
El ambiente en el que un sistema se instala
puede afectar su fiabilidad.
12/05/16
44
Las propiedades no
debidas
Las
propiedades como el desempeo y la fiabilidad

pueden medirse.
Sin embargo, algunas propiedades son propiedades
que el sistema no debe exhibir
Seguridad fsica: el sistema no debe comportarse
de una manera insegura;
Seguridad contra delitos: el sistema no debe
permitir el uso no autorizado.
Medir o evaluar estas propiedades es muy difcil.
12/05/16
45
Ingeniera de sistemas
Especificando,
diseando, implementando,
validando, desplegando y manteniendo los
sistemas socio-tcnicos.
Tenido
relacin
con
los
servicios
proporcionados
por
el
sistema,
las
restricciones
en
su
construccin
y
funcionamiento y las maneras en las que se
usa.
12/05/16
46
Los procesos de la
ingeniera de sistemas
Normalmente
se sigue el modelo de "cascada"

debido a la necesidad del desarrollo paralelo de
diferentes partes del sistema.
Alcance pequeo para la iteracin entre las fases

porque los cambios del hardware son muy caros. El
software puede tener que compensar los problemas
del hardware.
Inevitablemente
involucra a ingenieros
diferentes que deben trabajar juntos
12/05/16
de
Mucho alcance por

una mal interpretacin. Las
diferentes disciplinas usan un vocabulario diferente y
se requiere mucha negociacin. Los ingenieros pueden
tener las agendas personales llenas.
47
Los procesos de la
ingeniera de sistemas
Definicinde
Definicinde
requerimientos
requerimientos
Retirodel
Retirodel
sistema
sistema
Diseodel
Diseodel
sistema
sistema
Evolucindel
Evolucindel
sistema
sistema
Desarrollodel
Desarrollodel
subsistema
subsistema
Instalacindel
Instalacindel
sistema
sistema
Integracindel
Integracindel
sistema
sistema
12/05/16
48
Envolvimiento
interdisciplinario
Ingenierade
Ingenierade
software
software
Ingeniera
Ingeniera
estructural
estructural
Ingeniera
Ingeniera
civil
civil
12/05/16
Ingeniera
Ingeniera
electrnica
electrnica
Ingenierade
Ingenierade
sistemasATC
sistemasATC
Ingeniera
Ingeniera
elctrica
elctrica
Ingeniera
Ingeniera
mecnica
mecnica
Diseodeinterfazde
Diseodeinterfazde
usuario
usuario
Arquitectura
Arquitectura
49
Definicin de
requerimientos del sistema
Tres tipos de requerimientos son definidos en esta fase:
Los requisitos funcionales abstractos: Se definen las
funciones del sistema de una manera abstracta;
Las propiedades del sistema: Se definen requisitos
Non-funcionales para el sistema en general;
Las caractersticas indeseables: El comportamiento
inaceptable del sistema se especifica.
Tambin se debe definir los objetivos organizacionales
globales para el sistema.
12/05/16
50
Objetivos del sistema

Se deber definir por qu un sistema est procurndose
para un ambiente particular.
Los objetivos funcionales
Mantener un fuego y sistema de alarma de intruso para
la construccin el edificio que proporcionar
advertencia interior y exterior de fuego o la intrusin no
autorizada.
Los objetivos organizacionales
Asegurar que el normal funcionamiento de trabajo
llevada a cabo en la construccin no se rompa
seriamente por los eventos como el fuego y la intrusin
desautorizada. Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera
12/05/16
51
Problemas de los
Normalmente se desarrollan los sistemas complejos
para dirigirse a los problemas malignos
Problemas que no se entienden totalmente;
Cambiando como el sistema est especificado.
Se
deber anticiparse los desarrollos de
comunicaciones /hardware encima del tiempo de
vida del sistema.
Es
difcil los requerimientos no-funcionales
(particularmente) sin saber la estructura de
componentes del sistema.
12/05/16
52
El proceso de diseo del

sistema
12/05/16
Requerimientos de particin
Organizar los requerimientos dentro de los grupos.
Identificar sub-sistemas
Identificar
un
conjunto
de
sub-sistemas
que
colectivamente pueden reunir los requisitos del sistema.
Asignar requerimientos a sub-sistemas
Se causan problemas particulares cuando los COTS son
integrados.
Especificar la funcionalidad de subsistemas
Definir interfaces de sub-sistemas
La actividad crtica para el desarrollo del sub-sistema
paralelo.
53
El proceso de diseo del

sistema
Definir
Definir
interfacesde
interfacesde
subsistemas
subsistemas
Requerimientos
Requerimientos
departicin
departicin
Identificarsub
Identificarsub
sistemas
sistemas
Especificar
Especificar
funcionalidada
funcionalidada
subsistemas
subsistemas
Asignacinde
Asignacinde
requerimientos
requerimientos
asubsistemas
asubsistemas
12/05/16
54
Problemas del diseo de

sistemas
Los
requerimientos que particionan el hardware,

el software y los componentes humanos pueden
involucrar mucha negociacin.
Los problemas difciles del diseo a menudo son
asumidos para ser resueltos sin esfuerzo usando
software.
Las plataformas del hardware pueden ser
impropias para los requerimientos del software y
as el software debe recompensar esto.
12/05/16
55
Requerimientos y diseos
La ingeniera de requerimientos y el diseo de del
sistema se unen indisolublemente.
Los requerimientos propuestos por el ambiente del
sistema y otros sistemas limitan las opciones de
diseo y as el actual diseo a ser usado puede ser
un requerimiento.
El
diseo inicial puede ser necesario para
estructurar los requerimientos.
Conforme se hace diseo, se aprende ms acerca
de los requerimientos.
12/05/16
56
Modelo en espiral de
requerimientos /diseo
12/05/16
Requerimientos,
Requerimientos,
Elicitaciny
Elicitaciny
Anlisis
Anlisis
Diseo
Diseo
Arquitectnico
Arquitectnico
Definicindel
Definicindel
Problema
Problema
Revisiny
Revisiny
Valoracin
Valoracin
57
Modelamiento del sistema

Un
modelo arquitectural presenta

vista
abstracta de los sub - sistemas que
constituyen un sistema.
Puede incluir los flujos de informacin mayores
entre los sub sistemas.
Normalmente presentado como un diagrama
del bloque.
Puede
identificar
diferentes tipos de
componentes funcionales en el modelo.
12/05/16
58
El sistema de alarma de
ladrn
Sensoresde
Sensoresde
movimiento
movimiento
Sensoresde
Sensoresde
puerta
puerta
Controladorde
Controladorde
alarma
alarma
Sirena
Sirena
12/05/16
Sintetizador
Sintetizador
devoz
devoz
Centrodecontrol
externo
Llamadorde
Llamadorde
telfono
telfono
59
Descripcin de sub - sistema

Sub - sistema
Descripcin
Sensores
de Detecta el movimiento en las salas monitoreadas
movimiento
por el sistema.
Sensores de
puerta
Detecta puertas que abre en las puertas externas

de la construccin.
Control de
alarma
Controla la operacin del sistema.
Sirena
Emite una advertencia auditiva cuando un

intruso es sospechoso.
Sintetizador de Sintetiza un mensaje de voz que da ubicacin del

voz
intruso sospechoso.
Llamador de
telfono
12/05/16
Hace llamadas para notificar a la seguridad, a la

polica, etc.
60
Arquitectura de sistemas ATC

Sistemaderadar
Sistemaderadar
Procesadorde
Procesadorde
posicin
posicin
Sistemadesimulacin
Sistemadesimulacin
devuelo
devuelo
Sistemade
Sistemade
transponder
transponder
Sistemadecomandosde
Sistemadecomandosde
datos
datos
Procesadordeposicinde
Procesadordeposicinde
resguardo
resguardo
Ccomandosdevuelo
Ccomandosdevuelo
Procesadorde
Procesadorde
comandos
comandos
Sistemadetelfono
Sistemadetelfono
Procesadorde
Procesadorde
comandosde
comandosde
resguardo
resguardo
Basededatosdel
Basededatosdel
plandevuelo
plandevuelo
Sistemademapa
Sistemademapa
meterelogico
meterelogico
Sistemadeconteo
Sistemadeconteo
12/05/16
Sistemadecontrolde
Sistemadecontrolde
informacin
informacin
Consolasdecontrol
Consolasdecontrol
Sistemademallasde
Sistemademallasde
actividad
actividad
61
Desarrollo del sub sistema

Tpicamente los proyectos paralelos desarrollan el
hardware, software y comunicaciones.
Puede involucrar COTS (Commercial Off the
Shelf = stock comercial disponible) en procura de
los sistemas.
Falta de comunicacin a travs de los equipos de
implementacin.
El mecanismo lento y burocrtico para proponer
los medios de cambio que la agenda de desarrollo
puede extenderse de la necesidad para retrabajar.
12/05/16
62
Integracin del sistema

El
proceso de colocar hardware, software y

personas juntos para hacer un sistema.
Debe ser incrementalmente abordado de modo
que los subsistemas son integrados al mismo
tiempo.
Los problemas de interfaz entre sub sistemas
se encuentran normalmente en esta fase.
Pueden haber problemas con entregas no
coordinadas de componentes del sistema.
12/05/16
63
Instalacin del sistema
Despus del completamiento, el sistema tiene que ser

instalado en el entorno del cliente:
Las suposiciones del entorno pueden ser incorrectas;
Puede haber resistencia humana para la introduccin
de un nuevo sistema;
El sistema puede coexistir con sistemas alternativos
al mismo tiempo;
Puede haber problemas fsicos de instalacin (e.g.
problemas de cableado);
El
operador de entrenamiento tiene que ser
identificado.
12/05/16
64
12/05/16
Los sistemas grandes tienen largo tiempo de vida. Ellos deben

evolucionar para reunir los cambios de requerimientos.
La evolucin es inherentemente costosa
Deben analizarse los cambios de una perspectiva tcnica y
comercial;
Los sub - sistemas interactan para anticiparse a los
problemas que puedan surgir;
Raramente hay una razn para las decisiones de diseo
originales;
La estructura del sistema es corrompida cuando hay
cambios dentro de l.
Los sistemas existentes que deben ser mantenidos son a
veces llamados sistemas legados.
65
Retiro de sistemas
Poniendo
el sistema fuera de servicio despus

de su tiempo de vida til.
Puede requerir surgimiento de materiales (e.g.
qumicos peligrosos) que contaminan el
ambiente
Deben ser planeadas en el diseo del sistema por

encapsulamiento.
Puede
requerirse datos para ser reestructurado y

convertido para ser usado en algn otro sistema.
12/05/16
66
Organizaciones/personas/
sistemas
Los
sistemas socio - tcnicos are sistemas

organizacionales pensados para entregar
ayuda para alguna meta organizacional o de
negocios.
Si no se entiende el entorno organizacional
donde un sistema es usado, el sistema
probablemente no satisfacer las necesidades
reales de los negocios y sus usuarios.
12/05/16
67
Factores humanos y organizacionales

Los cambios del proceso
El sistema requiere los cambios a los
procesos de trabajo en el ambiente?
Los cambios del trabajo
Hace el sistema hbiles a los usuarios en un
entorno o causa cambios en la forma de
trabajar?
Los cambios organizacionales
El sistema cambia la estructura de poder
poltico en un organizacin?
12/05/16
68
Procesos Organizacionales
12/05/16
Los procesos de superposicin de ingeniera de sistemas

y la interaccin con los procesos de procuracin
organizacional.
Los procesos operacionales son los procesos
involucrados en el uso del sistema para el propsito
pensado. Para nuevos sistemas, estos tienen que ser
definidos como parte del diseo del sistema.
Los procesos operacionales deben ser diseados para
ser flexibles y no deben forzar operaciones de manera
particular. Es importante que los operadores humanos
puedan usar sus iniciativas si los problemas surgen.
69
Procesos de obtencin
/desarrollo
Procesode
Procesode
Obtencin
Obtencin
Procesode
Procesode
Desarrollo
Desarrollo
Proceso
Proceso
Operacional
Operacional
12/05/16
70
Obtencin del sistema
12/05/16
Adquiriendo un sistema para satisfacer alguna necesidad de una

organizacin.
Alguna especificacin del sistema y el diseo arquitectnico es
normalmente necesario antes de la obtencin
Se necesita una especificacin para permitir un contrato de
desarrollo del sistema.
La especificacin puede permitir comprar un sistema comercial de
stock disponible (COTS= Commercial Off The Shelf). Casi
siempre ms barato que desarrollar el sistema desde el principio.
Los grandes sistemas complejos normalmente consisten en una
mezcla de stock disponible y componentes diseados. Los procesos
de obtencin para estos diferentes tipos de componentes son
normalmente diferentes.
71
El proceso de obtencin de
sistema
Sistemade
disponibilidaden
stock
Elegir
Elegir
sistema
sistema
Adaptar
Adaptar
requerimientos
requerimientos
Publicar
Publicar
demandaparala
demandaparala
oferta
oferta
Elegir
Elegir
proveedor
proveedor
Estudiodemercado
Estudiodemercado
desistemasexistentes
desistemasexistentes
Publicardemanda
Publicardemanda
paravigilante
paravigilante
Elegir
Elegir
vigilante
vigilante
Negociarel
Negociarel
contrato
contrato
Permitircontrato
Permitircontrato
paraeldesarrollo
paraeldesarrollo
Lorequeridopor
elsistema
habitual
12/05/16
72
Emisin de obtenciones
Los
requerimientos pueden tener que ser

modificados para emparejar las capacidades de
los componentes disponibles en stock.
La especificacin de requerimientos puede ser
parte del contrato para el desarrollo del sistema.
Hay normalmente un periodo de negociacin de
contrato para estar de acuerdo en los cambios
despus de que el contratista construye el
sistema que ha sido seleccionado.
12/05/16
73
Contratistas y sub contratistas

La
obtencin
de
sistemas
del
hardware/software grandes est normalmente
basada alrededor de algn contratista
principal.
Los sub - contratos se emiten a otros
proveedores para suministrar partes del
sistema.
El cliente trata con el contratista principal y no
trata directamente con sub - contratistas.
12/05/16
74
Modelos de Contratista/Subcontratista
Sistemadel
Sistemadel
Cliente
Cliente
Contratista
Contratista
Principal
Principal
Sub
Sub
Contratista1
Contratista1
12/05/16
Sub
Sub
Contratista2
Contratista2
Sub
Sub
Contratista3
Contratista3
75
Sistemas legados
Los sistemas socio tecnolgicos que han

desarrollados usando tecnologas viejas u obsoletas.
Es crucial para la operacin de un negocio y es a
menudo demasiado arriesgado desechar estos
sistemas.
Sistema de cuenta bancaria de cliente;
Sistema de mantenimiento de avin.
Los sistemas legados restringen los nuevos procesos
de negocio y consumen una proporcin alta de
presupuestos de la compaa.
12/05/16
76
Sistemas legados
Softwarede
Softwarede
soporte
soporte
Correen
Sistemasde
Sistemasde
hardware
hardware
12/05/16
Usa
Softwarede
Softwarede
aplicacin
aplicacin
Correen
Incluye
Polticas
Polticas
conocimientode comercialesy
Usa
Datosde
Datosde
aplicacin
aplicacin
comercialesy
reglas
reglas
Usa
Restringe
n
Procesosde
Procesosde
negocios
negocios
77
Componentes de sistemas
legados
12/05/16
Hardware: puede ser hardware obsoleto de mainframes.

Software de soporte: puede confiar en el software de
apoyo de proveedores que son recientes en el negocio.
Software de aplicacin: puede ser escrito en lenguajes de
programacin obsoletos.
Datos de aplicacin: a menudo incompletos e
inconsistentes.
Procesos de negocios: pueden ser restringidos por
estructura de software y funcionalidad.
Polticas comerciales y reglas: pueden ser implcitas y
incrustadas en el sistema de software.
78
Sistemas socio tcnicos

Sistemassociotcnicos
Procesos de negocios
Software de aplicacin
Software de soporte
Hardware
12/05/16
79
Puntos clave
Los sistemas socio tcnicos incluyen hardware de
computadoras, software y gente y son diseados
para lograr algunas metas comerciales.
Las propiedades emergentes son propiedades que
son caractersticas del sistema como un todo y no de
sus partes componentes.
El proceso de ingeniera de sistemas incluye
especificacin, diseo, desarrollo, integracin y
pruebas.
La integracin del sistema es
particularmente crtica.
12/05/16
80
Puntos clave
Factores humanos y organizacionales tienen un efecto
significativo en la operacin de sistemas socio
tcnicos.
Hay complejas interacciones entre los procesos de
obtencin del sistema, desarrollo y operacin.
Un sistema legado s un viejo sistema que continua para
proveer servicios esenciales.
Los sistemas legados incluyen procesos de negocios,
software de aplicacin, software de soporte y hardware
de sistema.
12/05/16
81
Captulo 3
Sistemas crticos
12/05/16
82
Objetivos
Para
explicar lo que se entiende por un sistema

crtico dnde una falla del sistema puede tener
una consecuencia humana severa o econmica.
Para explicar cuatro dimensiones de confiabilidad:
disponibilidad, fiabilidad, seguridad (fsica) y
seguridad (contra delitos).
Para explicar que, para lograr la confiabilidad, se
necesita evitar los errores, detectar y quitar errores
y limitar el dao causados por falla.
12/05/16
83
Temas cubiertos
Un
sistema simple de seguridad

crtica
Confiabilidad de sistemas
Disponibilidad y fiabilidad
Safety (Seguridad fsica)
Security (Seguridad contra delitos)
12/05/16
84
Sistemas crticos
12/05/16
Sistemas de seguridad crtica

Una falla produce prdida de vida, lesin o dao al
ambiente;
Sistema de proteccin de una planta qumica;
Sistemas de misin crtica
Una falla produce el fracaso de algunas actividades
dirigidas a una meta;
Sistema de navegacin espacial;
Sistemas de negocios crticos
Una falla produce prdidas econmicas altas;
Sistema de cuenta de cliente en un banco.
85
Confiabilidad de sistemas
Para
los sistemas crticos, normalmente el caso

ms de propiedad del sistema es la confianza del
sistema.
La confiabilidad de un sistema refleja el grado de
crdito del usuario en ese sistema. Refleja la
magnitud de confianza del usuario de que el
sistema operar como los usuarios esperan y que
no quiere que haya falla en el uso normal.
La utilidad y confiabilidad no son la misma cosa.
Un sistema no tiene que ser confiable para ser til.
12/05/16
86
Importancia de la
confiabilidad
Sistemas
que no son confiables y son inestables,

no garantizados o inseguros pueden ser
rechazados por sus usuarios.
Los costos de falla del sistema pueden ser muy
altos.
Los sistemas
no confiables pueden causar la
prdida de informacin con un costo alto de la
consecuente recuperacin.
12/05/16
87
Mtodos de desarrollo para

sistemas crticos
Los
costos de falla de un sistema crtico son tan

altos que desarrollar los mtodos para otros
tipos de sistemas no es rentable.
Ejemplos de mtodos de desarrollo
Mtodos formales de desarrollo de software.
Anlisis estadstico.
Seguridad de calidad externa.
12/05/16
88
Sistemas socio - tcnicos

Falla de hardware
El hardware falla debido a errores en el diseo y errores
manufactura o porque los componentes han alcanzado
el final de su vida natural.
Falla de software
El
software falla debido a los errores en su
especificacin, diseo o implementacin.
Falla operacional
Los operadores humanos cometen los errores. Ahora
quizs sea la sola ms grande causa de fallas del
sistema.
12/05/16
89
Una bomba de insulina de

software controlada
Usada
por los diabticos para simular la

funcin del pncreas que fabrica la insulina,
una hormona esencial que metaboliza la
glucosa de sangre.
Las medidas de glucosa de la sangre (el
azcar) usando un micro-sensor y calcular
la dosis de insulina exigi metabolizar la
glucosa.
12/05/16
90
Organizacin de la bomba
de insulina
Depsito de insulina
Montajede
aguja
Sensor
Visual1
Bomba
Reloj
Controlador
Alarma
Visual2
Suministro de fuerza
12/05/16
91
Flujo de datos de la bomba de

insulina
Sangre Sensordeazcar
Sensordeazcar
enlasangre
enlasangre
Parmetrosde
sangre
Anlisisdeazcar
Anlisisdeazcar
enlasangre
enlasangre
Nivelde
azcarenlade
sangre
Cmputode
Cmputode
requerimientosde
requerimientosde
insulina
insulina
Insulina
12/05/16
Bombade
Bombade
insulina
insulina
Comandosde
controlde
bomba
Controladorde
Controladorde
entregadeinsulina
entregadeinsulina
Corregir
insulina
requerida
92
Requerimientos de
confiabilidad
El
sistema estar disponible para entregar

insulina cuando sea requerido para hacer eso.
El sistema realizar la confiabilidad y entregar la
cantidad correcta de insulina para neutralizar el
nivel actual del azcar de sangre.
El requisito esencial de seguridad es que nunca
deben entregarse dosis excesivas de insulina
dado que esto es potencialmente una amenaza a
la vida.
12/05/16
93
Confiabilidad
La confiabilidad de un sistema es equivalente a
su fidelidad.
Un sistema fidedigno es un sistema confiable por
sus usuarios.
Las principales dimensiones de confiabilidad son:
Disponibilidad;
Fiabilidad;
Seguridad fsica;
Seguridad contra delitos.
12/05/16
94
Dimensiones de confiabilidad
Confiabilidad
Confiabilidad
Disponibilidad
Disponibilidad
Fiabilidad
Fiabilidad
Seguridad
Seguridad
fsica
fsica
Seguridadcontra
Seguridadcontra
delitos
delitos
Lahabilidaddeun
Lahabilidaddeun
Lahabilidaddeun Lahabilidaddeun
sistemaparaentregar sistemaparaentregar sistemaparaoperar sistemaparaproteger
servicioscuandoson serviciosespecificados
sinfallas
intrusionescontrael
requeridos
catastrficas
sistemaaccidentaleso
deliberadas
12/05/16
95
Otras propiedades de la
confiabilidad
Reparabilidad
Refleja hasta que punto el sistema puede ser
reparado en caso de una falla.
Mantenabilidad
Refleja hasta que punto el sistema puede
adaptarse a los nuevos requerimientos.
Supervivencialidad
Refleja hasta que punto el sistema puede entregar
los servicios aun bajo ataque hostil.
Tolerancia de error
Refleja que hasta que punto el usuario ingresa
errores que pueden evitarse y tolerarse.
12/05/16
96
Mantenibilidad
Un atributo del sistema que se preocupa por la
facilidad de reparar el sistema despus de que una
falla se ha descubierto o por cambio del sistema para
incluir los nuevos rasgos.
Muy importante para los sistemas crticos como las
faltas a menudo se introduce en un sistema debido a
los problemas de mantenimiento.
La mantenibilidad es distinto de otras dimensiones de
confiabilidad porque es un atributo esttico y no un
atributo dinmico del sistema . Yo no lo cubro en este
curso.
12/05/16
97
Supervivencialidad
La
habilidad de un sistema de continuar entregando

sus servicios a los usuarios enfrentando el ataque
deliberado o accidental.
ste es un atributo de creciente importancia para
sistemas distribuidos cuya seguridad puede
comprometerse.
La
supervivencialidad incluye la nocin de
elasticidad: la habilidad de un sistema para
continuar en operacin a pesar de las fallas de
componentes.
12/05/16
98
Confiabilidad vs. desempeo

Los sistemas poco fiables pueden ser rechazados por
sus usuarios.
Los costos de falla de sistemas pueden ser muy altos.
Es muy difcil de poner a punto los sistemas para
hacerlos ms fidedignos.
Puede ser posible para compensar
el desempeo
pobre.
Los sistemas poco fiables pueden causar prdida de
informacin valiosa.
12/05/16
99
Costos de confiabilidad
Los costos de confiabilidad tienden a aumentar
exponencialmente cuando los niveles crecientes de
confiabilidad son requeridos.
Hay dos razones para esto:
El uso de mas tcnicas de desarrollo caras y
hardware que se exigen lograr los niveles ms
altos de confiabilidad.
Las crecientes pruebas y sistemas de validacin
que se exigen para convencer al cliente del
sistema, que se han logrado los niveles
requeridos de confiabilidad.
12/05/16
100
Costos de confiabilidad
creciente
12/05/16
101
Economa de la
confiabilidad
Debido a los costos muy altos para lograr la
confiabilidad, puede costearse ms eficazmente
aceptando los sistemas poco fiables y pagar por los
costos de fallas.
Sin embargo, esto depende de los factores sociales y
polticos. Una reputacin para productos en los que
no puede confiarse, puede causar perdidas en el
futuro del negocio.
Depende del tipo del sistema - para los sistemas
comerciales en particular, los niveles modestos de
confiabilidad pueden ser adecuados.
12/05/16
102
Fiabilidad
La probabilidad de operacin del sistema libre
de falla durante un tiempo especfico, en un
ambiente dado, para un propsito dado.
Disponibilidad
La probabilidad que un sistema en un tiempo
dado, ser operacional y capaz entregar los
servicios pedidos.
Ambos
atributos pueden ser expresados
cuantitativamente.
12/05/16
103
A veces es posible incluir a la disponibilidad del
sistema bajo la fiabilidad del sistema.
Obviamente si un sistema esta indisponible es
que no est entregando los servicios del sistema
especificados.
Sin embargo, es posible tener sistemas con
fiabilidad baja que pueden estar disponibles.
Mientras las fallas de sistema pueden repararse
rpidamente y no daen los datos, la fiabilidad baja
no debe ser un problema.
La disponibilidad tiene en cuenta tiempo de la
reparacin.
12/05/16
104
Terminologa de fiabilidad
Falla del sistema
Un evento que ocurre en algn punto del

tiempo cuando el sistema no entrega un
servicio como esperaban a los usuarios.
Error del sistema
Un estado errneo del sistema que puede

llevar
al
comportamiento
del
sistema
inesperado por los usuarios.
Defecto del
sistema
Una caracterstica del software del sistema,

que puede llevar a un error del sistema. Por
ejemplo, una falla de inicializacin de una
variable puede llevar a que la variable tenga
valor errado cuando es usado.
Error humano o
equivocacin
Comportamiento humano que resulta de la

introduccin de errores dentro de un sistema.
12/05/16
105
Errores y fallas
La fallas son normalmente un resultado de errores del

sistema que se derivan de errores en el sistema.
Sin embargo, las faltas no necesariamente resultan de los
errores del sistema.
El estado defectuoso del sistema puede ser pasajero y
corregido' antes de surgir un error.
Los errores no necesariamente llevan a fallas del sistema.
El error puede ser corregido por deteccin del error
empotrado y recuperacin.
Contra las fallas puede
protegerse por medio de
protecciones empotradas. Por ejemplo, stas pueden
proteger los recursos del sistema de los errores del
sistema.
12/05/16
106
Percepciones de confiabilidad
La definicin formal de fiabilidad no siempre refleja la percepcin del usuario

de la fiabilidad de un sistema.
Las asunciones que se hacen sobre el ambiente dnde un sistema ser

usado pueden ser incorrectas.
Es probable que el uso de un sistema en un ambiente de oficina sea
bastante diferente del uso del mismo sistema en un ambiente
universitario.
Las consecuencias de fallas del sistema afectan la percepcin de fiabilidad.

Los limpiadores del parabrisas inestables en un automvil pueden ser no
pertinentes en un clima seco.
Las fallas que tienen consecuencias serias (como una avera de una
pieza en un automvil) tienen mayor peso por usuarios que fallas que son
inoportunas.
12/05/16
107
El logro de la fiabilidad
La anulacin de falla
La tcnica de desarrollo se usa para minimizar la posibilidad
de errores o atrapar errores antes de que ellos produzcan la
introduccin de faltas en el sistema.
El descubrimiento de la falla y retiro
Las tcnicas de verificacin y validacin que aumentan la
probabilidad de descubrir y corregir los errores antes de que el
sistema entren en servicio y sean usados.
Tolerancia de falla
Las tcnicas de tiempo de ejecucin
son usadas para
asegurar que las faltas del sistema no produzcan errores del
sistema y/o esos errores del sistema no lleve a las fallas del
sistema.
12/05/16
108
Modelando fiabilidad
Se
puede modelar un sistema como una traza de

entrada-salida donde algunas entradas producirn
salidas errneas.
La fiabilidad del sistema es la probabilidad de que
una entrada colocada en el juego de entradas
causen salidas errneas.
Diferentes personas se usarn en el sistema de
maneras diferentes de modo que esta
probabilidad no es un atributo del sistema esttico,
pero depende del ambiente del sistema.
12/05/16
109
Modelando fiabilidad
Se
puede modelar un sistema como una traza de

entrada-salida donde algunas entradas producirn
salidas errneas.
La fiabilidad del sistema es la probabilidad de que
una entrada colocada en el juego de entradas
causen salidas errneas.
Diferentes personas se usarn en el sistema de
maneras diferentes de modo que esta
probabilidad no es un atributo del sistema esttico,
pero depende del ambiente del sistema.
12/05/16
110
Traza de entrada/salida
Conjunto
deentradas
Entradasque
causansalidas
errneas
Ie
Programa
Programa
Salidaserrneas
Conjunto
desalidas
12/05/16
Oe
111
Percepcin de
confiabilidad
Posibles
entradas
Usuario1
Usuario1
Usuario
Usuario
22
12/05/16
Usuario
Usuario
33
Entradas
errneas
112
La mejora de confiabilidad
Quitando X% de las faltas en un sistema no

necesariamente mejorar la fiabilidad
por X%. Un
estudio a IBM mostr que quitando 60% de defectos del
producto se produce un 3% de mejora en la fiabilidad.
Los defectos del programa pueden estar en las secciones
raramente ejecutadas del cdigo, por lo que nunca podr
ser encontrada por los usuarios. Quitando stos no afecta
la fiabilidad percibida.
Un programa con las faltas conocidas puede por
consiguiente verse todava como fiable por sus usuarios.
12/05/16
113
Seguridad fsica
La seguridad fsica es una propiedad de un sistema que

refleja la habilidad del sistema de operar, normalmente o
anormalmente, sin peligro de causar lesin humana o
muerte y sin dao al ambiente del sistema.
Es de creciente importancia considerar las seguridades
fsicas del software, porque cada vez ms se incorporan
dispositivos de sistemas de control basados en software.
Los
requerimientos
de
seguridad
fsica
son
requerimientos exclusivos, es decir, ellos excluyen las
situaciones indeseables, en lugar de especificar los
servicios requeridos del sistema.
12/05/16
114
Criticalidad de la seguridad
fsica
12/05/16
Los sistema de seguridad fsica crtica primarios

Sistemas del software empotrados cuya falla puede
causar falla en el hardware asociado y amenazar
directamente a las personas.
Los sistema de seguridad fsica crtica primarios
Sistemas cuya falla produce las faltas en otros
sistemas que pueden amenazar a las personas.
Aqu la discusin de los enfoques en los sistemas de
seguridad fsica crtica primarios
Los sistemas de seguridad fsica crtica secundarios
slo pueden ser considerados base de intento nico.
115
Seguridad fsica y
fiabilidad
La
seguridad fsica y fiabilidad estn relacionadas

pero son distintas
En general, la fiabilidad y disponibilidad son necesarias

pero no son condiciones suficientes para la seguridad
fsica del sistema.
La
fiabilidad se preocupa por la conformidad a una

especificacin dada y entrega de servicio.
La seguridad fsica se preocupa por asegurar que el
sistema no puede causar dao, independientemente
de que est o no conforme a su especificacin.
12/05/16
116
Los sistemas fiables no seguros

fsicamente
12/05/16
Errores de especificacin
Si la especificacin del sistema es
incorrecta,
entonces
el sistema puede comportarse como
especificado pero todava causa un accidente.
Fallas del hardware que generan entradas espurias
Duro para anticiparse en la especificacin.
Comandos de contexto sensibles, es decir,
emitiendo el comando correcto en un mal momento.
A menudo el resultado de error del operador.
117
Terminologa de seguridad
fsica
Trmino
Definicin
Accidente
(contratiempo)
Un evento no planificado o sucesin de eventos que resulta en muerte humana o

lesin, dao a la propiedad o ambiente. Una mquina controlada por computadora que
daa a su operador es un ejemplo de accidente.
Azar
Una condicin potencial para causar un accidente o contribuir en l. Una falla del
sensor que descubre un obstculo delante de una mquina es un ejemplo de azar.
Dao
Una medida de la prdida que resulta un contratiempo. El dao puede recorrer de

muchas personas muertas como resultado de un accidente a lesiones menores o
daos de propiedad.
Severidad de
riesgo
Una valoracin del peor dao posible que podra ser el resultado de un particular azar.
La severidad del azar puede ir desde catastrfico, donde muchas personas mueren; a
menor, donde slo resultan daos menores.
Probabilidad de
azar
La probabilidad de que en los eventos que ocurren haya azar. Los valores de
probabilidad tienden a ser arbitrarios pero van desde probable (digamos 1/100 de
oportunidad de ocurrencia de azar) a inverosmil (situaciones no concebibles son
probables donde el azar pueda ocurrir).
Riesgo
sta es una medida de la probabilidad de que el sistema causar un accidente. El

riesgo evaluado considerando la probabilidad de azar, la severidad de riesgo y la
probabilidad de que el azar producir un accidente.
12/05/16
118
El logro de la seguridad
fsica
Anulacin del azar

El sistema se disea para que algunas clases de azar
simplemente no puedan surgir.
Deteccin y retiro del azar
El sistema se disea para que se descubran los azares y
retirarlos antes de que ellos produzcan un accidente.
Limitacin del dao
El sistema incluye los rasgos de protecciones que
minimizan el dao que puede ser el resultado de un
accidente.
12/05/16
119
Accidentes normales
Los accidentes en los sistemas complejos raramente
tienen una sola causa, dado que estos sistemas se
disean para ser elsticos ante un solo punto de falla.
Diseando sistemas para que un solo punto de falla no
cause un accidente, es un principio fundamental de
diseo de sistemas garantizados.
Casi todos accidentes son un resultado de combinaciones
de funcionamientos defectuosos.
Es probable el caso que anticipndose a todo las
combinaciones del problema, sobre todo, en sistemas de
software controlado, logrando as la seguridad fsica
completa, es imposible.
12/05/16
120
Seguridad contra delitos

La seguridad contra delitos (security) de un sistema
es una propiedad del sistema que refleja la habilidad
del sistema de protegerse del ataque externo
accidental o deliberado.
La seguridad est ponindose en crecimiento
importante, tal como los sistemas que se conectan a
una red de computadoras para que el acceso
externo al sistema a travs de Internet, sea posible.
La seguridad es un pre -requisito esencial para la
disponibilidad, fiabilidad y seguridad.
12/05/16
121
Seguridad Fundamental
Si un sistema es un sistema conectado una red de
computadoras y es
inseguro, entonces las
declaraciones sobre su fiabilidad y su seguridad
fsica son inestables.
Estas declaraciones dependen del sistema en
ejecucin y del sistema desarrollado que es el
mismo. Sin embargo, la intrusin puede cambiar el
sistema en ejecucin y/o sus datos.
Por consiguiente, la fiabilidad y la conviccin de
seguridad fsica no son vlidas por tiempo
prolongado.
12/05/16
122
Terminologa de
seguridad contra delitos
Trmino
Exposicin
Definicin
Posible prdida o dao en un sistema de computacin. sta
puede ser prdida o dao a los datos o puede ser prdida de
tiempo y esfuerzo si la recuperacin es necesaria despus de
una brecha de seguridad.
Vulnerabilidad Una debilidad en un sistema basado en computadora que puede

explotar para causar prdida o dao.
Ataque
Una explotacin de una vulnerabilidad del sistema.

Generalmente, esto est fuera del sistema y es un esfuerzo
deliberado por causar algn dao.
Amenazas
Circunstancias que tienen el potencial para causar prdida o

dao. Se puede pensar en stos como una vulnerabilidad del
sistema que est sujeto a un ataque.
Control
Una medida de proteccin que reduce una vulnerabilidad del

sistema. La encriptacin sera un ejemplo de un control que
reduce una vulnerabilidad de sistemas de control de acceso
dbiles.
12/05/16
123
El dao de la inseguridad
Rechazo de servicio
El sistema es forzado a un estado dnde los servicios
normales son indisponibles o donde la provisin de
servicio se degrada significativamente.
Corrupcin de programas o datos
Pueden modificarse los programas o datos en el sistema
de una manera desautorizada.
El descubrimiento de informacin confidencial
La informacin que es manejada por el sistema puede ser
expuesta a las personas que no estn autorizadas para
leer o usar esa informacin.
12/05/16
124
Conviccin de seguridad
Anulacin de vulnerabilidad
El sistema se disea para que las vulnerabilidades no ocurran.
Por ejemplo, si no hay ninguna conexin externa de la red,
entonces que el ataque externo es imposible.
Descubrimiento y eliminacin de ataque
El sistema se disea para que se descubran ataques en las
vulnerabilidades y neutralizarlos, antes de que ellos produzcan
una exposicin. Por ejemplo, los comprobadores del virus
encuentran y quitan los virus antes de que ellos infecten un
sistema.
Limitacin de exposicin
El sistema se disea para que se minimicen las consecuencias
adversas de un ataque exitoso. Por ejemplo, una poltica auxiliar
permite restaurar la informacin daada.
12/05/16
125
Puntos crticos
Un sistema crtico es un sistema dnde una falla puede llevar

a una alta prdida econmica, dao fsico o amenazas a la
vida.
La confiabilidad en un sistema refleja la confianza del usuario
en ese sistema.
La disponibilidad de un sistema es la probabilidad que estar
disponible para entregar los servicios cuando sean pedidos.
La fiabilidad de un sistema es la probabilidad de que se
entregarn los servicios especificados del sistema.
La fiabilidad y disponibilidad son generalmente vistos como
condiciones necesarias pero no suficientes para la seguridad
fsica y la seguridad contra delitos.
12/05/16
126
Puntos crticos
La fiabilidad se relaciona a la probabilidad de
ocurrencia de un error en el uso operacional. Un
sistema con las faltas conocidas puede ser fiable.
La seguridad fsica es un atributo del sistema que
refleja la habilidad del sistema de operar sin
personas amenazantes o el ambiente.
La seguridad contra delitos es un atributo del
sistema que refleja la habilidad del sistema de
protegerse del ataque externo.
La mejora de confiabilidad exige a una aproximacin
socio-tcnica para disear, donde se considera a los
humanos, as como el hardware y software.
12/05/16
127
Captulo 4
Procesos de
software
12/05/16
128
Objetivos
Introducir modelos del proceso de software
Describir tres modelos de procesos genricos y
cuando ellos pueden ser usados
Describir el contorno de los modelos de procesos
para la ingeniera de requerimientos, desarrollo de
software, pruebas y evolucin
Explicar el modelo Proceso Unificado Rational
introducir tecnologa CASE para actividades del
proceso de software de soporte
12/05/16
129
Tpicos cubiertos
Modelos
del proceso de Software

Iteracin del proceso
Actividades del proceso
El Proceso Unificado Rational
Ingeniera de software auxiliado por
computadora
12/05/16
130
El proceso del software

Un conjunto de actividades estructuradas
requeridas para el desarrollo de un sistema de
software:
Diseo;
Validacin;
Evolucin.
Un modelo del proceso de software es una
representacin abstracta de un proceso.
Representa una descripcin de un proceso desde
alguna perspectiva particular.
12/05/16
131
Modelos del proceso de software

genrico
12/05/16
El modelo de cascada
Separa y distingue fases de especificacin y desarrollo.
Desarrollo evolutivo
Especificacin,
desarrollo
y
validacin
estn
entrelazados.
Ingeniera de software basada en componentes
El sistema es ensamblado a partir de componentes
existentes.
Hay muchas variantes de estos modelos e.g. desarrollo
formal donde es usado un proceso similar a de la
cascada, pero la especificacin es una especificacin
formal que es refinada a travs de varios estados para un
diseo implementable.
132
Modelo de cascada
Definicin
Definicinde
de
requerimientos
requerimientos
Diseo
Diseode
desistema
sistemayy
software
software
Implementacin
Implementacinyy
pruebas
pruebasde
deunidad
unidad
Integracin
Integracin yy
pruebas
pruebasde
desistema
sistema
Operacin
Operacinyy
mantenimiento
mantenimiento
12/05/16
133
Fases del modelo de cascada
Anlisis y definicin de requerimientos

Diseo del sistema y software
Implementacin y pruebas de unidad
Integracin y pruebas de sistema
Operacin y mantenimiento
El inconveniente principal del modelo de la cascada es
la dificultad de adaptacin al cambio despus de que el
proceso est en marcha. Una fase tiene que estar
completa antes de pasar hacia la prxima fase.
12/05/16
134
Problemas del modelo de

cascada
El particionamiento inflexible del proyecto en fases

distintas dificulta la respuesta a los requerimientos del
cliente cambiantes.
Por consiguiente, este modelo slo es apropiado
cuando los requisitos se entienden bien y los cambios se
limitarn justamente durante el proceso de diseo.
Pocos sistemas comerciales tienen los requisitos
estables.
El modelo de la cascada es principalmente usado para
grandes proyectos de ingeniera de sistemas, dnde un
sistema se desarrolla en varios sitios.
12/05/16
135
El
El objetivo es trabajar con clientes y desarrollar un

sistema final desde una especificacin inicial del
entorno. Se debe empezar con los requerimientos bien
entendidos y se debe agregar los nuevos rasgos
propuestos por el cliente.
El
12/05/16
desarrollo exploratorio
prototipo desechable
El objetivo es entender los requerimientos del sistema.

Se debe empezar con los requerimientos pobremente
entendidos para clarificar lo que realmente se
necesita.
136
Actividades
concurrentes
Descripcin
Descripcin
del
delentorno
entorno
12/05/16
Especificacin
Especificacin
Versin
Versininicial
inicial
Desarrollo
Desarrollo
Versin
Versin
intermedia
intermedia
Validacin
Validacin
Versin
Versinfinal
final
137
Problemas
Falta de visibilidad del proceso;

A menudo se estructuran pobremente los sistemas;
Pueden requerirse habilidades especiales (por
ejemplo, en lenguajes para el prototipado rpido).
Aplicabilidad
12/05/16
Para sistemas interactivos pequeos o medianos;

Para partes de sistemas grandes (por ejemplo la
interfaz del usuario);
Para sistemas de vida corta.
138
basada en componentes
Basado en el reuso sistemtico donde los sistemas se

integran a partir de componentes existentes o
sistemas COTS (Stock comercial disponible).
Fases del proceso
Anlisis de componentes;
Modificacin de requerimientos;
Diseo de sistemas con reuso;
Desarrollo e integracin.
Esta aproximacin es usada cada vez ms conforme
van surgiendo estndares de componentes.
12/05/16
139
Desarrollo orientado al
reuso
Especificacin
Especificacinde
de
requerimientos
requerimientos
Anlisis
Anlisisde
de
componentes
componentes
Modificacin
Modificacinde
de
requerimientos
requerimientos
Modificacin
Modificacinde
de
requerimientos
requerimientos
12/05/16
Diseo
Diseode
desistemas
sistemas
con
reuso
con reuso
Diseo
Diseode
desistemas
sistemas
con
reuso
con reuso
140
Iteracin del proceso
Los requisitos del sistema SIEMPRE evolucionan en el

curso de un proyecto de modo que la iteracin del
proceso en las fases ms tempranas son retrabajadas
siempre que sean parte del proceso para sistemas
grandes.
La iteracin puede aplicarse a cualquiera de los modelos
del proceso genrico.
Dos (relacionadas) aproximaciones
Entrega Incremental;
Desarrollo en espiral.
12/05/16
141
Entrega incremental
En lugar de entrega del sistema en una sola
entrega, el desarrollo y la entrega estn
fracturados
bajo
incrementos,
con
cada
incremento que entrega parte de la funcionalidad
requerida.
Los requerimientos del usuario se priorizan y los
requerimientos de prioridad ms altos son
incluidos en los incrementos tempranos.
Una vez que el desarrollo de un incremento ha
empezado, los requerimientos son congelados
aunque los requerimientos para los incrementos
ms tardios pueden continuar evolucionando.
12/05/16
142
Desarrollo incremental
Definir
Definirrequerimientos
requerimientos
del
delentorno
entorno
Desarrollar
Desarrollarincremento
incremento
del
sistema
del sistema
Asignar
Asignarrequerimientos
requerimientosalal
incremento
incremento
Validar
Validar
incremento
incremento
Integrar
Integrar
incremento
incremento
Sistema incompleto
12/05/16
Disear
Disear arquitectura
arquitectura
del
sistema
del sistema
Validar
Validar
sistema
sistema
Sistema final
143
Ventajas del desarrollo

incremental
El
valor del cliente puede entregarse con cada

incremento para que la funcionalidad del sistema
est disponible antes.
Hechos de incrementos tempranos como un
prototipo, ayudan a obtener requisitos para los
incrementos ms tardos.
El ms bajo riesgo de falla del proyecto global.
Los servicios de sistema de prioridad ms altos
tienden a recibir la mayora de pruebas.
12/05/16
144
Programacin extrema
Una
aproximacin para el desarrollo

basado en el desarrollo y entrega de
incrementos
muy
pequeos
de
funcionalidad.
Confa en la mejora constante del cdigo, la
integracin del usuario en el equipo de
desarrollo y programacin por pares.
Cubierto en el Captulo 17.
12/05/16
145
Desarrollo en espiral
El proceso se representa como una escalera de caracol,
en lugar de una sucesin de actividades con retroceso.
Cada vuelta en la escalera de caracol representa una
fase en el proceso.
Ninguna fase es fija como especificacin o ciclos de
diseo en la escalera de caracol son escogidos
dependiendo en cual son requeridos.
Los riesgos son evaluados
explcitamente y se
resuelven a lo largo del proceso.
12/05/16
146
Modelo de espiral del proceso de

software
Determinar objetivos,
alternativas y
restricciones
Evaluar alternativas,
identificar y resolver
riesgos
Anlisis de
riesgo
Anlisis de
riesgo
Anlisis de
riesgo
REVISION
Plan de requerimientos Plan
de ciclo de vida
Plan de desarrollo
Planificar prxima
fase
Integracin y plan
de pruebas
Pro totipo 3
Pro totipo 2
Anlisis de
riesgo Pro totipo 1
Concepto de
Simulaciones, modelos y referencias
operacin Requerimientos
de software
Producto
Validacin de
de
diseo
requerimientos
Diseo V & V
Servicio
12/05/16
Pro totipo
operacional
Diseo
detallado
Cdigo
Prueba de
Prueba de unidad
aceptacin
Prueba de
aceptacin
Desarrollo y verificacin
del prximo nivel del
producto
147
Sectores del modelo en

espiral
Poner
objetivos
Objetivos especficos para la fase son identificados.
Evaluacin
de riesgos y reduccin
Los riesgos son evaluados y las actividades son puestos en

su lugar para reducir los riesgos clave.
Desarrollo y validacin
Un modelo de desarrollo para un sistema es elegido y
puede ser cualquiera de los modelos genricos.
Planificacin
El proyecto es revisado en la prxima fase y la escalera en
espiral es planificada.
12/05/16
148

Especificacin
del software
Diseo e implementacin del software
Validacin de software
Evolucin del software
12/05/16
149
Especificacin del software

El
proceso de establecer que servicios son

requeridos y las restricciones en la operacin y
Proceso de ingeniera de requerimientos
Estudio de factibilidad;
Elicitacin (obtencin) de requerimientos;
Especificacin de requerimientos;
Validacin de requerimientos.
12/05/16
150
El proceso de ingeniera de
requerimientos
Estudio
Estudiode
de
factibilidad
factibilidad
Informe
Informe de
de
factibilidad
factibilidad
Elicitacin
Elicitacinde
de
requerimientos
requerimientosyy
anlisis
anlisis
Especificacin
Especificacinde
de
requerimientos
requerimientos
Validacin
Validacinde
de
requerimientos
requerimientos
Modelos
Modelosdel
del
sistema
sistema
Requerimientos
Requerimientos
del
delusuario
usuarioyydel
del
sistema
sistema
Documentos
Documentosde
de
requerimientos
requerimientos
12/05/16
151
Diseo e implementacin
del software
El proceso de conversin de la especificacin del

sistema en sistema ejecutable.
Diseo del software
Disear una estructura de software que realice la
especificacin.
Implementacin
Transformar la estructura en un programa ejecutable.
Las actividades de diseo e implementacin estn
estrechamente relacionados y pueden ser inter - dejados
12/05/16
152
Actividades del proceso de

diseo
Diseo
arquitectnico
Especificacin abstracta
Diseo de la interfaz
Diseo de componentes
Diseo de estructuras de datos
Diseo de algoritmos
12/05/16
153
Proceso de diseo de
software
Especificacin de
Especificacin de
requerimientos
requerimientos
Diseo
Diseo
arquitectnico
arquitectnico
Arquitectura
Arquitectura
del sistema
del sistema
Especificacin
Especificacin
abstracta
abstracta
Especificacin
Especificacin
del software
del software
Actividades de diseo
Diseo de
Diseo de
la interfaz
la interfaz
Especificacin
Especificacin
de la interfaz
de la interfaz
Diseo de
Diseo de
componentes
componentes
Especificacin
Especificacin
de componentes
de componentes
Diseo de
Diseo de
estructura de datos
estructura de datos
Especificacin de
Especificacin de
estructura de datos
estructura de datos
Diseo de
Diseo de
algoritmos
algoritmos
Especificacin
Especificacin
de algoritmos
de algoritmos
Productos de diseo
12/05/16
154
Mtodos estructurados
Aproximaciones sistemticas al diseo de software.
El diseo es normalmente documentado como un
conjunto de modelos grficos.
Modelos posibles
Modelo de objeto;
Modelo secuencial;
Modelo de transicin;
Modelo estructural;
Modelo de flujo de datos.
12/05/16
155
Programando y depurando
Traduciendo
un diseo en un programa y
quitando los errores de ese programa.
Programar es una actividad personal - no hay
ningn proceso genrico de programacin.
Los programadores llevan a cabo algunas
pruebas de programa para descubrir las fallas
en el programa y quitar estas faltas en el
proceso de la depuracin.
12/05/16
156
El proceso de depuracin
Error
Error
12/05/16
local
local
Reparar
Repararerror
error
de
dediseo
diseo
Reparar
Repararerror
error
Programa
Programade
de
re
prueba
re - prueba
157
Validacin del software

La
verificacin y validacin (V & V) estn

pensados para mostrar que un sistema est
conforme a su especificacin y rene los
requisitos del cliente del sistema.
Involucra comprobacin y revisin de procesos y
pruebas del sistema.
La prueba del sistema involucra la ejecucin del
sistema con casos de prueba, que se derivan de
la especificacin de los datos reales a ser
procesados por el sistema.
12/05/16
158
El proceso de prueba
Prueba
Prueba de
de
componentes
componentes
12/05/16
Prueba
Prueba del
del
sistema
sistema
Prueba
Prueba de
de
aceptacin
aceptacin
159
Fases de prueba
12/05/16
Prueba de componente o unidad

Componentes
individuales
son
probadas
individualmente;
Los componentes pueden ser funciones u objetos
o grupos coherentes de estas entidades.
Pruebas de sistema
Probando en conjunto del sistema. La prueba de
propiedades emergentes es particularmente
importante.
Prueba de aceptacin
Prueba con los datos del cliente para verificar que
el sistema satisface las necesidades del cliente.
160
Fases de prueba
Especificacin de
Especificacin de
requerimientos
requerimientos
Especificacin
Especificacin
del sistema
del sistema
Plan de prueba
Plan de prueba
de aceptacin
de aceptacin
Servicio
Servicio
12/05/16
Diseo del
Diseo del
sistema
sistema
Plan de prueba de
Plan de prueba de
integracin del
integracin del
sistema
sistema
Prueba de
Prueba de
aceptacin
aceptacin
Diseo
Diseo
detallado
detallado
Plan de prueba de
Plan de prueba de
integracin del
integracin del
sub - -sistema
sub - -sistema
Prueba de
Prueba de
integracin del
integracin del
sistema
sistema
Cdigo de
Cdigo de
mdulo y unidad
mdulo y unidad
y pruebas
y pruebas
Prueba de
Prueba de
integracin de
integracin de
Sub - sistema
Sub - sistema
161
Evolucin del software

El
software es inherentemente flexible y puede

cambiar.
Cuando los requisitos cambian a travs de las
circunstancias comerciales cambiantes, el
software que apoya el negocio tambin debe
evolucionar y debe cambiar.
Aunque ha habido una demarcacin entre el
desarrollo y evolucin (mantenimiento), esto es
cada vez ms irrelevante, puesto que menos y
menos sistemas son completamente nuevos.
12/05/16
162

Definicin
Definicinde
de
requerimientos
requerimientos
del
delsistema
sistema
Evaluacin
Evaluacin
de
desistemas
sistemas
existentes
existentes
Proponer
Proponer
cambios
cambiosdel
del
sistema
sistema
Sistema
Sistema
existente
existente
12/05/16
Modificar
Modificar
elel
sistema
sistema
Nuevo
Nuevo
sistema
sistema
163
El Proceso Unificado Rational

Un
modelo de proceso moderno derivado del

trabajo del proceso asociado en UML.
Normalmente descrito desde 3 perspectivas
12/05/16
Una perspectiva dinmica que muestra las fases

sobre el tiempo;
Una perspectiva dinmica que muestra las actividades
del proceso;
Una perspectiva prctica que sugiere la buena
prctica.
164
Modelo de fase RUP

Fase de integracin
Comienzo
12/05/16
Elaboracin
Construccin
Transicin
165
Fases de RUP
Comienzo
Establece el caso comercial para el sistema.
Elaboracin
Desarrolla una comprensin del dominio del problema y

la arquitectura del sistema.
Construccin
Diseo del sistema, programacin y pruebas.
Transicin
12/05/16
Despliegue del sistema en el ambiente que opera.

166
Buena prctica en RUP

Desarrollo
de la iteracin del software

Manejo de requerimientos
Uso
de arquitecturas basadas
componentes
Visualizacin del modelo de software
Verificar la calidad del software
Control de cambios del software
12/05/16
en
167
Flujos de trabajo esttico

Flujos de trabajo
Definicin
Modelamiento del negocio
El proceso y modelamiento del sistema usando casos de uso del negocio.
Requerimientos
Actores que interactan con el sistema son identificados y los casos de uso son
usados para modelar los requerimientos del sistema.
Anlisis y diseo
Un modelo de diseo es creado y documentado usando modelos de arquitectura,

modelos de componentes, modelos de objetos y modelos de secuencia.
Implementacin
Los componentes en el sistemas son implementados y estructurados dentro de los

sub sistemas de implementacin. La generacin automtica de cdigo desde
modelos de diseo ayuda a acelerar el proceso.
Prueba
Las pruebas son un proceso iterativo que es llevado a cabo en conjuncin con
implementacin.
Las pruebas del sistema siguen el completamiento de la
implementacin.
Despliegue
Una descarga del producto es creado, distribuido para usar e instalar en su lugar de
trabajo.
Manejo de configuracin y
cambios
Estos flujos de trabajo de soporte manejan cambios para el sistema (Ver Capitulo 29 ).
Manejo del proyecto
Estos flujos de trabajo de soporte manejan el desarrollo del sistema (Ver Captulo 29).
El ambiente
Este flujo de trabajo concierne al uso apropiado de herramientas de software

disponibles en el equipo de desarrollo del software
12/05/16
168
Ingeniera de software auxiliado

por computadora
CASE (Computer-aided software engineering) es

software para soportar el desarrollo del software y
procesos de evolucin.
Actividades de automatizacin
Editores grficos para desarrollo de modelos de
sistema;
Diccionario de datos para manejar entidades de diseo;
GUI (Interfaz Grfica de Usuario) para construccin de
la interfaz de usuario;
Depuraciones para apoyar el hallazgo de fallas de
programa;
Los traductores automatizados para generar nuevas
versiones de un programa.
12/05/16
169
Tecnologa Case
La tecnologa CASE ha llevado a

mejoras
significativas en el proceso del software. Sin
embargo, stos no son del orden de mejoras de
magnitud que se predijeron una vez.
La ingeniera de software requiere el pensamiento
creativo - esto no se automatiza automticamente;
La ingeniera de software
es una actividad del
equipo y, para los proyectos grandes, mucho
tiempo se consume en las interacciones del
equipo. La tecnologa CASE realmente no apoya
esto.
12/05/16
170
Clasificacin de CASE
La clasificacin nos ayuda a entender los tipos diferentes

de herramientas CASE y su apoyo para las actividades
del proceso.
Perspectiva funcional
Las herramientas son clasificadas segn su funcin
especfica.
Perspectiva de proceso
Las herramientas son clasificadas segn actividades
del proceso que apoyan.
Perspectiva de integracin
Las
herramientas son clasificadas segn su
organizacin dentro de unidades integradas.
12/05/16
171
Clasificacin de
herramientas funcionales
Tipo de herramienta
Ejemplo
Planificacin
Herramientas PERT, herramientas de estimacin, hojas de clculo.
Edicin
Editores de texto, editores grficos, procesadores de palabras.
Cambio de gestin
Herramientas de trazabilidad de requerimientos, sistemas de control de

cambios.
Gestin de
configuracin
Sistemas de gestin de versiones, herramientas de construccin de

sistemas.
Prototipado
Lenguajes de alto nivel, generadores de interfaz de usuario.
Soporte de modelos
Editores de diseo, diccionario de datos, generadores de cdigo.
Lenguaje de procesos
Compiladores, intrpretes.
Anlisis de programa
Generadores de referencia
analizadores dinmicos.
Pruebas
Generadores de datos de prueba, comparadores de archivos.
Depuracin
Sistemas de depuracin interactivos.
Documentacin
Programas de configuracin de pgina, editores de imagen.
Reingeniera
Sistemas de referencia cruzada, sistemas de reestructuracin de

programas.
172
12/05/16
cruzada,
analizadores
estticos,
Clasificacin de herramientas
basadas en actividades
Herramientas de reingeniera
Herramientas de prueba
Herramientas de depuracin
Herramientas de anlisis de programas
Herramientas de lenguaje de procesos
Herramientas de soporte de mtodos
Herramientas de prototipado
Herramientas de gestin de configuracin
Herramientas de gestin de cambios
Herramientas de documentacin
Herramientas de edicin
Herramientas de planificacin
Especificacin Diseo Implementacin
12/05/16
Verificacin y
validacin
173
Integracin CASE
Herramientas
Soporte a tareas del proceso individuales como el
diseo de verificacin de consistencia, edicin de texto,
etc.,
Bancos de trabajo
Soporte a fases de procesos tales como especificacin o
diseo. Normalmente varias herramientas integradas.
Ambientes
Soporte a todo o una parte sustancial de un proceso
entero de software. Normalmente incluya que algunos
bancos de trabajo integrados.
12/05/16
174
Herramientas, bancos de trabajo,

ambientes
Tecnologa
Tecnologa
CASE
CASE
Herramientas
Herramientas
Editores
Editores
Compiladores
Compiladores
Bancos de
Bancos de
trabajo
trabajo
Comparadores
Comparadores
de archivo
de archivo
Anlisis y
Anlisis y
Diseo
Diseo
Bancos de trabajo
Bancos de trabajo
Multi - mtodos
Multi - mtodos
12/05/16
Ambientes
Ambientes
integrados
integrados
Programacin
Programacin
Bancos de trabajo
Bancos de trabajo
unimodelo
unimodelo
Ambientes
Ambientes
Ambientes de
Ambientes de
procesos centrados
procesos centrados
Pruebas
Pruebas
Bancos de trabajo de
propsito general
propsito general
lenguajes especficos
lenguajes especficos
175
Puntos clave
Los procesos del software son las actividades

involucradas en la produccin y desenvolvimiento de un
sistema del software.
Los modelos de proceso de software son
representaciones abstractas de estos procesos.
Las actividades generales son especificacin, diseo e
implementacin, validacin y evolucin.
Los modelos del proceso genricos describen la
organizacin de procesos de software. Los ejemplos
incluyen el modelo de cascada, desarrollo evolutivo, y la
ingeniera del software basada en componentes.
Los modelos del proceso iterativos describen el proceso
del software como un ciclo de actividades.
12/05/16
176
Puntos clave
La ingeniera de requerimientos es el proceso de

desarrollar una especificacin del software.
El proceso de diseo e implementacin transforman la
especificacin en un programa ejecutable.
La validacin involucra comprobacin que el sistema se
encuentra de acuerdo a su especificacin y necesidades
del usuario.
La evolucin se preocupa por modificar el sistema
despus de que est en el uso.
El Proceso Unificado Rational es un modelo de proceso
genrico que separa las actividades de las fases.
La tecnologa CASE da soporte a las actividades de
proceso de software.
12/05/16
177
Captulo 5
Gestin de
Proyectos
12/05/16
178
Objetivos
Explicar las tareas principales emprendidas por gerentes
del proyecto.
Introducir la de gestin del proyecto de software y
describir sus caractersticas distintivas.
Discutir la planificacin del proyecto y el proceso de la
planificacin.
Mostrar cmo las representaciones del horario grficas
son usadas por la gestin del proyecto.
Discutir la nocin de riesgos y el proceso de direccin de
riesgo.
12/05/16
179
Tpicos cubiertos
Actividades
de gestin
Planificacin del proyecto
Programacin del proyecto
Gestin de riesgos
12/05/16
180
Gestin del proyecto de

software
Concierne
a las actividades involucradas que

aseguren que el software se entrega a tiempo y
dentro de lo planificado y de acuerdo con los
requerimientos
de
las
organizaciones,
desarrollando y procurando el software.
La gestin del proyecto se necesita porque el
desarrollo del software siempre est sujeto al
presupuesto y restricciones del horario que son
fijadas por la organizacin que desarrolla el
software.
12/05/16
181
Distinciones en la gestin del

software
El producto es intangible.
El producto es singularmente flexible.
La ingeniera de software se reconoce como una
disciplina de ingeniera con el estado sensato

como la ingeniera mecnica, elctrica, etc.,
El proceso de desarrollo de software no est
estandarizado
Muchos proyectos de software son intentos
nicos de proyectos.
12/05/16
182
Actividades de gestin
Escritura
de la propuesta.
Planificacin y programacin del proyecto.
Clculo de costos del proyecto.
Monitoreo del proyecto y revisiones.
Seleccin y evaluacin del personal.
Escritura del informe y presentaciones.
12/05/16
183
Comunidad de gestin
Estas
actividades no son peculiares a la gestin

del software.
Muchas tcnicas de gestin de ingeniera de
proyectos son igualmente aplicables a la
direccin de proyectos de software.
Tcnicamente los sistemas de la ingeniera
complejos tienden a padecer los mismos
problemas de los sistemas del software.
12/05/16
184
Provisin de personal al
proyecto
Pueda no ser posible fijar a las personas ideales para

trabajar en un proyecto.
El presupuesto del proyecto puede no permitir el uso
de personal altamente - pagado;
Personal con la experiencia apropiada puede no estar
disponible;
Un
organizacin puede desear desarrollar las
habilidades del empleado en un proyecto de software.
Los gerentes tienen que trabajar sobre todo dentro de
estas restricciones cuando hay escaseces de personal
especializado.
12/05/16
185

Probablemente la actividad de gestin de proyecto de
mayor consumo de tiempo.
La actividad continua desde el concepto inicial a
travs de a la entrega del sistema. Los planes deben
revisarse regularmente como la nueva informacin
est disponible.
Pueden desarrollarse varios tipos diferentes de planes
para apoyar el plan principal de proyecto de software
que se preocupa por el programa y presupuesto.
12/05/16
186
Tipos de planes de proyecto

Plan
Descripcin
Plan de calidad
Describe los procedimientos de calidad y

estndares que sern usados en un proyecto. Ver
Captulo 27.
Plan de validacin
Describe la aproximacin, recursos y programa

usadas para validar un sistema. Ver Captulo 22.
Plan de gestin de
configuracin
Describe los procedimientos de gestin de

configuracin y estructuras a ser usadas. Ver
Captulo 29.
Plan de
mantenimiento
Predice los requerimientos de mantenimiento de

los sistemas, costos de mantenimiento, y el
esfuerzo requerido. Ver Captulo 21.
Plan de desarrollo
de personal
Describe cmo las habilidades y experiencia de

los miembros de equipos de proyecto sern
desarrolladas. Ver Captulo 25.
12/05/16
187
Procesos de planificacin
de proyectos
Establecer restricciones del proyecto
Hacer valoraciones iniciales de los parmetros del proyecto
Definir hitos del proyectos y entregables
Mientras el proyecto no ha sido terminado o cancelado ciclo
Preparar el programa el proyecto
Iniciar actividades de acuerdo al proyecto
Esperar (Durante un tiempo)
Revisin del progreso del proyecto
Revisar estimaciones de parmetros del proyecto
Actualizar el programa del proyecto
Renegociar las restricciones y las entregas
Si (problemas surgen) entonces
Iniciar repaso tcnico y posible revisin
Fin de Si
Fin de ciclo
12/05/16
188
El plan del proyecto

Empezar
el plan del proyecto

Los
recursos disponibles
proyecto;
La avera de trabajo;
Un programa para el trabajo.
12/05/16
del
189
Estructura del plan del

Proyecto
Introduccin.
Organizacin
del proyecto.
Anlisis de riesgo.
Requerimientos de recursos de hardware y
software.
Averas de trabajo.
Programa de proyecto.
Mecanismos de monitoreo e informes.
12/05/16
190
Organizacin de actividad
Las
actividades de un proyecto deben

organizarse para producir salidas tangibles
por la gestin para juzgar el progreso.
Los hitos son el punto final de una actividad
del proceso.
Los entregables son resultados del proyecto
entregados a clientes.
El proceso de cascada permite la definicin
sincera de hitos de progreso.
12/05/16
191
Hitos en el Reproceso
Actividades
Estudio
Estudiode
de
factibilidad
factibilidad
Informe
Informede
de
factibilidad
factibilidad
Anlisis
Anlisisde
de
requerimientos
requerimientos
Requerimientos
Requerimientos
de
deusuario
usuario
Desarrollo
Desarrollode
de
prototipo
prototipo
Informe
Informede
de
evaluacin
evaluacin
Estudio
Estudiode
de
diseo
diseo
Diseo
Diseo
arquitectnico
arquitectnico
Especificacin
Especificacinde
de
requerimientos
requerimientos
Requerimientos
Requerimientos
del
delsistema
sistema
Hitos
12/05/16
192
La programacin del
proyecto
Dividir
el proyecto en tareas y estimar el tiempo y

recursos requeridos para completar cada tarea.
Organizar las tareas concurrentemente para hacer
uso ptimo de la mano de obra.
Minimizar las dependencias entre tareas para
evitar retrasos causados por una tarea que espera
a otra para ser completada.
Dependencia del proyecto
en la intuicin y
experiencia de los gerentes.
12/05/16
193
El proceso de
programacin del proyecto
Identificacin
Identificacin
de
delas
las
actividades
actividades
Identificacin
Identificacinde
de
las
lasdependencia
dependencia
de
delas
lasactividades
actividades
Estimacin
Estimacinde
de
los recursos
los recursos
para
paraactividades
actividades
Requerimientos
de software
12/05/16
Colocacin
Colocacinde
de
gente en las
gente en las
actividades
actividades
Creacin
Creacinde
de
diagramas
diagramasdel
del
proyecto
proyecto
Grficas de
actividades y grficas
de barras
194
Problemas de programacin
Estimar
la dificultad de problemas y del costo de

desarrollo de una solucin es duro.
La productividad no es proporcional al nmero de
las personas que trabajan en una tarea.
Agregar personas a hechos tardos del proyecto
lo retrasa debido a gastos de comunicacin.
El inesperado siempre ocurre. Siempre permitir
la contingencia en la planificacin.
12/05/16
195
Grficas de barra y redes de

actividades
Las
notaciones grficas son usadas para ilustrar

la programacin de proyectos.
Mostrar las averas del proyecto en las tareas.
Las tareas no deben ser demasiado pequeas.
Ellos deben tomar entre una semana o dos.
Los
grficos de actividad muestran las
dependencias entre las tareas y el camino crtico.
Los grficos de barra muestran la programacin
contra el tiempo de calendario.
12/05/16
196
Duracin de tareas y dependencias
12/05/16
Actividad
Duracin (das)
Inicio
T1
Inicio
T2
15
Inicio
T3
15
T1
T4
10
Inicio
T5
10
T2, T4
T6
T1, T2
T7
20
T1
T8
25
T4
T9
15
T3, T6
T10
15
T5, T7
T11
T9
10
T11
T8, T10,T12
T12
Final
Dependencias
197
Red de actividades
12/05/16
198
Calendario de Actividades
12/05/16
199
Asignacin de personal
12/05/16
200
Gestin de riesgos
La
gestin de riesgos se preocupa por identificar

los riesgos y preparar planes para minimizar su
efecto en un proyecto.
Un riesgo es una probabilidad que ocurrir
alguna circunstancia adversa.
12/05/16
Los riesgos del proyecto afectan programa

(calendario) o recursos;
Los riesgos del producto afectan la calidad o el
desempeo del software que est desarrollndose;
Los riesgos comerciales afectan el desarrollo de la
organizacin o la procura del software.
201
Riesgos del software

Riego
Afectados
Descripcin
Produccin personal
Proyecto
El personal experimentado dejar el proyecto antes que

est acabado.
Cambio de gestin
Proyecto
Habr un cambio en la gestin de la organizacin

diferentes prioridades.
Indisponibilidad del
hardware
Proyecto
Hardware que es esencial para el proyecto no ser

entregado de acuerdo a la programacin.
Cambio de
requerimientos
Proyecto
producto
y Habr un gran nmero de cambios en los requerimientos

que se anticiparon.
Retrasos de la
especificacin
Proyecto y
producto
Especificaciones de interfaces
disponibles en la programacin.
Tamao subestimado
Proyecto y
producto
El tamao del sistema ha sido subestimado.
Bajo desempeo de
herramientas CASE
Producto
Las herramientas CASE que dan soporte al proyecto no

tienen el desempeo esperado.
Cambio de tecnologa
Negocio
La tecnologa subyacente para la construccin del

sistema, ha sido superado por nuevas tecnologas.
Competencia de
producto
Negocio
Un producto de la competencia es marketeado antes que

el sistema haya sido entregado.
12/05/16
esenciales
no
con
estas
202
El proceso de gestin de
riesgos
Identificacin de riesgos
Identificacin de riesgos del proyecto, del producto
y del negocio;
Anlisis de riesgos
Evaluar la probabilidad y consecuencias de estos
riesgos;
Planificacin de riesgos
Preparar los planes para evitar o minimizar los
efectos de los riesgos;
Monitoreo de riesgos
Monitorear los riesgos a travs del proyecto.
12/05/16
203
El proceso de gestin de
riesgos
Identificacin
Identificacin
de
deriesgos
riesgos
Lista
Listade
deriegos
riegos
potenciales
potenciales
12/05/16
Anlisis
Anlisisde
de
riesgos
riesgos
Lista
Listade
deriegos
riegos
prioritarios
prioritarios
Planificacin
Planificacin
de
deriesgos
riesgos
Anulacin
Anulacinde
de
riesgos
y
planes
riesgos y planesde
de
contingencia
contingencia
Monitoreo
Monitoreo
de
deriesgos
riesgos
Valoracin
Valoracin
de
deriesgos
riesgos
204
Identificacin de riesgos
Riesgos
tecnolgicos.
Riesgos de personas.
Riesgos organizacionales.
Riesgos de requerimientos.
Riesgos de estimacin.
12/05/16
205
Tipos de riesgos
Tipo de riesgo
Posibles riesgos
Tecnolgico
La base de datos usada en el sistema no puede procesar muchas transacciones

por segundo como se estera.
Los componentes de software que van a ser reusadas contienen defectos que
limitan su funcionalidad.
Personas
Es imposible reclutar personas con las habilidades requeridas.

El personal importante est enfermo e indisponible.
El entrenamiento requerido para las personas no est disponible
Organizacional
La organizacin es reestructurada, de modo que diferentes gestiones son

responsables para el proyecto.
Problemas funcionales de organizacin fuerzan a reducir el presupuesto del
proyecto.
Herramientas
El cdigo generado por las herramientas CASE es deficiente.

Las herramientas CASE no pueden ser integradas.
Requerimientos
Los cambios de requerimientos que requieren mayor diseo proponen retrabajo.

Los clientes no entienden el impacto de los cambios de requerimientos.
Estimacin
El tiempo requerido para desarrollar el software es subestimado.

La tasa de reparacin de fallas es subestimada.
El tamao del software es subestimado.
12/05/16
206
Anlisis de riesgos
Evaluar
la probabilidad y seriedad de
cada riesgo.
La probabilidad puede ser muy baja,
baja, moderada, alta o muy alta.
Los efectos de riesgo podran ser
catastrficos, serios, tolerables o
insignificantes.
12/05/16
207
Anlisis de riesgos (i)

Riesgo
Probabilidad
Efectos
Problemas funcionales de organizacin fuerzan Baja

a reducir el presupuesto del proyecto.
Catastrfico
Es imposible reclutar
habilidades requeridas.
Catastrfico
personas
con
las Alta
Personal importante est enfermo en tiempos Moderada

crticos del proyecto.
Serio
Los componentes de software que van a ser Moderada

reusados contienen defectos que limitan su
funcionalidad.
Serio
Los cambios de requerimientos que requieren Moderada

mayor diseo proponen retrabajo.
Serio
La organizacin es reestructurada, de modo que Alta

diferentes gestiones son responsables para el
proyecto.
Serio
12/05/16
208
Anlisis de riesgos (ii)

Riesgo
Probabilidad
Efectos
La base de datos usada en el sistema no puede Moderada

procesar muchas transacciones por segundo como
se estera.
Serio
El tiempo requerido para desarrollar el software es Alta

subestimado.
Serio
Las herramientas CASE no pueden ser integradas.
Tolerable
Alta
Los clientes no entienden el impacto de los Moderada

cambios de requerimientos.
Tolerable
El entrenamiento requerido para las personas no Moderada

est disponible
Tolerable
La tasa de reparacin de fallas es subestimada.
Moderada
Tolerable
El tamao del software es subestimado.
Alta
Tolerable
El cdigo generado por las herramientas CASE es Moderada

deficiente.
12/05/16
Insignificante
209
Planificacin de riesgos
Considerar
cada riesgo y desarrollar una

estrategia para manejar ese riesgo.
Estrategias de anulacin
La probabilidad que el riesgo surgir es reducida;
Estrategias
El impacto del riesgo en el proyecto o el producto ser

reducido;
Planes
12/05/16
de minimizacin
de contingencia
Si el riesgo surge, los planes de contingencia son

planeados para tratar con ese riesgo.
210
Estrategias de gestin de riesgos (i)

Riesgo
Estrategia
Problemas
financieros de
organizacin
Preparar un documento de informacin para la alta

direccin mostrando cmo los proyectos son
hechos como una contribucin muy importante para
alcanzar las metas de los negocios.
Problemas de
reclutamiento
Alertar a los clientes de potenciales dificultades y

las posibilidades de retrasos, investigar compra en
componentes.
Enfermedad
del personal
Reorganizar el equipo de trabajo de modo que haya

solapamiento de trabajo y gente y por consiguiente
hay entendimiento del trabajo.
Componentes
defectuosos
Remplazar potenciales componentes defectuosos

con compra de componentes de conocida fiabilidad.
12/05/16
211
Estrategias de gestin de riesgos (ii)

Riesgo
Cambio de
requerimientos
Estrategia
Derivar la informacin de trazabilidad para
evaluar
el
impacto
de
cambio
de
requerimientos , maximizar la informacin oculta
en el diseo.
Reestructuracin Preparar un documento de informacin para la

organizacional
alta direccin mostrando cmo los proyectos
son hechos como una contribucin muy
importante para alcanzar las metas de los
negocios.
Desempeo de
base de datos
Tiempo de
desarrollo
subestimado
12/05/16
Investigar la posibilidad de compra una base de

datos de alto desempeo.
Investigar compra de componentes, investigar
el uso de un generador de programas.
212
Monitoreo de riesgos
Evaluar
cada uno de los riesgos

identificados regularmente para decidir si
est o no volvindose menos o ms
probable.
Tambin evaluar si los efectos del riesgo
han cambiado.
Cada riesgo importante debe discutirse en
las reuniones de progreso de gestin.
12/05/16
213
Indicadores de riesgo
Tipo de riesgo
Indicadores potenciales
Tecnologa
Entrega tarda de hardware o soporte de software,

muchos problemas tcnicos reportados.
Gente
Pobre moral del personal, pobre interrelacin entre

los miembros del equipo, disponibilidad de trabajo.
Organizacin
Chisme organizacional, falta de accin de la alta

direccin.
Herramientas
Repugnancia de los miembros del equipo a usar

herramientas , quejas sobre herramientas CASE,
demandas de estaciones de trabajo de alto
rendimiento.
Requerimientos
Muchas demandas de cambio de requerimientos,

quejas de clientes.
Estimacin
Fracaso para reunirse en el horario acordado, falla

paraIng.borrar
defectos
de reporte.
Otoniel Silvalos
Delgado
- Ing. Ivan Pino Tellera
214
12/05/16
Puntos clave
La
buena gestin del proyecto es esencial para el

xito del proyecto.
La naturaleza intangible del software causa
problemas para la gestin.
Los gerentes tienen diversos papeles, pero sus
actividades ms significativas estn planeadas,
estimadas y programadas.
La planificacin y estimacin son procesos
iterativos que continan a lo largo del curso de un
proyecto.
12/05/16
215
Puntos clave
Un hito del proyecto es un estado predecible dnde
un informe formal del progreso se presenta a la
direccin.
La programacin del proyecto involucra preparar
varias representaciones grficas que muestran las
actividades del proyecto, sus duraciones y asignacin
de personal.
La gestin de riesgo se preocupa por identificar
riesgos que pueden afectar el proyecto y planificar
para asegurar que estos riesgos no se conviertan en
amenazas mayores.
12/05/16
216
Captulo 6
Requerimientos
de software
12/05/16
217
Objetivos
Introducir
los conceptos of usuario y

Describir requerimientos funcionales y
no funcionales
Explicar
cual requerimientos de
software pueden ser organizados en
un documento de requerimientos
12/05/16
218
Tpicos cubiertos
Requerimientos
funcionales
no
funcionales
Requerimientos de usuario
Requerimientos del sistema
Especificacin de la interfaz
Documento de requerimientos de software
12/05/16
219
Ingeniera de
requerimientos
El
proceso de establecer los servicios que el

cliente requiere de un sistema y las
restricciones bajo las cuales opera y se
desarrolla.
Los requerimientos por si mismos son las
descripciones de los servicios del sistema y
las restricciones que se generan durante el
proceso de ingeniera de requerimientos.
12/05/16
220
Qu es un requerimiento?
Puede ir de una declaracin abstracta de alto nivel de un

servicio o de una restriccin del sistema a una
especificacin funcional matemtica detallada.
Es inevitable que los requisitos puede servir a una funcin
dual
Pueda ser la base para una oferta de un contrato - por
consiguiente debe estar abierto a la interpretacin;
Pueda ser la base para el propio contrato - por
consiguiente debe definirse en detalle;
Ambas
estas
declaraciones
pueden
llamarse
requerimientos.
12/05/16
221
Abstraccin de
requerimientos (Davis)
Si una compaa desea firmar un contrato para un proyecto
grande de desarrollo de software, debe definir sus
necesidades de una manera suficientemente abstracta que
una solucin no se predefina. Los requerimientos deben
escribirse para que varios contratistas puedan ofrecerse
para el contrato, ofreciendo, quizs, maneras diferentes de
satisfacer las necesidades de la organizacin del cliente.
Una vez un contrato se ha otorgado, el contratista debe
escribir para el cliente una definicin del sistema con ms
detalle para que el cliente entienda y puede validar lo que el
software har. Estos dos documentos pueden llamarse
documento de requerimientos para el sistema ".
12/05/16
222
Tipos de requerimientos
Requerimientos
Las declaraciones en el idioma natural ms los

diagramas de los servicios que el sistema proporciona
y sus restricciones operacionales. Escrito para
clientes.
Requerimientos
12/05/16
de usuario
del sistema
Un documento estructurado con las descripciones

detalladas de las funciones del sistema, servicios y
restricciones operacionales. Define lo que debe
llevarse a cabo para que puede ser parte de un
contrato entre el cliente y contratista.
223
Definiciones y especificaciones
Definicin de requerimientos de usuario
1.1.
El
El software
software be
be proporcionar
proporcionar los
los medios
medios de
de representar
representar yyacceder
acceder aa archivos
archivos externos
externos
creados
por
otras
herramientas
creados por otras herramientas
Especificacin de requerimientos del sistema

1.1
1.1 El
Elusuario
usuariodebe
debeproporcionar
proporcionarfacilidades
facilidadespara
paradefinir
definireleltipo
tipode
dearchivos
archivosexternos.
externos.
1.2
1.2 Cada
Cadatipo
tipode
dearchivo
archivoexterno
externopuede
puedetener
teneruna
unaherramienta
herramientaasociada
asociadalalacual
cualse
seaplica
aplicaalal
archivo.
archivo.
1.3
1.3 Cada
Cada tipo
tipode
de archivo
archivo externo
externo puede
puedeser
ser representado
representadocon
conun
un icono
icono especificado
especificado en
en lala
visual
visualdel
delusuario.
usuario.
1.4
1.4
Pueden
Puedenser
serproporcionadas
proporcionadasfacilidades
facilidadespara
pararepresentar
representarelelicono
iconoen
enun
untipo
tipode
dearchivo
archivo
externo
definido
por
el
usuario.
externo definido por el usuario.
1.5
1.5 Cuando
Cuandoelelusuario
usuarioselecciona
seleccionaun
unicono
iconoque
querepresenta
representaun
un archivo
archivoexterno,
externo,elelefecto
efectode
de
esta
seleccin
es
para
aplicar
la
herramienta
asociada
con
el
tipo
de
archivo
externo
para
esta seleccin es para aplicar la herramienta asociada con el tipo de archivo externo para
elelarchivo
archivorepresentado
representadopor
porelelicono
iconoseleccionado.
seleccionado.
12/05/16
224
Lectores de requerimientos
Requerimientos
Requerimientos
de
deusuario
usuario
Gestin
Gestindel
delcliente
cliente
Usuarios
Usuariosfinales
finalesdel
delsistema
sistema
Ingenieros
Ingenierosdel
delcliente
cliente
Gerentes
Gerentesde
decontrato
contrato
Arquitectos
Arquitectos del
delsistema
sistema
Requerimientos
Requerimientos
del
delsistema
sistema
Especificacin
Especificacin
del
deldiseo
diseode
de
software
software
12/05/16
Usuarios
Usuariosfinales
finalesdel
delsistema
sistema
Ingenieros
Ingenierosdel
delcliente
cliente
Arquitectos
Arquitectos del
delsistema
sistema
Desarrolladores
Desarrolladoresde
desoftware
software
Ingenieros
Ingenierosdel
delcliente
cliente(quizs)
(quizs)
Arquitectos
Arquitectos del
delsistema
sistema
Desarrolladores
Desarrolladoresde
desoftware
software
225
Los requerimientos funcionales

y no funcionales
Requerimientos Funcionales
Las declaraciones de servicios que el sistema debe
proporcionar, cmo el sistema debe reaccionar a entradas
particulares y cmo el sistema debe comportarse en
situaciones.
Requerimientos no funcionales
Las restricciones en los servicios o funciones ofrecidas por
el sistema como cronometrar las restricciones, las
restricciones en el proceso de desarrollo, estndares, etc.
Requerimientos del dominio
Requerimientos que vienen del dominio de la aplicacin del
sistema y que refleje las caractersticas de ese dominio.
12/05/16
226
Requerimientos funcionales
Describe
la funcionalidad o servicios del sistema.

Depende
del tipo del software, usuarios
esperados y el tipo de sistema dnde el software
se usa.
Los requerimientos
funcionales del usuario
pueden ser declaraciones de alto nivel, de lo que
el sistema debe hacer, pero los requerimientos
funcionales del sistema deben describir los
servicios del sistema en detalle.
12/05/16
227
Los sistemas LIBSYS

Un
sistema de librera (LIBSYS) que

proporciona una sola interfaz a varios
bases de datos de artculos en
diferentes libreras.
Los usuarios pueden buscar, pueden
bajar y pueden imprimir estos
artculos para el estudio personal.
12/05/16
228
Ejemplos de requerimientos
funcionales
El
usuario podr ser capaz de

investigar
cualquiera de todo conjunto inicial de bases de
datos o seleccionar un subconjunto de l.
El
sistema
proporcionar
visualizadores
apropiados para que el usuario pueda leer los
documentos en el almacn del documento.
cada orden se asignar un nico identificador

(ORDER_ID) qu el usuario podr copiar al rea
del almacenamiento permanente de la cuenta.
12/05/16
229
Imprecisin de los
requerimientos
Los
problemas surgen cuando los requerimientos no

se declaran con precisin.
Los requerimientos ambiguos pueden interpretarse
de
maneras diferentes por desarrolladores y
usuarios.
Considerar
el trmino los visualizadores
apropiados
12/05/16
La intencin del usuario - el visualizador del propsito

especial para cada tipo del documento diferente;
La interpretacin del diseador - Proporciona un
visualizador del texto que muestra los volmenes del
documento.
230
Completitud y consistencia
de los requerimientos
En principio, los requerimientos deben estar completos y

consistentes.
Completo
Ellos deben incluir las descripciones de todos las
recursos requeridos.
Consistente
No debe haber ningn conflicto o contradicciones en
las descripciones de los recursos del sistema.
En la prctica, es imposible producir un documento de
requerimientos completo y consistente.
12/05/16
231
Requerimientos no
funcionales
stos definen propiedades del sistema y restricciones,

por ejemplo la fiabilidad, tiempo de respuesta y
requerimientos del almacenamiento. Las restricciones
son son la capacidad de dispositivo I/O (entrada/salida),
las representaciones del sistema, etc.
Los requerimientos de proceso tambin pueden ser
especificados asignando un sistema CASE particular, un
lenguaje de programacin o un mtodo de desarrollo.
Los requerimientos no funcionales pueden ser ms
crticos que los requerimientos funcionales. Si stos no
se renen, el sistema es intil.
12/05/16
232
Clasificaciones no
funcionales
Requerimientos del producto

Requerimientos que especifican que el producto entregado
debe comportarse de una manera particular por ejemplo la
velocidad de la ejecucin, la fiabilidad, etc.
Requerimientos organizacionales
Requerimientos que son una consecuencia de polticas
organizacionales y procedimientos, por ejemplo las
estndares del proceso usados, requerimientos de
aplicacin, etc.
Requerimientos externos
Requerimientos que surgen de factores que son externos al
sistema y su proceso de desarrollo, por ejemplo los
requerimientos de interoperabilidad, los requerimientos
legales, etc.
12/05/16
233
Tipos de requerimientos no
funcionales
Requerimientos
Requerimientos
no funcionales
no funcionales
Requerimientos
Requerimientos
del producto
del producto
Requerimientos
Requerimientos
de eficiencia
de eficiencia
Requerimientos
Requerimientos
de fiabilidad
de fiabilidad
Requerimientos
Requerimientos
organizacionales
organizacionales
Requerimientos
Requerimientos
de portabilidad
de portabilidad
Requerimientos
Requerimientos
externos
externos
Requerimientos de
Requerimientos de
interoperabilidad
interoperabilidad
Requerimientos
Requerimientos
ticos
ticos
Requerimientos
Requerimientos
legales
legales
Requerimientos
Requerimientos
de utilidad
de utilidad
Requerimientos
Requerimientos
de entrega
de entrega
Requerimientos
Requerimientos
de desempeo
de desempeo
12/05/16
Requerimientos de
Requerimientos de
implementacin
implementacin
Requerimientos
Requerimientos
estndar
estndar
Requerimientos
Requerimientos
de privacidad
de privacidad
Requerimientos
Requerimientos
de espacio
de espacio
Requerimientos de
Requerimientos de
seguridad fsica
seguridad fsica
234
Ejemplos de requerimientos no
funcionales
Requerimientos del producto

8.1 La interfaz del usuario para LIBSYS ser implementado
como HTML simple sin marcos o applets (aplicaciones o
para Internet) de Java.
Requerimientos organizacionales
9.3.2 El proceso de desarrollo de sistema y los documentos
entregables conforme al proceso y los entregables definidos
en XYZCo-SP-STAN-95.
Requerimientos externos
7.6.5 El sistema no descubrirn informacin personal sobre
clientes aparte de su nombre y nmero de referencia para
operadores del sistema.
12/05/16
235
Metas y requerimientos
Los requerimientos no funcionales pueden ser muy

difciles de declarar con precisin y los requerimientos
imprecisos pueden ser difciles de verificar.
Meta
Una intencin general del usuario como la facilidad de
uso.
Requerimiento no funcional verificable
Una declaracin que usa alguna medida que puede
probarse objetivamente.
Las metas son tiles a desarrolladores cuando ellos
llevan las intenciones de los usuarios del sistema.
12/05/16
236
Ejemplos
Una meta del sistema
El sistema debe ser fcil de usar por los directores
experimentados y debe organizarse de tal manera que
se minimizan los errores del usuario.
Un requerimiento no funcional verificable
Los directores experimentados podrn usar todas las
funciones del sistema despus de un total de dos horas
de entrenamiento . Despus de este entrenamiento, el
nmero promedio de errores cometidos por los usuarios
experimentados no exceder de dos por da.
12/05/16
237
Medidas de requerimientos
Propiedad
Medida
Velocidad
Transacciones/segundo procesadas.
Tiempo de respuesta usuario/evento.
Tiempo de refrescamiento de pantalla.
Tamao
MBytes.
N de chips ROM.
Facilidad de uso
Tiempo de entrenamiento.
Nmero de marcos de ayuda.
Fiabilidad
Tiempo promedio de falla.

Probabilidad de indisponibilidad.
Tasa de ocurrencia de falla.
Disponibilidad.
Robustez
Tiempo de reinicio despus de falla.

Porcentaje de eventos causados por falla.
Probabilidad de corrupcin de datos en falla.
Portabilidad
Porcentaje de declaraciones dependientes de objetivo.

Numero de objetivos del sistema.
12/05/16
238
Interaccin de
requerimientos
Los conflictos entre los diferentes requerimientos no
funcionales diferentes comunes en los sistemas complejos.
Sistema de nave espacial
Para minimizar el peso, el nmero de chips separados
en el sistema debe minimizarse.
Para minimizar el consumo de energa, deben usarse
chips del ms bajo poder.
Sin embargo, el uso de chips de bajo poder puede
significar que ms chips tienen que ser usadas. Cual es
el requerimiento ms crtico?
12/05/16
239
Requerimientos del
dominio
Derivado
del dominio de aplicacin y describe las

caractersticas del sistema y rasgos que refleja el
dominio.
Los requerimientos del dominio son los nuevos
requerimientos funcionales, restricciones en los
requerimientos existentes o define cmputos
especficos.
Si los requerimientos
del dominio no estn
satisfechos, el sistema puede ser inexplotable.
12/05/16
240
Requerimientos del dominio

del sistema de librera
Habr
una interfaz de usuario estndar a todas

los bases de datos que sern basados en la
norma Z39.50.
Debido a las restricciones del derechos de
propiedad, algunos documentos deben anularse
inmediatamente en la llegada. Dependiendo de
los requerimientos de usuario, estos documentos,
o se imprimirn localmente en el servidor del
sistema para remitir a mano al usuario, o se
enviarn a una impresora de la red.
12/05/16
241
Tren del sistema de proteccin

La
desaceleracin del tren se calcular

como:
Dtren = Dcontrol + Dgradiente

donde Dgradiente tiene 9.81ms2 aos *
gradiente/alpha compensado y donde los
valores de 9.81ms2 /alpha son conocidos
por los tipos diferentes de tren.
12/05/16
242
Problemas de
requerimientos del dominio
Entendibilidad
Los requerimientos son expresados en el lenguaje del

dominio de aplicacin;
Esto a menudo no es entendido por los ingenieros de
software que desarrollan el sistema.
Implicitidad
12/05/16
Los especialistas del dominio entienden tan bien el

rea, que no piensan en la fabricacin de los
requerimientos explcitos del dominio .
243
Requerimientos del usuario

Debe
describirse los requerimientos funcionales

y no funcionales de tal una manera que sean
entendibles por los usuarios del sistema que no
tienen detallado el conocimiento tcnico.
Los requerimientos del usuario son definidos
usando lenguaje natural, tablas y diagramas de
modo que stos puedan ser entendidos por todos
los usuarios.
12/05/16
244
Problemas con el lenguaje

natural
Falta
de claridad
La precisin es difcil sin hacer que el
documento sea difcil de leer.
Confusin de requerimientos
Los requerimientos funcionales y no funcionales
tienden a ser confundidos.
La fusin de requerimientos
Pueden expresarse juntos varios requerimientos
diferentes.
12/05/16
245
Requerimientos de LIBSYS
4 ..5 LIBSYS proporcionar un sistema
de contabilidad financiero que mantiene
archivos de todos los pagos hecho por
los usuarios del sistema. Los gerentes
del sistema pueden configurar este
sistema para que los usuarios regulares
puedan recibir las tasas descontadas.
12/05/16
246
Requerimientos del editor

de rejilla
2.6 Soporte de rejilla: Para ayudar en el posicionamiento
de entidades en un diagrama, el usuario puede mover
una rejilla en centmetros o pulgadas, va una opcin en
el panel de control. Inicialmente, la rejilla est
desactivada. La rejilla puede ponerse en on /off cuando
se quiera durante una sesin de edicin y puede ser
intercambiada entre pulgadas y centmetros cuando se
quiera. Una opcin de rejilla se proporcionar en la vista
del reducir al ataque pero el nmero de lneas de la rejilla
mostrados se reducir para evitar el relleno del diagrama
ms pequeo con las lneas de la rejilla.
12/05/16
247
Problemas de
requerimientos
Los requerimientos de la base de datos incluyen informacin

conceptual y detallada
Describe el concepto de un sistema de contabilidad
financiera que ser incluido en LIBSYS;
Sin embargo, tambin incluye el detalle que los gerentes
pueden configurar en este sistema - esto es innecesario a
este nivel.
El requerimiento de la rejilla mezcla tres tipos diferentes de
requerimiento
El requerimiento funcional conceptual (la necesidad para
una rejilla);
El requerimiento no funcional (unidades de rejilla);
El requerimiento no funcional de UI (rejilla que cambia).
12/05/16
248
Presentacin estructurada
2.6.1 Recursos de rejilla
El editor proporcionar un recurso de rejilla dnde una matriz de
lneas horizontales y verticales proporciona un fondo a la ventana
del editor. Esta rejilla ser una rejilla pasiva dnde la alineacin
de entidades es la responsabilidad del usuario.
La razn: Una rejilla ayuda para que el usuario cree un diagrama
ordenado con las entidades bien espaciadas. Aunque una rejilla
activa dnde las entidades estn 'partidas en' las lneas de la
rejilla pueden ser tiles, el posicionamiento es impreciso. El
usuario es la
mejor persona para decidir donde deben
posicionarse las entidades.
La especificacin: ECLIPSE /WS /Tools/DE/FS Seccin 5.6
La fuente: Ray Wilson, la Oficina de Glasgow.
12/05/16
249
Pautas para escribir los

requerimientos
Inventar
un formato estndar y usarlo para todos

los requerimientos.
Usar el lenguaje de una manera consistente. El
uso debe ser para los requerimientos
obligatorios, para los requerimientos deseables.
Usar texto resaltado para identificar partes
importantes de los requerimientos.
Evitar el uso de jerga de computadora.
12/05/16
250
Requerimientos del
sistema
Las
especificaciones ms detalladas de
funciones del sistema, servicios y restricciones
que los requerimientos del usuario.
Se piensa que ellos son una base por disear el
sistema.
Ellos pueden incorporarse en el contrato del
sistema.
Los requerimientos del sistema pueden definirse
o ilustrarse usando a modelos del sistema
discutidos en el Captulo 8.
12/05/16
251
Requerimientos y diseo
En
principio, los requerimientos deben declarar lo

que el sistema debe hacer y el diseo debe describir
cmo se hace esto.
En la prctica, los requerimientos y el diseo plan
son inseparables.
12/05/16
Una arquitectura del sistema puede disearse para

estructurar los requerimientos;
El sistema puede interoperar con otros sistemas que
generan los requerimientos del diseo;
El uso de un diseo especfico puede ser un requerimiento
del dominio.
252
Problemas con especificacin NL

Ambigedad
Los lectores y escritores de los requerimientos deben
interpretar las mismas palabras de la misma manera. NL
(Lenguaje Natural) es naturalmente ambiguo, as que esto
es muy difcil.
Sobre-flexibilidad
La misma cosa, puede decirse de varios maneras
diferentes en la especificacin.
Falta de modularizacin
Las estructuras NL son inadecuadas para estructurar los
requerimientos del sistema.
12/05/16
253
Alternativas de especificacin NL
Propiedad
Medida
Lenguaje natural
estructurado
Esta aproximacin depende de definir formas normales o

plantillas para expresar la especificacin de requerimientos.
Descripcin del
diseo
Esta aproximacin usa un lenguaje como un lenguaje de

programacin, pero con los rasgos ms abstractos para
especificar los requerimientos definiendo a modelo operacional
del sistema.
Esta aproximacin no es usada ahora
ampliamente, aunque puede ser til para las especificaciones
de la interfaz.
Notaciones grficas
Un lenguaje grfico, complementado por anotaciones de texto

es usado para definir los requerimientos funcionales del
sistema. Un ejemplo temprano de tal lenguaje grfico era SADT.
Ahora, descripciones de casos de uso y diagramas de
secuencia son usados comnmente.
Especificaciones
matemticas
stas son anotaciones basadas en conceptos matemticos

como mquinas de estado finito o conjuntos. Estas
especificaciones no ambiguas reducen los argumentos entre
cliente y contratista sobre la funcionalidad del sistema. Sin
embargo, la mayora de los clientes no entienden las
especificaciones formales y son renuentes para aceptar como
un contrato del sistema.
12/05/16
254
Especificaciones en lenguaje
estructurado
La libertad de escritura de los requerimientos est
limitada por una plantilla predefinida para los
requerimientos.
Todos los requerimientos son escritos de una manera
estndar.
La terminologa usada en la descripcin puede ser
limitada.
La ventaja es que la mayora de las expresiones del
lenguaje natural se mantienen, pero un grado de
uniformidad se impone en la especificacin.
12/05/16
255
Especificaciones basadas en
formatos
Definicin
de funcin o entidad.
Descripcin of entradas y de dnde vienen ellas.
Descripcin of salidas y a dnde van ellas.
Indicacin de otras entidades requeridas.
Pre y post condiciones (si son apropiados).
Los efectos laterales (si cualquier) de la
funcin.
12/05/16
256
Especificacin del nodo

basada en formatos
Insulin Pump /Control Software/SRS/3.3.2
Funcin
Computa la dosis de insulina: El nivel de azcar seguro.
Descripcin
Computa la dosis de insulina para ser entregada cuando el nivel de azcar moderado
actual est en la zona segura entre 3 y 7 unidades.
Entradas
Lectura actual de azcar (r2), las dos lecturas previas (el r0 y r1).
Fuente
La lectura actual de azcar desde e sensor. Otras lecturas desde la memoria.
Salidas
CompDose - la dosis en la insulina para ser entregado.
Destino
Ciclo de control principal..
Accin
CompDose es el cero si el nivel de azcar es estable o cayndose o si el nivel est

aumentando pero la proporcin de aumento est disminuyendo. Si el nivel est
aumentando y la tasa de aumento est aumentando, entonces CompDose se computa
dividiendo la diferencia entre el nivel de azcar actual y el nivel anterior por 4 y se
redondea el resultado. Si el resultado, es redondeado para poner a cero entonces
CompDose se pone a la dosis mnima que puede entregarse.
Requiere
Dos lecturas anteriores para que la proporcin de cambio de nivel de azcar pueda
calcularse.
Pre condicin
La reserva de insulina contiene al menos el mximo permitido de dosis simple de

insulina.
Post condicin
r0 es reemplazado por r1 entonces r1 es reemplazado por r2.
Efectos
12/05/16
colaterales
Ninguno.
257
Especificacin tabular
Usado
para complementar el lenguaje

natural.
Particularmente til cuando se tiene
que
definir
varias
posibles
alternativas en el curso de accin.
12/05/16
258
Especificacin tabular
Condicin
Accin
Cada de nivel de azcar (r2 CompDose = 0

< r1)
Nivel de azcar estable (r2 = CompDose = 0
r1)
Nivel
de
azcar CompDose = 0
aumentando y tasa
de
incremento decreciendo ((el
r2-r1)<(r1-r0))
Nivel
de
azcar
aumentando y tasa de
incremento
estable
o
aumentando.((el r2-r1)? (el
r1-r0))
12/05/16
CompDose = redondeo ((el r2-r1)/4)

Si el resultado redondeado = 0
entonces
CompDose = MinimumDose
259
Modelos grficos
Los
modelos grficos son muy tiles

cuando se necesita mostrar cmo los
cambios de estado o donde se
necesita describir una secuencia de
acciones.
Diferentes
modelos grficos se
explican en el Captulo 8.
12/05/16
260
Diagramas de secuencia
stos
muestran la sucesin de eventos que tienen

lugar durante alguna interaccin del usuario con un
sistema.
Se lee desde la cima basar para ver el orden de las
acciones que tienen lugar.
Retiro en efectivo desde ATM
Validar tarjeta;
Peticin manual;
Completar transaccin.
12/05/16
261
Diagrama de secuencia de retiro

de CA (Cajero Automtico)
ca : CajeroAutomtico
bd : Base de Datos
c : Cliente
1: Tarjeta
2: Nmero de tarjeta
3: Solicitud de PIN
4: Tarjeta OK
5: PIN
6: Men de Opciones
<<excepcin>>
7: Tarjeta invlida
8: Pedido de retiro
9: Pedido de balance
10: Pedido de monto

11: Balance
12: Monto
13: Cargar(Monto)
<<execpcin>>
15: Efectivo insuficiente
14: Rpta de carga
16: Tarjeta
17: Retirar tarjeta
18: Efectivo
19: Retirar efectivo
20: Recibo
12/05/16
262
La
mayora de los sistemas debe operar con otros

sistemas y las interfaces que operan deben
especificarse como la parte de los requerimientos.
Tres tipos de interfaz pueden tener que ser
definidos
Interfaces procedurales;
Estructuras de los datos que se intercambian;
Representaciones de datos.
Las
notaciones formales son una tcnica eficaz

para la especificacin de la interfaz.
12/05/16
263
Descripcin de interfaz PDL

nterface PrintServer {
// defines an abstract printer server
// requires:
interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter

void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
12/05/16
264
El documento de
requerimientos
El
documento de requerimientos es la
declaracin oficial de lo que es requerido por los
desarrolladores del sistema.
Debe incluir una definicin de requerimientos del
usuario
y
una
especificacin
de
los
NO es un documento de diseo. Hasta donde
posible, debe poner de lo QUE el sistema debe
hacer en lugar de CMO debe hacerlo
12/05/16
265
Usuarios de un documento
de requerimientos
Clientes
Clientesdel
delsistema
sistema
Especifican
Especifican los
los requerimientos
requerimientos yylos
los leen
leen para
para
chequear
que
renan
sus
necesidades.
Ellos
chequear que renan sus necesidades. Ellos
especifican
especificanlos
loscambios
cambiosen
enlos
losrequerimientos.
requerimientos.
Gerentes
Gerentes
Usan
Usan elel documento
documento de
de requerimientos
requerimientos para
para
planificar
una
oferta
para
el
sistema
planificar una oferta
para el sistema yy
planifican
el
proceso
de
desarrollo
planifican el proceso de desarrollodel
delsistema.
sistema.
Ingenieros
Ingenierosde
de
sistemas
sistemas
Usan
Usan los
los requerimientos
requerimientos del
del sistema
sistema para
para
pensar
pensarque
quesistema
sistemava
vaaaser
serdesarrollado.
desarrollado.
Ingenieros
Ingenierosde
de
pruebas
del
sistema
pruebas del sistema
Usan
Usan los
los requerimientos
requerimientos del
del sistema
sistema para
para
desarrollar
desarrollar las
las pruebas
pruebas de
de validacin
validacin del
del
sistema
sistema
Ingenieros
Ingenierosde
de
mantenimiento
mantenimientodel
del
sistema
sistema
Usan
Usan los
los requerimientos
requerimientos del
del sistema
sistema para
para
pensar
en
el
sistema
y
las
interrelaciones
con
pensar en el sistema y las interrelaciones con
sus
suspartes
partes
12/05/16
266
Estndar de
requerimientos IEEE
Define una estructura genrica para un documento de

requerimientos que debe ser instanciada para cada
sistema especfico.
Introduccin.
Descripcin general.
Requerimientos especficos.
Apndices.
ndices.
Nota: IEEE = Institute of Electrical Electronic Engineers
= El instituto de Ingenieros Electrnicos Elctricos
12/05/16
267
Estructura de documento
de especificaciones
Prefacio
Introduccin
Glosario
Definicin de requerimientos del usuario.
Arquitectura del sistema
Especificacin de requerimientos del sistema
Modelos del sistema
Apndices
Indece
12/05/16
268
Puntos clave
Los
requerimientos del sistema son pensados

para comunicar las funciones que el sistema
debe proporcionar.
Un documento de requerimientos de software
es una declaracin convenida de los
El estndar de IEEE es un punto de partida til
para definir las normas especficas de los
requerimientos con mayores detalles.
12/05/16
269
Puntos clave
Los requerimientos parten de lo que el sistema debe
hacer y debe definir las restricciones en su
funcionamiento y aplicacin.
Los requerimientos
funcionales parten de los
servicios que el sistema debe proporcionar.
Los requerimientos no funcionales restringen el
sistema a desarrollndose o el proceso de desarrollo.
Los requerimientos del usuario son declaraciones de
alto nivel de lo que el sistema debe hacer. Deben
escribirse los requerimientos del usuario usando
lenguaje natural, tablas y diagramas.
12/05/16
270
Captulo 7
Proceso de
ingeniera de
procesos
12/05/16
271
Objetivos
Describir
las principales actividades de la

ingeniera
de
requerimientos
y
sus
interrelaciones
Introducir las tcnicas para el elicitacin de
requerimientos y anlisis
Describir la validacin de requerimientos y el
papel de revisiones de requerimientos
Discutir el papel de la gestin de requerimientos
en el apoyo de otros procesos de la ingeniera de
requerimientos
12/05/16
272
Tpicos cubiertos
Estudios
de factibilidad
Elicitacin
de requerimientos
anlisis
Validacin de requerimientos
Gestin de requerimientos
12/05/16
273
Procesos de la ingeniera de
requerimientos
Los procesos usados por la RE (Requirements

Engineering = Ingeniera de Requerimientos) varan
ampliamente dependiendo del dominio de la aplicacin,
las personas involucradas y la organizacin que
desarrolla los requerimientos.
Sin embargo hay varias actividades genricas, comn a
todos los procesos
Elicitacin de requerimientos;
Anlisis de requerimientos;
Validacin de requerimientos;
Gestin de requerimientos.
12/05/16
274
Procesos de la ingeniera
de requerimientos
Estudio
Estudiode
de
factibilidad
factibilidad
Elicitacin
Elicitacinde
de
requerimientos
requerimientos
yyanlisis
anlisis
Especificacin
Especificacinde
de
requerimientos
requerimientos
Informe
Informede
de
factibilidad
factibilidad
Validacin
Validacinde
de
requerimientos
requerimientos
Modelos
Modelosdel
del
sistema
sistema
Requerimientos
Requerimientos
del
delusuario
usuarioyyelel
sistema
sistema
Documento
Documentode
de
requerimientos
requerimientos
12/05/16
275
Ingeniera de requerimientos
Especificacin
Especificacinde
de
requerimientos
requerimientos
Especificacin de
requerimientos del
sistema y
modelamiento
Especificacin de
requerimientos del
usuario
Especificacin de
requerimientos del
negocio
Elicitacin de e
requerimientos del
sistema
Elicitacin de e
requerimientos del
usuario
Elicitacin
Elicitacinde
de
requerimientos
requerimientos
Documento de
requerimientos del
sistema
12/05/16
Estudio de
factibilidad
Revisiones
Prototipado
Validacin
Validacinde
de
requerimientos
requerimientos
276
Estudio de factibilidad
Un estudio de factibilidad decide si el sistema
propuesto vale o no la pena.
Un corto estudio enfocado que verifica:
Si el sistema contribuye a los objetivos del
organizacin;
Si el sistema que use la tecnologa actual puede
disearse y dentro del presupuesto;
Si el sistema puede integrarse con otros sistemas
que se usan.
12/05/16
277
Implementacin del estudio

de factibilidad
12/05/16
Basado en la valoracin de informacin (lo que se

requiere), recopilacin de informacin y escritura del
informe.
Preguntas para las personas en la organizacin
Qu pasa si el sistema no fuera llevado a cabo?
Cules son los problemas actuales del proceso ?
Cmo ser la ayuda del sistema propuesto?
Cul sern los problemas de integracin?
Se necesita la nueva tecnologa? Qu habilidades?
Qu recursos deben apoyarse por el sistema
propuesto?
278
Elicitacin y anlisis
12/05/16
A veces llamado elicitacin de requerimientos o

descubrimiento de requerimientos.
Involucra a personal tcnico que trabaja con clientes
para averiguar sobre el dominio de la aplicacin, los
servicios que el sistema debe proporcionar y las
restricciones operacionales del sistema.
Puede involucrar a los usuarios finales, gerentes,
ingenieros involucrados en el mantenimiento,
expertos del dominio, sindicatos, etc. stos se
llaman los stakeholders.
279
Problemas del anlisis de

requerimientos
Los
stakeholders no saben lo que ellos realmente

quieren.
Los stakeholders expresan los requerimientos en
sus propias condiciones.
Los diferentes stakeholders
pueden tener los
requerimientos contradictorios.
Los factores organizacionales y polticos pueden
influir en los requerimientos del sistema.
Los requerimientos cambian durante el proceso del
anlisis. Pueden surgir nuevos stakeholders y
cambios del ambiente de negocios.
12/05/16
280
La espiral de los requerimientos

Clasificacin de
requerimientos y
organizacionales
Descubrimiento de
requerimientos
12/05/16
Prioritarizacin de
requerimientos y
negociacin
Documentacin de
requerimientos
281

Descubrimiento de requerimientos
Interactuando recprocamente con los stakeholders para
descubrir sus requerimientos. Tambin se descubren los
requerimientos del dominio en esta fase.
Requirements de clasificacin y organizacin
Los grupos relacionan los requerimientos y los organizan
en grupos coherentes.
Prioritarizacin y negociacin
Prioritarizando
los requerimientos y resolviendo los
conflictos de requerimientos.
Documentacin de requerimientos
Se documentan los requerimientos y se entra en la prxima
espiral de la escalera
de caracol.
12/05/16
282
Descubrimiento de
requerimientos
El
proceso de recoger la informacin acerca

de los sistema propuesto y existentes y
destilar el usuario y requerimientos del
sistema a partir de esta informacin.
Las fuentes de informacin incluyen la
documentacin, stakeholders del sistema y
la caracterstica tcnicas de sistemas
similares.
12/05/16
283
Stakeholders de un CA
Clientes del banco
Representes de otros bancos
Gerentes del banco
Personal de contadores
Administradores de bases de datos
Gerentes de seguridad
Departamento de marketing
Ingenieros de mantenimiento de hardware y
software
Reguladores de la banca
12/05/16
284
Puntos de vista
Los
puntos de vista son una manera de

estructurar los requerimientos para representar
las perspectivas de stakeholders diferentes.
Los stakeholders pueden ser clasificados bajo
los puntos de vista diferentes.
Este anlisis multi-perspectiva es importante
porque all no existe una sola manera correcta
de analizar los requerimientos del sistema.
12/05/16
285
Tipos de puntos de
vista
Puntos de vista de interactor

Las personas u otros sistemas que actan recproca y
directamente con el sistema. En un CA el cliente y la base de
datos de cuentas son los interactores PVs.
Puntos de vista indirectos
Los stakeholders que no usan el sistema ellos mismos, pero
son quienes influyen en los requerimientos. En un CA, la
direccin y personal de seguridad son los puntos de vista
indirectos.
Punto di vista del dominio
Las caractersticas del dominio y restricciones que influyen
en los requerimientos. En un CA, un ejemplo sera los
estndares para las comunicaciones inter-banco.
12/05/16
286
Identificacin de puntos de
vista
Identificar
12/05/16
los puntos de vista usando:
Proveedores y receptores de servicios del sistema;

Sistemas que actan recproca y directamente con el
sistema a especificarse;
Regulaciones y estndares;
Fuentes de negocios y requerimientos no funcionales.
Ingenieros que tienen que desarrollar y mantener el
sistema;
El marketing y otros puntos de vista de negocios.
287
Jerarqua de los puntos de vista

de LIBSYS
Todos los PVs
Indirecta
Indirecta
Gerente
Gerentede
de
librera
librera
Finanzas
Finanzas
Estudiantes
Estudiantes
12/05/16
Interactor
Interactor
ElElartculo
artculo
proporciona
proporciona
Personal
Personal
Usuarios
Personal
de librera
Externos
Externos
Dominio
Dominio
Estndares
de UI
Gerentes del
sistema
Sistema de
clasificacin
Catalogadores
288
Entrevistando
En
una entrevista formal o informal, el equipo de

RE pone las preguntas a los stakeholders sobre
el sistema que ellos usan y el sistema a ser
desarrollado.
Hay dos tipos de entrevista
Entrevistas cerradas dnde se contesta aun
conjunto pre-definido de preguntas.
Entrevistas
abiertas dnde hay ninguna
agenda pre-definida y un rango de problemas
son explorados con los stakeholders.
12/05/16
289
Entrevistas en la prctica
Normalmente una mezcla de entrevistas cerradas y

abiertas.
Las entrevistas son buenas para conseguir un
entendimiento global de lo que los stakeholders hagan
y cmo ellos podran interactuar con el sistema.
Las entrevistas no son buenas para el entendimiento de
los requerimientos del dominio.
Los
requerimientos de los ingenieros no pueden
entender la terminologa especfica del dominio;
Un poco de conocimiento del dominio est tan
familiarizado que las personas lo encuentran difcil
para articular o pensar que no es ningn valor
articulado.
12/05/16
290
Entrevistadores efectivos
Los
entrevistadores deben tener mente abierta ,

para escuchar a los stakeholders y no debe de
tener
ideas
preconcebidas
sobre
los
requerimientos.
Ellos deben incitar al entrevistado con una
pregunta o una propuesta y simplemente no
deben esperar que ellos respondan a una
pregunta como que es lo que usted quiere.
12/05/16
291
Escenarios
Los
escenarios son los ejemplos de la vida real

de cmo un sistema puede usarse.
Ellos deben incluir
12/05/16
Una descripcin de la situacin de arranque;

Una descripcin del flujo normal de eventos;
Una descripcin de lo que puede salir mal;
Informacin sobre otras actividades concurrentes;
Una descripcin del estado cuando los escenarios
finalizan.
292
Escenario LIBSYS (1)

La asuncin inicial: El usuario se ha registrado en el sistema de LIBSYS y ha
localizado el peridico que contiene la copia del artculo.
Normal: El usuario selecciona el artculo a ser copiado. El l o ella es
entonces impulsado por el sistema para proporcionar informacin como
subscriptor del peridico o indicar cmo pagarn por el artculo. Los mtodos
del pago alternativos son por tarjeta de crdito o citando un nmero de cuenta
organizacional.
Si pide entonces al usuario rellenar una formato de derechos de propiedad
que mantiene detalles de la transaccin y entonces ellos someten esto al
sistema de LIBSYS.
El formato de derechos de propiedad se verifica y, si est OK, la versin PDF
del artculo se transmite al rea activa de LIBSYS en la computadora del
usuario y el usuario es informado que la copia est disponible. Se pide al
usuario seleccionar una impresora y una copia del artculo se imprime. Si el
artculo se ha marcado como 'slo impresin' es eliminado del sistema del
usuario una vez que el usuario ha confirmado que la impresin est completa.
12/05/16
293
Escenario LIBSYS (2)

Qu puede salir mal: El usuario no puede rellenar el formato de derechos de propiedad
correctamente. En este caso, el formato debe representarse al usuario para la
correccin. Si el formato es resometido y todava es incorrecta, entonces la demanda
del usuario para el artculo se rechaza.
El pago puede ser rechazado por el sistema. La demanda del usuario para el artculo es
rechazado.
La transmisin del artculo puede fallar. Reintentar hasta obtener un resultado exitoso
o que el usuario termine la sesin.
Puede no ser posible imprimir el artculo. Si el artculo no se marca como slo
impresin entonces es retenido el rea de trabajo de LIBSYS. De otro modo, el artculo
se elimina con la cuenta que el usuario acredit con el costo del artculo.
Otras actividades: Transmisin simultneo de otros artculos.
El estado del sistema en la realizacin: El usuario es registrado. El artculo transmitido
se ha eliminado del rea de trabajo de LIBSYS si se ha marcado como slo impresin.
12/05/16
294
Casos de uso
Los
casos de uso son un escenario tcnicamente

basados en el UML que identifica a los actores en
una interaccin y qu describe la propia
interaccin.
Un conjunto de casos de uso debe describir
todas las posibles interacciones con el sistema.
Pueden usarse los diagramas de secuencia para
agregar detalle a los casos de uso mostrando la
sucesin de eventos que se procesan en el
sistema.
12/05/16
295
Caso de uso: Imprimir

artculo
Usario
12/05/16
Imprimir artculo
296
Casos de uso LIBSYS

Buscar artculo
Usuario de
Librera
Imprimir artculo
Administracin de usuario
Proveedor
12/05/16
Personal de
Librera
Servicio de catlogo
297
Imprimir artculo
usuario1 :
Usuario
item :
Artculo
1: Peticin
formDR :
Formulario
miET :
EspacioTrabajo
miImpresora
: Impresora
2: Peticin
3: Retornar
4: Completar
5: DR:=OK
6: Entregar
7: Artculo:=OK
8: Imprimir
11: Informar
9: Enviar
10: Confirmar
12: Eliminar
12/05/16
298
Secuencia: Imprimir artculo

usuario1 :
Usuario
item :
Artculo
1: Peticin
formDR :
Formulario
miET :
EspacioTrabajo
miImpresora
: Impresora
2: Peticin
3: Retornar
4: Completar
5: DR:=OK
6: Entregar
7: Artculo:=OK
8: Imprimir
11: Informar
9: Enviar
10: Confirmar
12: Eliminar
12/05/16
299
Factores sociales y
organizacionales
Los
sistemas del software se usan en un contexto

social y organizacional. Esto puede influenciar o
incluso puede dominar los requerimientos del
sistema.
Los factores sociales y organizacionales no son
un solo punto de vista, pero son influyentes en
todos los puntos de vista.
Los buenos analistas deben ser sensibles a estos
factores pero realmente no hay ninguna manera
sistemtica de acometer su anlisis.
12/05/16
300
Etnografa
Unos
cientficos sociales se pasan un tiempo

considerable observando y analizando cmo las
personas trabajan realmente.
Las personas no tienen que explicar o articular su
trabajo.
Los factores sociales y organizacionales de
importancia pueden ser observados.
Los estudios de etnografa han mostrado que ese
trabajo es normalmente ms rico y ms complejo
que el sugerido por simples modelos del sistema.
12/05/16
301
La etnografa enfocada
Desarrollado
en un proyecto que estudia el

proceso de control de trfico areo.
Combina la etnografa con el prototipado.
El desarrollo del prototipo produce preguntas sin
contestar que enfocan el anlisis de la etnografa.
El problema con la etnografa es que estudia
prcticas existentes que pueden tener alguna
base histrica lo que no es por mucho tiempo
relevante.
12/05/16
302
Etnografa y prototipado
Anlisis
Anlisis
etnogrfico
etnogrfico
Reuniones
Reuniones
interrogando
interrogando
Etnografa
Etnografa
enfocada
enfocada
Evaluacin
Evaluacin
del
delprototipo
prototipo
Desarrollo
Desarrollode
de
sistemas
sistemas
genricos
genricos
12/05/16
Prototipado
Prototipado
de
desistemas
sistemas
303
Alcance de la etnografa
Los
requerimientos que se derivan de la

manera en que las personas realmente
trabajan, en lugar de la manera que las
definiciones del proceso sugieren que ellos
deban trabajar.
Los requerimientos que se derivan de la
cooperacin y conocimiento de las
actividades de otras personas.
12/05/16
304
Validacin de requerimientos
Hay
inters en la demostracin de que los

requerimientos definen el sistema como el cliente
realmente quiere.
Los costos de error en los requerimientos son
altos, por lo que la validacin es muy importante
Arreglar
un error de los requerimientos
despus de la entrega, puede costar 100 veces
el
costo
de
arreglar
un
error
de
implementacin.
12/05/16
305
Comprobando
requerimientos
Validez. El sistema proporciona las funciones que
dan el mejor soporte a las necesidades del cliente?
Consistencia.
Hay
algn
conflicto
de
requerimientos?
Completitud. Estn incluidas todas las funciones
requeridas por el cliente?
Realismo.
Pueden
los requerimientos ser
implementados dados el presupuesto y la tecnologa
disponibles?
Verificabilidad. Los requisitos pueden verificarse?
12/05/16
306
Tcnicas de validacin de
requerimientos
Revisiones
de requerimientos
El
anlisis
manual
sistemtico
de
los
requerimientos.
Prototipado
Usando un modelo ejecutable del sistema para
verificar los requerimientos. Cubierto en Captulo
17.
Generacin de casos de prueba
Desarrollo pruebas de los requerimientos para
verificar la comprobabilidad.
12/05/16
307
Revisin de requerimientos
Deben
sostenerse las revisiones regulares

mientras la definicin de requerimientos estn
formulndose.
El cliente y el personal del contratista deben ser
involucrados en las revisiones.
Las revisiones pueden ser formales (con los
documentos completados) o informales. Las
buenas comunicaciones entre desarrolladores,
clientes y usuarios pueden resolver los
problemas en una fase temprana.
12/05/16
308
Comprobacin de la revisin
Verificabilidad.
El
requerimiento
es
realsticamente comprobable?
Comprensibilidad. El requisito se entiende
adecuadamente?
Trazabilidad. El origen del requerimiento se
declara claramente?
Adaptabilidad.
Puede cambiarse el
requerimiento sin un impacto grande en otros
requerimientos?
12/05/16
309
La gestin de requerimientos es el proceso de manejar

los requerimientos cambiantes durante el proceso de
ingeniera de requerimientos y desarrollo del sistema.
Los requisitos estn inevitablemente incompletos e
incoherentes
Los nuevos requerimientos
surgen durante el
proceso como el cambio de necesidades del negocio
y un buen entendimiento del sistema es desarrollado;
Diferentes
puntos de vista tienen diferentes
requerimientos y stos son a menudo son
contradictorios.
12/05/16
310
Cambio de requerimientos
La
prioridad de los requerimientos desde cambios

de diferentes puntos de vista durante el proceso
de desarrollo.
Clientes del sistema pueden especificar los
requerimientos desde una perspectiva comercial
que son conflictivos con los requerimientos del
usuario final.
El ambiente comercial y tcnico del sistema
cambian durante su desarrollo.
12/05/16
311
Evolucin de los
requerimientos
Entendimiento
Entendimiento
inicial
inicialdel
del
problema
problema
Cambio
Cambiodel
del
entendimiento
entendimiento
del
delproblema
problema
Requerimientos
Requerimientos
iniciales
iniciales
Cambio
Cambiode
delos
los
requerimientos
requerimientos
Tiempo
12/05/16
312
Resistencia y requerimientos
voltiles
Requerimientos
pacientes. Los requerimientos

estables se derivan del centro de actividad de la
organizacin del cliente. Por ejemplo, un hospital
siempre tendr doctores, enfermeras,
etc.
Pueden se derivado de modelos del dominio
Requerimientos voltiles. Los requerimientos
que cambian durante el desarrollo o cuando el
sistema est en el uso. En un hospital, los
requerimientos se derivan de la poltica de
cuidado de la salud.
12/05/16
313
Clasificacin de requerimientos
Tipo de
requerimiento
Descripcin
Requerimientos
mudables
Requerimientos que cambian debido a los cambios al ambiente en

el cual la organizacin est operando. Por ejemplo, en los
sistemas de hospital, el fondo de cuidado paciente puede cambiar
y as puede exigir recolectar la informacin de tratamiento
diferente.
Requerimientos
emergentes
Requerimientos que surgen de lo que el cliente est entendiendo

del desarrollo del sistema desarrolla durante el desarrollo del
sistema. El proceso de diseo puede revelar nuevos
requerimientos emergentes.
Requerimientos
consecuenciales
Requerimientos que son el resultado de la introduccin del

sistema de computadora. Introduciendo el sistema de
computadora pueden cambiar el proceso de organizacin y abre
nuevas maneras de trabajar, lo que genera nuevos requerimientos
del sistema.
Requerimientos
de compatibilidad
Requerimientos que dependen de los sistemas particulares o

procesos de negocio dentro de un organizacin. Como stos
cambien, los requerimientos de compatibilidad en el comisionado
o entrega, el sistema tambin puede tener que evolucionar.
12/05/16
314
Planificando la gestin de
requerimientos
Durante el proceso de ingeniera de requerimientos, se tiene

que planear:
Identificacin de requerimientos
Cmo se identifican los requerimientos individualmente;
Proceso de gestin de cambios
El proceso sigue al analizar un cambio de requerimientos;
Polticas de trazabilidad
La cantidad de informacin sobre interrelaciones de
requerimientos que se mantienen;
Herramienta CASE de soporte
El apoyo de la herramienta requerida para ayudar en el
manejo de cambio de requerimientos;
12/05/16
315
Trazabilidad
La trazabilidad se preocupa por las interrelaciones entre
los requerimientos, sus fuentes y el diseo del sistema.
Trazabilidad de la fuente
Los enlaces de los requerimientos a los stakeholders
que propusieron estos requerimientos;
Trazabilidad de requerimientos
Los enlaces entre los requerimientos dependientes;
Trazabilidad del diseo
Los enlaces de los requerimientos al diseo.
12/05/16
316
Matriz de trazabildad
12/05/16
317
Soporte de herramientas
CASE
Almacenamiento de requerimientos
Los requerimientos deben gestionarse en un almacn de
datos seguro, gestionado.
Gestin de cambios
El proceso de gestin de cambio es un proceso de flujo de
trabajo cuyos fases pueden definirse y el flujo de
informacin entre estas fases parcialmente automatizados.
Gestin de trazabilidad
La recuperacin automatizada de los enlaces entre los
requerimientos.
12/05/16
318
Gestin de cambio de
requerimientos
Debe
aplicarse a todos los cambios propuestos

para los requerimientos.
Fases principales
Anlisis del problema. Discutir el problema de
los requerimientos y proponer el cambio;
Anlisis y costos del cambio. Evaluar los
efectos de cambio en otros requerimientos;
Implementacin
del cambio. Modificar el
documento de
los requerimientos y otros
documentos para reflejar el cambio.
12/05/16
319
Gestin de cambios
Revisin de
requerimientos
Identificacin
del problema
Anlisis
Anlisisdel
del
problema
problemayy
especificacin
especificacindel
del
cambio
cambio
12/05/16
Anlisis
Anlisisyycostos
costos
del
cambio
del cambio
Implementacin
Implementacin
del
delcambio
cambio
320
Puntos clave
El
proceso de ingeniera de requerimientos

incluye un estudio de factibilidad, elicitacin de
requerimientos y anlisis, especificacin de
requerimientos y gestin de requerimientos.
El
elicitacin de requerimientos es el
entendimiento del dominio involucrado iterativo,
recoleccin de requerimientos , clasificacin,
estructuracin, prioritarizacin y validacin.
Los sistemas tienen mltiples stakeholders con
requerimientos diferentes.
12/05/16
321
Puntos clave
Los
factores social y el organizacional influyen

sobre los requerimientos del sistema.
La validacin de requerimientos se preocupa por
las comprobaciones para la validez, consistencia,
completitud, realismo y verificabilidad.
Los cambios comerciales llevan inevitablemente
al cambio de los requerimientos.
La
gestin
de
requerimientos
incluye
planificacin y gestin del cambio.
12/05/16
322
Captulo 8
Modelos de
sistema
12/05/16
323
Objetivos
Explicar
por qu el contexto de un sistema debe

ser los modelado como la parte del proceso de RE
(Ingeniera de Requerimientos)
Describir
el modelado del comportamiento,
modelado de datos y modelado de objetos
Introducir algunas de las notaciones usados en el
Lenguaje de Modelado Unificado (UML)
Mostrar
cmo los bancos de trabajo
(workbenches) CASE dan soporte al modelado del
sistema
12/05/16
324
Tpicos cubiertos
Modelos
de contexto
Modelos de comportamiento
Modelos de datos
Modelos de objetos
Bancos de trabajo CASE
12/05/16
325
Modelado del sistema
12/05/16
El modelado del sistema ayuda que el analista entienda la

funcionalidad del sistema y los modelos se usan para
comunicarse con clientes.
Diferentes modelos presentan el sistema desde
perspectivas diferentes
Perspectiva externa, mostrando el contexto del
sistema o ambiente;
Perspectiva del comportamiento, mostrando
el
comportamiento del sistema;
Perspectiva estructural mostrando el sistema o la
arquitectura de los datos.
326
Tipos de modelo
Modelo de procesamiento de datos, que muestra
cmo se procesan los datos en diferentes fases.
Modelo de composicin, que muestra cmo las
entidades estn compuestas de otras entidades.
Modelo arquitectnico, que nuestra los subsistemas principales.
Modelo de clasificacin, que muestra cmo las
entidades tienen caractersticas comunes.
Modelo de estmulo/respuesta, que muestra la
reaccin del sistema a los eventos.
12/05/16
327
Modelos de contexto
Los
modelos del contexto son usados para

ilustrar el contexto operacional de un sistema ellos muestran qu situaciones hay fuera de
los lmites del sistema.
Lo social y organizacional pueden afectar la
decisin en dnde poner los lmites del
sistema.
Los modelos arquitectnicos muestran el
sistema y su interrelacin con otros sistemas.
12/05/16
328
El contexto de un sistema
de un CA
Sistema
Sistemade
de
seguridad
seguridad
Sistema
Sistemade
de
contabilidad
contabilidadde
de
sucursal
sucursal
Sistema
Sistemade
de
contador
de
contador de
sucursal
sucursal
Base
Basede
dedatos
datosde
de
cuenta
cuenta
Sistema
Sistemade
de
Cajero
Cajero
Automtico
Automtico
Base
Basede
dedatos
datosde
de
usuario
usuario
Sistema
Sistemade
de
mantenimiento
mantenimiento
12/05/16
329
Modelos de proceso
Los
modelos de proceso muestran el

proceso global y los procesos que
son apoyados por el sistema.
El modelo de flujo de datos pueden
usarse para mostrar los procesos y el
flujo de informacin de un proceso a
otro.
12/05/16
330
Proceso de obtencin de
equipo
Requerido
Requerido
por
porequipo
equipo
especfico
especfico
Especificacin
de equipo
Especificacin
de equipo
Base
Basede
dedatos
datos
del
proveedor
del proveedor
Nota de
entrega
Especificacin
revisada
Especificacin
Especificacin
de
devalidacin
validacin
Lista de
proveedores
Obtener
Obtenercosto
costo
de
de
estimaciones
estimaciones
Aceptar
Aceptar
entrega
entregade
de
equipo
equipo
Especificacin
+ Proveedor +
Estimacin
Hallar
Hallar
proveedores
proveedores
Elegir
Elegir
proveedor
proveedor
Pedido de
detalles +
Formato de
pedido en
blanco
Nota de
entrega
Notificacin
de pedido
Hacer
Hacerpedido
pedido
de
equipo
de equipo
Revisar
Revisar
entrega
entregade
de
tems
tems
Instrucciones
de instalacin
Instalar
Instalar
equipo
equipo
Aceptacin de
instalacin
Formato de
pedido
verificado y
revisado
Aceptar
Aceptarentrega
entrega
de
de equipo
equipo
Detalles de
equipo
Base de datos
Base de datos
de
deequipo
equipo
12/05/16
331
Modelos de comportamiento
Los modelos de comportamiento se usan para describir

el comportamiento global de un sistema.
Los dos tipos del modelos de comportamiento son:
Modelos
de procesamiento de datos, que
muestran cmo el datos son procesados y como se
mueven a travs del sistema;
Modelos de la mquina de estado, que muestran la
respuesta de los sistemas a los eventos.
Estos modelos muestran las diferentes perspectivas
para que los dos son requeridos para describir el
comportamiento del sistema.
12/05/16
332
Modelos de procesamiento
de datos
Los diagramas de flujo de fluyen (DFDs) puede
usarse para modelar el procesamiento de datos del
sistema.
stos muestran que el proceso camina como flujos
de datos a travs de un sistema.
Los DFDs son una parte intrnseca de muchos
mtodos del anlisis.
Notacin simple e intuitiva que los clientes pueden
entender.
Mostrar el procesamiento extremo-a-extremo de
datos.
12/05/16
333
DFD de procesamiento de
pedido
Pedido de
detalles +
Formato de
pedido en
blanco
Completar
Completar
formato
formatode
de
pedido
pedido
Formato de
pedido
completado
Formato de
pedido
firmado
Formato de
pedido
firmado
Validar
Validar
pedido
pedido
Enviar al
Enviar al
proveedor
proveedor
Pedido verificado
y firmado +
Notificacin de
pedido
Registrar
Registrar
pedido
pedido
Detalle de
pedido
Formato de
pedido
firmado
Ajustar
Ajustaralal
presupuesto
presupuesto
disponible
disponible
Cuenta de pedido
+ Detalles de
cuenta
Archivo
Archivode
de
pedidos
pedidos
12/05/16
Aceptar
Aceptarentrega
entrega
de
equipo
de equipo
334
Diagramas de flujo de datos

Los
DFDs modelan el sistema desde una

perspectiva funcional.
Rastreando y documentando cmo los datos
asociados con un proceso son tiles para
desarrollar un entendiendo global del sistema.
Los diagramas de flujo de datos tambin
pueden ser usados mostrando el intercambio
de datos entre un sistema y otros sistemas en
su ambiente.
12/05/16
335
DFD de bombeo de insulina

Sangre
Sensor
Sensorde
de
azcar
azcaren
enla
la
sangre
sangre
Insulina
Bombeo
Bombeode
de
insulina
insulina
12/05/16
Parmetros
Nivel de
de sangre Anlisis
Anlisisde
de azcar en la
azcar
sangre
azcaren
en
la
lasangre
sangre
Computacin
Computacinde
de
requerimientos
Comandos de
requerimientos
de
control de
deinsulina
insulina
bombeo
Controlador
Controlador
Requerimientos
de
entrega
de entrega
de insulina
de
deinsulina
insulina
336
Modelos de mquina de estados
12/05/16
stos modelan el comportamiento del sistema en

respuesta a los eventos externos e interiores.
Ellos muestran las respuestas del sistema a los
estmulos que se usan a menudo para el modelado de
sistemas de tiempo real.
Los modelos de la mquina de estados muestran los
estados del sistema como los nodos y eventos, como
los arcos entre estos nodos. Cuando un evento
ocurre, el sistema se mueve de un estado a otro.
Los diagramas de estado son una parte integrante de
UML y se usan para representar a los modelos de
mquina de estados.
337
Diagramas de estado
Permite
la descomposicin de un modelo
en los sub-modelos (ver la diapositiva
siguiente).
Una breve descripcin de las acciones es
incluido siguiendo lo que hacen en cada
estado.
Puede complementarse por tablas que
describen los estados y los estmulos.
12/05/16
338
Modelo de horno
microondas
Mxima potencia
Mxima potencia
do/ Poner Power = 600
Cronmetro
Nmero
Operacin
Esperando
do/ Visual izar tiempo
Media energa
do/ Operar el horno
Fijar tiempo
Iniciar
do/ Dar nmero

exit/ Fijar ti empo
Cronmetro
Media potencia
Puerta cerrada
Habilitado
Puerta abierta
do/ Vi sualizar "Listo"
Media potencia
do/ Poner Power = 300
Puerta cerrada
Deshabilitado
do/ Visual izar "Esperando"
Cancelar
12/05/16
339
Descripcin de estados del

horno microondas
Estado
Descripcin
Esperando
El horno est esperando por la entrada. El visualizador muestra el

tiempo actual.
Media potencia
La potencia del horno se pone a 300 vatios. El visualizador muestra

Media potencia.
Mxima
potencia
La potencia del horno se pone a 600 vatios. El visualizador muestra

Mxima potencia.
Fijar tiempo
El tiempo coccin se pone al valor de la entrada del usuario. El

visualizador muestra el tiempo de coccin seleccionado y se pone al da
cuando el tiempo es fijo.
Deshabilitado
El funcionamiento del horno es deshabilitado por seguridad. La luz

interior se enciende. El visualizador muestra "No listo".
Habilitado
El funcionamiento del horno es habilitado. La luz del horno interior se

apaga. El visualizador muestra " Listo".
Operacin
El horno en funcionamiento. La luz del horno interior se enciende. El

visualizador muestra la cuenta atrs del cronmetro. En la realizacin de
cocinar, el zumbador suena durante 5 segundos. La luz del horno se
enciende. El visualizado muestra "Coccin completa" mientras el
zumbador est sonando.
12/05/16
340
Estmulos del horno

microondas
Estado
Descripcin
Media potencia
El usuario ha presionado el botn de media

potencia.
Mxima potencia
El usuario ha presionado el botn de mxima

potencia.
Cronmetro
El usuario ha presionado uno de los botones

del cronmetro.
Nmero
El usuario ha presionado una llave numrica.
Puerta abierta
El interruptor de puerta del horno no est

cerrado.
Puerta cerrada
El interruptor de puerta del horno est cerrado.
Iniciar
El usuario ha presionado el botn de salida.
Cancelar
12/05/16
El Ing.usuario
ha presionado
Otoniel Silva Delgado - Ing. Ivan Pino Tellera
cancelacin.
el
botn
de
341
Operacin de horno microondas

OperacinHorno
Tiempo
Comprobando
OK
do/ Comprobar estado
Falla de botn
giratorio
Cocinando
do/ Ejecutar generador
Interrupcin
Falla del
emisor
Hecho
do/ Sonido durante 5 segundos
Alarma
do/ Mostrar evento
Desactivado
12/05/16
Puerta abierta
EnEspera
342
Modelos de datos semnticos

Usado para describir la estructura lgica de datos
procesados por el sistema.
Un conjunto de modelos de Entidad-interrelacinatributo fuera las entidades en el sistema, las
interrelaciones entre estas entidades y los atributos
de la entidad.
Ampliamente usado en el diseo de bases de datos.
Puede, sin esfuerzo, implementarse usando las
bases de datos relacionales.
No hay ninguna notacin especfica proporcionada
por UML, pero objetos y asociaciones pueden ser
usados.
12/05/16
343
Modelo semntico de Librera

Artculo
Fuente
ID_artculo
Ttulo
Autores
Archivo_PDF
Cuota
ID_fuente
Publica_en
Ttulo
Editor
Edicin
Fecha
Pginas
Cuota_pagable_a
Solicita
En
Pedido
Nro_pedido
PagoTotal
Fecha
Impuesto_estado
ID_artculo (FK)
Id_comprador (FK)
Agencia_DR
Pas
Id_agencia
Nombre
Direccin
ID_fuente (FK)
ID_pas
En
ID_fuente (FK)
Formato_DR
Tasa_impuesto
Id_agencia (FK)
Coloca
Comprador
Id_comprador
Nombre
Direccin
E_mail
InformeCuenta
12/05/16
344
Diccionarios de datos
Los
diccionarios de datos son listas de todos los nombres

usados en los modelos del sistema. Las descripciones de
las entidades, las interrelaciones y atributos tambin son
incluidos.
Ventajas
Soporta la gestin del nombre de apoyo y evita la
duplicacin;
Almacn
del conocimiento organizacional ligado al
anlisis, diseo e implementacin;
Muchos bancos de trabajo CASE apoyan los diccionarios
de datos.
12/05/16
345
Entradas de diccionario de
datos
Nombre
Descripcin
Tipo
Fecha
Artculo
Detalles del artculo publicado que Entidad

pueden ser pedidas por las
personas que usan LIBSYS.
30/12/2005
Autores
Los nombres de los autores del Atributo

artculo quienes pueden ser una
porcin de la cuota.
30/12/2005
Comprador
La persona u organizacin que Entidad

piden una copia del artculo.
30/12/2005
Cuota_pagable_a
Interrelacin entre las entidades Interrelacin

Artculo y
Agencia_DR que
describe la cuota del pago de los
derechos reservados.
29/12/2005
Direccin
La direccin del comprador. Esto Atributo

se usa para cualquier papel que
factura
informacin
que
se
requiere.
31/12/2005
12/05/16
346
Modelos de objetos
Los
modelos del objetos describen el sistema en

trminos de clases de objetos y sus asociaciones.
Una clase de objetos es una abstraccin sobre un
conjunto de objetos con atributos comunes y
servicios (operaciones) proporcionados por cada
objeto.
Pueden producirse varios modelos del objeto:
Modelos de herencia;
Modelos de agregacin;
Modelos de interacciones.
12/05/16
347
Modelos de objetos
Maneras
naturales de reflejar las entidades del

mundo real manipuladas por el sistema.
Las entidades ms abstractas son ms difciles
de modelar usando esta aproximacin.
Las entidades ms abstractas son ms difciles
de modelar usando esta aproximacin.
Las clases del objetos que reflejan las entidades
del dominio son reusables por los sistemas.
12/05/16
348
Modelos de herencia
Organiza
las clases de objetos de dominio en

una jerarqua.
Las clases a la cima de la jerarqua reflejan los
rasgos comunes de todas las clases.
Las clases del objetos heredan sus atributos y
servicios de uno o ms superclases. Estos
pueden entonces especializarse cuanto sea
necesario.
El diseo de herencia de clases puede ser un
proceso difcil si la duplicacin en las ramas
diferentes debe ser evitada.
12/05/16
349
Modelos de objetos en el
UML
El UML es una representacin estndar inventada por los

diseadores del ampliamente usado anlisis orientado a objetos
y mtodos de diseo.
Se ha vuelto una estndar eficaz para el modelado orientado a
objetos.
Notacin
Las clases del objeto son rectngulos con el nombre en la
cima, atributos en la media seccin y operaciones en la
seccin del fondo;
Las interrelaciones entre las clases del objetos (conocidas
como asociaciones) se muestran como lneas que unen los
objetos;
La herencia es referenciada como generalizacin y se muestra
"hacia arriba" en lugar de "hacia abajo" en una jerarqua.
12/05/16
350
Herencia de la clase Librera

ItemLibrera
NmeroCatlogo
FechaAdquisicin
Costo
T ipo
Estado
NmeroCopias
Adquirir()
Catalogar()
Disponer()
Publicar()
Retornar()
ItemPublicado
ItemRegistrado
T tulo
Editor
Libro
Autor
Edicin
FechaPublicacin
ISBN
12/05/16
T tulo
Medio
Revista
Ao
Nmero
Pelcula
Director
FechaRealizacin
Distribuidor
ProgramaComputadora
Versin
Plataforma
351
Herencia de la clase Usuario

UsuarioLibrera
Nombre
Direccin
Telfono
NmeroRegistro
Regis trar()
Desregistrar()
Lector
Prestatario
Afiliacin
Items Prstamo
Mxim oPrs tam o
Personal
Departamento
TelfonoDepto
12/05/16
Estudiante
TemaMayor
DireccinDomicilio
352
Herencia mltiple
En lugar de heredar los atributos y servicios de una
sola clase-padre, un sistema que apoya la herencia
mltiple permite que las clases del objetos heredar
de varias superclases.
Esto puede llevar a conflictos semnticos dnde los
atributos/servicios con el mismo nombre en
diferentes superclases tienen diferente semntica.
La herencia mltiple hace la reorganizacin de
jerarqua de clases ms compleja.
12/05/16
353
Herencia mltiple
Libro
GrabacinVoz
Autor
Edicin
FechaPublicacin
ISBN
Altavoz
Duracin
FechaGrabacin
LibroParlante
NmeroCintas
12/05/16
354
Agregacin de objetos
Un
modelo de agregacin muestra

cmo clases que son las colecciones
estn compuestas de otras clases.
Los modelos de agregacin son
similares
a
la
interrelacin
"parte_de" en los modelos de los
datos semnticos.
12/05/16
355
Agregacin de objetos
PaqueteEstudio
TtuloCurso
Nmero
Ao
Instructor
Asignacin
Crditos
12/05/16
Ejercicios
Soluciones
NmeroProblema
Descripcin
Texto
Diagramas
DiapositivasOHP
NotasLectura
Videocinta
Diapositivas
Texto
IdCinta
356
Modelamiento del
comportamiento de objetos
Un
modelo de comportamiento muestra las

interacciones entre los objetos para
producir algn comportamiento del sistema
particular que se especifica como un caso
de uso.
Los diagramas de secuencia (o diagramas
de colaboracin) en UML son usados para
modelar la interaccin entre los objetos.
12/05/16
357
Edicin de artculos
electrnicos
Ecat : Catlogo
usLib :
UsuarioLibrera
itLib : ItemLibrera
Lib1
1: Mirar
2: Visualizar
3: Publicar
4: Licencia de publicar
5: Aceptar licencia
6: Comprimir
7: Entregar
12/05/16
358
Mtodos estructurados
Los
mtodos estructurados se incorporan al

modelado de sistemas como una parte
inherente del mtodo.
Los mtodos definen un conjunto de modelos,
un proceso por derivar estos modelos y reglas
y pautas que deben aplicar a los modelos.
Las herramientas CASE apoyan el modelado
de sistemas como parte de un mtodo
estructurado.
12/05/16
359
Debilidades del mtodo

Ellos
no modelan los requerimientos del sistema

no-funcionales.
Ellos normalmente no incluyen la informacin
sobre si un mtodo es apropiado para un
problema dado.
El puede producir demasiada documentacin.
Los modelos del sistema a veces tambin se
detallan y son difciles de entender para los
usuarios
12/05/16
360
Bancos de trabajo CASE

Un conjunto coherente de herramientas que se
disean para apoyar las actividades del proceso de
software relacionadas como el anlisis, diseo o
pruebas.
Los bancos de trabajo del anlisis y diseo apoyan
el modelado del sistema durante la ingeniera de
requerimientos y el diseo del sistema.
Estos bancos de trabajo pueden apoyar un mtodo
de diseo especfico o pueden proporcionar apoyo
para varios tipos diferentes de creacin de modelo
del sistema.
12/05/16
361
Un banco de trabajo de anlisis

y diseo
Diccionario
Diccionario
de
de
datos
datos
Generador
Generador
de
de
cdigo
cdigo
Herramientas
Herramientasde
de
creacin
de
creacin de
formularios
formularios
12/05/16
Herramientas
Herramientasde
de
diagramacin
diagramacin
estructurada
estructurada
Recursos
Recursosde
de
generacin
generacinde
de
informes
informes
Almacn
Almacnde
de
informacin
informacin
central
central
Recursos
Recursosde
de
lenguaje
lenguajede
de
consulta
consulta
Herramientas
Herramientasde
de
anlisis,
diseo
anlisis, diseoyy
comprobacin
comprobacin
Recursos
Recursosde
de
importacin
importacin/ /
exportacin
exportacin
362
Componentes del banco de

trabajo del anlisis
Editores de diagrama
Herramientas de comprobacin del modelo de
anlisis
Almacn y lenguaje de consulta asociado
Diccionario de datos
Definicin
de informe y herramientas de
generacin
Herramientas de definicin de formularios
Traductores de importacin/exportacin
Herramientas de generacin de cdigo
12/05/16
363
Puntos clave
Un modelo es una vista abstracta del sistema . Los
tipos complementarios de modelo proporcionan la
informacin del sistema diferente.
Los modelos de contexto muestran la posicin de un
sistema en su ambiente con otros sistemas y
procesos.
Los modelos de flujo de datos pueden usarse para
modelar el procesamiento de datos en un sistema.
Los modelos de mquina de estados modelan el
comportamiento del sistema en respuesta a los
eventos internos o externos.
12/05/16
364
Puntos clave
Los
modelos de datos semnticos describen la

estructura lgica de datos que son importados
o exportados por los sistemas.
Los modelos del objetos describen entidades
del sistema lgicas, su clasificacin y
agregacin.
Los modelos de secuencia muestran las
interacciones entre actores y los objetos del
sistema que ellos usan.
Los mtodos estructurados proporcionan un
framework para los modelos del sistema en
vas de desarrollo.
12/05/16
365
Captulo 9
Especificacin
de sistemas
crticos
12/05/16
366
Objetivos
Explicar
cmo los requerimientos de confiabilidad

pueden ser identificados analizando los riesgos
enfrentados por los sistemas crticos
Explicar cmo se generan los requerimientos de
seguridad del anlisis de riesgo del sistema
Explicar la derivacin de requerimientos de
seguridad
Describir mtricas usadas para la especificacin
de fiabilidad
12/05/16
367
Tpicos cubiertos
Especificacin
de manejo de riesgo
Especificacin de seguridad fsica
Especificacin de seguridad contra
delitos
Especificacin
de fiabilidad del
software
12/05/16
368
Requerimientos de confiabilidad
Requerimientos
funcionales para definir
comprobacin de error y medios de recuperacin

y proteccin contra las fallas del sistema.
Requerimientos
no
funcionales
que
definen la fiabilidad requerida y disponibilidad del
sistema.
Requerimientos
excluyentes que definen
los estados y condiciones que no deben surgir.

12/05/16
369
Especificacin de manejo
de riesgos
La
especificacin de los sistemas crticos debe

manejar riesgos.
Esta aproximacin se ha usado ampliamente en
la seguridad y los sistemas de seguridad crticos.
El objetivo del proceso de especificacin debe
ser entender los riesgos (la seguridad fsica, la
seguridad contra delitos, etc.) enfrentados por el
sistema y para definir requerimientos que
reducen estos riesgos.
12/05/16
370
Estado de anlisis basado en

riesgos
Identificacin del riesgo

Identifica riesgos potenciales que pueden surgir.
Anlisis y clasificacin del riesgo
Evala la gravedad de cada riesgo.
Descomposicin del riesgo
Descompone los riesgos para descubrir sus causas de
raz potenciales.
Evaluacin de reduccin del riesgo
Define cmo cada riesgo debe tomarse para ser
eliminado o reducido cuando el sistema es diseado.
12/05/16
371
Especificacin de manejo de
riesgos
Identificacin
Identificacin
del
del
riesgo
riesgo
Anlisis
Anlisisyy
clasificacin
clasificacin
del
del riesgo
riesgo
Planificacin
Planificacin
del
del
riesgo
riesgo
Evaluacin
Evaluacinde
de
reduccin
del
reduccin del
riesgo
riesgo
Descripcin
Descripcindel
del
riesgo
riesgo
Evaluacin
Evaluacindel
del
riesgo
riesgo
Anlisis
Anlisisde
delala
causa
causaraz
raz
Requerimientos
Requerimientos
de
deconfiabilidad
confiabilidad
12/05/16
372
Identificacin del riesgo

Identificar los riesgos enfrentados por el sistema
crtico.
En los sistemas de seguridad fsica crticos, los riesgos
son los peligros que pueden llevar a los accidentes.
En los sistemas seguridad contra delitos crticos, los
riesgos son los ataques potenciales en el sistema.
En la identificacin del riesgo, se debe identificar
clases de riesgos y la posicin del riesgo en estas
clases
Falla de servicio;
Riesgos elctricos;

12/05/16
373
Los riesgos de la bomba

de insulina
12/05/16
Dosis excesiva de insulina (falla de servicio).

Baja dosis de insulina (falla de servicio).
Falla de potencia debido a la batera exhausta
(elctrico).
Interferencia elctrica con otro equipo mdico
(elctrico).
Sensor pobre e impulsor de contacto (fsico).
Partes de interrupcin de la mquina fuera del cuerpo
(fsico).
Infeccin causada por la introduccin de mquina
(biolgico).
La reaccin alrgica a materiales o insulina (biolgico).
374
Anlisis de riesgo y clasificacin
12/05/16
El proceso se preocupa por entender la probabilidad

que un riesgo surgir y las consecuencias potenciales
si un accidente o incidente deben ocurrir.
Los riesgos pueden categorizarse como:
Intolerable. Nunca debe surgir o producir un
accidente.
Tan bajo como razonablemente prctico (As low
as reasonably practical= ALARP). Debe minimizar
la posibilidad de riesgo dados el costo y restricciones
de horario.
Aceptable. Las consecuencias del riesgo son
aceptables y ningn costo extra debe incurrirse para
reducir la probabilidad de riesgo.
375
Niveles de riesgo
Regin inaceptable
El riesgo no puede ser tolerado
Riesgo tolerado slo si la

reduccin del riesgo es es
imprctico o groseramente caro
Regin
ALARP
Regin
aceptable
Riego despreciable
12/05/16
376
Aceptabilidad social del

riesgo
La aceptabilidad de un riesgo est determinada por lo humano,
las consideraciones sociales y polticas.
En la mayora de las sociedades, los lmites entre las regiones se
empujan ms con tiempo, es decir, la sociedad est menos
deseosa aceptar el riesgo.
Por ejemplo, los costos de limpiar la polucin pueden ser
menos costosa que prevenirla, pero esto no puede ser
socialmente aceptable.
La valoracin de riesgo es subjetiva.
Los riesgos se identifican como probable, improbable, etc. Esto
depende en adelante de quin est haciendo la evaluacin.
12/05/16
377
Valoracin del riesgo

Estimar
la probabilidad de riesgo y la severidad

del riesgo.
No es normalmente posible hacer esto con
precisin, puesto que
se usan valores tan
relativos como 'improbable, 'raro , muy
alto, etc.
El objetivo debe ser excluir riesgos que son
probables de surgir o si estos tienen severidad
alta.
12/05/16
378
Valoracin del riesgo

bomba de insulina
Identificacin del Probabilidad
riesgo
del riesgo
Severidad del
riesgo
Sobredosis de
insulina
Media
Alta
Alta
Intolerable
Baja dosis de
insulina
Media
Baja
Baja
Aceptable
Falla de potencia
Alta
Baja
Baja
Aceptable
Mquina ajusta
incorrectamente
Alta
Alta
Alta
Intolerable
Mquina
interrumpe en el
paciente
Baja
Alta
Media
ALARP
Mquina causa
infeccin
Media
Media
Media
ALARP
Interferencia
elctrica
Baja
Alta
Media
ALARP
Reaccin
alrgica
Baja
Baja
Baja
Aceptable
12/05/16
Riesgo
estimado
Aceptabilidad
379
Descomposicin del riesgo

Concerniente con descubrir las causas de raz de
riesgos en un sistema particular.
Las tcnicas han sido principalmente derivadas de
los sistemas de seguridad crtica y pueden ser:
Inductivo, tcnicas de abajo - arriba. Empezar
con una falla del sistema propuesto y evaluar
los riesgos que podran surgir de esa falla;
Deductivo,
tcnicas de arriba - abajo.
Empezar con un riesgo y deducir las posibles
causas de esta.
12/05/16
380
Anlisis de rbol de falla

Una
tcnica deductiva de arriba-abajo.

Poner el riesgo o azar en la raz del rbol e
identificar los estados del sistema que podran
llevar a ese riesgo.
Donde sea apropiado, unir stos con condiciones
"y" ("and ) o "o" ( "or ).
Una meta debe ser minimizar el nmero de
causas simples de falla del sistema.
12/05/16
381
rbol de falla de la bomba

de insulina
Incorrecta
Incorrectadosis
dosis
de
insulina
de insulina
administrada
administrada
Or
Or
Incorrecto
Incorrectonivel
nivel
de
deazcar
azcar
medido
medido
Correcta
Correctadosis
dosis
entregada
entregadaen
en
mal momento
mal momento
Falla
Fallade
de
sistema
sistemade
de
entrega
entrega
Or
Or
Falla
Fallade
de
sensor
sensor
Or
Or
Error
Errorde
de
cmputo
cmputo
de azcar
de azcar
Incorrecto
Incorrecto
clculo
clculode
de
insulina
insulina
Falla
Fallade
de
cronmetro
cronmetro
Or
Or
Or
Or
Error
Error
algortmico
algortmico
12/05/16
Incorrecta
Incorrecta
seal
sealde
de
bombeo
bombeo
Error
Error
aritmtico
aritmtico
Error
Error
algortmico
algortmico
Error
Error
aritmtico
aritmtico
382
Valoracin de la reduccin
del riesgo
El
objetivo de este proceso es identificar

requerimientos de confiabilidad que especifican que
cmo deben manejarse los riesgos
y deben
asegurarse que esos accidentes/incidentes no
surjan.
Estrategias de la reduccin del riesgo:
Anulacin del riesgo;
Deteccin y retiro del riesgo;
Limitacin del dao.
12/05/16
383
Uso de estrategias
Normalmente,
en los sistemas crticos, una

mezcla de estrategias de reduccin de riesgo es
usada.
En un sistema de control de planta qumico, el
sistema incluir los sensores para descubrir y
corregir el exceso de presin en el reactor.
Sin embargo, tambin incluir un un sistema de
proteccin independiente que abre una vlvula de
auxilio, si se descubre la presin peligrosamente
alta .
12/05/16
384
Bomba de insulina
riesgos de software
Error
aritmtico
Un cmputo causa el valor de una variable para
sobreflujo o subflujo;
Quiz incluya un manejador de excepcin para
cada tipo de error aritmtico.
Error algortmico
Compara dosis a ser entregada con dosis anterior
o las dosis mximo seguras. Reduce la dosis si
es demasiada alta.
12/05/16
385
Requerimientos de seguridad
bomba de insulina
SR1: El sistema no entregar una sola dosis de insulina que sea mayor
que una dosis mxima especificada para un usuario del sistema.
SR2: El sistema no entregar una dosis diariamente acumulativa de
insulina que sea mayor que un mximo especificado para un usuario
del sistema.
SR3: El sistema incluir un recurso de diagnstico de hardware que se
ejecutar por lo menos 4 veces por hora.
SR4: El sistema incluir un manejador de excepcin para todas las
excepciones que se identifican en la Tabla 3.
SR5: La alarma audible sonar cuando cualquier hardware o anomala
del software se descubre y un mensaje de diagnstico como el
definido en la Tabla 4 debe visualizarse.
SR6: En caso de una alarma en el sistema, la entrega de insulina se
suspender hasta que el usuario haya restablecido el sistema y ha
anulado la alarma.
12/05/16
386
Especificacin de seguridad
fsica
Los
requerimientos de seguridad de un sistema

deben ser especificados separadamente.
Estos requerimientos deben estar basados en un
anlisis de los posibles peligros y riesgos como
previamente se ha discutido.
Los requerimientos de seguridad normalmente se
aplican al sistema en su conjunto en lugar de a
los sub-sistemas individuales. En trminos de
ingeniera de sistemas, la seguridad de un
sistema es una propiedad emergente.
12/05/16
387
IEC 61508
Un
estndar internacional para gestin de

seguridad fsica que se dise especficamente
para los sistemas de proteccin - no es
aplicable a todos los sistemas seguridad
crticos.
Incorpora un modelo del ciclo de vida de
seguridad fsica y cubre todos los aspectos de
gestin de seguridad fsica desde la definicin
del alcance al sistema de decomiso.
12/05/16
388
del sistema de control
Requerimientos
Requerimientos
del
delsistema
sistema
Sistema
Sistemade
de
control
control
Equipamiento
Equipamiento
Sistema
Sistemade
de
proteccin
proteccin
12/05/16
Requerimientos
Requerimientosde
de
seguridad
seguridadfsica
fsica
Requerimientos
Requerimientosde
de
seguridad
fsica
seguridad fsica
funcional
funcional
Requerimientos
Requerimientosde
de
integridad
integridadde
de
seguridad
fsica
seguridad fsica
389
Ciclo de vida de la seguridad

fsica
Conceptoydefinicin
Conceptoydefinicin
dealcance
dealcance
Anlisisdepeligroy
Anlisisdepeligroy
riesgo
riesgo
Asignacinde
Asignacinde
requerimientosde
requerimientosde
seguridad
seguridad
Derivacinde
Derivacinde
requerimientosde
requerimientosde
seguridad
seguridad
Planificacin y desarrollo
Desarrollodesistemas
Desarrollodesistemas
deseguridad
deseguridad
relacionados
relacionados
Planeando
Validacin
O&M
Recursosde
Recursosde
reduccinde
reduccinde
riesgosexterno
riesgosexterno
Instalacin
Validacindeseguridad
Validacindeseguridad
defsica
defsica
Instalaciny
Instalaciny
comisionado
comisionado
Operaciny
Operaciny
mantenimiento
mantenimiento
Decomisodel
Decomisodel
sistema
sistema
12/05/16
390
fsica
Los requerimientos de seguridad fsica funcionales

stos definen las funciones de seguridad fsica del
sistema de proteccin, es decir, define cmo el
sistema debe proporcionar proteccin.
Los requerimientos de integridad de la seguridad fsica
stos definen la fiabilidad y disponibilidad del
sistema de proteccin. Ellos estn basados en el
uso esperado y son clasificados usando un nivel de
integridad de seguridad de 1 a 4.
12/05/16
391
Especificacin de la seguridad
contra delitos
Tiene un poco de similitud a la especificacin de seguridad fsica.
No es posible especificar los requerimientos de seguridad
contra delitos cuantitativamente;
Los requerimientos son a menudo "no debe" en lugar de
requerimientos "debe".
Diferencias
No hay nocin bien definida de un ciclo de vida de seguridad
contra delitos para la gestin de seguridad; no hay estndares;
Las amenazas genricas en lugar de peligros especficos del
sistema;
La tecnologa de seguridad contra delitos es madura (encriptacin,
etc.).Sin embargo, hay problemas de trasferencia de esto en el uso
general;
El dominio de un solo proveedor (Microsoft) significa que los
grandes variedad de sistemas pueden ser afectados por falla
de seguridad.
12/05/16
392
El proceso de especificacin
de seguridad contra delitos
Tecnologa
Tecnologade
de
seguridad
y
seguridad y
anlisis
anlisis
Identificacin
Identificacindel
del
recurso
recurso
Lista
Listade
derecursos
recursos
del
sistema
del sistema
12/05/16
Anlisis
Anlisisde
delala
amenaza
amenazayy
valoracin
valoracindel
del
riesgo
riesgo
Matriz
Matrizde
deriesgos
riesgosyy
amenazas
amenazas
Anlisis
Anlisisde
de
tecnologa
tecnologa
Asignacin
Asignacin
de
deamenaza
amenaza
Descripcin
Descripcinde
de
amenaza
y
amenaza y
riesgo
riesgo
Especificacin
Especificacinde
de
requerimientos
de
requerimientos de
seguridad
seguridad
Requerimientos
Requerimientosde
de
confiabilidad
confiabilidad
393
Especificacin de estados en
la seguridad contra delitos
Identificacin del recurso y evaluacin
Anlisis de la amenaza y valoracin del riesgo
Los recursos (datos y programas) y su grado requerido de

proteccin son identificados. El grado de proteccin requerida
depende del valor del recurso de modo que una contrasea de
archivo (digamos) es ms valioso que un conjunto de Web
pblicas.
Se identifican las posibles amenazas de seguridad y los riesgos
asociados con cada uno de estas amenazas son estimados.
Asignacin de la amenaza
12/05/16
Se relacionan las amenazas identificadas a los recursos para que,

para cada recurso identificado, hay una lista de amenazas
asociadas.
394
Especificacin de estados en
la seguridad contra delitos
Anlisis
de tecnologa
Se evalan las tecnologas de seguridad
disponibles y su pertinencia contra las
amenazas identificadas.
Especificacin
de
requerimientos
de
seguridad
Los
requerimientos de seguridad son
especificados. Donde sea apropiado, sern
explcitamente identificadas las tecnologas de
seguridad que pueden usarse para proteger
contra las amenazas diferentes al sistema.
12/05/16
395
Tipos de requerimientos de
Requerimientos de identificacin.
Requerimientos de autenticacin.
Requerimientos de autorizacin.
Requerimientos de inmunidad.
Requerimientos de integridad.
Requerimientos de deteccin de intrusin.
Requerimientos de no repudio.
Requerimientos de privacidad.
Requerimientos de auditoria de seguridad contra delitos.
Requerimientos de seguridad de mantenimiento del
sistema.
12/05/16
396
Requerimientos de
seguridad LIBSYS
SEC1: Todos los usuarios del sistema se identificarn usando su
nmero de tarjeta de biblioteca y la contrasea personal
SEC2: Los privilegios de usuario se asignarn segn la clase de
usuario (estudiante, personal, personal de biblioteca).
SEC3: Antes de la ejecucin de cualquier comando, LIBSYS verificar
que el usuario tiene los privilegios suficientes para acceder y ejecutar
esa orden.
SEC4: Cuando un usuario pide un documento, la demanda del orden
ser anotada. Los datos de registro mantenidos incluirn el tiempo
del pedido, la identificacin del usuario y los artculos pedidos.
SEC5: Todos los datos del sistema sern apoyados una vez por da y
las copias guardadas fuera de sitio en una rea de almacenamiento
segura.
SEC6: No se permitirn a los usuarios tener ms de 1 registro
simultneo en LIBSYS.
12/05/16
397
Especificacin de fiabilidad
de sistemas
Fiabilidad del hardware
Fiabilidad del software
Cul es la probabilidad de que un componente del hardware

est fallando y cunto tiempo toma reparar ese componente?
Cun probable es que un componente de software produzca
una salida incorrecta. Las fallas del software se diferencian
de las fallas del hardware en que las del software no lleven
fuera. Incluso puede continuar en funcionamiento despus de
que un resultado incorrecto se ha producido.
Fiabilidad del operador
12/05/16
Cun probable es que el operador de un sistema cause un

error?
398
Requerimientos de
fiabilidad funcional
Un rango predefinido para todos los valores que se
ingresan por el operador sern definidos y el
sistema verificar que todo operador ingrese
cadas dentro de ese rango predefinido.
El sistema verificar todos los discos para los
bloques malos cuando se inicialicen.
El sistema debe usar la versin N del programa
para implementar el frenado del sistema de control.
El sistema debe se implementado
en un
subconjunto seguro de Ada y debe verificarse
usando el anlisis esttico.
12/05/16
399
Especificacin de fiabilidad no
funcional
El nivel requerido de fiabilidad del sistema requerido

debe expresarse cuantitativamente.
La fiabilidad es un atributo del sistema dinmico especificaciones de fiabilidad relacionadas al cdigo
fuente no tienen sin sentido.
No ms de las N fallas/1000 lneas;
Esto slo es til para un anlisis de proceso de postentrega dnde se est intentando evaluar cuan
buenas son sus tcnicas de desarrollo.
Una mtrica de fiabilidad apropiada debe ser elegida
para especificar la fiabilidad del sistema global.
12/05/16
400
Mtricas de fiabilidad
Las
mtricas de fiabilidad son unidades de

medida de fiabilidad del sistema.
La fiabilidad del sistema es medida contando el
nmero de fallas operacionales y, dnde
apropiadamente, se relacionan stas a las
demandas hechas al sistema y el tiempo en que
el sistema ha sido operacional.
Un programa de medicin a largo plazo se exige
evaluar la fiabilidad de sistemas crticos.
12/05/16
401
Mtricas de fiabilidad
Mtrica
Explicacin
POFOD
La posibilidad de
falla en la demanda
La probabilidad que el sistema fallar cuando una

demanda de servicio es hecha. Un POFOD de 0.001
significa que 1 entre mil demandas de servicio pueden
producir una falla.
ROCOF
La proporcin de
ocurrencia de falla
La frecuencia de ocurrencia de que un comportamiento

inesperado ocurra. Un ROCOF de 2/100 significa que es
probable que 2 fallas ocurran de cada 100 unidades de
tiempo operacionales. Esta mtrica a veces se llama la
intensidad de falla.
MTTF
Tiempo
media de falla
El tiempo promedio de falla. El tiempo promedio entre las

fallas del sistema observados. Un MTTF de 500 significa
que 1 falla puede esperarse de cada 500 unidades de
tiempo.
AVAIL Disponibilidad
La probabilidad de que el sistema est disponible para el

uso en un momento dado. La disponibilidad de 0.998
significa que de cada 1000 unidades de tiempo, es
probable que el sistema est disponible para 998 de stos.
12/05/16
402
Probabilidad de falla en demanda

Esta es la probabilidad que el sistema fallar cuando
una demanda de servicio sea hecha. Es til cuando
las demandas para el servicio son intermitentes y
relativamente poco frecuente.
Apropiado para los sistemas de proteccin dnde se
exigen los servicios de vez en cuando y donde hay
consecuencias serias si el servicio no se entrega.
Relevante
para muchos sistemas de seguridad
crticos con los componentes de gestin de excepcin
El sistema de cierre de emergencia en una planta
qumica.
12/05/16
403
Tasa de ocurrencia de falla

(ROCOF)
Refleja la tasa de ocurrencia de falla en el sistema.
Un ROCOF de 0.002 significa que 2 fallas son
probables en cada 1000 unidades de tiempo
operacionales, por ejemplo, 2 fallas por 1000 horas
de funcionamiento.
Relevante para los sistemas operativos, transaccin
que procesa sistemas dnde el sistema tiene que
procesar un nmero grande de demandas similares
que son relativamente frecuentes.
12/05/16
Sistema de procesamiento de tarjeta de crdito,

sistema de reserva en aerolnea.
404
Tiempo media de falla
La medida del tiempo entre las fallas observadas del

sistema. Es el recproco de ROCOF para los sistemas
estables.
MTTF de 500 significa que el tiempo medio entre fallas
es de 500 unidades de tiempo.
Relevante para sistemas con transacciones largas, es
decir, donde el proceso del sistema toma un tiempo
largo. MTTF debe ser ms largo que la longitud de la
transaccin.
Sistemas del diseo auxiliado por computadora
dnde un diseador trabajar en un diseo de varias
horas, sistemas de procesador de texto.
12/05/16
405
Disponibilidad
La medida de la fraccin de tiempo que el sistema
est disponible para el uso.
Se toman los tiempos de reparo y reinicio en la
cuenta.
Una disponibilidad de 0.998 significa que el software
est disponible para 998 de 1000 unidades de
tiempo.
Relevante para sistemas sin para, continuamente
ejecutables.
sistemas de intercambio de telfonos, sistemas de
sealamiento de vas frreas.
12/05/16
406
Especificacin de
requerimientos no funcionales
Las
mediciones de fiabilidad NO tienen en cuenta

las consecuencias de falla.
Las fallas transitorias pueden no tener ninguna
consecuencia real, pero otras fallas pueden
causar prdida o corrupcin de datos y prdida
de servicio del sistema.
Puede ser necesario identificar diferentes clases
de fallas y usar mtricas diferentes para cada una
de stas. La especificacin de fiabilidad debe ser
estructurada.
12/05/16
407
Consecuencias de fallas
Al
especificar la fiabilidad, no es slo el nmero

de fallas del sistema que importan sino las
consecuencias de estas fallas.
Las fallas que tienen consecuencias serias son
claramente ms perjudiciales que aqullos dnde
se las repara y la recuperacin es directa.
En
algunos casos, por consiguiente,
especificaciones de fiabilidad diferentes para
diferentes tipos de falla pueden ser definidas.
12/05/16
408
Clasificacin de fallas
Clase de falla
Descripcin
Transitoria
Slo ocurre con ciertas entradas.
Permanente
Ocurre con todas las entradas.
Recuperable El sistema puede recuperarla sin la
intervencin del operador.
Inrecuperable Necesita
la
intervencin
operador recuperar la falla.
del
No corrupta
La falla no corrompe el estado del

sistema o datos
Corrupta
La falla corrompe el estado del

sistema o datos.
12/05/16
409
Pasos para especificacin

de fiabilidad
Para
cada
sub-sistema,
analizar
las
consecuencias de posibles fallas del sistema.
Desde el anlisis de falla del sistema, fallas de
particin dentro de las clases apropiadas.
Para cada clase de falla identificada, presentar
la fiabilidad usando una mtrica apropiada.
Diferentes mtricas pueden usarse para los
requerimientos de fiabilidad diferentes.
Identificar los requerimientos de fiabilidad
funcionales para reducir las oportunidades de
fallas crticas.
12/05/16
410
Sistema de cajero automtico

Cada
mquina en una red es usada 300 veces

por da.
El banco tiene 1000 mquinas.
El tiempo de vida de lanzamiento del software es
de 2 aos.
Cada mquina maneja aproximadamente 200,
000 transacciones.
Aproximadamente 300, 000 transacciones de la
base de datos en total por da.
12/05/16
411
Especificacin de
fiabilidad para un CA
Clases de
falla
Ejemplo
Mtrica de
fiabilidad
Permanente
no corrupta
El sistema falla para operar con

cualquier tarjeta que se entra. El
software debe reiniciarse para
corregir la falla.
Transitoria
no corrupta
Los datos de la franja magntica ROCOF

no pueden leerse en una tarjeta 1
en
1000
no daada que se ingresa.
transacciones
Transitoria
corrupta
Un patrn de transacciones a No
travs
de
la
red
causa cuantificable!
corrupcin de base de datos. Nunca
debe
pasar en la vida
del sistema.
12/05/16
ROCOF
1
ocurrencia/1000
das.
412
Validacin de la especificacin
Es
imposible validar empricamente las

especificaciones de fiabilidad muy altas.
Ninguna corrupcin de base de datos significa
POFOD de menos de 1 en 200 milln.
Si una transaccin toma 1 segundo, entonces
simulando una transaccin por da toma 3.5
das.
Tomara
mucho ms tiempo que la vida del
sistema probarlo para la fiabilidad.
12/05/16
413
Puntos clave
El anlisis de riesgo es la base por identificar los
requerimientos de fiabilidad del sistema.
El anlisis de riesgo se preocupa por evaluar las
oportunidades de surgimiento de un riesgo y
clasificar los riesgos segn su gravedad.
Los requerimientos de seguridad contra delitos
deben identificar los recursos y definir cmo
deben protegerse stos.
Pueden definirse los requerimientos de fiabilidad
cuantitativamente.
12/05/16
414
Puntos clave
Las
mtricas de fiabilidad incluyen

POFOD, ROCOF, MTTF y disponibilidad.
Las especificaciones no funcionales de
la fiabilidad pueden llevar a los
requerimientos del sistema funcionales
reducir las fallas o tratar con su
ocurrencia.
12/05/16
415
Captulo 10
Especificaciones
formales
12/05/16
416
Objetivos
Explicar
por qu las especificaciones tcnicas

formales ayudan a descubrir los problemas en
los requerimientos del sistema.
Describir el uso de tcnicas algebraicas para
la especificacin de la interfaz.
Describir el uso de tcnicas basadas en
modelo
para
la
especificacin
del
comportamiento.
12/05/16
417
Tpicos cubiertos
Especificacin
formal en el proceso
de software
Especificacin de la interfaz de un
sub-sistema
Especificacin del comportamiento
12/05/16
418
Mtodos formales
La especificacin formal es parte de una coleccin
ms general de tcnicas que son conocidas como
"los mtodos formales".
Ellos estn todas basados en la representacin
matemtica y anlisis de software.
Los mtodos formales incluyen
Especificacin formal;
Anlisis de especificacin y demostracin;
Desarrollo transformacional;
Verificacin de programa.
12/05/16
419
Aceptacin de los mtodos

formales
12/05/16
Los mtodos formales no se han vuelto en la corriente principal de las

tcnicas de desarrollo de software como se predijo una vez.
Otras tcnicas de ingeniera de software ha sido exitosas en la
calidad creciente de sistemas . De all que la necesidad para los
mtodos formales ha estado reducida;
Los cambios del mercado han hecho el tiempo de comercializar en
lugar del software con una cuenta de error baja como factor clave.
Los mtodos formales no reducen tiempo el tiempo de
comercializar;
El alcance de los mtodos formales est limitado. Ellos no estn
preparados para especificar y analizar las interfaces del usuario e
interaccin del usuario;
Los mtodos formales todava son difciles para escalar a los
sistemas grandes.
420
Uso de mtodos formales

Los principales beneficios de los mtodos formales
estn en la reduccin del nmero de faltas en los
sistemas.
Por consiguiente, su rea principal de aplicabilidad
est en la ingeniera de sistemas crticos. Ha habido
varios proyectos exitosos dnde se han usado los
mtodos formales en este rea.
En esta rea, el uso de mtodos formales es
probablemente el ms rentable porque deben
evitarse los altos costos de falla del sistema .
12/05/16
421
Especificacin en el proceso de
software
La
especificacin y el diseo se entremezclan

indisolublemente.
El
diseo arquitectnico es esencial para
estructurar una especificacin y el proceso de
especificacin.
Las especificaciones formales son expresadas
en una notacin matemtica con el vocabulario
precisamente definido, sintaxis y semntica.
12/05/16
422
Especificacin y diseo
Participacin creciente del contratista
Participacin decreciente del cliente
Definicin
Definicinde
de
requerimientos
requerimientos
del
delusuario
usuario
Especificacin
Especificacinde
de
requerimientos
requerimientos
del
delsistema
sistema
Diseo
Diseo
arquitectnico
arquitectnico
Especificacin
Especificacin
formal
formal
Diseo
Diseode
de
alto
nivel
alto nivel
Especificacin
Diseo
12/05/16
423
Especificacin en el proceso de
software
Especificacin
Especificacinde
de
requerimientos
requerimientos
del
delsistema
sistema
Especificacin
Especificacin
formal
formal
Diseo
Diseode
de
alto
nivel
alto nivel
Definicin
Definicinde
de
requerimientos
requerimientos
del
delusuario
usuario
Modelamiento
Modelamientodel
del
sistema
sistema
12/05/16
Diseo
Diseo
arquitectnico
arquitectnico
424
Uso de la especificacin
formal
La especificacin formal se involucra invirtiendo ms

esfuerzo en las fases tempranas de desarrollo del
software.
Esto reduce los errores de requerimientos forzando un
anlisis detallado de los requerimientos.
Pueden
descubrirse
estados
incompletos
e
inconsistencias y pueden resolverse.
En consecuencia, economas como la cantidad de
retrabajo debido a los problemas de requerimientos, se
reducen.
12/05/16
425
El perfil del costo

El
uso de especificacin formal significa que el

perfil del costo de un proyecto cambia
Hay
grandes costos claros como el mayor
tiempo y esfuerzo que son gastados
desarrollando la especificacin;
Sin embargo, los costos de implementacin y
validacin deben ser reducidos as como el
proceso de la especificacin reduce errores y
ambigedades en los requerimientos.
12/05/16
426
Desarrollo de costos con

especificacin formal
12/05/16
427
Especificaciones tcnicas
Especificacin
El sistema es especificado en trminos de sus

operaciones y sus interrelaciones.
Especificacin
12/05/16
algebraica
basada en modelo
El sistema es especificado en trminos de un modelo

de estados que es construido usando construcciones
matemticas tales como conjuntos y sucesiones. Las
operaciones son definidas por modificaciones del
estado del sistema.
428
Lenguajes de
especificacin formal
Algebraico
Basado en
modelo
12/05/16
Secuencial
Concurrente
Larch(Guttag, 1993) Lotos (Bolognesi y
OBJ
(Futatsugi, Brinksma, 1987)
1985)
Z (Spivey, 1992)
VDM (Jones, 1980)
B (Worsworth, 1996)
CSP (Hoare, 1985)

Petri
Nets
(Peterson 1981)
429
Los sistemas grandes se descomponen en
subsistemas con las interfaces bien definidas entre
estos subsistemas.
La especificacin de interfaces de subsistema
permite el desarrollo independiente de subsistemas
diferentes.
Las interfaces pueden ser definidas como tipos de
datos abstractos o clases de objetos.
La aproximacin algebraica para la especificacin
formal est particularmente bien preparada para la
especificacin de la interfaz como se enfoca en las
operaciones definidas en un objeto.
12/05/16
430
Interfaces de subsistema
Objetos de interfaz
Sub - sistema
A
12/05/16
Sub - sistema
B
431
La estructura de una
especificacin algebraica
<SPECIFICATION NAME>
sort <name>
Imports <LIST OF SPECIFICATION NAMES>
Descripcin informal de clase y sus operaciones
Signatura de operaciones que ponen encima los

nombres y los tipos de parmetros para las
operaciones definidas sobre la clase
Axiomas que definen operaciones sobre la clase
12/05/16
432
Componentes de especificacin
Introduccin
Define la clase (el nombre de tipo) y declara otras
especificaciones que son usados.
Descripcin
Informalmente describe las operaciones en el tipo.
Signatura
Define la sintaxis de las operaciones en la interfaz y sus
parmetros.
Axiomas
Define las semnticas de la operacin por axiomas de
definicin que caracterizan el comportamiento.
12/05/16
433
Especificacin algebraica
sistemtica
Especificaciones
algebraica de un sistema puede

ser desarrollada de una manera especfica:
12/05/16
Estructuracin de la especificacin;
Denominacin de la especificacin;
Seleccin de operacin;
Especificacin de operacin informal;
Definicin de la sintaxis;
Definicin del axioma.
434
Operaciones de especificacin
Operaciones
de constructor. Operaciones que

crean entidades de un tipo que es especificado.
Operaciones de inspeccin. Operaciones que
evalan entidades de un tipo que es
especificado.
Para especificar el comportamiento. Define las
operaciones de inspector por cada operacin
constructor.
12/05/16
435
Operaciones en una lista

ADT
Operaciones de constructor que evalan para
Lista de clase.
Create, Cons y Tail.
Operaciones de inspeccin que toma lista de la
clase como un parmetro y devuelven alguna otra
clase
Head y Length.
Tail puede ser definida usando constructores
simples Create y Cons. No se necesita definir Head
y Length con Tail.
12/05/16
436
Especificacin de List
List (Elem)
sort List
Imputs Integer
Define una lista dnde los elementos son agregados al final y retirados del frente. Las operaciones son Create qu
trae una lista vaca en existencia, Cons que crea una nueva lista con un miembro agregado, Length que evala el
tamao de la lista, Head que evala el elemento delantero de la lista y Tail que crea una lista quitando la cabeza de su
lista de la entrada. Undefined representa un valor indefinido de tipo Elem.
Create List
Cons(List, Elem) List
Head(List) Elem
Length(List) Integer
Tail(List) List
Head(Create) = Undefined exception (empty list)
Head(Cons(L, v) = if L = Create then v else Head(L)
Length(Create) = 0
Length(Cons(L,v)) = Length(L) + 1
Tail(Create) = Create
Tail(Create(L, v))= if L = Create then Create else Cons(Tail(L),v)
12/05/16
437
Recursin en
especificaciones
Las
operaciones se especifican a menudo

recursivamente.
12/05/16
Tail (Cons (L, v)) = if L = Create then Create

else Cons (Tail (L), v).
Cons ([5, 7], 9) = [5, 7, 9]
Tail ([5, 7, 9]) = Tail (Cons ( [5, 7], 9)) =
Cons (Tail ([5, 7]), 9) = Cons (Tail (Cons ([5], 7)), 9) =
Cons (Cons (Tail ([5]), 7), 9) =
Cons (Cons (Tail (Cons ([], 5)), 7), 9) =
Cons (Cons ([Create], 7), 9) = Cons ([7], 9) = [7, 9]
438
en sistemas crticos
Considerar
un sistema de control de trfico

areo dnde el vuelo del avin a travs de los
sectores manejados de espacio areo.
Cada sector puede incluir varios aviones pero,
por razones de seguridad, stos deben
separarse.
En este ejemplo, una separacin vertical
simple de 300m es propuesta.
El sistema debe advertir al controlador si el
avin es instruido para moverse de modo que
la regla de la separacin abra una brecha.
12/05/16
439
Un objeto de sector
Las
operaciones crticas en un objeto que

representan un sector controlado son:
Enter. Agrega un avin al espacio areo
controlado.
Leave. Retira un avin desde el espaci areo
controlado;
Move. Mueve un avin de una altura a otra;
Lookup.
Dado un identificador del avin,
devuelve su altura actual.
12/05/16
440
Operaciones primitivas
12/05/16
A veces es necesario introducir operaciones adicionales

para simplificar la especificacin.
Las otras operaciones pueden entonces ser definidas
usando estas ms operaciones primitivas.
Operaciones primitivas
Create. Trae una instancia de un sector en existencia;
Put. Agrega un avin sin revisiones de seguridad;
In-space. Determina si un avin dado est en el
sector;
Occupied. Dada una altura, determina si hay un
avin dentro de 300m de esa altura.
441
Especificacin de sector (1)

SECTOR
sort Sector
Imputs INTEGER, BOOLEAN
Enter agrega un avin en el sector si las condiciones de seguridad fsica.
Leave retira un avin desde el sector.
Move - mueve un avin desde una altura a otra si est seguro de hacerlo
Lookup halla la altura de un avin en el sector
Create crea un sector vaco
Put agrega un avin a un sector sin controles de restricciones
In-space - controla si un avin ya est en un sector
Occupied -controla si una altura especificada est disponible.
Enter (Sector, Call-sign, Height) Sector
Leave (Sector, Call-sign) Sector
Move (Sector, Call-sign, Height) Sector
Lookup (Sector, Call-sign) Height
Create Sector
Put (Sector, Call-sign, Height) Sector
In-space (Sector, Call-sign) Boolean
Occupied (Sector, Height) Boolean
12/05/16
442
Especificacin de sector (2)

Enter (S, CS, H)
If In-space (S, CS) then S exception (Hay avin en el sector)
elseif Occupied (S, H) then S exception (Conflicto de altura)
else Put (S, CS, H)
Leave (Create, CS) = Create exception (No hay avin en el sector)
Leave (Put(S, CS1, H1), CS) =
if CS = CS1 then S else Put (Leave (S, CS), CS1, H1)
Move (S, CS, H) =
if S = (Create then Create exception (No hay avin en el sector)
elseif not In-space (S, CS) then S exception (No hay avin en el sector)
elseif Occupied (S, H) then S exception (Conflicto de altura)
else Put (Leave (S, CS),CS, H)
..NO -HEIGHT es una constante indicando que una altura valida no puede ser devuelta
Lookup (Create, CS) = NO .HEIGHT exception (No hay avin en el sector)
Lookup (Put (S, CS1, H1), CS) =
if CS = CS1 then H1 else Lookup (S, CS)
Occupied (Create, H) = false
Occupied (Put (S, CS1, H1), H) =
if (H1 > H and H1 H ^S 3 00) or (H >H1
and H H ^S 3 00) then true
else Occupied (S, H)

In-space (Create, CS) = false
In-space (Put (S, CS1, H1), CS) =
if CS = CS1 then true else In-space (S, CS)
12/05/16
443
Comentario de especificacin
Usar
los constructores bsicos Create y Put

para especificar otras operaciones.
Definir Occupied e In- space usando Create y
Put y usarlos para hacer los controles en otras
definiciones de operacin.
Todos las operaciones que producen los cambios
para el sector deben verificar el sostenimiento de
criterio de seguridad.
12/05/16
444
Especificacin del
comportamiento
La
especificacin
algebraica
puede
ser
embarazosa cuando las operaciones del objeto
no son independientes del estado del objeto.
La especificacin basado en modelo expone el
estado del sistema y define las operaciones en
trminos de cambios para ese estado.
La notacin Z es una tcnica madura para la
especificacin basada en modelo. Combina
descripcin formal e informal y usa el resaltado
grfico al presentar las especificaciones.
12/05/16
445
La estructura de un esquema Z
Nombre del esquema
Signatura del esquema
Predicado del esquema
Container
contents
capacity N
contents ^S = capacity
12/05/16
446
Modelando la bomba de
insulina
El
esquema Z para la bomba de insulina declara

una variedad de variables de estado incluyendo:
12/05/16
Las variables de entrada como interruptor? (el

dispositivo interruptor), Depsito de insulina? (la
cantidad actual de insulina en el depsito) Leyendo?
(la lectura del sensor);
Las variables de salida como alarma! (una alarma
del sistema), display1!, display2! (lo visualizaciones
en la bomba) y dosis! (la dosis de insulina a ser
entregada).
447
Invariante del esquema

Cada
esquema Z tiene una parte invariante que

define condiciones que siempre son verdad.
Para el esquema de bomba de insulina es siempre
verdad que
12/05/16
La dosis debe ser menor o igual a la capacidad del

depsito de insulina;
Ninguna sola dosis puede estar en ms de 4 unidades de
insulina y la dosis total entregada en un periodo de tiempo
no debe exceder 25 unidades de insulina. ste es una
restriccin de seguridad;
display2! muestra la cantidad de insulina a ser entregada.
448
Esquema de la bomba de
insulina
INSULIN_PUMP_STATE
//Input device definition

switch?: (off, manual, auto)
ManualDeliveryButton?: N
Reading?: N
HardwareTest?: (OK, batterylow, pumpfail, sensorfail, deliveryfail)
InsulinReservoir?: (present, notpresent)
Needle?: (present, notpresent)
clock?: TIME
//Output device definition
alarm! = (on, off)
display1!, string
display2!: string
clock!: TIME
dose!: N
// State variables used for dose computation
status: (running, warning, error)
r0, r1, r2: N
capacity, insulin_available : N
max_daily_dose, max_single_dose, minimum_dose: N
safemin, safemax: N
CompDose, cumulative_dose: N
12/05/16
449
Invariantes de estado
r2 = Reading?
dose! ^S insulin_available
insulin_available ^S capacity
// The cumulative dose of insulin delivered is set to zero once every 24
hours
clock? = 000000 cumulative_dose = 0
// If the cumulative dose exceeds the limit then operation is suspended
cumulative_dose max_daily_dose
display1! = Daily dose exceeded
status
error
// Pump configuration parameters

capacity = 100 safemin = 6 safemax = 14
max_daily_dose = 25 max_single_dose = 4 minimum_dose = 1
display2! = nat_to_string (dose!)
clock! = clock?
12/05/16
450
El clculo de dosaje
La
bomba de insulina calcula la cantidad de

insulina requerida comparando la lectura actual
con dos lecturas anteriores.
Si stos sugieren que la glucosa de sangre est
subiendo entonces que la insulina se entregue.
La informacin sobre la dosis total entregada es
mantenida para permitir que la seguridad verifique
invariante a ser aplicada.
Ntese que este invariante siempre aplica - No
hay ninguna necesidad de repetirlo en el clculo
de la dosificacin.
12/05/16
451
Ejecutando esquema (1)

RUN
INSULIN_PUMP_STATE
switch? = auto
status = running status = warning
insulin_available max_single_dose
cumulative_dose < max_daily_dose
// The dose of insulin is computed depending on the blood sugar level
(SUGAR_LOW SUGAR_OK SUGAR_HIGH)
// 1. If the computed insulin dose is zero, dont deliver any insulin
CompDose = 0 dose! = 0
// 2. The maximum daily dose would be exceeded if the computed dose was delivered so the insulin
dose is set to the difference between the maximum allowed daily dose and the cumulative dose
delivered so far
CompDose + cumulative_dose > max_daily_dose alarm! = on status = warning dose! =
max_daily_dose cumulative_dose
12/05/16
452
Ejecutando esquema (2)

// 3. The normal situation. If maximum single dose is not exceeded then deliver
the computed dose. If the single dose computed is too high, restrict the dose
delivered to the maximum single dose
CompDose + cumulative_dose < max_daily_dose
( CompDose max_single_dose dose! = CompDose
CompDose > max_single_dose dose! = max_single_dose )

insulin_available = insulin_available dose!
cumulative_dose = cumulative_dose + dose!
insulin_available max_single_dose * 4 status = warning
display1! = Insulin low
r1 = r2
r0 = r1
12/05/16
453
Esquema de Azcar OK
SUGAR_OK
r2 safemin r2 safemax
// sugar level stable or falling
r2 r1 CompDose = 0
// sugar level increasing but rate of increase falling

r2 > r1 (r2-r1) < (r1-r0) CompDose = 0
// sugar level increasing and rate of increase increasing compute dose

// a minimum dose must be delivered if rounded to zero
r2 > r1 (r2-r1) (r1-r0) (round ((r2-r1)/4) = 0)
CompDose = minimum_dose
r2 > r1 (r2-r1) (r1-r0)
(round ((r2-r1)/4) > 0)
CompDose = round ((r2-r1)/4)

12/05/16
454
Puntos clave
12/05/16
La especificacin de un sistema formal complementa

las tcnicas de la especificacin informales.
Las especificaciones formales son precisas e
inequvocas. Ellos quitan reas de duda en una
especificacin.
La especificacin formal fuerza un anlisis de los
requerimiento del sistema en una fase temprana. La
correccin de errores en esta fase es ms barata que
modificando un sistema entregado.
Las tcnicas de especificacin formal son ms
aplicables en el desarrollo de sistemas crticos y
estndares.
455
Puntos clave
Las
tcnicas algebraicas estn preparadas para la

especificacin de una interfaz, dnde la interfaz se
define como un conjunto de clases del objetos.
Las tcnicas basadas en modelo modelan el
sistema usando conjuntos y funciones. Esto
simplifica algunos tipos de especificacin del
comportamiento.
Las
operaciones son definidas en una
especificacin basada en modelo, definiendo pre
y post condiciones en el estado del sistema.
12/05/16
456
Captulo 11
Diseo
arquitectnico
12/05/16
457
Objetivos
Introducir el diseo arquitectnico y discutir su
importancia
Explicar las decisiones del diseo arquitectnico que
deben ser tomadas
Introducir
tres
estilos
arquitectnicos
complementarios
que cubren la organizacin,
descomposicin y control.
Discutir las arquitecturas de referencia que se usan
para comunicar y comparar las arquitecturas
12/05/16
458
Tpicos cubiertos
Decisiones
del diseo arquitectnico

Organizacin del sistema
Estilos de descomposicin
Estilos de control
Arquitecturas de referencia
12/05/16
459
Arquitectura del software

El
proceso de diseo para identificar

los sub-sistemas construyendo un
sistema y el framework para el control
de sub-sistemas y la comunicacin es
el diseo arquitectnico.
La salida de este proceso de diseo es
una descripcin de la arquitectura del
software.
12/05/16
460
Diseo arquitectnico
Una
fase temprana del proceso de diseo del

sistema.
Representa el eslabn entre la especificacin y
procesos del diseo.
A menudo se desarrolla en paralelo con algunas
actividades de especificacin.
Involucra la identificacin de los componentes del
sistema mayor y sus comunicaciones.
12/05/16
461
Ventajas de una
arquitectura explcita
Comunicacin
con los Stakeholder

La arquitectura puede usarse como un enfoque
de discusin por los stakeholders del sistema.
Anlisis del sistema
Significa que el anlisis de que si el sistema
puede reunir sus requerimientos no funcionales,
es posible.
Reuso a gran escala
La arquitectura puede ser reusable a travs de
un rango de sistemas.
12/05/16
462
Arquitectura y caractersticas
del sistema
Desempeo
Localiza las operaciones crticas y minimiza las comunicaciones.
Usa grandes componentes en lugar de los componentes de grano
fino.
Usa una arquitectura de capas con los recursos crticos en las
capas internas.
Seguridad fsica
Localiza los rasgos de seguridad-crtica en un nmero pequeo
de sub-sistemas.
Disponibilidad
Incluye componentes redundantes y mecanismos para la
tolerancia de falla.
Mantenibilidad
Usa componentes de grano fino, reemplazables.
12/05/16
463
Conflictos arquitectnicos
Usando
componentes de grano grande mejora el

desempeo pero reduce la mantenibilidad.
Introduciendo
datos redundantes mejora la
disponibilidad pero realizar la seguridad es ms
difcil.
La localizacin de hechos relacionados con la
seguridad fsica normalmente significa ms
comunicacin as como desempeo degradado.
12/05/16
464
Estructuracin del sistema

Concerniente
con descomponer el sistema en

los subsistemas entrelazados.
El diseo arquitectnico normalmente se expresa
como un diagrama del bloque que presenta una
apreciacin global de la estructura del sistema.
La exhibicin de ms modelos especficos cmo
los sub-sistemas comparten datos, son
distribuidos y la interfaz con otros tambin puede
desarrollarse.
12/05/16
465
Sistema de control de
robot empaquetado
Sistema
Sistema
de
deVisin
Visin
Sistema
Sistemade
de
identificacin
identificacin
de
deobjetos
objetos
Controlador
Controlador
de
debrazo
brazo
Controlador
Controlador
de
depinza
pinza
Sistema
Sistemade
de
seleccin
de
seleccin de
empaquetamiento
empaquetamiento
Sistema
Sistemade
de
condensado
condensado
12/05/16
Controlador
Controlador
de
deportador
portador
466
Diagramas de caja y lnea

Muy
abstracto - ellos no muestran la

naturaleza
de
relaciones
de
componente ni las
propiedades
visibles externamente
de los subsistemas.
Sin
embargo, es til para la
comunicacin con los stakeholders y
para la planificacin del proyecto.
12/05/16
467
Decisiones del diseo

arquitectnico
El
diseo arquitectnico es un
proceso creativo de modo que el
proceso difiera dependiendo del tipo
de sistema que se desarrolla.
Sin
embargo, una variedad de
decisiones comunes alcanzan a todos
los procesos del diseo.
12/05/16
468
Decisiones del diseo

arquitectnico
Hay
una arquitectura de aplicacin genrica que

puede usarse?
Cmo se distribuir el sistema ?
Qu estilos arquitectnicos son apropiados?
Qu aproximacin se usar para estructurar el
sistema?
Cmo se descompondr el sistema en mdulos?
Qu estrategia del control debe usarse?
Cmo se evaluar el diseo arquitectnico?
Cmo debe documentarse la arquitectura ?
12/05/16
469
Reuso de la arquitectura
Los
sistemas en el mismo dominio tienen a

menudo arquitecturas similares que reflejan los
conceptos del dominio.
Las
lneas de producto de aplicacin se
construyen alrededor de una arquitectura de
centro con variantes que satisfacen los
requerimientos del clientes particulares.
Las arquitecturas de aplicacin se cubren en el
Captulo 13 y lneas de producto en el Captulo
18.
12/05/16
470
Estilos de Arquitectura
El
modelo arquitectnico de un sistema puede

conformar un modelo arquitectnico genrico o
estilo.
Un
conocimiento de estos estilos puede
simplificar el problema de definir las arquitecturas
del sistema.
Sin embargo, los sistemas ms
grandes son
heterogneos y no siguen un solo estilo
arquitectnico.
12/05/16
471
Modelos arquitectnicos
Usados para documentar el diseo arquitectnico.

Modelo estructural esttico que muestra los componentes
del sistema mayor.
Modelo del proceso dinmico que muestra la estructura del
proceso del sistema.
Modelo de la interfaz que define las interfaces de
subsistemas.
Modelo de interrelaciones como un modelo de flujo de
datos que muestran las interrelaciones del subsistemas.
Modelo de la distribucin que muestra cmo los
subsistemas son distribuidas a travs de las computadoras.
12/05/16
472
Organizacin del sistema

Refleja
la estrategia bsica que se usa para

estructurar un sistema.
Tres
estilos organizacionales son usados
ampliamente:
Un estilo de almacn de datos compartido;
Un estilo de servicios compartido y de
servidores;
Un estilo de mquina abstracta o capas.
12/05/16
473
Un modelo de almacn
Los
subsistemas deben intercambiar datos. Esto

puede hacerse de dos maneras:
Los datos compartidos se sostienes en una base de

datos central o almacn y pueden ser accedidos por
todos los subsistemas;
Cada subsistema mantiene su propia base de datos y
pasa los datos explcitamente a otros subsistemas.
Cuando grandes cantidades de datos sern

compartidas, el modelo del almacn de datos
compartidos es el ms comnmente usado.
12/05/16
474
Arquitectura del conjunto

de herramientas CASE
Editor
Editorde
de
diseo
diseo
Traductor
Traductor
de
dediseo
diseo
Almacn
Almacn
del
del proyecto
proyecto
Analizador
Analizador
de
dediseo
diseo
12/05/16
Generador
Generador
de
decdigo
cdigo
Editor
Editorde
de
programa
programa
Generador
Generador
de
deinformes
informes
475
Caractersticas del
modelo de almacn
12/05/16
Ventajas
Manera eficaz de compartir grandes cantidades de datos;
Los subsistemas necesitan no ser involucrados cmo datos
producido por gestin Centralizada por ejemplo, copia de
respaldo, la seguridad, etc.,
El modelo compartido es publicado como el esquema del
almacn.
Desventajas
Los subsistemas deben estar de acuerdo a un modelo de
datos de almacn. Inevitablemente un compromiso;
La evolucin de los datos es difcil y cara;
Ningn alcance para las polticas de gestin especficas;
Dificultad para distribuir eficazmente.
476
Modelo cliente-servidor
Modelo
de sistema distribuido que muestra cmo

los datos y procesamiento son distribuidos a
travs de un rango de componentes.
Conjunto
de servidores autosuficientes que
proporcionan servicios especficos como imprimir,
la gestin de datos, etc.
Conjunto de clientes que llaman a estos servicios.
Red que les permite a los clientes acceder a los
servidores.
12/05/16
477
Librera de pelcula y pintura

Cliente
Cliente 11
Cliente
Cliente 22
Cliente
Cliente 33
Cliente
Cliente 44
Internet
Internet
Servidor
Servidorde
de
catlogo
catlogo
Servidor
Servidorde
de
video
video
Servidor
Servidorde
de
pinturas
pinturas
Servidor
Servidorde
de
Web
Web
Catlogo
Catlogode
de
librera
librera
Archivos
Archivosde
de
pelculas
pelculasyy
clips
clips
Grficos
Grficosde
de
fotos
fotos
digitalizadas
digitalizadas
Informacin
Informacin
de
defotos
fotosyy
pelculas
pelculas
12/05/16
478
Caractersticas de clienteservidor
Ventajas
La distribucin de datos es sincera;
Hace uso eficaz de sistemas conectados a una red de
computadoras. Puede requerir hardware ms barato;
Fcil para agregar nuevos servidores o actualizar los
servidores existentes.
Desventajas
Ningn modelo de datos compartidos para subsistemas
usan organizacin de datos diferentes. El intercambio de
datos puede ser ineficaz;
Gestin redundante en cada servidor;
Ningn registro central de nombres y servicios - puede ser
difcil averiguar qu servidores y servicios estn disponibles.
12/05/16
479
Modelo de mquina
abstracta (capas)
Usado
por modelar la interfaz de subsistemas.

Organiza el sistema en un conjunto de capas (o
mquinas abstractas) cada una de los cuales
proporciona un conjunto de servicios.
Soporta el desarrollo incremental de subsistemas
en las diferentes capas. Cuando una interfaz de
capa cambia, slo la capa adyacente es afectada.
Sin embargo, a menudo artificial para estructurar
sistemas de esta manera.
12/05/16
480
Sistema de gestin de versin

Capa
Capa de
de sistema
sistema de
de gestin
gestin de
de configuracin
configuracin
Capa
Capa de
de sistema
sistema de
de gestin
gestin de
de objetos
objetos
Capa
Capa de
de sistema
sistema de
de base
base de
de datos
datos
Capa
Capa de
de sistema
sistema operativo
operativo
12/05/16
481
Estilos de
descomposicin modular
Estilos
de descomponer subsistemas
en los mdulos.
Ninguna distincin rgida entre la
organizacin del sistema y la
descomposicin modular.
12/05/16
482
Subsistemas y mdulos
Un
subsistema es un sistema con propio

derecho
,cuyo
funcionamiento
es
independiente
de
los
servicios
proporcionados por otros subsistemas.
Un mdulo es un componente del sistema
que proporciona servicios a otros
componentes, pero normalmente no sera
considerado como un sistema separado.
12/05/16
483
Descomposicin modular
Otro nivel estructural dnde

subsistemas son
descompuestos en mdulos.
Dos modelos de descomposicin modular cubiertos
Un modelo de objetos dnde el sistema se
descompone en objetos interactivos;
Un segmento (pipeline) o modelo de flujo de datos
dnde el sistema se descompone en mdulos
funcionales que transforman las entradas en salidas
Si es posible, las decisiones acerca de concurrencia
deben postergarse hasta que se implementen los
mdulos.
12/05/16
484
Modelo de objetos
Estructura
el sistema en un conjunto de objetos

dbilmente acoplados con
interfaces bien
definidas.
La descomposicin orientada a objetos se
preocupa por identificar clases de objetos, sus
atributos y operaciones.
Cuando es implementado, se crean los objetos
de estas clases y algn modelo de control es
usada para coordinar las operaciones de objetos.
12/05/16
485
Sistema de proceso de factura

Recibo
Cliente
NumCliente
Nombre
Direccin
PeriodoCrdito
Pago
NumFactura
Fecha
Cantidad
NumCliente
12/05/16
Factura
NumFactura
Fecha
Cantidad
Cliente
NumFactura
Fecha
Cantidad
NumCliente
Emitir()
EnviarRecordatorio()
AceptarPago()
EnviarRecibo()
486
Ventajas del modelo de

objetos
Los objetos son dbilmente acoplados para que su
implementacin puede modificarse sin afectar a
otros objetos.
Los objetos pueden reflejar las entidades del mundo
real.
Los
lenguajes de implementacin OO son
ampliamente usados.
Sin embargo, los cambios de interfaz de objetos
pueden causar problemas y las entidades complejas
pueden ser difciles de representar como objetos.
12/05/16
487
Segmentacin orientada
a funcin
Las transformaciones funcionales procesan sus
entradas para producir salidas.
Pueda ser referida como un tubo y modelo del filtro
(como el shell (intrprete de comandos) de UNIX).
Las variantes de esta aproximacin son muy comunes.
Cuando las transformaciones son secuenciales, ste es
un modelo secuencial por lotes que se usa
extensivamente en sistemas de procesamiento de
datos.
No es muy conveniente para sistemas interactivos.
12/05/16
488
Sistema de procesamiento
de factura
Emitir
Emitirrecibos
recibos
Leer
Leerfacturas
facturas
emitidas
emitidas
Identificar
Identificar
pagos
pagos
Encontrar
Encontrarlala
deuda
deudade
de
pagos
pagos
Facturas
Facturas
12/05/16
Recibos
Recibos
Emitir
Emitir
recordatorio
recordatorio
de
depagos
pagos
Recordatorios
Recordatorios
Pagos
Pagos
489
Ventajas del modelo de

segmentacin
Soporta reuso de transformacin.
Organizacin intuitiva para la comunicacin de los
stakeholder.
Fcil para agregar nuevas transformaciones.
Relativamente simple para implementar como o
un sistema coexistente o secuencial.
Sin embargo, requiere un formato comn para
transferencia de datos a lo largo de la
segmentacin y difcil para apoyar eventos
basados en la interaccin.
12/05/16
490
Estilos de control
Se preocupan por el flujo del control entre los
subsistemas. Distinto del modelo de descomposicin
del sistema.
Control centralizado
Un subsistema tiene la responsabilidad global para
el control e inicios y salidas de otros subsistemas.
Control basado en eventos
Cada subsistema puede responder a eventos
externamente generados por otros subsistemas o
por el entorno del sistema.
12/05/16
491
Estilos de control
Se preocupan por el flujo del control entre los
subsistemas. Distinto del modelo de descomposicin
del sistema.
Un subsistema tiene la responsabilidad global para
el control e inicios y salidas de otros subsistemas.
Control basado en eventos
Cada subsistema puede responder a eventos
externamente generados por otros subsistemas o
por el entorno del sistema.
12/05/16
492
Un subsistema de control toma la responsabilidad por

manejar la ejecucin de otros subsistemas.
Modelo de retorno de llamada
Modelo de subrutina arriba-abajo donde el control se
inicia en la cima de una jerarqua de subrutina y se
mueve hacia abajo. Aplicable a los sistemas
secuenciales.
Modelo del gerente
Aplicable a sistemas concurrentes. Un componente del
sistema controla la parada, el inicio y la coordinacin de
otros procesos del sistema. Puede ser implementado en
los sistemas secuenciales como un estamento de caso.
12/05/16
493
Modelo de retorno de llamada

Programa
Programa
principal
principal
Rutina
Rutina11
Rutina
Rutina1.1
1.1
12/05/16
Rutina
Rutina33
Rutina
Rutina22
Rutina
Rutina1.2
1.2
Rutina
Rutina3.1
3.1
Rutina
Rutina1.2
1.2
494
Control de sistemas de
tiempo real
Procesos
Procesosde
de
sensor
sensor
Procesos
Procesosde
de
actuados
actuados
Controlador
Controlador
del
delsistema
sistema
Procesos
Procesosde
de
computacin
computacin
12/05/16
Interfaz
Interfazde
de
usuario
usuario
Manejador
Manejador
de
defallas
fallas
495
Sistemas manejados por eventos
Manejados por eventos externamente generados dnde la

oportunidad del evento es burlar el control de los
subsistemas que procesan el evento.
Dos modelos manejados por eventos principales
Modelos de emisin. Un evento es la emisin para todos
los subsistemas. Cualquier subsistema que puede
manipular el evento puede hacerlo as;
Modelos de manejo de interrupcin. Usado en sistemas
de tiempo real dnde las interrupciones son descubiertas
por un manejador de interrupcin y pasados a algn otro
componente por procesar.
Otros modelos manejados por eventos incluyen hojas de
clculo y sistemas de produccin.
12/05/16
496
Modelos de emisin
12/05/16
Eficaz integrando los subsistemas en diferentes

computadoras en una red.
Los subsistemas registran un inters en eventos
especficos. Cuando stos ocurren, el control es
transferido al subsistema que puede ocuparse del
evento.
La poltica del control no es incluida en el evento y
manejador del mensaje. Los subsistemas deciden
en los eventos de inters para ellos.
Sin embargo, los subsistemas no saben si o
cuando un evento ser manejado.
497
La emisin selectiva
Subsistema
Subsistema
11
Subsistema
Subsistema
22
Subsistema
Subsistema
33
Subsistema
Subsistema
44
Manejador
Manejador de
de evento
evento yy mensaje
mensaje
12/05/16
498
Sistemas de manejador
de eventos
Usado
en sistemas de tiempo real dnde la

rpida respuesta a un evento es esencial.
Hay tipos conocidos de interrupcin con un
manejador definido para cada tipo.
Cada tipo es asociado con una ubicacin de
memoria y un interruptor de hardware causa
transferencia a su manejador.
Permite contestacin rpida pero compleja
para programar y difcil de validar.
12/05/16
499
Control de manejador de
interrupcin
Interrupciones
Vector de
interrupcin
Manejador
Manejador
11
Manejador
Manejador
22
Manejador
Manejador
33
Proceso
Proceso
11
Proceso
Proceso
22
Proceso
Proceso
33
12/05/16
Manejador
Manejador
44
Proceso
Proceso
44
500
Los modelos arquitectnicos pueden ser especficos para

algn dominio de aplicacin.
Dos tipos de modelo de dominio especfico
Modelos genricos que son
abstracciones de varios
sistemas reales y qu encapsulan las caractersticas
principales de estos sistemas. Cubierto en el Captulo 13.
Modelos de referencia que son ms abstractos,
idealizados. Proporcionan unos medios de informacin
sobre esa clase de sistema y de comparacin de
diferentes arquitecturas.
Los modelos genricos son normalmente modelos de abajoarriba; los modelos de referencia son modelos de arribaabajo.
12/05/16
501
Los
modelos de la referencia se derivan de un

estudio del dominio de aplicacin en lugar de los
sistemas existentes.
Puede
usarse como una base para la
implementacin del sistema o para comparar
sistemas diferentes. Acta como una estndar
contra la cual pueden evaluarse los sistemas.
El modelo de OSI es un modelo de capas para
los sistemas de comunicacin.
12/05/16
502
Modelo de referencia OSI

7
6
Aplicacin
Aplicacin
Presentacin
Presentacin
Sesin
Sesin
Transporte
Transporte
Red
Red
Red
Enlace de datos
Fsico
Enlace de datos
Fsico
Enlace de datos
Fsico
Medios
Medios de
de comunicacin
comunicacin
12/05/16
503
Modelo de referencia a
caso
Servicios de almacn de datos

Almacenamiento y gestin de tems de datos.
Servicios de integracin de datos
Grupos de gerencia de entidades.
Servicios de gestin de tareas
Definicin y presentacin de modelos de proceso.
Servicios de mensajera
Comunicacin herramienta-herramienta y herramientaentorno.
Servicios de interfaz de usuario
Desarrollo de interfaz de usuario.
12/05/16
504
El modelo de referencia
ECMA
Data
repository
Servicio
de almacn services
de datos
Servicio
integracin
de datos
Data de
integ
ration services
Tool de
Ranura
slots
herramientas
Task de
management
services
Servicio
interfaz de usuario
Servicio
interfaz
usuario
User de
inter
face de
services
12/05/16
Servicio
de
Message
mensaje
services
505
Modelos arquitectnicos
Diferentes
modelos arquitectnicos
pueden ser producidos durante el
proceso de diseo.
Cada modelo presenta diferentes
perspectivas en la arquitectura
12/05/16
506
Atributos de la
arquitectura
12/05/16
Desempeo
Localiza operaciones para minimizar la comunicacin de
subsistemas.
Usa una arquitectura de capas con recursos crticos en las
capas internas.
Seguridad fsica
Aislar los componentes de seguridad fsica crticos.
Disponibilidad
Incluye componentes redundantes en la arquitectura.
Mantenibilidad
Usar componentes de grano fino y autocontenidos.
507
Puntos clave
Los
modelos de descomposicin modular

incluyen a los modelos de objetos y modelos de
segmentacin.
Los modelos de control incluyen modelos de
control centralizado y manejados por eventos.
Las arquitecturas de referencia pueden ser
usados para comunicarse con arquitecturas de
dominio especfico y para evaluar y comparar los
diseos arquitectnicos.
12/05/16
508
Captulo 12
Arquitecturas de
Sistemas
Distribuidos
12/05/16
509
Objetivos
Explicar las ventajas y desventajas de diferentes

arquitecturas de sistemas distribuidas
Discutir las arquitecturas cliente-servidor y de objetos
distribuidos
Describir agentes de demanda de objetos y los
principios que estn debajo de los estndares CORBA
Introducir las arquitecturas par-a-par y orientadas a
servicios como los nuevos modelos de computacin
distribuida.
12/05/16
510
Tpicos cubiertos
Arquitecturas
multiprocesador
Arquitecturas cliente-servidor
Arquitecturas distribuidas a objetos
Computacin inter-organizacional
12/05/16
511
Sistemas distribuidos
Virtualmente
todos los grandes sistemas basados

en computadora son ahora sistemas distribuidos.
El proceso de informacin es distribuido sobre
varias computadoras en lugar de estar confinada
a una sola mquina.
La ingeniera de software es, por consiguiente,
muy importante para sistemas de computacin
empresariales.
12/05/16
512
Tipos de sistemas
Sistemas personales que no son distribuidos y que

se disean para ejecutarlos en una computadora
personal o estacin de trabajo.
Sistemas empotrados que ser ejecutados en un solo

procesador o en un grupo integrado de
procesadores.
Sistemas distribuidos dnde el software del sistema

se ejecuta en un grupo dbilmente integrado de
procesadores cooperativos ligados por una red.
12/05/16
513
Caractersticas de
sistemas distribuidos
12/05/16
Recursos compartidos
Compartiendo recursos de hardware y software.
Franqueza
Uso de equipos y software de diferentes vendedores.
Concurrencia
Procesamiento concurrente para reforzar el desempeo.
Escalabilidad
Crecimiento de volumen procesado agregando nuevos
recursos.
Tolerancia de fallas
La habilidad para continuar en operacin, despus de
que ha ocurrido una falla.
514
Desventajas de sistemas
distribuidos
Complejidad
Tpicamente, los sistemas distribuidos son ms
complejos que los sistemas distribuidos.
Seguridad fsica
Ms susceptible al ataque externo.
Manejabilidad
Ms esfuerzo requerido para la gestin de sistemas.
impredecibilidad
Respuestas imprevisibles que dependen de la
organizacin del sistema y la carga de red.
12/05/16
515
Arquitecturas de
sistemas distribuidas
Arquitecturas
cliente-servidor
Servicios distribuidos que son llamados por los
clientes. Servidores que proporcionan servicios
que son tratados diferentemente por clientes
para usar servicios.
Arquitecturas de objetos distribuidos
Ninguna distincin entre clientes y servidores.
Cualquier objeto en el sistema puede
proporcionar y puede usar los servicios de otros
objetos.
12/05/16
516
Middleware
Software
que maneja y apoya los diferentes

componentes
de un sistema distribuido. En
esencia, se sienta en el medio del sistema.
El middleware normalmente est disponible en
stock, en lugar de software especialmente escrito.
Ejemplos
Monitores procesando transacciones;
Convertidores de datos;
Controladores de comunicacin.
12/05/16
517
Arquitecturas
multiprocesador
Modelo
de sistema distribuido ms simple.

Sistema compuesto de mltiples procesadores
que pueden (pero no necesariamente) ejecutar
en diferentes procesadores.
Modelo
arquitectnico de muchos grandes
La distribucin de procesos a procesadores
puede ser presolicitado o puede estar bajo el
control de un distribuidor.
12/05/16
518
Un sistema de control de
trfico multiprocesador
Sensores de
flujo de trfico y
cmaras
12/05/16
Procesador
de sensor
Procesador
de flujo de
trfico
Procesador
de control de
luz de trfico
Proceso
de control
de
proceso
Proceso
de
visualizar
Proceso
de control
de luz
Consolas de
operador
Luces de
trfico
519
Arquitectura cliente-servidor
La
aplicacin es el modelado como un conjunto

de servicios que son proporcionados por los
servidores y un conjunto de clientes que usan
estos servicios.
Los clientes conocen los servidores pero los
servidores no necesitan conocer a los clientes.
Los clientes y servidores son procesos lgicos.
La correspondencia de procesadores a procesos
no necesariamente es 1: 1.
12/05/16
520
Un sistema cliente-servidor
c3
c3
c2
c2
c1
c1
c4
c4
a1
a1
c12
c12
c11
c11
a4
a4
c10
c10
c5
c5
a2
a2
c6
c6
12/05/16
a3
a3
c7
c7
Proceso
servidor
c9
c9
c8
c8
Proceso
cliente
521
Computadoras en una red

C/S
c1
CC
CC
11
s1, s2
c2
CC
CC
22
c3, c4
CC
CC
33
s3, s4
Red
SC1
SC1
SC2
SC2
c5, c6, c7
c8, c9
CC
CC
44
12/05/16
CC
CC
55
c10, c11, c12
Computadora
servidor
Computadora
cliente
CC
CC
66
522
Arquitectura de
aplicacin de capas
Capa de presentacin
Tiene relacin con la presentacin de los resultados de un
cmputo a los usuarios del sistema y con las entradas de
usuario colectivas.
Capa de procesamiento de aplicacin
Tiene relacin con proporcionar a la aplicacin la
funcionalidad especfica, por ejemplo, en un sistema
bancario, funciones de banca como abrir cuenta, cerrar
cuenta, etc.
Capa de gestin de datos
Tiene relacin con manejar las bases de datos del sistema.
12/05/16
523
Capas de aplicacin
Capa de
de
Capa
presentacin
presentacin
Capa de
de procesamiento
procesamiento de
de
Capa
aplicacin
aplicacin
Capa de
de gestin
gestin de
de bases
bases de
de
Capa
datos
datos
12/05/16
524
Clientes delgados y gruesos

Modelo
En un modelo de cliente delgado, todo el proceso de

la aplicacin y la gestin de datos se lleva a cabo en
el servidor. El cliente es absolutamente responsable
para ejecutar el software de la presentacin.
Modelo
12/05/16
de cliente delgado
de cliente grueso
En este modelo, el servidor es slo es responsable de

la gestin de datos. El software en el cliente
implementa la lgica de la aplicacin y las
interacciones con el usuario del sistema.
525
Clientes delgados y gruesos

Modelo
de cliente
delgado
Cliente
Cliente
Presentacin
Servidor
Gestin de datos
Procesamiento de aplicacin
Presentacin
Modelo
de cliente
grueso
12/05/16
Servidor
Cliente
Cliente
Gestin de datos
526
Modelo de cliente delgado

Usado
cuando se emigran los sistemas

legados a las arquitecturas cliente -servidor.
El sistema legado acta como un servidor
con derecho propio con una interfaz
grfica implementada en un cliente.
Una desventaja mayor es que pone una carga
de proceso pesada en el servidor y en la red.
12/05/16
527
Modelo de cliente
grueso
Ms
procesamiento es delegado al cliente tal

como el procesamiento de aplicacin que es
localmente ejecutada .
Ms conveniente para nuevos sistemas C/S
dnde las capacidades del sistema del cliente
son conocidas de antemano.
Ms complejo que un modelo cliente delgado
sobre todo para la gestin. Las nuevas versiones
de la aplicacin tienen que ser instaladas en
todos los clientes.
12/05/16
528
Un sistema de CA clienteservidor
CA
CA
CA
CA
Servidor de cuenta
Monitor de
teleproceso
CA
CA
Base de
datos de
cuenta del
cliente
CA
CA
12/05/16
529
Arquitectura de 3 pisos
En una arquitectura del tres pisos, cada uno de
las capas de arquitectura de aplicacin puede
ejecutarse en un procesador separado.
Permite
el mejor desempeo que una
aproximacin a cliente delgado y es ms simple de
manejar que una aproximacin a cliente grueso.
Una arquitectura ms escalable - ya que al
aumento de demandas, pueden agregarse los
servidores extras.
12/05/16
530
Una arquitectura de 3 pisos C/S
Presentacin
Cliente
Cliente
Servidor
12/05/16
Servidor
Gestin de datos
531
Un sistema bancario por

Internet
Cliente
Cliente
Interaccin
HTTP
Cliente
Cliente
Servidor WEB
Cliente
Cliente
Consulta
SQL
Provisin de
servicio de
cuenta
Servidor de base
de datos
SQL
Base de datos
de cuenta del
cliente
Cliente
Cliente
12/05/16
532
Uso de arquitecturas C/S

Arquitectura
Aplicaciones
Arquitectura
de
dos pisos C/S con
clientes delgados
Las aplicaciones de sistema legado, dnde la separacin del

proceso de aplicacin y la gestin de datos es imprctica.
Las aplicaciones computacionalmente intensivas como los
compiladores con pequeo o ninguna gestin de datos.
Las aplicaciones de datos intensivos (hojeando y preguntando)
con pequeo o ningn procesamiento de aplicacin.
Arquitectura
de
dos pisos C/S con
clientes gruesos
Aplicaciones dnde el proceso de aplicacin es proporcionado

por el software disponible en stock (por ejemplo Microsoft
Excel) en el cliente.
Las aplicaciones dnde el proceso computationalmente
intensivo de datos (por ejemplo el visualizacin de datos) es
requerido.
Las aplicaciones con funcionalidad de usuario final
relativamente estable usadas en un ambiente con gestin del
sistema bien establecida.
Arquitectura
de
tres
pisos
o
multipisos C/S
Aplicaciones de gran escala con centenares o miles de clientes

Aplicaciones dnde los datos y la aplicacin son voltiles.
Aplicaciones dnde se integran datos de fuentes mltiples.
12/05/16
533
Arquitectura de objetos
distribuidos
No
hay ninguna distincin en arquitecturas de

objetos distribuidos entre clientes y servidores.
Cada entidad distribuible es un objeto que
proporciona los servicios a otros objetos y recibe
los servicios de otros objetos.
La comunicacin de objetos es a travs de un
sistema middleware llamado un agente de
demanda de objeto.
Sin
embargo, las arquitecturas de objeto
distribuidos son ms complejas de disear que los
sistemas C/S.
12/05/16
534
Arquitectura de objetos
distribuidos
o1
o2
S(o1)
S(o2)
o3
o4
S(o3)
S(o4)
Agentede
dedemanda
demandade
deobjeto
objeto
Agente
o5
o6
S(o5)
12/05/16
S(o6)
535
Ventajas de la arquitectura
de objetos distribuidos
Permite al diseador del sistema retardar las decisiones
sobre dnde y cmo deben proporcionarse los
servicios.
Es una arquitectura del sistema muy abierta que
permite agregar nuevos recursos a ella cuando sean
requeridos.
El sistema es flexible y escalable.
Es posible reconfigurar el sistema dinmicamente con
objetos que emigran a travs de la red cuando son
requeridos.
12/05/16
536
Usos de la arquitectura
de objetos distribuidos
Como
un modelo lgico que le permite

estructurar y organizar el sistema. En este
caso, se piensa sobre cmo proporcionar la
funcionalidad de la aplicacin solamente en
trminos de servicios y combinaciones de
servicios.
Como una aproximacin flexible a la aplicacin
de sistemas cliente-servidor. El modelo lgico
del sistema es un modelo cliente-servidor pero
clientes y servidores se comprenden como
objetos distribuidos que comunican a travs de
un framework de comunicacin comn.
12/05/16
537
Un sistema de minera de
datos
Bases de datos 1
Integrador 1
Bases de datos 2
Generador de
informes
Visualizador
Integrador 2
Bases de datos 3
12/05/16
Desplegador
538
Sistema de minera de
datos
El
modelo lgico del sistema no es ninguna

provisin de servicio dnde hay servicios de
gestin de datos distinguidos.
Permite que una variedad de bases de datos que
son accedidas, pueden ser incrementado sin
romper el sistema.
Permite que nuevos tipos de interrelaciones
pueden ser extrados agregando nuevos objetos
del integrador.
12/05/16
539
CORBA
12/05/16
CORBA (Common Object Request Broker Architecture) es

un estndar internacional para
para un Agente de
Demanda de Objeto - el middleware para manejar las
comunicaciones entre los objetos distribuidos.
El middleware para la computacin distribuida es
requerida en 2 niveles:
Al nivel de comunicacin lgico, el middleware permite
a objetos de computadoras diferentes intercambiar
datos e informacin de control;
Al nivel de componentes, el middleware proporciona
una base para el desarrollo de componentes
compatibles. Los estndares de componentes CORBA
han sido definidos.
540
Estructura de aplicacin
CORBA
Objetosde
de
Objetos
aplicacin
aplicacin
Dominiode
de
Dominio
recursos
recursos
Recursosde
de
Recursos
CORBAhorizontal
horizontal
CORBA
Agentede
dedemanda
demandade
deobjeto
objeto
Agente
ServiciosCORBA
CORBA
Servicios
12/05/16
541
Estructura de aplicacin
Objetos
de la aplicacin.
Objetos estndar, definidos por el OMG, para un
dominio especfico, por ejemplo: seguro.
Servicios de CORBA fundamental
tales como
directorios y gestin de seguridad contra delitos.
Horizontal (es decir cortando a travs de las
aplicaciones) los recursos tales como los
recursos de interfaz de usuario.
12/05/16
542
Estndares CORBA
Un modelo de objetos para objetos de la aplicacin

Un objeto CORBA es un encapsulamiento de estado
bien definido, la interfaz de un lenguaje neutral definido
en un IDL (Lenguaje de definicin de interfaz).
Un agente de demanda de objeto que maneja las
demandas para los servicios del objeto.
Un conjunto de servicios de objeto general de uso para
muchas aplicaciones distribuidas.
Un conjunto de componentes comunes construidos
encima de estos servicios.
12/05/16
543
Objetos CORBA
Los
objetos CORBA son comparables, en

principios, a objetos en C++ y Java.
Ellos DEBEN tener una definicin separada de la
interfaz que se expresa usando un lenguaje
comn (IDL) similar a C++.
Hay una correspondencia de este IDL a
los
lenguajes de programacin (C++, Java, etc.).
Por consiguiente, objetos escritos en diferentes
lenguajes pueden comunicarse entre s.
12/05/16
544
Agente de demanda de objeto

(ORB = Object request broker)
El
ORB se ocupa de comunicaciones del objeto.

Conoce todos los objetos en el sistema y sus
interfaces.
Usando un ORB, el objeto llamado enlaza un
taln de IDL que define la interfaz del objeto.
Llamando estos resultados del taln en las
llamadas al ORB que entonces llama al objeto
requerido a travs de un esqueleto de IDL
publicado que une la interfaz a la aplicacin de
servicio.
12/05/16
545
Comunicaciones de objeto
basados en ORB
o1
o2
S(o1)
S(o2)
Talnde
de
Taln
IDL
IDL
Esqueleto
Esqueleto
deIDL
IDL
de
Agentede
dedemanda
demanda de
de objeto
objeto
Agente
12/05/16
546
Comunicaciones Inter-ORB
Los ORB no son los programas normalmente, pero
son un conjunto de objetos en una biblioteca que se
une con una aplicacin cuando se desarrolla.
Los ORB manejan comunicaciones entre objetos
que se ejecutan en la mquina sana.
Varios ORBS pueden estar disponibles y cada
computadora en un sistema distribuido tendr su
propio ORB.
Las comunicaciones inter-ORB son usadas para
llamadas de objetos distribuidos.
12/05/16
547
Comunicaciones Inter-ORB
o1
S(o1)
Talnde
de
Taln
IDL
IDL
o3
o2
S(o3)
S(o2)
Talnde
de
Taln
IDL
IDL
Esqueleto
Esqueleto
deIDL
IDL
de
Agentede
dedemanda
demandade
de
Agente
objeto
objeto
o4
S(o4)
Esqueleto
Esqueleto
deIDL
IDL
de
Agentede
dedemanda
demandade
de
Agente
objeto
objeto
Red
12/05/16
548
Servicios CORBA
Nombrando
stos permiten a los objetos descubrir y referirse a

otros objetos en la red.
Servicios
12/05/16
de notificacin
stos permiten a los objetos notificar a otros objetos

que un evento ha ocurrido.
Servicios
y traficando servicios
de transaccin
Estos apoyan transacciones atmicas y reduccin en

fallas.
549
Computacin interorganizacional
Por
razones de seguridad contra delitos y de

interoperatividad, ms computacin distribuida se
ha implementado a nivel de empresa.
Estndares locales, gestin y aplicar procesos
operacionales.
Nuevos modelos de computacin distribuida han
sido diseados para apoyar computacin interorganizacional donde se localizan nodos
diferentes en organizaciones diferentes.
12/05/16
550
Arquitecturas par a par

Los sistemas para a par (p2p) son sistemas
descentralizados donde las computaciones pueden
ser llevadas a cabo por cualquier nodo de la red.
El sistema global se disea para tomar ventaja del
poder computacional y almacenamiento de un
nmero grande de computadoras conectadas a una
red.
La mayora de los sistemas p2p han sido sistemas
personales pero hay uso creciente de esta
tecnologa.
12/05/16
551
Modelos arquitectnicos p2p

La
arquitectura de red lgica

Arquitecturas descentralizadas;
Arquitecturas semicentralizadas.
Arquitectura de aplicacin
La organizacin genrica de componentes que
constituyen una aplicacin p2p.
Enfocar aqu las arquitecturas de red.
12/05/16
552
Arquitectura p2p descentralizada

n6
n6
n1
n1
n2
n2
n8
n8
n7
n7
n3
n3
n9
n9
n4
n4
12/05/16
n14
n14
n1
n1
33
n1
n1
22
n1
n1
00
n11
n11
n5
n5
553
Arquitectura p2p descentralizada

n6
n6
n1
n1
n2
n2
n8
n8
n7
n7
n3
n3
n9
n9
n4
n4
12/05/16
n14
n14
n1
n1
33
n1
n1
22
n1
n1
00
n11
n11
n5
n5
554
Arquitectura p2p semicentralizada

Servidorde
de
Servidor
descubrimiento
descubrimiento
n4
n4
n1
n1
n3
n3
n6
n6
n2
n2
12/05/16
n5
n5
555
Arquitectura orientada al
servicio
Basada
alrededor de la nocin de servicio

provisto externamente (servicios de la Web).
Un servicio de la Web es una aproximacin
estndar para hacer un componente reusable
disponible y accesible a travs de la Web.
Un servicio de limado de impuesto podra
proporcionar soporte a los usuarios para llenar
sus formularios de impuesto y someter stos a
las autoridades de impuestos.
12/05/16
556
Un servicio genrico
Un
acto o desempeo ofrecidos por una fiesta

para otro. Aunque el proceso puede atarse a
un producto fsico, la actuacin es
esencialmente intangible y normalmente no
resulta en propiedad de cualquiera de los
factores de produccin.
La provisin de servicio es por consiguiente
independiente de la aplicacin que usa el
servicio.
12/05/16
557
Servicios de la Web
Registro
Registro
de
de
servicio
servicio
Publicar
Buscar
Demandado
Demandado
de
rrde
servicio
servicio
12/05/16
Enlazar
Proveedor
Proveedor
de
de
servicios
servicios
558
Servicios y objetos distribuidos

Independencia
del proveedor.
Publicidad pblica de disponibilidad de servicio.
Potencialmente, ligadura de servicio de tiempo
de ejecucin.
Construccin oportuna de nuevos servicios a
travs de la composicin.
Pago por el uso de servicios.
Pequeas, aplicaciones ms compactas.
Aplicaciones reactivas y adaptables.
12/05/16
559
Estndares de servicios
Los servicios estn basado en estndares convenidos basados

en XML para que puede ser proporcionados en cualquier
plataforma y pueden escribirse en cualquier lenguaje de
programacin.
Estndares cales
SOAP - Simple Object Access Protocol = Protocolo de
acceso a objeto simple;
WSDL - Web Services Description Language = Lenguaje de
descripcin de servicios de la Web;
UDDI - Universal Description, Discovery and Integration =
Descripcin universal, Descubrimiento e integracin.
12/05/16
560
Escenario de servicios
Un sistema de informacin
en automvil
proporciona informacin a chferes sobre el tiempo,
las condiciones de trfico del camino, informacin
local, etc. Esto se une a la radio del automvil para
que se entregue la informacin como una seal en
un canal especfico de la radio.
El automvil est provisto con un receptor GPS para
descubrir su posicin y, basado en esa posicin, el
sistema accede un rango de servicios de
informacin. La informacin puede ser entregada en
el lenguaje especificado del chofer.
12/05/16
561
Sistema automotor
Informacin
Informacin
de tiempo
de tiempo
Informacin de trfico del camino
Informacin
Informacin
de recursos
de recursos
Localizado
Localizado
r de
r de
camino
camino
Coordenadas
GPS
Coordenadas
GPS
Coordenadas GPS
Servicio de informacin mvil
Traductor
Traductor
Ensamblar informacin
Informacin de
lenguaje
Flujo de
informacin
Receptor
Recibe
informacin de
servicios
Radio
Traduce flujos
de informacin
digital a seal
de radio
12/05/16
Informaci
Informaci
n de
ntrfico
de
trfico
Descubrimiento de servicio
Halla servicios disponibles
Comando de
coordenadas GPS
Transmisor
Enva posicin e
informacin
requerida para
servicios
Interfaz de
usuario
Recibe
demanda para
usuario
Localizador
Descubre
posicin del
carro
562
Puntos clave
Los sistemas distribuidos soportan recursos
compartidos,
franqueza,
concurrencia,
escalabilidad, tolerancia de fallas y transparencia.
Las arquitecturas cliente servidor involucran
servicios que son entregados por los servidores a
programas que operan en los clientes.
El software de interfaz de usuario siempre se
ejecuta en el cliente y la gestin de datos en el
servidor. La funcionalidad de la aplicacin puede
estar en el cliente o en el servidor.
En la arquitectura de objetos distribuidos no hay
diferencia entre clientes y servidores.
12/05/16
563
Puntos clave
Los sistemas de objetos distribuidos requieren de
middleware para manejar las comunicaciones de
objetos y para agregar o quitar objetos del sistema.
Los estndares CORBA son un conjunto de
estndares middleware que soportan arquitecturas
de objetos distribuidos.
La arquitecturas par a par son arquitecturas
descentralizadas donde no hay distincin entre
clientes y servidores.
Los sistemas orientados a servicios son creados por
enlace de servicios proporcionados por diferentes
proveedores de servicios.
12/05/16
564
Captulo 13
Arquitecturas de
aplicacin
12/05/16
565
Objetivos
Explicar
la organizacin de dos modelos

fundamentales de sistemas comerciales -proceso
por lotes y sistemas de procesamiento de
transaccin
Describir la arquitectura abstracta de sistemas de
gestin de recurso
Explicar
cmo los editores genricos son
sistemas de procesamiento de eventos
Describir
la estructura de sistemas de
procesamiento de lenguajes
12/05/16
566
Tpicos cubiertos
Sistemas
de procesamiento de datos
Sistemas de procesamiento de
transaccin
Sistemas de procesamiento de eventos
Sistemas de procesamiento de
lenguaje
12/05/16
567
Arquitecturas de
aplicacin genrica
Los
sistemas de la aplicacin son diseados para

satisfacer una necesidad organizacional.
Cuando los negocios tienen mucho en comn,
sus sistemas de aplicacin tambin tienden a
tener una arquitectura comn, que refleja los
requerimientos de la aplicacin.
Una arquitectura genrica es configurada y
adaptada para crear un sistema que rene los
requerimientos especficos.
12/05/16
568
Uso de arquitecturas de
aplicacin
Como
un punto de partida para el diseo

arquitectnico
Como una lista de control del diseo.
Como una manera de organizar el trabajo del
equipo de desarrollo.
Como una manera de organizar el trabajo del
Como un vocabulario para hablar sobre los tipos
de aplicacin.
12/05/16
569
Tipos de aplicacin
12/05/16
Aplicaciones de procesamiento de datos

Aplicaciones de manejo de datos que procesan los datos en lotes
sin la intervencin explcita del usuario durante el proceso.
Aplicaciones de procesamiento de transaccin
Aplicaciones de datos centrados que procesan pedidos de usuario
y actualizan la informacin en una base de datos del sistema.
Sistemas de procesamiento de evento
Aplicaciones dnde las acciones del sistema dependen de
interpretar los eventos del ambiente del sistema.
Sistemas de procesamiento de lenguaje
Aplicaciones dnde las intenciones de los usuarios son
especificadas
en un lenguaje formal que es procesado e
interpretado por el sistema.
570
Ejemplo de tipos de
aplicacin
Sistemas de procesamiento de datos

Sistema de cargo de cuenta;
Sistemas de nmina.
Sistemas de procesamiento de transaccin
Sistemas de comercio electrnico;
Sistemas de reservacin.
Sistemas de procesamiento de evento
Procesadores de palabra;
Sistemas de tiempo real.
Sistemas de procesamiento de lenguaje
Compiladores;
Intrpretes de comandos.
12/05/16
571
Sistemas de
procesamiento de datos
Sistemas que son centrados de datos donde las bases

de datos usadas son normalmente ordenes de magnitud
ms grande que el propio software.
Los datos tienen entrada y salida por lotes
Entrada: Un conjunto de nmeros de cliente y
lecturas asociadas de un medida de electricidad;
Salida: Un conjunto correspondiente de factura, uno
por cada nmero de cliente.
Sistemas de procesamiento de datos que normalmente
tienen una estructura de entrada-proceso-salida.
12/05/16
572
Modelo entrada-procesosalida
Sistema
Sistema
Entrada
Entrada
Proceso
Proceso
Salida
Salida
Impresora
Base de
de datos
datos
Base
12/05/16
573
Entrada-proceso-salida
El componente de entrada lee los datos de un
archivo o base de datos, chequea su validez y
hace cola de los datos vlidos por procesar.
El componente de proceso toma una transaccin
de la cola (entrada), realiza los cmputos y crea un
nuevo registro con los resultados del cmputo.
El componente de salida lee estos archivos, los
estructura de acuerdo con un formato y los escribe
para la base de datos o los enva a una impresora.
12/05/16
574
Diagramas de flujo de datos

Muestra
cmo los datos son procesados y

como se mueven a travs de un sistema.
Las
transformaciones se representan
como rectngulos de bordes redondo, los
flujos de datos como flechas entre ellos y
el los archivos de datos como rectngulos.
12/05/16
575
DFD de pago de salario

Registros de
Registros
de
empleados
empleados
Tasas de pago
Tasas
de pago
mensual
mensual
Leer registro
Leer
registro
de empleado
de empleado
Registro de
empleado
descifrado
Registro de
empleado vlido
Validar datos
Validar
datos
de empleado
de empleado
Leer datos de
Leer
datos
de
pago
mensual
pago mensual
calcular
calcular
salario
salario
Deduccin de
impuesto +
Nmero SS +
Oficina de
impuesto
Deduccin de
impuesto +
Nmero SS
Datos de empleado +
deducciones
12/05/16
Escribir datos
Escribir
datos
de pensin
de pensin
Imprimir tira
Imprimir
tira
de pago
de pago
Pago de red
+Informacin de
cuenta bancaria
Informacin de
pago
Tabla de
Tabla
de
impuestos
impuestos
Datos de pago
Datos
de pago
mensual
mensual
Escribir
Escribir
transacciones
transacciones
de impuesto
de impuesto
Deduccin de
seguridad social +
Nmero SS
Transacciones
Transacciones
de impuesto
de impuesto
Datos de
Datos
de
pensin
pensin
IMPRESORA
Escribir
Escribir de
transaccin
transaccin
banco de
banco
Transacciones
Transacciones
de bancos
de bancos
Escribir datos
Escribir
datos
de seguridad
de seguridad
social
social
Datos de
Datos desocial
seguridad
seguridad social
576
Sistemas de procesamiento
de transacciones
Procesa demandas de usuario para informacin de una

base de datos o pide actualizar la base de datos.
Desde una perspectiva del usuario una transaccin es:
Una
secuencia coherente de operaciones que
satisfacen una meta;
Por ejemplo hallar el tiempo de vuelo de Londres a
Pars.
Los usuarios hacen demandas asncronas para servicios
que son entonces procesados por un gerente de
transaccin.
12/05/16
577
Procesamiento de transaccin
Procesamiento
Procesamiento
E/S
E/S
12/05/16
Aplicacin
Aplicacin
lgica
lgica
Gerentede
de
Gerente
transaccin
transaccin
Basede
de
Base
datos
datos
578
Organizacin de un
sistema CA
Entrada
ObtenerId.
Id.de
de
Obtener
cuentade
decliente
cliente
cuenta
Validar
Validar
Consultar
Consultar
cuenta
cuenta
CA
Salida
Imprimir
Imprimir
detalles
detalles
Devolver
Devolver
tarjeta
tarjeta
tarjeta
tarjeta
Seleccionar
Seleccionar
servicio
servicio
12/05/16
Proceso
Actualizar
Actualizar
cuenta
cuenta
Base de datos
Expenderdinero
dineroen
en
Expender
efectivo
efectivo
CA
579
Middleware para procesamiento

de transacciones
Middleware
para gestin de transacciones o

monitores de teleprocesamiento que supervisan
las comunicaciones con diferentes tipos de
servidores (por ejemplo CAs y terminales de
contador), datos en serie y lo enva para
procesarlos.
El procesamiento de consultas tiene lugar en la
base de datos del sistema y se envan los
resultados atrs a travs del gerente de
transaccin al terminal del usuario.
12/05/16
580
Gestin de transacciones
Consultas y
actualizaciones
de cuenta
Monitorde
de
Monitor
teleprocesamiento
teleprocesamiento
Transaccion
es en serie
Basede
dedatos
datosde
de
Base
cuentas
cuentas
CAs y
terminales
12/05/16
581
Arquitectura de sistemas
de informacin
Los
sistemas de informacin tienen una

arquitectura genrica que puede organizarse
como una arquitectura en capas.
Las capas incluyen:
La interfaz de usuario
Comunicaciones de usuario
Recuperacin de informacin
Base de datos del sistema
12/05/16
582
Estructura de sistema de
informacin
Interfazde
deusuario
usuario
Interfaz
Comunicacionesde
deusuario
usuario
Comunicaciones
Recuperacinde
deinformacin
informacinyymodificacin
modificacin
Recuperacin
Gestinde
detransacciones
transacciones
Gestin
Basede
dedatos
datos
Base
12/05/16
583
Arquitectura LIBSYS
El
sistema de biblioteca LIBSYS es un ejemplo de

un sistema de informacin..
Capa de comunicaciones de usuario:
Componente de identificador de LIBSYS;
Formulario y gestin de consulta;
Gerente de impresora;
Capa de recuperacin de informacin
Bsqueda distribuida;
Documenta recuperacin;
Gerente de derechos;
Contabilidad.
12/05/16
584
Organizacin de LIBSYS
Interfazde
denavegador
navegadorde
dela
laWeb
Web
Interfaz
Formulario y
gerente de
consultas
Identificacin
LIBSYS
Bsqueda
distribuida
Documento de
recuperacin
Gerente de
impresin
Gerente de
derechos
Contabilidad
ndicede
delibrera
librera
ndice
BD1
BD1
12/05/16
BD2
BD2
BD3
BD3
BD4
BD4
BDn
BDn
585
Sistema de asignacin de
recursos
Sistemas que manejan una cantidad fija de algn

recurso (boletos del juego del ftbol, libros en una
librera, etc.) y asigna estos a los usuarios.
Ejemplos de sistemas de asignacin de recursos:
Sistemas de cronograma dnde el recurso a
asignarse es un periodo de tiempo;
Sistemas de biblioteca dnde el recurso a manejarse
son libros y otros artculos para el prstamo;
Sistemas de control de trfico areo dnde el recurso
a manejarse es el espacio areo.
12/05/16
586
Arquitectura de
asignacin de recursos
Sistema de asignacin de recursos son tambin sistemas de
capas que incluyen:
Una base de datos de recursos;
Un conjunto de reglas que describen cmo sern
asignados los recursos;
Un gerente de recursos;
Un asignador de recursos;
Autentificacin de usuario;
Gestin de consultas;
Componente de entrega de recursos;
Interfaz de usuario.
12/05/16
587
Asignacin de recursos
por capas
Interfazde
de usuario
usuario
Interfaz
Identificacin
De usuario
Gestin de
recursos
Entrega de
recursos
Control de poltica
de recursos
Gerente de
consultas
Asignacin de
recursos
Gestinde
detransacciones
transacciones
Gestin
Basede
dedatos
datosde
derecursos
recursos
Base
12/05/16
588
Implementacin del
sistema de capas
Cada capa puede implementarse como un
componente a larga escala grande que se ejecuta en
un servidor separado. ste es el modelo
arquitectnico ms comnmente usado para los
sistemas basados en la Web.
En una sola mquina, las capas medias son
implementadas como un programa separado que se
comunica con la base de datos a travs de su API.
Los componentes de grano fino dentro de las capas
pueden ser implementadas como servicios de la Web.
12/05/16
589
E-Comercio
Los
sistemas E-comercio son sistemas de gestin

de recursos basados en Internet que acepta
ordenes electrnicas para productos o servicios.
Ellos
son
normalmente
organizados
una
arquitectura multi-piso con capas de aplicacin
asociadas con cada piso.
Navegador
Navegador
Web
Web
12/05/16
Servidor
Servidor
Web
Web
Servidorde
de
Servidor
aplicacin
aplicacin
Servidorde
de
Servidor
basede
dedatos
datos
base
590
Sistemas de
procesamiento de eventos
Estos
sistemas responden a los eventos en el

entorno del sistema.
Su caracterstica clave es que el evento
cronometrando es imprevisible tal que la
arquitectura tiene que ser organizada para
manejar esto.
Muchos sistemas comunes como los procesador
de texto, juegos, etc. son sistemas de
procesamiento de eventos.
12/05/16
591
Sistemas de edicin
Sistemas de tiempo real (Captulo 15) y sistemas de
edicin son los tipos ms comunes de sistemas de
procesamiento de eventos.
Caractersticas de sistemas de edicin:
Sistemas de usuario simple;
Deba proporcionar la retroalimentacin rpida a las
acciones del usuario;
Organizado alrededor de grandes transacciones tal
que pueden incluir los recursos de recuperacin.
12/05/16
592
Componentes de
sistemas de edicin
Los sistemas de edicin son naturalmente orientados a

objetos:
Pantalla monitorea memoria de pantalla y detecta
eventos;
Evento
reconoce eventos y los pasa por
procesamiento;
Comando ejecuta comandos de usuario;
Datos de editor - maneja el editor de estructura de
datos;
Datos auxiliares maneja otros datos como estilos y
preferencias;
Sistemas de archivo maneja archivos de E/S;
Visualizacin actualiza el despliegue por pantalla.
12/05/16
593
de edicin
Sistema de
archivo
Grabar
Abrir
Datos
auxiliares
Comandos
auxiliares
Datos de
editor
Comandos de
edicin
Comandos
Visualizacin
Interpretes
Actualizar
Eventos
Procesar
Pantalla
Refrescar
12/05/16
594
Sistemas de
procesamiento de lenguaje
Acepta un lenguaje natural o artificial como entrada y

genera alguna otra representacin de ese lenguaje.
Puede incluir un intrprete para actuar en las
instrucciones en el lenguaje que est procesndose.
Usado en situaciones dnde la manera ms fcil de
resolver un problema es describir un algoritmo o
describir los datos del sistema
Las herramientas meta-casos procesan descripciones
de herramientas, reglas de mtodos, etc., y genera las
herramientas.
12/05/16
595
Un sistema de
Instrucciones
Instrucciones
Traductor
Chequea sintaxis
Chequea semntica
Genera
Instruccionesm/c
m/c
Instrucciones
abstracto
abstracto
Intrprete
Datos
Datos
12/05/16
Sacar
Extraer
Resultados
Resultados
596
Componentes de
Analizador
lxico
Tabla de smbolos
Analizador de sintaxis
rbol de sintaxis
Analizador de sintaxis
Generador de cdigo
12/05/16
597
Compilador de modelo de
flujo de datos
Tabla de smbolos
rbol de sintaxis
Anlisis
Anlisis
lxico
lxico
12/05/16
Anlisis
Anlisis
sintctico
sintctico
Anlisis
Anlisis
semntico
semntico
Generadorde
de
Generador
cdigo
cdigo
598
Modelo de repositorio de
un compilador
Analizador
Analizador
lxico
lxico
Analizador
Analizador
sintctico
sintctico
Analizador
Analizador
semntico
semntico
Impresora
Impresora
bonita
bonita
rbol de
de
rbol
sintaxis
sintaxis
abstracto
abstracto
Definicinde
de
Definicin
gramtica
gramtica
Optimizador
Optimizador
Editor
Editor
Tablade
de
Tabla
smbolos
smbolos
Definicinde
de
Definicin
salida
salida
Generadorde
de
Generador
cdigo
cdigo
Depsito
12/05/16
599
Puntos clave
Modelos
genricos
de
arquitecturas
de
comportamiento nos ayudan a entender y comparar
las aplicaciones.
Importantes clases de aplicacin son sistemas de
procesamiento de datos, sistemas de procesamiento
de transaccin, sistemas de procesamiento de
evento, y sistemas de procesamiento de lenguaje
Los sistemas de procesamiento de datos operan en
el modo del lotes y tienen una estructura del
entrada-proceso-salida.
12/05/16
600
Puntos clave
Los sistemas de procesamiento de transaccin
permite informacin en una base de datos a ser
accedida remotamente y modificada por mltiples
usuarios.
Los sistemas de procesamiento incluye editores y
En un editor, eventos de interfaz de usuario son
detectadas y un estructura de datos en almacn
es modificada.
Los sistemas de procesamiento de lenguaje
traducen textos desde un lenguaje a otro y puede
interpretar las instrucciones especficas.
12/05/16
601
Captulo 14
Diseo orientado
a objetos
12/05/16
602
Objetivos
Explicar como un diseo de software puede ser
representado como un conjunto de objetos interactivos
que manejan su propio estado y operaciones
Describir las actividades en el proceso de diseo
orientado a objetos
Introducir varios modelos que pueden ser usados para
describir el diseo orientado a objetos
Mostrar como el UML puede ser usado para
representar esos modelos
12/05/16
603
Tpicos cubiertos
Objetos
y clases de objetos
Un proceso de diseo orientado a
objetos
Evolucin del diseo
12/05/16
604
Desarrollo orientado a
objetos
El
anlisis orientado a objetos, el diseo orientado

a objetos y la programacin estn relacionadas
pero son distintas.
El AOO se preocupa por desarrollar un modelo de
objetos del dominio de la aplicacin.
El DOO se preocupa por desarrollar un modelo de
sistema orientado a objetos para implementar los
requerimientos.
La POO se preocupa por la realizacin de un DOO
usando un lenguaje de programacin OO tal como
Java o C++.
12/05/16
605
Caractersticas del DOO

Los objetos son abstracciones del mundo real o
entidades del sistema y se manejan as mismos.
Los objetos son independientes y encapsulan
estado y representacin de informacin.
La funcionalidad del sistema es expresada en
trminos de servicios de objetos.
Las reas de datos compartidos son eliminadas.
Los objetos se comunican por el pase de mensajes.
Los objetos pueden ser distribuidos y pueden ser
ejecutados secuencialmente o en paralelo.
12/05/16
606
Objetos interactuando
o1:C1
o3:C3
o4:C4
Estado de o1
Estado de o3
Estado de o4
Operaciones3()
Operaciones4()
Operaciones1()
12/05/16
o2:C3
o6:C1
o5:C5
Estado de o2
Estado de o6
Estado de o5
Operaciones3()
Operaciones1()
Operaciones5()
607
Ventajas del DOO

Fcil
mantenimiento. Los objetos pueden

ser
entendidos
como
entidades
autosuficientes.
Los
objetos son componentes potencialmente

reusables.
Para algunos sistemas, puede haber una
correspondencia obvia de las entidades del
mundo reales, con los objetos del sistema.
12/05/16
608
Objetos y clases de
objetos
Los
objetos son entidades en un sistema de

software que representan casos de mundo real y
entidades del sistema.
Las clases de objeto son plantillas para los
objetos. Ellos pueden usarse para crear los
objetos.
Las clases de objeto pueden heredar atributos y
servicios de otras clases de objeto.
12/05/16
609
Objetos y clases de objetos

Un objeto es una entidad que tiene un estado y un conjunto
definido de operaciones que operan en ese estado. El estado
est representado como un conjunto de atributos del objeto.
Las operaciones asociadas con el objeto proporcionan los
servicios a otros objetos (clientes) qu demandan estos
servicios cuando algn cmputo es requerido.
Los objetos son creados de acuerdo a alguna definicin de
clase de objeto. Una definicin de clase de objeto sirve como
una plantilla para los objetos. Incluye declaraciones de todos
los atributos y servicios que deben asociarse con un objeto
de esa clase.
12/05/16
610
El Lenguaje de
Modelamiento Unificado
Varias
notaciones diferentes parar describir los

diseos orientados a objetos han sido propuestos
en los 1980 y 1990.
El Lenguaje de Modelamiento Unificado es una
integracin de esas notaciones.
Describe las notaciones para una variedad de
diferentes modelos que pueden producirse
durante el anlisis y diseo OO.
Actualmente es un estndar de facto para el
modelado OO.
12/05/16
611
Clase de objeto Empleado

(UML)
Empleado
Nombre : String
Direccin : String
FechaNacimiento : Date
NumEmpleado : Integer
NumSeguroSocial : String
Departamento : String
Cargo : String
Salario : Currency
Estado : String
CodigoImpuesto : Integer
Alta()
Baja()
Retirar()
CambiarDetalle()
12/05/16
612
Comunicacin de objetos
Conceptualmente, los objetos se comunican por el paso de

mensajes.
Mensajes
El nombre del servicio solicitado por llamamiento del objeto;
Copias de la informacin requerida para ejecutar el servicio
y el nombre de un titular para el resultado del servicio.
En la prctica, los mensajes son a menudo implementados
por llamamiento a procedimientos
Nombre = nombre del procedimiento;
Informacin = lista de parmetros.
12/05/16
613
Ejemplos de mensaje
// Llamada a un mtodo asociado con un
objeto //buffer (memoria intermediaria) que
devuelve un prximo valor en el //buffer
v = circularBuffer.Get () ;
// Llamada a un mtodo asociado con un
objeto // termostato que pone la temperatura a
ser
// mantenida
thermostat.setTemp (20) ;
12/05/16
614
Generalizacin y herencia
Los objetos son miembros de clases que definen tipos

de atributo y operaciones.
Las clases pueden ser colocadas en una jerarqua de
clases donde una clase (una super-clase) es una
generalizacin de una o ms clases (sub-clases).
Una sub-clase hereda los atributos y operaciones desde
una super clase y puede agregar nuevos mtodos o
atributos a si mismo.
La generalizacin in el UML es implementado como
herencia en los lenguajes de programacin OO.
12/05/16
615
Una herencia de generalizacin

Empleado
Programador
Gerente
Proyectos
LenguajeProg
PresupuestosControlados
FechaFijada
12/05/16
GerenteProyecto
GerenteDepto
Proyectos
Depto
GerenteEstratgico
Responsabilidades
616
Ventajas de herencia
Es
un mecanismo de abstraccin que

puede usarse para clasificar las entidades.
Es un mecanismo de reuso en el nivel de
diseo y programacin.
El grfico de herencia es una fuente de
conocimiento
organizacional sobre los
dominios y sistemas.
12/05/16
617
Problemas con la herencia

Las
clases del objeto no son autocontenidas.

Ellas no pueden ser entendidas sin la referencia
a sus super-clases.
Los diseadores tienen la tendencia a reusar los
grficos de herencia creados durante el anlisis.
Puede llevar a la ineficacia significativa.
Los grficos de herencia del anlisis, diseo e
implementacin tienen diferentes funciones y
sern separadamente mantenidas.
12/05/16
618
Asociaciones UML
Los objetos y clases de objetos participan en
interrelaciones con otros objetos y clases de
objetos.
En el UML, una interrelacin generalizada es
indicada por una asociacin.
Las asociaciones pueden ser notadas con
informacin que describe la asociacin.
Las asociaciones son generales pero pueden
indicar que un atributo de un objeto es un objeto
asociado o que un mtodo cuenta en un objeto
asociado.
12/05/16
619
Un modelo de
asociacin
Es_miembro_de
Empleado
Departamento
+Es_dirigido_por
+Dirige
12/05/16
Gerente
620
Objetos concurrentes
La
naturaleza de objetos como las

entidades autnomas los hace convenientes
para la implementacin concurrente.
El modelo de pase de mensajes de
comunicacin de objeto puede ser
directamente implementada si los objetos
estn corriendo en procesadores separados
en un sistema distribuido.
12/05/16
621
Servidores y objetos activos

Servidores
El objeto es implementado como un proceso paralelo
(servidor)
con puntos de entrada correspondientes para operaciones de
objeto. Si ninguna llamada se hace a l, el objeto se
suspende y espera por las demandas extensas por el servicio.
Objetos activos
Los objetos son implementadas como procesos paralelos y el
estado interno del objeto puede ser cambiado por el propio
objeto y no simplemente por llamadas externas.
12/05/16
622
Objeto repetidor activo

Los
objetos activos puede tener sus atributos

modificados por operaciones pero ellos tambin
pueden ser actualizados autnomamente usando
operaciones internas.
Un objeto repetidor transmite la posicin de un
avin. La posicin puede ser actualizada usando
el sistema de posesionamiento de satlite. El
objeto
actualiza
peridicamente
por
la
triangulacin de los satlites.
12/05/16
623
Un objeto repetidor activo

class Transponder extends Thread {
Position currentPosition ;
Coords c1, c2 ;
Satellite sat1, sat2 ;
Navigator theNavigator ;
public Position givePosition ()
{
return currentPosition ;
}
public void run ()
{
while (true)
{
c1 = sat1.position () ;
c2 = sat2.position () ;
currentPosition = theNavigator.compute (c1, c2) ;
}
} //Transponder
12/05/16
624
Hilos Java
Los
hilos (threads) en Java son un

constructores simples para implementar
objetos concurrentes.
Los hilos pueden incluir a un mtodo llamado
run() y este es iniciado por un sistema Java
run-time (ejecucin).
Los objetos activos tpicamente incluyen un
bucle infinito para que ellos siempre estn
llevando a cabo el cmputo.
12/05/16
625
Proceso de diseo orientado

a objeto
Los
procesos de diseo estructurado involucran el

desarrollo de una variedad de diferentes modelos
de sistemas.
Ellos requieren mucho esfuerzo para el desarrollo y
mantenimiento de esos modelos y, para sistemas
pequeos, esto puede ser no rentable.
Sin embargo para grandes sistemas desarrollados
por diferentes grupos disear modelos es un
mecanismo esencial de comunicacin.
12/05/16
626
Fases del proceso
12/05/16
Los rasgos salientes codifican las actividades a

menos que atndose para cualquier proceso
propietario como el RUP.
Define el contexto y modos de uso del sistema;
Diseo de la arquitectura del sistema;
Identificar los principales objetos del sistema;
Desarrollar modelos de diseo;
Especificar interfaces de objetos.
627
Descripcin del sistema

de tiempo
Un sistema de correspondencia del tiempo es requerido para generar
los mapas de tiempo en una base regular que usa los datos
coleccionados solo desde estaciones de tiempo remotas y otras
fuentes de los datos como los observadores de tiempo, globos y
satlites. Las estaciones de tiempo transmiten sus datos a la
computadora del rea en respuesta a una demanda de esa mquina.
El sistema de computadora de rea valida los datos reunidos y los
integra con los datos de las diferentes fuentes . Los datos integrados
se archivan y, usando los datos de este archivo y una base de datos
del mapa digitalizado, un conjunto de mapas de tiempo locales es
creado. Pueden imprimirse los mapas para la distribucin en una
impresora de propsito especial o pueden desplegarse en varios
formatos diferentes.
12/05/16
628
Contexto del sistema y

modelos de uso
Desarrollar una comprensin de la interrelaciones entre el

software el software a ser diseado y su entorno externo
Contexto del sistema
Un modelo esttico que describe otros sistemas en el
entorno. Usa un modelo del subsistema para mostrar otros
sistemas. La diapositiva siguiente muestra el sistema
alrededor del sistema de estacin de tiempo.
Modelo de uso del sistema
Un modelo dinmico que describe como el sistema
interacta con el entorno. Usa casos de uso para mostrar
interacciones.
12/05/16
629
Arquitectura de capas
<<subsystem>>
Despliegue de
datos
<<subsystem>>
Archivamiento
de datos
<<subsystem>>
Procesamiento
de datos
<<subsystem>>
Recoleccin de
datos
12/05/16
La capa de despliegue de datos donde los objetos se

preocupan con la preparacin y presentacin de datos
en un formato legible por humanos.
La capa de archivamiento de datos donde los objetos

se preocupan por el almacenamiento de datos para
futuros procesamientos.
La capa de procesamiento donde los objetos se

preocupan con la recisin e integracin de los datos
recolectados.
La capa de recoleccin de datos donde los objetos se

preocupan con la adquisicin de datos desde fuentes
remotas.
630
Subsistemas en el sistema
correspondencia en el tiempo
<<subsystem >>
<<subsystem >>
Despliegue de datos
Recoleccin de datos
Observador
Satlite
Interfaz de
usuario
Despliegue
de mapa
Comandos
Estacin de
tiempo
Globo
Mapa
Impresora de
mapa
<<subsystem >>
Archivamiento de datos
<<subsystem >>
Procesamiento de datos
Revisin de
datos
Almacenamiento
de datos
Integracin
de datos
Almacen de
mapas
12/05/16
Almacen de
datos
631
Modelos de casos de uso

Los
modelos de casos de uso son

usados para representar cada
interaccin con el sistema.
Un modelo de caos de uso muestran
los hechos del sistema como elipses
y las entidades como una figura de
palo.
12/05/16
632
Casos de uso para la

estacin de tiempo
Iniciar
Cerrar
Informe
Calibracin
Pruebas
12/05/16
633
Descripcin de un casos
de uso
Sistema
Estacin de tiempo.
Casos de uso
Informe.
Actores
Sistema de coleccin de datos de tiempo. Estacin de tiempo.
Datos
La estacin de tiempo enva un resumen de los datos de tiempo que han

sido reunidos de los instrumentos en el periodo de la recoleccin para el
sistema de recoleccin de datos del tiempo. Los datos enviados son el
mnimo mximo y promedio de temperaturas de tierra y aire, el mximo,
mnimo y promedio de presiones atmosfricas, el mximo, el mnimo y el
promedio de aceleracin del viento, la lluvia total y la direccin del viento
como muestras de intervalos de 5 minutos.
Estmulos
El sistema de recoleccin de datos del tiempo datos establece un mdem

de enlace con la estacin del tiempo y transmisin de demandas de los
datos.
Respuestas
Los datos resumidos se envan al sistema de recoleccin de datos.
Comentarios
Las estaciones de tiempo normalmente interrogadas para informar una

vez por hora pero esta frecuencia puede diferir de una estacin a otra y
puede modificarse en el futuro.
12/05/16
634
Diseo arquitectnico
12/05/16
Una vez que las interacciones entre el sistema y su

ambiente se han entendido, se usa esta informacin
por disear la arquitectura del sistema.
Una arquitectura de capas como la discutida en el
Captulo 11 es apropiado para la estacin de tiempo
Capa
de
interfaz
para
manejar
las
comunicaciones;
Capa de recoleccin de datos pata instrumentos de
manejo;
Capa de instrumento para la recoleccin de datos.
Debe haber normalmente no ms de 7 entidades en
un modelo arquitectnico.
635
Arquitectura de estacin
de tiempo
Estacin de tiempo
<<subsystem>>
Interfaz
<<subsystem>>
Recoleccin
de datos
<<subsystem>>
Instrumentos
12/05/16
Maneja todas las comunicaciones

externas.
Recolecta y compendia todos

los datos dl tiempo.
Paquete de instrumentos de
recoleccin de datos crudos.
636
Identificacin de objetos
La
identificacin de objetos (o clases de

objetos) es la parte ms difcil del diseo
orientado a objetos.
No
hay formula mgica para la
identificacin de objetos. Se confa en la
habilidad, experiencia y conocimiento
dominio de los diseadores del sistema.
del
La
identificacin de objetos es un proceso

iterativo. La identificacin del objeto es un
proceso iterativo. Es improbable corregir el
tiempo primero.
12/05/16
637
Aproximaciones para la
identificacin
Usar
una aproximacin gramatical basada en

una descripcin del sistema en lenguaje natural
(usada en el mtodo Hood de DOO).
Basa la identificacin en las cosas tangibles en
el dominio de la aplicacin.
Usa una aproximacin del comportamiento e
identifica objetos basados en qu participa en
qu comportamiento.
Usar el anlisis basado en escenario.
Los
objetos, atributos y mtodos en cada escenario
son identificados.
12/05/16
638
Descripcin de una
estacin de tiempo
Una estacin de tiempo es que un paquete de software que
controla instrumentos que recoleccionan datos, realiza
algunos procesamientos de datos y transmite este datos
ms all del procesamiento. Los instrumentos incluyen
termmetros de aire y tierra, un anemmetro, una veleta del
viento, un barmetro y un medidor de lluvia. Los datos son
peridicamente recolectados.
Cuando un comando es emitido para transmitir los datos de
tiempo, lla estacin de tiempo procesa y compendian los
datos recolectados. El datos compendiados se transmiten a
la computadora correspondiente cuando una demanda es
recibida.
12/05/16
639
Clases de objetos de la
estacin de tiempo
Termmetro de tierra, Anemmetro, Barmetro
Los objetos del dominio de aplicacin que son objetos
del "hardware" relacionados a los instrumentos en el
sistema.
Estacin de tiempo
La interfaz bsica de la estacin de tiempo para su
entorno. La interfaz bsica del tiempo estaciona a su
ambiente. Por consiguiente refleja las interacciones
identificadas en el modelo de casos de uso.
Datos del tiempo
Encapsula
los datos compendiados desde los
instrumentos. Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera
12/05/16
640
Clases de objetos de la
estacin de tiempo
DatosTiempo
EstacinTiempo
TemperaturaAire
TemperaturaTierra
VelocidadViento
DireccinViento
Presiones
Lluvia
Identificador
ImformeTiempo()
Calibrar(Instrumentos)
Prueba()
PonerEnMarcha(Instrumentos)
Cerrar(Instrumentos)
TermmetroTierra
Temperatura
Prueba()
Calibrar()
12/05/16
Coleccionar()
Compendiar()
TermmetroAire
VelocidadViento
DireccinViento
Prueba()
Barmetro
Presin
Altura
Prueba()
Calibrar()
641
Los objetos extensos y

refinamiento del objeto
12/05/16
Usa el conocimiento del dominio para identificar ms objetos y

operaciones.
Las estaciones de tiempo deben tener un nico identificador;
Las estaciones de tiempo son situadas remotamente de
modo que los fallas de instrumento tienen que ser
informadas automticamente. Por consiguiente los atributos
y operaciones para verificar por si mismos son requeridos.
Objetos activos o pasivos
En este caso, los objetos son pasivos y coleccionan los
datos en el lugar de la demanda autnomamente. Esto
introduce la flexibilidad en el gasto del controlador que
procesa tiempo.
642
Modelos de diseo
Los
12/05/16
modelos de diseo muestran los

objetos y clases de objetos y las
interrelaciones entre dichas entidades.
Los
modelos estticos describen la
estructura esttica del sistema por lo que
se refiere a las clases del objeto en
interrelaciones.
Los modelos dinmicos describen las
interacciones dinmicas entre objetos
643
Ejemplos de modelos de
diseo
Modelos de subsistemas que muestran los
agrupamientos lgicos de objetos en subsistemas
coherentes.
Modelos secuenciales que muestran la secuencia de
interacciones de objetos.
Modelos de mquina de estado que muestran como
objetos individuales cambian su estado en respuesta a
eventos.
Otros modelos incluyen los modelos de casos de uso,
modelos de agregacin, modelos de generalizacin,
etc.
12/05/16
644
Modelos de subsistemas
Muestran
cmo el diseo es organizado

dentro de los grupos de objetos
lgicamente relacionados.
En el UML, stos se muestran usando los
paquetes
una
estructura
del
encapsulamiento. ste es un modelo
lgico. La actual organizacin de objetos en
el sistema puede ser diferente.
12/05/16
645
Subsistemas de una
estacin de tiempo
<<subsystem>>
<<subsystem>>
Interfaz
Recoleccin de datos
ControladorComandos
DatosTiempo
EstacinTiempo
EstadoInstrumentos
<<subsystem>>
Instrumentos
TermmetroAire
TermmetroTierra
12/05/16
MedidaLluvia
Anemmetro
Barmetro
VeletaViento
646
Modelos de secuencia
12/05/16
Los modelos de secuencia muestran la secuencia de

interacciones de objetos que tienen lugar
Los objetos se arreglan horizontalmente en la cima;
El tiempo es representado verticalmente de modo que los
modelos son ledos de arriba hacia abajo;
Las
interacciones son representadas por fechas
etiquetadas. Diferentes tipos de flechas representan
diferentes tipos de interaccin;
Un rectngulo delgado en la lnea de vida de un objeto
representa el tiempo que un objeto es el objeto
controlando en el sistema.
647
Secuencia de recoleccin
de datos
: Usuario
: ControladorComandos
I : EstacinTiempo
C : DatosTiempo
1: Demanda(Informacin)
2: Informacin()
3: Compendiar()
4:
5: Enviar(Informacin)
6: Respouesta(Informacin)
7: Reconocer()
12/05/16
648
Diagramas de estado
Muestra cmo los objetos responden a la demanda de

diferentes servicios y las transiciones de estado activadas por
dichas demandas
Si el estado del objeto es Cierre entonces el responde al
mensaje Startup();
En el estado de espera el objeto est esperando por
mensajes extensos;
Si InformeTiempo() entonces el sistema se mueve al estado
de compendio;
Si Calibrar () el sistema se mueve al estado calibrando;
Al estado recolectando se entra cuando una seal de reloj
es recibida.
12/05/16
649
Diagrama de estado de
una estacin de tiempo
Operacin
Calibrar
Calibrando
Calibracin OK
Iniciar
Cierre
Probar
Esperando
Cerrar
Transmisin hecha
InformeTiempo
Probando
Prueba completa
Transmitiendo
Reloj
Recoleccin hecha
Compendiando
Tiempo compendiado
completo
Recoleccionando
12/05/16
650
Especificacin de la
interfaz de objeto
12/05/16
Las interfaces de objeto tienen que ser especificadas

de modo que los objetos y otros componentes pueden
ser diseados en paralelo.
Los
diseadores
deben
evitar
disear
la
representacin de la interfaz pero deben esconder
esto en el propio objeto.
Los objetos pueden tener varias interfaces, que son
los puntos de vista en los mtodos proporcionados.
El UML usa diagramas de clase para la especificacin
de la interfaz, pero Java tambin pude ser usado.
651
Interfaz de la estacin de
tiempo
interface WeatherStation {
public void WeatherStation () ;
public void startup () ;
public void startup (Instrument i) ;
public void shutdown () ;
public void shutdown (Instrument i) ;
public void reportWeather ( ) ;
public void test () ;
public void test ( Instrument i ) ;
public void calibrate ( Instrument i) ;
public int getID () ;
12/05/16
652
Evolucin del diseo

Esconder informacin dentro de los objetos significa
que los cambios hechos a un objeto no afectan a
otros objetos de una manera imprevisible.
El asumir polucin monitoreando los recursos ser
agregado para las estaciones de tiempo. stos
sacan muestra del aire y computan la cantidad de
contaminantes diferentes en la atmsfera.
Las lecturas de polucin sern transmitidas con los
datos del tiempo.
12/05/16
653
Cambios requeridos
Agregar
una clase de objetos llamada Calidad

de aire como parte de EstacinTiempo.
Agregar una operacin informeCalidadAire
para EstacinTiempo. Modificar el software de
control para recolectar lecturas de polucin.
Agregar objetos que representan instrumentos
de monitoreo de polucin.
12/05/16
654
Monitoreando la polucin
EstacinTiempo
Calidad del aire
Identificador
NODatos
DatosHumo
BatosBenceno
ImformeTiempo()
InformeCalidad()
Calibrar(Instrumentos)
Prueba()
Iniciar(Instrumentos)
Cerrar(Instrumentos)
Recolectar()
Compendiar()
Instrumentos de monitoreo de polucin

MedirHumo
NoMedir
MedirBenceno
12/05/16
655
Puntos clave
El DOO es una aproximacin para el diseo, de
modo que los componentes de diseo tengan su
propio estado privado y sus operaciones.
Los objetos deben tener operaciones de constructor
e inspeccin. Ellos proporcionan servicios a otros
objetos.
Los
objetos
pueden
ser
implementados
secuencialmente o concurrentemente.
El lenguaje Unificado de Modelamiento proporciona
notaciones para diferentes modelos de objetos.
12/05/16
656
Puntos clave
Un
rango de diferentes modelos pueden ser

producidos durante el proceso de diseo
orientado a objetos. Ellos incluyen modelos de
sistemas estticos y dinmicos.
Las interfaces de objetos deben ser definidas
precisamente usando, por ejemplo, lenguajes de
programacin como Java.
El diseo orientado a objetos potencialmente
simplifica la evolucin de sistemas.
12/05/16
657
Captulo 15
Diseo de
software de
tiempo real
12/05/16
658
Objetivos
Explicar
el concepto de tiempo real y por qu estos

sistemas son normalmente implementados como
procesos concurrentes
Describir un proceso de diseo para sistemas de
tiempo real
Explicar el rol de sistemas operativos de tiempo
real
Introducir arquitectura de procesos genricos para
monitoreo y control y sistemas de adquisicin de
datos
12/05/16
659
Tpicos cubiertos
Diseo
de sistema
Sistemas operativos de tiempo real
Sistemas de monitoreo y control
Sistemas de adquisicin de datos
12/05/16
660
Sistemas de tiempo real

Sistemas
que monitorean y controlan su entorno.

Inevitablemente
asociado con dispositivos de
hardware
Sensores: Recolectar datos desde el entorno del
sistema;
Actuadores: Cambio (de alguna manera) del
entorno del sistema;
El tiempo es crtico. Los sistemas de tiempo real
DEBEN responder dentro de los tiempos especificados.
12/05/16
661
Definicin
Un sistema de tiempo real es un sistema de software

donde el correcto funcionamiento del sistema depende de
los sistemas producidos por el sistema y el tiempo en que
estos resultados son producidos.
Un sistema de tiempo real suave es un sistema cuyo
funcionamiento es degradado si no se producen los
resultados de acuerdo al tiempo especificado para los
requerimientos.
Un sistema de tiempo real duro es un sistema cuyo
funcionamiento es incorrecto si no se producen los
resultados de acuerdo al tiempo especificado para los
requerimientos.
12/05/16
662
Sistemas de
Estmulo/Respuesta
Dado un estmulo, el sistema debe producir una
contestacin dentro de un tiempo especificado.
Estmulos peridicos. Estmulos que ocurren a los
intervalos de tiempo predecibles
Por ejemplo, un sensor de temperatura puede ser
registrado 10 veces por segundo.
Estmulos aperidicos. Estmulos que ocurren en los
momentos imprevisibles
Por ejemplo, una falla de un sistema de potencia
puede activar una interrupcin que debe ser
procesada por el sistema.
12/05/16
663
Consideraciones
arquitectnicos
Debido a la necesidad de responder a los tiempos
de
demanda
hechas
por
diferentes
estmulos/respuestas, la arquitectura del sistema
debe permitir cambiar rpidamente entre
manejadores del estmulo.
Los tiempos de demandas de diferentes estmulos
son diferentes, as un bucle secuencial simple no
es normalmente adecuado.
Los sistemas de tiempo real por consiguiente son
normalmente
diseados
como
procesos
cooperativos con un ejecutor de tiempo real que
controla estos procesos.
12/05/16
664
Modelo de un sistema de
tiempo real
Sensor
Sensor
Sensor
Sensor
Sensor
Sensor
Sensor
Sensor
Sensor
Sensor
Sensor
Sensor
Sistemade
decontrol
control
Sistema
detiempo
tiemporeal
real
de
Actuador
Actuador
12/05/16
Actuador
Actuador
Actuador
Actuador
Actuador
Actuador
665
Procesos de
sensor/actuador
Actuador
Actuador
Sensor
Sensor
Estmulo
Controlde
de
Control
sensor
sensor
12/05/16
Respuesta
Procesador de
de
Procesador
datos
datos
Controlde
de
Control
actuador
actuador
666
Elementos del sistema

Procesos
de control de sensor
Recolecta la informacin de los sensores. Es posible

una memoria intermedia de informacin recolectada
en respuesta para un estmulo del sensor.
Procesador
de datos
Lleva a cabo un procesamiento de la informacin

recolectada y computa la respuesta del sistema.
Procesos de control de actuador
12/05/16
Genera seales de control para los actuadores.

667
Programando en tiempo real

Los
sistemas de tiempo duro-reales pueden

tener
que programar
en lenguaje
ensamblador para asegurar que fechas
lmite se encuentran.
Lenguajes tales como C permiten escribir
los programas eficaces pero no tienen las
estructuras para apoyar concurrencia la
gestin de recursos compartidos.
12/05/16
668
Java como un lenguaje de

tiempo real
Java soporta la concurrencia ligera (los hilos y los mtodos

sincronizados) y puede usarse para algunos sistemas de
tiempo real suaves.
Java 2.0 no es apropiada para la programacin en TR dura,
pero las versiones de Java est ahora disponible para los
problemas de direccin como
No es posible especificar tiempo de ejecucin del hilo;
Diferentes tiempos en las mquinas virtuales diferentes;
La recoleccin de basura incontrolable;
No es posible descubrir los tamaos de cola para los
recursos compartidos;
No es posible acceder al hardware del sistema;
No es posible espaciar o cronometrar el anlisis.
12/05/16
669
Diseo del sistema

Disea
el hardware y el software asociado con el

sistema. La particin funciona para el hardware o
el software.
Las decisiones de diseo deben tomarse en la
base a los requerimientos del sistema no
funcionales.
El hardware entrega buen desempeo, pero
desarrollo potencialmente ms largo y menos
alcance para el cambio.
12/05/16
670
Proceso de diseo de
sistemas de T-R
Identifica
los estmulos a ser procesados y

las respuestas requeridas a estos
estmulos.
Para cada estmulo y respuesta, identifica
las restricciones de oportunidad.
Agrega el estmulo y respuesta que
procesa en los procesos concurrentes. Un
proceso puede asociarse con cada clase
de estmulo y respuesta.
12/05/16
671
Proceso de diseo de
sistemas de T-R
Disea
los algoritmos para procesar cada clase

de estmulo y respuestas. stos deben
enfrentarse dada la oportunidad de los
requerimientos.
Disea
un sistema de planificacin que
asegurar que se empiezan los procesos a
tiempo a encontrarse sus fechas lmite.
Se integra usando un sistema operativo del
tiempo real.
12/05/16
672
Restricciones de
oportunidad
Puede
requerir la simulacin extensa y

experimento para asegurar que stos se renen
por el sistema.
Puede significar que ciertas estrategias de
diseo, como el diseo orientado a objetos, no
puede usarse debido al adicional encabezado
involucrado.
Puede significar que los rasgos del lenguaje de
programacin de bajo nivel tienen que ser usados
por razones de desempeo.
12/05/16
673
Modelamiento de
sistemas de tiempo real
El efecto de un estmulo en un sistema del tiempo real
puede activar una transicin de un estado a otro.
Las mquinas de estado finitas pueden usarse para el
modelamiento de sistemas de tiempo real.
Sin embargo, FSM modela estructura de escasez.
Incluso los sistemas simples pueden tener un modelo
complejo.
El UML incluye notaciones para definir modelos de
mquina de estados.
Ver el Captulo 8 para los ejemplos extensos de
modelos de mquinas de estado.
12/05/16
674
Modelo de estado de
bomba de gasolina
Interrupcin
Tarjeta insertada en la lectora
Ley endo
Inicializando
do/ Recibir T, Detalles T
Tarjeta remov ida
Esperando
Validando
do/ Visualiza bienvenida
do/ Validar tarjeta de crdito
do/ Inicializa despliegue
Tarjeta OK
Sacar manguera f uera del brazo

Listo
Apretar gatillo
Entregando
Tarjeta inv alida
Interrupcin
do/ Entregar gasolina, Actualiza despliegue
Reiniciando
Soltar gatillo
do/ Visulaizar T, error de T
Parada
Apretar gatillo
Pagando
Conf irmar pago
12/05/16
do/ Cargar T, Cuenta de T
Dev olv er manguera al brazo
675
Sistemas operativos de
tiempo real
Los
sistemas operativos de tiempo real son

sistemas operativos que manejan los procesos
en los STR.
Responsable para la gestin del proceso y la
asignacin del recurso (procesador y memoria).
Puede estar basado en un ncleo estndar que
es usado tal como est o modificado para una
aplicacin particular.
Normalmente no incluye recursos como la
administracin de archivos.
12/05/16
14
676
Componentes del sistema

operativo
Reloj de tiempo real

Provee la informacin la planificacin del proceso.
Manejador de interrupcin
Maneja demandas aperidicas pide para el servicio.
Programa
Elige el prximo proceso a ser ejecutado.
Administrador de recurso
Asigna memoria y recursos del procesador.
Distribuidor
Inicia proceso de ejecucin.
12/05/16
677
Componentes de un
sistema sin para
Administrador de configuracin
Responsable para la reconfiguracin dinmica de un
sistema de software y hardware. Los mdulos de
hardware modules pueden ser remplazadas y el
software es reactualizado sin parar el sistema.
Administrador de fallas
Responsable para detectar fallas de software y
hardware y tomar acciones apropiadas (por ejemplo,
intercambios de discos de respaldo) para asegurar
que el sistema continua en operacin.
12/05/16
678
Componentes de un SO
de tiempo real
Programacinde
de
Programacin
informacin
lalainformacin
Relojde
detiempo
tiempo
Reloj
real
real
Programador
Programador
Manejadorde
de
Manejador
interrupcin
interrupcin
Procesode
de
Proceso
requerimientos
requerimientos
derecursos
recursos
de
Procesode
de
Proceso
evaluacinde
de
evaluacin
recursos
recursos
Manejadorde
de
Manejador
recursos
recursos
Proceso listo
Listapreparada
preparada
Lista
Distribuidor
Distribuidor
Listade
derecursos
recursos
Lista
disponibles
disponibles
Recursos
libres
Listadel
del
Lista
procesador
procesador
Proceso de ejecucin
12/05/16
679
Procesar la prioridad
El procesamiento de algunos tipos de estmulos
debe tomar a veces la prioridad.
La prioridad a nivel de interrupcin. La prioridad
ms alta que se asigna a procesos que requieren
una respuesta muy rpida.
La prioridad a nivel del reloj. Asignado a los
procesos peridicos.
Dentro de stos, pueden asignarse niveles
extensos de prioridad.
12/05/16
680
Servicio de interrupcin
El control es transferido automticamente a una
ubicacin de memoria predeterminada.
Esta situacin contiene una instruccin para saltar
a una rutina de servicio de interrupcin.
Las interrupciones extensas son invlidas, la
interrupcin es reparada y devuelve el control al
devolvi al proceso interrumpido.
Las rutinas del servicio de interrupcin DEBEN se
cortas, simples y rpidas.
12/05/16
681
Servicio de proceso peridico

En ms sistemas de tiempo real, habr varias clases
de proceso peridico, cada uno con los diferentes
periodos (tiempo entre las ejecuciones), los tiempos
de ejecucin y fechas lmite (el tiempo en el cual el
procesamiento debe completarse).
El reloj de tiempo real hace tictac peridicamente y
cada tictac causa una interrupcin que fija al
administrador del proceso para los procesos
peridicos.
El administrador del proceso selecciona un proceso
que est listo para la ejecucin.
12/05/16
682
Gestin de procesos
Tiene
relacin con manejar el conjunto de

procesos concurrentes.
Los procesos peridicos son ejecutados
en
intervalos de tiempo pre-especificados.
El SOTR usa el reloj de tempo real para
determinar cuando ejecutar un proceso tomado
en cuenta:
12/05/16
Proceso peridico tiempo entre ejecuciones.

Proceso de fecha lmite el tiempo en el cual un
procesamiento debe ser completado.
683
Gestin de procesos TRE
Planificador
Elige procesos
para ejecucin
12/05/16
Manejador de
recursos
Asigna memoria y
procesador
Distribuidor
Inicia ejecucin en
un procesador
disponible
684
Cambiando el proceso
El
planificador elige el prximo proceso para

ser ejecutado por el procesador. Esto depende
de una estrategia de planificacin que puede
tener en cuenta la prioridad del proceso.
El administrador del recurso asigna memoria y
un procesador para el proceso a ser ejecutado.
El distribuidor toma el proceso de la lista
preparada, carga
en l un procesador y
ejecuta las salidas.
12/05/16
685
Estrategias de planificacin
Planificacin no preventiva
Una vez que un proceso se ha planificado para la
ejecucin, corre para completarla o hasta que se bloquee
por alguna razn (por ejemplo, esperando por E/S).
Planificacin preventiva
La ejecucin de un proceso ejecutndose puede detenerse
si un proceso de prioridad ms alto requiere el servicio.
Algoritmos de planificacin
Robin round (Turno rotatorio);
Rate monotonic (Prioridades fijas);
Shortest deadline first (Primero la tarea con menor tempo
de holgura).
12/05/16
686
Monitoreo y control de
sistemas
Clases
importantes de sistemas de tiempo real.

Continuamente los sensores de chequeo y toma
acciones que dependen de los valores del
sensor.
El monitoreo de sistemas examina y reporta sus
resultados.
Los sistemas de control toman valores del sensor
y actuadores de control de hardware.
12/05/16
687
Arquitectura genrica
Procesode
de
Proceso
prueba
prueba
S1
S1
P(S1)
P(S1)
S2
S2
P(S2)
P(S2)
S3
S3
P(S3)
P(S3)
Procesode
de
Proceso
monitoreo
monitoreo
Procesode
de
Proceso
control
control
P(A1)
P(A1)
A1
A1
P(A2)
P(A2)
A2
A2
P(A3)
P(A3)
A3
A3
P(A4)
P(A4)
A4
A4
Procesode
depanel
panel
Proceso
decontrol
control
de
12/05/16
688
Sistema de alarma contra

robo
Un
sistema es exigido para monitorear sensores

en las puertas y ventanas para detectar la
presencia de intrusos en un edificio.
Cuando un sensor indica un descanso, el
sistema enciende las luces alrededor del rea y
llama a la polica automticamente.
El sistema debe incluir la provisin para el
funcionamiento sin un suministro principal de
poder.
12/05/16
689
El proceso de diseos de
sistemas de TR
Identifica estmulos y respuestas asociadas.
Define las restricciones de tiempo asociados con
cada estmulo y respuesta.
Asigna las funciones del sistema a los procesos
concurrentes.
Disea algoritmos para estimular procesamiento y
generacin de respuestas.
Disea un sistema de planificacin que asegure que
el proceso siempre se planificar para cumplir con
las fechas lmite.
12/05/16
690
Estmulo para ser

procesado
Falla
de energa
Generado aperidicamente por un monitor de
circuito. Cuando es recibida el sistema debe
cambiar la energa de respaldo dentro de 50
ms.
Alarma de intruso
Estmulo generado por sensores del sistema.
La respuesta es llamar a la polica encender las
luces de la construccin y una alarma audible.
12/05/16
691
Requerimientos de tiempo
Estmulo/Respuesta
Requerimientos de tiempo
Interrupcin de falla de energa
El interruptor de energa auxiliar debe completarse

dentro de una fecha tope de 50 ms.
Alarma de puerta
Cada alarma de puerta debe registrarse dos veces por

segundo.
Alarma de ventana
Cada alarma de ventana debe registrarse dos veces por

segundo.
Detector de movimiento
Cada detector de movimiento debe registrarse de dos

veces por segundo.
Alarma audible
La alarma audible debe encenderse dentro de 1/2

segundo al ser la alarma promovida por un sensor.
Encendido de luces
La luces deben encenderse dentro de 1/2 segundo al

ser la alarma promovida por un sensor.
Comunicaciones
La llamada a la polica debe empezar dentro de 2

segundos al ser la alarma promovida por un sensor.
Sintetizadores de voz
Un mensaje sintetizado debe estar disponible dentro de

4 segundos al ser la alarma promovida por un sensor.
12/05/16
692
Proceso de sistema de
alarma contra robos
60 Hz
400 Hz
Proceso de sensor
Proceso de sensor
depuerta
puerta
de
Procesode
dedetector
detector
Proceso
de
movimiento
de movimiento
Estatus de
detector
560 Hz
Interruptor de
falla de energa
Construccin
de monitor
Nmero de
pieza
Procesode
de
Proceso
sistemade
dealarma
alarma
sistema
Sistema de
alarma
12/05/16
Estatus de
sensor
Estatus de
sensor
Procesode
deconstruccin
construccin
Proceso
demonitor
monitor
de
Procesode
deinterruptor
interruptor
Proceso
deenerga
energa
de
Procesode
dealarma
alarma
Proceso
audible
audible
100 Hz
Procesode
desensor
sensor
Proceso
deventana
ventana
de
Sistema de
alarma
Procesode
de
Proceso
comunicacin
comunicacin
Mensaje de
alerta
Sistema de
alarma
Nmero de Nmero de
pieza
pieza
Procesode
decontrol
controlde
de
Proceso
encendidode
deluz
luz
encendido
Procesode
de
Proceso
sintetizador de voz
sintetizador de voz
693
Proceso 1 de
construccin de monitor
class BuildingMonitor extends Thread {
BuildingSensor win, door, move ;
Siren
siren = new Siren () ;
Lights
lights = new Lights () ;
Synthesizer synthesizer = new Synthesizer () ;
DoorSensors doors = new DoorSensors (30) ;
WindowSensors
windows = new WindowSensors (50) ;
MovementSensors movements = new MovementSensors (200) ;
PowerMonitor pm = new PowerMonitor () ;
BuildingMonitor()
{
// initialise all the sensors and start the processes
siren.start () ; lights.start () ;
synthesizer.start () ; windows.start () ;
doors.start () ; movements.start () ; pm.start () ;
}
12/05/16
694
Proceso 2 de construccin
de monitor
public void run ()
{
int room = 0 ;
while (true)
{
// poll the movement sensors at least twice per second (400 Hz)
move = movements.getVal () ;
// poll the window sensors at least twice/second (100 Hz)
win = windows.getVal () ;
// poll the door sensors at least twice per second (60 Hz)
door = doors.getVal () ;
if (move.sensorVal == 1 | door.sensorVal == 1 | win.sensorVal == 1)
{
// a sensor has indicated an intruder
if (move.sensorVal == 1)
room = move.room ;
if (door.sensorVal == 1)
room = door.room ;
if (win.sensorVal == 1 )
room = win.room ;
lights.on (room) ; siren.on () ; synthesizer.on (room) ;
break ;
}
}
12/05/16
695
Proceso 3 de
construccin de monitor
lights.shutdown () ; siren.shutdown () ; synthesizer.shutdown () ;

windows.shutdown () ; doors.shutdown () ; movements.shutdown () ;
} // run
} //BuildingMonitor
12/05/16
696
Sistemas de control
Un sistema de alarma contra robos es principalmente
un sistema de monitoreo. Recolecta los datos de los
sensores pero ningn control de actuador de tiempo
real.
Los sistemas de control son similares pero, en
respuesta para valores del sensor, el sistema enva
seales de control para los actuadores.
Un ejemplo de un sistema de monitoreo y control es
un sistema que monitorea la temperatura
e
intercambia el estado del calentador en encendido
(on) o apagado (off).
12/05/16
697
Un sistema de control de
temperatura
500 Hz
Procesode
de
Proceso
sensor
sensor
500 Hz
500 Hz
Valores de
sensor
Procesode
de
Proceso
termostato
termostato
Proceso de
termostato
Comando de cambio
Procesode
decontrol
control
Proceso
decalentador
calentador
de
12/05/16
Nmero de pieza
Proceso de control
Proceso de control
dehorno
horno
de
698
Sistemas de adquisicin
de datos
Recolecta los datos de los sensores para el proceso
subsecuente y el anlisis.
Los procesos de recoleccin de datos y los procesos de
procesamiento pueden tener periodo diferentes y
fechas tope.
La recoleccin de los datos puede ser ms rpida que
procesando, por ejemplo, la informacin colectiva sobre
una explosin.
Las memorias intermediarias (buffers) circulares o en
anillo son un mecanismo para las diferencias de
velocidad suavizadoras.
12/05/16
699
Arquitectura de
adquisicin de datos
Sensor (cada flujo de datos es un valor del sensor)
s1
s1
s2
s2
Identificador de
sensor y valor
Procesode
de
Proceso
sensor
sensor
Identificador de
sensor y valor
Bufferde
dedatos
datos
Buffer
desensor
sensor
de
Datosdel
del
Datos
proceso
proceso
Desplegar
Desplegar
s3
s3
s4
s4
s5
s5
Identificador de
sensor y valor
Procesode
de
Proceso
sensor
sensor
Identificador de
sensor y valor
Bufferde
dedatos
datos
Buffer
desensor
sensor
de
Datosdel
del
Datos
proceso
proceso
s6
s6
12/05/16
700
Recoleccin de datos de
reactor
Un
sistema recolectan datos desde un conjunto

de sensores que monitorean el flujo del neutrn
de un reactor nuclear.
Los datos de flujo se ponen en un buffer en anillo
para el posterior proceso.
El buffer en anillo es implementado como un
proceso concurrente de modo que el conjunto y
los procesos del proceso puedan ser
sincronizados.
12/05/16
701
Monitoreando el flujo del

reactor
Sensores de flujos
de neutrn
Identificador de sensor
y valores de flujo
Convertidor
Convertidor
A-D
A-D
12/05/16
Bufferde
de
Buffer
datosde
deflujo
flujo
datos
Nivel de flujo
procesado
Procesamient
Procesamient
deflujo
flujo
oode
Despliega
Despliega
operador
operador
702
Un buffer en anillo
Proceso
Proceso
productor
productor
Proceso
Proceso
consumidor
consumidor
12/05/16
703
Exclusin mutua
Los procesos productores recolectan los datos y lo
agregan al buffer. El proceso consumidor toma los
datos del buffer y hace los elementos disponibles.
Los procesos productor y consumidor deben ser
mutuamente excluyentes puesto que acceden al
mismo elemento.
El
buffer debe parar el proceso productor
agregando informacin para un buffer lleno y el
proceso consumidor prueba a tomar informacin
desde un buffer vaco.
12/05/16
704
Implementacin de un
buffer en anillo 1
class CircularBuffer
{
int bufsize ;
SensorRecord [] store ;
int numberOfEntries = 0 ;
int front = 0, back = 0 ;
CircularBuffer (int n) {
bufsize = n ;
store = new SensorRecord [bufsize] ;
} // CircularBuffer
12/05/16
705
Implementacin de un
buffer en anillo 2
synchronized void put (SensorRecord rec )
throws InterruptedException
{
if ( numberOfEntries == bufsize)
wait () ;
store [back] = new SensorRecord (rec.sensorId, rec.sensorVal) ;
back = back + 1 ;
if (back == bufsize)
back = 0 ;
numberOfEntries = numberOfEntries + 1 ;
notify () ;
} // put
12/05/16
706
Implementacin de un
buffer en anillo 3
synchronized SensorRecord get () throws InterruptedException
{
SensorRecord result = new SensorRecord (-1, -1) ;
if (numberOfEntries == 0)
wait () ;
result = store [front] ;
front = front + 1 ;
if (front == bufsize)
front = 0 ;
numberOfEntries = numberOfEntries - 1 ;
notify () ;
return result ;
} // get
} // CircularBuffer
12/05/16
707
Puntos clave
La
correctitud de un sistema de tiempo real

depende no slo den lo que el sistema hace,
sino tambin de cuan rpido reacciona.
Un modelo de sistema de TR involucra procesos
asociados con sensores y actuadores.
Las arquitecturas de sistemas de tiempo real son
normalmente diseadas como una variedad de
procesos concurrentes.
12/05/16
708
Puntos clave
Los
sistemas operativos de tiempo real son

responsables para el proceso y gestin de recursos.
Los sistemas de monitoreo y controla registran los
sensores y envan la seal de control para los
actuadores.
Los
sistemas
de
adquisicin
son
normalmente organizados de acuerdo al
modelo productor consumidor.
12/05/16
709
Captulo 16
Diseo de
interfaz de
usuario
12/05/16
710
Objetivos
Sugerir
algunos principios de diseo general para el

diseo de interfaz de usuario
Explicar diferentes estilos de interaccin y su uso
Explicar cuando usar presentacin grfica y textual
de informacin
Explicar las principales actividades y el proceso de
interfaz de usuario
Introducir atributos de usuabilidad y aproximacin
para evaluacin de sistemas
12/05/16
711
Tpicos cubiertos
Problemas
de diseo
Proceso de diseo para interfaz de
usuario
Anlisis de usuario
Prototipado de interfaz de usuario
Evaluacin de interfaz
12/05/16
712
La interfaz de usuario
Las
interfaces de usuario deben ser diseadas

para igualar las habilidades, la experiencia, las
expectativas y de sus usuarios anticipados.
Los usuarios del sistemas a menudo juzgan un
sistema por su interfaz antes que por su
funcionalidad.
Una interfaz mal diseada puede causar que el
usuario cometa errores catastrficos.
Un diseo pobre de la interfaz de usuario es la
razn por la cual muchos sistemas de software no
se usan nunca.
12/05/16
713
Diseo de interfaz de
factores humanos
Memoria de corto plaza limitada

Las personas pueden recordar instantneamente alrededor
de 7 temas de informacin. Si superan este lmite, ellos son
ms susceptibles de cometer errores.
Las personas cometen errores
Cuando las personas cometes errores y sistemas van mal,
las alarmas inapropiadas y mensajes pueden aumentar la
tensin y la probabilidad de ms errores.
Las personas son diferentes
Las personas tienen una gama amplia de capacidades
fsicas. Los diseadores no deben disear solamente para
sus propias capacidades.
Las personas tienen diferentes preferencias de interaccin
Algunos gustan de grficos, otros gustan de textos.
12/05/16
714
Principios del diseo de IU

El diseo IU debe tomar en cuenta las necesidades,
experiencia y capacidades de los usuarios del
sistema.
Los diseadores deben ser conscientes de las
limitaciones fsicas y mentales de personas (por
ejemplo, la memoria a corto plazo limitada) y debe
reconocer que las personas cometen errores.
Los principios de diseo de IU estn supeditados a
los diseos de interfaz, aunque no todos los
principios son aplicables a todos los diseo.
12/05/16
715
Principios del diseo de

interfaz de usuario
Principio
Familiaridad
usuario
Descripcin
del
La familiaridad del usuario: La interfaz debe usar las

condiciones y conceptos que son delineados a partir de
la experiencia de las personas que harn ms uso del
sistema.
Consistencia
La interfaz debe ser consistente en eso, dondequiera sea

posible, las operaciones comparables deben ser
activadas de la misma manera.
Sorpresa mnima
Los usuarios nunca deben ser sorprendidos por el

comportamiento de un sistema.
Recuperabilidad
La interfaz debe incluir los mecanismos para permitirles

a los usuarios recuperarse de los errores.
Gua del usuario
La interfaz debe proporcionar la regeneracin

significativa cuando los errores ocurren y proporcionar
los recursos de ayuda de usuario contexto-sensibles.
Diversidad de usuario
La interfaz debe mantener los recursos de la interaccin

apropiados los tipos diferentes del sistema de usuario.
12/05/16
716
Principios de diseo
Familiaridad de usuario
La interfaz debe estar basada en trminos orientados al
usuario y conceptos en lugar de los conceptos de la
computadora. Por ejemplo, un sistema de la oficina debe
usar los conceptos como cartas, documentos, carpetas etc.
en lugar de los directorios, los identificadores de archivo,
etc.,
Consistencia
El sistema debe desplegar un nivel apropiado de
consistencia. Los comandos y mens deben tener el mismo
formato, la puntuacin del comando debe ser similar, etc.
Sorpresa mnima
Si un comando opera de una manera conocida, el usuario
debe poder predecir la operacin de comandos
comprables.
12/05/16
717
Principios de diseo
Recuperabilidad
El sistema debe proporcionar un poco de elasticidad para
los errores de usuario y debe permitirle al usuario
recuperarse de los errores. Esto podra incluir facilidad de
cancelar, la confirmacin de acciones destructivas, borrar
soft , etc.
Gua de usuario
Alguna gua del usuario como los sistemas de ayuda, los
manuales en lnea, etc. debe ser proporcionada.
Diversidad de usuario
Recursos de interaccin para los tipos diferentes de usuario
deben ser soportados. Por ejemplo, algunos usuarios
tienen dificultades de vista y los texto con tipos ms
grandes deben estar
disponibles.
12/05/16
718
Los problemas de diseo

en IUs
Dos
problemas deben ser dirigidos en el diseo de

sistemas interactivos
Cmo debe proporcionarse la informacin del usuario al

sistema de computadora?
Cmo debe presentarse la informacin del sistema de
computadora al usuario?
La
interaccin del usuario y la presentacin de

informacin pueden integrarse a travs de un
framework coherente como una metfora de interfaz
de usuario.
12/05/16
719
Estilos de interaccin
Manipulacin
directa
Seleccin de men
Llenado en formulario
Lenguaje de comandos
Lenguaje natural
12/05/16
720
Estilos de interaccin
Estilos de
interaccin
Principales
ventajas
Principales desventajas
Ejemplos de
aplicacin
Manipulacin directa
Interaccin
rpida
intuitiva.
Fcil de aprender
Puede ser duro de implementar.

Slo es conveniente donde hay
una metfora visual para las
tareas y objetos.
Juegos de video.
Sistemas CAD.
Seleccin de men
Evita el error de usuario.

Mecanografa requerida
pequea.
Lento
para
usuarios
experimentados.
Puede volverse complejo si hay
muchas opciones para el men.
La mayora de sistemas
de propsito general.
Llenado
formulario
en
Entrada de datos simple.

Fcil de aprender.
Controlable.
Toma mucho espacio en la

pantalla.
Causa problemas
cuando las
opciones
del
usuario
no
coinciden con los campos del
formulario.
Control de stock.
Procesamiento
de
prstamos personales.
Lenguaje
comandos
de
Poderoso y flexible.
Difcil de aprender.
Pobre gestin de error.
Sistemas operativos.
Sistemas de control
comandos.
Lenguaje natural
12/05/16
Accesible a usuarios
casuales.
Se extiende fcilmente.
Requiere ms mecanografa.
Los sistemas de interpretacin
del
lenguaje
natural
son
inestables.
Sistemas de recuperacin
de informacin.
721
Interfaces de mltiple
usuario
Interfazgrfica
grficade
de
Interfaz
usuario
usuario
(Gnome/KDE)
/KDE)
(Gnome
Interfazde
de
Interfaz
aparienciade
deUnix
Unix
apariencia
(ksh/csh)
/csh)
(ksh
Administrador
Administrador
GUI
XGUI
XWindows
Windows
Intrpretede
de
Intrprete
lenguajede
de
lenguaje
comandos
comandos
SistemaOperativo
OperativoLinux
Linux
Sistema
12/05/16
722
Interaccin LIBSYS
Bsqueda
de documento
Los usuarios necesitan poder usar los medios
de bsqueda para encontrar los documentos
que ellos necesitan.
Demanda de documento
Los usuarios piden que un documento se
entregue a su mquina o a un servidor para
imprimir.
12/05/16
723
Interfaces basadas en la
Web
Muchos
sistemas basados en la Web tienen las

interfaces basadas en las formatos de la Web.
Los campos de formato pueden ser mens,
entrada de texto libre, botones radio, etc.
En el ejemplo LIBSYS, los usuarios hacen uso
de una opcin de men, para buscar un
documento tipeando una frase dentro de un
campo de texto.
12/05/16
724
Formulario de bsqueda
LIBSYS
LIBSYS: Bsqueda
Elegir coleccin
Todo
Ttulo
Clave o frase
Buscar usando
Palabra adyacente
Buscar
12/05/16
Si
Restaurar
No
Cancelar
725
Presentacin de
informacin
La presentacin de informacin se preocupa por
presentar la informacin del sistema a los usuarios del
sistema.
La informacin puede ser presentada directamente
(por ejemplo, el texto en un procesador de texto) o
puede transformarse de alguna forma de presentacin
(por ejemplo, en alguna forma grfica).
La aproximacin Controlador-Vista-Modelo es una
manera de presentaciones mltiples de soporte de
datos.
12/05/16
726
Presentacin de
informacin
Informacinpara
para
Informacin
servisualizado
visualizado
ser
Softwarede
de
Software
presentacin
presentacin
Visualizador
12/05/16
727
Controlador-Vista-Modelo
Entradas
de usuario
Estado controlador
Mensajes de
modificacin
de vista
Estado vista
Mtodos de
vista
Mtodos de
controlador
Editar modelo
Estado modelo
Consultas de
modelo y
actualizaciones
Mtodos de
modelo
12/05/16
728
Presentacin de
informacin
Informacin
esttica
Inicializado al principio de una sesin. No
cambia durante la sesin.
Puede ser numrica o textual.
Informacin dinmica
Cambia durante una sesin y el cambio debe
ser comunicada al usuario del sistema.
Puede ser numrica o textual.
12/05/16
729
Factores de despliegue
de informacin
Est el usuario interesado en informacin precisa o

interrelaciones de los datos?
Cun rpidamente cambian los valores de
informacin?
Debe
indicarse
el
cambio
inmediatamente?
El usuario debe tomar alguna accin en respuesta a un
cambio?
Hay una interfaz de manipulacin directa?
La informacin es textual o numrica? Son
importantes los valores relativos?
12/05/16
730
Presentaciones de
informacin alternativas
12/05/16
731
Presentacin anloga o digital?

Presentacin
Compacto toma un pequeo espacio de la pantalla;

Valores precisos pueden ser comunicados.
Presentacin
12/05/16
digital
anloga
Mucha facilidad para conseguir una impresin de

valores '"de un vistazo";
Posibilidad de mostrar valores relativos;
Mucha facilidad para ver valores de datos
excepcionales.
732
Mtodos de presentacin
Marcar con
aguja
Diagrama de
pastel
Termmetro
10
20
30
40
50
60
70
80
90
Barra horizontal
12/05/16
733
Visualizando valores
relativos
Presin
0
12/05/16
100
200
Temperatura
300
400
25
70
75
100
734
Visualizacin de datos
Tiene relacin con las tcnicas para desplegar grandes

cantidades de informacin.
Visualizacin puede revelar las interrelaciones entre las
entidades y tendencias en los datos.
Las posibles visualizaciones de datos son:
12/05/16
Informacin del tiempo recolectada desde varias fuentes;

El estado de una red de telfonos como un conjunto de
nodos enlazados;
Una planta qumica visualizada por visualizacin de
presiones y temperaturas en un conjunto enlazado de
tanques y caeras;
Un modelo de visualizacin de molcula en 3 dimensiones;
Visualizacin de pginas Web
Web como un rbol
hiperblico.
735
Pantallas de color
El
color agrega una dimensin extra para una

interfaz y puede ayudar al usuario a entender
estructuras de informacin completa.
El color puede ser usado para resaltar eventos
excepcionales.
Los confusiones comunes en el uso de color en
el diseo de interfaz incluyen:
12/05/16
El uso del color par comunicar el significado;

El sobreuso de color en el despliegue.
736
Guas para el uso de color

Limitar
el nmero de colores usados y ser

conservadores en dicho uso.
Usar el cambio de color para mostrar un cambio
en el estado del sistema.
Usar un cdigo de colores para dar soporte a las
tareas que el usuario intenta realizar.
Usar un cdigo de colores de una manera
razonada y consistente.
Tener cuidado en la combinacin de colores.
12/05/16
737
Mensajes de error
El
diseo de mensajes de error es crticamente

importante. Los mensajes del error pobres
pueden significar que un usuario rechaza en
lugar de aceptar un sistema.
Los mensajes deben ser corteses, concisos,
consistentes y constructivos.
La formacin y experiencia de los usuarios deben
ser el factor determinante en el diseo del
mensajes.
12/05/16
738
Los factores de diseo en la

redaccin de mensajes
Factor
Descripcin
Contexto
Dondequiera que sea posible, los mensajes generados por el sistema deben
reflejar el contexto del usuario actual. Hasta donde sea posible, el sistema
debe ser consciente de lo que el usuario est haciendo y debe generar
mensajes que sean pertinentes a su actividad actual.
Experiencia
Cuando los usuarios se familiaricen con un sistema, se irritan bastante con

los mensajes "significativos". Sin embargo, los principiantes lo encuentran
difcil de entender declaraciones muy concisas de un problema. Se debe
proporcionar ambos tipos de mensaje y debe permitir al usuario controlar la
concisin del mensaje.
Nivel de habilidad
Deben adaptarse los mensajes a las habilidades del usuario, as como a su

experiencia. Pueden expresarse mensajes para diferentes clases de
usuario, de diferentes maneras, que dependen de la terminologa a la que
est familiarizado el lector.
Estilo
Los mensajes deben ser positivos en lugar de negativos. Ellos deben usar
el activo en lugar del modo pasivo de direccin. Ellos nunca deben ser
insultantes o deben intentar ser humorsticos.
Cultura
Dondequiera sea posible, el diseador de mensajes debe estar familiarizado

con la cultura del pas dnde el sistema se vende. Hay diferencias
culturales distintas entre Europa, Asia y Amrica. Un mensaje conveniente
para una cultura podra ser inaceptable en otro.
12/05/16
739
Error de usuario
Asumir
que una enfermera deletrea mal el nombre de

un paciente cuyos registros est intentando recuperar.
Por favor
favor escribir
escribir elel nombre
nombre del
del paciente
paciente en
en lala caja
caja yy entonces
entonces
Por
hacerclick
clicken
enOK
OK
hacer
Nombre del paciente
RODRIGUEZSANCHEZ,
SANCHEZ,J.J.
RODRIGUEZ
OK
OK
12/05/16
Cancelar
Cancelar
740
Diseo de buen y mal

mensaje
Mensaje de error orientado al sistema
??
OK
OK
Error##27
27
Error
Pacienteinvlido
invlido
Paciente
Cancelar
Cancelar
Mensaje de error orientado al usuario

RODRIGUEZ SANCHEZ
SANCHEZ no
no es
es un
un paciente
paciente
J.J. RODRIGUEZ
registrado.
registrado.
Clicken
enPacientes
Pacientespara
parauna
unalista
listade
depacientes.
pacientes.
Click
Click en
enReintentar
Reintentarpara
parareingresar
reingresar elelnombre
nombre
Click
de
un
paciente.
de un paciente.
Clicken
enAyuda
Ayuda para
paramayor
mayorinformacin
informacin
Click
Pacientes
Pacientes
12/05/16
Ayuda
Ayuda
Reintentar
Reintentar
Cancelar
Cancelar
741
El proceso de diseo de IU
El
diseo de IU es un proceso interactivo que

involucra los enlaces ntimos entre usuarios y
diseadores.
Las 3 actividades centrales en este proceso son:
12/05/16
Anlisis de usuario: Entendimiento de lo que los

usuarios harn con el sistema;
Prototipado del sistema: Desarrollar una serie de
prototipos para experimentar;
Evaluacin de la interfaz: Experimentar estos
prototipos con los usuarios.
742
El proceso de diseo
Analizaryy
Analizar
entenderlas
las
entender
actividadesdel
del
actividades
usuario
usuario
Producirdiseos
diseos
Producir
deprototipos
prototipos
de
basadosen
enpapel
papel
basados
Prototipode
de
Prototipo
diseo
diseo
Evaluareleldiseo
diseo
Evaluar
conlos
losusuarios
usuarios
con
finales
finales
Producir
Producir
prototipode
de
prototipo
diseo
diseo
dinmico
dinmico
Prototipo
Prototipo
ejecutable
ejecutable
12/05/16
Evaluardiseo
diseo
Evaluar
conlos
los
con
usuariosfinales
finales
usuarios
Implementarlala
Implementar
interfazdel
del
interfaz
usuariofinal
final
usuario
743
Anlisis de usuario
Si
no se entiende lo que los usuarios quieren

hacer con un sistema, no se tiene ninguna
perspectiva realista de disear una interfaz
eficaz.
Los anlisis del usuario tienen que ser descritos
en trminos que los usuarios y otros diseadores
puedan entender.
Escenarios donde se describe episodios tpicos
de uso, es una manera de describir estos
anlisis.
12/05/16
744
Escenario de interaccin
de usuario
Jane es un estudiante de Estudios Religiosos y est trabajando en
un ensayo en la arquitectura india y cmo ha sido influenciado por
las prcticas religiosas. Para ayudarse a entender esto, le gustara
acceder a algunos cuadros de detalles en los edificios notables,
pero no puede encontrar nada en su biblioteca local.
Ella se acerca al bibliotecario de este tema para discutir sus
necesidades y l le sugiere algunas condiciones de bsqueda que
podran usarse. Tambin le hace pensar en algunas bibliotecas en
Nueva Delhi y Londres que podran tener este material para que
ellos registren los catlogos de la biblioteca y hacen algn uso
escrutador en estas condiciones. Ellos encuentran algn material
de la fuente y solicitan fotocopias de los cuadros con detalle
arquitectnico y que pueden ser ser enviados directamente por
correo a Jane.
12/05/16
745
Requerimientos desde el
escenario
Los
usuarios pueden no ser conscientes de los

trminos de bsqueda apropiadas, de modo que
hay necesidad de una forma de ayudarlos para
escoger estos trminos.
Los usuarios tienen que poder seleccionar las
colecciones para investigar.
Los usuarios necesitan poder llevar a cabo las
bsquedas y copias de la demanda del material
pertinente.
12/05/16
746
Tcnicas de anlisis
Anlisis
de tareas
Modelar los pasos involucrados en completar
una tarea.
Entrevistas y encuestas
Preguntar a los usuarios acerca del trabajo que
hacen.
Etnografa
Observar al usuario en su trabajo.
12/05/16
747
Anlisis de las tareas jerrquicas

Recuperarlos
los
Recuperar
cuadrosde
de
cuadros
bibliotecas
bibliotecas
remotas
remotas
Hacer 1, 2, 3 hasta encontrar los cuadros, 4
1
Describir
Describir
posibles
posibles
fuentes
fuentes
Establecer
Establecer
trminosde
de
trminos
bsqueda
bsqueda
Bsqueda
Bsqueda
para
para
cuadros
cuadros
Demandade
de
Demanda
artculos
artculos
encontrados
encontrados
Hacer 3.1, 3.2, 3.3 hasta encontrar los cuadros,

3.4 si es necesario, 3.5
Seleccionar
3.1Seleccionar
librera
librera
Registrar
3.2Registrar
encatlogo
catlogo
en
Bsqueda
Bsqueda
para
cuadros
para cuadros
3.3
Modificar
Modificar
trminosde
de
trminos
bsqueda
bsqueda
3.4
3.5
Registrode
de
Registro
artculos
artculos
relevantes
relevantes
Hacer 3.3.1, 3.3.2, 3.3.3

Ingresar
Ingresar
trminosde
de
trminos
bsqueda
bsqueda
3.3.1
12/05/16
Iniciarlala
Iniciar
bsqueda
bsqueda
3.3.2
3.3.3
Revisar
Revisar
los
los
resultados
resultados
748
Entrevista
Disear
entrevistas
semiestructuradas
basadas en preguntas abiertas.
Los
usuarios pueden, entonces, proporcionar

informacin que ellos piensan que es esencial; no
slo informacin que se ha pensado en recolectar.
Las entrevistas en grupo o grupos orientados
(focus group) permiten a los usuarios discutir lo
que ellos hacen entre s.
12/05/16
749
Etnografa
Involucra
a un observador externo que mira el

trabajo de los usuarios y los cuestiona de una
manera no escrita sobre su trabajo.
Valioso porque muchas tareas del usuario son
intuitivas y ellos encuentran stos muy difciles
de describir y explicar.
Tambin ayudan a entender el papel social y
organizacional que influencian en el trabajo.
12/05/16
750
Registros etnogrficos
El control de trfico areo involucra varias series de controles dnde se
localizan las series que controlan sectores adyacentes de espacio areo
fsicamente localizados cerca de uno a otro. Los vuelos en un sector son
representados por tiras del papel que son colocados en las perchas de
madera en un orden que refleja su posicin en el sector. Si no hay bastantes
hendeduras en la percha (es decir cuando el espacio areo est muy
ocupado), los controladores extienden las tiras fuera del escritorio delante
de la percha.
Cuando nosotros estbamos observando a los controladores, notamos que
ellos regularmente han echado una mirada a las perchas de tiras en el
sector adyacente. Nosotros sealamos esto a ellos y les preguntamos por
qu hacan esto. Ellos contestaron que, si el controlador adyacente tiene
tiras en su escritorio, entonces esto significa que ellos tendrn muchos
vuelos que entran en su sector. Ellos, por consiguiente, intentaron aumentar
la velocidad de avin en el sector 'espacio limpio" para el avin entrante .
12/05/16
751
Las visiones de la
etnografa
Los
controladores tenan que ver todos los

vuelos en un sector. Por consiguiente los
despliegues de
desplazamiento dnde los
vuelos desaparecen fuera de la cima o fondo del
despliegue deben ser evitados.
La interfaz deba tener, alguna manera de
decirles a los controladores, cuntos vuelos
estaban en los sectores adyacentes, para que
ellos pudieran planear su trabajo.
12/05/16
752
Prototipado de la interfaz
de usuario
El objetivo de prototipado es permitir a los usuarios

ganar la experiencia directa con la interfaz.
Sin tal experiencia directa, es imposible juzgar la utilidad
de una interfaz.
El prototipado puede ser un proceso de dos fases:
Tempranamente en el proceso, los prototipos en papel
pueden ser utilizados;
El diseo es entonces refinado
y prototipos
automatizados cada vez ms sofisticados son
desarrollados.
12/05/16
753
Prototipado en papel
Trabajar
a travs de escenarios que usan

bocetos de la interfaz.
Usar una sinopsis para presentar una serie
de interacciones con el sistema.
El prototipado en papel es una manera
eficaz de obtener las reacciones del
usuario para una propuesta de diseo.
12/05/16
754
Tcnicas de prototipado
Prototipado
basado en guiones
Desarrollar un conjunto de guiones y pantallas usando

una herramienta como Macromedia Director. Cuando
el usuario interacta con ellos, la pantalla cambia al
prximo despliegue.
Programacin
Usar un lenguaje diseado para desarrollo rpido tal

como Visual Basic. Ver el Captulo 17.
Prototipado
12/05/16
visual
basado en Internet
Usar un navegado de la Web y guiones asociados.

755
Evaluacin de la interfaz de
usuario
Alguna
evaluacin de un diseo de interfaz de

usuario debe llevarse a cabo para evaluar su
conveniencia.
La evaluacin a escala completa es muy costosa
e impracticable para la mayora de sistemas.
Idealmente, una interfaz debe ser evaluada en
contraste a una especificacin de utilidad. Sin
embargo,
esto
es
raro
para
tales
especificaciones a ser producidas.
12/05/16
756
Atributos de utilidad
Atributo
Descripcin
Aprendibilidad
Cunto tiempo toma a un nuevo usuario

ponerse productivo con el sistema?
Velocidad
operacin
de Cun bien responde el sistema en

cuanto a la prctica de trabajo del
usuario?
Robustez
Cun tolerante es el sistema con los

errores del usuario?
Recuperabilidad Cun bueno es el sistema para

recuperarse de los errores del usuario?
Adaptabilidad
12/05/16
Cun estrechamente est el sistema

ligado a un solo modelo de trabajo?
757
Tcnicas de evaluacin
simple
Cuestionarios
para
la
retroalimentacin
del
usuario.
Grabacin de video del uso de un sistema y la
subsiguiente evaluacin de la cinta.
Instrumentacin de cdigo para recolectar
informacin acerca de la facilidad de uso y
errores de usuario.
La provisin de cdigo en el software para
recolectar en lnea, la retroalimentacin del
usuario.
12/05/16
758
Puntos clave
12/05/16
Los principios de diseo de interfaz de usuario deben

servir como gua para el diseo de interfaces de
usuario.
Los estilos de interaccin de usuario incluyen
manipulacin directa, sistemas de men, llenado de
formularios, lenguajes de comandos y lenguaje natural.
Los despliegues grficos deben ser usados para
presentar tendencias y valores aproximados. Los
despliegues digitales cuando la precisin es requerida.
El color debe ser usado econmica y consistentemente.
759
Puntos clave
El proceso de diseo de la interfaz de usuario involucra

anlisis del usuario, prototipado del sistema y la evaluacin
del prototipo.
El objetivo del anlisis del usuario es sensibilizar a los
diseadores de las maneras como realmente trabajan los
usuarios.
Un prototipo de IU debe ser un proceso organizado con
prototipos de papel tempranos usados como una base para
prototipos automatizados de la interfaz.
Las metas de la evaluacin de la IU son obtener la
retroalimentacin en como mejorar el diseo de la interfaz y
para evaluar si la interfaz rene los requerimientos de utilidad.
12/05/16
760
Captulo 17
Desarrollo rpido
de software
12/05/16
761
Objetivos
Explicar
cmo un proceso de desarrollo iterativo,

incremental lleva a la entrega rpida de software
ms til
Discutir la esencia de los mtodos de desarrollo
giles
Explicar
los principios y prcticas de la
programacin extrema
Explicar los roles del prototipado en el proceso
de software
12/05/16
762
Tpicos cubiertos
Mtodos
giles
Programacin extrema
Desarrollo rpido de aplicaciones
Prototipado de software
12/05/16
763
Desarrollo rpido de
aplicaciones
Debido
a los ambientes de negocios rpidamente

cambiantes, los negocios tienen que responder a
las nuevas oportunidades y la competencia.
Esto requiere de software, desarrollo rpido y la
entrega no es, a menudo, el requerimiento ms
crtico para los sistemas de software.
Los negocios pueden estar dispuesto a aceptar
software de baja calidad si la entrega rpida y si
la funcionalidad esencial es posible.
12/05/16
764
Requerimientos
Debido
a los ambientes cambiantes, es, a

menudo, imposible arribar a un conjunto estable
y consistente de requerimientos.
Por consiguiente el modelo de cascada de
desarrollo es impracticable y una aproximacin
de desarrollo basado en una especificacin
interactiva y entrega es el nico camino para
entregar software rpidamente.
12/05/16
765
Caractersticas del proceso

DRA
Los procesos de especificacin, diseo e
implementacin son concurrentes. No hay
especificacin detallada y la documentacin del
diseo es minimizada.
El sistema es desarrollado en una serie de
incrementos. Los usuarios finales evalan cada
incremento y hacen propuestas para incrementos
posteriores.
Las interfaces de usuarios del sistema son
normalmente desarrollados usando un sistema de
desarrollo interactivo.
12/05/16
766
Un proceso de desarrollo
interactivo
Definirlos
los
Definir
entregablesdel
del
entregables
sistema
sistema
Especificarlos
los
Especificar
incrementos
del
incrementos del
sistema
sistema
Disearlala
Disear
arquitectura del
arquitectura del
sistema
sistema
Construirlos
los
Construir
incrementosdel
del
incrementos
sistema
sistema
Validar
Validar
los
los
incrementos
incrementos
Validar
Validar
elel
sistema
sistema
Integrar
Integrar
los
los
incrementos
incrementos
NO
Sistema
Sistema
final
final
entregado
entregado
12/05/16
SI
El
El
sistema
sistema
est
est
completo?
completo?
767
Ventajas del desarrollo

incremental
Entrega
acelerada de servicios del cliente.

Cada incremento entrega la funcionalidad de
prioridad ms alta al cliente.
Compromiso del cliente con el sistema. Los
usuarios tienen que ser involucrados en el
desarrollo, lo cual significa que el sistema ms
capaz de reunir sus requerimientos y que los
usuarios se compromete ms al sistema.
12/05/16
768
Problemas con el desarrollo

incremental
Problemas de gestin
El progreso puede ser difcil de juzgar y los problemas difciles de
encontrar porque no hay ninguna documentacin para demostrar lo
que se ha hecho.
Problemas contractual
El contrato normal puede incluir una especificacin; sin una
especificacin, diferentes formas de contrato tienen que ser
usadas.
Problemas de validacin
Sin una especificacin, contra qu se est probando se el
sistema?
Problemas de mantenimiento
El cambio incesante tiende a adulterar la construccin de la
estructura del software, resulta ms caro cambiar y evolucionar
para reunir los nuevos
requerimientos.
12/05/16
769
Prototipado
Para
algunos sistemas grandes, el desarrollo

iterativo incremental y entrega puede ser
impracticable; esto es verdad especialmente
cuando mltiples equipos trabajan en diferentes
sitios.
El prototipado, donde un sistema experimental es
desarrollado como una base para la formulacin
de requerimientos puede se usado. Este sistema
se lanza cuando la especificacin del sistema ha
sido convenida.
12/05/16
770
Prototipado y desarrollo
incremental
Desarrollo
Desarrollo
incremental
incremental
Perfilde
delos
los
Perfil
requerimientos
requerimientos
Prototipadode
de
Prototipado
unamanera
manera
una
12/05/16
Sistemade
de
Sistema
entrega
entrega
Prototipo
Prototipo
ejecutable ++
ejecutable
Especificacindel
del
Especificacin
sistema
sistema
771
Conflicto de objetivos
El
objetivo del desarrollo incremental es la

entrega de un sistema que funciona a los
usuarios finales. El desarrollo empieza con esos
requerimientos que son mejor entendidos.
El objetivo del prototipado desechable es
validar o derivar los requerimientos del sistema.
El proceso de prototipado empieza cuando esos
requerimientos son pobremente entendidos.
12/05/16
772
Mtodos giles
El descontento con todo los mtodos de diseo arriba
mencionados llev a la creacin de los mtodos giles.
Estos mtodos destacan:
Enfoque en el cdigo, en lugar del diseo;
Estn basados en la aproximacin iterativa para el
desarrollo de software;
Se piensa en la entrega de software que funciona
rpidamente y evolucionar rpidamente para reunir los
requerimientos cambiantes.
Los
mtodos giles son probablemente los ms
adecuados para pequeos /medios sistemas de negocios
clasificados por su tamao, o productos para PC.
12/05/16
773
Principios de mtodos
giles
Atributo
Involucrar
cliente
Entrega
incremental
Descripcin
al El cliente debe ser involucrado estrechamente a lo largo del
proceso de desarrollo. Su papel es proporcionar y priorizar los
nuevos requerimientos del sistema y evaluar las iteraciones del
sistema.
El software se desarrolla en incrementos con el cliente que
especifica los requerimientos a ser incluidos en cada incremento.
Las personas Las habilidades del equipo de desarrollo deben ser reconocidas y
no procesan
deben explotarse. El equipo debe salirse de lo habitual para
desarrollar sus propias maneras de trabajar sin procesos
prescriptivos.
Adaptacin al Esperar los requerimientos del sistema para cambiar y disear el
cambio
sistema para que pueda acomodarse a estos cambios.
Mantener la Enfocar la simplicidad en el software a desarrollarse y en el
simplicidad
proceso de desarrollo usado. Dondequiera que sea posible,
trabajar activamente para eliminar la complejidad del sistema.
12/05/16
774
Problemas con los

mtodos giles
Puede ser difcil de mantener el inters de clientes que
estn involucrados en el proceso.
Los miembros del equipo pueden ser inaptos para la
intensa participacin que caracteriza los mtodos
giles.
La priorizacin de cambios puede ser difcil cuando hay
mltiples involucrados (stakeholders).
Mantener la simplicidad requiere de trabajo extra.
Los contratos pueden ser un problema como con otras
aproximaciones al desarrollo iterativo.
12/05/16
775
Programacin extrema
Quizs el mejor conocido y el ms usado mtodo gil.

La Programacin Extrema (XP) toma una aproximacin
extrema para el desarrollo iterativo.
Pueden ser construidas nuevas versiones varias
veces por da;
Los incrementos y entregas para clientes cada dos
semanas;
Las pruebas deben ejecutarse para cada producto y
cada producto se acepta slo si han superado la
prueba suficientemente.
12/05/16
776
El ciclo de lanzamiento XP
Historiasde
de
Historias
usuarioselectas
selectas
usuario
paraeste
este
para
lanzamiento
lanzamiento
Evaluacin
Evaluacin
delsistema
sistema
del
12/05/16
Defectosde
de
Defectos
historiaspara
para
historias
tareas
tareas
Lanzamiento
Lanzamiento
delsoftware
software
del
Lanzamiento
Lanzamiento
delplan
plan
del
Desarrollo
Desarrollo
/integracin/prueba
/prueba
/integracin
delsoftware
software
del
777
Prcticas de programacin
extrema 1
Planificacin
incremental
Se graban los requerimientos en las Tarjetas de Historia y las

Historias que deben
ser incluidas en un lanzamiento son
determinados por el tiempo disponible y su prioridad relativa. Los
diseadores interrumpen estas Historias en el desarrollo de
"Tareas".
Pequeos
lanzamientos
La utilidad minimal de un conjunto de funcionalidades que

proporcionan el valor comercial se desarrolla primero. Los
lanzamientos del sistema son frecuentes e incrementalmente
agregan la funcionalidad al primer lanzamiento.
Diseo simple
Bastante diseo se lleva a cabo para reunir los requerimientos

actuales y ninguno ms.
El
primer Un framework de prueba de unidad automatizada se usa para
escribir las pruebas para un nuevo pedazo de funcionalidad,
desarrollo
antes que esa funcionalidad sea implementada.
Refactorizaci
n
12/05/16
Todos los desarrolladores estn esperado para refactorizar el

cdigo continuamente para que lo ms pronto posible se
encuentren las mejoras del cdigo. Esto permite guardar el
cdigo simple y mantenible.
778
Prcticas de programacin
extrema 2
Programacin
por pares
Los diseadores trabajan por pares, verificando el trabajo uno del

otro y proporcionando apoyo para hacer siempre un trabajo
bueno.
Propiedad
colectiva
El trabajo de los pares de desarrolladores en todas las reas del

sistema, para que no haya islas de desarrollo especializado y
todos los desarrolladores poseen todo el cdigo. Cualquiera
puede cambiar algo.
Integracin
continua
En cuanto el trabajo de una tarea est completo se integra al

sistema entero. Despus de cualquier integracin, toda las
unidades del sistema debe pasar por pruebas..
Paso sustentable
Las grandes cantidades de horas extras no son consideradas

aceptables como efecto neto, es a menudo para reducir la calidad
del cdigo y el termino medio de productividad
Cliente en el sitio
Un representante de los usuarios finales del sistema (el Cliente)

debe estar a tiempo completo disponible para el equipo de XP. En
un proceso de la programacin extrema, el cliente es un miembro
del equipo de desarrollo y es responsable para traer los
requerimientos del sistema al equipo para la implementacin.
12/05/16
779
XP y los principio giles
El desarrollo incremental es soportado a travs de

pequeos y frecuentes lanzamientos del sistema.
El cliente involucrado significa el compromiso del cliente
a tiempo completo con el equipo.
Las personas no procesan por pares de programadores,
propiedad colectiva, y un proceso que evita las horas de
trabajo largas.
El cambio es soportado a travs de lanzamientos del
sistema regulares.
El mantenimiento de simplicidad a travs del la
constante refactorizacin de cdigo.
12/05/16
780
Escenarios de
requerimientos
En
XP, los requerimientos de usuario son

expresados como escenarios e historias de
usuario.
Estos son escrito en tarjetas y el equipo de
desarrollo lo parte en tareas de implementacin.
Estas tareas son la base del horario y las
estimaciones del costo.
El cliente escoge las historias para la inclusin en
el prximo lanzamiento basado en sus
prioridades y las estimaciones del programa.
12/05/16
781
Tarjeta de historia para

transmisin de documento
Bajando e imprimiendo un artculo
Primero, se selecciona el artculo de una lista del despliegue. Entonces
se tiene que decir al sistema cmo se pagar por l - o puede ser un a
travs de una suscripcin, a travs de una cuenta de la compaa o por
tarjeta del crdito.
Despus de esto, usted recibe los derechos de propiedad literaria del
sistema para llenar, y, cuando ha cumplido con esto, el artculo
transmite la necesidad hacia su computadora.
Usted escoge una copiadora y una copia del artculo entonces ser
impresa. Usted comunicar al sistema que la impresin ha terminado
por completo.
Si el artculo es un artculo de slo impresin, usted no puede guardar
la versin de PDF porque se anula automticamente de su
computadora.
12/05/16
782
XP y cambio
La sabidura convencional en la ingeniera de software
disear para el cambio. Es que los valores del tiempo
consumido y el esfuerzo que se anticipan a cambios
como estos, reducen los costos tardios en el ciclo de
vida.
XP, sin embargo, sostiene que esto no vale la pena,
cuando los cambios no puede preverse fiablemente.
Ms bien, propone la mejora
constante del cdigo
(refactorizacin) para hacer los cambios ms
fcilmente cuando ellos tienen que implementarse.
12/05/16
783
Pruebas en XP
Desarrollo
de primera prueba.
Desarrollo de pruebas incrementales desde
escenarios.
Involucrar al usuario en el desarrollo de pruebas
y validacin.
Los enseres de prueba automatizada son usadas
para ejecutar cada vez que un nuevo
lanzamiento se construye.
12/05/16
784
Tarjetas de tarea para

transmisin de documento
Tarea 1: Implementar el flujo de trabajo principal
Tarea 2: Implementar el catlogo del artculo y seleccin
Tarea 3: Implementar la coleccin de pago
El pago puede ser hecho de 3 maneras. El usuario selecciona
una de las maneras de pagar. Si el usuario tiene una
suscripcin de librera, entonces puede ingresar las clave de
suscripcin
que
ser
verificada
por
el
sistema;
alternativamente puede ingresar un nmero de cuenta
organizacional. Si es vlido una nota con el costo del artculo
ser enviado por correo a esa cuenta. Finalmente pueden
ingresar 16 dgitos del nmero de cuenta de una tarjeta de
crdito y la fecha de vencimiento. Este ser revisado para
validar y si es valido la nota del costo ser enviado por correo
a la cuenta de la tarjeta de crdito.
12/05/16
785
Descripcin de caso de
prueba
Tarea 4: Validacin de la tarjeta de crdito
Entrada:
Una cadena que representa el nmero de cuenta de la tarjeta de crdito y dos
enteros que representan el mes y el ao de expiracin de la tarjeta.
Pruebas:
Revisar que todos los bytes de la cadena sean dgitos.
Revisar que el mes este entre 1 y 12 y que el ao sea mayor o igual al ao en
curso.
Usando los 4 primeros dgitos del nmero de la tarjeta de crdito revisar que
el emisor de la tarjeta es vlido, buscando la tabla de emisores de tarjeta.
Revisar la validez de la tarjeta de crdito sometiendo el nmero de tarjeta y la
informacin de la fecha de expiracin del emisor de la tarjeta.
Salida:
OK en el mensaje de error, indica que la tarjeta no es vlida.
12/05/16
786
Desarrollo de primera prueba

Escribir las pruebas antes que el cdigo clarifique los
requerimientos a ser implementados.
Las pruebas son escritas como programas en lugar de
los datos de modo que puedan ejecutarse
automticamente. La prueba incluye una revisin de
que se ha ejecutado correctamente.
Todas
las pruebas previas y nuevas son
automticamente ejecutadas cuando una nueva
funcionalidad es aadida. As se verifica que la nueva
funcionalidad no introduce errores.
12/05/16
787
Programacin por pares
En XP, los programadores trabajan por pares,

sentndose juntos para desarrollar cdigo.
Esto ayuda a desarrollar una propiedad comn del
cdigo y extender el conocimiento a travs del equipo.
Sirve como un proceso de revisin informal puesto que
cada lnea de cdigo ha sido mirado por ms de una
persona.
Alienta la refactorizacin de modo que todo el equipo
puede beneficiarse con esto.
Las mediciones sugieren que la productividad del
desarrollo con la programacin por pares es similar a la
de dos personas que trabajan independientemente.
12/05/16
788
Desarrollo rpido de
aplicaciones
Los
mtodos giles han recibido mucha atencin,

pero otras aproximaciones para el desarrollo
rpido de aplicaciones han sido usados durante
muchos aos.
Estas
son
diseadas
para
desarrollar
aplicaciones de negocios de datos intensivos y
confiar en la programacin y presentacin de
informacin desde una base de datos.
12/05/16
789
Herramientas del ambiente

DRA
Lenguaje
de programacin de base
de datos
Generador de interfaz
Enlace con aplicaciones para oficina
Generador de informes
12/05/16
790
Un ambiente DRA
Generadorde
de
Generador
interfaz
interfaz
Sistemasde
de
Sistemas
Oficina
Oficina
Lenguajede
de
Lenguaje
programacinde
de
programacin
BD
BD
Generadorde
de
Generador
informes
informes
Sistemade
degestin
gestinde
debases
basesde
dedatos
datos
Sistema
Ambiente del desarrollo rpido de

aplicaciones
12/05/16
791
Generacin de interfaz
Muchas aplicaciones estn basadas alrededor de formas

complejas y el desarrollo manual de estas formas es una
actividad que consume tiempo.
Los ambientes de DRA incluyen el soporte para
generacin de pantallas que incluye:
Definicin de formularios interactivos usando tcnicas
de arrastrar y soltar;
Enlace de formularios donde la secuencia de
formularios para ser presentadas est especificada;
Verificacin de los formularios cuando se definen
rangos permitidos en los campos del formulario.
12/05/16
792
Programacin visual
Los
lenguajes de guiones tales como Visual

Basic soportan programacin visual donde el
prototipo es desarrollado por creacin de una
interfaz de usuario a partir de artculos
estndares y componentes asociados con esos
artculos.
Existe una librera grande de componentes para
dar soporte este tipo de desarrollos.
Estos pueden ser adecuados para satisfacer los
requerimientos de una aplicacin especfica.
12/05/16
793
Programacin visual con reuso

Componente
Componente
demen
men
de
Componente
Componente
defecha
fecha
de
Archivo
Editar
Ver
Configurar
Opciones
12 de enero, 2006
Guin que
Guin que
verificarango
rango
verifica
Ayuda
General
ndice
3.876
Componente
Componente
de aviso al
de aviso al
usuario++
usuario
Guin
Guin
Componente
Componente
dedibujo
dibujo
de
Canvas
Canvas
Componentede
de
Componente
despliegue de rbol
despliegue de rbol
12/05/16
794
Problemas con el
desarrollo visual
Dificultad
para coordinar el desarrollo

basado en equipo.
Ninguna arquitectura explcita del sistema.
Dependencias complejas entre las partes
de un programa pueden causar problemas
de mantenimiento.
12/05/16
795
Reuso de COTS
Un
acercamiento eficaz al desarrollo rpido es

para configurar y ligar con sistemas existentes
fuera del anaquel.
Por
ejemplo, un sistema de gestin de
requerimientos podra construirse usando:
12/05/16
Una base de datos para almacenar requerimientos;

Un procesador de textos para capturar requerimientos
y un formato de informes;
Una hoja de clculo para gestin de trazabilidad.
796
Documentos del compuesto

Para
algunas aplicaciones, un prototipo puede

crearse desarrollando un documento compuesto.
Este es un documento con elementos activos (como
una hoja de clculo) que permite clculos del
usuario.
Cada elemento activo tiene una aplicacin asociada
que se invoca cuando ese elemento se selecciona.
El propio documento es el integrador para las
aplicaciones diferentes.
12/05/16
797
Vinculacin de la aplicacin
Documentos del compuesto
Texto
Texto11
Tabla
Tabla11
Tabla
Tabla22
Texto
Texto44
Procesador
Procesadorde
de
textos
textos
12/05/16
Texto
Texto22
Texto
Texto33
Sonido
Sonido22
Hoja
Hojade
de
clculo
clculo
Sonido
Sonido11
Texto
Texto 55
Ejecutor
Ejecutorde
de
audio
audio
798
Prototipado de software
Un prototipo es una versin inicial de un sistema usado

para demostrar conceptos y probar opciones de diseo.
Un prototipo puede ser usado en:
El proceso de ingeniera de requerimientos para
ayudar con la elicitacin de requerimientos y
validacin;
En los procesos de diseo para explorar opciones y
desarrollar un diseo de IU;
En el proceso de pruebas para correr pruebas de
fondo a fondo.
12/05/16
799
Beneficios del prototipado

Mejora
la utilidad del sistema.

Un partido ntimo para las necesidades
reales de los usuarios.
Mejora la calidad del diseo.
Mejora la mantenibilidad.
Reduce el esfuerzo de desarrollo.
12/05/16
800
Prueba fondo a fondo

Datos
Datosde
de
prueba
prueba
Prototipo
Prototipo
del
delsistema
sistema
Sistema
Sistemade
de
aplicacin
aplicacin
Comparador
Comparador
de
deresultados
resultados
Informe
Informede
de
resultados
resultados
12/05/16
801
El proceso de prototipado
Establecer
Establecerlos
los
objetivos
del
objetivos del
prototipo
prototipo
Definir
Definirlala
funcionalidad
funcionalidad
del
delprototipo
prototipo
Desarrollar
Desarrollar
elel
prototipo
prototipo
Plan
Plandel
del
prototipado
prototipado
Definicin
Definicindel
del
contorno
contorno
Prototipo
Prototipo
ejecutable
ejecutable
12/05/16
Evaluar
Evaluar
elel
prototipo
prototipo
Informe
Informede
de
evaluacin
evaluacin
802
Los prototipos desechables

Los
prototipos deben ser desechables despus

del desarrollo, de modo que ellos no son buena
base para un sistema de produccin:
12/05/16
Puede ser imposible para poner el sistema a punto

para reunir los requerimientos no funcionales;
Los prototipos son normalmente indocumentados;
La estructura del prototipo normalmente se degrada a
travs del cambio rpido;
El prototipo probablemente no reunir los estndares
de calidad organizacional normal.
803
Puntos clave
Una aproximacin iterativa para el desarrollo del

software lleva a la entrega rpida del software.
Los mtodos giles son mtodos de desarrollo iterativo
que apunta a reducir el desarrollo sobre la cabeza y as
producir software ms rpidamente.
La programacin extrema incluye prcticas como las
pruebas sistemticas, mejora continua y participacin
del cliente.
La aproximacin de pruebas en XP es un fuerza
particular donde pruebas ejecutables son desarrolladas
antes de que el cdigo sea escrito.
12/05/16
804
Puntos clave
Los ambientes del desarrollo rpido de aplicaciones
incluye lenguajes de programacin de bases de
datos, herramientas de generacin de formularios y
enlaces con aplicacin de oficina.
Un prototipo desechable es usado para explorar los
requerimientos y opciones de diseo.
Cuando se implementa un prototipo desechable,
empieza con los requerimientos que se entienda
menos; en desarrollo incremental; empieza con los
requerimientos bien entendidos.
12/05/16
805
Captulo 18
Reuso del
software
12/05/16
806
Objetivos
Explicar
los beneficios del reuso del software y

algunos problemas del reuso
Discutir las diferentes maneras de implementar el
reuso del software
Explicar como los conceptos de reuso pueden ser
representados como patrones o incluidos en los
generadores de programa
Discutir los COTS de reuso
Describir el desarrollo de lneas de producto de
software
12/05/16
807
Tpicos cubiertos
El
reuso del paisaje

Patrones de diseo
Reuso basado en generador
Frameworks de aplicacin
Reuso de sistemas de aplicacin
12/05/16
808
Reuso de software
En
ms disciplinas de ingeniera, los sistemas

son diseados por composicin de componentes
existentes que han sido usados en otros
sistemas.
La ingeniera de software ha sido enfocada en el
desarrollo original, pero ahora se reconoce que
para lograr un buen software, ms rpidamente y
con un menor costo, necesitamos adoptar
procesos basados en el reuso de software
sistemtico.
12/05/16
809
basada en el reuso
Reuso de sistemas de aplicacin

El total de un sistema de aplicacin puede ser reusado
incorporndolo sin cambios en otros sistemas (reuso de
COTS) o por desarrollo de familias de aplicaciones.
Reuso de componentes
Los componentes de una aplicacin desde un subsistema
para objetos singulares pueden ser reusados. Cubierto en
el captulo 19.
Objeto y reuso de funcin
Componentes de software que implementan un objeto solo
bien definido o una funcin puede ser reusada.
12/05/16
810
Beneficios del reuso 1

Confiabilidad El software reusado, que ha sido ensayado y probado en
sistemas activos, debe ser ms fidedigno que el nuevo
creciente
software. El uso inicial del software revela algn diseo y

fallas de implementacin. Estos son entonces fijados, y
de esa manera van reduciendo el nmero de fallas
cuando el software es reusado.
Riesgo
de Si el software existe, hay menos incertidumbre en los
costos de reusar este software que en los costos de
proceso
desarrollo. Este es un factor importante para la gestin
reducido
del proyecto, puesto que reduce el margen de error en la

estimacin del costo del proyecto . Esto es
particularmente
verdadero
cuando
se
reusan
componentes del software relativamente grandes como
los subsistemas.
Uso efectivo En lugar de especialistas de la aplicacin que hacen el

mismo trabajo en
proyectos diferentes, estos
de
especialistas especialistas pueden desarrollar software reusable que
encapsula su conocimiento.
12/05/16
811
Beneficios del reuso 2

Complacencia Algunos estndares, como los estndares de interfaz
de
los del usuario, pueden ser implementados, como un
estndares
conjunto de componentes reusables estndares. Por
ejemplo, si se implementan mens en unas interfaces
de usuario, usando componentes reusables, todas las
aplicaciones presentan la misma estructura de mens a
los usuarios. El uso de estndares en las interfaces de
usuario, mejora la confiabilidad, puesto que hay menor
probabilidad que los usuarios
cometan errores
cuando se les presenta una interfaz familiar.
El desarrollo Traer un sistema para comercializar lo ms pronto
acelerado
posible, es a menudo, ms importante que los costos de
desarrollo globales. Reusando el software, se puede
acelerar la produccin del sistema, porque el desarrollo
y el tiempo de validacin deben ser reducidos.
12/05/16
812
Problemas del reuso 1

Costos
de
mantenimien
to crecientes
Si el cdigo fuente de un sistema de software reusado o

componente no est disponible, entonces los costos de
mantenimiento pueden incrementarse, puesto que los
elementos reusados del sistema puede ponerse en
aumento incompatible con los cambios del sistema.
Falta
de Los conjuntos de herramientas CASE no pueden dar
soporte
de soporte al desarrollo con reuso. Puede ser difcil o
herramientas imposible de integrar estas herramientas con un sistema
de librera de componentes. El proceso del software

asumido por estas herramientas no puede tomar en
cuenta el reuso.
No inventar Algunos ingenieros del software, a veces, prefieren

aqu
el reescribir los componentes, cuando ellos creen que
pueden mejorar el componente reusable. Este es en
sndrome
parte, porque se tiene confianza y en parte tiene que ver
con el hecho de que se est escribiendo el software
original, y esto se ve como ms desafiante, que reusar el
software de otras personas.
12/05/16
813
Problemas del reuso 2

Creacin
y
mantenimiento
de
una
biblioteca
de
componentes
Si el cdigo fuente de un sistema de

software reusado o componente no est
disponible, entonces los costos de
mantenimiento pueden incrementarse,
puesto que los elementos reusados del
sistema puede ponerse en aumento
incompatible con los cambios del sistema.
Encontrar,
mientras
se
entienden
y
adaptan
los
componentes
reusables
Los componentes del software tienen que

ser descubiertos en una librera, entender y,
a veces, adaptar, para trabajar en un nuevo
ambiente. Los ingenieros deben estar
bastante seguros de hallar un componente
en la librera, antes de que ellos hagan que
rutinariamente se incluya una bsqueda del
componente, como parte de su proceso de
desarrollo normal.
12/05/16
814
El reuso de paisaje
Aunque
el reuso, se piensa a menudo

simplemente como el reuso de componentes del
sistema, hay muchas aproximaciones diferentes
para reusar eso que puede ser usado.
Reusar es posible en un rango de niveles, desde
funciones simples para completar los sistemas de
aplicacin.
El reuso de paisaje cubre el rango de tcnicas de
reuso posibles.
12/05/16
815
El reuso de paisaje
Patrones
de diseo
Framework de
componentes
Desarrollo basado
en componentes
Sistemas
orientados a
servicios
12/05/16
Lneas de producto
de aplicacin
La envoltura de
sistemas legados
Desarrollo de
software orientado
a aspectos
Integracin de
COTS
Generacin
de programas
Aplicaciones
verticales
configurables
Librera de
programas
816
Aproximaciones de reuso 1
Patrones de diseo Las abstracciones genricas que ocurren a travs de
aplicaciones son representadas como patrones de

diseo que muestran objetos abstractos y concretos e
interacciones.
Desarrollo basado Los sistemas son desarrollados integrando los

componentes (colecciones de objetos) que conforman
en componentes
los estndares del modelo de componentes. Esto se

cubre en el Captulo 19.
Framework
componentes
de Las colecciones de clases abstractas y concretas que
pueden adaptarse y pueden extenderse para crear los

sistemas de aplicacin.
Envoltura
de Los sistemas legados (ver Captulo 2) que pueden ser
"cubiertos" definiendo un conjunto de interfaces y
sistemas legados
proporcionando el acceso a stos sistemas legados a
travs de estas interfaces.
Sistemas
orientados
servicios
12/05/16
Los sistemas son desarrollados ligando servicios

que
pueden
ser
proporcionados
a compartidos
externamente.
817
Aproximaciones de reuso 2
Lneas
producto
aplicacin
de Un tipo de la aplicacin es generalizado alrededor de una

de arquitectura comn, para que pueda adaptarse a las
Integracin
COTS
de Los sistemas son desarrollados por integracin de
Aplicaciones
verticales
configuracin
Un sistema genrico es diseado para que pueda

de configurarse a las necesidades de los clientes del sistema
especfico.
Libreras
programas
de Las clases y bibliotecas de funciones que implementan
Generadores
programas
de Un sistema generador empotra conocimiento de unos
Desarrollo
software
12/05/16
orientado
aspectos
de Los componentes compartidos se entrelazan en una
diferentes maneras para diferentes clientes.

sistemas de aplicacin existentes.
las abstracciones comnmente usadas estn disponibles

para el reuso.
tipos particulares de aplicacin y puede generar sistemas
o fragmentos del sistema en ese dominio.
aplicacin, en los diferentes lugares cuando el programa

818
a se compila.
Factores de planificacin de
reuso
El
programa de desarrollo para el software.

La expectativa del tiempo de vida de software.
Los antecedentes, habilidades y experiencia del
La criticidad del software y sus requerimientos
no funcionales.
El dominio de aplicacin.
La plataforma de ejecucin para el software.
12/05/16
819
Reuso de conceptos
Cuando se reusa programas o componentes de diseo, se

tiene que seguir las decisiones de diseo hechas por el
desarrollador original del componente.
Esto puede limitar las oportunidades de reuso.
Sin embargo, una forma ms abstracta de reuso, es el
concepto de reuso cuando una aproximacin particular es
descrita en una manera de implementacin independiente y
una implementacin es entonces desarrollada.
Las dos principales aproximaciones para el reuso de
conceptos son:
Patrones de diseo;
Programacin generativa.
12/05/16
820
Patrones de diseo
Un
patrn de diseo es una manera de reuso de

un conocimiento abstracto acerca de un
problema y su solucin.
Un patrn es una descripcin de un problema y
la esencia de su solucin.
Debe ser lo suficientemente abstracto para ser
reusado en diferentes configuraciones.
Los modelos a menudo confan
en las
caractersticas del objeto, como la herencia y el
polimorfismo.
12/05/16
821
Elementos de un patrn
Nombre
Un identificador significativo del patrn.
Descripcin
del problema.
Descripcin de la solucin
No un diseo concreto, pero es una plantilla para una

solucin de diseo que pude ser instanciado de
diferentes maneras.
Consecuencias
12/05/16
Los resultados y los intercambios de la aplicacin del

patrn.
822
Mltiples despliegues
Asunto
Observador11
Observador
12/05/16
40
25
15
20
Observador22
Observador
823
El patrn del
observador
12/05/16
Nombre
Observador.
Descripcin
Separa el despliegue de estado de objetos desde el
mismo objeto.
Descripcin del problema
Usado cuando se necesita mltiples despliegues de
estado.
Descripcin de la solucin
Ver la transparencia con una descripcin UML.
Consecuencias
Las optimizaciones para reforzar el desempeo del
despliegue sonIng.impracticables.
824
El patrn del
observador
Asunto
Observador
Atar(Observador)
Desatar(Observador)
Notificar()
Actualizar()
Para todos los usuarios

permitidos
o -> Actualizar()
AsuntoConcreto
ObservadorConcreto
estadoAsunto
estadoObservador
DarEstado()
Devuelve
estadoAsunto
Actualizar()
estadoObservador =
Asunto -> DarEstado()
12/05/16
825
Reuso basado en
generador
Los generadores de programa involucran el reuso
de patrones estndar y algoritmos.
Estos
son incluidos en el generador y
parametrizados por los comandos del usuario.
Entonces se genera automticamente un
programa.
El reuso basado en generador es posible cuando
pueden identificarse las abstracciones del dominio
y su correspondencia con el cdigo ejecutable.
Un lenguaje de un dominio especfico se usa
componer y controlar estas abstracciones.
12/05/16
826
Tipos de generador de
programa
12/05/16
Tipos de generador de programa

Generador de aplicaciones para procesamiento de
datos de negocios;
Generador de analizador gramatical y de lxico para
procesamiento de lenguaje;
Generadores de cdigo en herramientas CASE.
El reuso basado en generadores es muy rentable, pero su
aplicabilidad est limitada para un nmero relativamente
pequeo de dominios de aplicacin.
Es ms fcil para los usuarios finales desarrollar programas
que usan los generadores comparados con otras
aproximaciones de reuso basados en componentes.
827
Reuso a travs de generacin

de programa
Descripcin
Descripcin
de
delala
aplicacin
aplicacin
Generador
Generadorde
de
programa
programa
Conocimiento
Conocimientodel
deldominio
dominio
del
delproblema
problema
12/05/16
Programa
Programa
generado
generado
Base
Base de
de
datos
datos
828
Desarrollo orientado a
aspectos
El desarrollo orientado a aspectos se dirige a un problema

mayor de ingeniera de software la separacin de intereses.
Las preocupaciones no estn a menudo asociadas
absolutamente con la funcionalidad de la aplicacin, pero
estn transversalmente cortados; por ejemplo, todos los
componentes pueden supervisar su propio funcionamiento,
todos los componentes pueden tener que mantener la
seguridad, etc.,
Las preocupaciones transversalmente cortadas son
implementadas como los aspectos y se entrelazan
dinmicamente en un programa. El cdigo concerniente es
reusar y el nuevo sistema se genera por el entrelazador del
aspecto.
12/05/16
829
El desarrollo orientado a
aspectos
Aspecto
Aspecto11
Aspecto
Aspecto22
Ingresar cdigo fuente

<estamento 1>
punto de unin 1
Generador de cdigo
Entrelazador
Entrelazador
de
deAspecto
Aspecto
<estamento 1>
Aspecto 1
<estamento 2>
<estamento 2>
punto de unin 2
Aspecto 2
12/05/16
830
Frameworks de aplicacin
Los
frameworks son un diseo de subsistema

compuesto de una coleccin de clases abstractas
y concretas y las interfaces entre ellas.
El subsistema es implementado por adicin de
componentes para llenar en partes del diseo y
por instanciacin de clases abstractas en el
framework.
Los frameworks son entidades moderadamente
grandes que pueden ser reusadas.
12/05/16
831
Clases de frameworks
Frameworks
Suporta el desarrollo de las infraestructuras de sistemas

tales como comunicaciones, interfaces de usuario y
compiladores.
Frameworks
12/05/16
de integracin de middleware
Estndares y clases que soportan comunicacin de

componentes e intercambio de informacin.
Frameworks
de infraestructura de sistemas
de aplicacin empresarial
Soporta el desarrollo de tipos especficos de aplicacin,

tales como telecomunicaciones o sistemas financieros.
832
Extendiendo de frameworks
Las frameworks son genricos y son extendidos para

crear una aplicacin ms especfica o subsistema.
La extensin del framework involucra
Adicin de clases concretas que heredan operaciones

desde clases abstractas en el framework;
Adicin de mtodos que son llamados en respuesta a
eventos que son reconocidos por el framework.
El problema con los frameworks es su complejidad

que significa que toman un largo tiempo usarlos
efectivamente.
12/05/16
833
Controlador del modelo

vista
El
framework de la infraestructura de sistema

para el diseo IGU.
Permite mltiples presentaciones de un objeto y
las
interacciones
separadas
con
estas
presentaciones.
El framework CMV involucra la instanciacin de
un nmero de patrones (como discutido antes
bajo el concepto de reuso).
12/05/16
834
Controlador del modelo

vista
Entradas del
usuario
Estado del controlador

Mtodos del controlador
Ediciones del
modelo
Mensajes de
modificacin
de las vistas
Estado del modelo
Estado de la vista
Mtodos de la vista
Consultas ya
actualizaciones
del modelo
Mtodos del modelo
12/05/16
835
Reuso de sistemas de
aplicacin
Involucra
el reuso de sistemas de
aplicacin enteras o por configuracin de
un sistema para un ambiente o por
integracin de dos o ms sistemas para
crear una nueva aplicacin.
Dos aproximaciones cubiertas aqu:
12/05/16
Integracin de producto COTS;

Desarrollo de lnea de producto.
836
Reuso de producto COTS
COTS - Commercial Off-The-Shelf systems= Stock

comercial disponible
Los sistemas COTS son normalmente usados en
sistemas de aplicacin completos que ofrecen un API
(Application Programming Interface = Interfaz de
Programas de Aplicacin).
Construyendo sistemas grandes por integracin de
sistemas COTS es nuevo es ahora una estrategia de
desarrollo viable para algunos tipos de sistemas tales
como sistema de comercio electrnico (E-commerce).
El beneficio clave es el desarrollo de aplicacin ms
rpido y normalmente bajos costos de desarrollo.
12/05/16
837
Opciones de diseo COTS
12/05/16
Qu productos COTS ofrecen la funcionalidad ms

adecuada?
Puede haber varios productos similares que pueden
usarse.
Cmo se intercambiarn los datos?
Los
productos individuales usan sus propias
estructuras de datos y formatos.
Qu aspectos del producto sern realmente usados?
La
mayora de los productos tienen ms
funcionalidad de la que se necesita. Se debe intentar
negar el acceso a la funcionalidad no usada.
838
Sistema de E-procuracin
Cliente
Sistemade
deCorreo
Correo
Sistema
Electrnico
Electrnico
Navegador
Navegador
delalaWeb
Web
de
Servidor
Sistemade
de
Sistema
Comercio
Comercio
Electrnico
Electrnico
Adaptador
Adaptador
Sistemade
deCorreo
Correo
Sistema
Electrnico
Electrnico
12/05/16
Sistemade
de
Sistema
Pedidoyy
Pedido
facturacin
facturacin
Adaptador
Adaptador
839
Productos COTS reusados

En el cliente, el correo electrnico estndar y los
navegadores de la Web son usados.
En el servidor, una plataforma de comercio electrnico tiene
que ser integrada con un sistema de clasificacin existente.
Esto involucra escritura de un adaptador de modo que
ellos pueden intercambiar datos.
Un sistema del correo electrnico tambin se integra para
generar el correo electrnico para los clientes. Esto
tambin exige un adaptador para recibir los datos de la
clasificacin y un sistema de facturacin.
12/05/16
840
Problemas de integracin de
los sistemas COTS
Falta de control sobre la funcionalidad y el desempeo

Los sistemas COTS pueden ser menos efectivos de lo
que parecen.
Problemas con la interoperabilidad de sistemas COTS
Diferentes sistemas COTS pueden tomar diferentes
asunciones, lo que significa que la integracin es difcil.
Ningn control sobre la evolucin de sistemas
Los vendedores de COTS y no lo usuarios del sistema
controlan la evolucin.
El soporte de los vendedores de COTS
Los vendedores de COTS no pueden ofrecer soporte
sobre el tiempo de vida del producto.
12/05/16
841
Lneas de producto de
software
Las lneas de producto de software o familias se

aplicaciones son aplicaciones con funcionalidad genrica
que pueden ser adaptadas y configuradas para su uso en
un contexto especfico.
La adaptacin puede involucrar:
Configuracin de componentes y sistemas;
Adicin de nuevos componentes para el sistema;
Seleccionando desde una librera de componentes
existentes;
Modificando
componentes para reunir nuevos
requerimientos.
12/05/16
842
Especializacin de producto COTS
Especializacin de plataforma
Diferentes versiones de la aplicacin son desarrolladas para
diferentes plataformas.
Especializacin del ambiente
Diferentes versiones de la aplicacin son creadas para
manejar diferentes ambientes de operacin, por ejemplo,
diferentes tipos de equipos de comunicacin.
Especializacin funcional
Diferentes versiones de la aplicacin son creadas para clientes
con diferentes requerimientos.
Especializacin de procesos
Diferentes versiones de la aplicacin son creadas para dar
soporte a diferentes procesos de negocios.
12/05/16
843
Configuracin de COTS
Configuracin
Un sistema genrico es configurado por conocimiento

encajado de los requerimientos de los clientes y
procesos de negocios. El software en si no se cambia.
Configuracin
12/05/16
del tiempo de despliegue
del tiempo de diseo
Un cdigo genrico comn es adaptado y cambiado

de acuerdo a los requerimientos de clientes
particulares.
844
Organizacin del sistema ERP

Herramientas
Herramientasde
de
planificacin
de
planificacin de
configuracin
configuracin
Sistema genrico PRE

Base
Basede
dedatos
datos
de
la
de la
configuracin
configuracin
Base
Basede
dedatos
datosdel
delsistema
sistema
12/05/16
845
Sistemas PRE
12/05/16
Un sistema de Planificacin de Recursos de la Empresa

(PRE) (ERP= Enterprise Resource Planning) es un
sistema genrico que da soporte a procesos comunes de
negocios como pedidos y facturacin, manufactura, etc.
Estos son muy ampliamente usados en las compaas
grandes - ellos representan probablemente la forma ms
comn de reuso de software.
El centro genrico es adaptado por inclusin de mdulos
e incorporando conocimiento de procesos de negocios y
reglas.
846
Configuracin del tiempo

de diseo
Las
lneas de producto de software que han

sido configuradas en tiempo de diseo son
instanciaciones
de
arquitecturas
de
aplicacin genrica como se discute en el
Captulo 13.
Normalmente los productos
genricos
emergen despus de la experiencia con
productos especficos.
12/05/16
847
Arquitecturas de lnea de
producto
Las
arquitecturas deben ser estructuradas

de tal manera que separa diferentes
subsistemas y les permite ser modificadas.
La arquitectura tambin debe separar
entidades y sus descripciones y los ms
altos niveles en que el sistema accede a
las entidades a travs de descripciones en
lugar de directamente.
12/05/16
848
Un sistema de gestin de
recursos
Interfaz
Interfaz de
de usuario
usuario
Autenticacin del
usuario
Gestin de
recursos
Entrega del
recurso
Control de poltica
de recursos
Gestin de
consultas
Asignacin de
recursos
Gestin de la transaccin
Base de datos del recurso
12/05/16
849
Despacho de vehculos
12/05/16
Un sistema de gestin de recurso especializado donde el

objetivo es asignar recursos (vehculos) para manejar
incidentes.
Las adaptaciones incluyen:
Al nivel de IU, hay componentes para el despliegue del
operador y comunicaciones;
Al nivel de gestin de I/O; hay componentes me manejan la
autenticacin, informe y planificacin de ruta;
Al nivel de gestin del recurso, hay componentes par
ubicacin de vehculos y despacho, estado del vehculo
manejado y registro de incidente;
La base de dato incluye equipo, vehculo y base de datos de
mapas.
850
Despacho de vehculos
Interfaz de sistema de
comandos
Interfaz de usuario
Autenticacin del
operador
Manejador del
estado del
vehculo
Base de datos
del equipo
12/05/16
Planificador de
mapa y ruta
Registrador del
incidente
Manejador
del evento
Despachador
del vehculo
Gestin de transacciones
Registro de
incidente
Generador de
informes
Base de datos
del vehculo
Generador de
consultas
Localizador
de vehculo
Base de datos
mapas
851
Desarrollo de instancia
del producto
Renegociar
Renegociarlos
los
requerimientos
requerimientos
Elicitar
Elicitarlos
los
requerimientos
requerimientos
de
delos
los
involucrados
involucrados
Elegir
Elegirlos
los
miembros
miembrosde
de
familia
ms
familia ms
adecuados
adecuados
Adaptar
Adaptaralal
sistema
sistema
existente
existente
12/05/16
Entregar
Entregarnueva
nueva
familia
familiade
de
miembros
miembros
852
Desarrollo de instancia
del producto
Elicitar los requerimientos del involucrado (stakeholder)
Usar miembro de la familia como un prototipo.
Elegir el miembro de familia ms adecuado
Hallar
el miembro de familia que mejor reuna los
requerimientos.
Renegociar los requerimientos
Adaptar los requerimientos como necesario para las
capacidades del software.
Adaptar el sistema existente
Desarrollar nuevos mdulos y realizar cambios para el
miembro de la familia.
Entregar el nuevo miembro de la familia
Documentar los rasgos calve para el desarrollo de miebro
extenso.
12/05/16
853
Puntos clave
12/05/16
Las ventajas del reuso son los bajos costos , desarrollo

rpido del software y ms bajos riesgos.
Los patrones de diseo son abstracciones de alto nivel
que documentan suficientemente las soluciones de
diseo.
Los generadores de programa tambin se preocupan por
el reuso del software los conceptos reusables son
incluidos en el sistema generador.
Los frameworks de aplicacin son colecciones de
objetos concretos y abstractos que son diseados para
el reuso a travs de la especializacin.
854
Puntos clave
El reuso de productos COTS se preocupa por el reuso

de grandes, sistemas de stock comercial disponible.
Los problemas de reuso de COTS incluyen la falta de
control sobre la funcionalidad, desempeo y evolucin,
y problemas con la interoperacin.
Los sistemas PRE son creados ERP por configuracin
de un sistema genrico con informacin acerca de los
negocios de los clientes.
Las lneas de producto de software son el desarrollo de
aplicaciones relacionadas alrededor de un centro
comn de funcionalidad compartida.
12/05/16
855
Captulo 19
Ingeniera del
software basada
en componentes
12/05/16
856
Objetivos
Explicar que la ISBC (Ingeniera de software basada en

componentes) [CBSE = Component-based software
engineering] se preocupa por el desarrollo de
componentes estandarizadas y la composicin de estos
en las aplicaciones
Describir los componentes y los modelos de
componentes
Mostrar las principales actividades en el proceso de la
ISBC
Discutir las aproximaciones para la composicin de
componentes y problemas que pueden levantarse
12/05/16
857
Tpicos cubiertos
Componentes
modelos
de
componentes
El proceso de ISBC
Composicin de componentes
12/05/16
858
Desarrollo basado en
componentes
La Ingeniera de software basada en componentes
(ISBC) es una aproximacin para el desarrollo de
software que confa en el reuso de software.
Emerge del fracaso del desarrollo orientado a
objetos para soportar el reuso efectivo. Las clases
de objetos singulares son tambin detallados y
especificados.
Los componentes son ms abstractos que las clases
de objetos y pueden considerarse que son los
proveedores de servicios autosuficientes.
12/05/16
859
Lo esencial de ISBC
Componentes
independientes especificados
por sus interfaces.
Estndares de componentes para facilitar la
integracin de componentes.
Middleware que provee de soporte para la
interoperatividad de componentes.
Un proceso de desarrollo que es engranado
para el reuso.
12/05/16
860
ISBC y principios de
diseo
Aparte
de los beneficios de reuso, la ISBC se

basa en principios de diseo de ingeniera de
software slidos:
12/05/16
Las componentes son independientes para que no

interfieran entre s;
Las implementaciones de componentes estn ocultas;
La comunicacin es a travs de interfaces bien
definidas;
Las plataformas de componentes son compartidas y
reducen los costos de desarrollo.
861
Problemas de la ISBC
Fidelidad
de componentes - cmo se puede

confiar en un componente sin el cdigo fuente
disponible?
Certificacin
de componentes - quin
certificar la calidad de los componentes?
Prediccin
de propiedades emergentes cmo las propiedades emergentes de
la
composicin de componentes pueden predecirse?
Los intercambios de requerimientos - cmo
hacemos el anlisis del intercambio entre los
rasgos de un componente y otro?
12/05/16
862
Componentes
Los componentes proporcionan un servicio sin

tener en cuenta dnde se est ejecutando el
componente o el lenguaje de programacin.
Un componente es una entidad ejecutable
independiente que puede componerse de
uno o mas objetos ejecutables;
La interfaz del componente es publicada y
todas las interacciones lo son a travs de la
interfaz publicada;
12/05/16
863
Definiciones de componente
Councill y Heinmann:
Un componente de software es un elemento del
software que conforma un modelo del componente y
puede
ser
desplegada
independientemente
y
compuesta sin la modificacin segn un estndar de
composicin.
Szyperski:
Un componente de software slo es una unidad de
composicin con las interfaces especificadas
contractualmente y las dependencias del contexto
explcitas. Un componente del software puede ser
desplegada independientemente y est sujeto a la
composicin de terceras partes.
12/05/16
864
El componente como
proveedor de servicio
El
componente es una entidad ejecutable

independiente. No tiene que ser compilado
entes de ser usado con otros componentes.
Los servicios ofrecidos por un componente
estn de hecho disponible a travs de una
interfaz y todas las interacciones del
componente tienen lugar a travs de esa
interfaz.
12/05/16
865
Caractersticas de
componente 1
Estandarizado
La estandarizacin de componentes significa que un

componente que es usado en un proceso de ISBC tiene
que conformar algn modelo de componentes
estandarizado. Este modelo puede definir interfaces de
componente, metadatos de componentes, composicin
y despliegue.
Independiente
Un componente debe ser independiente - debe ser

posible componer y desplegarlo sin tener que usar otros
componentes especficos. En situaciones dnde el
componente necesita servicios provedos externamente,
stos deben ser explcitamente colocados fuera de una
especificacin de interfaz "pedida".
Componible
Para que un componente sea componible, todas las

interacciones externas deben tener lugar a travs de las
interfaces pblicamente definidas para un componente.
Adems, debe proporcionar el acceso externo a la
informacin sobre s misma, as como sus mtodos y
atributos.
12/05/16
866
Caractersticas de
componente 2
Desplegable
Para ser desplegable, un componente tiene

que ser autnomo y debe poder operar como
una entidad autosuficiente, en alguna
plataforma de componente que implementa el
modelo de componente. Esto normalmente
significa
que
el
componente
es
un
componente binario que no tiene que ser
compilado antes de ser desplegado.
Documentado Los
componentes
tienen
que
ser
documentados totalmente para que los
usuarios potenciales del componente puedan
decidir si
ellos satisfacen o no sus
necesidades. La sintaxis e, idealmente, la
semntica de todas las interfaces del
componente tienen que ser especificadas.
12/05/16
867
Interfaces de componente
Proporcionar
interfaz
Definir
los
servicios
que
son
proporcionados por el componente a otros
componentes.
Requerir interfaz
Definir los servicios que especifican que
servicios pueden estar disponibles para el
componente a ejecutar como especificado.
12/05/16
868
Interfaces de componente
Requiere interfaz
Proporciona interfaz
Define los servicios

desde el ambiente de
los componentes que
usa
Componente
12/05/16
Define los
servicios que son
proporcionados
por el
componente a
otros
componentes.
869
Un componente de
recolector de datos
Requiere interfaz
Proporciona interfaz
agregarSensor
quitarSensor
iniciarSensor
pararSensor
gestinSensor
datosSensor
Recolector de
datos
probarSensor
inicializar
informe
listarTodo
12/05/16
870
Componentes y objetos
Los
componentes son entidades desplegables.

Los componentes no definen tipos.
La
implementaciones de componente son
opacas.
Los
componentes son independientes del
lenguaje.
Los componentes estn estandarizados.
12/05/16
871
Modelos de componentes
Un modelo de componente es una definicin de
estndares
para
la
implementacin
de
componentes, documentos y despliegue.
Ejemplos de modelos de componentes
Modelo EJB (Enterprise Java Beans)
Modelo COM+ ( modelo .NET)
Modelo se componente Corba
El modelo del componente especifica cmo deben
definirse las interfaces y los elementos que deben
ser incluidos en una definicin de la interfaz.
12/05/16
872
Elementos de un modelo
de componente
Adaptacin
Convencin de
nominacin
Documentacin
Composicin
Definicin
de interfaz
Especificar
la interfaz
Interfaces
Acceso a
metadatos
Embalaje
Informacin
de uso
Soporte de
evolucin
Despliegue
y uso
Modelo de componentes
12/05/16
873
Soporte middleware
Los modelos de componentes son la base para el

middleware que proporciona soporte para la ejecucin de
componentes.
Las implementaciones de componentes proporcionan:
Servicios de plataforma que permiten componentes
escritos de acuerdo al modelo para comunicar;
Servicios horizontales que son los servicios de aplicacin
independiente usados por diferentes componentes.
Para usar los servicios proporcionados por un modelo, los
componentes son desplegados en un contenedor. Esto es
un conjunto de interfaces usados para acceder a las
implementaciones de servicios.
12/05/16
874
Servicios del modelo de

componentes
Servicios horizontales
Gestin de
componentes
Gestin de
transacciones
Concurrencia
Persistencia
Gestin de
recursos
Seguridad
Servicios de plataforma
Direccionamiento
12/05/16
Definicin de
interfaz
Gestin de
excepcin
Comunicacin
de componentes
875
Desarrollo de
componentes para reuso
Los
componentes son desarrollados para una

aplicacin especfica normalmente tienen que ser
generalizados para hacerlos reusables.
Un componente es lo ms probablemente a ser
reusable si es asociado con una abstraccin de
dominio estable (objeto de negocios).
Por ejemplo, en un hospital las abstracciones son
asociados con el propsito fundamental
enfermeras, pacientes, tratamientos, etc.
12/05/16
876
Desarrollo de
componentes para reuso
12/05/16
Los componentes para reuso puede ser construidos

especialmente por generalizacin de componentes
existentes.
Reutilidad de componentes
Debe reflejar abstracciones de un dominio estable;
Debe ocultar la representacin de estado;
Debe ser tan independiente como sea posible;
Debe publicar excepciones a travs de la interfaz de
componente.
Hay un intercambio entre reutilidad y utilidad
Lo ms general la interfaz, lo mayor la reutilidad pero
es entonces de lo ms complejo y de lo menos usable.
877
Cambios para reutilidad

Quitar
los mtodos de aplicacin especficos.

Los cambios de nombre para hacerlo general.
Agregar mtodos para ensanchar la cobertura.
Hacer un consistente manejo de la excepcin.
Agregar una interfaz de configuracin para la
adaptacin del componente.
Integrar los componentes
requeridos para
reducir dependencias.
12/05/16
878
Componentes de un
sistema legado
Los
sistemas de legado existentes que cumplen

una funcin de negocio til pueden ser
reempaquetados como componentes de reuso.
Esto involucra la escritura que un componente de
la envoltura que implementa, proporciona y
requiere interfaces de acceso al sistema legal.
Aunque costoso, esto puede ser mucho menos
caro que la reescritura del sistema legal.
12/05/16
879
Componentes reusables
El
costo de componentes reusables puede ser

ms alto que el costo de equivalentes
especficos. Este costo de perfeccionamiento de
reutilidad extra debe ser una organizacin antes
que un costo del proyecto.
Componentes genricos pueden ser menos
eficientes en espacio y pueden tener el tiempo de
ejecucin ms largo que sus equivalentes
especficos.
12/05/16
880
El proceso de ISBC
12/05/16
Cuando se reusan componentes, esto es esencial para

hacer los intercambios entre los requerimientos ideales y
los servicios realmente proporcionados por componentes
disponibles.
Esto involucra:
Desarrollo de requerimientos del contorno;
Buscando componentes que entonces modifiquen los
requerimientos de acuerdo a funcionalidad disponible.
Buscando para encontrar de nuevo si existe buenos
componentes que renan los requerimientos revisados.
881
El proceso de ISBC
Requerimientos
Requerimientos
deentorno
entornodel
del
de
sistema
sistema
Diseo
Diseo
arquitectnico
arquitectnico
12/05/16
Identificar
Identificar
componentes
componentes
candidatos
candidatos
Modificarlos
los
Modificar
requerimientos
requerimientos
deacuerdo
acuerdoaa
de
componentes
componentes
descubiertos
descubiertos
Identificar
Identificar
componentes
componentes
candidatos
candidatos
Componer
Componer
componentes
componentes
paracrear
crearelel
para
sistema
sistema
882
El proceso de identificacin
de componentes
Bsquedade
de
Bsqueda
componentes
componentes
12/05/16
Seleccinde
de
Seleccin
componentes
componentes
Validacinde
de
Validacin
componentes
componentes
883
Problemas de identificacin
de componentes
Confianza. Usted necesita poder confiar en el proveedor de

un componente. A lo mejor, un componente no confiable puede
no operar como debe funcionar segn lo ha anunciado, y en el
peor de los casos puede abrir su brecha de seguridad.
Requerimientos. Diferentes grupos de componentes
satisfarn diferentes requerimientos.
Validacin.
La especificacin del componente puede no puede ser
demasiado detallado para permitir que las pruebas
comprensivas puedan ser desarrolladas.
Los componentes pueden no tener la funcionalidad
deseada. Cmo puede usted probar que esto no interferir
con su aplicacin?
12/05/16
884
Falla del lanzador de

Ariane
En 1996, el 1er vuelo de prueba del cohete Ariane 5
acab en el desastre cuando el lanzador estuvo
fuera de control 37 segundos despus del despegue.
El problema se debi a un componente reusado
desde una versin anterior del lanzador (Sistema de
Navegacin Inercial) que fall porque las asunciones
se hicieron cuando ese componente fue desarrollado
no para sostener a Ariane 5.
La funcionalidad que falla en este componente no
fue requerida en el Ariane 5.
12/05/16
885
Composicin de
componentes
El
proceso de ensamblaje de componentes

para crear un sistema.
La composicin involucra los componentes
entre s y con la infraestructura de
componentes.
Normalmente usted tiene que escribir
"pegando cdigo" para integrar los
componentes.
12/05/16
886
Tipos de composicin
Composicin secuencial donde la composicin de
componentes son ejecutados en secuencia. Esto
involucra la composicin para proporcionar interfaces
para cada componente.
Composicin jerrquica donde un componente
llama los servicios de otro. El proporciona una interfaz
de un componente y esta requiere la interfaz de otro.
Composicin aditiva donde las interfaces de dos
componentes se ponen juntas a crear un nuevo
componente.
12/05/16
887
Tipos de composicin
A
A
A
B
(a)
12/05/16
(b)
(c)
888
Incompatibilidad de interfaz
Incompatibilidad
de parmetro donde las

operaciones tienen el mismo nombre pero son de
diferentes tipos.
Incompatibilidad
de operacin donde los
nombres de la operacin en las interfaces son
diferentes.
Incompletitud de operacin donde la interfaz
proporcionada de un componente es un
subconjunto que requiere la interfaz de otro.
12/05/16
889
Componentes
incompatibles
fonoBaseDatos(comando de cadena)
Ubicacin de cadena (cadena pn)
Propietario de cadena (cadena pn)
halladorDireccin
Cadena propiedadTipo(cadena pn)
mapaBD(comando de cadena)
despliegaMapa (cadena cdigo
postal, escala)
mapeador
12/05/16
imprimeMapa (cadena cdigo postal,

escala)
890
Componentes de adaptador
Dirigir
el problema de incompatibilidad del

componente reconciliando las interfaces de los
componentes que estn compuestos.
Diferentes tipos de
adaptador son requeridos
dependiendo del tipo de composicin.
Un halladorDireccin y un componente mapeador
pueden ser compuestos a travs de un adaptador
que despeja el cdigo postal de una direccin y lo
pasa a un componente del mapeador.
12/05/16
891
Composicin a travs de
un adaptador
El
componente cdigoPostalDespojador es el
adaptador que facilita la composicin secuencial
de halladorDireccin
y componentes del
mapeador.
direccin = halladorDireccin.ubicacin (nmeroTelefnico);

cdigoPostal = cdigoPostalDespojador.obtenerCdigoPostal (direccin);
mapeador.desplegarMapa(postalCdigo, 10000)
12/05/16
892
Adaptador para el
recolector de datos
iniciar
Sensor
parar
gestinSensor
agregarSensor
quitarSensor
iniciarSensor
pararSensor
Adaptador
Recolector
de datos
obtenerD
ato
datosSensor
12/05/16
probarSensor
inicializar
informe
listarTodo
893
Semnticas de la interfaz
Se tiene que confiar en la documentacin del

componente para decidir si las interfaces que son
sintcticamente compatibles son realmente compatibles.
Considerar una interfaz para un componente
LibreraFotos:
public void agregarItem (Identificador pid ; Fotografa p; EntradaCatlogo descfoto) ;

public RecuperarFotografa (Identificador pid) ;
public EntradaCatlogo EntCata (Identificador pid) ;
12/05/16
894
Composicin de librera
de Fotos
obtenerImagen
agregarItem
Adaptador
recuperar
Librera de
Fotos
Gestor de
Imagen
obtenerEntradaCatlogo
entCata
Interfaz de
usuario
12/05/16
895
Documentacin de
librera de fotos
Este mtodo agrega una fotografa a la librera y
asocia el identificador de la fotografa y el
descriptor del catlogo con la fotografa.
qu pasa si el identificador de la fotografa ya
est asociado con una fotografa en la librera?
est el descriptor de la fotografa asociado con
la entrada del catlogo adems de la fotografa, es
decir si yo anulo la fotografa, tambin anulo la
informacin del catlogo?
12/05/16
896
El lenguaje de restriccin
de objetos
El
lenguaje de restriccin de objetos (LRO)

[OCL = Object Constraint Language] ha
sido diseado para definir las restricciones
que estn asociadas con los modelos UML.
Est basada alrededor de la nocin de
especificacin de pre y post condiciones similar a la aproximacin usada en Z como
la descrita en el Captulo 10.
12/05/16
897
Descripcin formal de la
librera de fotos
--La palabra clave del contexto nombra el componente a la que las condiciones aplican el
addItem del contexto
--Las pre condiciones especifican lo que debe ser verdad antes de la ejecucin de
addItem
pre: PhotoLibrary.libSize ()> 0
PhotoLibrary.retrieve(pid) = null
--Los post condiciones especifican lo que es verdad despus de la ejecucin
post: el libSize () = el libSize () @pre + 1
PhotoLibrary.retrieve(pid) = p
PhotoLibrary.catEntry(pid) = el photodesc
context delete
pre: PhotoLibrary.retrieve(pid) <> null;
post: PhotoLibrary.retrieve(pid) = null
PhotoLibrary.catEntry(pid) = PhotoLibrary.catEntry(pid)@pre
PhotoLibrary.libSize () = el libSize () @pre - 1
12/05/16
898
Condiciones de la librera
de fotos
12/05/16
Como se ha especificado, el LRO se asocia con los

estados de componentes de la Librera de Fotos que:
No debe haber una fotografa en la librera con el mismo
identificador tal como la fotografa ha sido ingresada;
La librera debe existir - asume que se crea una librera
agregando un artculo simple a ella.
Cada nueva entrada aumenta el tamao de la librera
en 1;
Si se recupera usando el mismo identificador entonces
se recupera la foto que se ha agregado;
Si se busca el catlogo que usa ese identificador,
entonces se vuelve a la entrada del catlogo que se
hizo.
899
Los cambios de composicin

Cuando se componen los componentes, se puede
encontrar los conflictos entre los requerimientos
funcionales y no funcionales y los conflictos entre las
necesidades de la entrega rpida y la evolucin del
sistema.
Se necesita tomar decisiones como:
Cul composicin de componentes es eficaz para la
entrega de los requerimientos funcionales?
Cul composicin de componentes es permite el
cambio futuro?
Cules sern las propiedades emergentes de los
sistemas compuestos?
12/05/16
900
Recoleccin de datos y
generacin de informe
(a)
(b)
12/05/16
Recoleccin
de datos
Recoleccin
de datos
Generador
de informe
Gestin de
datos
Base de
datos
Informe
Informe
901
Puntos clave
La ISBC es una aproximacin basada en el reuso para

la definicin e implementacin de componentes
dbilmente acoplados en el sistema.
Un componente es una unidad de software cuya
funcionalidad y dependencias estn completamente
definidas por sus interfaces.
Un modelo de componentes define un conjunto
estndares que los proveedores de componentes y los
compositores deben seguir.
Durante el proceso de ISBC, el proceso de ingeniera de
requerimientos y el diseo de sistema se entrelazan.
12/05/16
902
Puntos clave
La composicin de componentes es el proceso de
cableado de las componentes reunidos para crear
un sistema.
Cuando se componen componentes reusables,
normalmente se tiene que escribir adaptadores para
reconciliar diferentes interfaces de componentes.
Cuando se escoge composiciones, se tiene que
considerar
la
funcionalidad
requerida,
los
requerimientos no funcionales y la evolucin del
sistema.
12/05/16
903
Captulo 20
Desarrollo de
sistemas crticos
12/05/16
904
Objetivos
Explicar
cmo la tolerancia de falla y anulacin

de falla contribuyen al desarrollo de sistemas
fidedignos
Describir las caractersticas de procesos de
software fidedignos
Introducir tcnicas de programacin para la
anulacin de falla
Describir los mecanismos de tolerancia de falla y
su uso de diversidad y redundancia
12/05/16
905
Tpicos cubiertos
Procesos
fidedignos
Programacin fidedigna
Tolerancia de falla
Arquitecturas tolerantes de fallas
12/05/16
906
Confiabilidad del software

En
general, los clientes del software esperan

todo del software para ser fidedigno. Sin
embargo, para las aplicaciones no crticas,
pueden estar dispuestos a aceptar algunas fallas
del sistema.
Algunas aplicaciones, sin embargo, tienen los
requerimientos de confiabilidad muy altos y las
tcnicas de ingeniera de software especiales
puede ser usadas para lograr esto.
12/05/16
907
Logro de la confiabilidad
Anulacin de falla
El sistema es desarrollado de manera que el error humano es
evitado, y as se minimizan las fallas del sistema.
El proceso de desarrollo es organizado para que las fallas del
sistema sean detectadas y se reparen antes de la entrega al
cliente.
Deteccin de falla
Las tcnicas verificacin y validacin son usados para descubrir
y remover fallas en un sistema antes que este sea desarrollado.
Tolerancia de falla
El sistema es diseado para que las faltas en el software
entregado no produzcan falla del sistema.
12/05/16
908
Diversidad y redundancia
Redundancia
Guardar ms de un aversin en un componente crtico
disponible de modo que si uno falla, entonces hay uno de
reserva que est disponible.
Diversidad
Proporcionar
la misma funcionalidad de diferentes
maneras de modo que no fallarn de la misma manera.
Sin embargo, agregar diversidad y redundancia agrega
complejidad y esto puede incrementar la posibilidad de error.
Algunos ingenieros defienden simplicidad y extensividad V &
V es una ruta efectiva para la confiabilidad del software.
12/05/16
909
Ejemplos de redundancia
y diversidad
Redundancia.
Donde la disponibilidad es crtica

(por ejemplo, en los sistemas de comercio
electrnico),
las
compaas
normalmente
guardan los servidores de resguardo y cambian
automticamente cuando ocurre una falla.
Diversidad. Para proporcionar resistencia contra
ataques externos, pueden ser implementados
diferentes servidores usando sistemas operativos
diferentes (por ejemplo, Windows y Linux).
12/05/16
910
Software libre de falla
12/05/16
Los mtodos actuales de la ingeniera de software ahora

permiten la produccin de software libre de falla, por lo
menos para los sistemas relativamente pequeos.
Software libre de falla significa software que est conforme
a su especificacin. Ello NO significa que el software
siempre se desempear correctamente porque pude tener
errores de especificacin.
El costo de produccin de falla de software libre es muy alto.
Esto solo es rentable en situaciones excepcionales. A
menudo, es ms barato aceptar las fallas del software y
pagar por sus consecuencias que expender los recursos en
el desarrollo de software libre de falla.
911
Desarrollo de software
libre de falla
Procesos
de software fidedigno
Gestin de la calidad
Especificacin formal
Verificacin esttica
Mecanografa fuerte
Programacin segura
Informacin protegida
12/05/16
912
Costo de liberacin de falla
12/05/16
913
Procesos fidedignos
Para asegurar un mnimo nmero de fallas de
software, es importante tener un bien definido
repetible proceso de software.
Un bien definido y repetible proceso es uno que no
dependa enteramente de habilidades individuales;
ms bien puede ser presentado por diferentes
personas.
Para la deteccin de fallas, est claro que las
actividades del proceso deben incluir el desarrollo de
significativo esfuerzo para la verificacin y validacin.
12/05/16
914
Caractersticas de
procesos fidedignos
Documentable El proceso debe tener un modelo del proceso definido
que presenta las actividades en el proceso y la

documentacin que ser producida durante estas
actividades.
Estandarizado Un conjunto comprensivo de estndares de desarrollo
de software que definen cmo el software ser

producido y documentado para estar disponible.
Auditable
El proceso debe ser entendible por las personas

aparte de los participantes del proceso que pueden
verificar esos estndares
del proceso, debe
continuarse y hacer las sugerencias para la mejorar
del proceso.
Diverso
El proceso debe incluir comprobacin redundante y

diversa y actividades de validacin.
Robusto
El proceso debe poder recuperar de las fallas de

actividades del proceso individuales.
12/05/16
915
Actividades de validacin
Las
inspecciones de requerimientos.
Gestin de requerimientos.
Chequeo del modelo.
Inspeccin de diseo y cdigo.
Anlisis esttico.
Planificacin de prueba y gestin.
Gestin de configuracin discutido en el Captulo
29, es tambin esencial .
12/05/16
916
Programacin fidedigna
Usar
estructuras de programacin y tcnicas que

contribuyan a la anulacin de falla y tolerancia de
falla
Diseo para la simplicidad;
Proteger la informacin contra accesos no
autorizados;
Minimizar
el uso de estructuras de
programacin inseguras.
12/05/16
917
Proteccin de informacin
Slo debe exponerse la informacin a las partes del programa
que se necesita acceder. Esto involucra la creacin de objetos o
tipos abstractos de datos que mantienen el estado y que
proporcionan las operaciones en ese estado.
Esto evita las fallas por tres razones:
la probabilidad de corrupcin accidental de informacin est
reducida;
la informacin est rodeada por "cortafuegos", de modo que
los problemas estn menos probablemente expuestos a
expandirse a otras partes del programa;
como toda la informacin es localizada, es menos probable
cometer errores y los inspectores ms probablemente
encontrarn errores.
12/05/16
918
Una especificacin de
cola en Java
interface Cola {
public void put (Object o) ;
public void remove (Object o) ;
public int tamao () ;
} //Cola
12/05/16
919
Declaracin de seal en
Java
class Seal {
static public final int rojo =
1;
static public final int ambar =
2;
static public final int verde =
3;
public int sealEstado ;
12/05/16
920
Programacin segura
Las
fallas en los programas normalmente son

una consecuencia de programadores que
cometen errores.
Estos errores ocurren porque las personas
pierden la huella de las interrelaciones entre
las variables del programa.
Algunas estructuras de programacin son ms
propensas a error que otras, evitando as que
su uso reduzca los errores del programador.
12/05/16
921
Programacin estructurada
Propuesta
primero propuesto en 1968 como una

aproximacin al desarrollo que hace los
programas ms fciles de entender y eso evita
los errores del programador.
Programando sin los gotos.
Los ciclos while y los estamentos if como los
nicos estamentos de control.
Diseo Top - down (Arriba abajo).
Un desarrollo importante porque promovi
pensamiento y discusin acerca de la
programacin.
12/05/16
922
Estructuras propensas a error
12/05/16
Nmeros de punto flotante

Inherentemente impreciso. La imprecisin puede llevar a
comparaciones invlidas.
Puntero
Los punteros que hacen referencia a reas de memoria
errneas pueden corromper datos. Los alias pueden hacer los
programas difciles de entender y cambiar.
Asignacin de memoria dinmica
La asignacin de ejecucin de programas puede causar
desborde de memoria.
Paralelismo
Puede causar errores de sincronizacin sutiles a causa de
interaccin imprevista de procesos paralelos.
Recursin
Errores en la recursin pueden causar desborde de memoria.
923
Estructuras propensas a
error
Interrupciones
Las interrupciones pueden causar una operacin crtica para ser
terminada y hacer un programa difcil de entender.
Herencia
El
cdigo no es localizado. Esto puede producir un
comportamiento inesperado cuando son hechos los cambios y
problemas de entendimiento.
Alias
Usando ms de un nombre para referirse a la misma variable de
estado.
Arreglos ilimitados
Fallas de desborde de memoria intermedia pueden ocurrir si no
hay ninguna comprobacin de los lmites en arreglos.
Procesamiento de entradas predefinidas
Una accin de entrada que ocurre independientemente de la
entrada.
12/05/16
924
Manejo de excepcin
Una excepcin del programa es un error o algn evento
inesperado tal como una falla de energa.
Las estructuras de manejo de excepcin permiten que
tales eventos sean manejados sin la necesidad para la
revisin continua del estado para detectar excepciones.
El uso de las estructuras de control para detectar
excepciones necesita de muchos estamentos
adicionales para ser agregados al programa. Esto
agrega un significativo desborde y una potencial
propensin al error.
12/05/16
925
Excepciones en Java 1
class ExcepcinFallaSensor extends Excepcin {
ExcepcinFallaSensor (String msg) {

super (msg) ;
Alarma.activate (msg) ;
}
} // ExcepcinFallaSensor
12/05/16
926
Excepciones en Java 2
class Sensor {
int readVal () throws ExcepcinFallaSensor {
try {
int elValor = DeviceIO.readInteger () ;
if (elValor < 0)
throw new ExcepcinFallaSensor (Falla del Sensor") ;
return elValor ;
}
catch (deviceIOExcepcin e)
{
throw new ExcepcinFallaSensor ( Error de lectura del Sensor ) ;
}
} // readVal
} // Sensor
12/05/16
927
Un controlador de
temperatura
Las excepciones pueden ser usadas como un a
tcnica normal de programacin y no solamente como
una manera de recuperarse de las fallas.
Considerar
un ejemplo de un controlador de
congelador que guarda la temperatura del congelador
dentro de un rango especificado.
Interruptores entre una bomba refrigerante y fura de
ella.
Hacer explosionar una alarma si la mxima
temperatura permitida es excedida.
Usar excepciones como una tcnica
normal de
programacin.
12/05/16
928
Controlador de congelador 1
class ControladorCongeladorr {
Sensor tempSensor = new Sensor () ;
Dial tempDial = new Dial () ;
float freezerTemp = tempSensor.readVal () ;
final float dangerTemp = (float) -18.0 ;
final long coolingTime = (long) 200000.0 ;
public void run ( ) throws InterruptedException {
try { Pump.switchIt (Pump.on) ;
do {
if (freezerTemp > tempDial.setting ())
if (Pump.status == Pump.off)
{ Pump.switchIt (Pump.on) ;
Thread.sleep (coolingTime) ;
}
12/05/16
929
Controlador de congelador 2
if (freezerTemp > dangerTemp)
throw new FreezerTooHotException () ;
freezerTemp = tempSensor.readVal () ;
} while (true) ;
} // try block
catch (FreezerTooHotException f)
{ Alarm.activate ( ) ; }
catch (InterruptedException e)
{
System.out.println (Thread exception) ;
throw new InterruptedException ( ) ;
}
} //Ejecutar
} // ControladorCongelador
12/05/16
930
Tolerancia de fallas
12/05/16
En situaciones crticas, los sistemas de software deben

ser tolerantes con las fallas.
La tolerancia de falla es requerida donde hay alta
disponibilidad de requerimientos o donde los costos de
falla del sistema sean muy altos.
La tolerancia de falla significa que el sistema puede
continuar en operacin a pesar de fallas del software.
Aun cuando se ha demostrado que el sistema est
conforme a su especificacin, tambin debe ser
tolerante a fallas, de modo que pueden haber errores en
la especificacin o la validacin puede ser incorrecta.
931
Acciones de tolerancia de
fallas
Deteccin de falla
El sistema detectar que una falla (un estado incorrecto del
sistema) ha ocurrido.
Valoracin de falla
Las partes del estado del sistema afectadas por la falla
deben ser detectadas.
Recuperacin de la falla
El sistema debe restaurar su estado a un estado seguro
conocido.
Reparacin de fallas
El sistema puede ser modificado para prevenir la recurrencia
de las fallas. Como las muchas fallas del software son
transitorias, esto es a menudo innecesario.
12/05/16
932
Deteccin de falla y valoracin

del dao
La
primera fase de la tolerancia de falla es

para detectar que una falla (un estado
errneo del sistema) ha ocurrido o va a
ocurrir.
La tolerancia de falla involucra la definicin
de restricciones que deben sostenerse para
todos los estados legales y revisando los
estados contra estas restricciones.
12/05/16
933
Restricciones de estado
de la bomba de insulina
/ / La dosis de insulina a ser entregado siempre debe ser mayor
/ / que cero y menor que algunos definieron como el mximo de una dosis
simple
dosis_insulina >= 0 & dosis_ insulina <= contenido_reserva_insulina

/ / La cantidad total de insulina entregada por un da debe ser menor
// que o igual a una dosis mxima diaria definida
dosis_acumulativa <= el maxima_dosis_diaria
12/05/16
934
Deteccin de falla
Deteccin
El mecanismo de deteccin de falla es iniciado antes

de que el cambio de estado se ha realizado. Si un
estado errneo es detectado el cambio no es hecho.
Deteccin
12/05/16
de falla preventiva
de falla retrospectiva
El mecanismo de deteccin de falla es iniciado

despus de que el estado ha sido cambiado. Esto es
un usado cuando una secuencia de acciones
correctas lleva a un estado errneo o cuando una
deteccin de falla preventiva involucra mucho
desbordamiento.
935
Extensin de sistemas
tipo
La
deteccin de falla preventiva

involucra la extensin de sistema tipo
por inclusin de restricciones como
parte de la definicin del tipo.
Estas restricciones se implementan
por definicin de operaciones bsicas
dentro de la definicin de clase.
12/05/16
936
EnteroParPositivo 1
class EnteroParPositivo {
int val = 0 ;
EnteroParPositivo (int n) throws ExcepcinNumrica
{
if (n < 0 | n%2 == 1)
throw new ExcepcinNumrica () ;
else
val = n ;
}// EnteroParPositivo
12/05/16
937
EnteroParPositivo 2
public void assign (int n) throws ExcepcinNumrica
{
if (n < 0 | n%2 == 1)
throw new ExcepcinNumrica ();
else
val = n ;
} // Asignar
int paraEntero ()
{
return val ;
} //Para entero
boolean equals (EnteroParPositivo n)
{
return (val == n.val) ;
} // equals
} //ParPositivo
12/05/16
938
Valoracin de dao
Analizar
el estado del sistema para juzgar la

extensin de corrupcin causada por la falla del
sistema.
La valoracin debe revisar que partes del
espacio de estado han sido afectadas por la falla.
Basada generalmente en las funciones de
validacin que puede ser aplicada a los
elementos de estado para evaluar si los valores
estn dentro del rango permitido.
12/05/16
939
Arreglo robusto 1
class ArregloRobusto {
/ / Revisar que todos los objetos en un arreglo de objetos
/ / conforme a algunas restricciones definidas
boolean [] checkState ;
CheckableObject [] elArregloRobusto ;
AregloRobusto (CheckableObject [] elArreglo)

{
checkState = new boolean [elArreglo.length] ;
el ArreloRobusto = elArreglo ;
} //ArregloRobusto
12/05/16
940
Arreglo robusto 2
public void assessDamage () throws ArrayDamagedException
{
boolean hasBeenDamaged = false ;
for (int i= 0; i <this.elArregloRobusto.length ; i ++)
{
if (! elArregloRobusto [i].check ())
{
checkState [i] = true ;
hasBeenDamaged = true ;
}
else
checkState [i] = false ;
}
if (hasBeenDamaged)
throw new ArrayDamagedException () ;
} //assessDamage
} // ArregloRobusto
12/05/16
941
Tcnicas de valoracin
de dao
Los
checksums son usados para la valoracin

del dao en los datos de transmisin.
Punteros redundantes pueden se usados para
revisar la integridad de las estructuras de datos.
Los cronmetros guardianes pueden revisar los
procesos no terminados. Si no responde antes
de cierto tiempo, un problema es asumido.
12/05/16
942
Recuperacin de falla y
reparacin
Recuperacin hacia adelante

Aplicar reparaciones para un estado de sistema corrupto.
Recuperacin hacia atrs
Restaurar el estado de sistema para un estado seguro
conocido.
La recuperacin hacia delante es normalmente una
aplicacin especfica es requerido el para calcular las
posibles correcciones de estado.
La recuperacin de error hacia atrs es ms simple. Los
detalles de un estado seguro son mantenidos y esto
reemplaza el estado de sistema corrupto.
12/05/16
943
Recuperacin hacia
adelante
Corrupcin de codificacin de datos

Las tcnicas de codificacin de error que agrega la
redundancia para datos codificados puede ser usado para
reparar
datos
corruptos
durante
la
transmisin.
Punteros redundantes
Cuando los punteros redundantes son incluidos en las
estructuras de datos (pro ejemplo, las listas
bidireccionales), una lista corrupta o un almacn de
archivos puede ser reconstruido si un nmero suficiente de
punteros son incorruptos.
A menudo es usado para bases de datos y reparo de
sistemas de archivo.
12/05/16
944
Recuperacin hacia atrs

Las
transacciones
son
un
mtodo
frecuentemente usado para la recuperacin hacia
adelante. Los cambios no son aplicados hasta
que la computacin sea completa. Si ocurre un
error, el sistema se va al estado precedente de la
transaccin.
Los puntos de control peridicos permiten al
sistema regresar a la situacin anterior de un
estado correcto.
12/05/16
945
Procedimiento de orden
seguro
Una operacin de orden monitorea su propia
ejecucin y evala si el orden ha sido
correctamente ejecutado.
Mantiene una copia de su entrada, de modo que
si ocurre un error, la entrada no es corrupta.
Basada
en la identificacin y manejo de
excepciones.
Posible en este caso cuando la condicin para un
orden vlido es conocida. Sin embargo en
muchos casos. Sin embargo en muchos casos es
difcil escribir revisiones de validacin.
12/05/16
946
Orden seguro 1
class OrdenSeguro {
static void sort ( int [] intarreglo, int orden ) throws ErrorOrden
{
int [] copy = new int [intarray.length];
// copia del arreglo de entrada
for (int i = 0; i < intarray.length ; i++)
copy [i] = intarray [i] ;
try {
Sort.bubblesort (intarrerglo, intareglo.length, orden) ;
12/05/16
947
Orden seguro 2
if (order == Sort.ascending)
for (int i = 0; i <= intarreglo.length-2 ; i++)
if (intarray [i] > intarreglo [i+1])
throw new ErrorOrden () ;
else
for (int i = 0; i <= intarray.length-2 ; i++)
if (intarray [i+1] > intarray [i])
throw new tErrorOrden () ;
} // try block
catch (SortError e )
{
for (int i = 0; i < intarray.length ; i++)
intarray [i] = copy [i] ;
throw new SortError ("Arreglo no ordenado") ;
} //catch
} // sort
} // OrdenSegurot
12/05/16
948
Arquitectura tolerante de falla
12/05/16
La programacin defensiva no puede cubrir todas las

fallas en las interacciones involucradas entre el
hardware y el software.
Las equivocaciones en los requerimientos pueden
significar que las revisiones y el cdigo asociado son
incorrectos.
Cuando los sistemas tienen alta disponibilidad de
requerimientos, una arquitectura especfica diseada
para soportar tolerancia a fallas puede ser requerida.
Esto debe tolerar fallas entre hardware y software.
949
Tolerancia a fallas de
hardware
Depende de la redundancia-modular-triple (RMT).
Hay
tres componentes idnticas replicados que
reciben la misma entrada y cuyas salidas son
comparadas.
Si una salida s diferente, ella es ignorada y la falla
de componente es asumida.
Basada en la mayora de fallas resultantes desde
fallas de componentes, en lugar de las fallas de
diseo
y una baja probabilidad de falla de
componentes simultanea.
12/05/16
950
Fiabilidad de hardware con

RMT
A1
A1
A2
A2
Comparador
Comparadorde
de
salida
salida
A3
A3
12/05/16
951
Seleccin de salida
El
comparador de salida es un (relativamente)

simple unidad de hardware.
Compara sus seales de salida, si una es
diferente de los otros, lo rechaza. Esencialmente,
la seleccin de la salida efectiva depende de la
mayora de votos.
El comparador de salida est conectada a la
unidad de gestin de falla que puede intentar
reparar la unidad defectuosa o sacarla fuera de
servicio.
12/05/16
952
Arquitecturas de software
tolerante a fallas
El xito de RTM a proporcionar tolerancia de fallas est

basada en dos fundamentales asunciones
Ninguna de estas asunciones es verdadera para el

software
Los componentes de hardware no incluyen fallas de diseo

comunes;
Los componentes fallan al azar y hay baja probabilidad de falla de
componente simultanea.
No es posible simplemente replicar el mismo componente cuando

ellos tuvieran fallas de diseo comunes;
La falla de componentes simultanea es por lo tanto virtualmente
inevitable.
Los sistemas de software deben, por lo tanto ser diversas.
12/05/16
953
Diversidad de diseo
Diferentes versiones del sistema son diseados e

implementados de diferentes maneras.
Ellos, por
consiguiente, deben tener diferentes modos de falla.
Diferentes aproximaciones para el diseo (por ejemplo,
orientado a objetos y orientado a funciones)
Implementacin
en
diferentes
lenguajes
de
programacin;
Uso de diferentes herramientas y ambientes de
desarrollo;
Use de diferentes algoritmos en la implementacin.
12/05/16
954
Analogas de software de
RMT
Programacin versin N
La misma especificacin es implementada en varias
versiones diferentes por equipos diferentes. Todas las
versiones computan simultneamente y la salida de la
mayora es seleccionada usando un sistema de votacin.
Esta es la aproximacin ms comnmente usada, por
ejemplo, en muchos modelos del avin comercial Airbus.
Bloques de recuperacin
Un nmero de explcitamente diferentes versiones de la
misma especificacin son escritas y ejecutadas en
secuencia.
Una prueba de aceptacin es usada para seleccionar la
salida a ser transmitida.
12/05/16
955
Programacin versin-N
Versin
Versin11
Entrada
Versin
Versin22
Comparador
Comparadorde
de
salida
salida
Versin
Versin33
Resultado
Resultado
convenido
convenido
N versiones
12/05/16
956
Comparacin de salidas
Como
en los sistemas de hardware, el

comparador de salidas es una simple pieza
de software que usa el mecanismo de
votacin para seleccionar la salida.
En los sistemas de tiempo real, puede
haber un requerimiento que los resultados
de diferentes versiones son todas
producidas dentro de un cierto horario.
12/05/16
957
Programacin de la versin N
Las
diferentes versiones del sistema son

diseados e implementadas por diferentes
equipos. Se asume que hay una baja
probabilidad que ellas cometan los mismos
errores. Los algoritmos usados deben pero no
pueden ser diferentes.
Hay alguna evidencia emprica que los equipos
normalmente malentienden las especificaciones
de la misma manera y escogen los mismos
algoritmos en sus sistemas.
12/05/16
958
Pruebas para
sucesos
Probar el
algoritmo 1
Algoritmo
Algoritmo11
Continua
la
ejecucin si sucede
la
prueba
de
aceptacin. Sealar
excepcin si todos
los algoritmos fallan
Prueba
Pruebade
de
aceptacin
aceptacin
Pruebas de aceptacin
Reintentar fallas
Re-prueba
Re-prueba
Reintentar
Algoritmo
Algoritmo22
Algoritmo
Algoritmo33
Bloques de
recuperacin
12/05/16
959
Estos
obligan a usar un diferente algoritmo para

para cada versin para que ellos reduzcan la
probabilidad de errores comunes.
Sin embargo, el diseo de las pruebas de
aceptacin es difcil puesto que debe ser
independiente de la computacin usada.
Hay problemas con la aproximacin para
sistemas de tiempo real debido a la operacin
secuencial de las versiones redundantes.
12/05/16
960
Problemas con la
diversidad del diseo
Los equipos no son culturalmente diversos para que ellos tiendan
a tomar los problemas de la misma manera.
Errores caractersticos
Equipos diferentes cometen los mismos errores. Algunas partes
de una implementacin son ms difciles que otras de modo que
todos los equipos tienden a cometer errores en el mismo lugar;
Errores de especificacin;
Si hay un error en la especificacin, entonces esto se refleja en
todas las implementaciones;
Esto
puede ser dirigida a alguna extensin usando
representaciones de especificacin mltiple.
12/05/16
961
Dependencia de la
especificacin
Ambas aproximaciones para la redundancia de
software son susceptibles a errores en la
especificacin. Si la especificacin es incorrecta el
sistema podra fallar.
Esto es tambin un problema con el hardware,
pero las especificaciones de software normalmente
son ms complejas que las especificaciones del
hardware y ms difcil para validar.
Esto ha sido dirigido en algunos casos por
desarrollo separado de las especificaciones de
software desde las mismas especificaciones del
usuario.
12/05/16
962
Puntos clave
La confiabilidad en un sistema puede ser logrado a
travs de la anulacin de falta, deteccin de falta y
tolerancia de falta.
El uso de redundancia y diversidad es esencial para
el desarrollo de sistemas fidedignos.
El uso de procesos repetibles bien definidos es
importante si las fallas en sistema sern
minimizadas.
Algunas
estructuras de construccin son la
inherentemente propensos a error su uso debe
evitarse dondequiera sea posible.
12/05/16
963
Puntos clave
Las
excepciones son usadas para soportar la

gestin de error en sistemas fidedignos.
Los 4 aspectos de la tolerancia de falla de
programa son la deteccin de falla, valoracin del
dao, recuperacin de falla y reparacin de falla.
La programacin de la versin N y los bloques de
recuperacin son aproximaciones alternativas
para las arquitecturas tolerantes a fallas.
12/05/16
964
Captulo 21
Evaluacin del
software
12/05/16
965
Objetivos
Explicar porque el cambio es inevitable si los
sistemas de software son para permanecer tiles.
Discutir el mantenimiento del software y factores de
costo del mantenimiento
Describir los procesos involucrados en la evolucin
del software
Discutir
una aproximacin para evaluar las
estrategias de evolucin y las estrategias para
sistemas legados.
12/05/16
966
Tpicos cubiertos
Dinmicas
de
la
evolucin
de
programa
Mantenimiento del software
Procesos de evolucin
Evolucin de procesos legados
12/05/16
967
Cambio del software
12/05/16
El cambio del software es inevitable

Los nuevos requerimientos emergen cuando el software
es usado;
El ambiente de negocios cambia;
Los errores deben ser reparados;
Nuevas computadoras y equipos son agregados al
sistema;
El desempeo o fiabilidad del sistema pueden ser
mejorados.
Un problema clave para las organizaciones es la
implementacin y el manejo de cambios para los sistemas
de software existentes.
968
Importancia de la
evolucin
Las
organizaciones tienen grandes inversiones

en sus sistemas de software ellos son los
recursos comerciales crticos.
Para mantener el valor de estos recursos de los
negocios, ellos deben ser cambiados y
actualizados.
La mayora de los presupuestos de software en
grandes compaas se consagran a la evolucin
del software existentes antes que el desarrollo de
software nuevo.
12/05/16
969
Modelo en espiral de la
evolucin
Especificacin
Especificacin
Implementacin
Implementacin
Inicio
Operacin
Operacin
Lanzamiento
1
Lanzamiento
2
Validacin
Validacin
Lanzamiento
3
12/05/16
970
Dinmicas de la evolucin
de programa
Dinmicas
de evolucin del programa es el

estudio de los procesos de cambio de sistemas.
Despus de que los empricos mayores, Lehman
y Belady propusieron que hay haban varias
leyes que aplicaron a todos los sistemas
cuando ellos evolucionan.
Hay observaciones sensatas en lugar de leyes,
Ellos son aplicados al desarrollo de grandes
sistemas por grandes equipos. Quizs menos
aplicables en otros sistemas
12/05/16
971
Reglas de Lehman
Ley
Descripcin
Cambio continuo
Un programa que se usa en un ambiente del mundo real necesariamente debe

cambiar o debe progresivamente llegar a ser menos til en ese ambiente.
Complejidad creciente
Como un programa que evoluciona cambia, su estructura tiende a llegar a ser

ms compleja. Deben consagrarse recursos extras para conservar y simplificar la
estructura.
Evolucin del programa largo
La evolucin del programa es un proceso autorregulador. Los atributos del

sistema como el tamao, tiempo entre lanzamientos y el nmero de errores
informados es aproximadamente invariante para cada lanzamiento del sistema.
Estabilidad organizacional
Sobre el tiempo de vida de un programa, su proporcin de desarrollo es

aproximadamente constante e independiente de los recursos consagrados al
Conservacin de familiaridad
Sobre el tiempo de vida de un sistema, el cambio incremental en cada

lanzamiento es aproximadamente constante.
Crecimiento continuado
La funcionalidad ofrecida por los sistemas tiene que aumentar para mantener
continuamente la satisfaccin del usuario
Calidad declinante
La calidad de sistemas aparecer para ser declinante, a menos que ellos se

adapten a los cambios en su ambiente operacional.
Sistema de retroalimentacin
El proceso de evolucin incorpora multiagentes, sistemas de retroalimentacin

multiciclo y se tienen que tratarlos como sistemas de retroalimentacin para
lograr la mejora significativa del producto.
12/05/16
972
Aplicabilidad de las leyes

de Lehman
Las leyes de Lehman parecen ser generalmente aplicables para

grandes entalallados sistemas desarrollados por grandes
organizaciones.
Confirmado por el ms reciente trabajo de Lehman el proyecto
FEAST [FIESTA] (ver y leer el libro mas all de la Website del
libro).
No est claro cmo debe modificarse ellos para
Productos de software compacto envueltos;
Sistemas
que incorporan un nmero significativo de
componentes COTS;
Pequeas organizaciones;
Sistemas de tamao mediano.
12/05/16
973
Mantenimiento del software

Modificando
un programa despus de que ha

sido puesto en uso.
El mantenimiento normalmente no incluye
mayores cambios en la arquitectura del
sistema.
Los
cambios
son
implementados
por
modificacin de componentes existentes y por
adicin de nuevos componentes par el sistema.
12/05/16
974
El mantenimiento es inevitable
12/05/16
Es probable que los requerimientos del sistema

cambien cuando el sistema se est desarrollando
porque el ambiente est cambiando. Por consiguiente
un sistema entregado no reunir sus requerimientos!
Los sistemas son hermticamente acoplados con sus
ambientes. Cuando un sistema es instalado en un
ambiente, ese ambiente cambia y por consiguiente
cambian los requerimientos del sistema.
Los sistemas DEBEN ser mantenidos, puesto que ellos
deben permanecer tiles en el ambiento.
975
Tipos de mantenimiento
Mantenimiento para reparar fallas del software

Cambiando un sistema para corregir deficiencias las
deficiencias de una manera que renan los
requerimientos.
Mantenimiento para adaptar el software a diferentes
ambientes operativos
Cambiando un sistema para que opere en un ambiente
diferente
(computadora,
SO,
etc.)
desde
una
implementacin inicial.
Mantenimiento para agregar o modificar la funcionalidad del
sistema
Modificando
el sistema para satisfacer nuevos
requerimientos.
12/05/16
976
Distribucin del esfuerzo de

mantenimiento
12/05/16
977
Costos de mantenimiento
Normalmente mayor que los costos de desarrollo
(de 2* a 100* dependiendo en la aplicacin).
Afectado por los factores tcnicos y no tcnicos.
El crecimiento como el software es mantenido. El
mantenimiento corrompe la estructura del software,
lo que hace el mantenimiento ms dificultoso.
El software viejo puede tener altos costos de
soporte
(por
ejemplo,
viejos
lenguajes,
compiladores, etc. ).
12/05/16
978
Costos de
desarrollo/mantenimiento
Sistema 2
Sistema 1
50
100
150
200
150
Costos de desarrollo
12/05/16
200
250
300
350
400
450
500
Costos de mantenimiento
979
Factores de costo de
mantenimiento
Estabilidad del equipo
Los costos de mantenimiento estn reducidos si el mismo
personal est involucrado con ellos por algn tiempo.
Responsabilidad contractual
Los desarrolladores de un sistema pueden no tener
responsabilidad contractual para el mantenimiento, de
modo que no hay incentivo para disear un cambio futuro.
Habilidades del personal
El equipo de mantenimiento son a menudo inexpertos y
tienen conocimiento limitado del dominio.
Edad de programa y estructura
Cuando la edad de los programas, su estructura se
degrada y ellos se ponen ms difciles de entender y
cambiar.
12/05/16
980
Prediccin del
mantenimiento
La prediccin de mantenimiento se preocupa para

evaluar que partes del sistema pueden causar problemas
y tener altos costos de mantenimiento
La aceptacin del cambio depende de la mantenibilidad
de los componentes afectados por el cambio;
La implementacin de cambios degrada el sistema y
reduce su mantenibilidad;
Los costos de mantenimiento dependen del nmero de
cambios y los costos de cambio dependen de la
mantenibilidad.
12/05/16
981
Prediccin del
mantenimiento
Qu
Qupartes
partesdel
del
sistema
sern
ms
sistema sern ms
probablemente
probablemente
afectadas
afectadaspor
porlas
las
demandas
de
demandas de
cambio?
cambio?
Cuntas
Cuntasdemandas
demandas
de
cambio
de cambiopueden
pueden
esperarse?
esperarse?
12/05/16
Prediciendo
mantenibilidad
Prediciendo
cambios del
sistema
Prediciendo
costos de
mantenimiento
Qu
Qupartes
partesdel
del
sistema
pueden
sistema puedenser
ser
ms
caras
para
el
ms caras para el
mantenimiento?
mantenimiento?
Cul
Culser
sereleltiempo
tiempo
de
vida
de
los
de vida de los
costos
costosde
de
mantenimiento
mantenimientode
de
este
sistema?
este sistema?
Cules
Culessern
sernlos
loscostos
costos
de
mantenimiento
de mantenimientodel
del
sistema
mantenimiento
sistema mantenimiento
para
paraelelprximo
prximoao?
ao?
982
Prediccin del cambio
Prediciendo el nmero de cambios que requiere y

entendiendo las interrelaciones entre el sistema y su
ambiente.
Los sistemas hermticamente acoplados requieren
cambios siempre que el ambiente es cambiado.
Los factores que influyen en estas interrelaciones son
Nmero y complejidad de las interfaces del sistema;
Nmero de requerimientos del sistema inherentemente
voltiles;
Los procesos de negocios donde el sistema es usado.
12/05/16
983
Mtricas de complejidad
Las predicciones de mantenibilidad pueden ser
hechas evaluando la complejidad de componentes
del sistema.
Los estudios han mostrado ms esfuerzo de
mantenimiento est gastando en un nmero
relativamente pequeo de componente de sistemas.
La complejidad depende de
La complejidad de las estructuras de control;
La complejidad de estructuras de datos;
Objeto, mtodo (procedimiento) y tamao de
modulo.
12/05/16
984
Mtricas del proceso

Las mediciones del proceso pueden ser usadas para
evaluar la mantenibilidad
Nmero
de demandas para mantenimiento
correctivo;
Tiempo promedio requerido por el anlisis de
impacto;
Tiempo medio tomado para implementar una
demanda de cambio;
Nmero de demandas de cambio pendientes.
Si uno o cualquiera de estos est creciendo, esto
puede indicar una declinacin en la mantenibilidad.
12/05/16
985
Proceso de evolucin
El
proceso de evolucin de
El tipo de software que es mantenido;
El proceso de desarrollo usado;
Las habilidades y experiencia de la
gente involucrada.
Las propuestas para el cambio son los
conductores de la evolucin del sistema. Se
identifica el cambio y la evolucin continua
a travs del tiempo de vida del sistema.
12/05/16
986
Identificacin del cambio

y evolucin
Proceso
Procesode
de
identificacin
identificacindel
del
cambio
cambio
Nuevo
Nuevo
sistema
sistema
Propuesta
Propuestade
de
cambios
cambios
Proceso
Procesode
de
evolucin
evolucindel
del
software
software
12/05/16
987
El proceso de evolucin
del sistema
Demanda de
Demanda de
cambios
cambios
Anlisis
Anlisisde
de
impacto
impacto
Reparacin
Reparacinde
de
falla
falla
12/05/16
Planificacin
Planificacinde
de
lanzamiento
lanzamiento
Implementacin
Implementacin
del
delcambio
cambio
Adaptacin
Adaptacinde
de
plataforma
plataforma
Perfeccionamiento
Perfeccionamiento
del
delsistema
sistema
Lanzamiento
Lanzamiento
del
delsistema
sistema
988
Implementacin del cambio
Cambios
Cambios
propuestos
propuestos
12/05/16
Anlisis
Anlisisde
de
requerimientos
requerimientos
Actualizacin
Actualizacinde
de
requerimientos
requerimientos
Desarrollo
Desarrollode
de
software
software
989
Demandas de cambio
urgente
12/05/16
Los
cambios
urgentes
pueden
ser
implementados sin pasar a travs de todas las
fases del proceso de ingeniera de software
Si una falla de sistema seria tiene que ser
reparada;
Si los cambios en el ambiente del sistema (por
ejemplo, actualizar SO) tienen efectos
inesperados;
Si hay cambios en los negocios que requieren
una respuesta muy rpida (por ejemplo, el
lanzamiento de un producto competitivo).
990
Reparar una emergencia
Demanda
Demanda
de
decambios
cambios
12/05/16
Analizar
Analizarcdigo
cdigo
fuente
fuente
Modificar
Modificarcdigo
cdigo
fuente
fuente
Entregar
Entregarsistema
sistema
modificado
modificado
991
Reingeniera de
sistemas
Reestructurar
o rescribir parte o todo de un

sistema legado sin cambiar su funcionalidad.
Aplicable cuando algunos pero no todos los
subsistemas de un sistema grande requieren de
mantenimiento frecuente.
La reingeniera involucra el esfuerzo de la adicin
para hacer ms fcil el mantenimiento.
El
sistema
puede
ser
reestructurado
y
redocumentado.
12/05/16
992
Ventajas de la reingeniera
Riesgo
reducido
Hay un riesgo alto en el nuevo desarrollo del
software. Puede haber problemas de desarrollo,
problemas de proveer de personal y problemas
de la especificacin.
Costo reducido
El costo de reingeniera es significativamente
menor que el costo de desarrollar nuevo
software.
12/05/16
993
Adelante y reingeniera
Especificacin
Especificacin
del
delsistema
sistema
Diseo
Diseoee
implementacin
implementacin
Nuevo
Nuevo
sistema
sistema
Entendimiento
Entendimientoyy
transformacin
transformacin
Sistema
Sistemacon
con
reingeniera
reingeniera
Ingeniera hacia adelante

Sistema
Sistemade
de
software
software
existente
existente
Reingeniera de software
12/05/16
994
Los procesos de
reingienera
Documentacin
Documentacin
de
deprograma
programa
Programa
Programa
original
original
Programa
Programa
modularizado
modularizado
Datos
Datos
originales
originales
Ingeniera
Ingeniera
reversa
reversa
Traslacin
Traslacinde
de
cdigo
fuente
cdigo fuente
Modularizacin
Modularizacin
de
deprograma
programa
Reingienera
Reingienerade
de
datos
datos
Programa
Programa
estructurado
estructurado
Datos
Datoscon
con
reingienera
reingienera
Mejora
Mejorade
delala
estructura
estructura
de
deprograma
programa
12/05/16
995

de reingienera
Traduccin de cdigo fuente

Convertir cdigo a nuevo lenguaje.
Ingeniera reversa
Analizar el programa para entenderlo;
Mejoramiento de la estructura de programa
Reestructurar automticamente para la entendibilidad;
Modularizacin de programa
Reorganizar la estructura de programa;
Reingienera de datos
Limpiar y reestructurar los datos del sistema.
12/05/16
996
Aproximacin de
reingienera
Reestructuracin de
programa automatizado
Conversin de
cdigo fuente
automatizado
Reestructuracin de
datos del programa
Reestructuracin
automatizada con
cambios manuales
Reestructuracin
ms cambios
arquitectnicos
Costo incrementado
12/05/16
997
Factores de costo de la
reingienera
La
calidad del software para aplicar reingeniera.

Las herramientas de soporte disponibles para la
reingienera.
La magnitud de conversin de datos que son
requeridos.
La disponibilidad de personal experto para la
reingienera.
Esto puede ser un problema con sistemas viejos
basados en tecnologa que no ha sido
ampliamente usada.
12/05/16
998
Evolucin de sistemas
legados
Las organizaciones que confan en sistemas legados deben

escoger una estrategia para evolucionar esos sistemas
Desechar el sistema completamente y modificar procesos
de negocios de modo que ya no ms requerido;
Continuar el mantenimiento del sistema;
Transformar el sistema por reingienera para mejorar su
mantenibilidad;
Reemplazar el sistema por un nuevo sistema.
La estrategia elegida debe depender de la calidad del sistema
y su valor comercial.
12/05/16
999
Valor comercial
Calidad del sistema y valor

comercial
Alto valor comercial
Alto valor comercial
Baja calidad
Alta calidad
6
10
Bajo valor comercial

Baja calidad
8
7
Bajo valor comercial

Alta calidad
5
Calidad del sistema

12/05/16
1000
Categoras de sistemas
legados
Baja calidad, bajo valor comercial

Estos sistemas deben rechazarse.
Baja calidad, alto valor comercial
Estos hacen una importante contribucin comercial pero
son costosos de mantener. Debe aplicarse reingienera
o reemplazar si un sistema conveniente est disponible.
Alta calidad, bajo valor comercial
Reemplazar con COTS, desechar completamente o
mantener.
Alta calidad, alto valor comercial
Continuar en operacin usando el mantenimiento normal
del sistema.
12/05/16
1001
Valoracin del valor

comercial
La
valoracin debe tener en cuenta diferentes

puntos de vista
Usuarios finales del sistema;

Clientes comerciales;
Gerentes en lneas;
Gerentes de IT;
Gerentes mayores.
Entrevista
de diferentes stakeholders y resultados

intercalados.
12/05/16
1002
Valoracin de la calidad
del sistema
Valoracin
Qu tan bien el proceso de negocios apoya las

metas actuales del negocio?
Valoracin
12/05/16
del ambiente
Cun efectiva es el ambiente del sistema es y cun

costoso es mantenerlo?
Valoracin
del proceso de negocios
de la aplicacin
Cul es la calidad del sistema de software de

aplicacin?
1003
Valoracin del proceso de

negocio
Usar una aproximacin orientada a un punto de vista y buscar las
respuestas de los stakeholders del sistema
Hay un modelo del proceso definido y l es seguido?
Las partes diferentes de la organizacin usan procesos
diferentes para la misma funcin?
Cmo ha sido adaptado el proceso?
Cules son las interrelaciones con otros procesos de negocio y
son estos necesarios?
El proceso es efectivamente apoyado por el sistema legado de
software de aplicacin?
Ejemplo Un sistema de pedido de viaje puede tener un bajo valor
comercial debido al uso extendido de pedidos basados en la Web.
12/05/16
1004
Valoracin del ambiente 1

Factor
Estabilidad
proveedor
Preguntas
del Est todava el proveedor en existencia? El proveedor
es financieramente estable y probablemente contine en

existencia? Si el proveedor no est mucho tiempo en el
negocio, alguien ms mantiene los sistemas?
Proporcin de falla El hardware tiene una proporcin alta de fallas
reportadas? El software de soporte cae y fuerza el

reinicio del sistema?
Edad
Cuntos aos tienen el hardware y software? El ms

viejo hardware y software de soporte, ser el ms
obsoleto. Todava puede funcionar correctamente, pero
all podran estar los beneficios econmicos y
comerciales significativos para mover a los sistemas
ms modernos.
Desempeo
El desempeo del sistema es adecuado? Los

problemas de desempeo tienen un efecto significativo
en los usuarios del sistema?
12/05/16
1005
Valoracin del ambiente 2

Requerimientos
de soporte
Qu apoyo local se requiere para el hardware y

el software? Si hay costos altos asociados con
este soporte, puede merecer la pena considerar el
reemplazo del sistema.
Costos
de Cules son los costos de mantenimiento del
hardware y licencias de software de soporte? El
mantenimiento
hardware ms viejo puede tener el mantenimiento
de costo ms alto que los sistemas modernos. El
software de soporte puede tener los costos de
licencia anuales altos.
Interoperatividad
12/05/16
Hay problemas de interfaz de un sistema a otros

sistemas? Pueden los compiladores etc. ser
usados con las versiones actuales del sistema
operativo? Se requiere la emulacin del
hardware?
1006
Valoracin de la aplicacin 1
Factor
Preguntas
Entendibilidad
Cun difcil es el entendimiento del cdigo fuente

del sistema actual? Cun complejas son las
estructuras del control que se usan? Tienen las
variables nombres significativos que reflejan su
funcin?
Documentacin
Qu documentacin del sistema est disponible?

La documentacin est completa, consistente y
moderna?
Datos
Hay un explcito modelo de datos para el sistema?

Hasta qu punto los datos se reproducen en
archivos diferentes? Son los datos usados por el
sistema actualizados y consistentes?
Desempeo
Es adecuado el desempeo de la aplicacin ?

Los problemas de desempeo tienen un efecto
significativo en los usuarios del sistema?
12/05/16
1007
Valoracin de la aplicacin 2
Lenguaje de Los compiladores modernos estn disponibles para
programacin el lenguaje de programacin para desarrollar el
sistema? El lenguaje de programacin todava se
usa para el nuevo desarrollo del sistema?
Gestin de la Son todas las versiones o las partes del sistema

configuracin manejados por un sistema de gestin de
configuracin? Hay una descripcin explcita de las
versiones de componentes que se usan en el sistema
actual?
Datos
prueba
Habilidades
personales
12/05/16
de Existen los datos de prueba del sistema? Hay un
registro de pruebas de regresin llevado a cabo

cundo se han agregado los nuevos rasgos al
sistema?
Hay personas disponibles quin tiene las habilidades
para mantener la aplicacin? Hay slo un nmero
limitado de personas que entienden el sistema?
1008
Medida del sistema

Se
pueden recolectar datos cuantitativos

para hacer una valoracin de la calidad del
sistema de aplicacin
El nmero de demandas de cambio del
sistema;
El nmero de diferentes interfaces de
usuarios usados por el sistema;
El volumen de datos usados por el
sistema.
12/05/16
1009
Puntos clave
El desarrollo del software y evolucin ser un
simple proceso iterativo.
Las leyes de Lehman describen varias visiones
dentro de la evolucin del sistema.
Tres tipos de mantenimiento son la fijacin de
problema, modificacin del software para un nuevo
ambiente y la implementacin de nuevos
requerimientos.
Para
sistemas de hbitos, los costos de
mantenimiento normalmente usados exceden los
costos de desarrollo.
12/05/16
1010
Puntos clave
Los
procesos de evolucin se maneja por las

demandas
para
cambios
desde
los
stakeholders del sistema.
La reingeniera de software se preocupa de
reestructurar y redocumentacin para hacer
ms fcil el cambio.
El valor comercial de sistemas legados y su
calidad debe determinar la estrategia de
evolucin que es usado.
12/05/16
1011
Captulo 22
Verificacin y
Validacin
12/05/16
1012
Objetivos
Introducir
la verificacin y validacin del software

y para discutir la distincin entre ellos.
Describir el proceso de inspeccin del programa
y su rol en V & V
Explicar el anlisis esttico y como una tcnica
de verificacin
Describir el proceso de software sala limpia
12/05/16
1013
Tpicos cubiertos
Planificacin
de
verificacin
validacin
Inspecciones de software
Anlisis esttico automatizado
Desarrollo de software de sala limpia
12/05/16
1014
Verificacin vs validacin
Verificacin:
Somos nosotros construyendo el derecho
del producto.
El
software debe estar conforme a su
especificacin.
Validacin:
Somos nosotros construyendo el
producto correcto.
El software debe hacer lo que el usuario
realmente requiere.
12/05/16
1015
El proceso V & V
Es
un proceso de ciclo de vida entero V & V

debe ser aplicado para cada estado en el
proceso de software.
Tiene dos objetivos principales
El descubrimiento de los defectos del
sistema;
La valoracin de que si el sistema es o no
til y usable en una situacin operacional.
12/05/16
1016
Metas de V & V
La
verificacin y validacin deben establecer la

confianza de que el software es capaz de cumplir
sus propsito.
Esto NO significa que est completamente libre
de defectos.
Mas bien, debe ser lo bastante bueno para su
uso proyectado y el tipo de uso ser determinado
por el grado de confianza que se necesita.
12/05/16
1017
Confianza de V & V
Depende del propsito del sistema, las expectativas del usuario

y el ambiente de comercializacin
Funcin del software
El nivel de confianza depende de cun crtico es el
software a la organizacin.
Expectativas del usuario
Los usuarios pueden tener altas expectativas de ciertos
tipos de software.
Ambiente de la comercializacin
Conseguir un producto para comercializarlo temprano
puede ser ms importante que encontrar defectos en el
programa.
12/05/16
1018
Verificacin esttica y
dinmica
12/05/16
Inspecciones de software. Concierne al anlisis e la

representacin del sistema esttico para descubrir los
problemas (verificacin esttica)
Pueda ser completada por documento basado en
herramientas y el anlisis del cdigo
Prueba de software. Concierne a ejercer y observar el
comportamiento del producto observado (verificacin
dinmica)
El sistema es ejecutado con datos de prueba y su
comportamiento operacional es observado.
1019
V&V esttico y dinmico

Inspecciones
Inspecciones
de
desoftware
software
Especificacin
Especificacinde
de
requerimientos
requerimientos
Diseo
Diseode
de
alto
nivel
alto nivel
Especificacin
Especificacin
formal
formal
Prototipado
Prototipado
12/05/16
Diseo
Diseo
detallado
detallado
Programa
Programa
Prueba
Pruebade
de
programa
programa
1020
Prueba de programa
Puede
revelar la presencia de errores NO su

ausencia.
La
nica tcnica de validacin para los
requerimientos no funcionales puesto que el
software tiene que ser ejecutada para ver cmo
se comporta.
Debe ser usado en conjuncin con verificacin
esttica para proporcionar toda la cobertura de
V&V.
12/05/16
1021
Tipos de prueba
Prueba por omisin
Las pruebas se disearon para descubrir los defectos del
sistema.
Una prueba por omisin exitosa es uno que revela la
presencia de defectos en un sistema.
Cubierto en el Captulo 23.
Prueba de validacin
Pensado
para mostrar que el software rene sus
requerimientos.
Una prueba exitosa es una que muestra que unos
requerimientos se han implementado propiamente.
12/05/16
1022
Prueba y depuracin
La prueba y depuracin son procesos distintos.
La verificacin y la validacin se preocupan por
establecer la existencia de defectos en un
programa
La depuracin se preocupa por localizar y
reparar estos errores.
La depuracin involucra la formulacin de una
hiptesis sobre el comportamiento del
programa, entonces se prueban estas hiptesis
para encontrar el error del sistema.
12/05/16
1023
El proceso de depuracin
Resultados
Resultados
de
deprueba
prueba
Localizar
Localizar
error
error
12/05/16
Especificacin
Especificacin
Disear
Disear
reparacin
reparacinde
de
error
error
Casos
Casosde
de
prueba
prueba
Reparar
Reparar
error
error
Programa
Programade
de
reprueba
reprueba
1024
Planificacin V & V
La planificacin cuidadosa es requerida para
conseguir lo ms fuera de pruebas y procesos de
inspeccin.
La planificacin debe empezar temprano en el
proceso de desarrollo.
El plan debe identificar el equilibrio entre la
verificacin esttica y prueba.
La planificacin de prueba est
alrededor de
definicin de estndares para el proceso de prueba
en lugar de la descripcin de pruebas del producto.
12/05/16
1025
El modelo V de desarrollo
Especificacin
Especificacinde
de
requerimientos
requerimientos
Plan
Plande
de
prueba
pruebade
de
aceptacin
aceptacin
Servicio
Servicio
12/05/16
Especificacin
Especificacin
del
delsistema
sistema
Diseo
Diseodel
del
sistema
sistema
Plan
Plande
deprueba
prueba
de
integracin
de integracin
del
delsistema
sistema
Prueba
Pruebade
de
aceptacin
aceptacin
Diseo
Diseo
detallado
detallado
Plan
Plande
deprueba
prueba
de
integracin
de integracin
del
delsubsistema
subsistema
Prueba
Pruebade
de
integracin
integracin
del
delsistema
sistema
Mdulo
Mduloyy
unidad
unidadde
de
cdigo
y
cdigo y
prueba
prueba
Prueba
Pruebade
de
integracin
integracindel
del
subsistema
subsistema
1026
La estructura de un plan
de prueba de software
El
proceso de prueba.
Trazabilidad de requerimientos.
Artculos probados.
Programacin de prueba.
Los procedimientos magnetofnicos.
Requerimientos de hardware y software.
Restricciones.
12/05/16
1027
El plan de prueba de software

Una descripcin de las fases mayores del proceso de la comprobacin. stos podran ser como descrito
antes en este captulo.
La trazabilidad de requerimientos
Los usuarios son los ms interesados en que el sistema rena sus requerimientos y la prueba debe
planificarse de modo que todos los requerimientos se prueben individualmente.
Los artculos probados
Deben especificarse los productos del proceso del software que sern probados.
La programacin de prueba
Una programacin de la prueba global y la asignacin del recurso para esta programacin. Esto,
obviamente, se une a la programacin del desarrollo de proyecto ms general.
Procedimientos magnetofnicos de prueba
Simplemente no es bastante para ejecutar las pruebas. Deben grabarse los resultados de las pruebas
sistemticamente. Debe ser posible intervenir en el proceso de prueba para verificar que se llevar a
cabo correctamente.
Los requerimientos de hardware y software
Esta seccin debe presentar las herramientas del software requeridas y debe estimar la utilizacin del
hardware.
Las restricciones
Deben preverse las restricciones que afectan el proceso de prueba como las escasez de personal en
esta seccin.
12/05/16
1028
Inspecciones de software
stos involucran a las personas que examinan la
representacin de la fuente con el objetivo de descubrir
anomalas y defectos.
Las inspecciones no requieren la ejecucin de un
sistema, de modo que pueden ser usados antes de la
implementacin.
Ellos pueden aplicarse a cualquier representacin del
sistema
(requerimientos,
diseo,
datos
de
configuracin, datos de prueba, etc.).
Ellos se han mostrado para ser una tcnica efectiva
para el descubrimiento de errores de programa.
12/05/16
1029
El xito de la inspeccin
Muchos
defectos diferentes pueden ser

descubiertos en una sola inspeccin. En la
prueba, un defecto, puede enmascaran a otro de
modo que se requieren varias ejecuciones.
El reuso del dominio y el conocimiento de la
programacin, de modo que los revisores
probablemente habrn visto los tipos de error
que normalmente surgen.
12/05/16
1030
Inspecciones y pruebas
Las
inspecciones y pruebas son complementarias

y no se oponen las tcnicas de verificacin.
Ambas pueden se usadas en el proceso V & V.
Las inspecciones pueden verificar la conformidad
con una especificacin, pero no la conformidad
con los requerimientos reales del cliente.
Las
inspecciones no pueden verificar las
caractersticas
no
funcionales
como
el
desempeo, la utilidad, etc.,
12/05/16
1031
Inspecciones de programa
Aproximacin
formalizada
para
documentar
revisiones.
Propuesto explcitamente para la deteccin de
defectos (no correccin).
Los
defectos pueden ser errores lgicos,
anomalas en el cdigo que podran indicar una
condicin errnea (Por ejemplo, una variable no
inicializada) o incumplimiento de los estndares.
12/05/16
1032
Pre-condiciones de la inspeccin
Una especificacin precisa debe estar disponible.

Los miembros del equipo deben estar familiarizados con los
estndares de la organizacin.
Cdigo sintcticamente correcto u otras representaciones
del sistema deben estar disponibles.
Una lista de control de error debe estar preparada.
La gestin debe aceptar que la inspeccin aumentar los
costos tempranamente en el proceso de software.
La gestin no debe usar inspecciones para la apreciacin
personal, esto es, encontrar fuera de los que cometen
errores.
12/05/16
1033
El proceso de inspeccin
Planificacin
Planificacin
Vista
Vistaglobal
global
Seguir
Seguiraa
Preparacin
Preparacin
individual
individual
Retrabajo
Retrabajo
Reunin
Reuninde
de
inspeccin
inspeccin
12/05/16
1034
Procedimiento de
inspeccin
La vista global del sistema presentada por el
equipo de inspeccin.
El cdigo y los documentos asociados son
distribuidos de antemano al equipo de inspeccin.
La
inspeccin tiene lugar y los errores
descubiertos son anotados.
Las modificaciones son hechas para reparar los
errores descubiertos.
La reinspeccin puede o no ser requerida.
12/05/16
1035
Roles de la inspeccin
Autor
o El programador o diseador responsable para producir el
propietario programa o documento. Responsable por arreglar defectos
descubiertos durante el proceso de inspeccin.
Inspector
Encuentra los errores, omisiones e inconsistencias en los

programas y documentos. Tambin pueda identificar problemas
ms extensos que estn fuera del alcance del equipo de la
inspeccin.
Lector
Presenta el cdigo o documenta en una reunin de inspeccin.
Escriba
Registra los resultados de la reunin de inspeccin.
Presidente Maneja el proceso y facilita la inspeccin. Informa los resultados

del proceso al moderador Principal.
o
moderador
Moderador
principal
12/05/16
Responsable por las mejoras de proceso inspeccin,

actualizacin de la lista de control, desarrollo de los estndares,
etc.
1036
Listas de revisin de la
inspeccin
La lista de control de errores comunes debe ser usado
para manejar la inspeccin.
Las listas de revisin de errores son programadas en
un lenguaje dependiente y refleja los errores
caractersticos que son probables de levantarlos en el
lenguaje.
In general, el dbil comprobacin de tipo, el mayor
de la lista de control.
Ejemplos: Inicializacin, denominacin Constante,
terminacin del bucle, lmites de arreglos, etc.
12/05/16
1037
Revisiones de inspeccin 1
Fallas de datos
Todas las variables del programa se inicializan antes de que sus valores
sean usados?
Se han nominado todas las constantes?
Debe el lmite superior de arreglos ser igual al del arreglo o Tamao -1?
Si las cadenas de carcter son usadas, hay un delimitador explcitamente
asignado?
Hay cualquier posibilidad de desborde de memoria intermediaria?
Fallas de control
Para cada estamento condicional, la condicin es correcta?

Hay seguridad de terminar cada bucle?
Se ponen correctamente entre parntesis las declaraciones compuestas?
En los estamentos case, son considerados todos los posibles casos for?
Si una interrupcin es requerida despus de cada caso en los estamentos
case, han sido incluidos?
Fallas
Entrada/Salida
12/05/16
de
Todas las variables de entrada son usados?

Se asignan valores a todas las variables de salida antes de que ellos sean
salidas?
Las entradas inesperadas pueden causar corrupcin?
1038
Revisiones de inspeccin 2
Fallas de interfaz
Todas las funciones y llamadas del mtodo tienen el

nmero correcto de parmetros?
Los tipos del parmetro formales y reales emparejan?
Estn los parmetros en el orden correcto?
Si los accesos a los componentes de memoria son
compartidos, tienen ellos el mismo modelo de estructura
de memoria compartida?
Fallas de manejo Si una estructura enlazada es modificada, todos los enlaces

de
han sido correctamente reasignadas?
almacenamiento
Si el almacenamiento dinmico es usado, el espacio se ha
asignado correctamente?
Es el espacio explcitamente desasignado despus de que
ya no se le requiere?
Fallas de manejo Todas las posibles condiciones de error se han tenido en
de excepciones
cuenta?
12/05/16
1039
Proporcin de inspeccin
500 estamentos /hora durante la vista global.
125
estamentos fuente /hora durante la
preparacin individual.
90-125
estamentos
/hora
pueden
inspeccionados.
La inspeccin, por consiguiente, es un proceso
caro.
Los
costos de inspeccionar 500 lneas
aproximadamente esfuerzo de 40 horas/hombre
aproximadamente 2800 a la proporcin del
Reino Unido.
12/05/16
1040
Anlisis esttico
automatizado
Los
analizadores automticos son herramientas

de software para el procesamiento de texto
fuente.
Ellos analizan el texto del programa e intentas
descubrir
las
condiciones
potencialmente
errneas y traer la atencin de estos al equipo V
& V.
Ellos son muy eficaces como una ayuda a las
inspecciones ellos son un suplemento, pero no
un reemplazo para las inspecciones.
12/05/16
1041
Revisiones del anlisis

esttico
Clases de falla
Fallas de datos
Variables usadas antes de la inicializacin.

Variables declaradas pero no usadas.
Variables asignadas dos veces pero
asignaciones.
Posibles violaciones de lmites de arreglos.
Variables no declaradas.
Fallas de control
Fallas
entrada/salida
Revisin de anlisis esttico
nunca
usados
entre
Cdigo inalcanzable.
Bifurcaciones sin condicin en los bucles.
de Variables de salida repetidas sin asignacin intermedia.
Fallas de interfaz
Tipos de parmetros desiguales.

Nmero de parmetros desiguales.
Resultados de funciones no usadas.
Funciones y procedimientos no llamados.
Fallas de manejo Punteros no asignados.

de
Aritmtica de punteros.
almacenamiento
12/05/16
1042
Fases de anlisis esttico

Anlisis
de flujo de control. Revisa bucles con

salida mltiple puntos de entrada, halla cdigo
inalcanzable, etc.
Anlisis de uso de datos. Detecta variables no
inicializadas, variables escritas dos veces sin una
asignacin intermedia, variables que son
declaradas pero nunca usadas, etc.
Anlisis de interfaz. Revisa la consistencia de
rutina y declaraciones de procedimientos y su uso.
12/05/16
1043
Fases de anlisis esttico

Anlisis
de flujo de informacin. Identifica las

dependencias de variables de salida. No detecta
anomalas, por si misma pero resalta informacin
para inspeccin de cdigo o revisin.
Anlisis de camino. Identifica caminos a travs
del programa y conjuntos fuera de los estamentos
ejecutados en ese camino. Nuevamente es
potencialmente til en el proceso de revisin.
Ambas
fases generan gran cantidad de
informacin. Ellas deben usarse con cuidado.
12/05/16
1044
Anlisis esttico LINT

138% more lint_ex.c
#include <stdio.h>
printarray (Anarray)
int Anarray;
{ printf(%d,Anarray); }
main ()
{
int Anarray[5]; int i; char c;
printarray (Anarray, i, c);
printarray (Anarray) ;
}
139% cc lint_ex.c
140% lint lint_ex.c
lint_ex.c(10): warning: c may be used before set
lint_ex.c(10): warning: i may be used before set
printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10)
printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10)
printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11)
printf returns value which is always ignored
12/05/16
1045
Uso de anlisis esttico

Particularmente
valioso cuando un
lenguaje como C usa comprobacin de
tipos dbil y muchos errores no son
detectados por el compilador.
Menos rentable para lenguajes como
Java que tienen comprobacin fuerte de
tipos y puede, por consiguiente,
detectar muchos errores durante la
compilacin.
12/05/16
1046
Verificacin y mtodos formales

Los
mtodos formales pueden ser usados

cuando una especificacin matemtica del
sistema se produce.
Ellos son la ltima tcnica de verificacin tcnica.
Ellos involucran anlisis matemtico detallado de
la
especificacin
y
pueden
desarrollar
argumentos formales que un programa conforme
a su especificacin matemtica.
12/05/16
1047
Argumentos para mtodos

formales
La
produccin de una especificacin formal

requiere un anlisis detallado de los
requerimientos y esto es probablemente
para destapar errores.
Ellos
pueden detectar errores de
implementacin antes de la prueba cuando
el programa es analizado junto con la
especificacin.
12/05/16
1048
Argumentos contra los

mtodos formales
Requiere
notacin especializada que puede

ser no entendida por los expertos del dominio.
Muy caro para desarrollar una especificacin
y y ms caro aun para mostrar que un
programa rene esa especificacin.
Puede ser posible para alcanzar el mismo
nivel de confianza en un programa ms
barato que usar tcnicas V & V.
12/05/16
1049
Desarrollo de software de
sala limpia
12/05/16
El nombre es derivado del proceso de Sala limpia en la

fabricacin de semiconductor. La filosofa es la
anulacin de defectos antes que el levantamiento de
defectos.
El proceso de desarrollo de software es basado en:
Desarrollo incremental;
Especificacin formal;
Verificacin
esttica usando argumentos de
correctitud;
Pruebas estadsticas para determinar la fiabilidad de
programas.
1050
El proceso de Sala limpia

Retrabajo de error
Especificar
Especificarelel
sistema
sistema
formalmente
formalmente
Definir
Definir
incrementos
incrementos
de
desoftware
software
Desarrollo
Desarrollode
de
perfil
perfil
operacional
operacional
12/05/16
Construir
Construir
programas
programas
estructurado
estructurado
Verificar
Verificarelel
cdigo
cdigo
formalmente
formalmente
Disear
Disear
pruebas
pruebas
estadsticas
estadsticas
Incremento
Incremento
integrado
integrado
Probar
Probarsistema
sistema
integrados
integrados
1051
Caractersticas del
proceso de Sala limpia
Especificacin formal usando un modelo de
transicin de estado.
Desarrollo incremental donde el cliente prioriza los
incrementos.
Programacin estructurada control limitado y
estructuras de abstraccin son usados en el
programa.
Verificacin esttica usando inspecciones rigurosas.
La prueba estadstica del sistema (cubierto en el
Cap. 24 ).
12/05/16
1052
Especificacin formal e
inspecciones
El
modelo basado en estado es una

especificacin de sistema y el proceso de
especificacin revisa el programa contra este
modelo.
La aproximacin de programacin es definida de
modo que la correspondencia entre el modelo y
el sistema est claro.
Los argumentos matemticos (no las pruebas)
son usados para aumentar la confianza en el
proceso de inspeccin.
12/05/16
1053
Los equipos del proceso

de sala limpia
Equipo de especificacin. Responsable del desarrollo

y mantenimiento de la especificacin del sistema.
Equipo de desarrollo. Responsable para desarrollar y
verificar el software. El software es NO ejecutado o
iguala compilado durante el proceso.
Equipo de certificacin. Responsable para desarrollar
un conjunto de pruebas estadsticas para ejercitar el
software antes del desarrollo. Los modelos de
crecimiento de fiabilidad usados para determinar si la
fiabilidad es aceptable.
12/05/16
1054
Evaluacin del proceso de

Sala limpia
Los resultados de usar el proceso de Sala limpia ha
sido muy impresionante con pocas faltas
descubiertas en sistemas entregados.
Valoraciones
independientes muestran que el
proceso no es ms caro que otras aproximaciones.
Haba menos errores que un proceso de desarrollo
tradicional.
Sin embargo, el proceso no es usado ampliamente.
No est claro como esta aproximacin es
transformada para un ambiente con los ingenieros de
software menos experimentados o menos motivados.
12/05/16
1055
Puntos clave
La
verificacin y validacin no son la misma

cosa. La verificacin muestra la conformidad co
la especificacin; la validacin muestra que el
programa rene las necesidades del cliente.
Los planes de prueba deben prepararse para
guiar el proceso de prueba.
Las tcnicas de verificacin esttica involucra el
examen y el anlisis de un programa para
deteccin de error.
12/05/16
1056
Puntos clave
Las inspecciones de programa son muy eficaces
descubriendo errores.
El cdigo del programa en las inspecciones se verifica
sistemticamente por un equipo pequeo para localizar
las faltas del software.
Las
herramientas del anlisis estticas pueden
descubrir anomalas del programa que pueden ser una
indicacin de faltas en el cdigo.
El proceso de desarrollo de Sala limpia depende del
desarrollo incremental, comprobacin esttica y
comprobacin estadstica.
12/05/16
1057
Captulo 22
Pruebas del
software
12/05/16
1058
Objetivos
Discutir
las distinciones entre pruebas de

validacin y pruebas de defectos
Describir los principios del sistema y pruebas de
componentes
Describir estrategias para generacin de casos
de prueba de sistemas
Entender
las caractersticas esenciales de
herramientas usadas para la automatizacin de
prueba
12/05/16
1059
Tpicos cubiertos
Prueba
de sistema
Prueba de componente
Diseo de caso de prueba
Automatizacin de prueba
12/05/16
1060
Prueba de componente
Prueba de componentes de programa individuales;
Normalmente
la responsabilidad del desarrollo de
componentes (exceptuando algunas veces para sistemas
crticos);
Las pruebas son derivadas desde la experiencia de los
desarrolladores.
Prueba de sistema
Pruebas de grupos de componentes integrados para crear
un sistema o subsistema;
La responsabilidad de un equipo de prueba independiente;
Las pruebas estn basadas en una especificacin de
sistema.
12/05/16
1061
Fases de prueba
Prueba
Prueba de
de
componente
componente
Desarrollo
de software
12/05/16
Prueba
Prueba de
de
sistema
sistema
Equipo de prueba
independiente
1062
Prueba de defectos
La
meta de las pruebas es para descubrir

defectos en los programas.
Una prueba de defecto exitosa es una
prueba que causa un programa para
comportarse de una manera anmala.
La prueba muestra la presencia no la
ausencia de defectos.
12/05/16
1063
Metas del proceso de

prueba
Prueba de validacin
Para demostrar al desarrollador y al cliente del sistema que el
software rene los requerimientos;
Una prueba exitosa muestra que el sistema opera como ha sido
proyectado.
Prueba de defectos
Para descubrir fallas o defectos en el donde su comportamiento
es incorrecto o no est en conformidad con su especificacin;
Una prueba exitosa es una prueba que hace que el sistema tena
tenga desempeo incorrecto y as exponga un defecto en el
sistema.
12/05/16
1064
El proceso de prueba del sistema
Casos
Casosde
de
prueba
prueba
Diseo
Diseode
de
casos
de
casos de
prueba
prueba
12/05/16
Datos
Datosde
de
prueba
prueba
Preparar
Preparar
datos
datos de
de
prueba
prueba
Resultados
Resultados
de
deprueba
prueba
Ejecutar
Ejecutar
programa
programacon
con
datos
de
datos de
prueba
prueba
Informes
Informes
de
deprueba
prueba
Preparar
Preparar
datos
datos de
de
prueba
prueba
1065
Polticas de prueba
Slo una prueba exhaustiva puede mostrar si un

programa est libre de defectos. Sin embargo, una
prueba exhaustiva es imposible.
Las polticas de prueba define la aproximacin para ser
usada en la seleccin de pruebas de sistema:
Todas las funciones accedidas a travs de mens
deben ser probadas;
Las combinaciones de funciones accedidas a travs
del mismo men deben ser probadas;
Donde la entrada de usuario es requerida, todas las
funciones deben ser probadas con entradas correctas
e incorrectas.
12/05/16
1066
Prueba de sistema
Involucra la integracin de componentes para crear un
sistema o subsistema.
Puede involucrar la prueba de un incremento a a ser
entregado al cliente.
Dos fases:
Prueba de integracin el equipo de prueba tiene
acceso para el cdigo fuente del sistema. El sistema es
probado conforme los componentes son integrados.
Prueba de lanzamiento el equipo de prueba, prueba
el sistema completo para ser entregado como una caja
negra.
12/05/16
1067
Prueba de integracin
Involucra la construccin de un sistema desde sus

componentes y pruebas para problemas que se levantan de
las interacciones de componentes.
Integracin de Arriba-abajo (Top-down)
Desarrollar el esqueleto del sistema y poblarlo con los
componentes.
Integracin de Abajo-arriba (Bottom -up)
Integrar los componentes de infraestructura que entonces
agregan componentes funcionales.
Para simplificar la localizacin de error, los sistemas
debern ser integradas incrementalmente.
12/05/16
1068
Prueba de integracin
incremental
AA
BB
TT
11
TT
22
TT
33
12/05/16
AA
BB
CC
TT
11
AA
TT
22
BB
TT
33
CC
TT
44
DD
TT
11
TT
22
TT
33
TT
44
TT
55 1069
Aproximacin de
prueba
Validacin arquitectnica
Las pruebas de integracin de Arriba-abajo son buenas para
descubrir errores en la arquitectura del sistema.
Demostracin de sistema
Las pruebas de integracin de Arriba-abajo permiten una
demostracin limitada en un estado temprano en el
desarrollo.
Implementacin de prueba
A menudo es ms fcil una prueba de integracin de Abajoarriba.
Observacin de prueba
Problemas con ambas aproximaciones. Puede ser requerido
cdigo extra para observar pruebas.
12/05/16
1070
Pruebas de lanzamiento
El
proceso de probar un lanzamiento de un sistema

que ser distribuido a los clientes.
La meta primaria es incrementar la confianza de los
proveedores
que
el
sistema
rene
sus
requerimientos.
La prueba de lanzamiento es normalmente una caja
negra o prueba funcional
Basado slo en la especificacin del sistema.
Los probadores no tienen conocimiento de la
implementacin del sistema.
12/05/16
1071
Prueba de caja negra

Entrada de
datos de
prueba
Ie
Las entradas causan

comportamiento
anmalo
Sistema
Sistema
Salida de
resultados de
prueba
12/05/16
Oe
Las salidas que

revelan la presencia de
defectos
1072
Directrices de prueba
Las directrices de prueba son indicaciones para el equipo de

prueba para ayudar a escoger pruebas que revelarn defectos
en el sistema
Escoger entradas que fuercen al sistema para generara todos
los mensajes de error;
Disear entradas que causan memorias intermediarias para
el desborde Design;
Repetir las mismas entradas o series entradas en varios
tiempos;
Forzar salidas invlidas para ser generadas;
Forzar resultados de computacin para ser demasiada
grandes o demasiada pequeas.
12/05/16
1073
Escenario de prueba
Una estudiante en Escocia est estudiando la Historia Americana y se le ha
pedido escribir un documento "La mentalidad de la frontera en el Oeste
Americano de 1840 a 1880 ". Para hacer esto, ella necesita encontrar las
fuentes de un rango de bibliotecas. Ella se registra en el sistema LIBSYS y
usa la facilidad de bsqueda para descubrir si puede acceder los
documentos originales de ese tiempo. Ella descubre las fuentes en varias
bibliotecas universitarias de EE.UU., y descarga copias de algunas de
stas. Sin embargo, para un documento, ella necesita tener la confirmacin
de su universidad que es una estudiante genuina y el uso es para
propsitos no comerciales. La estudiante, entonces, usa la facilidad en
LIBSYS de que puede solicitar tal permiso y registrar. Si es concedido, el
documento se transmitir al servidor registrado de la librera y es impreso
para ella. Ella recibe un mensaje de LIBSYS que le dice que ella recibir un
mensaje del correo electrnico cuando el documento impreso est
disponible para la coleccin.
12/05/16
1074
Pruebas de sistema
1. Probar el mecanismo de registro usando registros correctos e
incorrectos para verificar que los usuarios vlidos se aceptan y
los usuarios invlidos se rechazan
2. Probar la facilidad de bsqueda que usando diferentes consultas a
las fuentes conocidas para verificar que el mecanismo de
bsqueda est realmente encontrando los documentos .
3. Probar la facilidad de presentacin del sistema, para verificar que
que esa informacin sobre los documentos sea desplegada
propiamente.
4. Probar el mecanismo para pedir el permiso para descargar.
5. Probar que la respuesta por correo electrnico que indica que el
documento transmitido est disponible.
12/05/16
1075
Casos de uso
Los
casos de uso pueden ser una base para

derivar pruebas para el sistema. Ellos ayudan
a identificar las operaciones a ser probadas y
ayuda a disear los casos de prueba
requeridos.
Desde un diagrama de secuencia asociado,
las entradas y salidas asociadas a ser
creadas para las pruebas pueden ser
identificadas.
12/05/16
1076
Recolectar el diagrama de
secuencia de datos del tiempo
: Usuario
: ControladorComandos
: EstacinTiempo
: DatosTiempo
1: Demanda (informe)
2: Reconocer()
3: Informe()
4: Resumir()
5:
6: Enviar(informe)
7: Responder(informe)
8: Reconocer
12/05/16
1077
Prueba de desempeo
Parte
de la prueba de lanzamiento puede

involucrar prueba de propiedades emergentes de
un sistema como el desempeo y la fiabilidad.
Normalmente
las pruebas de desempeo
involucra la planificacin de una serie de pruebas
donde la carga es incrementada firmemente
antes de que el desempeo del sistema se haga
aceptable.
12/05/16
1078
Prueba de stress
Practicar el sistema ms all de su carga de diseo

mxima. Estresar el sistema a menudo causa defectos a
ser descubiertos.
Estresando el sistema se prueba el comportamiento de
falla. Los sistemas no fallarn catastrficamente. La
prueba de stress verifica la prdida inaceptable del
servicio o de datos.
La prueba del stress es particularmente relevante para
sistemas distribuidos que puede exhibir degradacin
severa como una sobrecarga en la red.
12/05/16
1079
Prueba de componentes
Las pruebas de componente o unidad es el
proceso de prueba de componentes individuales
en aislamiento.
Es un proceso de pruebas de defecto.
Los componentes pueden ser:
Funciones individuales o mtodos dentro de un
objeto;
Clases de objetos con varios atributos y
mtodos;
Los componentes compuestos con interfaces
definidas se usan para acceder s funcionalidad.
12/05/16
1080
Prueba de clase de objetos

La
cobertura de prueba completa de una clase

involucra
Prueba de todas las operaciones asociadas con
un objeto;
Fijar e interrogar a todos los atributos del objeto;
Practicar el objeto en todos sus posibles estado.
La herencia hace ms difcil el diseo de pruebas
de clases de objetos puesto que la la informacin
as ser probada no es localizada.
12/05/16
1081
Interfaz de objeto estacin de

tiempo
EstacinTiempo
Indentificador
InformeTiempo()
Calibrar(instrumento)
Prueba()
Iniciar(instrumento)
Cerrar(instrumento)
12/05/16
1082
Prueba de estacin de tiempo

Necesita
definir los casos de prueba pata

informeTiempo, calibrar, probar, iniciar y cerrar.
Usando
un modelo de estado, identificar
secuencias de transiciones de estado para ser
probados y las secuencias de eventos para causar
estas transiciones
Por ejemplo:
Esperando -> Calibrando -> Probando ->
Transmitiendo ->Esperando
12/05/16
1083
Prueba de interfaz
Los
objetivos son detectar fallas debidas a

errores de interfaz o asunciones invlidas
acerca de las interfaces.
Particularmente
importante
para
el
desarrollo orientado a objetos de modo que
los objetos son definidos por sus interfaces.
12/05/16
1084
Prueba de interfaz
Casos
Casosde
de
prueba
prueba
12/05/16
1085
Tipos de interfaz
12/05/16
Interfaces de parmetro
Datos pasados de un procedimiento a otro.
Interfaces de memoria compartida
El
bloque de memoria es compartido entre
procedimientos o funciones.
Interfaces procedimentales
Los
subsistemas
encapsulan
un
conjunto
de
procedimientos para ser llamados por otros subsistemas.
Interfaces de paso de mensajes
Los
subsistemas solicitan servicios desde otros
subsistemas.
1086
Errores de interfaz
Mal uso de interfaz

Un componente de oficio llama a otro componente y
comete un error en el uso de su interfaz. Por ejemplo, los
parmetros en un mal pedido.
Equivocacin de la interfaz
Un componente de oficio incluye asunciones acerca del
comportamiento del componente llamado que es incorrecto.
Errores de cronometraje
La llamada y los componentes llamados operan a
diferentes velocidades y la informacin anticuada es
accedida.
12/05/16
1087
Directrices de pruebas de
interfaz
Disear pruebas de modo que los parmetros a un
procedimiento llamado estn en los extremos finales de
sus rangos.
Siempre los parmetros de punteros a pruebas con
punteros nulos.
Disear pruebas que causan el componente para fallar.
Usar las pruebas de stress en los sistemas de paso de
mensajes.
En los sistemas de memoria compartida, variar el orden
en que se activan los componentes.
12/05/16
1088
Diseo de casos de prueba

Involucra el diseo de los casos de pruebas
(entradas y salidas) usados para probar el sistema.
La meta del diseo de casos de prueba es crear un
conjunto de pruebas que son efectivas en la
validacin y pruebas de deteccin.
Aproximaciones de diseo:
Prueba basada en requerimientos;
Prueba de particin;
Prueba estructural.
12/05/16
1089
Prueba basada en
requerimientos
Un
principio general de la ingeniera de

requerimientos es que los requerimientos
deben ser probables (ser sometidos a
prueba).
La prueba basada en requerimientos es
una tcnica de prueba de validacin donde
se considera cada requerimiento y deriva
un conjunto de prueba por ese
requerimiento.
12/05/16
1090
Requerimientos de LIBSYS
El usuario podr investigar cualquiera de todo el
conjunto inicial de bases de datos o seleccionar un
subconjunto de l.
El sistema mantendr a los visualizadores
apropiados para que el usuario lea los documentos
en el almacn del documento.
Cada orden se asignar un nico identificador
(ID_PEDIDO) que el usuario podr copiar al rea del
almacenamiento permanente de la cuenta.
12/05/16
1091
Pruebas de LIBSYS
Iniciar la bsqueda de usuario para bsquedas de artculos que se
conocen y estn presentes y otros conocidos que no estn presenten,
dnde el conjunto de bases de datos incluye 1 base de datos.
Iniciar las bsquedas de usuario para artculos que se conocen y estn
presentes y otros conocidos que no estn presentes, dnde el conjunto
de bases de datos incluyen 2 bases de datos.
Iniciar las bsquedas de usuario para artculos que se conocen y estn
presentes y otros conocidos que no estn presentes, donde el conjunto
de bases de datos incluyen ms de 2 bases de datos.
Seleccionar una base de datos del conjunto de bases de datos e iniciar
bsquedas de usuario para artculos que se conocen y estn presentes y
otros conocidos que no estn presentes,
Seleccionar ms de una base de datos del conjunto de bases de datos e
iniciar bsquedas para artculos que se conocen y estn presentes y
otros conocidos que no estn presentes.
12/05/16
1092
Prueba de particin
Los
datos de entrada y resultados de salida a

menudo a menudo caen a menudo dentro de
diferentes clases donde los miembros de una
clase estn relacionados.
Cada una de estas clases es una particin de
equivalencia o dominio donde el programa se
comporta en una manera equivalente para cada
miembro de clase.
Los caos de prueba deben ser escogidos de cada
particin.
12/05/16
1093
Particin de equivalencia
Entradas
invlidas
Entradas
vlidas
Sistema
Sistema
Salidas
12/05/16
1094
Particiones de equivalencia
3
Menor que 4
11
10
Entre 4 y 10 Mayor que 10
Nmero de valores de entrada

9999
10000
Menor que 10000

Valores de entrada
12/05/16
50000
100000
99999
Entre 10000 y
99999
Mayor que 99999
1095
Especificacin de rutina de
bsqueda
procedure Search (Key : ELEM ; T: SEQ of ELEM;
Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pre-condition
-- la sucesin tiene al menos un elemento
TFIRST <= TLAST
Post-condition
-- el elemento es encontrado y es referenciado por
L
( Found and T (L) = Key)
or
-- el elemento no est en el arreglo
( not Found and
12/05/16
Silva Delgado - Ing. Ivan Pino Tellera
not (existsIng.i,Otoniel
TFIRST
>= i <= TLAST, T (i) = Key )) 1096
Rutina de bsqueda
particiones de entrada
Entradas
que
conforman
a
precondiciones.
Entradas donde una precondicin no
lleva a cabo.
Entradas donde el elemento clave es
miembro del arreglo.
Entradas donde el elemento clave no
miembro del arreglo
12/05/16
las
se
un
es
1097
Directivas de prueba
(secuencias)
Probar
el software con secuencias que tienen

un solo valor.
Usar secuencias de diferentes tamaos en
diferentes pruebas.
Derivar pruebas de modo que el primero,
medio y ltimo elementos de la secuencia
son accedidos.
Probar con secuencias de longitud cero.
12/05/16
1098
Rutina de bsqueda
particiones de entrada
Secuencia
Un slo valor
Un slo valor
Ms de un valor
Ms de un valor
Ms de un valor
Ms de un valor
Elemento
En secuencia
No en secuencia
Primer elemento en la secuencia
ltimo elemento en la secuencia
Elemento central en la secuencia
No en secuencia
Secuencia de entrada (T)

17
17
17, 29, 21, 23
41, 18, 9, 31, 30, 16, 45
17, 18, 21, 23, 29, 41, 38
21, 23, 29, 33, 38
12/05/16
Clave(clave)
17
0
17
45
23
25
Salida(Encontrar, L)
Verdadero, 1
Falso, ??
Verdadero, 1
Verdadero, 7
Verdadero, 4
Falso, ??
1099
Prueba estructural
Algunas
veces llamada prueba de caja negra.

La derivacin de casos de prueba of test cases
de acuerdo a la estructura de un programa. El
conocimiento de un programa es usado para
identificar casos de prueba adicionales.
El objetivo es aplicar todos los estamentos del
programa (no todas las combinaciones de
camino).
12/05/16
1100
Prueba estructural
Datos
Datosde
de
prueba
prueba
Prueba
Deriva
Cdigo
Cdigo de
de
componente
componente
12/05/16
Salida
Salidade
de
prueba
prueba
1101
Bsqueda binaria particiones

de equivalencia
Pre-condiciones satisfechas, elemento clave en el
arreglo.
Pre-condiciones satisfechas, elemento clave no en el
arreglo.
Pre-condiciones insatisfechas, elemento clave en el
arreglo.
Pre-condiciones insatisfechas, elemento clave no en el
arreglo
Arreglo de entrada tiene un solo valor.
Arreglo de entrada tiene un nmero par de valores.
Arreglo de entrada tiene un nmero impar de valores.
12/05/16
1102
Bsqueda binaria
particiones de equivalencia
Lmites de clases de equivalencia
Elementos < Medio
Elementos > Medio
Punto medio
12/05/16
1103
Bsqueda binaria casos

de prueba
Arreglo de entrada (T)
17
17
17, 21, 23, 29
9, 16, 18, 30, 31, 41, 45
17, 18, 21, 23, 29, 38, 45
17, 18, 21, 23, 29, 33, 38
12, 18, 21, 23,32
21, 23, 29, 33, 38
12/05/16
Clave(clave)
Salida(Encontrar, L)
17
0
17
45
23
21
23
25
Verdadero, 1
Falso, ??
Verdadero, 1
Verdadero, 7
Verdadero, 4
Verdadero, 3
Verdadero, 4
Falso, ??
1104
Prueba de camino
El
objetivo de la prueba de camino es para

asegurar que el conjunto de casos de prueba es
tal que cada camino a travs del programa es
ejecutada por lo menos una vez.
El punto de partida de la prueba de camino es un
grafo de flujo de programa que muestra nodos
representando decisiones de programa y arcos
representado el flujo de control.
Los estamentos con condiciones son, por
consiguiente nodos en el grafo de flujo.
12/05/16
1105
Grafo de flujo de
bsqueda binaria
1
9
1
1
4
4
12/05/16
MIENTRAS fondo<= tope
fondo > tope
elemArreglo[mid] =
clave
elemArreglo[mid] !=
clave
elemArreglo[mid] >
clave
1
1
2
2
1
1
1
1
elemArreglo[mid] <
clave
1
1
3
3
1
1
0
0
1106
Caminos independientes
1,
2, 3, 4, 5, 6, 7, 8, 9, 10, 14
1, 2, 3, 4, 5, 14
1, 2, 3, 4, 5, 6, 7, 11, 12, 5,
1, 2, 3, 4, 6, 7, 2, 11, 13, 5,
Los casos de prueba deben ser derivados de
modo que esos caminos sean ejecutados.
Un analizador de programa dinmico puede ser
usado para verificar que los caminos sean bien
ejecutados.
12/05/16
1107
Automatizacin de prueba
La
prueba es una fase del proceso cara. Los

bancos de trabajo de prueba proporcionan un
rango de herramientas para reducir el tiempo
requerido y los costos de prueba totales.
Los sistemas como Junit soportan la ejecucin
automtica de pruebas.
Ms bancos de trabajo de prueba son sistemas
abiertos porque las necesidades de prueba son
especficas de una organizacin.
Ellas son a veces difciles de integrar con diseo
cerrado y bancos de trabajo de anlisis.
12/05/16
1108
Un banco de trabajo de prueba

Especificacin
Especificacin
Generador
Generadorde
de
datos
de
prueba
datos de prueba
Cdigo
Cdigo
fuente
fuente
Analizador
Analizador
dinmico
dinmico
Informe
Informede
de
ejecucin
ejecucin
Manejador
Manejadorde
de
prueba
prueba
Programa
Programa
probado
probado
Simulador
Simulador
Datos
Datosde
de
prueba
prueba
Resultados
Resultados
de
deprueba
prueba
Oracle
Oracle
Precondiciones
Precondiciones
de
deprueba
prueba
Comparado
Comparado
r rde
dearchivo
archivo
Generador
Generadorde
de
informe
informe
12/05/16
Informe
Informede
de
resultados
resultadosde
de
prueba
prueba
1109
Adaptacin de bancos de
trabajo de prueba
Los
guiones (scripts) pueden ser desarrollados

para simuladores de interfaz de usuario y
patrones para generadores de datos de prueba.
La salidas de prueba pueden tener que ser
preparados manualmente para la comparacin.
Los comparadores de archivo de propsito
especial pueden ser desarrollados.
12/05/16
1110
Puntos clave
La prueba puede mostrar la presencia de fallas en un

sistema; no pude demostrar que no hay fallas
remanentes.
Los desarrolladores de componentes son responsables
de la prueba de componentes; la prueba de sistema es
responsabilidad de un equipo separado.
Las pruebas de integracin son incrementos de prueba
del sistema; la prueba de lanzamiento involucra la
prueba del sistema para ser lanzado al cliente.
Usar la experiencia y directrices para disear casos de
prueba en la prueba de defectos.
12/05/16
1111
Puntos clave
La prueba de interfaz est diseada para descubrir
defectos en las interfaces de componentes
compuestos.
La particin de equivalencia es una manera de
descubrimiento de casos de prueba debern
comportarse de la misma manera.
El anlisis estructural confa en el anlisis de un
programa y derivar las pruebas a partir de este
anlisis.
La automatizacin de prueba reduce los costos de
prueba, soportando el proceso de prueba con un
rango de herramientas del software.
12/05/16
1112
Captulo 23
Validacin de
Sistemas
Crticos
12/05/16
1113
Objetivos
Explicar
cmo la fiabilidad del sistema puede ser

medida y cmo pueden usarse los modelos de
crecimiento de fiabilidad para la prediccin de la
fiabilidad
Describir los argumentos de seguridad fsica y cmo
estos sern usados
Discutir los problemas de certidumbre de seguridad
fsica
Introducir casos de seguridad fsica y cmo estos
sern usados en la validacin de la seguridad fsica
12/05/16
1114
Tpicos cubiertos
Validacin
de la fiabilidad
Certidumbre de seguridad fsica
Valoracin de la seguridad fsica
Seguridad
fsica y casos
confiabilidad
12/05/16
de
1115
Validacin de sistemas
crticos
Los costos de verificacin y validacin para sistemas

crticos involucran procesos de validacin adicional para
sistemas no crticos:
Los costos y consecuencias de falla son altos de modo
que es ms barato el hallazgo y quitar las fallas que
pagar la falla del sistema;
Se puede tener que hacer un caso formal para clientes o
para un regulador que el sistema rene sus
requerimientos de confiabilidad. Este caso de
confiabilidad puede requerir actividades V & V
especficas para ser llevadas a cabo.
12/05/16
1116
Costos de validacin
Debido
a las actividades adicionales

involucradas, los costos de validacin para
sistemas
crticos
son
normalmente
significativamente altos que para los
sistemas no crticos.
Normalmente, los costos V & V suben ms
del 50% del total de costos del desarrollo
del sistema.
12/05/16
1117
Validacin de la
fiabilidad
La validacin de la fiabilidad involucra la prctica del

programa para evaluar si se ha alcanzado o no el nivel
requerido de fiabilidad.
Esto normalmente no puede ser incluido como parte de un
proceso de prueba de defecto, porque los datos para una
prueba de defecto es (usualmente) atpico de datos de uso
reales.
La medida de fiabilidad, por consiguiente, requiere de
conjunto de datos especialmente diseados que
reproduzcan el patrn de entradas para ser procesados por
el sistema.
12/05/16
1118
El proceso de medida de
la fiabilidad
Identificar
Identificar
perfiles
perfiles
operacionales
operacionales
12/05/16
Preparar
Preparar
conjunto
conjuntode
de
datos
de
prueba
datos de prueba
Aplicar
Aplicar
pruebas
pruebaspara
para
elelsistema
sistema
calcular
calcularlala
confiabilidad
confiabilidad
observada
observada
1119
Actividades de validacin
de fiabilidad
Establecer
el
perfil
operacional
para
el
sistema.
Construir datos de prueba que reflejan el perfil
operacional.
Probar el sistema y observar el nmero de
fallas y las veces de esas fallas.
calcular la fiabilidad despus de
que un
nmero estadsticamente significativo de
fallas han sido observadas.
12/05/16
1120
Pruebas estadsticas
Probar
el software para la fiabilidad, en lugar de la

deteccin de falla.
Medir el nmero de errores permite predecir la
fiabilidad del software. Notar que, por razones
estadsticas, ms errores que son permitidos para
que la especificacin de la fiabilidad debe ser
inducida.
Un
nivel aceptable de fiabilidad debe ser
especificado y el software probado y enmendado
hasta que el nivel de fiabilidad se alcance.
12/05/16
1121
Problemas de medida de
fiabilidad
Incertidumbre de perfil operacional
El perfil operacional no puede ser una reflexin
exacta del uso real del sistema.
Altos costos de generacin de datos de prueba
Los costos pueden ser muy altos si los datos de
prueba para el sistema no son generados
automticamente.
Incertidumbre estadstica
Se
necesita un nmero estadsticamente
significativo de fallas para calcular la fiabilidad,
pero los sistemas muy fiables raramente fallarn.
12/05/16
1122
Perfiles operacionales
Un
perfil operacional es un conjunto de datos de

prueba, cuya frecuencia compara la actual frecuencia
de esas entradas de uso normal del sistema. Una
pareja cerrada con uso real es necesario, en otro
caso, la fiabilidad medida no se reflejar en el uso
real del sistema.
Pueden ser generadas de datos reales recolectados
desde un sistema existente o (ms a menudo)
depende de asunciones hechas sobre el patrn de
uso del sistema.
12/05/16
1123
Un perfil operacional
12/05/16
1124
Generacin del perfil operacional

Debe
generarse automticamente siempre

que sea posible.
La generacin de perfil automtico es difcil
para sistemas interactivos.
Puede
ser
sincero
para
entradas
normales pero es difcil para predecir
improbables entradas y crear datos de
prueba para ellas.
12/05/16
1125
Prediccin de fiabilidad
Un modelo de crecimiento de fiabilidad es un

matemtico modelo del cambio de fiabilidad del sistema,
tal como es probada y las fallas son retiradas.
Es usado como un medio de prediccin de fiabilidad por
extrapolacin desde los datos actuales
Simplifica
la planificacin de la prueba y
negociaciones del cliente.
Se
puede predecir cuando las pruebas se
completarn y demostrarn a clientes, si alguna vez,
el crecimiento de la fiabilidad se lograr o no.
La prediccin depende del uso de pruebas estadsticas
para medir la fiabilidad de una versin del sistema.
12/05/16
1126
El crecimiento de fiabilidad
de paso igual
12/05/16
1127
Crecimiento de fiabilidad
observada
El modelo de crecimiento de paso-igual es simple, pero

normalmente no refleja la realidad.
La fiabilidad no necesariamente es creciente con el
cambio, de modo que el cambio puede introducir nuevas
fallas.
La proporcin de crecimiento de fiabilidad tiende a
reducir la velocidad con el tiempo de modo que las fallas
que ocurren frecuentemente son descubiertas y
removidas desde el software.
Un modelo de crecimiento aleatorio donde los cambios
de fiabilidad fluctan puede ser una reflexin ms exacta
de cambios reales de la fiabilidad.
12/05/16
1128
El crecimiento de fiabilidad
de paso aleatorio
Notar diferentes
mejoras de fiabilidad
12/05/16
Reparacin de falla
agregar fallas y
fiabilidad decreciente
(incremento ROCOF)
1129
Seleccin de modelo de
crecimiento
Muchos
modelos de crecimiento de fiabilidad

diferentes han sido propuestos.
No
existe
un
modelo
de
crecimiento
universalmente aplicable.
La fiabilidad debe ser medida y los datos
observados deben encajar en diferentes modelos.
El modelo ms apropiado puede, entonces, ser
usado para la prediccin de fiabilidad.
12/05/16
1130
Prediccin de fiabilidad
= Medida de
fiabilidad
Curva modelo
de fiabilidad
adecuada
Fiabilidad
requerida
Logro de tiempo
estimado de
fiabilidad
12/05/16
1131
Certidumbre de
seguridad fsica
La
certidumbre de seguridad fsica y medicin de

la fiabilidad son bastante diferentes:
Dentro de los lmites de error de medicin, se
conoce si se ha logrado o no el nivel requerido
de fiabilidad;
Sin embargo, la medicin cuantitativa de la
seguridad fsica es imposible. La certidumbre
de fiabilidad fsica se preocupa por establecer
un nivel de confianza en el sistema.
12/05/16
1132
Confianza de seguridad
fsica
La
confianza en la seguridad fsica de un sistema

puede variar de muy baja a muy alta.
La confianza se desarrolla a travs de:
Experiencia
pasada con la compaa que
desarrolla software;
El uso de procesos fidedignas y actividades del
proceso engranado a la seguridad fsica;
El V & V extensivo que incluye las tcnicas de
validacin esttica y dinmica.
12/05/16
1133
Revisiones de seguridad
fsica
Revisar
la funcin intencional correcta.

Revisar
para
la
estructura
mantenible,
entendible.
Revisar para verificar algoritmo y disear
estructura de dato contra la especificacin.
Revisar para verificar la consistencia del cdigo
con diseo de algoritmo y estructura de datos.
Revisar la suficiencia de prueba de sistema.
12/05/16
1134
Revisar la gua
Hacer el software tan simple como sea posible.
Usar las tcnicas ms simples de desarrollo de
software que evita las estructuras propensas a error,
tales como los punteros y la recursin.
Usar informacin que oculta la localizacin del efecto
de alguna corrupcin de datos.
Hacer uso apropiado de tcnicas tolerantes a fallas
pero no debe ser seducido a pensar que el software
tolerante a falla es necesariamente segura fsicamente.
12/05/16
1135
Argumentos de seguridad fsica
12/05/16
Los argumentos de seguridad fsica se han propuesto

para mostrar que el sistema no puede alcanzarse en un
estado inseguro.
Estos son ms dbiles que los argumentos de correctitud
que deben mostrar que el cdigo del sistema est
conforma a su especificacin.
Ellos generalmente estn basados en la demostracin por
contradiccin
Asume que un estado inseguro puede ser alcanzado;
Demostrar que esto es una contradiccin por el cdigo
del programa.
A modelo grfico de una argumento de seguridad fsica
puede ser desarrollado.
1136
Construccin de un argumento
de seguridad fsica
Establecer las condiciones de salida de la seguridad
fsica para un componente o un programa.
Empezando desde el FIN del cdigo, trabajar hasta
que se haya identificado todos los caminos que
llevan a la salida del cdigo.
Asumir que la condicin de salida es falso.
Mostrar que, para cada camino que lleva a la salida,
las asignaciones hicieron que ese camino contradiga
la asuncin de una salida insegura del componente.
12/05/16
1137
Cdigo de entrega de
salida
currentDose = computeInsulin () ;
// Safety check - adjust currentDose if necessary
// if statement 1
if (previousDose == 0)
{
if (currentDose > 16)
currentDose = 16 ;
}
else
if (currentDose > (previousDose * 2) )
currentDose = previousDose * 2 ;
// if statement 2
if ( currentDose < minimumDose )
currentDose = 0 ;
else if ( currentDose > maxDose )
currentDose = maxDose ;
administerInsulin (currentDose) ;
12/05/16
1138
Modelo de argumento de
seguridad fsica
Sobredosis
Sobredosis
administrada
administrada
administrarInsulina
administrarInsulina
dosisActual >
dosisActual
maxDosis >
maxDosis
o
o
Contradiccin
Pre-condicin para un
estado inseguro
Contradiccin
dosisActual > minDosis y
dosisActual > minDosis y
dosisActual <= maxDosis
dosisActual <= maxDosis
Si estamento 2 no es
Si estamento
ejecutado2 no es
ejecutado
Contradiccin
dosisActual =
dosisActual
maxDosis =
maxDosis
dosisActual = 0
dosisActual = 0
Asignar
Asignar
dosisActual = 0
dosisActual = 0
Si estamento 2
Si estamento
entonces
la rama 2es
entonces
la rama es
ejecutada
ejecutada
12/05/16
dosisActual =
dosisActual
maxDosis =
maxDosis
Si estamento 2 otra
Si
estamento
rama
alterna 2esotra
rama
alterna es
ejecutada
ejecutada
1139
Caminos de programa
Ninguna rama del if - estamento 2 es ejecutada
then (entonces) una rama del if - estamento 2 es

ejecutada
dosisActual = 0.
else (en otro caso) otra rama del if estamento 2 es

ejecutada
Slo puede pasar si dosisActual => minDosis y <= maxDosis.
dosisActual = maxDosis.
En todos los casos, las post condiciones contradicen la

condicin de inseguridad que la dosis administrada es
mayor que la maxDosis.
12/05/16
1140
Certidumbre del
proceso
La certidumbre del proceso involucra la definicin de un

proceso fidedigno y asegura que este proceso es seguido
durante el desarrollo del sistema.
Tal como es discutido en el Captulo 20, el uso de este
proceso seguro es un mecanismo para reducir las
oportunidades de error introducidos dentro del sistema.
Los accidentes son eventos raros, de modo que la prueba
puede no encontrar todos los problemas;
Los requerimientos de seguridad fsica,
a veces no
deben ser requerimientos de modo que no pueden
demostrarse a travs de la prueba.
12/05/16
1141
Actividades del proceso relacionado

con la seguridad fsica
La
creacin de un riesgo registrado y nonitoreo

del sistema.
La designacin de los ingenieros de seguridad
fsica del proyecto.
Uso extensivo de las revisiones de seguridad
fsica.
Creacin de un sistema de certificacin de
seguridad fsica.
Gestin de configuracin detallada (ver el
Captulo 29).
12/05/16
1142
Anlisis de riesgo
El
anlisis de riesgo involucra los riesgos y sus

causas de raz.
Debe haber trazabilidad clara desde los riesgos
identificados a travs del anlisis para las
acciones tomadas durante el proceso para
asegurar que estos riesgos han sido cubiertos.
Un registro de riesgo puede ser usado para
rastrear los riesgos a travs del proceso.
12/05/16
1143
Entrada de registro de
riesgo
Registro de riesgo
20/02/2003
Pgina 4: Impreso.
Sistema : Sistema de bomba de insulina

Ingeniero de seguridad: James Brown
Archivo: Bomba de Insulina/Seguridad/ RegistroRiesgo

Versin de registro: 1/3
Riesgo identificado:
Sobredosis de insulina entregada al paciente.
Identificado por:
Jane Williams
Clase crtica:
Riesgo de identificacin
Alto
rbol de falta identificado
YES Fecha
Creadores del rbol de falta
Jane Williams y Bill Smith
rbol de falta revisado
YES Fecha
24.01.99
28.01.99
Ubicacin: Registro.Riesgo.Pg 5
Revisin: James Brown.
Requerimientos de diseo de seguridad de diseo

1.
El sistema incluir software de falt prueba que probar el sistema del sensor, el reloj y el sistema de entrega de
insulina.
2.
La prueba de si mismo del software ejecutar una vez por minuto.
3.
En el evento de prueba de si mismo del software que descubre una falta en cualquiera de los componentes del
sistema, una advertencia audible se emitir y el despliegue de la bomba debe indicar el nombre del componente
dnde la falta se ha descubierto. La entrega de insulina debe suspenderse.
4.
El sistema incorporar un sistema sustituido que permite al usuario del sistema modificar la dosis computada de
insulina que ser entregada por el sistema.
5.
La cantidad de sustitucin debe limitarse para ser no mayor que un valor del prefijado que se fija cuando el
12/05/16 sistema se configura por el personal
Ing. mdico.
1144
La comprobacin de seguridad
fsica en tiempo de ejecucin
Durante
la ejecucin de programa, las revisiones

de seguridad fsica pueden ser incorporadas
como las aserciones para verificar que el
programa se est ejecutando dentro de un
sobre que opera.
Las
aserciones puede ser incluido como
comentarios (o usando un estamento de
declaracin en algunos lenguajes). El cdigo
puede ser generado automticamente para
revisar esas declaraciones.
12/05/16
1145
Administracin de insulina
con aserciones
static void administerInsulin ( ) throws SafetyException {
int maxIncrements = InsulinPump.maxDose / 8 ;
int increments = InsulinPump.currentDose / 8 ;
// asercin currentDose <= InsulinPump.maxDose
if (InsulinPump.currentDose > InsulinPump.maxDose)
throw new SafetyException (Pump.doseHigh);
else
for (int i=1; i<= increments; i++)
{
generateSignal () ;
if (i > maxIncrements)
throw new SafetyException ( Pump.incorrectIncrements);
} // bucle loop
} //administrador de Insulina
12/05/16
1146
La valoracin de
12/05/16
La valoracin de seguridad contra delitos tiene algo en

comn con la valoracin de seguridad fsica.
Se piensa que demuestra que el sistema el sistema no
puede entrar en algn estado (peligroso o un estado
inseguro) en lugar de demostrar que el sistema puede hacer
algo.
Sin embargo, hay diferencias
Los problemas de seguridad fsica son accidentales; los
problemas de seguridad contra delitos son deliberados;
Los problemas de seguridad contra delitos son ms
genricos muchos sistemas padecen los mismos
problemas; los problemas de seguridad fsica son
principalmente al dominio de aplicacin.
1147
Validacin de la
Validacin basada en la experiencia

El sistema es revisado y analizado contra los tipos de ataques
que son conocidos por el equipo de validacin.
Validacin basada en herramientas
Varias
herramientas de seguridad contra delitos como
verificadores de contrasea son usados para el anlisis del
sistema en operacin.
Equipos del tigre
Un equipo es establecido cuya meta es abrir la brecha de
seguridad del sistema para la simulacin de ataques en el
sistema.
Verificacin formal
El sistema es verificado contra una especificacin formal de
seguridad contra delitos.
12/05/16
1148
Lista de control de
Hacer que todos los archivos que se crean en la aplicacin tengan los
permisos de acceso apropiados? Los permisos de acceso malos pueden
llevar a estos ser accedidos por usuarios desautorizado.
El sistema termina las sesiones de usuario automticamente despus de
un periodo de inactividad? Las sesiones que quedan activas pueden
permitir el acceso desautorizado a travs de una computadora desatendida.
Si el sistema est escrito en un lenguaje de programacin sin control de
lmite de arreglo, hay situaciones dnde el desborde de memoria
intermediaria puede ser explotada? El desborde de memoria intermediaria
puede permitir a los asaltadores enviar las cadenas de cdigo al sistema y
entonces ejecutarlos.
Si las contraseas son fijas, hace que el sistema que controla esa
contrasea sea "fuerte". Las contraseas fuertes consisten en letras
mezcladas, nmeros y puntuacin y no son entradas del diccionario
normales. Ellos son ms difciles de romper que las contraseas simples.
12/05/16
1149
Seguridad y casos de
confiabilidad
La
seguridad y los casos de confiabilidad

son
documentos
estructurados
que
presentan
argumentos
detallados
y
evidencian que un nivel requerido de
seguridad contra delitos ha sido logrado.
Ellos normalmente son requeridos por
reguladores antes que un sistema pueda
ser certificado para el uso operacional.
12/05/16
1150
El caso de seguridad
fsica de sistema
Es ahora una prctica normal, para un caso de seguridad

fsica formal, ser requerido por toda la seguridad crtica de los
sistemas basados en computadora, por ejemplo, el sealado
de va frrea, control de trfico areo, etc.
Un caso de seguridad fsica es:
Un cuerpo documentado de evidencia que proporciona un
convencimiento y argumento vlido que un sistema est
adecuadamente seguro para una aplicacin dada en un
ambiento dado.
Los argumentos en una seguridad fsica o un caso de
confiabilidad pueden estar basados en una comprobacin
formal, razn de diseo, comprobacin de seguridad fsica,
etc. Los factores del proceso pueden, tambin, ser incluidos.
12/05/16
1151
Componentes de un caso
de seguridad fsica
Componente
Descripcin
Descripcin
sistema
del
Una apreciacin global del sistema y una descripcin de sus componentes crticos.
Requerimientos
seguridad fsica
de
Los requerimientos de seguridad

requerimientos de sistema.
fsica resumidos de la especificacin de
Peligro y anlisis de
riesgo
Documentos que describen los peligros y riesgos que se han identificado y las
medidas tomadas para reducir el riesgo.
Anlisis de diseo
Un conjunto de argumentos estructurados que justifican por qu el diseo es

seguro.
Verificacin
validacin
y Una descripcin de los procedimientos V & V usados y, dnde son apropiados, las
pruebas se planean para el sistema. Los resultados de sistema V &V.
Informe
revisiones
de
Los registros de todos los diseos y revisiones de seguridad fsica.
Competencias
equipo
de
La evidencia de la competencia de todo el equipo involucrado en el desarrollo de

sistemas relacionados con la seguridad fsica y la validacin.
Proceso QA
Los registros de los procesos de certidumbre de calidad llevadas a cabo durante el

Procesos de gestin
de cambio
Los registros de todos los cambios propuestos, acciones tomadas y, dnde sea
apropiado, la justificacin de la seguridad fsica de estos cambios.
Casos
de seguridad
12/05/16
fsica asociados
Las referencias
a otros casos de seguridad fsica que pueden impactar en estos
1152
casos de seguridad fsica.
Estructura de argumento
EVIDENCIA
EVIDENCIA
EVIDENCIA
EVIDENCIA
<<ARGUMENTO>>
DEMANDA
DEMANDA
EVIDENCIA
EVIDENCIA
12/05/16
1153
Argumento de bomba de
insulina
Demanda: La sola dosis mxima computada por la bomba de insulina no
exceder la maxDosis.
Evidencia: El argumento de seguridad para la bomba de insulina como la
mostrada en la Figura 24.7.
Evidencia: Los conjuntos de juegos de datos de prueba para la bomba de
insulina.
Evidencia: El informe del anlisis esttico para el software de bomba de
insulina
Argumento: El argumento de seguridad presentado las muestras que la dosis
mxima de insulina que puede calcularse es igual a la maxDosis.
En 400 pruebas, el valor de la Dosis fue correctamente computada y
nunca excedi a la maxDose.
El anlisis esttico de control del software no revel ninguna
anomala.
En conjunto, es razonable asumir que la demanda est justificada.
12/05/16
1154
Demandar jerarqua
La
La bomba
bomba de
de insulina
insulina
no
entregar
una
no entregar una dosis
dosis
simple
de
insulina
simple de insulina que
que
es
insegura
es insegura
La
La mxima
mxima simple
simple dosis
dosis
computada
por
elel
computada
por
software
software que
que no
no excede
excede
maxDosis
maxDosis
En
operacin
En
operacin
normal,
la
normal, la mxima
mxima
dosis
computada
dosis computada
no
exceder
no
exceder
maxDosis
maxDosis
12/05/16
maxDosis
maxDosises
espresentada
presentada
cuando
la
bomba
cuando la
bomba de
de
insulina
es
configurada
insulina es configurada
maxDosis
maxDosis es
es una
una dosis
dosis
segura
para
el
usuario
segura para el usuario
de
delala bomba
bombade
deinsulina
insulina
Si
Si elel software
software falla,
falla,
entonces,
la
mxima
entonces, la mxima
dosis
dosis computada
computada
no
exceder
no
exceder
maxDosis
maxDosis
1155
Puntos clave
La medida de fiabilidad confa en el ejercicio del
sistema usando un perfil operacional una entrada
simulada que encaja al actual uso del sistema.
El modelo de crecimiento de fiabilidad se preocupa
por el modelamiento de cmo la fiabilidad de un
sistema de software mejora de modo que es probado
y las faltas son removidas.
Los
argumentos
de
seguridad
fsica
o
comprobaciones son una forma de demostracin que
una condicin arriesgada nunca puede ocurrir.
12/05/16
1156
Puntos clave
Es importante tener un proceso fidedigno para el
desarrollo de sistemas de seguridad fsica crticas.
El proceso incluir identificacin del peligro y
actividades de monitoreo.
La validacin de seguridad puede incluir el anlisis
basado en la experiencia, el anlisis basado en
herramientas o el uso de equipos tigre para atacar
el sistema.
Los casos de seguridad fsica recolectan al mismo
tiempo la evidencia que un sistema es seguro.
12/05/16
1157
Captulo 24
Personal de gerencia
Las
personas de
gerencia que trabajan
como individuos y en
grupos
12/05/16
1158
Objetivos
Explicar algunos de los problemas involucrados
seleccionando y reteniendo el personal
Describir factores que influencian en la motivacin
individual
Discutir problemas clave de equipos de trabajo
incluyendo
composicin,
cohesividad
y
comunicaciones
Introducir el modelo de capacidad de madurez del
personal (MCM-P) una armazn para reforzar
capacidades de las personas en una organizacin
12/05/16
1159
Tpicos cubiertos
Seleccin
de personal
Motivacin de personas
Gestin de grupos
El modelo de madurez de capacidad
de personas
12/05/16
1160
Las personas en el proceso

Las
personas son en una organizacin el

recurso ms importante.
Las tareas de un gerente son esencialmente
orientadas a personas. A menos que haya un
poco de comprensin de las personas la
gestin ser infructuoso.
La
pobre gestin de personas es un
contribuyente importante para el fracaso del
proyecto.
12/05/16
1161
Factores de gestin de
personal
12/05/16
Consistencia
Los miembros del equipo deben ser todos tratados de
una manera comparable sin favoritos o discriminacin.
Respeto
Diferentes miembros de equipo tienen habilidades
diferentes y estas diferencias deben ser respetadas.
Inclusin
Involucrar a todos los miembros del equipo y hacer
seguro que las vistas de personas sean consideradas.
Honestidad
Siempre se debe ser honrado alrededor de que esta
yendo bien y lo que esta yendo mal en un proyecto.
1162
Seleccin de personal
Una
tarea de gestin de proyecto importante es la

seleccin de personal.
La informacin en la seleccin viene de:
Informacin proporcionada por los candidatos.
Informacin ganada en las entrevistas y hablando
con los candidatos.
Las recomendaciones y comentarios de otras
personas que conocen o quien ha trabajado con
los candidatos.
12/05/16
1163
Estudio de caso de
seleccin de personal 1
Alicia es una gerente de proyecto de software que trabaja en una compaa que
desarrolla sistemas de alarma. Esta compaa desea entrar en el mercado
creciente de tecnologa del asistencia para ayudar al anciano y a las personas
invlidas a vivir independientemente. Alicia ha pedido llevar un equipo de 6
desarrolladores que pueden desarrollar nuevos productos basados alrededor de
la tecnologa de alarma de la compaa. Su primer papel es seleccionar a los
miembros del equipo de ingenieros de software en la compaa o de fuera de ella.
Para ayudar a seleccionar un equipo, Alicia evala las habilidades que ella
necesitar primero: Estas son:
12/05/16
1.
Experiencia con la tecnologa de alarma existente de modo que es reusado.
2.
La experiencia en diseo de interfaz de usuario, porque los usuarios son

inexpertos y pueden ser descartados y de necesidad de servicios como los
tamaos de fuente de las variables, etc.
3.
Idealmente, alguien que tiene experiencia en diseo de sistemas de

tecnologa de asistencia . Por otra parte, alguien con experiencia de
comunicacin fsica con las unidades del hardware, puesto que todos los
sistemas a ser desarrollados involucran algn control del hardware.
Las habilidades de desarrollo

propsito
general
Ing. Otonielde
Silva
Delgado - Ing. Ivan
Pino Tellera
1164
Estudio de caso de
seleccin de personal 2
La prxima fase es intentar y hallar las personas desde dentro de la compaa con las
habilidades necesarias. Sin embargo, la compaa ha extendido significativamente y ha
tenido poco personal disponible. El mejor que Alicia puede negociar es tener la ayuda de
un experto de alarma (Fred) por 2 das/semana. Ella, por consiguiente decide anunciar
para el nuevo personal del proyecto, la lista de atributos que le gustara:
1.
Experiencia en programacin con C. Ella ha decidido desarrollar todo el software

de control de tecnologa de asistencia en C.
2.
Experiencia en diseo de interfaz de usuario. Un diseador de IU es esencial ,pero

no puede haber una necesidad por un nombramiento por jornada a tempo
completo.
3.
Experiencia en el la comunicacin fsica con el hardware con C y usando los

sistemas de desarrollo remotos. Todos los dispositivos usados tienen las
interfaces del hardware complejas.
4.
Experiencia de trabajar con ingenieros de hardware. A veces, ser necesario

construir completamente el nuevo hardware.
Una personalidad simptica para que ellos puedan relacionarse y puedan trabajar con la
mayora de personas que estn proporcionando los requerimientos y que estn
probando el sistema.
12/05/16
1165
Lecciones
Los gerentes de una compaa no pueden desear
perder a las personas en un nuevo proyecto. La
participacin a tiempo parcial puede ser inevitable.
Las habilidades como el diseo de IU y las
comunicaciones fsicas con el hardware son para
abreviar el suministro.
Los recin graduados pueden no tener habilidades
especficas, pero pueden ser una manera de
introducir nuevas habilidades.
La habilidad tcnica puede ser menos importante
que las habilidades sociales.
12/05/16
1166
Factores de seleccin de
personal 1
Experiencia en Para desarrollar un sistema exitoso, los desarrolladores
el dominio de deben entender el dominio de la aplicacin para un proyecto.
aplicacin
Es esencial que algunos miembros de un equipo de desarrollo
tengan un poco de experiencia del dominio.
Experiencia en Esto puede ser significativo si la programacin de bajo nivel
la plataforma
est involucrada. Por otra parte, no es normalmente un
atributo crtico.
Experiencia en Esto normalmente slo es significativo para proyectos de
lenguajes
de duracin corta dnde no hay bastante tiempo para aprender
programacin un nuevo leguaje. Mientras que el aprendizaje de un lenguaje
no es difcil, toma varios meses para ponerse hbil usando las
libreras asociadas y componentes.
Habilidad
en Esto es muy importante para los ingenieros del software que
la solucin de constantemente tienen que resolver los problemas tcnicos.
problemas
Sin embargo, es casi imposible de juzgar sin saber el trabajo
de un miembro potencial del equipo.
12/05/16
1167
Factores de seleccin de
personal 2
Formacin
educacional
Esto puede proporcionar un indicador de los principios bsicos que

el candidato debe saber y de su habilidad de aprender. Este factor se
pone en aumento irrelevante como la experiencia de ganancia de los
ingenieros para un rango de proyectos.
Habilidad
de Esto es importante debido a la necesidad del personal del proyecto
comunicacin para comunicar oralmente y por escrito con otros ingenieros,
gerentes y clientes.
Adaptabilidad
La adaptabilidad puede juzgarse mirando los tipos diferentes de

experiencia que han tenido los candidatos. Este es un atributo
importante puesto que indica una habilidad por aprender.
Actitud
El personal del proyecto debe tener una actitud positiva de su trabajo

y debe estar deseoso de aprender nuevas habilidades. Este es un
atributo importante pero a menudo muy difcil de evaluar.
Personalidad
Este es un atributo importante pero difcil de evaluar. Los candidatos

deben ser bastante compatibles con los otros miembros del equipo.
Ningn tipo particular de personalidad satisface ms o menos a la
ingeniera de software.
12/05/16
1168
Motivando personas
Un rol importante de un gerente es motivar el trabajo
de las personas en un proyecto.
La motivacin es un problema complejo, pero aparecen
diferentes tipos de motivacin basados en:
Necesidades bsicas (por ejemplo, comida, sueo,
etc.);
Necesidades personales (por ejemplo, respeto,
autoestima);
Necesidades sociales (por ejemplo, ser aceptado
como parte de un grupo).
12/05/16
1169
Jerarqua de necesidades
humanas
Necesidades de
realizacin personal
Necesidades
de estima
Necesidades
sociales
Necesidades de
seguridad fsica
Necesidades
psicolgicas
12/05/16
1170
Necesidad de satisfaccin
Social
Proporcionar los recursos comunales;
Permitir la comunicacin informal.
Estima
Reconocimiento de los logros;
Premios apropiados.
Auto-realizacin
Entrenamiento de personas que quieren aprender
ms;
Responsabilidad.
12/05/16
1171
Motivacin individual
El proyecto de tecnologa de asistencia de Alicia empieza bien. Las buenas relaciones
de trabajo se desarrollan dentro del equipo y se desarrollan nuevas ideas creativas. Sin
embargo, algunos meses en el proyecto, Alicia nota que Dorothy, la experta en diseo de
hardware, empieza llegando tarde al trabajo, la calidad de su trabajo deteriora y, cada vez
ms, ella no parece estar comunicndose con otros miembros del equipo. Alicia habla
sobre el problema con los otros miembros del equipo, para intentar averiguar si las
circunstancias personales de Dorothy han cambiado y si esto podra estar afectando su
trabajo. Ellos no conocen nada, para que Alicia decida hablar con Dorothy, para intentar
entender el problema.
Despus de negar que haya un problema, Dorothy admite que ella parece haber perdido
el inters en el trabajo. Ella esper un trabajo dnde desarrollara y usara sus
conocimientos de interfaz con el hardware que aproveche sus habilidades. Sin embargo,
ella est trabajando bsicamente como una programadora de C con otros miembros del
equipo y est preocupada porque o est desarrollando sus habilidades de interfaz lcon
el hardware. Ella est angustiada porque ser difcil de encontrar un trabajo despus de
este proyecto que involucra el interfaz con el hardware uniendo. Porque ella no quiere
perturbar al equipo, revelando lo que ella est pensando sobre el prximo proyecto, ha
decidido que es mejor minimizar la conversacin con ellos.
12/05/16
1172
Tipos de personalidad
La
jerarqua de necesidades es casi con certeza

un sobre simplificacin de motivacin en la
prctica.
La motivacin tambin debe tener en cuenta, los
tipos de personalidades diferentes:
Orientadas a la tarea;
Orientada a si mismas;
Orientadas a la interaccin.
12/05/16
1173
Tipos de personalidad
Orientadas a la tarea
La motivacin para hacer el trabajo es el propio
trabajo;
Orientadas a si mismas
El trabajo es un medio para un fin que es el logro de
las metas individuales por ejemplo, hacerse rico,
jugar tenis, viajar, etc.;
Orientadas a la interaccin
La principal motivacin es la presencia y acciones de
colaboradores. Las personas van a trabajar porque les
gusta ir a trabajar.
12/05/16
1174
Equilibrio de la motivacin
Las motivaciones individuales son presentados de
elementos de cada clase.
El
equilibrio puede cambiar dependiendo de
circunstancias personales y eventos personales.
Sin embargo, las personas no
estn justamente
motivadas por factores personales pero tambin por
ser parte de un grupo y cultura.
Las personas van a trabajar porque estn motivadas
por las personas con que ellas trabajan.
12/05/16
1175
Gerencia de grupos
12/05/16
La mayora de la ingeniera de software son actividades

de grupo.
El programa de desarrollo para ms proyectos del
software no triviales es tal que ellos no pueden
completarse por una sola persona que trabaja
exclusivamente.
La interaccin del grupo es una clave determinante del
desempeo del grupo.
La flexibilidad en la composicin del grupo est limitada
Los gerentes deben hacer lo mejor que ellos pueden
con las personas disponibles.
1176
Factores que influyen en el

funcionamiento del grupo
Composicin
del grupo.
Cohesividad del grupo.
Comunicaciones del grupo.
Organizacin del grupo.
12/05/16
1177
Composicin del grupo
Grupo compuesto de miembros que comparten la misma

motivacin que puede ser problemtico
Orientado a tareas todos quieren hacer su propia cosa;
Orientado a si mismo todos quieren ser el jefe;
Orientado a la interaccin demasiada conversacin, no
bastante trabajo.
Un grupo efectivo tiene un equilibrio de todos los tipos.
Esto puede ser difcil de lograr para los ingenieros de
software que son a menudo orientados a tareas.
La gente orientada a la interaccin son muy importantes
puesto que ellos pueden detectar y calmar las tensiones que
se levantan.
12/05/16
1178

El la creacin de un grupo para el desarrollo de tecnologa de asistencia, Alicia es
consciente de la importancia de seleccionar a los miembros con las
personalidades complementarias. Al entrevistar a las personas, ella intent evaluar
si ellos estaban orientadas a tareas, orientados a si mismos y orientados a la
interaccin orient. Ella se senta que era principalmente del tipo orientado a si
mismo, cuando ella se senta que este proyecto era una manera en que ella se
notara por la gerencia mayor y sera promovida. Ella buscaba 1 o quizs 2
personalidades orientadas a la interaccin, por consiguiente con el resto orientado
a la tarea. La ltima valoracin a que ella lleg era:
Alicia - orientada a si misma
Brian - orientado a tareas
Bob - orientado a tareas
Carol - orientada a la interaccin
Dorothy - orientada a si misma
Ed - orientado a la interaccin
Fred - orientado a tareas
12/05/16
1179
La direccin del grupo

La
direccin depende del respeto

del estado no titular
Puede haber un lder tcnico y un
lder administrativo.
La direccin democrtica es ms
efectiva
que
la
direccin
autocrtica.
12/05/16
1180
Cohesividad del grupo
12/05/16
En un grupo cohesivo, los miembros consideran que el

grupo es ms importante que cualquier individuo en l.
La s ventajas de un grupo cohesivo son:
Los estndares de calidad del grupo pueden ser
desarrollados;
Los miembros del grupo trabajan estrechamente juntos,
de modo que las inhibiciones causadas por ignorancia
son reducidos;
Los miembros del equipo aprenden de cada uno y
consiguen conocer el trabajo de cada uno de ellos;
La programacin Egoless donde los miembros se
esfuerzan por mejorar cada uno de los otros programas
que pueden ser practicados
1181
Espritu de equipo
Alicia es una gerente del proyecto experimentada y entiende la importancia de crear un
grupo cohesivo. Cuando el desarrollo del producto es nuevo, ella aprovecha la oportunidad
de involucrar a todos los miembros del grupo en la especificacin del producto y disea
hacindoles discutir la posible tecnologa con los mayores miembros de sus familias y trae
a stos al almuerzo de grupo semanal. El almuerzo de grupo es una oportunidad para todos
los miembros del equipo se encuentren informalmente, hablen alrededor de los problemas
que preocupan y, generalmente, consigan conocerse.
El almuerzo es organizado como una sesin de informacin dnde Alicia les dice lo que ella
sabe sobre las noticias de la organizacin a los miembros del grupo, las polticas, las
estrategias, el etc. Cada miembro del equipo resume brevemente lo que ellos han estado
haciendo entonces y el grupo discute algn tema general como las nuevas ideas del
producto de los parientes ms viejos.
Cada ciertos meses, Alicia organiza un "da libre" para el grupo dnde el equipo se pasa
dos das
"actualizacin de tecnologa". Cada miembro del equipo prepara una
actualizacin en un poco de tecnologa pertinente y regalos de l al grupo. Esto es una
reunin fuera del sitio habitual, que se encuentra en un buen hotel y se fija tiempo
suficiente a para la discusin y la interaccin social.
12/05/16
1182
Desarrollo de la cohesividad
La cohesividad esta influenciada por factores tales
como cultura organizacional y las personalidades en el
grupo.
La cohesividad puede animarse a travs de
Eventos sociales
Desarrollando una identidad de grupo y territorio;
Las actividades del grupo de construccin explcitas.
La franqueza con la informacin es una simple manera
de asegurar a todos los miembros del equipo que se
sientan parte del grupo.
12/05/16
1183
Lealtades de grupo
Los
miembros de grupo tienden a ser leales s

grupos cohesivos.
El Pensamiento de grupo es la preservacin
del grupo independiente de consideraciones
tcnicas u organizacionales.
La direccin debe actuar positivamente para
evitar el pensamiento de grupo, forzando la
participacin externa con cada grupo.
12/05/16
1184
Comunicaciones del grupo

Las
buenas comunicaciones son esenciales

para el efectivo grupo de trabajo.
La informacin debe ser intercambiada sobre
el estado de trabajo, decisiones de diseo y
cambios para decisiones previas.
Las
buenas
comunicaciones
tambin
fortalecen la cohesin de grupo as como
pruebe la comprensin.
12/05/16
1185
Comunicaciones del grupo
12/05/16
Tamao del grupo

El ms grande del grupo, lo ms duro de las
personas para comunicarse con otros miembros del
grupo.
Estructura del grupo
La comunicacin es buena en grupos estructurados
informalmente que en los grupos, que en los grupos
estructurados jerrquicamente.
La comunicacin es buena cuando hay tipos de
personalidad diferente en un grupo y cuando los
grupos son mixtos , en lugar de un solo sexo.
1186
Organizacin del grupo

Grupos
de ingeniera de software pequeos

so
normalmente
organizados
informalmente sin una estructura rgida.
Para grandes proyectos puede haber una
estructura jerrquica donde diferentes
grupos son responsables para diferentes
subproyectos.
12/05/16
1187
Grupos informales
Los actos de grupo como un todo y vienen para un
consenso en las decisiones que afectan al sistema.
Los servicios del lder del grupo como la interfaz externa
del grupo pero no asigna los artculos de trabajo especfico.
Mas bien, el trabajo es discutido por el grupo en conjunto y
las tareas se asignan de acuerdo a la habilidad y
experiencia.
Esta aproximacin tiene xito para grupos donde todos los
miembros experiencia y competencia.
12/05/16
1188
Grupos de programacin
extrema
Los
grupos de programacin extrema son variantes

de una informal, organizacin democrtica.
En los grupos de programacin extrema, algunas
decisiones de direccin son desarrollados por los
miembros del grupos.
Los programadores trabajan en pares y toman una
responsabilidad colectiva para el cdigo que es
desarrollado.
12/05/16
1189
Equipos de
programadores principales
Consiste en un ncleo de especialistas ayudados
por otros agregados al proyecto como requeridos.
La motivacin detrs de su desarrollo es la ancha
diferencia
en la habilidad en programadores
diferentes.
Los equipos del programador principales mantienen
un ambiente de apoyo los programadores muy
capaces para ser responsables para la mayora del
12/05/16
1190
Problemas
Esta aproximacin del programador principal, en formas

diferentes, ha tenido xito en algunas escenas.
Sin embargo, padece varios problemas
Los diseadores talentosos y programadores son difciles
de encontrar. Sin las personas excepcionales en estos
papeles, el acercamiento fallar;
Otros miembros de grupo pueden resentirse con el
programador principal que toma el crdito para el xito, de
modo que puede deliberadamente minar (el/ella) su rol ;
Hay un riesgo alto del proyecto de que el proyecto fallar, si
el programador principal y secundario estn indisponibles.
Las estructuras organizacionales y las calidades en una
compaa pueden ser incapaces de acomodarse a este tipo
de grupo.
12/05/16
1191
Ambientes de trabajo
La provisin del lugar de trabajo tiene un efecto importante
en la productividad individual y satisfaccin
Confort;
Privacidad;
Recursos.
Salud y consideraciones de seguridad deben tenerse en
cuenta
Alumbrado;
Calefaccin;
Mobiliario.
12/05/16
1192
Factores ambientales
Privacidad
cada ingeniero requiere un rea

de trabajo ininterrumpido.
Fuera del conocimiento las personas
prefieren trabajar con luz natural.
Personalizacin los individuos adoptan
diferentes prcticas de trabajo y gustan
organizar su ambiente de diferentes maneras.
12/05/16
1193
Organizacin de espacios
de trabajo
Los
espacios de trabajo deben proporcionar

espacios privados donde la gente puede trabajar
sin interrupcin
Proporcionando oficinas individuales para el
personal para aumentar la productividad.
Sin embargo, los equipos que trabajan juntos
tambin requieren espacios donde reuniones
formales e informales pueden sostenerse.
12/05/16
1194
Diseo de oficina
Sala de
reunin
Oficina
Oficina
rea
comunal
Oficina
Ventana
Oficina
Oficina
Oficina
Documentacin
compartida
Oficina
12/05/16
Oficina
1195
El Modelo de Madurez de
Capacidad del Personal
Pensado
como una armazn para la

gestin y desarrollo de la gente
involucrada en el desarrollo del
software.
12/05/16
1196
Objetivos del MMC-P

Mejorar
la capacidad organizacional para mejorar

la capacidad de mano de obra.
Asegurar que esa capacidad de desarrollo de
software no es confiada a un pequeo nmero de
individuos.
Alinear la motivacin de los individuos con esa
de la organizacin
Ayudar
a retener a las personas con
conocimiento crtico y habilidades.
12/05/16
1197
Niveles del MMC-P

Modelo
de 5 fases
Inicial. Adecuado para la direccin de personas.
Repetible. Las polticas desarrolladas para la mejora de
capacidad
Definido. La direccin de las personas estandarizadas a
travs de la organizacin
Manejado. Las metas cuantitativas para la direccin de
las personas en el lugar
Optimizando. El enfoque continuo en mejorar la
competencia individual y motivacin de la mano de obra
12/05/16
1198
El modelo de capacidad
de personas
Continuamente mejora de
mtodos para desarrollo
personal y competencia
organizacional
Optimizando
Optimizando
Innovacin de mano de obra continua

Innovacin de mano de obra continua
Adiestrando
Adiestrando
Desarrollo de competencia personal
Desarrollo de competencia personal
Manejado
Manejado
Cuantitativamente manejo
organizacional del crecimiento de
las habilidades de mano de obra y
establecimiento de equipos
basados en la competencia
Alienacin de desempeo personal

Alienacin de desempeo personal
Direccin de competencia organizacional
Direccin de competencia organizacional
Prcticas basadas en equipo
Prcticas basadas en equipo
Construccin de equipo
Construccin de equipo
Guiando
Guiando
Definido
Definido
Identificacin de competencias
primarias y actividades de
alineacin de mano de obra con
ellas
Cultura participatoria
Cultura participatoria
Prcticas basadas en la competencia
Prcticas basadas en la competencia
Desarrollo de carrera
Desarrollo de carrera
Desarrollo de competencia
Desarrollo de competencia
Planificacin de mano de obra
Planificacin de mano de obra
Anlisis de conocimiento y habilidades
Anlisis de conocimiento y habilidades
Repetible
Repetible
Compensacin
Compensacin
Entrenamiento
Entrenamiento
Gestin de desempeo
Gestin de desempeo
Provisin de personal
Provisin de personal
Comunicacin
Comunicacin
Ambiente de trabajo
Ambiente de trabajo
Introducir la disciplina dentro

bsica dentro de las
actividades de mano de obra
Inicial
Inicial
12/05/16
1199
Puntos clave
Los
factores de seleccin de personal incluyen

educacin,
experiencia
del
dominio,
adaptabilidad y personalidad.
Las personas son motivadas por la interaccin,
reconocimiento y desarrollo personal.
Los grupos de desarrollo de software deben
ser pequeos y cohesivos. Los lderes deben
ser competentes y deben tener soporte
administrativo y tcnico.
12/05/16
1200
Puntos clave
Las
comunicaciones entre grupos son

afectadas por el estado, tamao de grupo,
organizacin del grupo, y gnero y
composicin de la personalidad del grupo.
Los ambientes de trabajo sern incluidos
espacios para la interaccin y espacios para el
trabajo privada.
El Modelo de Madurez de Capacidad de
Personal es la armazn para mejorar las
capacidades del personal en la organizacin.
12/05/16
1201
Captulo 25
Estimation del
costo del
software
12/05/16
1202
Objetivos
Introducir
los fundamentos de costos y precios

del software
Describir
tres mtricas para evaluar la
productividad del software
Explicar por qu deben ser usadas diferentes
tcnicas para la estimacin del software
Describir los principios del modelo de estimacin
del costo algortmico COCOMO 2
12/05/16
1203
Tpicos cubiertos
Productividad
del software
Tcnicas de estimacin
Modelo de costo algortmico
Duracin del proyecto y provisin del
personal
12/05/16
1204
Preguntas de la estimacin
fundamentales
Cunto
esfuerzo se requiere para completar

una actividad?
Cunto tiempo del calendario es necesario
para completar una actividad?
Cul es el costo total de una actividad?
Proyectar la estimacin y planificacin que
son actividades entrelazadas.
12/05/16
1205
Componentes del costo

del software
12/05/16
Costos de hardware y software.

Costos de viaje y entrenamiento.
Costos de esfuerzo (el factor dominante de la mayora de los
proyectos)
Los salarios de los ingenieros involucrados en el proyecto;
Costos sociales y de seguro.
Los costos de esfuerzo deben tener los gastos generales
Costos de construccin, calefaccin, alumbrado.
Costos de redes de computadoras y comunicaciones.
Costos de servicios compartidos (por ejemplo, librera,
restaurante del personal, etc.).
1206
Costos y precios
Las
estimaciones se hacen para descubrir

el costo, para el desarrollador, de
produccin de un sistema de software.
No hay una simple relacin entre el costo
de desarrollo y el precio cobrado al cliente.
La organizacin ms ancha, econmica,
poltica
y consideraciones comerciales
influyen en el precio cobrado.
12/05/16
1207
Factores del precio del

software
Oportunidad
mercado
de Una organizacin de desarrollo puede cotizar un precio bajo
porque desea pasar a un nuevo segmento del mercado del

software. Aceptando una ganancia baja en un proyecto pueden dar
la oportunidad de ms ganancia despus. La experiencia ganada
puede permitir desarrollar los nuevos productos.
Incertidumbre en la Si una organizacin est insegura de su estimacin del costo,

estimacin
del puede aumentar su precio por alguna contingencia de nuevo y por
encima de su ganancia normal.
costo
Condiciones
contractuales
Un cliente puede estar deseoso de permitirle al diseador retener la

propiedad del cdigo fuente y reusarlo en otros proyectos. El
precio cobrado puede ser entonces menor, si el cdigo fuente de
software se entrega al cliente.
Volatilidad
de Si es probable que los requerimientos cambien, una organizacin
puede bajar su precio para ganar un contrato. Despus de que el
requerimientos
contrato se otorga, pueden cobrarse los precios altos por los
cambios a los requerimientos.
Salud financiera
12/05/16
Los desarrolladores en dificultad financiera pueden bajar su precio

para ganar un contrato. Es bueno hacer uno ms pequeo que la
ganancia normal o incluso romper para salir del negocio.
1208
Productividad del software

Un
medida que es la proporcin en la cual los

ingenieros individuales involucran en el
desarrollo del software, el producto software y
documentacin asociada.
No orientada
a la calidad a pesar de que la
certidumbre de calidad es un factor en la
evaluacin de la productividad.
Esencialmente, queremos medir la funcionalidad
til producida por unidad de tiempo.
12/05/16
1209
Medidas de productividad
Medidas
relacionadas al tamao basadas en

alguna salida del proceso del software. Estos
pueden ser lneas de cdigo fuente entregas,
instrucciones de cdigo objeto, etc.
Medidas relacionadas a la funcin basadas en
una estimacin de la funcionalidad del software
entregado. Los puntos de funcin es la ms
conocida de este tipo de medidas.
12/05/16
1210
Problemas de la
medicin
Estimacin
del tamao de la medida (por

ejemplo, cuntos puntos de funcin).
Estimacin del nmero total de meses de
programador que han pasado.
Estimacin
de la productividad del
contratista (por ejemplo, el equipo de
documentacin) e incorporando esta
estimacin en la estimacin global.
12/05/16
1211
Lneas de cdigo
Qu es una lnea de cdigo?
La medida fue propuesta primero cuando los programas
eran tipeadas en tarjetas con una lnea por tarjeta;
Cmo hacer que esto corresponda para estamentos en
Java en la cual se puede medir por palmos de varias
lneas o donde puede haber varios estamentos en una
lnea.
Qu programas deben contarse como parte del sistema?
Este modelo asume que hay una relacin lineal entre el
tamao del sistema y el volumen de la documentacin.
12/05/16
1212
Comparacin de
productividad
A nivel ms bajo del lenguaje, ms productivo el
programador
La misma funcionalidad toma ms cdigo para
implementar en un lenguaje de bajo nivel que en un
lenguaje de alto nivel.
A programador ms verboso, ms alta la productividad
Las medidas de productividad basadas en lneas de
cdigo sugiere que los programadores que escriben
cdigo verboso son ms productivos que escriben
cdigo compactado.
12/05/16
1213
Tiempos de desarrollo del

sistema
Anlisis
Diseo
Codificacin
Prueba
Documentacin
Cdigo
Assembler
3 semanas 5 semanas 8 semanas
10
semanas
Lenguaje de
alto nivel
3 semanas 5 semanas 4 semanas
6 semanas 2 semanas
Tamao
12/05/16
Esfuerzo
2 semanas
Productividad
Cdigo
Assembler
5000 lneas
28 semanas
714 lneas /mes
Lenguaje de
alto nivel
1500 lneas
20 semanas
300 lneas /mes
1214
Puntos de funcin
Basado en una combinacin de caractersticas del

programa
Entradas externas y salidas;

Interacciones de usuario;
Interfaces externas;
Archivos usados por el sistema.
Un peso est asociado con cada de estos y la cuenta

del punto de funcin es computada por multiplicacin de
la cuenta de cada cuenta por el peso y la suma de todos
los valores.
12/05/16
1215
Puntos de funcin
El punto de funcin La cuenta del punto de funcin es
modificada por la complejidad del proyecto
Los PFs pueden ser usados para estimar la LDC
dependiendo del promedio del nmero de LDC usadas
por PF de un lenguaje dado
LDC = PRC * nmero de puntos de funcin;
PRC es un factor dependiente del lenguaje que vara
desde 200-300 para el lenguaje Assembler hasta 2-40
para un L4G;
Los PFs son muy subjetivos. Ellos dependen del
estimador
El conteo automtico de los puntos de funcin es
imposible.
12/05/16
1216
Puntos objeto
Los puntos objeto (alternativamente llamado puntos de

aplicacin) son una alternativa de medida relacionada con
funcin para puntos de funcin cuando L4G o lenguajes
similares son usados para el desarrolladores
Los puntos objeto NO son lo mismo que las clases de objeto.
El nmero puntos objeto en un programa es una estimacin
pesada de
El nmero de pantallas separadas que son desplegadas;
El nmero de informes que son producidos por el sistema;
El nmero de mdulos de programa que deben ser
desarrollados para complementar el cdigo de bases de
datos;
12/05/16
1217
Estimacin de puntos
objeto
Los
puntos objeto son ms fciles de estimar

desde una especificacin que los puntos de
funcin, puesto que ellos estn interesados con
pantallas, informes y mdulos de lenguajes de
programacin.
Ellos pueden, por consiguiente, ser estimados en
un punto bastante temprano del proceso de
desarrollo.
En esta fase, es muy difcil estimar el nmero de
lneas de cdigo en un sistema.
12/05/16
1218
Estimacin de productividad
Sistemas
empotrados de tiempo real, 40-160

LDC /P-mes.
Programas de sistemas , 150-400 LDC/P-mes.
Aplicaciones comerciales, 200-900 LDC /P-mes.
En puntos objeto, la productividad ha sido
medida entre 4 y 50 puntos objeto /mes
dependiendo del soporte de herramientas y la
capacidad del desarrollador.
12/05/16
1219
Factores que afectan la

productividad
Experiencia en el El conocimiento del dominio de la aplicacin es esencial
dominio
de para el desarrollo de un software eficaz. Es probable que los
aplicacin
ingenieros que ya entienden un dominio sean los ms
productivos.
Calidad del proceso El proceso de desarrollo usado puede tener un efecto
significativo en la productividad. Esto se cubre en el Captulo
28.
Tamao
proyecto
Soporte
tecnolgico
Ambiente
trabajo
12/05/16
del Lo grande en un proyecto, el mayor tiempo requerido es para

las comunicaciones del equipo. Menor tiempo est
disponible para el desarrollo de modo que la productividad
individual est reducida.
El buen soporte de la tecnologa como las herramientas
CASE, sistemas de gestin de configuracin, etc. puede
mejorar la productividad.
de Cuando yo discut en el Captulo 25, un ambiente de trabajo
quieto con reas de trabajo privadas contribuye a mejorar la
productividad.
1220
Calidad y productividad
Todas las mtricas basadas en volumen /unidad de
tiempo son defectuosas porque no toman en cuenta
la calidad.
La productividad puede generalmente ser creciente a
costo de la calidad.
No
est claro cmo la las mtricas de
productividad /calidad estn relacionadas.
Si
los
requerimientos
estn
cambiando
constantemente entonces una aproximacin basada
en la cuenta de lneas de cdigo no es significativa
como el propio programa no es esttico.
12/05/16
1221
No hay ninguna manera simple para hacer una estimacin

exacta del esfuerzo requerido para desarrollar un sistema de
software
Las estimaciones iniciales estn basadas en la informacin
inadecuada y en una definicin de requerimientos del
usuario;
El software puede ejecutarse en computadoras poco
familiares o usar nueva tecnologa;
La gente en un proyecto puede ser desconocida.
Las estimaciones del costo del proyecto puede estar
cumpliendo por si mismo.
La estimacin define el presupuesto y el producto es
ajustado para estar en el presupuesto.
12/05/16
1222
Cambio de tecnologas
12/05/16
El cambio de tecnologas puede significar que la

experiencia de estimacin previa no se lleva para los
nuevos sistemas
Sistemas de objetos distribuidos en lugar de sistemas de
sistema informtico grande;
Uso de servicios de la Web;
Uso de ERP o sistemas centrados de base de datos;
Uso de software fuera de estante;
Desarrollo para y con reuso;
Desarrollo usando lenguajes de guiones
El uso de herramientas CASE y generadores de
programa.
1223
Modelo
de costo algortmico.
Juicio experto.
Estimacin por analoga.
Leyes de Parkinson.
Precio para ganar.
12/05/16
1224
Modelo de costo Un modelo basado en informacin histrica del costo que relaciona alguna
algortmico
mtrica del software (normalmente su tamao) al costo del proyecto es usado.
Una estimacin es hecha de esa mtrica y el modelo predice el esfuerzo
requerido.
Juicio experto
Varios expertos en las tcnicas de desarrollo de software propuestas y el

dominio de la aplicacin son consultados. Cada uno de ellos estima el costo del
proyecto. Estas estimaciones son comparadas y discutidas. El proceso de
estimacin se itera hasta que una estimacin concordada sea alcanzada.
Estimacin
analoga
por Esta tcnica es aplicable cuando se han completado otros proyectos en el

mismo dominio de la aplicacin. El costo de un nuevo proyecto se estima por la
analoga con estos proyectos completados. Myers (Myers 1989) da una
descripcin muy clara de este acercamiento.
Leyes
Parkinson
de Los estados de la Ley de Parkinson que el trabajo extiende para llenar el tiempo
disponible. El costo es determinado por los recursos disponibles en lugar de
por la valoracin objetiva. Si el software tiene que ser entregado en 12 meses y
5 personas estn disponibles, el esfuerzo requerido se estima para ser 60
persona-meses.
Precio para ganar
12/05/16
El costo del software se estima para ser cualquiera que el cliente tiene
disponible para gastar en el proyecto. El esfuerzo estimado depende del
presupuesto del cliente y no de la funcionalidad del software.
1225
Precio para ganar

El
proyecto cuesta lo que el cliente tiene

disponible para pagar.
Ventajas:
Se consigue el contrato.
Desventajas:
La probabilidad de que el cliente consiga el
sistema que el o elle desea es pequea. Los
costos no reflejan precisamente el trabajo
requerido.
12/05/16
1226
Estimacin de arribaabajo y de abajo-arriba

Una de estas aproximaciones puede ser usada de
arriba-abajo o de abajo-arriba.
De arriba-abajo
Empieza en el nivel ms alto y accede a la
funcionalidad global y cmo esto es entregado a
travs de subsistemas.
De abajo-arriba
Empieza a nivel de componente y estima el
esfuerzo requerido por cada componente. Agrega
esos esfuerzos para hallar la estimacin final.
12/05/16
1227
Estimacin de arriba-abajo
Utilizable
sin el conocimiento de la
arquitectura y los componentes que podran
ser parte del sistema.
Toma en cuenta costos como la integracin,
gestin de configuracin y documentacin.
Puede subestimar el costo de resolver
problemas tcnicos de bajo nivel de
dificultad.
12/05/16
1228
Estimacin de abajo-arriba
Utilizable
cuando la arquitectura del

sistema es conocida y los componentes
identificados.
Este puede ser un mtodo exacto si el
sistema ha sido diseado en detalle.
Puede subestimar los costos al nivel de
actividades del sistema como los de
integracin y documentacin.
12/05/16
1229
Mtodos de estimacin
Cada mtodo tiene fortalezas y debilidades.
La estimacin debe estar basada en varios mtodos.
Si estos no devuelven aproximadamente el mismo
resultado, entonces se tiene insuficiente informacin
disponible para hacer una estimacin.
Alguna accin debe ser tomada para buscar ms en
orden para hacer estimaciones ms exactas.
Precio para ganar es a veces el nico mtodo aplicable.
12/05/16
1230
Precio para ganar

Esta aproximacin puede parecer no tica y no
comercial.
Sin
embargo, cuando est faltando informacin
detallada puede ser la nica estrategia aplicable.
El costo del proyecto est convenido en base a una
propuesta del contorno y el desarrollo est restringido
por el costo.
Una especificacin detallada puede ser negociada o
una aproximacin evolutiva usada por el desarrollo del
sistema.
12/05/16
1231
Modelamiento del costo

algortmico
El costo es estimado como una funcin matemtica del

producto, atributos del proceso y el proyecto cuyos valores son
estimados por los gerentes del proyecto:
Esfuerzo = A TamaoB M
A es una constante dependendiente de la organizacin, B

refleja el esfuerzo desproporcionado para proyectos y M es
un multiplicador que refleja atributos del producto, del
proceso y de las personas.
El ms comnmente usado atributo del producto para la

estimacin del costo es el tamao de cdigo.
La mayora de modelos son similares, pero usan diferentes
valores parar A, B y M.
12/05/16
1232
Exactitud de la estimacin
El
tamao de un sistema de software slo puede

conocerse con exactitud cuando est terminado.
Varios factores influencian en el tamao final
Use de COTS y componentes;
Lenguaje de programacin;
Distribucin del sistema.
Como el desarrollo del programa progresa,
entonces la estimacin del tamao se hace ms
exacta.
12/05/16
1233
Estimar la Incertidumbre
12/05/16
1234
El modelo COCOMO
Un
modelo emprico basado en la experiencia

del proyecto.
Bien documentado, modelo independiente que
no est atado a un vendedor especfico de
software.
La larga de la versin inicial publicada en 1981
(COCOMO-81)
a
travs
de
varias
instanciaciones para COCOMO 2.
COCOMO
2 toma en cuenta diferentes
aproximaciones para el desarrollo del software,
reuso, etc.
12/05/16
1235
COCOMO 81
Complejidad
del proyecto
Frmula
Descripcin
Simple
PM = 2.4(KDSI)1.05xM
Aplicaciones
bien
entendidas
desarrolladas por equipos pequeos.
Moderado
Proyectos ms complejos dnde los

miembros del equipo pueden tener
limitada
experiencia
en
sistemas
relacionados.
Empotrado
Proyectos complejos dnde el software

es parte de un complejo fuertemente
acoplado
al
hardware,
software,
regulaciones
y
procedimientos
operacionales.
12/05/16
1236
COCOMO 2
COCOMO
81 fue desarrollado con la asuncin

de un proceso de cascada ser usado y que
todo el software se desarrollar desde el
principio.
Subsecuentemente su formulacin, ha habido
muchos cambios en la prctica de ingeniera de
software y COCOMO 2 es diseado para
acomodar diferentes aproximaciones para el
desarrollo del software.
12/05/16
1237
Modelos de COCOMO 2
COCOMO 2 incorpora un rango de submodelos que

producen las estimaciones de software cada vez ms
detalladas.
Los submodelos en COCOMO 2 son:
Modelo de composicin de aplicacin. Usado cuando el
software es compuesto desde partes existentes.
Modelo de diseo temprano. Usado cuando los
requerimientos estn disponibles, pero el diseo no ha
empezado todava.
Modelo de reuso. Usado para calcular el esfuerzo de
integrar componentes reusables.
Modelo de post-arquitectura. Usado una vez la
arquitectura del sistema se ha diseado y ms informacin
acerca del sistema est disponible.
12/05/16
1238
Uso de modelos de
COCOMO 2
Nmero
Nmerode
de
puntos
de
puntos de
aplicacin
aplicacin
Basado en
Modelo
Modelode
de
composicin
composicinde
de
aplicacin
aplicacin
Usado por
Nmero
Nmerode
de
puntos
de
puntos de
funcin
funcin
Basado en
Modelo
Modelode
de
diseo
diseo
temprano
temprano
Usado por
Basado en
Modelo
Modelode
de
reuso
reuso
Usado por
Nmero
Nmerode
de
lneas
de
cdigo
lneas de cdigo
reusado
reusadooo
generado
generado
Nmero
Nmerode
de
lneas
de
cdigo
lneas de cdigo
fuente
fuente
12/05/16
Basado en
Modelo
ModeloPostPostarquitectnico
arquitectnico
Usado por
Desarrollo
Desarrollo de
desistemas
sistemas
prototipo
usando
prototipo usando
guiones
guionesyy
programacin
programacinde
deBD
BD
Estimacin
Estimacindel
del
esfuerzo
inicial
basado
esfuerzo inicial basado
en
enrequerimientos
requerimientosdel
del
sistema
y
opciones
de
sistema y opciones de
diseo
diseo
Esfuerzo
Esfuerzopara
paraintegrar
integrar
componentes
componentes
reusables
reusablesoocdigo
cdigo
generado
generado
automticamente
automticamente
Desarrollo
Desarrollo de
deesfuerzo
esfuerzo
basado
en
basado enlala
especificacin
especificacinde
de
diseo
de
sistemas
diseo de sistemas
1239
Modelo de composicin
de aplicacin
Soporta proyectos de prototipado y proyectos donde hay
ruso extensivo.
Basado en estimaciones estndares de productividad de
desarrollador en aplicacin (objeto) puntos/mes.
Toma en cuenta el uso de herramienta CASE.
La frmula es
PM = ( NPA (1 - %reuso/100 ) ) / PROD
12/05/16
PM es el esfuerzo en personas meses, NPA es el

nmero de puntos de aplicacin y PROD es la
productividad.
1240
Productividad del punto

objeto
Experiencia
Muy
del
alta
desarrollador
y capacidad
Baja
Nominal
Alto
Muy alto
Madurez y
Muy
capacidad del alta
ICASE
Baja
Nominal
Alto
Muy alto
PROD
(NPO/mes)
13
25
50
12/05/16
1241
Modelo de diseo temprano

Las estimaciones pueden ser hechas despus de que los
requerimientos han sido convenidos.
Basado
en una frmula estndar para modelos
algortmicos
PM = A TamaoB M donde
M = PERS RCPX RUSE PDIF PREX FCIL
SCED;
A = 2.94 en la calibracin inicial, Tamao en KLDC, B
varia de 1.1 a 1.24 dependiendo de la novedad del
proyecto, flexibilidad de desarrollo, aproximaciones en
la gestin del riego y la madurez del proceso.
12/05/16
1242
Multiplicadores
Los multiplicadores reflejan la capacidad de los

desarrolladores, los requerimientos no funcionales,
la familiaridad con la plataforma de desarrollo, etc.
12/05/16
RCPX Fiabilidad del producto y complejidad;

RUSE Reuso requerido;
PDIF Dificultad de la plataforma;
PREX Experiencia personal;
PERS Capacidad personal;
SCED Planificacin requerida;
FCIL los recursos de soporte del equipo.
1243
El modelo de reuso
Toma en cuenta el cdigo de caja negra que es
reusado sin cambio y cdigo que ha sido adaptado
para integrarlo con el nuevo cdigo.
Hay dos versiones:
El reuso de caja negra donde el cdigo no es
modificado. Una estimacin del esfuerzo (PM) es
computada.
El reuso de caja blanca donde el cdigo es
modificado. Una estimacin de tamao equivalente
para el nmero de lneas de nuevo cdigo fuente es
computada. Esto ajusta, entonces, la estimacin del
tamao para el nuevo cdigo.
12/05/16
1244
Estimacin del modelo de

reuso 1
Para
12/05/16
el cdigo generado:
PM = (ASLOC * AT/100)/ATPROD
ASLOC es el nmero de lneas de cdigo
generado.
AT
es
el
porcentaje
de
cdigo
automticamente generado.
ATPROD es la productividad de los ingenieros
en la integracin de este cdigo.
1245
Estimacin del modelo de

reuso 2
Cuando
12/05/16
el cdigo ha sido entendido e integrado:

ESLOC = ASLOC * (1-AT/100) * AAM.
ASLOC y AT como antes.
AAM es el multiplicador de ajuste de
adaptacin computado desde los costos de
cambio del cdigo reusado, los costos de
entender cmo integrar el cdigo y los costos
de hacer la decisin de reuso.
1246
Nivel post-arquitectnico
Se usa la misma frmula del diseo temprano pero
con 17 en lugar de 7 multiplicadores asociados.
El tamao del cdigo es estimado como:
Nmero de lneas de cdigo a ser desarrollado
Estimar el nmero equivalente de lneas de nuevo
cdigo computado usando el modelo de reuso;
Una estimacin del nmero de lneas de cdigo
que tienen que ser modificados de acuerdo al
cambio de requerimientos.
12/05/16
1247
El trmino exponente
Esto depende de 5 factores de la balanza (ver la prxima

diapositiva). Su suma/100 se agrega a 1.01
Una compaa asume un proyecto en un nuevo dominio. El
cliente no ha definido el proceso a ser usado y no ha permitido
tiempo el anlisis de riesgo. La compaa tiene un nivel de razn
CMM 2 .
Precedente- Nuevo proyecto(4)
Flexibilidad en el desarrollo ninguna participacin del cliente
- Muy alto (1)
Resolucin
Arquitectura/riesgo - Ningn anlisis de riesgo
-Muy bajo.(5)
Cohesin del equipo - nuevo equipo - nominal (3).
Madurez del proceso - algn control - nominal (3)
El factor de equilibrio es por consiguiente 1.17.
12/05/16
1248
Factores de equilibrio de
exponente
Precedente
Refleja la experiencia anterior de la organizacin con este tipo de

proyecto. Las medias muy bajos indican ninguna experiencia anterior:
Las medios extra altas indican que la organizacin est completamente
familiarizado con este dominio de aplicacin.
Flexibilidad
de desarrollo
Refleja el grado de flexibilidad en el proceso de desarrollo. Las medias

muy bajas indican que un proceso prescrito es usado. Las medias extra
altas indican que el cliente slo fijan las metas generales.
Resolucin
arquitectura/
riesgo
Refleja la magnitud de anlisis de riesgo llevada a cabo. La media baja

indica anlisis pequeo, las medias extra altas indican un anlisis de
riesgo completo.
Cohesin
equipo
de Refleja cuan bien el equipo de desarrollo se conocen y trabajen juntos.
Madurez
proceso
del Refleja la madurez del proceso del organizacin. El cmputo de este
12/05/16
Las medias muy bajos indican interacciones muy difciles. Las medias
extras altas indican un equipo integrado y efectivo sin los problemas de
comunicacin.
valor depende de la encuesta de madurez del MMC, pero una
estimacin puede lograrse substrayendo el proceso de madurez MMC
del nivel 5.
1249
Multiplicadores
Atributos del producto

Tiene relacin con las caractersticas requeridas del
producto del software a desarrollarse.
Atributos de la computadora
Las restricciones impuestas en el software por la
plataforma del hardware.
Atributos del personal
Multiplicadores que toman en cuenta la experiencia y

capacidades de las personas que trabajan en el proyecto.
Atributos del proyecto
12/05/16
Tiene relacin con las caractersticas particulares del

proyecto de desarrollo de software.
1250
Efectos de manejadores de
costo
Valor del exponente
1.17
Tamao del sistema (incluye factores de reuso y 128.000 DSI

volatilidad de requerimientos)
Estimacin del COCOMO sin tener en cuenta los 730 personas-mes
manejadores de costos
Confiabilidad
Muy alta, multiplicador =1.39
Complejidad
Restricciones de memoria
Alta, multiplicador =1.21
Uso de herramienta
Baja, multiplicador =1.12
Planificacin
Acelerada, multiplicador = 1.29
Estimacin del COCOMO ajustado
2306 personas-mes
Confiabilidad
Muy baja, multiplicador =0.75
Complejidad
Muy baja, multiplicador =0.75
Restricciones de memoria
Ninguna, multiplicador =1
Uso de herramienta
Planificacin
12/05/16
Normal, multiplicador = 1
Estimacin del COCOMO ajustado
295 personas-mes
1251

Los modelos de costo algortmico mantienen una base de
planificacin del proyecto cuando ellos permiten comparar las
estrategias alternativas.
Sistema de nave espacial empotrado
Debe ser fiable;
Debe minimizar el peso (nmero de chips);
Multiplicadores de fiabilidad y restricciones de computadora > 1.
Componentes de costo
Hardware designado;
Plataforma de desarrollo;
Esfuerzo de desarrollo.
12/05/16
1252
Opciones de gestin
A.
A.Uso
Usode
dehardware
hardware
existente,
desarrollo
existente, desarrollo
del
delsistema
sistemayydesarrollo
desarrollo
del
equipo
del equipo
B.
B.Procesador
Procesadoryymemoria
memoria
actualizada
actualizada
Aumento
Aumentodel
delcosto
costode
dehardware
hardware
Decrece
Decreceexperiencia
experiencia
E.
E.Nuevo
Nuevodesarrollo
desarrollodel
delsistema
sistema
Aumento
Aumentodel
delcosto
costode
dehardware
hardware
B.
B.Memoria
Memoriaactualizada
actualizada
solamente
solamente
Aumento
Aumento del
del costo
costo de
de
hardware
hardware
D.
D.Personal
Personalde
de
mayor
experiencia
mayor experiencia
F.F.Personal
Personalcon
con
experiencia
en
hardware
experiencia en hardware
Decrece
Decreceexperiencia
experiencia
12/05/16
1253
Costos de opcin de costos

Opcin
CONF ALMAC
TIEMP
O
HERRA LTEX
Esfuerzo
total
Costo
software
Costo
hardware
Costo
total
1.39
1.06
1.11
0.86
63
949399
100000
1049393
1.39
1.12
1.22
88
1313550
120000
1402025
1.39
1.11
0.86
60
895653
105000
1000635
1.39
1.06
1.11
0.86
0.84
51
769008
100000
897490
1.39
0.72
1.22
56
844425
220000
1044159
1.39
1.12
0.84
57
851180
120000
1002706
12/05/16
1254
Elegir opcin
Opcin D (usar personal ms experimentado)
parece la mejor alternativa
Sin embargo, tiene un alto riesgo asociado puesto
que el personal experimentado puede ser difcil de
encontrar.
Opcin C (memoria actualizada) tiene un bajo costo
que ahorra, pero el riesgo es muy bajo.
En conjunto, el modelo revela la importancia de la
experiencia del personal en el desarrollo del
software.
12/05/16
1255
Duracin del proyecto y

provisin de personal
As como la estimacin del esfuerzo, los gerentes deben estimar
el tiempo de calendario requerido para completar un proyecto y
cuanto personal ser requerido.
El tempo de calendario puede ser estimado usando la frmula de
COCOMO 2
TDEV = 3 (PM)(0.33+0.2*(B-1.01))
PM es el clculo del esfuerzo y B es el exponente calculado

como el anteriormente discutido (B es 1 para el modelo de
prototipado temprano). Este clculo predice el calendario
nominal para el proyecto.
El tiempo requerido es independiente del nmero de personas
que trabajan en el proyecto.
12/05/16
1256
Requerimientos de
provisin de personal
El personal requerido no puede calcularse
sumergindose en el tiempo de desarrollo de la
planificacin requerida.
El nmero de personas que trabajan en un proyecto
vara dependiendo de la fase de un proyecto.
A ms personas que trabajan en un proyecto, ms
esfuerzo total es normalmente requerido.
Un aumento muy rpido de personas a menudo
pone en relacin con el desprendimiento de la
planificacin.
12/05/16
1257
Puntos clave
No hay una simple relacin entre el precio cobrado
para un sistema y sus costos de desarrollo.
Los factores que afectan la productividad incluyen la
aptitud individual, experiencia en el dominio, el
proyecto de desarrollo, el tamao del proyecto,
soporte de herramientas y el ambiente de
desarrollo.
El software puede ser preciado para ganar un
contrato y la funcionalidad ajustada para el precio.
12/05/16
1258
Puntos clave
Tcnicas diferentes de estimacin del costo sern
usadas cuando se estimen costos.
El modelo COCOMO toma en cuenta el proyecto,
producto, personal y atributos del hardware cuando
predice el esfuerzo requerido.
El modelo de costos algortmico soporta el anlisis de
opcin cuantitativa de modo que permite comparar los
costos de diferentes opciones.
El tiempo para completar un proyecto no es
proporcional para el nmero de personas que trabajan
en el proyecto.
12/05/16
1259
Captulo 26
Gestin de
calidad
12/05/16
1260
Objetivos
Introducir el proceso de gestin y actividades de
gestin de calidad claves
Explicar el rol de los estndares en la gestin de
calidad
Explicar el concepto de mtrica del software,
mtricas de prediccin y mtricas de control
Explicar cmo la medida puede ser usada en la
evaluacin del software y las limitaciones de la
medida del software
12/05/16
1261
Tpicos cubiertos
Calidad
del proceso y el producto

La
certidumbre de calidad y
estndares
Planificacin de calidad
Control de calidad
12/05/16
1262
Gestin de la calidad del

software
Se
preocupa por asegurar el nivel requerido de

calidad logrado en un producto del software.
Involucra una definicin apropiada de los
estndares de calidad y procedimiento y
asegurando que estos son seguidos.
Debe apuntar a desarrollar una cultura de
calidad donde la calidad es vista como
responsabilidad de todos.
12/05/16
1263
Qu es la calidad?
Calidad, simplemente, significa que un producto debe cumplir

con su especificacin.
Esto es problemtico para los sistemas de software
Hay una tensin entre los requerimientos de calidad del
cliente (eficiencia, fiabilidad, etc.) y los requerimientos de
calidad del desarrollador (mantenibilidad, reusabilidad, etc.);
Algunos
requerimientos de calidad son difciles de
especificar de una manera no ambigua;
Las
especificaciones del software son normalmente
incompletas y a veces inconsistentes.
12/05/16
1264
El compromiso de la
calidad
Nosotros
no podemos esperar las

especificaciones para mejorar, antes de
una provechosa atencin a la gestin de la
calidad.
Nosotros
debemos
poner
los
procedimientos de gestin en lugar de
mejorar la calidad a pesar de la
especificacin imperfecta.
12/05/16
1265
Alcance de la gestin de
calidad
La
gestin de calidad es particularmente

importante para grandes, complejos sistemas.
La documentacin de la calidad es un registro
del progreso y continuidad del soporte del
desarrollo como los cambios del equipo de
desarrollo.
Para los ms pequeos sistemas, la gestin
de calidad necesita menos documentacin y
se debe enfocar en establecer una cultura de
calidad.
12/05/16
1266
Actividades de gestin de
calidad
La certidumbre de calidad
Establecer procedimientos organizacionales y estndares
para la calidad.
Seleccionar procedimientos aplicables y estndares para
un proyecto particular y modificar estos como es requerido.
Control de calidad
Asegurar que los procedimientos y estndares sean
seguidas por el equipo de desarrollo de software.
La gestin de calidad debe estar separada de la gestin del
proyecto para asegurar la independencia.
12/05/16
1267
Gestin de calidad y
desarrollo de software
Proceso de
desarrollo del
software
D1
D2
D3
D4
D5
Proceso de
gestin de
calidad
Estndares y
procesos
12/05/16
Plan de
calidad
Informes de revisin
de calidad
1268
Proceso y calidad del

producto
La
calidad del desarrollo de un producto est

influenciada por la calidad del proceso de
produccin.
Esto es importante en el desarrollo del software,
puesto que algunos atributos de calidad son
difciles de evaluar.
Sin
embargo, hay una muy complejo y
pobremente entendida relacin entre el proceso
de software y la calidad del producto.
12/05/16
1269
Calidad basada en el proceso
Hay un enlace directo entre el proceso y el producto en

bienes manufacturados.
Mas complejo para el software porque:
La aplicacin de habilidades individuales y la experiencia
son particularmente importantes en el desarrollo del
software;
Los factores externos como la novedad de una aplicacin o
la necesidad para un plan acelerado de desarrollo pueden
daar la calidad del producto.
El cuidado que debe tenerse para no imponer estndares de
procesos inapropiados estos podrn reducir en lugar de
mejorar la calidad del producto.
12/05/16
1270
Calidad basada en el proceso
Definir
Definirelel
proceso
proceso
Proceso
Procesode
de
mejora
mejora
12/05/16
Acceder
Accederlala
calidad
calidaddel
del
producto
producto
Desarrollar
Desarrollar
elelproducto
producto
No
Calidad
Calidad
OK
OK
Si
Proceso
Procesode
de
estandarizacin
estandarizacin
1271
La calidad del proceso

prctica
Definir
los estndares del proceso tal como

deben conducirse las revisiones, la gestin de
configuracin, etc.
Supervisar
el proceso de desarrollo para
asegurar que se estn siguiendo los estndares.
Informe del proceso para la gestin del proyecto
y terceros del software.
No usar prcticas impropias simplemente porque
se han establecido los estndares.
12/05/16
1272
Certidumbre de la calidad
y estndares
Los
estndares son la clave para una gestin de

calidad efectiva.
Estos pueden ser internacionales, nacionales,
organizacionales o estndares de proyecto.
Estndares del producto define caractersticas
que todos los componentes deben exhibir, por
ejemplo, un estilo comn de programacin.
Estndares del proceso define como el
proceso del software debe promulgarse.
12/05/16
1273
Importancia de los estndares

Encapsulamiento
de mejor prctica evita

la repeticin de errores del pasado.
Ellos son una armazn para la certidumbre
de calidad del proceso ellos involucran la
complacencia de comprobacin de los
estndares.
Ellos proporcionan continuidad el nuevo
personal puede entender la organizacin
por entendimiento de los estndares que
son usados.
12/05/16
1274
Producto y estndares del

proceso
Estndares del producto
Estndares del proceso
Formulario de revisin del Conducta de revisin del diseo
diseo
Estructura del documento de La sumisin de documento para
requerimientos
MC
Formato de encabezamiento Proceso
del mtodo
versin
de
lanzamiento
de
Estilo de programacin en Plan del proyecto de aprobacin

Java
del proceso
Formato
proyecto
del
plan
del Proceso de control de cambio
Formulario de demanda del Prueba

del
cambio
magnetofnico
12/05/16
proceso
1275
Problemas con los estndares

Ellos
pueden no verse como relevantes y

actualizados por los ingenieros de software.
Ellos a veces involucran demasiadas formas
burocrticas de completar.
Si ellos no son soportados por herramientas
de software, el trabajo manual tedioso es a
menudo para mantener la documentacin
asociada con los estndares.
12/05/16
1276
Desarrollo de estndares
Involucrar a los practicantes en el desarrollo. Los
ingenieros deben entender la razn que est debajo
de un estndar.
Revisar estndares y su uso regularmente. Los
estndares pueden rpidamente volverse anticuadas
y esto reduce su credibilidad entre los practicantes.
Los estndares detalladas deben tener asociadas
herramientas de soporte. El excesivo trabajo de
oficina es la ms significativa queja contra los
estndares.
12/05/16
1277
ISO 9000
Un
conjunto internacional de estndares para

la gestin de calidad.
Aplicable para un rango de organizaciones
desde fbricas para reparar las industrias.
ISO 9001 aplicable para organizaciones que
disean, desarrollan y mantienen productos.
ISO 9001 es un modelo genrico del proceso
de calidad que puede ser instanciado para
cada organizacin usando el estndar.
12/05/16
1278
ISO 9001
Responsabilidad de gestin
Control
de
conformes
productos
Sistema de calidad
no Control de diseo
Manejo,
almacenamiento, Compra
empaquetamiento y entrega
Productos proporcionados por Identificacin
el comprador
trazabilidad
del
producto
Control del proceso
Inspeccin y prueba
Inspeccin y equipo de prueba
Inspeccin y estado de prueba
Revisin del contrato
Accin correctiva
Control del documento
Registros de calidad
Auditorias de calidad interna
Entrenamiento
Reparacin
Tcnicas estadsticas
12/05/16
1279
Certificacin ISO 9000

Los
estndares
de
calidad
y
procedimientos deben ser documentados
en un manual de calidad organizacional.
Un cuerpo puede certificar que el manual
de calidad de la organizacional conforme a
los estndares ISO 9000.
Algunos
clientes demandan a los
proveedores
que
sean
ISO
9000
certificados aunque la necesidad de
flexibilidad aqu se reconoce cada vez ms.
12/05/16
1280
ISO 9000 y gestin de calidad

Modelos
Modelosde
de
calidad
ISO
9000
calidad ISO 9000
Instanciado como
Manual
Manualde
decalidad
calidad
de
la
organizacin
de la organizacin
Documentos
Instanciado como
Es usado para
desarrollo
Plan
Plande
decalidad
calidad
del
Proyecto
del Proyecto11
Plan
Plande
decalidad
calidad
del
Proyecto
del Proyecto22
Proceso
Procesode
de
calidad
de
calidad delala
organizacin
organizacin
Plan
Plande
decalidad
calidad
del
Proyecto
del Proyecto33
Gestin
Gestinde
de
calidad
del
calidad del
proyecto
proyecto
Soportes
12/05/16
1281
Estndares de documentacin
Particularmente importante los documentos son la

manifestacin tangible del software.
Estndares del proceso de documentacin
Relacionado con cmo debe ser desarrollado, validado y
mantenido.
Documentar estndares
Relacionado con contenido de documentos, estructura, y
apariencia.
Documentar estndares de intercambio
Relacionado
con la compatibilidad de documentos
electrnicos.
12/05/16
1282
Proceso de documentacin
Crear
Crearboceto
boceto
inicial
inicial
Fase 1:
Creacin
Corregir
Corregirtexto
texto
Fase 1:
Publicacin
Configurar
Configurar
texto
texto
Fase 3:
Produccin
12/05/16
Revisar
Revisar
boceto
boceto
Incorporara
Incorporara
comentarios
comentarios
de
derevisin
revisin
Rebosquejar
Rebosquejar
documento
documento
Documento aprobado
Producir
Producir
boceto
bocetofinal
final
Chequear
Chequear
boceto
bocetofinal
final
Documento aprobado
Revisar
Revisar
esquema
esquema
Producir
Producirde
de
matrices
de
matrices de
impresin
impresin
Imprimir
Imprimir
copias
copias
1283
Estndares de documento
Documentar estndares de identificacin
Como
son singularmente identificados los
documentos.
Documentar estndares de estructuras
Estructura estndar para documentos del proyecto.
Documentar estndares de presentacin
Define fuentes y estilos, use de logotipos, etc.
Documentar estndares de actualizacin
Define cmo cambian las versiones previas y se
reflejan en un documento.
12/05/16
1284
Estndares de intercambio
de documentos
Los estndares de intercambio permiten documentos

electrnicos para ser intercambiados, envos por correo, etc.
Los documentos son producidos usando diferentes sistemas
y en diferentes computadoras. Incluso cuando se usan
herramientas estndares se necesita definir convenciones
para su uso, por ejemplo, usar hojas de estilo y macros.
Necesidad de archivar. El tiempo de vida de sistemas de
procesamiento de palabra puede ser mucho menor que el
tiempo de vida del software a ser documentado. Un estndar
de archivo puede ser definido para asegurar que el
documento puede ser accedido en el futuro.
12/05/16
1285
Un
plan de calidad presenta las calidades

deseadas del producto y cmo estas son
evaluadas y define los atributos de calidad ms
significativos.
El plan de calidad debe definirse el proceso de
valoracin de calidad.
Deben
presentarse
que
estndares
organizacionales y donde sea necesario, definir
nuevos estndares a ser usados.
12/05/16
1286
Planes de calidad
Estructura del plan de calidad
Introduccin del producto;
Planes del producto;
Descripciones del proceso;
Metas de calidad;
Riesgos y gestin de riesgos.
Planes de calidad deben ser documentos cortos,
sucintos
Si ellos son demasiado largos, nadie los leer
12/05/16
1287
Atributos de calidad del

software
Seguridad fsica
Comprensibilidad
Portabilidad
Seguridad contra
delitos
Comprobabilidad
Usabilidad
Fiabilidad
Adaptabilidad
Reusabilidad
Elasticidad
Modularidad
Eficiencia
Robustez
Complejidad
Aprendebilidad
12/05/16
1288
Control de calidad
Esto
involucra la comprobacin del

proceso de desarrollo de software para
asegurar que los procedimientos y
estndares sern seguidos.
Hay dos aproximaciones para el control de
calidad
Revisiones de calidad;
Valoracin del software automatizada y
medida del software.
12/05/16
1289
Revisiones de calidad
Es el principal mtodo de validacin de calidad de un
proceso o producto.
Un grupo examina parte o todo de un proceso o
sistema y su documentacin para encontrar
problemas potenciales.
Hay diferentes tipos de revisin y con diferentes
objetivos
Inspecciones para remover defectos (producto);
Revisiones
para la valoracin del progreso
(producto y proceso);
Revisiones de calidad (producto y proceso).
12/05/16
1290
Tipos de revisin
Tipos de
revisin
Propsito principal
Inspecciones Para detectar los errores detallados en los

de diseo o requerimientos, diseo o cdigo. Una lista de control
programa
de posibles errores debe manejar la revisin.
Revisiones
del progreso
Para mantener la informacin para la gestin acerca

del progreso global del proyecto. Este es un proceso
y una revisin del producto y se preocupa por los
costos, planes y horarios.
Revisiones
de calidad
Llevar a cabo un anlisis tcnico de componentes del

producto o documentacin para encontrar las
desigualdades entre la especificacin y el diseo del
componente, cdigo o documentacin y asegurar los
estndares de calidad definidos se han seguido.
12/05/16
1291
Un grupo de gente examina cuidadosamente parte o
todo un sistema de software y la documentacin
asociada.
Cdigo, diseos, especificaciones, planes de prueba,
estndares, etc., pueden todos ser revisados.
El software o documentos pueden ser fuera de
contrato en una revisin que significa que ese
progreso para la prxima fase de desarrollo, ha sido
aceptado por la direccin.
12/05/16
1292
Funciones de revisin
Funcin
de calidad ellas son parte del

proceso de gestin de calidad general.
Funcin de gestin de proyecto ellas
proveen de informacin para los gerentes del
proyecto.
Entrenamiento y funcin de comunicacin
el conocimiento del producto es pasado entre los
miembros del equipo de desarrollo.
12/05/16
1293
El
objetivo es el descubrimiento de los defectos e

inconsistencias del sistema.
Cualquier documento producido en el proceso
puede ser revisado.
Los equipos de revisin deben ser relativamente
pequeos y las revisiones deben ser bastante
cortas.
Los registros de revisin de calidad siempre
deben ser mantenidos.
12/05/16
1294
Resultados de la revisin
Los comentarios hechos durante la revisin sern

clasificados
Ninguna accin. Ningn cambio para el software o
documentacin es requerido;
Refiere para reparar. El diseador o programador
debe corregir una falla identificada;
Reconsiderar
el diseo global. El problema
identificado en la revisin impacta en otras partes del
diseo. Algn juicio global debe hacerse acerca de la
manera ms rentable de solucin del problema;
Los requerimientos y especificacin de errores pueden
tener que ser enviados al cliente.
12/05/16
1295
Medidas y mtricas del software

La medida del software est relacionada con la
derivacin de un valor numrico para un atributo del
producto software o proceso.
Esto permite comparaciones objetivas entre tcnicas y
procesos.
Aunque algunas compaas han introducido programas
de medidas, la mayora de organizaciones aun no
hacen uso sistemtico de la medida del software.
Hay alguno que estableci estndares en esta rea.
12/05/16
1296
Mtricas del software

Algn tipo de mediada que relaciona a un sistema de
software, proceso o documentacin relacionada
Lneas de cdigo en un programa, el ndice Fog,
nmero de persona das requerido para desarrollar un
componente.
Permite que el software y el proceso de software
ser
cuantificados.
Puede ser usado para predecir atributos del producto o
para el control del proceso de software.
Las mtricas del producto pueden ser usadas para
predicciones generales o para identificar componentes
anmalos.
12/05/16
1297
Mtricas de control y prediccin

Proceso
Procesode
de
software
software
Producto
Producto
software
software
Medidas
Medidasde
de
control
control
Medidas
Medidasde
de
prediccin
prediccin
Decisiones
Decisiones
de
degestin
gestin
12/05/16
1298
Asunciones de mtricas
Una
propiedad del software puede ser mediada.

La interrelacin existe entre lo que nosotros
podemos saber y lo que nosotros queremos
saber know. Nosotros slo podemos medir
atributos internos, pero a menudo son ms
interesantes los atributos externos del software
Esta interrelacin se ha formalizado y validado.
Puede ser ms difcil relacionar lo que puede ser
medido para los atributos de calidad externos
deseables.
12/05/16
1299
Atributos internos y externos

Mantenibilidad
Mantenibilidad
Fiabilidad
Fiabilidad
Portabilidad
Portabilidad
Usabilidad
Usabilidad
12/05/16
Nmero
Nmerode
deparmetros
parmetros
de
deprocedimiento
procedimiento
Complejidad
Complejidad
ciclomtica
ciclomtica
Tamao
Tamaodel
delprograma
programa
en
enlneas
lneasde
decdigo
cdigo
Nmero
Nmerode
demensajes
mensajes
de
deerror
error
Longitud
Longitudde
demanual
manual
del
delusuario
usuario
1300
El proceso de medida
Un
proceso de mediada del software puede ser

parte del proceso de control de calidad.
La recoleccin de datos durante este proceso
debe ser mantenida como un recurso
organizacional.
Una vez que una base de datos de medidas ha
sido establecida, las comparaciones a travs
de proyectos se hacen posibles.
12/05/16
1301
Proceso de medida del producto

Analizar
Analizar
componentes
componentes
anmalas
anmalas
Elegir
Elegirmedidas
medidas
aaser
serhechas
hechas
Seleccionar
Seleccionar
componentes
componentes
ser
serevaluadas
evaluadas
Identificar
Identificar
medidas
medidas
anmalas
anmalas
Medir
Medir
caractersticas
caractersticasde
de
componentes
componentes
12/05/16
1302
Recoleccin de datos
Un
programa de mtricas debe estar basado en

un conjunto de productos y datos de proceso.
Los
datos
deben
ser
recolectados
inmediatamente (no en retrospectiva) y si es
posible, automticamente.
Tres tipos de recoleccin automtica de datos
Anlisis del producto esttico;
Anlisis del producto dinmico;
Procesar comparacin de datos.
12/05/16
1303
La exactitud de datos
No
recolectar datos innecesarios

Las preguntas a ser contestadas deben ser
decididas de antemano y los datos requeridos
identificados.
Decir a las personas por qu los datos deben ser
recolectados.
No debe ser parte de la evaluacin del personal.
No confiar en la memoria
Recolectar los datos cuando no son generado
despus de que un proyecto ha finalizado.
12/05/16
1304
Mtricas del producto
Una mtrica de calidad debe ser un predictor de calidad del

producto.
Clases de mtricas del producto
Las mtricas dinmicas son recolectadas por medidas
hechas en una ejecucin de programa;
Las mtricas estticas son recolectadas por medidas
hechas de las representaciones del sistema;
Las mtricas dinmicas ayudan a evaluar la eficiencia y
la fiabilidad, las mtricas estticas ayudan a evaluar la
complejidad, la comprensibilidad y la mantenibilidad.
12/05/16
1305
Mtricas dinmicas y
estticas
Las mtricas dinmicas estn estrechamente
relacionadas a los atributos de calidad del software
Es relativamente fcil para medir el tempo de
respuesta de un sistema (atributo de desempeo)
o el nmero de fallas (atributo de fiabilidad).
La mtricas dinmicas tienen un relacin indirecta
con los atributos de calidad
Se necesita intentar y derivar una interrelacin
entre estas mtricas y propiedades como la
complejidad, comprensibilidad y mantenibilidad.
12/05/16
1306
Mtricas del producto

software
Mtricas del software
Descripcin
Fan-in /Fan-out
Fan-in es una medida del nmero de funciones o mtodos que llaman alguna otra
funcin o mtodo (digamos X). Fan-out es el nmero de funciones que son
llamadas por la funcin X. Un alto valor para fan-in significa que X se acopla
hermticamente al resto del diseo y los cambios para X tendrn extenso golpe
en los efectos. Un alto valor para Fan-out sugiere que la complejidad global de X
puede ser alta debido a la complejidad de la lgica del control necesario para
coordinar los componentes llamados.
Longitud del cdigo
sta es una medida del tamao de programa. Es probable que esta sea, la ms
grande de tamaos de cdigo de un componente, ea ms compleja y propensa a
error. La longitud de cdigo ha mostrado ser una de las mtricas ms fiables por
predecir la propensin a error de los componentes.
Complejidad
ciclomtica
Esta es una medida de la complejidad del control de un programa. Esta

complejidad del control puede relacionarse para programar la comprensibilidad.
Yo discuto cmo calcular la complejidad ciclomtica en el Captulo 22.
Longitud
identificadores
de
Esta es una medida de la media longitud de identificadores distintos en un

programa. El ms largo de los identificadores, el ms probablemente de ser
significativo y el ms entendible del programa.
Profundidad
de
anidacin condicional
Esta es una medida de la profundidad de anidar del estamento if en un programa.

Profundamente anidados los estamentos if son duras de entender y estn
potencialmente propensas a error.
ndices Fog
Esta es una medida de la media de la longitud de palabras y frases en los

documentos. El ms alto el valor para el ndice Fog, el ms difcil el documento
es el entendimiento.
12/05/16
1307
Mtricas orientadas al
objeto
Mtricas orientadas al
objeto
Descripcin
Profundidad del rbol Esta representa el nmero de niveles discretos en el rbol de la herencia
de herencia
dnde las subclases heredan atributos y operaciones (mtodos) de las
superclases. El ms profundo rbol de herencia, el ms complejo del
diseo. Muchas clases de objetos diferentes pueden tener que ser
entendidas para entenderlas clases de objetos en las hojas del rbol.
Mtodo
out
Fan-in
/Fan- Esta se relaciona directamente a fan-in y fan-out descritas anteriormente

y significa la misma cosa esencialmente. Sin embargo, puede ser
apropiado hacer una distincin entre las llamadas de otros mtodos
dentro del objeto y que puede llamar de mtodos externos.
Mtodos pesados por Esta es el nmero de mtodos que son incluidos en una clase pesada por
la clase
la complejidad de cada mtodo. Por consiguiente, un mtodo simple
puede tener una complejidad de 1 y un mtodo grande y complejo un
valor mucho ms alto. El ms grande el valor para este mtrica, el ms
complejo la clase de objetos. Los objetos complejos son ms
probablemente difciles de entender. Ellos no pueden ser lgicamente
cohesivos de modo que no puede reusarse eficazmente como las
superclases en un rbol de herencia.
Nmero
operaciones
desborde
12/05/16
de Esta es el nmero de operaciones en una superclase que se sobreponen

de en una subclase. Un valor alto para este mtrica indica que la superclase
usada no puede ser un padre apropiado para la subclase.
1308
Anlisis de la medida
No
siempre es obvio que datos

significan
Analizar los datos recolectados es
difcil.
Los profesionales de estadstica deben
ser consultados si estn disponibles.
El anlisis de datos debe tener en
cuenta las circunstancias locales.
12/05/16
1309
Sorpresas de la medida
Reduciendo el nmero de fallas de un programa

lleva a un nmero aumentado de llamadas de
oficina de ayuda
El programa es ahora pensado como ms fiable y
as tiene un mercado mas extensamente diverso.
El porcentaje de usuarios llaman a la oficina de
ayuda puede haber disminuido, pero el total
puede aumentar;
Un sistema ms fiable es usado de una manera
diferente en un sistema donde los usuarios
trabajan alrededor de las fallas Esto lleva a ms
llamadas de la oficina de ayuda
12/05/16
1310
Puntos clave
La gestin de calidad del software se preocupa por
asegurar que ese software rene sus estndares
requeridos.
Los procedimientos de certidumbre de calidad deben
ser documentados en un manual de calidad
organizacional
Los estndares son un encapsulamiento de la mejor
prctica.
Las revisiones son las ms ampliamente usadas
aproximaciones para evaluar la calidad del software
12/05/16
1311
Puntos clave
La
medida del software recoge informacin

acerca del proceso de software y el
producto software.
Las mtricas de calidad del software deben
ser usadas para identificar componentes
potencialmente problemticos.
No
hay
mtricas
de
software
estandarizadas y universalmente aplicables.
12/05/16
1312
Captulo 27
Mejora del
proceso
12/05/16
1313
Objetivos
Explicar
los principios de mejora del proceso de
software
Explicar cmo los factores del proceso de
software influyen en la calidad del software y la
productividad
Explicar cmo desarrollar los modelos simples de
desarrollo de software
Explicar la nocin de capacidad del proceso en el
modelo de mejora del proceso MCMI
12/05/16
1314
Tpicos cubiertos
Calidad
del proceso y del producto

Clasificacin del proceso
Medida del proceso
Anlisis del proceso y modelamiento
Cambio del proceso
La armazn de mejora del proceso CMMI
12/05/16
1315
Mejora del proceso

El
entendimiento del proceso existente y la

introduccin de cambios al proceso para mejorar
la calidad del producto, reduce los costo o acelera
los calendarios.
Ms trabajo de mejora del proceso se ha
enfocado hasta ahora en la reduccin del defecto.
Esto refleja la creciente atencin pagada por la
industria para la calidad.
Sin embargo, otros atributos del proceso pueden
se tambin el enfoque de mejora.
12/05/16
1316
Atributos del proceso

Caractersticas del
proceso
Descripcin
Comprensibilidad
Hasta qu punto el proceso se define explcitamente y cmo de fcil

es l entender la definicin del proceso?
Visibilidad
Las actividades del proceso culminan en los resultados claros para

que el progreso del proceso sea externamente visible?
Soportabilidad
Hasta qu punto las herramientas CASE pueden ser usadas para

apoyar las actividades del proceso?
Aceptabilidad
El proceso definido es aceptable y utilizable por los ingenieros

responsables para producir el producto del software?
Fiabilidad
El proceso se disea de tal manera que se evitan los errores del

proceso o se entrampan antes de que ellos produzcan los errores del
producto?
Robustez
El proceso puede continuar a pesar de los problemas inesperados?
Mantenibilidad
El proceso puede evolucionar para reflejar requerimientos

organizacionales cambiantes o las mejoras del proceso
identificadas?
Rapidez
Cun rpido pueda el proceso entregar un sistema desde que una

especificacin dada se ha completado?
12/05/16
1317
El ciclo de mejora del proceso

Medida
Medida
Anlisis
Anlisis
Cambio
Cambio
12/05/16
1318
Fases de la mejora del

proceso
Medida del proceso
Los atributos del proceso actual son medidos.
Estos son una lnea de base para evaluar mejoras.
Anlisis del proceso
El actual proceso es evaluado y los cuellos de
botella y debilidades son identificados.
Cambio del proceso
Los cambios para el proceso que han sido
identificados durante el anlisis son introducidos.
12/05/16
1319
Calidad del proceso y del

producto
La calidad del proceso y calidad del producto estn

estrechamente relacionados y los beneficios de la
mejora del proceso se levanta porque la calidad del
producto depende del proceso de desarrollo.
Un buen proceso es normalmente requerido para
producir un buen producto.
Para productos manufacturados, el proceso es el primer
determinante de calidad.
Para la actividad basada en el diseo, otros factores
estn tambin involucrados, especialmente las
capacidades de los diseadores.
12/05/16
1320
Factores de calidad de
producto principales
Tecnologa de
desarrollo
Calidad
del
proceso
Calidad del
producto
Calidad
de la
gente
Costo, tiempo y
calendario
12/05/16
1321
Factores de calidad
Para
proyectos grandes con capacidades

promedio, proceso de desarrollo determina
la calidad del producto.
Para pequeos proyectos, la capacidad de los
desarrolladores es el principal determinante.
La tecnologa de desarrollo es particularmente
significativa para pequeos proyectos.
En todos los casos, si un calendario poco
realista es impuesto, entonces, la calidad del
producto sufrir.
12/05/16
1322
Clasificacin del proceso
12/05/16
Informal
Ningn modelo de proceso detallado. El equipo de desarrollo
elige su propia manera de trabajo.
Manejado
Un modelo de proceso definido que maneja el proceso de
desarrollo.
Metdico
Procesos apoyados por algn mtodo de desarrollo como el
RUP.
Apoyado
Proceso apoyado por herramientas CASE automatizadas.
1323
Aplicabilidad del proceso

Prototipos
Prototipos
Proceso
Proceso
informal
informal
Proceso
Proceso
manejado
manejado
Proceso
Proceso
metdico
metdico
12/05/16
Sistemas
Sistemasde
detiempo
tiempode
devida
vidacortos
cortos
Sistemas
Sistemasde
denegocios
negocios L4G
L4G
Sistemas
Sistemasde
detamao
tamaopequeo/mediano
pequeo/mediano
Sistemas
Sistemasgrandes
grandes
Productos
Productosde
detiempo
tiempode
devida
vidalargo
largo
Dominios
Dominiosde
deaplicacin
aplicacinbien
bien
entendidos
entendidos
Sistemas
Sistemasde
dereingienera
reingienera
1324
Elegir proceso
El proceso usado debe depender del tipo de producto que se est
desarrollando
Para grandes sistemas, la gestin es normalmente el principal
problema que se necesita para un proceso estrictamente manejado;
Para pequeos sistemas, ms informalidad es posible.
No hay ningn proceso uniformemente aplicable que pueda ser
estandarizado dentro de una organizacin
Puede incurrirse en altos costos si se fuerza un proceso inapropiado
a un equipo de desarrollo;
Mtodos inapropiados puede tambin incrementar los costos y
pueden llevar a reducir la calidad.
12/05/16
1325
Soporte de herramientas
del proceso
Proceso
Proceso
informal
informal
Herramientas
genricas
12/05/16
Proceso
Proceso
manejado
manejado
Herramientas
de gestin de
configuracin
Proceso
Proceso
metdico
metdico
Herramientas
de gestin de
proyecto
Anlisis y
bancos de
trabajo del
diseo
Proceso
Procesode
de
mejora
mejora
Herramientas
especializadas
1326
Medida del proceso
Dondequiera sea posible, los datos de procesos cuantitativos

deben ser recolectados
Sin embargo, donde las organizaciones no han definido
claramente los estndares del proceso esto es muy difcil
si no se sabe qu medir. Un proceso puede tener que ser
definido antes que cualquier medida sea posible.
Las medidas del proceso deben ser usadas para evaluar las
mejoras del proceso
Pero esto no significa que las medidas deben manejar las
mejoras. El manejador de mejoras debe ser los objetivos
de la organizacin.
12/05/16
1327
Clases de medidas del

proceso
Toma
tiempo para que las actividades del

proceso sean completadas
Por ejemplo, el tiempo de calendario o esfuerzo
para completar una actividad o proceso.
Los recursos requeridos para
procesos o
actividades
Por ejemplo, esfuerzo total en personas-das.
Nmero de ocurrencias de un evento particular
Por
ejemplo, el nmero de defectos
descubiertos.
12/05/16
1328
Paradigma Meta-PreguntaMtrica
Metas
Qu
est probando la organizacin para
lograr? El objetivo de mejora del proceso es
satisfacer estas metas.
Preguntas
Las preguntas sobre las reas de incertidumbre
relacionadas a las metas. Se necesita el
conocimiento del proceso para derivar stas.
Mtricas
Las medidas a ser recolectadas para responder
las preguntas.
12/05/16
1329
Anlisis del proceso y

modelamiento
Anlisis
del proceso
El estudio de
procesos existentes para
entender las interrelaciones entre las partes de
un proceso y compararlos con otros procesos.
Modelamiento del proceso
La documentacin de un proceso que registra
las tareas, los roles y las entidades usadas;
Los modelos de proceso pueden presentarse
desde diferentes perspectivas.
12/05/16
1330
Anlisis del proceso y

modelamiento
Estudiar un proceso existente para entender sus
actividades.
Producir un modelo abstracto del proceso. Se debe
representar normalmente esto grficamente. Varias
vistas diferentes (por ejemplo, actividades,
entregables) pueden ser requeridas.
Analizar el modelo para descubrir problemas del
proceso. Esto involucra la discusin de actividades
del proceso con los stakeholders y el descubrimiento
de problemas y posibles cambios del proceso.
12/05/16
1331
Tcnicas de anlisis del

proceso
Modelos del proceso publicados y estndares del proceso

Siempre es mejor empezar el proceso de anlisis con un
modelo existente. Las personas, entonces, pueden extenderse
y cambiar esto.
Cuestionarios y entrevistas
Deben ser cuidadosamente diseadas. Los participantes
pueden decir lo que ellos piensan de lo que se quiere or.
Anlisis etnogrfico
Involucra la asimilacin del conocimiento del proceso por
observacin. La mejor para una anlisis a fondo de fragmentos
del proceso en lugar de la comprensin del proceso total.
12/05/16
1332
Elementos del modelo de

proceso 1
Actividad
Una actividad tiene un objetivo claramente definido, condiciones
(mostrada como un de entrada y salida. Ejemplos de actividades son la preparacin
rectngulo con sombra) de un conjunto de datos para probar un mdulo, codificacin de
una funcin o un mdulo, prueba de lectura de un documento,
etc. Generalmente, una actividad es atmica, es decir es la
responsabilidad de una persona o grupo. No se descompone en
las subactividades.
Proceso
(mostrado como un
rectngulo de esquinas
redondeadas
con
sombra)
Un proceso es un conjunto de actividades que tienen alguna

coherencia y cuyo objetivo es generalmente convenido dentro de
una organizacin. Ejemplos de procesos son el anlisis de
requerimientos, el diseo arquitectnico, la planificacin de
prueba, etc.
Entregable
Un entregable es una salida tangible de una actividad que es
(mostrado como un predecida en un plan del proyecto.
rectngulo con sombra)
Condicin
(mostrada como
paralelogramo)
12/05/16
Una condicin es una pre-condicin que debe cumplirse antes de

un que un proceso o actividad pueda empezar o un post-condicin
que se cumple despus de que un proceso o actividad ha
terminado.
1333
Elementos del modelo de

proceso 2
Rol
Un rol es una rea limitada de responsabilidad. Ejemplos de
(mostrada como un roles podran ser gerente de configuracin, ingeniero de
prueba, diseador de software, etc. Una persona puede
crculo con sombra)
tener varios roles diferentes y un solo rol puede estar
asociado con varias personas diferentes.
Excepcin
(no mostrado en los
ejemplos aqu pero
puede representarse
como una caja afilada
doble)
Una excepcin es una descripcin de cmo modificar el

proceso si algunos se han anticipado o un evento no
anticipado ocurre. Las excepciones son a menudo
indefinidas y se deja a la ingeniosidad de los gerentes del
proyecto e ingenieros para ocuparse de la excepcin.
Comunicacin
Un intercambio de informacin entre las personas o entre
(mostrada como una las personas y los sistemas de computadora de soporte.
Las comunicaciones pueden ser informales o formales. Las
flecha)
comunicaciones formales podran ser la aprobacin de un
entregable por un gerente del proyecto; las comunicaciones
informales podran ser el intercambio de correo electrnico
para resolverse las ambigedades en un documento.
12/05/16
1334
El mdulo de actividad de
prueba
Rol
Ingenier
Ingenier
oode
de
prueba
prueba
Pre-condicin
El
Elmdulo
mdulocompila
compila
sin
errores
sin erroresde
de
sintaxis
sintaxis
Entrada
Especificacin
Especificacin
del
delmdulo
mdulo
12/05/16
Responsable
de
Prueba
Pruebade
de
mdulo
mdulo
Post-condicin
Todas
Todaslas
laspruebas
pruebas
definidas
definidas
ejecutan
ejecutanen
enelel
mdulo
mdulo
Salidas
Firmado
Firmadofuera
fueradel
del
registro
de
prueba
registro de prueba
Proceso
Datos
Datosde
deprueba
prueba
del
mdulo
del mdulo
1335
Actividades en la prueba de mdulo

PREPARACION DE DATOS DE PRUEBA
Leer
especificacin
del mdulo
Preparar datos de
prueba de acuerdo
a la especificacin
Someter datos
de prueba a
revisin
Revisar datos
de prueba
PREPARACION DE LAS PARTES DE PRUEBA DE MODULO

Comprobar el
mdulo del sistema
de gestin de
configuracin
Leer y
comprender la
interfaz del
mdulo
Preparar partes
de prueba para el
mdulo
Compilar las
partes de
prueba
EJECUCION DE PRUEBA
Incorporar mdulo
con sus partes de
prueba
Ejecutar las
pruebas
aprobadas del
mdulos
Registrar los
resultados de pruebas
para pruebas de
regresin
INFORME DE PRUEBA
Escribir informe de pruebas
de mdulo incluyendo
detalles de descubrimiento
de problemas
12/05/16
Someter informe a
aprobacin
Someter
resultados de
prueba a CM
1336
Excepciones del proceso
Los proceso de software son complejos y los modelos de

proceso no pueden representar efectivamente como manejar
la excepciones:
Algunas personas clave se pueden enfermar justo antes
de una revisin crtica;
Una brecha en la seguridad contra delitos puede significar
que todas las comunicaciones externas estn fuera de
accin por varios das;
Reorganizacin organizacional;
Una necesidad de responder
a una demanda no
anticipada para nuevos propuestas.
Bajo estas circunstancias el mdulo es suspendido y los
gerentes usan su iniciativa para tratar con la excepcin.
12/05/16
1337
Cambios del proceso

Involucra hacer modificaciones al proceso
existente.
Esto puede involucrar:
Introduccin de nuevas prcticas, mtodos o
procesos;
Cambiar el ordenamiento de las actividades del
proceso;
Introduccin o remocin de entregables;
Introduccin
de
nuevos
roles
o
responsabilidades.
El cambio debe ser manejado por las metas de
medida.
12/05/16
1338
El proceso de cambio del

proceso
Identificar
mejoras
Introducir
cambios de
proceso
Priorizar
mejoras
Afinar
cambios de
proceso
Entrenar
ingenieros
Modelo del
proceso
12/05/16
Plan de
cambio del
proceso
Plan de
entrenamiento
Retroalimentacin
en mejoras
Modelo del
proceso
revisado
1339
Fases del cambio de proceso

Identificacin
de mejora.
Priorizacin de mejora.
Introduccin de cambio de proceso.
Entrenamiento de
cambio de
proceso.
Afinamiento del cambio
12/05/16
1340
La armazn de CMMI
12/05/16
La armazn de CMMI es la fase actual de trabajo en

la valoracin del proceso y mejora que empez el
Instituto de Ingeniera de Software en los aos
ochenta.
La misin del SEI es promover la transferencia de
tecnologa de software particularmente a los
contratistas de defensa de EEUU.
Ha tenido una influencia profunda en la mejora del
proceso
Modelo de Madurez de Capacidad introducido en
los tempranos 1990s.
La
armazn de madurez revisada (CMMI)
introducida en 2001.
1341
Valoracin de la
capacidad del proceso
Pensado
como un medio para evaluar hasta que

pinto los procesos de una organizacin siguen la
mejor prctica.
Proporcionando un medio para la valoracin, es
posible identificar reas de debilidad para la
mejora del proceso.
Ha habido varias valoraciones de proceso y
modelos de mejora, pero el trabajo del SEI ha
sido muy influyente.
12/05/16
1342
El modelo de madurez de
capacidad del SEI
12/05/16
Inicial
Esencialmente incontrolado
Repetible
Procedimientos de gestin del producto definidos y usados
Definido
Procedimientos de gestin del proceso y estrategias
definidas y usadas
Manejado
Estrategias ge gestin de calidad definidas y usadas
Optimizado
Estrategias de mejora del proceso definidas y usadas
1343
Problemas con el CMM
Prcticas asociadas con los niveles del modelos

Las compaas podran estar usando prcticas de diferentes
niveles al mismo tiempo, pero si no se usaron todas las
prcticas del nivel ms bajo no es posibles ir ms all de ese
nivel.
Discreto en lugar de continuo
No reconoce distinciones entre el tope y el fondo de los
niveles
Orientada a la prctica
Comprometido en cmo se hicieron las cosas (las prcticas)
en lugar de que las metas sean logradas.
12/05/16
1344
El modelo CMMI
Un
modelo de capacidad integrado que incluye el

software y valoracin de la capacidad de
ingeniera de sistemas.
El modelo tiene dos instanciaciones
Puesto en escena donde el modelo es
expresado en trminos de niveles de
capacidad;
Continuo donde la tasa de capacidad se
calcula.
12/05/16
1345
Componentes del modelo

CMMI
reas de proceso
24 reas de proceso que son relevantes para
capacidad de proceso y mejora han sido identificadas.
Estos son organizados en 4 grupos.
Metas
Las metas son descripciones de estados deseables de
la organizacin. Cada rea de proceso tiene metas
asociada.
Prcticas
Las prcticas son maneras de alcanzar una meta sin
embargo ellos son asesores y otras aproximaciones
para alcanzar las metas pueden ser usadas.
12/05/16
1346
reas de procesos CMMI 1
12/05/16
Gestin de procesos
Definicin de procesos organizacionales

Enfoque de procesos organizacionales
Entrenamiento organizacional
Desempeo de proceso organizacional
Innovacin y despliegue organizacional
Gestin de proyectos

Monitoreo y control del proyecto
Gestin de acuerdo al proveedor
Gestin del proyecto integrado
Gestin de riesgos
Enganchamiento integrado
Gestin del proyecto cuantitativo
1347
reas de procesos CMMI 2

Ingeniera
Desarrollo de requerimientos
Solucin tcnica
Integracin del producto
Verificacin
Validacin
Soporte
Gestin de configuracin
Gestin de calidad del proceso y el
producto
Medida y anlisis
Anlisis de decisin y resolucin
Ambiente organizacional para integracin
Anlisis causal y resolucin
12/05/16
1348
Metas de CMMI
Meta
rea de proceso
Las
acciones
correctivas
son Meta especfica en el Proyecto.
manejadas para el cierre cuando la Monitoreo y Control.
actuacin del proyecto o los resultados
se desvan significativamente del plan.
El desempeo real y el progreso del La meta especfica en proyecto que supervisa y
proyecto es supervisado contra el plan controla.
del proyecto.
Los requerimientos son analizados y La meta especfica
validados y una definicin de la requerimientos.
funcionalidad requerida se desarrolla.
en
el
desarrollo
de
Las causas de la raz de los defectos y La meta especfica en el anlisis causal y

otros problemas son sistemticamente resolucin.
determinadas.
El proceso se institucionaliza como un Meta genrica.
proceso definido.
12/05/16
1349
Prcticas CMMI
Prctica
Meta asociada
Analizar los requerimientos derivados para asegurar que Los

requerimientos
son
ellos son necesarios y suficientes
analizados y
validados y
una
definicin
de
la
Validar los requerimientos para asegurar que el producto funcionalidad requerida es
resultante se desempear tal como se intent en el desarrollada.
ambiente del usuario usando mltiples tcnicas que sean
apropiadas.
Seleccionar los defectos y otros problemas para el anlisis.
Las causas de raz de los

defectos y otros problemas
Realizar anlisis causal de defectos seleccionados y otros son
sistemticamente
problemas y proponer las acciones a realizar.
determinadas.
Establecer y mantener una poltica organizacional para El
proceso
planificar y realizar el proceso de desarrollo de institucionaliza como
requerimientos.
proceso definido.
se
un
Asignar responsabilidad y autoridad por realizar el proceso,

desarrollando los productos de trabajo y proporcionando
los servicios del proceso de desarrollo de requerimientos.
12/05/16
1350
Valoracin del CMMI

Examinar los procesos usados en la organizacin
y evaluar su madurez en cada rea del proceso.
Basado en una escala de 6 puntos;
No realizado;
Realizado;
Definido;
Cuantitativamente manejado;
Optimizado.
12/05/16
1351
El modelo CMMI
organizado
Comparable
con el software CMM.

Cada nivel de madurez tiene reas de proceso y
metas. Por ejemplo, el rea de proceso asociado
con el nivel manejado incluido:
12/05/16
Gestin de requerimientos;
Planificacin de proyectos;
Monitoreo del proyecto y control;
La gestin de acuerdo al proveedor;
Medida y anlisis;
Certidumbre de calidad del proceso y el producto.
1352
El modelo CMMI organizado

Nivel 5
Optimizado
Nivel 4
Cuantitativamente
manejado
Nivel 3
Definido
Nivel 2
Manejado
Nivel 1 Inicial
12/05/16
1353
Prcticas institucionales
Instituciones que operan al nivel manejado deben de

haber institucionalizado prcticas que se engranan
para la estandarizacin.
Establecer y mantener polticas para realizar el
proceso de gestin del proyecto;
Proveer recursos adecuados para realizar el
proceso de gestin del proyecto;
Monitorear y controlar el proceso de planificacin
del proyecto;
Revisar las actividades, estados y resultados del
proceso de planificacin del proyecto.
12/05/16
1354
El modelo CMMI continuo

Este es un modelo de grano fino que considera
individuos o grupos de prcticas y evalan su uso.
La valoracin de madurez no es slo un valor pero es un
conjunto de valores que muestran la madurez de
organizaciones en cada rea.
Los CMMI tasan cada area del proceso en niveles de 1
a 5.
Las ventajas de un acercamiento continuo es que la
organizaciones pueden recoger y escoger reas de
proceso para mejorar de acuerdo a sus necesidades
locales.
12/05/16
1355
Un perfil de capacidad del

proceso
12/05/16
1356
Puntos clave
La mejora del proceso involucra anlisis del
proceso, estandarizacin, medida y cambio.
Los procesos pueden ser clasificados como
informal, manejado, metdico y mejorado. Esta
clasificacin puede usarse para identificar el apoyo
de herramienta de proceso.
El ciclo de mejora de proceso involucra medida del
proceso, anlisis del proceso y cambio del proceso.
La medida del proceso debe ser usado para
contestar las preguntas especficas del proceso ,
basado en las metas de mejora organizacional.
12/05/16
1357
Puntos clave
Los tres tipos de mtricas del proceso usadas en el

proceso son mtricas del tiempo, mtricas de
utilizacin de recursos y mtricas de evento.
Los modelos de proceso incluyen descripcin de
tareas,
actividades,
roles,
excepciones,
comunicaciones, entregables y otros procesos.
El modelo de madurez del proceso CMMI integra
software y mejora del proceso de ingeniera de
sistemas.
La mejora del proceso en el modelo CMMI est
basado en alcanzar un conjunto de metas
relacionados para una buena practica de ingeniera de
sistemas.
12/05/16
1358
Captulo 28
Gestin de
configuracin
12/05/16
1359
Objetivos
Explicar
la importancia de la gestin de
configuracin del software (CM)
Describir las actividades clave de CM a saber
planificacin CM, gestin de cambio, gestin
de versin y construccin del sistema
Discutir el uso de herramientas CASE para
dar soporte a los procesos de gestin de
configuracin
12/05/16
1360
Tpicos cubiertos
Planificacin
de
gestin
de
configuracin
Gestin de cambio
Gestin de versin y lanzamiento
Construccin del sistema
Herramientas CASE para gestin de
configuracin
12/05/16
1361
Nuevas versiones de sistemas de software son creados

cuando ellos cambian:
Para diferentes mquinas/SO;
Ofreciendo diferentes funcionalidades;
Adecuando para requerimientos de usuario particulares.
La gestin de configuracin se preocupa por manejar la
evolucin de sistemas de software:
El cambio de sistema es una actividad de equipo.
El CM apunta para controlar los costos y esfuerzo
involucrados al hacer los cambios a un sistema.
12/05/16
1362
Involucra
el desarrollo y aplicacin de
procedimientos y estndares para manejar y
evolucionar un producto de software.
CM puede ser visto como parte un proceso ms
general de gestin de calidad.
Cuando es lanzado para CM, los sistemas de
software son a veces llamadas lneas de base
puesto que ellos son un punto de partida para el
desarrollo extenso.
12/05/16
1363
Familias de sistemas
Versin
Versin
PC
PC
Versin
Versin
HP
HP
Sistema
Sistema
inicial
inicial
Versin
Versin
PC
PC
Versin
Versin
WindowsXP
XP
Windows
Versin
Versin
Servidor
Servidor
VersinLinux
Linux
Versin
Versin
Versin
Sun
Sun
12/05/16
1364
Estndares CM
CM siempre debe estar basado en un conjunto de
estndares que son aplicados dentro de una
organizacin.
Los estndares deben definir cmo se identifican los
artculos y cmo son controlados los cambios y con son
manejadas las nuevas versiones.
Los estndares pueden estar basados en estndares
externos de CM (Por ejemplo, estndares IEEE para
CM).
Algunos estndares existentes estn basados en un
modelo de proceso de cascada los nuevos estndares
CM son necesitados para el desarrollo evolutivo.
12/05/16
1365
Desarrollo concurrente y
prueba
Una
hora (digamos 2pm) para la entrega de

componentes del sistema es convenida.
Una nueva versin de un sistema es construida a
partir de esos componentes por compilacin y
ligndolos a l.
Esta nueva versin es entregada para ser probada
usando pruebas predefinidas.
Las fallas que son descubiertas durante la prueba
son documentadas y son devueltos para los
desarrolladores del sistema.
12/05/16
1366
Construccin de un
sistema frecuente
Es
ms fcil encontrar problemas que provienen

de las interacciones de componente tempranas
en el proceso.
Esto alienta una prueba de unidad completa los
desarrolladores no estn bajo presin
de
romper la estructura.
Un proceso de gestin de cambio rgido es
requerido para guardar las huellas de los
problemas que han sido descubiertos y
reparados.
12/05/16
1367
Planificacin de la gestin de
configuracin
Todos
los productos de un proceso de software pueden

tener que ser manejados:
Especificaciones;
Diseos;
Programas;
Datos de prueba;
Manuales de usuario.
Miles
de documentos separados pueden ser
generados para un grande y complejo sistema de
software.
12/05/16
1368
El plan CM
Definir
los tipos de documentos para ser

manejados y y un esquema de denominacin del
documento.
Definir quin toma la responsabilidad para los
procedimientos CM y la creacin de lneas de base.
Definir las polticas para el control de cambio y
gestin de versin.
Definir los registros de CM que deben ser
mantenidos.
12/05/16
1369
El plan CM
Describir
las herramientas que deben ser usadas

para asistir los procesos de CM y cualquier
limitacin en su uso.
Definir el proceso de uso de la herramienta.
Definir la base de datos de CM usada para
registro de la informacin de la configuracin.
Puede incluir informacin tal como el CM de
software externo, procesos de auditora, etc.
12/05/16
1370
Identificacin del artculo

de configuracin
Los grandes proyectos tpicamente producen miles de

documentos que ser singularmente identificados.
Algunos de estos documentos deben ser mantenidos
para el tiempo de vida del software.
El esquema de denominacin de documento debe ser
definido de modo que los documentos relacionados
tengan nombres relacionados.
Un esquema jerrquico con los nombres multi-nivel es
probablemente la aproximacin ms flexible
12/05/16
PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE
1371
Jerarqua de configuracin
PCL TOOLS
COMPILE
EDIT
BIND
MAKEGEN
FORM STRUCTURE
DISPLAY
FORM - SPECS
12/05/16
QUERY
AST - INTERFACE
OBJECTS
CODE
HELP
FORM - IO
TESTS
1372
La base de datos de la
configuracin
Toda la informacin de CM debe ser mantenida en una base

de datos de la configuracin.
Esto debe permitir consultas acerca de la configuracin a ser
respondidas:
Qu tiene una particular versin del sistema?
Qu plataforma es requerida para una particular versin?
Qu versiones sern afectadas por un cambio al
componente X?
Cuntas fallas informadas en la versin T?
La base de datos de CM debe ser ligada preferentemente al
software a ser manejado.
12/05/16
1373
Implementacin de la
base de datos de CM
Puede
ser parte del ambiente integrado para el

apoyar el desarrollo del software.
La base de datos de CM y los documentos
manejados son todos mantenidos en el mismo
sistema
Las herramientas CASE pueden se integradas con
esto de modo que hay una ntima relacin entre las
herramientas CASE y las herramientas CM.
Ms normalmente, la base de datos de CM es
mantenida separadamente puesto que esto es ms
barato y ms flexible.
12/05/16
1374
Gestin del cambio

Sistemas
de software estn sujetos a las

demandas de cambio continuas:
De los usuarios;
De los desarrolladores;
De las fuerzas del mercado.
La gestin de cambio se preocupa por guardar
huellas de esos cambios y asegurar que ellos se
llevan a cabo de la manera ms rentable.
12/05/16
1375
El proceso de gestin del

cambio
Pedir cambio completando una forma de demanda de cambio
Analizar demanda de cambio
si el cambio es vlido entonces
Evaluar cmo el cambio podra llevarse a cabo
Evaluar el costo de cambio
Someter la demanda de cambio a la tabla de control
si el cambio es aceptado entonces
repetir
hacer cambios del software
someter el software cambiado a la aprobacin de calidad
hasta que la calidad del software sea adecuada
crear la nueva versin del sistema
si no
rechazar la demanda de cambio
si no
rechazar la demanda de cambio
12/05/16
1376
Formulario de demanda
de cambio
La definicin de una forma de demanda de cambio
es parte del proceso de planificacin de CM.
Esta
forma registra el cambio propuesto, el
demandador de cambio, la razn de por qu el
cambio fue sugerido y la urgencia del cambio (desde
el demandador del cambio).
Tambin registra la evaluacin del cambio, el anlisis
del impacto, costo del cambio y recomendaciones
(personal de mantenimiento del cambio).
12/05/16
1377
Formulario de demanda de
cambio
Formulario de demanda del cambio
Proyecto: Proteus /PCL-Tools
Nmero: 23/02
Demandador de cambio: I. Somerville
Fecha: 01/12/06
Demanda de cambio: Cuando el componente es seleccionado desde la estructura,
despliega el nombre del archivo donde est almacenado.
Analizador de cambio: G. Dean
Fecha del anlisis: 10/12/06
Componentes afectados: Display-Icon-Select, Display-Icon-Display
Componente asociado: Tabla Archivo
Valoracin del cambio: Relativamente simple de implementar puesto que una tabal de
nombre archivo esta disponible. Requiere el diseo e implementacin de un campo de
despliegue. No son requeridos cambios para asociar componentes.
Prioridad del cambio: Bajo
Implementacin del cambio:
Esfuerzo estimado: 0.5 das,
Fecha para CCB: 15/02/02
Fecha de demanda de CCB: 01/02/03
Implementador del cambio:
Fecha de cambio:
Fecha sometida a QA:
Decisin QA:
Fecha sometida a CM:
Comentarios
12/05/16
1378
Herramientas de rastreo
de cambio
Un
problema mayor en la gestin del cambio

es el estado de rastreo de cambio.
Las herramientas de rastreo de cambio
guardan el estado de cada demanda de
cambio y automticamente asegura que esas
demandas de cambio son enviadas a las
personas correctas en el momento correcto.
Integrado
con los sistemas de correo
electrnico que permiten la distribucin de
demanda de cambio electrnica.
12/05/16
1379
Tablero de control de
cambio
Los cambios deben ser revisados por un grupo
externo que decide si ellos son o no rentables desde
un punto de vista estratgico y organizacional en
lugar de un punto de vista tcnica.
Debe
ser independiente del responsable del
proyecto para el sistema. El grupo es a veces
llamado tablero de control de cambio.
El CCB puede incluir a representantes del cliente y
del personal del contratista.
12/05/16
1380
Historia de la derivacin
Este
es un registro de los cambios aplicados a un

documento o un componente de cdigo.
Debe registrar, en el contorno, el cambio hecho,
la razn del cambio, quin hizo el cambio y
cuando fue implementado.
Puede ser incluido como un comentario en el
cdigo. Si un estilo de prlogo estndar es usado
para la historia de la derivacin, las herramientas
pueden procesar esto automticamente.
12/05/16
1381
La informacin del ttulo

del componente
/ / Proyecto BANKSEC (IST 6087)
//
/ / BANKSEC-TOOLS/AUTH/RBAC/USER_ROLE
//
/ /Objeto: el currentRole
/ / Autor: N. PERWAIZ
/ / Fecha de creacin: 10 de noviembre del 2002
//
/ / Universidad de Lancaster 2002
//
/ /Historia de la modificacin
/ / Versin
Modificador
/ / 1.0
J. Jones
1/12/2002
Agrega ttulo
Sometido al CM
/ / 1.1
N. Perwaiz
9/4/2003
Nuevo campo
Req. de Cambio R07/02
12/05/16
Fecha
Cambio
Razn
1382
Versin y gestin de
lanzamiento
Inventar
un esquema de identificacin para

versiones del sistema.
Planear cuando una nueva versin del
sistema ser producida.
Asegurar que los procedimientos de gestin
de versin y herramientas sern propiamente
aplicadas.
Planear y distribuir lanzamientos de un nuevo
sistema.
12/05/16
1383
Versiones/variantes/
lanzamientos
Versin
Una instancia de un sistema que

funcionalmente distinta de alguna manera
otras instancias del sistema.
Variante Una instancia de un sistema que
funcionalmente idntica pero funcionalmente
distinta de otras instancias del sistema.
Lanzamiento Una instancia del sistema que
distribuida a usuarios fuera del equipo
desarrollo.
12/05/16
es
de
es
no
es
de
1384
Identificacin de la versin
Los
procedimientos para identificacin de la

versin deben definir una manera no ambigua de
identificar versiones de componentes.
Hay 3 tcnicas bsicas ara la identificacin de
componentes
Enumeracin de la versin;
Identificacin basada en atributos;
Identificacin orientada al cambio.
12/05/16
1385
Enumeracin de la versin
El
esquema de denominacin simple usa una

derivacin lineal
V1, V1.1, V1.2, V2.1, V2.2 etc.
La actual estructura de derivacin es un rbol o
una red en lugar de una secuencia.
Los nombres no son significativos.
Un esquema de denominacin jerrquica lleva a
menos errores en la identificacin de la versin.
12/05/16
1386
Estructura de derivacin
de la versin
1.0
VV1.0
1.1b
VV1.1b
1.1.1
VV1.1.1
1.1
VV1.1
1.2
VV1.2
2.0
VV2.0
2.1
VV2.1
2.2
VV2.2
1.1a
VV1.1a
12/05/16
1387
Identificacin basada en
atributo
Los atributos pueden ser asociadas con una versin con

la combinacin de atributos que identifican esa versin
Ejemplos
de atributos son Fecha, Creador,
Lenguaje de Programacin, Cliente, Estado, etc.
Esto es ms flexible que un esquema de denominacin
explcita para la recuperacin de la versin; Sin embargo
puede causar problemas con la singularidad el conjunto
de atributos tiene que ser escogido de modo que todas
las versiones pueden ser identificadas singularmente.
En la prctica una versin tambin necesita un nombre
asociado para la referencia fcil.
12/05/16
1388
Consultas basadas en
atributo
Una
importante ventaja de la identificacin

basada en atributo es que puede soportar
consultas de modo que se puede encontrar la
ms reciente versin en Java etc.
La consulta selecciona una versin dependiente
de valores de atributos
AC3D (lenguaje =Java, plataforma = XP,
fecha = Enero 2003).
12/05/16
1389
Identificacin orientada a
cambio
Integra las versiones y los cambios hechos para crear
esas versiones.
Usados por sistemas en lugar de los componentes.
Cada cambio propuesto tiene un conjunto de cambios que
describen cambios hechos para implementar ese cambio.
Los conjuntos de cambios son aplicados en secuencia
para que, en principio, una versin de un sistema que
incorpora un conjunto arbitrario de cambios pueda ser
creada.
12/05/16
1390
Gestin de lanzamiento
Los
lanzamientos deben incorporar cambios

forzados en el sistema por errores descubiertos
por usuarios y por cambios de hardware.
Ellos tambin deben incorporar la nueva
funcionalidad del sistema.
La planificacin del lanzamiento est interesada
con cundo emitir una versin del sistema como
un lanzamiento
12/05/16
1391
Lanzamiento del sistema
No slo un conjunto de programas ejecutables.

Puede tambin incluir:
Los archivos de configuracin definen cmo el lanzamiento
es configurado para una instalacin particular;
Los archivos de datos necesarios para una operacin del
sistema;
Un programa de instalacin o un guin de apariencia para
instalar el sistema en el hardware de destino;
Documentacin electrnica y en papel;
Publicidad empaquetada y asociada.
Los sistemas son ahora normalmente lanzados en discos
pticos (CD o DVD) o como archivos de instalacin
descargables desde la Web.
12/05/16
1392
Problemas de lanzamiento
El
cliente puede no querer una nueva versin del

sistema
Ellos pueden estar contentos con su actual
sistema de modo que la nueva versin puede
proporcionar una funcionalidad no deseada.
La gestin de lanzamiento no debe asumir que
todos los lanzamientos previos han sido
aceptados. Todos los archivos requeridos para un
lanzamiento deben ser recreados cuando un
nuevo lanzamiento es instalado.
12/05/16
1393
Hacer la decisin de
lanzamiento
La
preparacin y la distribucin un
lanzamiento del sistema es un proceso
expansivo.
Los factores como la calidad tcnica del
sistema, competencia, requerimientos de
comercializacin, y demandas de cambio del
usuario tienen todos influencia en la decisin
de cuando emitir un nuevo lanzamiento del
sistema.
12/05/16
1394
Estrategia de lanzamiento
de sistema
Factor
Calidad
sistema
tcnica
Descripcin
del
Si las fallas del sistema serias qu afectan la manera en que muchos clientes
usan el sistema son reportadas, puede ser necesario emitir un lanzamiento de
reparacin de la falla. Sin embargo, las fallas del sistema menores pueden ser
reparadas emitiendo los parches (a menudo distribuidas en Internet) que
pueden aplicarse al lanzamiento actual del sistema.
Cambios de plataforma
Se puede tener que crear una nueva versin de una aplicacin del software
cuando una nueva versin de la plataforma del sistema operativo es lanzada.
La quinta ley de Lehman

(ver Captulo 21)
Esto sugiere que el incremento de funcionalidad que es incluido en cada

lanzamiento sea aproximadamente constante. Por consiguiente, si ha habido
un lanzamiento del sistema con la nueva funcionalidad significativa, entonces
puede tener que ser seguido por un lanzamiento de reparacin.
Competencia
Un nuevo lanzamiento del sistema puede ser necesario porque un producto

de la competencia est disponible.
Requerimientos
comercializacin
de
La seccin de comercializacin de una organizacin puede haber hecho un

compromiso para los lanzamientos para estar disponible en una fecha
particular.
Propuestas de cambio del

cliente
Para los sistemas personalizados, los clientes pueden haber hecho y pagado
por un conjunto especfico de propuestas de cambio del sistema y ellos
esperan un lanzamiento del sistema en cuanto stos se hayan implementado.
12/05/16
1395
Creacin del lanzamiento

La creacin del lanzamiento involucra un colectivo de
todos los archivos y documentos requeridos para
crear un lanzamiento del sistema.
Las descripciones de configuracin tiene que ser
escritas para diferente hardware y las guas de
instalacin tiene que ser escritas.
El lanzamiento especfico debe ser documentado para
registrar exactamente que archivos sern usados para
crearlo Esto le permite ser recreado si es necesario.
12/05/16
1396

El
proceso de compilacin y enlace de

componentes del software dentro de un
sistema ejecutable.
Sistemas diferentes son construidos desde
diferentes combinaciones de componentes.
El proceso es ahora siempre apoyado por
herramientas
automatizados
que
son
manejados por guiones de construccin.
12/05/16
1397
Problemas de
construccin del sistema
Las instrucciones de construccin incluyen todos los componentes
requeridos?
Cuando hay muchos cientos de componentes que constituyen un
sistema, es fcil de encontrar uno afuera. Esto normalmente
debe ser detectado por el enlazador.
Es la versin de componente apropiada especificada?
Un problema ms significativa. Un sistema construido con una
mala versin puede trabajar inicialmente pero falla antes de la
entrega.
Estn todos los archivos de datos disponibles?
La estructuran debe confiar en archivos de datos estndar . Los
estndares varan de lugar a lugar.
12/05/16
1398
Problemas de
construccin del sistema
Son los archivos de datos las referencias dentro de los
componentes correctos?
Los nombres absolutos empotrados en el cdigo casi siempre
causan problemas como las convenciones de denominacin que
difieren de lugar a lugar.
Est construyndose el sistema para la plataforma correcta?
A veces se debe construir para una versin de SO especfico o
una configuracin de hardware.
Estn la versin correcta del compilador y otras herramientas de
software especificadas?
Diferentes versiones de compilador pueden generar ahora
diferente cdigo y los componentes compilados exhibirn diferente
comportamiento.
12/05/16
1399
Constructor
Constructor
delsistema
sistema
del
Construir
Construir
guin
guin
12/05/16
Sistemade
de
Sistema
gestinde
de
gestin
versin
versin
Compiladores
Compiladores
Versionesde
de
Versiones
componentede
de
componente
cdigofuente
fuente
cdigo
Enlazador
Enlazador
Componentes
Componentes
decdigo
cdigo
de
fuente
fuente
Cdigo
Cdigo
ejecutable
ejecutable
1400
Herramientas CASE para la

gestin de configuracin
Los
procesos CM son estandarizados e

involucran la aplicacin de procedimientos
predefinidos.
Cantidades grandes de datos pueden ser
manejadas.
El soporte de herramientas CASE para el es
por lo tanto esencial.
Las herramientas CASE maduras para apoyar
la gestin de configuracin estn disponibles
fluctuando desde herramientas autosuficientes
hasta bancos de trabajo CM integradas.
12/05/16
1401
Bancos de trabajo CM
Bancos
de trabajo abiertos
Las herramientas de cada estado en el proceso
CM son integradas a travs de procedimientos
organizacionales y guiones. Dan la flexibilidad
en la seleccin de herramientas.
Bancos de trabajo integrados
Proporcionan
procesos
enteros,
soporte
integrado para gestin de configuracin. Ms
herramientas hermticamente
integradas
fciles de usar. Sin embargo, el costo es menos
flexible en las herramientas usadas.
12/05/16
1402
Herramientas de gestin
de cambio
La gestin de cambio es un proceso procedural de modo que
puede ser modelado e integrado con un sistema de gestin de
versin.
Herramientas de gestin de cambio
Editor de formulario para apoyar procesando los formularios
de demanda de cambios;
Sistema de flujo de trabajo para definir quin hace qu y para
automatizar la transferencia de informacin;
Cambian la base de datos que maneja propuestas de cambio
y es ligada para un sistema VM;
Cambian sistemas de reporte que generan informes de
gestin en los estados de demanda de cambio.
12/05/16
1403
Herramientas de gestin
de versin
Identificacin de versin y lanzamiento

Los sistemas asignan identificadores automticamente cuando una
nueva versin es sometida al sistema.
Gestin de almacenamiento
El sistema guarda las diferencias entre versiones en lugar de todo el
cdigo de la versin.
Registro de historia de cambio
Registra las razones para la creacin de versin.
Desarrollo independiente
Slo una versin en un momento puede ser comprobada para el
cambio. Se trabaja paralelamente en diferentes versiones.
Apoyo de proyecto
Puede manejar grupos de archivos asociados con un proyecto en lugar
de simplemente archivos solos.
12/05/16
1404
Versiones basadas en delta

Versin
Versin
1.0
1.0
Versin
Versin
1.1
1.1
DD11
Versin1.3
1.3
Versin
Versin1.2
1.2
Versin
DD22
DD33
Datos de creacin
12/05/16
1405

La
construccin
de
un
sistema
grande
es
computacionalmente cara y puede tomar varias horas.
Cientos de archivos pueden estar involucrados.
Las herramientas que construyen el sistema pueden
proporcionar
Un lenguaje de
especificacin de dependencia e
interprete;
Seleccin de herramienta y apoyo de instanciacin;
Compilacin distribuida;
Gestin de objetos derivada.
12/05/16
1406
Dependencia de
componentes
comp
comp
scan.0
scan.0
scan.0
scan.0
syn.0
syn.0
syn.0
syn.0
sem.0
sem.0
sem.0
sem.0
cgen.0
cgen.0
cgen.0
cgen.0
defs.h
defs.h
12/05/16
1407
Puntos clave
La gestin de configuracin es la gestin de cambios
del sistema para productos del software.
Un esquema de denominacin de documento formal
debe ser establecida y los documentos deben ser
manejados en una base de datos.
La base de datos de configuracin debe registrar la
informacin acerca de los cambios y demandas de
cambios.
Un esquema consistente de identificacin de versin
debe ser establecida usando nmeros, atributos o
conjuntos de cambios .
12/05/16
1408
Puntos clave
Los lanzamientos del sistema incluyen cdigo
ejecutable, datos, archivos de configuracin y
documentacin.
La construccin del sistema involucra componentes
ensamblados dentro del sistema ..
Las herramientas CASE estn disponibles para
apoyar todas las actividades CM
Las herramientas CASE pueden ser herramientas
autosuficientes o pueden ser sistemas integrados que
integran apoyo para la gestin de versin,
construccin del sistema y gestin de cambios.
12/05/16
1409
12/05/16
1410

Ingenieria Software

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ingenieria Software

Caricato da

Copyright:

Formati disponibili

Una introduccin a

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

la ingeniera de software y explicar su

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

sobre la ingeniera del

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Costos del software

costos del software dominan a menudo los

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Preguntas ms frecuentes acerca

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Preguntas ms frecuentes acerca

son los costos de la ingeniera de

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Programas de computadora y documentacin asociada como

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

ingeniera de software es una disciplina

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Cul es la diferencia entre ingeniera

informtica se preocupa por la teora y

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Cul es la diferencia entre ingeniera

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Una representacin simplificada de un proceso del

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Cules son los costos de la

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Ingeniera de software basada en componentes

Desarrollo y evolucin de costos de largo tiempo de vida

Desarrollo del sistema

Evolucin del sistema

Costos de desarrollo del

Prueba del sistema

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Cules son los mtodos de

Los acercamientos estructurados al desarrollo del software que

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Qu es CASE (Competer Aided Software

del software con pensadas para prestar

Herramientas para apoyar las actividades tempranas del

Herramientas para apoyar las actividades tardas tales

Cules son los atributos

El software debe entregar la funcionalidad requerida y desempeo

Cules son los desafos importantes que

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

ingeniera de software involucra las

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Los ingenieros normalmente deben respetar la

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Cdigo ACM/IEEE de tica

Las sociedades profesionales en los EE. UU. han

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Cdigo de tica - principios

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

Cdigo de tica - principios

Cdigo de tica - principios

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera

discordancia entre los principios con las

Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellera