Una introducción a Una introducción a la Ingeniería del la Ingeniería del
softwaresoftwareIan Sommerville
Traducción: Ing.
13/04/23 Ing. 2
Introducción
Capítulo 1
13/04/23 Ing. 3
Objetivos Introducir la ingeniería de software y explicar su
importancia. Partir de las respuestas para plantear preguntas
acerca de ingeniería de software. Introducir los problemas éticos y profesionales y
explicar por qué ellos son de preocupación para los ingenieros del software.
13/04/23 Ing. 4
Temas cubiertos
FAQs sobre la ingeniería del software.
El profesional y la responsabilidad ética.
13/04/23 Ing. 5
Ingeniería de software Las economías de TODAS las naciones
desarrolladas son dependientes en el software. Cada vez más los sistemas son software
controlados. La ingeniería de software se preocupa por las
teorías, métodos y herramientas para el desarrollo del software profesional.
El gasto en el software representa una parte significativa del PNB en todos desarrolló los países.
13/04/23 Ing. 6
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 ingeniería de software se preocupa por el desarrollo del software rentable.
13/04/23 Ing. 7
Preguntas más frecuentes acerca de la ingeniería de software
¿Qué es software? ¿Qué es ingeniería de software? ¿Cuál es la diferencia entre ingeniería de
software e informática? ¿Cuál es la diferencia entre ingeniería de
software y ingeniería de sistemas? ¿Qué es un proceso de software? ¿Qué es un modelo de proceso de software?
13/04/23 8
Preguntas más frecuentes acerca de la ingeniería de software
¿Cuáles son los costos de la ingeniería de software?
¿Cuáles son los métodos de la ingeniería de software?
¿Qué es CASE (Competer Aided Software Engineering = Ingeniería de Software Asistida por Computadora)?
¿Cuáles son los atributos de un buen software? ¿Cuáles son los desafíos importantes que está
enfrentando la ingeniería del software?
13/04/23 9
¿Qué es software? Programas de computadora y documentación asociada como
los requisitos, modelos de diseño 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
Genérico: 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 genéricos o reusando software existente.
13/04/23 10
¿Qué es ingeniería de software?
La ingeniería de software es una disciplina de la ingeniería que se preocupa por todos los aspectos de producción del software.
Los ingenieros del software deben adoptar un acercamiento sistemático y organizado a su trabajo y usar las herramientas y técnicas apropiadas que dependen del problema a ser resuelto, las restricciones de desarrollo y los recursos disponibles.
13/04/23 11
¿Cuál es la diferencia entre ingeniería de software e informática?
La informática se preocupa por la teoría y principios; la ingeniería de software se preocupa por las viabilidades de desarrollar y entregar software útil.
Las teorías de la informática todavía son insuficientes para actuar como un soporte completo para la ingeniería de software (diferente, por ejemplo, en el caso de la física y la ingeniería eléctrica).
13/04/23 12
¿Cuál es la diferencia entre ingeniería de software y ingeniería de sistemas?
La ingeniería de sistemas se preocupa por todos los aspectos de desarrollo de sistemas basados en computadora incluso el hardware, software e ingeniería del proceso. La ingeniería 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 están envueltos en la especificación del sistema, diseño arquitectónico, integración y despliegue.
13/04/23 13
¿Qué es un proceso de software?
Un conjunto de actividades cuya meta es el desarrollo o evolución de software.
Las actividades genéricas en todos los procesos del software son: Especificación: lo que el sistema debe hacer y sus
restricciones de desarrollo. Desarrollo: la producción del sistema de software. Validación: verificación de que el software satisface las
necesidades del cliente. Evolución: cambio del software en respuesta a las
demandas cambiantes.
13/04/23 14
¿Qué es un modelo de proceso de software?
Una representación simplificada de un proceso del software, presentada de una perspectiva específica.
Los ejemplos de perspectivas del proceso son La perspectiva de Flujo de Trabajo: la sucesión de
actividades; La perspectiva de Flujo de Datos: el flujo de
información; La perspectiva de Rol/Acción: quién hace eso.
Los modelos del proceso genéricos Cascada; Desarrollo iterativo; Ingeniería de software basada en componentes.
13/04/23 15
¿Cuáles son los costos de la ingeniería 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 evolución exceden a menudo los costos de desarrollo.
Los costos varían dependiendo del tipo de sistema que se desarrolla y los requerimientos de los atributos del sistema como el desempeño y fiabilidad del sistema.
La distribución de costos depende del modelo de desarrollo que se usa.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 16
Distribución de costos de actividad
Especificación Diseño Desarrollo Integración y pruebas
0 25 50 75 100
Especificación Desarrollo iterativo Prueba del sistema
0 25 50 75 100
Modelo de cascada
Desarrollo iterativo
Especificación Desarrollo Integración y pruebas
0 25 50 75 100
Desarrollo del sistema Evolución del sistema
0 100 200 300 400
Ingeniería de software basada en componentes
Desarrollo y evolución de costos de largo tiempo de vida
13/04/23 17
Costos de desarrollo del producto
Especificación Desarrollo Prueba del sistema
0 25 50 75 100
13/04/23 18
¿Cuáles son los métodos de la ingeniería de software?
Los acercamientos estructurados al desarrollo del software que incluye a modelos del sistema, notaciones, las reglas, consejos de diseño y guía del proceso.
Descripciones del modelos Las descripciones de modelos gráficos que deben
producirse; Reglas
Restricciones aplicadas a modelos del sistema; Recomendaciones
Consejos en una buena práctica de diseño; Guía de proceso
Actividades a llevar a cabo.
13/04/23 19
¿Qué es CASE (Competer Aided Software Engineering = Ingeniería 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 método.
CASE de Alto Nivel Herramientas para apoyar las actividades tempranas
del proceso de de requerimientos y diseño; CASE de Bajo Nivel
Herramientas para apoyar las actividades tardías tales como programación, depuración y pruebas.
13/04/23 20
¿Cuáles son los atributos de un buen software?
El software debe entregar la funcionalidad requerida y desempeño 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 diseñado. Esto significa que debe ser entendible, utilizable y compatible con otros sistemas.
13/04/23 21
¿Cuáles son los desafíos importantes que está enfrentando la ingeniería del software?
La heterogeneidad, entrega y confianza. Heterogeneidad
Desarrollo de técnicas para construir software que puede cubrir con plataformas y ambientes de la ejecución heterogéneas;
Entrega Desarrollo de técnicas que llevan a la entrega más
rápida de software; Confianza
Desarrollo de técnicas que demuestren que el software puede ofrecer confianza a sus usuarios.
13/04/23 22
El profesional y la responsabilidad ética
La ingeniería de software involucra las responsabilidades más amplias que simplemente la aplicación de habilidades técnicas.
Los ingenieros del software deben comportarse en un camino honrado y éticamente y así serán respetados como profesionales.
La conducta ética va más allá de acatar simplemente la ley.
13/04/23 23
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 están fuera de su competencia.
13/04/23 24
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 técnicas para mal emplear las computadoras de otras personas. Los gama de mal uso de computadora va desde las relativamente triviales (jugar en la máquina de un empleador) a las sumamente serias (la diseminación de virus).
13/04/23 25
Código ACM/IEEE de Ética Las sociedades profesionales en los EE. UU. han
cooperado para producir un código de práctica ética. Los miembros de estas organizaciones acatan el
código de práctica ética cuando ellos lo suscriben. El Código contiene ocho Principios relativos a a la
conducta y decisiones hechas por ingenieros de software profesional, incluso practicantes, educadores, gerentes, supervisores y fabricantes de pólizas, así como los aprendices y estudiantes de la profesión.
13/04/23 26
Preámbulo al Código de ética
Preámbulo La versión corta del código resume las aspiraciones a un nivel alto
de abstracción; las cláusulas que son incluidas en la versión completa dan ejemplos y detalles de que cómo estas aspiraciones cambian la manera que actuar de nosotros como profesionales de ingeniería de software. Sin las aspiraciones, los detalles pueden ponerse legalistas y tediosos; sin los detalles, las aspiraciones pueden parecer altos pero vacíos; juntos, las aspiraciones y los detalles forman un código cohesivo.
Los ingenieros de software se comprometerán a hacer del análisis, especificación, diseño, desarrollo, pruebas y mantenimiento de software una beneficiosa y respetada profesión. De acuerdo con su compromiso a la salud, seguridad y bienestar del público, los ingenieros del software adherirán a los siguientes Ocho Principios:
13/04/23 27
Código de ética - principios EL PUBLICO
Los ingenieros del software actuarán de forma consistente con el interés público.
EL CLIENTE Y EL EMPLEADOR Los ingenieros del software actuarán de acuerdo
a los mejores intereses de sus clientes y empleadores consistentes con el interés público.
EL PRODUCTO Los ingenieros del software asegurarán que sus
productos y las modificaciones relacionadas cumplen las normas profesionales más altas posibles.
13/04/23 28
Código de ética - principios EL JUICIO
Los ingenieros del software mantendrán integridad e independencia en su juicio profesional.
LA GESTION La ingeniería software, gerentes y líderes suscribirán
y promoverán un acercamiento ético a la gestión de desarrollo del software y mantenimiento.
LA PROFESION Los ingenieros de software mejorarán la integridad y
reputación de la profesión consistentes con el interés público.
13/04/23 29
Código de ética - principios LOS COLEGAS
Los ingenieros del software serán justos y estarán a favor de sus colegas.
UNO MISMO Los ingenieros del software participarán
aprendiendo de toda la vida con respecto a la práctica de su profesión y promoverán un acercamiento ético a la práctica de la profesión.
13/04/23 30
Dilemas éticos La discordancia entre los principios con las
políticas de mayor dirección. Su empleador actúa de una manera inmoral y
libera un sistema de seguridad crítico sin terminar la comprobación del sistema.
La participación en el desarrollo de sistemas de armas militares o sistemas nucleares.
13/04/23 31
Puntos clave La ingeniería de software es una disciplina de la ingeniería que se
preocupa por todos los aspectos de producción del software. Los productos del software consisten en programas desarrollados y
la documentación asociada. Los atributos del producto esenciales son mantenibilidad, confiabilidad, eficiencia y utilidad.
El proceso del software consiste en actividades que están envueltas en el desarrollo de los productos del software. Las actividades básicas son la especificación del software, desarrollo, validación y evolución.
Los métodos 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 diseño.
13/04/23 32
Puntos clave Las herramientas CASE son sistemas de software que se
diseñan para apoyar las actividades rutinarias en el proceso de software tales como la edición de los diagramas de diseño, verificación 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 profesión de la ingeniería y la sociedad. Ellos simplemente no deben tener relación con los problemas técnicos.
Las sociedades profesionales publican los códigos de conducta que parten de las normas de conducta esperados de sus miembros.
13/04/23 33
Los Sistemas Socio-técnicos
Capítulo 2
13/04/23 34
Objetivos Para explicar lo que es un sistema socio-técnico y la
distinción 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 ingeniería de sistemas y procesos de obtención de sistemas.
Para explicar por qué el contexto organizacional de un sistema afecta su diseño y uso.
Para discutir los sistemas legados y por qué éstos son críticos para muchos negocios.
13/04/23 35
Tópicos cubiertosLas propiedades del sistema
emergentesLa ingeniería de sistemasLas organizaciones, las personas y
sistemas de computadora Los sistemas legados
13/04/23 36
¿Qué es un sistema? Una determinada colección de componentes
interrelacionados que trabajan juntos para lograr algún objetivo común.
Un sistema puede incluir componentes software, mecánico, hardware eléctrico y electrónico 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
13/04/23 37
Categorías de sistemas Los sistemas técnicos basados en computadora
Sistemas que incluyen hardware y software pero dónde 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-técnicos Sistemas que incluyen los sistemas técnicos pero
también los procesos operacionales y las personas que usan y actúan recíprocamente con el sistema técnico. Los sistemas Socio-técnicos son gobernados por políticas organizacionales y reglas.
13/04/23 38
Características de los sistemas Socio-técnicos
Las propiedades emergentes Las propiedades del sistema de un todo que depende
de los componentes del sistema y sus interrelaciones. No determinísticas
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.
13/04/23 39
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.
13/04/23 40
Ejemplos de propiedades emergentes
Propiedades DescripciónVolumen El volumen de un sistema (el espacio total ocupado) varía dependiendo
cómo 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 fácilmente. Puede idearse los ataques que no fueron previstos por los diseñadores y así poder derrotarlos con los resguardos incorporados.
Reparabilidad Esta propiedad refleja cuan fácil es arreglar un problema una vez que el sistema lo ha descubierto. a menor, donde sólo resultan daños 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 fácil es usar un sistema. Depende de los componentes técnicos del sistema, sus operadores y el ambiente donde opera.
13/04/23 41
Tipos de propiedades emergentes
Propiedades funcionales Éstas aparecen cuando todas las partes de un sistema trabajan
juntas para lograr algún 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, desempeño, seguridad y seguridad
física Éstos se relacionan con el comportamiento del sistema en su ambiente operacional. Ellos son a menudo críticos para los sistemas basados en computadora tal como fallas. Ellos son a menudo críticos para los sistemas basados en computadora tal como fallas para lograr algún nivel definido mínimo en estas propiedades que pueden hacer el sistema inutilizable.
13/04/23 42
Debido a los interdependencia de componente, las fallas pueden propagarse a través 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.
Ingeniería de fiabilidad de sistemas
13/04/23 43
Fiabilidad del hardware ¿Cuál es la probabilidad de que un componente del
hardware está fallando y cuánto tiempo toma reparar ese componente?
Fiabilidad del software Cuán 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 ¿Cuán probable es que el operador de un sistema
cometerá un error?
Influencias en fiabililidad
13/04/23 44
Interrelaciones de fiabilidad
Una falla del hardware puede generar signos espurios que están fuera del rango de entradas esperadas por el software.
Los errores del software pueden causar alarmas que al ser activadas causan tensión en el operador y llevar a errores del operador.
El ambiente en el que un sistema se instala puede afectar su fiabilidad.
13/04/23 45
Las propiedades “no debidas”
Las propiedades como el desempeño y la fiabilidad pueden medirse.
Sin embargo, algunas propiedades son propiedades que el sistema no debe exhibir Seguridad física: 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 difícil.
13/04/23 46
Ingeniería de sistemasEspecificando, diseñando, implementando,
validando, desplegando y manteniendo los sistemas socio-técnicos.
Tenido relación con los servicios proporcionados por el sistema, las restricciones en su construcción y funcionamiento y las maneras en las que se usa.
13/04/23 47
Los procesos de la ingeniería de sistemas
Normalmente se sigue el modelo de "cascada" debido a la necesidad del desarrollo paralelo de diferentes partes del sistema. Alcance pequeño para la iteración 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 de diferentes que deben trabajar juntos Mucho alcance por una mal interpretación. Las
diferentes disciplinas usan un vocabulario diferente y se requiere mucha negociación. Los ingenieros pueden tener las agendas personales llenas.
13/04/23 48
Los procesos de la ingeniería de sistemas
Definición de requerimientos
Definición de requerimientos
Diseño del sistemaDiseño del
sistema
Desarrollo del sub - sistemaDesarrollo del sub - sistema
Integración del sistema
Integración del sistema
Instalación del sistema
Instalación del sistema
Evolución del sistema
Evolución del sistema
Retiro del sistema
Retiro del sistema
13/04/23 49
Envolvimiento interdisciplinario
Ingeniería de software
Ingeniería de software
Ingeniería electrónica
Ingeniería electrónica
Ingeniería mecánicaIngeniería mecánica
Ingeniería estructural
Ingeniería estructural
Ingeniería de sistemas ATC
Ingeniería de sistemas ATC
Diseño de interfaz de usuario
Diseño de interfaz de usuario
Ingeniería civil
Ingeniería civil
Ingeniería eléctricaIngeniería eléctrica
Arquitectura
Arquitectura
13/04/23 50
Definición 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 características indeseables: El comportamiento inaceptable del sistema se especifica.
También se debe definir los objetivos organizacionales globales para el sistema.
13/04/23 51
Objetivos del sistema Se deberá definir por qué un sistema está procurándose
para un ambiente particular. Los objetivos funcionales
Mantener un fuego y sistema de alarma de intruso para la construcción el edificio que proporcionará advertencia interior y exterior de fuego o la intrusión no autorizada.
Los objetivos organizacionales Asegurar que el normal funcionamiento de trabajo
llevada a cabo en la construcción no se rompa seriamente por los eventos como el fuego y la intrusión desautorizada.
13/04/23 52
Problemas de los requerimientos del sistema 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 difícil los requerimientos no-funcionales (particularmente) sin saber la estructura de componentes del sistema.
13/04/23 53
El proceso de diseño del sistema
Requerimientos de partición 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 crítica para el desarrollo del sub-sistema paralelo.
13/04/23 54
El proceso de diseño del sistema
Requerimientos de partición
Requerimientos de partición
Identificar sub – sistemas
Identificar sub – sistemas
Asignación de requerimientos a sub - sistemas
Asignación de requerimientos a sub - sistemas
Especificar funcionalidad a sub - sistemas
Especificar funcionalidad a sub - sistemas
Definir interfaces de sub - sistemas
Definir interfaces de sub - sistemas
13/04/23 55
Problemas del diseño de sistemas
Los requerimientos que particionan el hardware, el software y los componentes humanos pueden involucrar mucha negociación.
Los problemas difíciles del diseño 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.
13/04/23 56
Requerimientos y diseños La ingeniería de requerimientos y el diseño de
del sistema se unen indisolublemente. Los requerimientos propuestos por el ambiente
del sistema y otros sistemas limitan las opciones de diseño y así el actual diseño a ser usado puede ser un requerimiento.
El diseño inicial puede ser necesario para estructurar los requerimientos.
Conforme se hace diseño, se aprende más acerca de los requerimientos.
13/04/23 57
Modelo en espiral de requerimientos /diseño
Requerimientos, Elicitación y
Análisis
Requerimientos, Elicitación y
Análisis
Diseño Arquitectónico
Diseño Arquitectónico
Definición del Problema
Definición del Problema
Revisión y ValoraciónRevisión y Valoración
13/04/23 58
Modelamiento del sistemaUn modelo arquitectural presenta vista
abstracta de los sub - sistemas que constituyen un sistema.
Puede incluir los flujos de información mayores entre los sub – sistemas.
Normalmente presentado como un diagrama del bloque.
Puede identificar diferentes tipos de componentes funcionales en el modelo.
13/04/23 59
El sistema de alarma de ladrón
Sensores de movimientoSensores de movimiento
Sensores de puertaSensores de puerta
Controlador de alarma
Controlador de alarma
SirenaSirenaSintetizador
de vozSintetizador
de voz
Llamador de teléfono
Llamador de teléfono
Centro de control externo
13/04/23 60
Descripción de sub - sistemaSub - sistema DescripciónSensores de movimiento
Detecta el movimiento en las salas monitoreadas por el sistema.
Sensores de puerta
Detecta puertas que abre en las puertas externas de la construcción.
Control de alarma
Controla la operación del sistema.
Sirena Emite una advertencia auditiva cuando un intruso es sospechoso.
Sintetizador de voz
Sintetiza un mensaje de voz que da ubicación del intruso sospechoso.
Llamador de teléfono
Hace llamadas para notificar a la seguridad, a la policía, etc.
13/04/23 61
Arquitectura de sistemas ATC
Sistema de radarSistema de radar
Sistema de transponder
Sistema de transponder
Sistema de comandos de datos
Sistema de comandos de datos
C comandos de vueloC comandos de vuelo
Sistema de teléfonoSistema de teléfono
Base de datos del plan de vuelo
Base de datos del plan de vuelo
Sistema de simulación de vuelo
Sistema de simulación de vuelo
Sistema de mapa metereólogico Sistema de mapa
metereólogico
Sistema de conteoSistema de conteo
Sistema de mallas de actividad
Sistema de mallas de actividad
Procesador de posición
Procesador de posición
Procesador de posición de resguardo
Procesador de posición de resguardo
Sistema de control de información
Sistema de control de información
Procesador de comandos
Procesador de comandos
Procesador de comandos de
resguardo
Procesador de comandos de
resguardo
Consolas de controlConsolas de control
13/04/23 62
Desarrollo del sub - sistema
Típicamente 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 comunicación a través de los equipos de implementación.
El mecanismo lento y burocrático para proponer los medios de cambio que la agenda de desarrollo puede extenderse de la necesidad para retrabajar.
13/04/23 63
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.
Integración del sistema
13/04/23 64
Después 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
introducción de un nuevo sistema; El sistema puede coexistir con sistemas
alternativos al mismo tiempo; Puede haber problemas físicos de instalación (e.g.
problemas de cableado); El operador de entrenamiento tiene que ser
identificado.
Instalación del sistema
13/04/23 65
Evolución del sistema Los sistemas grandes tienen largo tiempo de vida. Ellos deben
evolucionar para reunir los cambios de requerimientos. La evolución es inherentemente costosa
Deben analizarse los cambios de una perspectiva técnica y comercial;
Los sub - sistemas interactúan para anticiparse a los problemas que puedan surgir;
Raramente hay una razón para las decisiones de diseño 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.
13/04/23 66
Retiro de sistemas Poniendo el sistema fuera de servicio después
de su tiempo de vida útil. Puede requerir surgimiento de materiales (e.g.
químicos peligrosos) que contaminan el ambiente Deben ser planeadas en el diseño del sistema por
encapsulamiento. Puede requerirse datos para ser reestructurado y
convertido para ser usado en algún otro sistema.
13/04/23 67
Organizaciones/personas/sistemas
Los sistemas socio - técnicos 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.
13/04/23 68
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 hábiles a los usuarios en un
entorno o causa cambios en la forma de trabajar?
Los cambios organizacionales ¿El sistema cambia la estructura de poder
político en un organización?
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 69
Procesos Organizacionales Los procesos de superposición de ingeniería de
sistemas y la interacción con los procesos de procuración organizacional.
Los procesos operacionales son los procesos involucrados en el uso del sistema para el propósito pensado. Para nuevos sistemas, estos tienen que ser definidos como parte del diseño del sistema.
Los procesos operacionales deben ser diseñados 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.
13/04/23 70
Procesos de obtención /desarrollo
Proceso de ObtenciónProceso de Obtención
Proceso de DesarrolloProceso de Desarrollo
Proceso Operacional
Proceso Operacional
13/04/23 71
Obtención del sistema Adquiriendo un sistema para satisfacer alguna necesidad de una
organización. Alguna especificación del sistema y el diseño arquitectónico es
normalmente necesario antes de la obtención Se necesita una especificación para permitir un contrato de
desarrollo del sistema. La especificación puede permitir comprar un sistema comercial
de stock disponible (COTS= Commercial Off The Shelf). Casi siempre más barato que desarrollar el sistema desde el principio.
Los grandes sistemas complejos normalmente consisten en una mezcla de stock disponible y componentes diseñados. Los procesos de obtención para estos diferentes tipos de componentes son normalmente diferentes.
13/04/23 72
El proceso de obtención de sistema
Sistema de disponibilidad en
stock
Lo requerido por el sistema habitual
Estudio de mercado de sistemas existentes
Estudio de mercado de sistemas existentes
Adaptar requerimientos
Adaptar requerimientos
Publicar demanda para la
oferta
Publicar demanda para la
oferta
Elegir sistema
Elegir sistema
Elegir proveedorElegir proveedor
Publicar demanda para vigilante
Publicar demanda para vigilante
Negociar el contrato
Negociar el contrato
Elegir vigilante
Elegir vigilante
Permitir contrato para el desarrollo
Permitir contrato para el desarrollo
13/04/23 73
Emisión de obtenciones Los requerimientos pueden tener que ser
modificados para emparejar las capacidades de los componentes disponibles en stock.
La especificación de requerimientos puede ser parte del contrato para el desarrollo del sistema.
Hay normalmente un periodo de negociación de contrato para estar de acuerdo en los cambios después de que el contratista construye el sistema que ha sido seleccionado.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 74
Contratistas y sub - contratistas
La obtención de sistemas del hardware/software grandes está normalmente basada alrededor de algún 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.
13/04/23 75
Modelos de Contratista/Sub-contratista
Sistema del Cliente
Sistema del Cliente
Contratista PrincipalContratista Principal
Sub Contratista 1
Sub Contratista 1
Sub Contratista 2
Sub Contratista 2
Sub Contratista 3
Sub Contratista 3
13/04/23 76
Sistemas legados Los sistemas socio – tecnológicos que han
desarrollados usando tecnologías viejas u obsoletas. Es crucial para la operación de un negocio y es a
menudo demasiado arriesgado desechar estos sistemas. Sistema de cuenta bancaria de cliente; Sistema de mantenimiento de avión.
Los sistemas legados restringen los nuevos procesos de negocio y consumen una proporción alta de presupuestos de la compañía.
13/04/23 77
Sistemas legados
Software de soporte
Software de soporte
Sistemas de hardwareSistemas de hardware
Software de aplicaciónSoftware de aplicación
Datos de aplicación
Datos de aplicación
Procesos de negocios
Procesos de negocios
Políticas comerciales y
reglas
Políticas comerciales y
reglas
Corre en
Usa Incluye conocimiento de
Corre en Usa Usa Restringen
13/04/23 78
Componentes de sistemas legados
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 aplicación: puede ser escrito en lenguajes
de programación obsoletos. Datos de aplicación: a menudo incompletos e
inconsistentes. Procesos de negocios: pueden ser restringidos por
estructura de software y funcionalidad. Políticas comerciales y reglas: pueden ser implícitas y
incrustadas en el sistema de software.
13/04/23 79
Sistemas socio técnicos
Sistemas socio-técnicos
Procesos de negocios
Software de aplicación
Software de soporte
Hardware
13/04/23 80
Puntos clave Los sistemas socio técnicos incluyen hardware de
computadoras, software y gente y son diseñados para lograr algunas metas comerciales.
Las propiedades emergentes son propiedades que son características del sistema como un todo y no de sus partes componentes.
El proceso de ingeniería de sistemas incluye especificación, diseño, desarrollo, integración y pruebas. La integración del sistema es particularmente crítica.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 81
Puntos clave Factores humanos y organizacionales tienen un efecto
significativo en la operación de sistemas socio – técnicos.
Hay complejas interacciones entre los procesos de obtención del sistema, desarrollo y operación.
Un sistema legado s un viejo sistema que continua para proveer servicios esenciales.
Los sistemas legados incluyen procesos de negocios, software de aplicación, software de soporte y hardware de sistema.
13/04/23 82
Sistemas críticos
Capítulo 3
13/04/23 83
Objetivos Para explicar lo que se entiende por un sistema
crítico dónde una falla del sistema puede tener una consecuencia humana severa o económica.
Para explicar cuatro dimensiones de confiabilidad: disponibilidad, fiabilidad, seguridad (física) y seguridad (contra delitos).
Para explicar que, para lograr la confiabilidad, se necesita evitar los errores, detectar y quitar errores y limitar el daño causados por falla.
13/04/23 84
Temas cubiertosUn sistema simple de seguridad
críticaConfiabilidad de sistemasDisponibilidad y fiabilidadSafety (Seguridad física)Security (Seguridad contra delitos)
13/04/23 85
Sistemas críticos Sistemas de seguridad crítica
Una falla produce pérdida de vida, lesión o daño al ambiente;
Sistema de protección de una planta química; Sistemas de misión crítica
Una falla produce el fracaso de algunas actividades dirigidas a una meta;
Sistema de navegación espacial; Sistemas de negocios críticos
Una falla produce pérdidas económicas altas; Sistema de cuenta de cliente en un banco.
13/04/23 86
Confiabilidad de sistemas Para los sistemas críticos, normalmente el caso
más de propiedad del sistema es la confianza del sistema.
La confiabilidad de un sistema refleja el grado de crédito 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.
13/04/23 87
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 pérdida de información con un costo alto de la consecuente recuperación.
13/04/23 88
Métodos de desarrollo para sistemas críticos
Los costos de falla de un sistema crítico son tan altos que desarrollar los métodos para otros tipos de sistemas no es rentable.
Ejemplos de métodos de desarrollo Métodos formales de desarrollo de software. Análisis estadístico. Seguridad de calidad externa.
13/04/23 89
Sistemas socio - técnicos Falla de hardware
El hardware falla debido a errores en el diseño 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
especificación, diseño o implementación. Falla operacional
Los operadores humanos cometen los errores. Ahora quizás sea la sola más grande causa de fallas del sistema.
13/04/23 90
Una bomba de insulina de software controlada
Usada por los diabéticos para simular la función del páncreas que fabrica la insulina, una hormona esencial que metaboliza la glucosa de sangre.
Las medidas de glucosa de la sangre (el azúcar) usando un micro-sensor y calcular la dosis de insulina exigió metabolizar la glucosa.
13/04/23 91
Organización de la bomba de insulina
Depósito de insulina
Suministro de fuerza
Bomba
Controlador
Reloj
Alarma
Montaje de aguja
Sensor
Visual 1 Visual 2
13/04/23 92
Flujo de datos de la bomba de insulina
Sangre
Parámetros de sangre
Nivel de azúcar en la de
sangre
Corregir insulina
requerida
Comandos de control de
bombaInsulina
Sensor de azúcar en la sangre
Sensor de azúcar en la sangre
Análisis de azúcar en la sangre
Análisis de azúcar en la sangre
Cómputo de requerimientos de
insulina
Cómputo de requerimientos de
insulina
Bomba de insulinaBomba de insulina
Controlador de entrega de insulina
Controlador de entrega de insulina
13/04/23 93
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 azúcar 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.
13/04/23 94
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 física; Seguridad contra delitos.
13/04/23 95
Dimensiones de confiabilidad
ConfiabilidadConfiabilidad
DisponibilidadDisponibilidad FiabilidadFiabilidadSeguridad
físicaSeguridad
físicaSeguridad contra
delitosSeguridad contra
delitos
La habilidad de un sistema para entregar servicios cuando son
requeridos
La habilidad de un sistema para entregar servicios especificados
La habilidad de un sistema para operar
sin fallas catastróficas
La habilidad de un sistema para proteger intrusiones contra el
sistema accidentales o deliberadas
13/04/23 96
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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 97
Mantenibilidad Un atributo del sistema que se preocupa por la
facilidad de reparar el sistema después de que una falla se ha descubierto o por cambio del sistema para incluir los nuevos rasgos.
Muy importante para los sistemas críticos 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 estático y no un atributo dinámico del sistema . Yo no lo cubro en este curso.
13/04/23 98
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 noción de elasticidad: la habilidad de un sistema para continuar en operación a pesar de las fallas de componentes.
13/04/23 99
Confiabilidad vs. desempeño Los sistemas poco fiables pueden ser rechazados por
sus usuarios. Los costos de falla de sistemas pueden ser muy altos. Es muy difícil de poner a punto los sistemas para
hacerlos más fidedignos. Puede ser posible para compensar el desempeño
pobre. Los sistemas poco fiables pueden causar pérdida de
información valiosa.
13/04/23 100
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 técnicas de desarrollo caras y
hardware que se exigen lograr los niveles más altos de confiabilidad.
Las crecientes pruebas y sistemas de validación que se exigen para convencer al cliente del sistema, que se han logrado los niveles requeridos de confiabilidad.
13/04/23 101
Costos de confiabilidad creciente
Costos crecientes de confiablidad
0100200300400500600
Baja Media Alta Muy alta UltraaltaConfiabilidad
Cost
os Costos
13/04/23 102
Economía de la confiabilidad
Debido a los costos muy altos para lograr la confiabilidad, puede costearse más eficazmente aceptando los sistemas poco fiables y pagar por los costos de fallas.
Sin embargo, esto depende de los factores sociales y políticos. Una reputación 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.
13/04/23 103
Disponibilidad y fiabilidad Fiabilidad
La probabilidad de operación del sistema libre de falla durante un tiempo específico, en un ambiente dado, para un propósito 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.
13/04/23 104
Disponibilidad y fiabilidad 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 rápidamente y no dañen los datos, la fiabilidad baja no debe ser un problema.
La disponibilidad tiene en cuenta tiempo de la reparación.
13/04/23 105
Terminología de fiabilidadFalla del sistema Un evento que ocurre en algún punto del
tiempo cuando el sistema no entrega un servicio como esperaban a los usuarios.
Error del sistema Un estado erróneo del sistema que puede llevar al comportamiento del sistema inesperado por los usuarios.
Defecto del sistema
Una característica del software del sistema, que puede llevar a un error del sistema. Por ejemplo, una falla de inicialización de una variable puede llevar a que la variable tenga valor errado cuando es usado.
Error humano o equivocación
Comportamiento humano que resulta de la introducción de errores dentro de un sistema.
13/04/23 106
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 detección del error empotrado y recuperación.
Contra las fallas puede protegerse por medio de protecciones empotradas. Por ejemplo, éstas pueden proteger los recursos del sistema de los errores del sistema.
13/04/23 107
Percepciones de confiabilidad La definición formal de fiabilidad no siempre refleja la percepción del
usuario de la fiabilidad de un sistema. Las asunciones que se hacen sobre el ambiente dónde 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 percepción de fiabilidad.
Los limpiadores del parabrisas inestables en un automóvil pueden ser no pertinentes en un clima seco.
Las fallas que tienen consecuencias serias (como una avería de una pieza en un automóvil) tienen mayor peso por usuarios que fallas que son inoportunas.
13/04/23 108
El logro de la fiabilidad La anulación de falla
La técnica de desarrollo se usa para minimizar la posibilidad de errores o atrapar errores antes de que ellos produzcan la introducción de faltas en el sistema.
El descubrimiento de la falla y retiro Las técnicas de verificación y validación 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 técnicas de tiempo de ejecución 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.
13/04/23 109
Modelando fiabilidad Se puede modelar un sistema como una traza de
entrada-salida donde algunas entradas producirán salidas erróneas.
La fiabilidad del sistema es la probabilidad de que una entrada colocada en el juego de entradas causen salidas erróneas.
Diferentes personas se usarán en el sistema de maneras diferentes de modo que esta probabilidad no es un atributo del sistema estático, pero depende del ambiente del sistema.
13/04/23 110
Modelando fiabilidad Se puede modelar un sistema como una traza de
entrada-salida donde algunas entradas producirán salidas erróneas.
La fiabilidad del sistema es la probabilidad de que una entrada colocada en el juego de entradas causen salidas erróneas.
Diferentes personas se usarán en el sistema de maneras diferentes de modo que esta probabilidad no es un atributo del sistema estático, pero depende del ambiente del sistema.
13/04/23 111
Traza de entrada/salida
ProgramaPrograma
Conjunto de entradas Ie
Oe
Conjunto de salidas
Entradas que causan salidas
erróneas
Salidas erróneas
13/04/23 112
Percepción de confiabilidad
Posibles entradas
Usuario
2
Usuario
2
Usuario 1Usuario 1 Entradas erróneas
Usuario
3
Usuario
3
13/04/23 113
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 código, 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 todavía como fiable por sus usuarios.
13/04/23 114
Seguridad física La seguridad física es una propiedad de un sistema que
refleja la habilidad del sistema de operar, normalmente o anormalmente, sin peligro de causar lesión humana o muerte y sin daño al ambiente del sistema.
Es de creciente importancia considerar las seguridades físicas del software, porque cada vez más se incorporan dispositivos de sistemas de control basados en software.
Los requerimientos de seguridad física son requerimientos exclusivos, es decir, ellos excluyen las situaciones indeseables, en lugar de especificar los servicios requeridos del sistema.
13/04/23 115
Los sistema de seguridad física crítica primarios Sistemas del software empotrados cuya falla puede
causar falla en el hardware asociado y amenazar directamente a las personas.
Los sistema de seguridad física crítica primarios Sistemas cuya falla produce las faltas en otros
sistemas que pueden amenazar a las personas. Aquí la discusión de los enfoques en los sistemas de
seguridad física crítica primarios Los sistemas de seguridad física crítica secundarios
sólo pueden ser considerados base de intento único.
Criticalidad de la seguridad física
13/04/23 116
La seguridad física y fiabilidad están relacionadas pero son distintas En general, la fiabilidad y disponibilidad son necesarias
pero no son condiciones suficientes para la seguridad física del sistema.
La fiabilidad se preocupa por la conformidad a una especificación dada y entrega de servicio.
La seguridad física se preocupa por asegurar que el sistema no puede causar daño, independientemente de que está o no conforme a su especificación.
Seguridad física y fiabilidad
13/04/23 117
Errores de especificación Si la especificación del sistema es incorrecta,
entonces el sistema puede comportarse como especificado pero todavía causa un accidente.
Fallas del hardware que generan entradas espurias Duro para anticiparse en la especificación.
Comandos de contexto sensibles, es decir, emitiendo el comando correcto en un mal momento. A menudo el resultado de error del operador.
Los sistemas fiables no seguros físicamente
13/04/23 118
Terminología de seguridad física
Término Definición
Accidente (contratiempo)
Un evento no planificado o sucesión de eventos que resulta en muerte humana o lesión, daño a la propiedad o ambiente. Una máquina controlada por computadora que daña a su operador es un ejemplo de accidente.
Azar Una condición potencial para causar un accidente o contribuir en él. Una falla del sensor que descubre un obstáculo delante de una máquina es un ejemplo de azar.
Daño Una medida de la pérdida que resulta un contratiempo. El daño puede recorrer de muchas personas muertas como resultado de un accidente a lesiones menores o daños de propiedad.
Severidad de riesgo
Una valoración del peor daño posible que podría ser el resultado de un particular azar. La severidad del azar puede ir desde catastrófico, donde muchas personas mueren; a menor, donde sólo resultan daños 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 inverosímil (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.
13/04/23 119
El logro de la seguridad física
Anulación del azar El sistema se diseña para que algunas clases de azar
simplemente no puedan surgir. Detección y retiro del azar
El sistema se diseña para que se descubran los azares y retirarlos antes de que ellos produzcan un accidente.
Limitación del daño El sistema incluye los rasgos de protecciones que
minimizan el daño que puede ser el resultado de un accidente.
13/04/23 120
Accidentes normales Los accidentes en los sistemas complejos raramente
tienen una sola causa, dado que estos sistemas se diseñan para ser elásticos ante un solo punto de falla. Diseñando sistemas para que un solo punto de falla
no cause un accidente, es un principio fundamental de diseño de sistemas garantizados.
Casi todos accidentes son un resultado de combinaciones de funcionamientos defectuosos.
Es probable el caso que anticipándose a todo las combinaciones del problema, sobre todo, en sistemas de software controlado, logrando así la seguridad física completa, es imposible.
13/04/23 121
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á poniéndose en crecimiento importante, tal como los sistemas que se conectan a una red de computadoras para que el acceso externo al sistema a través de Internet, sea posible.
La seguridad es un pre -requisito esencial para la disponibilidad, fiabilidad y seguridad.
13/04/23 122
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 física son inestables.
Estas declaraciones dependen del sistema en ejecución y del sistema desarrollado que es el mismo. Sin embargo, la intrusión puede cambiar el sistema en ejecución y/o sus datos.
Por consiguiente, la fiabilidad y la convicción de seguridad física no son válidas por tiempo prolongado.
13/04/23 123
Terminología de seguridad contra delitos
Término DefiniciónExposición Posible pérdida o daño en un sistema de computación. Ésta
puede ser pérdida o daño a los datos o puede ser pérdida de tiempo y esfuerzo si la recuperación es necesaria después de una brecha de seguridad.
Vulnerabilidad Una debilidad en un sistema basado en computadora que puede explotar para causar pérdida o daño.
Ataque Una explotación de una vulnerabilidad del sistema. Generalmente, esto está fuera del sistema y es un esfuerzo deliberado por causar algún daño.
Amenazas Circunstancias que tienen el potencial para causar pérdida o daño. Se puede pensar en éstos como una vulnerabilidad del sistema que está sujeto a un ataque.
Control Una medida de protección que reduce una vulnerabilidad del sistema. La encriptación sería un ejemplo de un control que reduce una vulnerabilidad de sistemas de control de acceso débiles.
13/04/23 124
El daño de la inseguridad Rechazo de servicio
El sistema es forzado a un estado dónde los servicios normales son indisponibles o donde la provisión de servicio se degrada significativamente.
Corrupción de programas o datos Pueden modificarse los programas o datos en el sistema
de una manera desautorizada. El descubrimiento de información confidencial
La información que es manejada por el sistema puede ser expuesta a las personas que no están autorizadas para leer o usar esa información.
13/04/23 125
Convicción de seguridad Anulación de vulnerabilidad
El sistema se diseña para que las vulnerabilidades no ocurran. Por ejemplo, si no hay ninguna conexión externa de la red, entonces que el ataque externo es imposible.
Descubrimiento y eliminación de ataque El sistema se diseña para que se descubran ataques en las
vulnerabilidades y neutralizarlos, antes de que ellos produzcan una exposición. Por ejemplo, los comprobadores del virus encuentran y quitan los virus antes de que ellos infecten un sistema.
Limitación de exposición El sistema se diseña para que se minimicen las consecuencias
adversas de un ataque exitoso. Por ejemplo, una política auxiliar permite restaurar la información dañada.
13/04/23 126
Puntos críticos Un sistema crítico es un sistema dónde una falla puede llevar
a una alta pérdida económica, daño físico 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 entregarán los servicios especificados del sistema.
La fiabilidad y disponibilidad son generalmente vistos como condiciones necesarias pero no suficientes para la seguridad física y la seguridad contra delitos.
13/04/23 127
Puntos críticos 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 física 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 aproximación socio-técnica para diseñar, donde se considera a los humanos, así como el hardware y software.
13/04/23 128
Procesos de software
Capítulo 4
13/04/23 129
Objetivos Introducir modelos del proceso de software Describir tres modelos de procesos genéricos y
cuando ellos pueden ser usados Describir el contorno de los modelos de procesos
para la ingeniería de requerimientos, desarrollo de software, pruebas y evolución
Explicar el modelo Proceso Unificado Rational introducir tecnología CASE para actividades del
proceso de software de soporte
13/04/23 130
Tópicos cubiertosModelos del proceso de SoftwareIteración del procesoActividades del procesoEl Proceso Unificado Rational Ingeniería de software auxiliado por
computadora
13/04/23 131
El proceso del software Un conjunto de actividades estructuradas
requeridas para el desarrollo de un sistema de software: Diseño; Validación; Evolución.
Un modelo del proceso de software es una representación abstracta de un proceso. Representa una descripción de un proceso desde alguna perspectiva particular.
13/04/23 132
Modelos del proceso de software genérico
El modelo de cascada Separa y distingue fases de especificación y desarrollo.
Desarrollo evolutivo Especificación, desarrollo y validación están
entrelazados. Ingeniería 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 especificación es una especificación formal que es refinada a través de varios estados para un diseño implementable.
13/04/23 133
Modelo de cascadaDefinición de
requerimientos Definición de
requerimientos
Diseño de sistema y software
Diseño de sistema y software
Implementación y pruebas de unidad
Implementación y pruebas de unidad
Integración y pruebas de sistema
Integración y pruebas de sistema
Operación y mantenimiento
Operación y mantenimiento
13/04/23 134
Fases del modelo de cascada
Análisis y definición de requerimientos Diseño del sistema y software Implementación y pruebas de unidad Integración y pruebas de sistema Operación y mantenimiento El inconveniente principal del modelo de la cascada es
la dificultad de adaptación al cambio después de que el proceso está en marcha. Una fase tiene que estar completa antes de pasar hacia la próxima fase.
13/04/23 135
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 sólo es apropiado cuando los requisitos se entienden bien y los cambios se limitarán justamente durante el proceso de diseño.
Pocos sistemas comerciales tienen los requisitos estables.
El modelo de la cascada es principalmente usado para grandes proyectos de ingeniería de sistemas, dónde un sistema se desarrolla en varios sitios.
13/04/23 136
Desarrollo evolutivo El desarrollo exploratorio
El objetivo es trabajar con clientes y desarrollar un sistema final desde una especificación inicial del entorno. Se debe empezar con los requerimientos bien entendidos y se debe agregar los nuevos rasgos propuestos por el cliente.
El 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.
13/04/23 137
Desarrollo evolutivoActividades
concurrentes
Descripción del entornoDescripción del entorno
EspecificaciónEspecificación
DesarrolloDesarrollo
ValidaciónValidación
Versión inicialVersión inicial
Versión intermedia
Versión intermedia
Versión finalVersión final
13/04/23 138
Desarrollo evolutivo Problemas
Falta de visibilidad del proceso; A menudo se estructuran pobremente los sistemas; Pueden requerirse habilidades especiales (por
ejemplo, en lenguajes para el prototipado rápido). Aplicabilidad
Para sistemas interactivos pequeños o medianos; Para partes de sistemas grandes (por ejemplo la
interfaz del usuario); Para sistemas de vida corta.
13/04/23 139
Ingeniería de software basada en componentes
Basado en el reuso sistemático donde los sistemas se integran a partir de componentes existentes o sistemas COTS (Stock comercial disponible).
Fases del proceso Análisis de componentes; Modificación de requerimientos; Diseño de sistemas con reuso; Desarrollo e integración.
Esta aproximación es usada cada vez más conforme van surgiendo estándares de componentes.
13/04/23 140
Desarrollo orientado al reuso
Especificación de requerimientosEspecificación de
requerimientos
Análisis de componentes
Análisis de componentes
Modificación de requerimientosModificación de requerimientos
Diseño de sistemas con reuso
Diseño de sistemas con reuso
Modificación de requerimientosModificación de requerimientos
Diseño de sistemas con reuso
Diseño de sistemas con reuso
13/04/23 141
Iteración del proceso Los requisitos del sistema SIEMPRE evolucionan en el
curso de un proyecto de modo que la iteración del proceso en las fases más tempranas son retrabajadas siempre que sean parte del proceso para sistemas grandes.
La iteración puede aplicarse a cualquiera de los modelos del proceso genérico.
Dos (relacionadas) aproximaciones Entrega Incremental; Desarrollo en espiral.
13/04/23 142
Entrega incremental En lugar de entrega del sistema en una sola
entrega, el desarrollo y la entrega están fracturados bajo incrementos, con cada incremento que entrega parte de la funcionalidad requerida.
Los requerimientos del usuario se priorizan y los requerimientos de prioridad más 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 más tardios pueden continuar evolucionando.
13/04/23 143
Desarrollo incremental
Definir requerimientos del entorno
Definir requerimientos del entorno
Asignar requerimientos al incremento
Asignar requerimientos al incremento
Diseñar arquitectura del sistema
Diseñar arquitectura del sistema
Desarrollar incremento del sistema
Desarrollar incremento del sistema
Integrar incremento
Integrar incremento
Validar sistema
Validar sistema
Validar incremento
Validar incremento
Sistema finalSistema incompleto
13/04/23 144
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 más tardíos.
El más bajo riesgo de falla del proyecto global. Los servicios de sistema de prioridad más altos
tienden a recibir la mayoría de pruebas.
13/04/23 145
Programación extremaUna aproximación para el desarrollo
basado en el desarrollo y entrega de incrementos muy pequeños de funcionalidad.
Confía en la mejora constante del código, la integración del usuario en el equipo de desarrollo y programación por pares.
Cubierto en el Capítulo 17.
13/04/23 146
Desarrollo en espiral El proceso se representa como una escalera de
caracol, en lugar de una sucesión de actividades con retroceso.
Cada vuelta en la escalera de caracol representa una fase en el proceso.
Ninguna fase es fija como especificación o ciclos de diseño en la escalera de caracol son escogidos dependiendo en cual son requeridos.
Los riesgos son evaluados explícitamente y se resuelven a lo largo del proceso.
13/04/23 147
Modelo de espiral del proceso de software
Determinar objetivos, alternativas y restricciones
Evaluar alternativas, identificar y resolver
riesgos
Desarrollo y verificación del próximo nivel del
producto
Planificar próxima fase
REVISION
Análisis de riesgo
Análisis de riesgo
Análisis de riesgo
Análisis de riesgo
Pro totipo 1
Pro totipo 2
Pro totipo 3
Pro totipo operacional
Simulaciones, modelos y referenciasPlan de requerimientos Plan
de ciclo de vida
Plan de desarrollo
Integración y plan de pruebas
Concepto de operación
Validación de requerimientos
Diseño V & V
Servicio
Prueba de aceptación
Prueba de aceptación
Prueba de unidad
Código
Diseño detallado
Producto de diseño
Requerimientos de software
13/04/23 148
Sectores del modelo en espiral
Poner objetivos Objetivos específicos para la fase son identificados.
Evaluación de riesgos y reducción Los riesgos son evaluados y las actividades son puestos
en su lugar para reducir los riesgos clave. Desarrollo y validación
Un modelo de desarrollo para un sistema es elegido y puede ser cualquiera de los modelos genéricos.
Planificación El proyecto es revisado en la próxima fase y la escalera
en espiral es planificada.
13/04/23 149
Actividades del procesoEspecificación del softwareDiseño e implementación del software Validación de softwareEvolución del software
13/04/23 150
Especificación del software
El proceso de establecer que servicios son requeridos y las restricciones en la operación y desarrollo del sistema.
Proceso de ingeniería de requerimientos Estudio de factibilidad; Elicitación (obtención) de requerimientos; Especificación de requerimientos; Validación de requerimientos.
13/04/23 151
El proceso de ingeniería de requerimientos
Estudio de factibilidadEstudio de factibilidad
Elicitación de requerimientos y
análisis
Elicitación de requerimientos y
análisis Especificación de
requerimientosEspecificación de
requerimientosValidación de
requerimientosValidación de
requerimientosInforme de factibilidadInforme de factibilidad
Modelos del sistema
Modelos del sistema Requerimientos
del usuario y del sistema
Requerimientos del usuario y del
sistema
Documentos de requerimientosDocumentos de requerimientos
13/04/23 152
Diseño e implementación del software
El proceso de conversión de la especificación del sistema en sistema ejecutable.
Diseño del software Diseñar una estructura de software que realice la
especificación. Implementación
Transformar la estructura en un programa ejecutable. Las actividades de diseño e implementación están
estrechamente relacionados y pueden ser inter - dejados
13/04/23 153
Actividades del proceso de diseño
Diseño arquitectónicoEspecificación abstractaDiseño de la interfazDiseño de componentesDiseño de estructuras de datosDiseño de algoritmos
13/04/23 154
Proceso de diseño de software
Especificación de requerimientosEspecificación de
requerimientos Actividades de diseño
Diseño arquitectónico
Diseño arquitectónico
Especificación abstracta
Especificación abstracta
Diseño de la interfazDiseño de la interfaz
Diseño de componentes
Diseño de componentes
Diseño de estructura de datos
Diseño de estructura de datos
Diseño de algoritmos
Diseño de algoritmos
Productos de diseño
Arquitectura del sistemaArquitectura del sistema
Especificación del softwareEspecificación
del software
Especificación de la interfazEspecificación de la interfaz
Especificación de componentes
Especificación de componentes
Especificación de estructura de datos
Especificación de estructura de datos
Especificación de algoritmosEspecificación de algoritmos
13/04/23 155
Métodos estructurados Aproximaciones sistemáticas al diseño de software. El diseño es normalmente documentado como un
conjunto de modelos gráficos. Modelos posibles
Modelo de objeto; Modelo secuencial; Modelo de transición; Modelo estructural; Modelo de flujo de datos.
13/04/23 156
Programando y depurando Traduciendo un diseño en un programa y
quitando los errores de ese programa. Programar es una actividad personal - no hay
ningún proceso genérico de programación. 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 depuración.
13/04/23 157
El proceso de depuración
Error localError localReparar error
de diseñoReparar error
de diseñoReparar error Reparar error
Programa de re - pruebaPrograma de
re - prueba
13/04/23 158
Validación del software La verificación y validación (V & V) están
pensados para mostrar que un sistema está conforme a su especificación y reúne los requisitos del cliente del sistema.
Involucra comprobación y revisión de procesos y pruebas del sistema.
La prueba del sistema involucra la ejecución del sistema con casos de prueba, que se derivan de la especificación de los datos reales a ser procesados por el sistema.
13/04/23 159
El proceso de prueba
Prueba de componentes
Prueba de componentes
Prueba de aceptaciónPrueba de aceptación
Prueba del sistema
Prueba del sistema
13/04/23 160
Fases de prueba 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 aceptación Prueba con los datos del cliente para verificar que
el sistema satisface las necesidades del cliente.
13/04/23 161
Fases de prueba
Especificación de requerimientosEspecificación de
requerimientos
Especificación del sistemaEspecificación
del sistema
Diseño del sistemaDiseño del
sistema
Diseño detalladoDiseño detallado
Código de módulo y unidad
y pruebas
Código de módulo y unidad
y pruebas
ServicioServicioPrueba de aceptación
Prueba de aceptación
Prueba de integración del
sistema
Prueba de integración del
sistema
Prueba de integración de Sub - sistema
Prueba de integración de Sub - sistema
Plan de prueba de aceptaciónPlan de prueba de aceptación
Plan de prueba de integración del
sistema
Plan de prueba de integración del
sistema
Plan de prueba de integración del
sub - -sistema
Plan de prueba de integración del
sub - -sistema
13/04/23 162
Evolución del software El software es inherentemente flexible y puede
cambiar. Cuando los requisitos cambian a través de las
circunstancias comerciales cambiantes, el software que apoya el negocio también debe evolucionar y debe cambiar.
Aunque ha habido una demarcación entre el desarrollo y evolución (mantenimiento), esto es cada vez más irrelevante, puesto que menos y menos sistemas son completamente nuevos.
13/04/23 163
Evolución del sistema
Definición de requerimientos
del sistema
Definición de requerimientos
del sistema
Evaluación de sistemas existentes
Evaluación de sistemas existentes
Proponer cambios del
sistema
Proponer cambios del
sistema
Modificar el
sistema
Modificar el
sistema
Sistema existente
Sistema existente
Nuevo sistemaNuevo sistema
13/04/23 164
El Proceso Unificado Rational
Un modelo de proceso moderno derivado del trabajo del proceso asociado en UML.
Normalmente descrito desde 3 perspectivas Una perspectiva dinámica que muestra las fases
sobre el tiempo; Una perspectiva dinámica que muestra las actividades
del proceso; Una perspectiva práctica que sugiere la buena
práctica.
13/04/23 165
Modelo de fase RUP
Comienzo Elaboración Construcción Transición
Fase de integración
13/04/23 166
Fases de RUP Comienzo
Establece el caso comercial para el sistema. Elaboración
Desarrolla una comprensión del dominio del problema y la arquitectura del sistema.
Construcción Diseño del sistema, programación y pruebas.
Transición Despliegue del sistema en el ambiente que opera.
13/04/23 167
Buena práctica en RUP Desarrollo de la iteración del software Manejo de requerimientosUso de arquitecturas basadas en
componentesVisualización del modelo de softwareVerificar la calidad del softwareControl de cambios del software
13/04/23 168
Flujos de trabajo estáticoFlujos de trabajo Definición
Modelamiento del negocio El proceso y modelamiento del sistema usando casos de uso del negocio.
Requerimientos Actores que interactúan con el sistema son identificados y los casos de uso son usados para modelar los requerimientos del sistema.
Análisis y diseño Un modelo de diseño es creado y documentado usando modelos de arquitectura, modelos de componentes, modelos de objetos y modelos de secuencia.
Implementación Los componentes en el sistemas son implementados y estructurados dentro de los sub – sistemas de implementación. La generación automática de código desde modelos de diseño ayuda a acelerar el proceso.
Prueba Las pruebas son un proceso iterativo que es llevado a cabo en conjunción con implementación. Las pruebas del sistema siguen el completamiento de la implementación.
Despliegue Una descarga del producto es creado, distribuido para usar e instalar en su lugar de trabajo.
Manejo de configuración 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 Capítulo 29).
El ambiente Este flujo de trabajo concierne al uso apropiado de herramientas de software disponibles en el equipo de desarrollo del software
13/04/23 169
Ingeniería de software auxiliado por computadora
CASE (Computer-aided software engineering) es software para soportar el desarrollo del software y procesos de evolución.
Actividades de automatización Editores gráficos para desarrollo de modelos de
sistema; Diccionario de datos para manejar entidades de diseño; GUI (Interfaz Gráfica de Usuario) para construcción de
la interfaz de usuario; Depuraciones para apoyar el hallazgo de fallas de
programa; Los traductores automatizados para generar nuevas
versiones de un programa.
13/04/23 170
Tecnología Case La tecnología 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 ingeniería de software requiere el
pensamiento creativo - esto no se automatiza automáticamente;
La ingeniería de software es una actividad del equipo y, para los proyectos grandes, mucho tiempo se consume en las interacciones del equipo. La tecnología CASE realmente no apoya esto.
13/04/23 171
Clasificación de CASE La clasificación nos ayuda a entender los tipos diferentes
de herramientas CASE y su apoyo para las actividades del proceso.
Perspectiva funcional Las herramientas son clasificadas según su función
específica. Perspectiva de proceso
Las herramientas son clasificadas según actividades del proceso que apoyan.
Perspectiva de integración Las herramientas son clasificadas según su
organización dentro de unidades integradas.
13/04/23 172
Clasificación de herramientas funcionales
Tipo de herramienta Ejemplo
Planificación Herramientas PERT, herramientas de estimación, hojas de cálculo.
Edición Editores de texto, editores gráficos, procesadores de palabras.
Cambio de gestión Herramientas de trazabilidad de requerimientos, sistemas de control de cambios.
Gestión de configuración
Sistemas de gestión de versiones, herramientas de construcción de sistemas.
Prototipado Lenguajes de alto nivel, generadores de interfaz de usuario.
Soporte de modelos Editores de diseño, diccionario de datos, generadores de código.
Lenguaje de procesos Compiladores, intérpretes.
Análisis de programa Generadores de referencia cruzada, analizadores estáticos, analizadores dinámicos.
Pruebas Generadores de datos de prueba, comparadores de archivos.
Depuración Sistemas de depuración interactivos.
Documentación Programas de configuración de página, editores de imagen.
Reingeniería Sistemas de referencia cruzada, sistemas de reestructuración de programas.
13/04/23 173
Clasificación de herramientas basadas en actividades
Herramientas de reingeniería
Herramientas de prueba
Herramientas de depuración
Herramientas de análisis de programas
Herramientas de lenguaje de procesos
Herramientas de soporte de métodos
Herramientas de prototipado
Herramientas de gestión de configuración
Herramientas de gestión de cambios
Herramientas de documentación
Herramientas de edición
Herramientas de planificación
Especificación Diseño Implementación Verificación y validación
13/04/23 174
Integración CASE Herramientas
Soporte a tareas del proceso individuales como el diseño de verificación de consistencia, edición de texto, etc.,
Bancos de trabajo Soporte a fases de procesos tales como especificación o
diseño. 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.
13/04/23 175
Herramientas, bancos de trabajo, ambientes
Tecnología CASE
Tecnología CASE
CompiladoresCompiladores Ambientes de procesos centrados
Ambientes de procesos centrados
Ambientes integradosAmbientes integrados
Bancos de trabajo
Bancos de trabajo
EditoresEditores Comparadores de archivo
Comparadores de archivo
HerramientasHerramientas AmbientesAmbientes
PruebasPruebas
Bancos de trabajo unimodelo
Bancos de trabajo unimodelo
Bancos de trabajo Multi - métodosBancos de trabajo
Multi - métodos
Análisis y DiseñoAnálisis y
Diseño
Bancos de trabajo de propósito general
Bancos de trabajo de propósito general
Bancos de trabajo de lenguajes específicosBancos de trabajo de lenguajes específicos
ProgramaciónProgramación
13/04/23 176
Puntos clave Los procesos del software son las actividades
involucradas en la producción y desenvolvimiento de un sistema del software.
Los modelos de proceso de software son representaciones abstractas de estos procesos.
Las actividades generales son especificación, diseño e implementación, validación y evolución.
Los modelos del proceso genéricos describen la organización de procesos de software. Los ejemplos incluyen el modelo de cascada, desarrollo evolutivo, y la ingeniería del software basada en componentes.
Los modelos del proceso iterativos describen el proceso del software como un ciclo de actividades.
13/04/23 177
Puntos clave La ingeniería de requerimientos es el proceso de
desarrollar una especificación del software. El proceso de diseño e implementación transforman la
especificación en un programa ejecutable. La validación involucra comprobación que el sistema se
encuentra de acuerdo a su especificación y necesidades del usuario.
La evolución se preocupa por modificar el sistema después de que está en el uso.
El Proceso Unificado Rational es un modelo de proceso genérico que separa las actividades de las fases.
La tecnología CASE da soporte a las actividades de proceso de software.
13/04/23 178
Gestión de Proyectos
Capítulo 5
13/04/23 179
Objetivos Explicar las tareas principales emprendidas por
gerentes del proyecto. Introducir la de gestión del proyecto de software y
describir sus características distintivas. Discutir la planificación del proyecto y el proceso de la
planificación. Mostrar cómo las representaciones del horario gráficas
son usadas por la gestión del proyecto. Discutir la noción de riesgos y el proceso de dirección
de riesgo.
13/04/23 180
Tópicos cubiertosActividades de gestiónPlanificación del proyectoProgramación del proyectoGestión de riesgos
13/04/23 181
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 gestión del proyecto se necesita porque el desarrollo del software siempre está sujeto al presupuesto y restricciones del horario que son fijadas por la organización que desarrolla el software.
Gestión del proyecto de software
13/04/23 182
El producto es intangible.El producto es singularmente flexible.La ingeniería de software se reconoce como una
disciplina de ingeniería con el estado sensato como la ingeniería mecánica, eléctrica, etc.,
El proceso de desarrollo de software no está estandarizado
Muchos proyectos de software son intentos únicos de proyectos.
Distinciones en la gestión del software
13/04/23 183
Escritura de la propuesta.Planificación y programación del proyecto.Cálculo de costos del proyecto.Monitoreo del proyecto y revisiones.Selección y evaluación del personal.Escritura del informe y presentaciones.
Actividades de gestión
13/04/23 184
Estas actividades no son peculiares a la gestión del software.
Muchas técnicas de gestión de ingeniería de proyectos son igualmente aplicables a la dirección de proyectos de software.
Técnicamente los sistemas de la ingeniería complejos tienden a padecer los mismos problemas de los sistemas del software.
Comunidad de gestión
13/04/23 185
Provisión 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 organización 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.
13/04/23 186
Planificación del proyecto Probablemente la actividad de gestión de proyecto
de mayor consumo de tiempo. La actividad continua desde el concepto inicial a
través de a la entrega del sistema. Los planes deben revisarse regularmente como la nueva información 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.
13/04/23 187
Tipos de planes de proyectoPlan Descripción
Plan de calidad Describe los procedimientos de calidad y estándares que serán usados en un proyecto. Ver Capítulo 27.
Plan de validación Describe la aproximación, recursos y programa usadas para validar un sistema. Ver Capítulo 22.
Plan de gestión de configuración
Describe los procedimientos de gestión de configuración y estructuras a ser usadas. Ver Capítulo 29.
Plan de mantenimiento
Predice los requerimientos de mantenimiento de los sistemas, costos de mantenimiento, y el esfuerzo requerido. Ver Capítulo 21.
Plan de desarrollo de personal
Describe cómo las habilidades y experiencia de los miembros de equipos de proyecto serán desarrolladas. Ver Capítulo 25.
13/04/23 188
Procesos de planificación de proyectos
Establecer restricciones del proyecto
Hacer valoraciones iniciales de los parámetros 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)
Revisión del progreso del proyecto
Revisar estimaciones de parámetros del proyecto
Actualizar el programa del proyecto
Renegociar las restricciones y las entregas
Si (problemas surgen) entonces
Iniciar repaso técnico y posible revisión
Fin de Si
Fin de ciclo
13/04/23 189
El plan del proyectoEmpezar el plan del proyecto
Los recursos disponibles del proyecto;
La avería de trabajo; Un programa para el trabajo.
13/04/23 190
Estructura del plan del Proyecto
Introducción. Organización del proyecto. Análisis de riesgo. Requerimientos de recursos de hardware y
software. Averías de trabajo. Programa de proyecto. Mecanismos de monitoreo e informes.
13/04/23 191
Organización de actividad
Las actividades de un proyecto deben organizarse para producir salidas tangibles por la gestión 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 definición sincera de hitos de progreso.
13/04/23 192
Hitos en el Reproceso
Actividades
Estudio de factibilidadEstudio de factibilidad
Análisis de requerimientos
Análisis de requerimientos
Desarrollo de prototipo
Desarrollo de prototipo
Estudio de diseño
Estudio de diseño
Especificación de requerimientosEspecificación de
requerimientos
Hitos
Informe de factibilidadInforme de factibilidad
Requerimientos de usuario
Requerimientos de usuario
Informe de evaluaciónInforme de evaluación
Diseño arquitectónico
Diseño arquitectónico
Requerimientos del sistema
Requerimientos del sistema
13/04/23 193
La programación 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 intuición y experiencia de los gerentes.
13/04/23 194
El proceso de programación del proyecto
Identificación de las
actividades
Identificación de las
actividades
Identificación de las dependencia
de las actividades
Identificación de las dependencia
de las actividades
Estimación de los recursos
para actividades
Estimación de los recursos
para actividades
Colocación de gente en las actividades
Colocación de gente en las actividades
Creación de diagramas del
proyecto
Creación de diagramas del
proyecto
Requerimientos de software
Gráficas de actividades y gráficas
de barras
13/04/23 195
Problemas de programación Estimar la dificultad de problemas y del costo de
desarrollo de una solución es duro. La productividad no es proporcional al número de
las personas que trabajan en una tarea. Agregar personas a hechos tardíos del proyecto
lo retrasa debido a gastos de comunicación. El inesperado siempre ocurre. Siempre permitir la
contingencia en la planificación.
13/04/23 196
Gráficas de barra y redes de actividades
Las notaciones gráficas son usadas para ilustrar la programación de proyectos.
Mostrar las averías del proyecto en las tareas. Las tareas no deben ser demasiado pequeñas. Ellos deben tomar entre una semana o dos.
Los gráficos de actividad muestran las dependencias entre las tareas y el camino crítico.
Los gráficos de barra muestran la programación contra el tiempo de calendario.
13/04/23 197
Duración de tareas y dependenciasActividad Duración (días) Dependencias
Inicio 0
T1 8 Inicio
T2 15 Inicio
T3 15 T1
T4 10 Inicio
T5 10 T2, T4
T6 5 T1, T2
T7 20 T1
T8 25 T4
T9 15 T3, T6
T10 15 T5, T7
T11 7 T9
T12 10 T11
Final 0 T8, T10,T12
13/04/23 198
Red de actividades
13/04/23 199
Calendario de Actividades
13/04/23 200
Asignación de personal
13/04/23 201
Gestión de riesgos La gestión 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. Los riesgos del proyecto afectan programa
(calendario) o recursos; Los riesgos del producto afectan la calidad o el
desempeño del software que está desarrollándose; Los riesgos comerciales afectan el desarrollo de la
organización o la procura del software.
13/04/23 202
Riesgos del softwareRiego Afectados Descripción
Producción personal Proyecto El personal experimentado dejará el proyecto antes que esté acabado.
Cambio de gestión Proyecto Habrá un cambio en la gestión de la organización con diferentes prioridades.
Indisponibilidad del hardware
Proyecto Hardware que es esencial para el proyecto no será entregado de acuerdo a la programación.
Cambio de requerimientos
Proyecto y producto
Habrá un gran número de cambios en los requerimientos que se anticiparon.
Retrasos de la especificación
Proyecto y producto
Especificaciones de interfaces esenciales no estas disponibles en la programación.
Tamaño subestimado Proyecto y producto
El tamaño del sistema ha sido subestimado.
Bajo desempeño de herramientas CASE
Producto Las herramientas CASE que dan soporte al proyecto no tienen el desempeño esperado.
Cambio de tecnología Negocio La tecnología subyacente para la construcción del sistema, ha sido superado por nuevas tecnologías.
Competencia de producto
Negocio Un producto de la competencia es marketeado antes que el sistema haya sido entregado.
13/04/23 203
El proceso de gestión de riesgos
Identificación de riesgos Identificación de riesgos del proyecto, del
producto y del negocio; Análisis de riesgos
Evaluar la probabilidad y consecuencias de estos riesgos;
Planificación de riesgos Preparar los planes para evitar o minimizar los
efectos de los riesgos; Monitoreo de riesgos
Monitorear los riesgos a través del proyecto.
13/04/23 204
El proceso de gestión de riesgos
Identificación de riesgos
Identificación de riesgos
Monitoreo de riesgosMonitoreo de riesgos
Lista de riegos potenciales
Lista de riegos potenciales
Lista de riegos prioritarios
Lista de riegos prioritarios
Anulación de riesgos y planes de
contingencia
Anulación de riesgos y planes de
contingencia
Valoración de riesgosValoración de riesgos
Análisis de riesgos
Análisis de riesgos
Planificación de riesgosPlanificación
de riesgos
13/04/23 205
Identificación de riesgosRiesgos tecnológicos.Riesgos de personas.Riesgos organizacionales.Riesgos de requerimientos.Riesgos de estimación.
13/04/23 206
Tipos de riesgosTipo de riesgo Posibles riesgos
Tecnológico 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 organización es reestructurada, de modo que diferentes gestiones son responsables para el proyecto.Problemas funcionales de organización fuerzan a reducir el presupuesto del proyecto.
Herramientas El código generado por las herramientas CASE es deficiente.Las herramientas CASE no pueden ser integradas.
Requerimientos Los cambios de requerimientos que requieren mayor diseño proponen retrabajo.Los clientes no entienden el impacto de los cambios de requerimientos.
Estimación El tiempo requerido para desarrollar el software es subestimado.La tasa de reparación de fallas es subestimada.El tamaño del software es subestimado.
13/04/23 207
Análisis de riesgosEvaluar la probabilidad y seriedad de
cada riesgo.La probabilidad puede ser muy baja,
baja, moderada, alta o muy alta.Los efectos de riesgo podrían ser
catastróficos, serios, tolerables o insignificantes.
13/04/23 208
Análisis de riesgos (i)Riesgo Probabilidad Efectos
Problemas funcionales de organización fuerzan a reducir el presupuesto del proyecto.
Baja Catastrófico
Es imposible reclutar personas con las habilidades requeridas.
Alta Catastrófico
Personal importante está enfermo en tiempos críticos del proyecto.
Moderada Serio
Los componentes de software que van a ser reusados contienen defectos que limitan su funcionalidad.
Moderada Serio
Los cambios de requerimientos que requieren mayor diseño proponen retrabajo.
Moderada Serio
La organización es reestructurada, de modo que diferentes gestiones son responsables para el proyecto.
Alta Serio
13/04/23 209
Análisis de riesgos (ii)Riesgo Probabilidad Efectos
La base de datos usada en el sistema no puede procesar muchas transacciones por segundo como se estera.
Moderada Serio
El tiempo requerido para desarrollar el software es subestimado.
Alta Serio
Las herramientas CASE no pueden ser integradas. Alta Tolerable
Los clientes no entienden el impacto de los cambios de requerimientos.
Moderada Tolerable
El entrenamiento requerido para las personas no está disponible
Moderada Tolerable
La tasa de reparación de fallas es subestimada. Moderada Tolerable
El tamaño del software es subestimado. Alta Tolerable
El código generado por las herramientas CASE es deficiente.
Moderada Insignificante
13/04/23 210
Planificación de riesgos Considerar cada riesgo y desarrollar una
estrategia para manejar ese riesgo. Estrategias de anulación
La probabilidad que el riesgo surgirá es reducida; Estrategias de minimización
El impacto del riesgo en el proyecto o el producto será reducido;
Planes de contingencia Si el riesgo surge, los planes de contingencia son
planeados para tratar con ese riesgo.
13/04/23 211
Estrategias de gestión de riesgos (i)
Riesgo EstrategiaProblemas financieros de organización
Preparar un documento de información para la alta dirección mostrando cómo los proyectos son hechos como una contribución 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.
13/04/23 212
Estrategias de gestión de riesgos (ii)
Riesgo EstrategiaCambio de requerimientos
Derivar la información de trazabilidad para evaluar el impacto de cambio de requerimientos , maximizar la información oculta en el diseño.
Reestructuración organizacional
Preparar un documento de información para la alta dirección mostrando cómo los proyectos son hechos como una contribución muy importante para alcanzar las metas de los negocios.
Desempeño de base de datos
Investigar la posibilidad de compra una base de datos de alto desempeño.
Tiempo de desarrollo subestimado
Investigar compra de componentes, investigar el uso de un generador de programas.
13/04/23 213
Monitoreo de riesgosEvaluar cada uno de los riesgos
identificados regularmente para decidir si está o no volviéndose menos o más probable.
También evaluar si los efectos del riesgo han cambiado.
Cada riesgo importante debe discutirse en las reuniones de progreso de gestión.
13/04/23 214
Indicadores de riesgoTipo de riesgo Indicadores potenciales
Tecnología Entrega tardía de hardware o soporte de software, muchos problemas técnicos reportados.
Gente Pobre moral del personal, pobre interrelación entre los miembros del equipo, disponibilidad de trabajo.
Organización Chisme organizacional, falta de acción de la alta dirección.
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.
Estimación Fracaso para reunirse en el horario acordado, falla para borrar los defectos de reporte.
13/04/23 215
Puntos clave La buena gestión del proyecto es esencial para el
éxito del proyecto. La naturaleza intangible del software causa
problemas para la gestión. Los gerentes tienen diversos papeles, pero sus
actividades más significativas están planeadas, estimadas y programadas.
La planificación y estimación son procesos iterativos que continúan a lo largo del curso de un proyecto.
13/04/23 216
Un hito del proyecto es un estado predecible dónde un informe formal del progreso se presenta a la dirección.
La programación del proyecto involucra preparar varias representaciones gráficas que muestran las actividades del proyecto, sus duraciones y asignación de personal.
La gestión 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.
Puntos clave
13/04/23 217
Requerimientos de software
Capítulo 6
13/04/23 218
ObjetivosIntroducir los conceptos of usuario y
requerimientos del sistemaDescribir requerimientos funcionales
y no funcionalesExplicar cual requerimientos de
software pueden ser organizados en un documento de requerimientos
13/04/23 219
Tópicos cubiertosRequerimientos funcionales y no
funcionales Requerimientos de usuarioRequerimientos del sistemaEspecificación de la interfazDocumento de requerimientos de software
13/04/23 220
Ingeniería 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 ingeniería de requerimientos.
13/04/23 221
¿Qué es un requerimiento? Puede ir de una declaración abstracta de alto nivel de un
servicio o de una restricción del sistema a una especificación funcional matemática detallada.
Es inevitable que los requisitos puede servir a una función dual Pueda ser la base para una oferta de un contrato - por
consiguiente debe estar abierto a la interpretación; Pueda ser la base para el propio contrato - por
consiguiente debe definirse en detalle; Ambas estas declaraciones pueden llamarse
requerimientos.
13/04/23 222
Abstracción de requerimientos (Davis)
“ “Si una compañía desea firmar un contrato para un proyecto grande de desarrollo de software, debe definir sus necesidades de una manera suficientemente abstracta que una solución no se predefina. Los requerimientos deben escribirse para que varios contratistas puedan ofrecerse para el contrato, ofreciendo, quizás, maneras diferentes de satisfacer las necesidades de la organización del cliente. Una vez un contrato se ha otorgado, el contratista debe escribir para el cliente una definición del sistema con más 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 ".
13/04/23 223
Tipos de requerimientos Requerimientos de usuario
Las declaraciones en el idioma natural más los diagramas de los servicios que el sistema proporciona y sus restricciones operacionales. Escrito para clientes.
Requerimientos 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.
13/04/23 224
Definiciones y especificaciones
Definición de requerimientos de usuario
Especificación de requerimientos del sistema
1. El software be proporcionar los medios de representar y acceder a archivos externos creados por otras herramientas
1. El software be proporcionar los medios de representar y acceder a archivos externos creados por otras herramientas
1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos.
1.2 Cada tipo de archivo externo puede tener una herramienta asociada la cual se aplica al archivo.
1.3 Cada tipo de archivo externo puede ser representado con un icono especificado en la visual del usuario.
1.4 Pueden ser proporcionadas facilidades para representar el icono en un tipo de archivo externo definido por el usuario.
1.5 Cuando el usuario selecciona un icono que representa un archivo externo, el efecto de esta selección es para aplicar la herramienta asociada con el tipo de archivo externo para el archivo representado por el icono seleccionado.
1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos.
1.2 Cada tipo de archivo externo puede tener una herramienta asociada la cual se aplica al archivo.
1.3 Cada tipo de archivo externo puede ser representado con un icono especificado en la visual del usuario.
1.4 Pueden ser proporcionadas facilidades para representar el icono en un tipo de archivo externo definido por el usuario.
1.5 Cuando el usuario selecciona un icono que representa un archivo externo, el efecto de esta selección es para aplicar la herramienta asociada con el tipo de archivo externo para el archivo representado por el icono seleccionado.
13/04/23 225
Lectores de requerimientos
Requerimientos de usuario
Requerimientos de usuario
Requerimientos del sistema
Requerimientos del sistema
Especificación del diseño de
software
Especificación del diseño de
software
Gestión del cliente
Usuarios finales del sistema
Ingenieros del cliente
Gerentes de contrato
Arquitectos del sistema
Gestión del cliente
Usuarios finales del sistema
Ingenieros del cliente
Gerentes de contrato
Arquitectos del sistema
Usuarios finales del sistema
Ingenieros del cliente
Arquitectos del sistema
Desarrolladores de software
Usuarios finales del sistema
Ingenieros del cliente
Arquitectos del sistema
Desarrolladores de software
Ingenieros del cliente (quizás)
Arquitectos del sistema
Desarrolladores de software
Ingenieros del cliente (quizás)
Arquitectos del sistema
Desarrolladores de software
13/04/23 226
Los requerimientos funcionales y no funcionales
Requerimientos Funcionales Las declaraciones de servicios que el sistema debe
proporcionar, cómo el sistema debe reaccionar a entradas particulares y cómo 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, estándares, etc.
Requerimientos del dominio Requerimientos que vienen del dominio de la aplicación
del sistema y que refleje las características de ese dominio.
13/04/23 227
Requerimientos funcionales
Describe la funcionalidad o servicios del sistema. Depende del tipo del software, usuarios
esperados y el tipo de sistema dónde 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.
13/04/23 228
Los sistemas LIBSYS Un sistema de librería (LIBSYS) que
proporciona una sola interfaz a varios bases de datos de artículos en diferentes librerías.
Los usuarios pueden buscar, pueden bajar y pueden imprimir estos artículos para el estudio personal.
13/04/23 229
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 almacén del documento.
A cada orden se asignará un único identificador (ORDER_ID) qué el usuario podrá copiar al área del almacenamiento permanente de la cuenta.
13/04/23 230
Imprecisión de los requerimientos
Los problemas surgen cuando los requerimientos no se declaran con precisión.
Los requerimientos ambiguos pueden interpretarse de maneras diferentes por desarrolladores y usuarios.
Considerar el término “los visualizadores apropiados” La intención del usuario - el visualizador del propósito
especial para cada tipo del documento diferente; La interpretación del diseñador - Proporciona un
visualizador del texto que muestra los volúmenes del documento.
13/04/23 231
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 ningún conflicto o contradicciones en las descripciones de los recursos del sistema.
En la práctica, es imposible producir un documento de requerimientos completo y consistente.
13/04/23 232
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 también pueden ser especificados asignando un sistema CASE particular, un lenguaje de programación o un método de desarrollo.
Los requerimientos no funcionales pueden ser más críticos que los requerimientos funcionales. Si éstos no se reúnen, el sistema es inútil.
13/04/23 233
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 ejecución, la fiabilidad, etc.
Requerimientos organizacionales Requerimientos que son una consecuencia de políticas
organizacionales y procedimientos, por ejemplo las estándares del proceso usados, requerimientos de aplicación, 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.
13/04/23 234
Tipos de requerimientos no funcionales
Requerimientos del productoRequerimientos
del producto
Requerimientos de utilidad
Requerimientos de utilidad
Requerimientos de portabilidadRequerimientos de portabilidad
Requerimientos éticos
Requerimientos éticos
Requerimientos de entrega
Requerimientos de entrega
Requerimientos de desempeñoRequerimientos de desempeño
Requerimientos de privacidadRequerimientos
de privacidad
Requerimientos organizacionales
Requerimientos organizacionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos de implementaciónRequerimientos de
implementación
Requerimientos legales
Requerimientos legales
Requerimientos de interoperabilidadRequerimientos de interoperabilidad
Requerimientos externos
Requerimientos externos
Requerimientos de fiabilidadRequerimientos
de fiabilidad
Requerimientos de espacio
Requerimientos de espacio
Requerimientos de eficienciaRequerimientos
de eficiencia
Requerimientos estándar
Requerimientos estándar
Requerimientos de seguridad físicaRequerimientos de
seguridad física
13/04/23 235
Ejemplos de requerimientos no funcionales
Requerimientos del producto8.1 La interfaz del usuario para LIBSYS será implementado
como HTML simple sin marcos o applets (aplicaciones o para Internet) de Java.
Requerimientos organizacionales9.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 externos7.6.5 El sistema no descubrirán información personal sobre
clientes aparte de su nombre y número de referencia para operadores del sistema.
13/04/23 236
Metas y requerimientos Los requerimientos no funcionales pueden ser muy
difíciles de declarar con precisión y los requerimientos imprecisos pueden ser difíciles de verificar.
Meta Una intención general del usuario como la facilidad de
uso. Requerimiento no funcional verificable
Una declaración que usa alguna medida que puede probarse objetivamente.
Las metas son útiles a desarrolladores cuando ellos llevan las intenciones de los usuarios del sistema.
13/04/23 237
Ejemplos Una meta del sistema
El sistema debe ser fácil 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 podrán usar todas las
funciones del sistema después de un total de dos horas de entrenamiento . Después de este entrenamiento, el número promedio de errores cometidos por los usuarios experimentados no excederá de dos por día.
13/04/23 238
Medidas de requerimientos Propiedad Medida
Velocidad Transacciones/segundo procesadas.Tiempo de respuesta usuario/evento.Tiempo de refrescamiento de pantalla.
Tamaño MBytes.Nº de chips ROM.
Facilidad de uso Tiempo de entrenamiento.Número de marcos de ayuda.
Fiabilidad Tiempo promedio de falla.Probabilidad de indisponibilidad.Tasa de ocurrencia de falla.Disponibilidad.
Robustez Tiempo de reinicio después de falla.Porcentaje de eventos causados por falla.Probabilidad de corrupción de datos en falla.
Portabilidad Porcentaje de declaraciones dependientes de objetivo.Numero de objetivos del sistema.
13/04/23 239
Interacción 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 número de chips separados
en el sistema debe minimizarse. Para minimizar el consumo de energía, deben usarse
chips del más bajo poder. Sin embargo, el uso de chips de bajo poder puede
significar que más chips tienen que ser usadas. ¿Cual es el requerimiento más crítico?
13/04/23 240
Requerimientos del dominio
Derivado del dominio de aplicación y describe las características del sistema y rasgos que refleja el dominio.
Los requerimientos del dominio son los nuevos requerimientos funcionales, restricciones en los requerimientos existentes o define cómputos específicos.
Si los requerimientos del dominio no están satisfechos, el sistema puede ser inexplotable.
13/04/23 241
Requerimientos del dominio del sistema de librería
Habrá una interfaz de usuario estándar a todas los bases de datos que serán 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 imprimirán localmente en el servidor del sistema para remitir a mano al usuario, o se enviarán a una impresora de la red.
13/04/23 242
Tren del sistema de protección
La desaceleración del tren se calculará como:
Dtren = Dcontrol + Dgradiente
donde Dgradiente tiene 9.81ms2 años * gradiente/alpha compensado y donde los valores de 9.81ms2 /alpha son conocidos por los tipos diferentes de tren.
13/04/23 243
Problemas de requerimientos del dominio
Entendibilidad Los requerimientos son expresados en el lenguaje del
dominio de aplicación; Esto a menudo no es entendido por los ingenieros de
software que desarrollan el sistema. Implicitidad
Los especialistas del dominio entienden tan bien el área, que no piensan en la fabricación de los requerimientos explícitos del dominio .
13/04/23 244
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 técnico.
Los requerimientos del usuario son definidos usando lenguaje natural, tablas y diagramas de modo que éstos puedan ser entendidos por todos los usuarios.
13/04/23 245
Problemas con el lenguaje natural
Falta de claridad La precisión es difícil sin hacer que el
documento sea difícil de leer. Confusión de requerimientos
Los requerimientos funcionales y no funcionales tienden a ser confundidos.
La fusión de requerimientos Pueden expresarse juntos varios
requerimientos diferentes.
13/04/23 246
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.
13/04/23 247
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 centímetros o pulgadas, vía una opción en el panel de control. Inicialmente, la rejilla está desactivada. La rejilla puede ponerse en on /off cuando se quiera durante una sesión de edición y puede ser intercambiada entre pulgadas y centímetros cuando se quiera. Una opción de rejilla se proporcionará en la vista del reducir al ataque pero el número de líneas de la rejilla mostrados se reducirá para evitar el relleno del diagrama más pequeño con las líneas de la rejilla.
13/04/23 248
Problemas de requerimientos
Los requerimientos de la base de datos incluyen información conceptual y detallada Describe el concepto de un sistema de contabilidad
financiera que será incluido en LIBSYS; Sin embargo, también 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).
13/04/23 249
Presentación estructurada2.6.1 Recursos de rejilla
El editor proporcionará un recurso de rejilla dónde una matriz de líneas horizontales y verticales proporciona un fondo a la ventana del editor. Esta rejilla será una rejilla pasiva dónde la alineación de entidades es la responsabilidad del usuario.
La razón: Una rejilla ayuda para que el usuario cree un diagrama ordenado con las entidades bien espaciadas. Aunque una rejilla activa dónde las entidades están 'partidas en' las líneas de la rejilla pueden ser útiles, el posicionamiento es impreciso. El usuario es la mejor persona para decidir donde deben posicionarse las entidades.
La especificación: ECLIPSE /WS /Tools/DE/FS Sección 5.6
La fuente: Ray Wilson, la Oficina de Glasgow.
13/04/23 250
Pautas para escribir los requerimientos
Inventar un formato estándar 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.
13/04/23 251
Requerimientos del sistema
Las especificaciones más detalladas de funciones del sistema, servicios y restricciones que los requerimientos del usuario.
Se piensa que ellos son una base por diseñar 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 Capítulo 8.
13/04/23 252
Requerimientos y diseño En principio, los requerimientos deben declarar lo
que el sistema debe hacer y el diseño debe describir cómo se hace esto.
En la práctica, los requerimientos y el diseño plan son inseparables. Una arquitectura del sistema puede diseñarse para
estructurar los requerimientos; El sistema puede interoperar con otros sistemas que
generan los requerimientos del diseño; El uso de un diseño específico puede ser un
requerimiento del dominio.
13/04/23 253
Problemas con especificación NL Ambigüedad
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 difícil.
Sobre-flexibilidad La misma cosa, puede decirse de varios maneras
diferentes en la especificación. Falta de modularización
Las estructuras NL son inadecuadas para estructurar los requerimientos del sistema.
13/04/23 254
Alternativas de especificación NL Propiedad Medida
Lenguaje natural estructurado
Esta aproximación depende de definir formas normales o plantillas para expresar la especificación de requerimientos.
Descripción del diseño
Esta aproximación usa un lenguaje como un lenguaje de programación, pero con los rasgos más abstractos para especificar los requerimientos definiendo a modelo operacional del sistema. Esta aproximación no es usada ahora ampliamente, aunque puede ser útil para las especificaciones de la interfaz.
Notaciones gráficas Un lenguaje gráfico, complementado por anotaciones de texto es usado para definir los requerimientos funcionales del sistema. Un ejemplo temprano de tal lenguaje gráfico era SADT. Ahora, descripciones de casos de uso y diagramas de secuencia son usados comúnmente.
Especificaciones matemáticas
Éstas son anotaciones basadas en conceptos matemáticos como máquinas de estado finito o conjuntos. Estas especificaciones no ambiguas reducen los argumentos entre cliente y contratista sobre la funcionalidad del sistema. Sin embargo, la mayoría de los clientes no entienden las especificaciones formales y son renuentes para aceptar como un contrato del sistema.
13/04/23 255
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 estándar.
La terminología usada en la descripción puede ser limitada.
La ventaja es que la mayoría de las expresiones del lenguaje natural se mantienen, pero un grado de uniformidad se impone en la especificación.
13/04/23 256
Especificaciones basadas en formatos
Definición de función o entidad.Descripción of entradas y de dónde vienen
ellas.Descripción of salidas y a dónde van ellas. Indicación de otras entidades requeridas.Pre y post condiciones (si son apropiados).Los efectos laterales (si cualquier) de la
función.
13/04/23 257
Especificación del nodo basada en formatos
Insulin Pump /Control Software/SRS/3.3.2
Función Computa la dosis de insulina: El nivel de azúcar seguro.
Descripción Computa la dosis de insulina para ser entregada cuando el nivel de azúcar moderado actual está en la zona segura entre 3 y 7 unidades.
Entradas Lectura actual de azúcar (r2), las dos lecturas previas (el r0 y r1).
Fuente La lectura actual de azúcar desde e sensor. Otras lecturas desde la memoria.
Salidas CompDose - la dosis en la insulina para ser entregado.
Destino Ciclo de control principal..
Acción CompDose es el cero si el nivel de azúcar es estable o cayéndose o si el nivel está aumentando pero la proporción 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 azúcar 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 mínima que puede entregarse.
Requiere Dos lecturas anteriores para que la proporción de cambio de nivel de azúcar pueda calcularse.
Pre condición La reserva de insulina contiene al menos el máximo permitido de dosis simple de insulina.
Post condición r0 es reemplazado por r1 entonces r1 es reemplazado por r2.
Efectos colaterales
Ninguno.
13/04/23 258
Especificación tabular Usado para complementar el lenguaje
natural.Particularmente útil cuando se tiene
que definir varias posibles alternativas en el curso de acción.
13/04/23 259
Especificación tabularCondición AcciónCaída de nivel de azúcar (r2 < r1)
CompDose = 0
Nivel de azúcar estable (r2 = r1)
CompDose = 0
Nivel de azúcar aumentando y tasa de incremento decreciendo ((el r2-r1)<(r1-r0))
CompDose = 0
Nivel de azúcar aumentando y tasa de incremento estable o aumentando.((el r2-r1)? (el r1-r0))
CompDose = redondeo ((el r2-r1)/4)
Si el resultado redondeado = 0 entonces
CompDose = MinimumDose
13/04/23 260
Modelos gráficosLos modelos gráficos son muy útiles
cuando se necesita mostrar cómo los cambios de estado o donde se necesita describir una secuencia de acciones.
Diferentes modelos gráficos se explican en el Capítulo 8.
13/04/23 261
Diagramas de secuencia Éstos muestran la sucesión de eventos que tienen
lugar durante alguna interacción 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; Petición manual; Completar transacción.
13/04/23 262
Diagrama de secuencia de retiro de CA (Cajero Automático)
c : Cliente
ca : CajeroAutomático bd : Base de Datos
1: Tarjeta 2: Número de tarjeta
4: Tarjeta OK3: Solicitud de PIN
5: PIN
7: Tarjeta inválida
<<execpción>>
6: Menú de Opciones
8: Pedido de retiro
<<excepción>>
9: Pedido de balance
11: Balance10: Pedido de monto
12: Monto 13: Cargar(Monto)
14: Rpta de carga15: Efectivo insuficiente
16: Tarjeta
17: Retirar tarjeta
18: Efectivo
19: Retirar efectivo
20: Recibo
13/04/23 263
Especificación de la interfaz La mayoría 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 técnica eficaz para la especificación de la interfaz.
13/04/23 264
Descripción de interfaz PDLnterface 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
13/04/23 265
El documento de requerimientos
El documento de requerimientos es la declaración oficial de lo que es requerido por los desarrolladores del sistema.
Debe incluir una definición de requerimientos del usuario y una especificación de los requerimientos del sistema.
NO es un documento de diseño. Hasta donde posible, debe poner de lo QUE el sistema debe hacer en lugar de CÓMO debe hacerlo
13/04/23 266
Usuarios de un documento de requerimientos
Clientes del sistemaClientes del sistema
GerentesGerentes
Ingenieros de sistemas
Ingenieros de sistemas
Especifican los requerimientos y los leen para chequear que reúnan sus necesidades. Ellos especifican los cambios en los requerimientos.
Especifican los requerimientos y los leen para chequear que reúnan sus necesidades. Ellos especifican los cambios en los requerimientos.
Usan el documento de requerimientos para planificar una oferta para el sistema y planifican el proceso de desarrollo del sistema.
Usan el documento de requerimientos para planificar una oferta para el sistema y planifican el proceso de desarrollo del sistema.
Usan los requerimientos del sistema para pensar que sistema va a ser desarrollado.Usan los requerimientos del sistema para pensar que sistema va a ser desarrollado.
Ingenieros de pruebas del sistema
Ingenieros de pruebas del sistema
Usan los requerimientos del sistema para desarrollar las pruebas de validación del sistema
Usan los requerimientos del sistema para desarrollar las pruebas de validación del sistema
Ingenieros de mantenimiento del
sistema
Ingenieros de mantenimiento del
sistema
Usan los requerimientos del sistema para pensar en el sistema y las interrelaciones con sus partes
Usan los requerimientos del sistema para pensar en el sistema y las interrelaciones con sus partes
13/04/23 267
Estándar de requerimientos IEEE
Define una estructura genérica para un documento de requerimientos que debe ser instanciada para cada sistema específico. Introducción. Descripción general. Requerimientos específicos. Apéndices. Índices.
Nota: IEEE = Institute of Electrical Electronic Engineers = El instituto de Ingenieros Electrónicos Eléctricos
13/04/23 268
Estructura de documento de especificaciones
Prefacio Introducción Glosario Definición de requerimientos del usuario. Arquitectura del sistema Especificación de requerimientos del sistema Modelos del sistema Evolución del sistema Apéndices Indece
13/04/23 269
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 declaración convenida de los requerimientos del sistema.
El estándar de IEEE es un punto de partida útil para definir las normas específicas de los requerimientos con mayores detalles.
13/04/23 270
Puntos clave Los requerimientos parten de lo que el sistema debe
hacer y debe definir las restricciones en su funcionamiento y aplicación.
Los requerimientos funcionales parten de los servicios que el sistema debe proporcionar.
Los requerimientos no funcionales restringen el sistema a desarrollándose 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.
13/04/23 271
Proceso de ingeniería de
procesos
Capítulo 7
13/04/23 272
Objetivos Describir las principales actividades de la
ingeniería de requerimientos y sus interrelaciones
Introducir las técnicas para el elicitación de requerimientos y análisis
Describir la validación de requerimientos y el papel de revisiones de requerimientos
Discutir el papel de la gestión de requerimientos en el apoyo de otros procesos de la ingeniería de requerimientos
13/04/23 273
Tópicos cubiertosEstudios de factibilidadElicitación de requerimientos y
análisisValidación de requerimientosGestión de requerimientos
13/04/23 274
Procesos de la ingeniería de requerimientos
Los procesos usados por la RE (Requirements Engineering = Ingeniería de Requerimientos) varían ampliamente dependiendo del dominio de la aplicación, las personas involucradas y la organización que desarrolla los requerimientos.
Sin embargo hay varias actividades genéricas, común a todos los procesos Elicitación de requerimientos; Análisis de requerimientos; Validación de requerimientos; Gestión de requerimientos.
13/04/23 275
Procesos de la ingeniería de requerimientos
Estudio de factibilidadEstudio de factibilidad
Elicitación de requerimientos
y análisis
Elicitación de requerimientos
y análisis
Especificación de requerimientosEspecificación de
requerimientosInforme de factibilidadInforme de factibilidad
Modelos del sistema
Modelos del sistema
Requerimientos del usuario y el
sistema
Requerimientos del usuario y el
sistema
Documento de requerimientos
Documento de requerimientos
Validación de requerimientos
Validación de requerimientos
13/04/23 276
Ingeniería de requerimientos
Elicitación de requerimientos
Elicitación de requerimientos
Especificación de requerimientos Especificación de requerimientos
Validación de requerimientos
Validación de requerimientos
Especificación de requerimientos del
sistema y modelamiento
Especificación de requerimientos del
usuario
Especificación de requerimientos del
negocio
Elicitación de e requerimientos del
sistemaElicitación de e
requerimientos del usuario
Estudio de factibilidad Prototipado
RevisionesDocumento de Documento de
requerimientos del requerimientos del sistemasistema
13/04/23 277
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 organización;
Si el sistema que use la tecnología actual puede diseñarse y dentro del presupuesto;
Si el sistema puede integrarse con otros sistemas que se usan.
13/04/23 278
Implementación del estudio de factibilidad
Basado en la valoración de información (lo que se requiere), recopilación de información y escritura del informe.
Preguntas para las personas en la organización ¿Qué pasa si el sistema no fuera llevado a cabo? ¿Cuáles son los problemas actuales del proceso ? ¿Cómo será la ayuda del sistema propuesto? ¿Cuál serán los problemas de integración? ¿Se necesita la nueva tecnología? ¿Qué habilidades? ¿Qué recursos deben apoyarse por el sistema
propuesto?
13/04/23 279
Elicitación y análisis A veces llamado elicitación de requerimientos o
descubrimiento de requerimientos. Involucra a personal técnico que trabaja con clientes
para averiguar sobre el dominio de la aplicación, 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.
13/04/23 280
Problemas del análisis 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 políticos pueden influir en los requerimientos del sistema.
Los requerimientos cambian durante el proceso del análisis. Pueden surgir nuevos stakeholders y cambios del ambiente de negocios.
13/04/23 281
La espiral de los requerimientos
Clasificación de requerimientos y organizacionales
Prioritarización de requerimientos y
negociación
Descubrimiento de requerimientos
Documentación de requerimientos
13/04/23 282
Actividades del proceso Descubrimiento de requerimientos
Interactuando recíprocamente con los stakeholders para descubrir sus requerimientos. También se descubren los requerimientos del dominio en esta fase.
Requirements de clasificación y organización Los grupos relacionan los requerimientos y los organizan en
grupos coherentes. Prioritarización y negociación
Prioritarizando los requerimientos y resolviendo los conflictos de requerimientos.
Documentación de requerimientos Se documentan los requerimientos y se entra en la próxima
espiral de la escalera de caracol.
13/04/23 283
Descubrimiento de requerimientos
El proceso de recoger la información acerca de los sistema propuesto y existentes y destilar el usuario y requerimientos del sistema a partir de esta información.
Las fuentes de información incluyen la documentación, stakeholders del sistema y la característica técnicas de sistemas similares.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 284
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
13/04/23 285
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 análisis multi-perspectiva es importante porque allí no existe una sola manera correcta de analizar los requerimientos del sistema.
13/04/23 286
Tipos de puntos de vista
Puntos de vista de interactor Las personas u otros sistemas que actúan recíproca 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 dirección y personal de seguridad son los puntos de vista indirectos.
Punto di vista del dominio Las características del dominio y restricciones que influyen
en los requerimientos. En un CA, un ejemplo sería los estándares para las comunicaciones inter-banco.
13/04/23 287
Identificación de puntos de vista
Identificar los puntos de vista usando: Proveedores y receptores de servicios del sistema; Sistemas que actúan recíproca y directamente con el
sistema a especificarse; Regulaciones y estándares; 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.
13/04/23 288
Jerarquía de los puntos de vista de LIBSYS
IndirectaIndirecta InteractorInteractor
Todos los PVs
Sistema de clasificación
Estándares de UI
DominioDominio
FinanzasFinanzasGerente de librería
Gerente de librería
Personal de librería
Catalogadores
El artículo proporciona
El artículo proporciona
PersonalPersonalEstudiantesEstudiantes ExternosExternos
Usuarios
Gerentes del sistema
13/04/23 289
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 dónde se contesta aun
conjunto pre-definido de preguntas. Entrevistas abiertas dónde hay ninguna
agenda pre-definida y un rango de problemas son explorados con los stakeholders.
13/04/23 290
Entrevistas en la práctica Normalmente una mezcla de entrevistas cerradas y
abiertas. Las entrevistas son buenas para conseguir un
entendimiento global de lo que los stakeholders hagan y cómo ellos podrían 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 terminología específica del dominio; Un poco de conocimiento del dominio está tan
familiarizado que las personas lo encuentran difícil para articular o pensar que no es ningún valor articulado.
13/04/23 291
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”.
13/04/23 292
Escenarios Los escenarios son los ejemplos de la vida real
de cómo un sistema puede usarse. Ellos deben incluir
Una descripción de la situación de arranque; Una descripción del flujo normal de eventos; Una descripción de lo que puede salir mal; Información sobre otras actividades concurrentes; Una descripción del estado cuando los escenarios
finalizan.
13/04/23 293
Escenario LIBSYS (1)La asunción inicial: El usuario se ha registrado en el sistema de LIBSYS y ha localizado el periódico que contiene la copia del artículo.
Normal: El usuario selecciona el artículo a ser copiado. El él o ella es entonces impulsado por el sistema para proporcionar información como subscriptor del periódico o indicar cómo pagarán por el artículo. Los métodos del pago alternativos son por tarjeta de crédito o citando un número de cuenta organizacional.
Si pide entonces al usuario rellenar una formato de derechos de propiedad que mantiene detalles de la transacción y entonces ellos someten esto al sistema de LIBSYS.
El formato de derechos de propiedad se verifica y, si está OK, la versión PDF del artículo 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 artículo se imprime. Si el artículo se ha marcado como 'sólo impresión' es eliminado del sistema del usuario una vez que el usuario ha confirmado que la impresión está completa.
13/04/23 294
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 corrección. Si el formato es resometido y todavía es incorrecta, entonces la demanda del usuario para el artículo se rechaza.
El pago puede ser rechazado por el sistema. La demanda del usuario para el artículo es rechazado.
La transmisión del artículo puede fallar. Reintentar hasta obtener un resultado exitoso o que el usuario termine la sesión.
Puede no ser posible imprimir el artículo. Si el artículo no se marca como “sólo impresión” entonces es retenido el área de trabajo de LIBSYS. De otro modo, el artículo se elimina con la cuenta que el usuario acreditó con el costo del artículo.
Otras actividades: Transmisión simultáneo de otros artículos.
El estado del sistema en la realización: El usuario es registrado. El artículo transmitido se ha eliminado del área de trabajo de LIBSYS si se ha marcado como “sólo impresión”.
13/04/23 295
Casos de uso Los casos de uso son un escenario técnicamente
basados en el UML que identifica a los actores en una interacción y qué describe la propia interacción.
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 sucesión de eventos que se procesan en el sistema.
13/04/23 296
Caso de uso: Imprimir artículo
Usario Imprimir artículo
13/04/23 297
Casos de uso LIBSYS
Buscar artículo
Imprimir artículoUsuario de Librería
Administración de usuario Personal de Librería
Proveedor Servicio de catálogo
13/04/23 298
Imprimir artículo
usuario1 : Usuario
item : Artículo
formDR : Formulario
miET : EspacioTrabajo
miImpresora : Impresora
1: Petición 2: Petición
3: Retornar
4: Completar
5: DR:=OK
6: Entregar
7: Artículo:=OK
8: Imprimir 9: Enviar
10: Confirmar11: Informar
12: Eliminar
13/04/23 299
Secuencia: Imprimir artículo
usuario1 : Usuario
item : Artículo
formDR : Formulario
miET : EspacioTrabajo
miImpresora : Impresora
1: Petición 2: Petición
3: Retornar
4: Completar
5: DR:=OK
6: Entregar
7: Artículo:=OK
8: Imprimir 9: Enviar
10: Confirmar11: Informar
12: Eliminar
13/04/23 300
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 sistemática de acometer su análisis.
13/04/23 301
Etnografía Unos científicos sociales se pasan un tiempo
considerable observando y analizando cómo 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 etnografía han mostrado que ese trabajo es normalmente más rico y más complejo que el sugerido por simples modelos del sistema.
13/04/23 302
La etnografía enfocada Desarrollado en un proyecto que estudia el
proceso de control de tráfico aéreo. Combina la etnografía con el prototipado. El desarrollo del prototipo produce preguntas sin
contestar que enfocan el análisis de la etnografía.
El problema con la etnografía es que estudia prácticas existentes que pueden tener alguna base histórica lo que no es por mucho tiempo relevante.
13/04/23 303
Etnografía y prototipado
Análisis etnográfico
Análisis etnográfico
Reuniones interrogando
Reuniones interrogando
Etnografía enfocadaEtnografía enfocada
Evaluación del prototipo
Evaluación del prototipo
Desarrollo de sistemas genéricos
Desarrollo de sistemas genéricos
Prototipado de sistemasPrototipado de sistemas
13/04/23 304
Alcance de la etnografíaLos 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 cooperación y conocimiento de las actividades de otras personas.
13/04/23 305
Validación de requerimientos
Hay interés en la demostración 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 validación es muy importante Arreglar un error de los requerimientos
después de la entrega, puede costar 100 veces el costo de arreglar un error de implementación.
13/04/23 306
Comprobando requerimientos
Validez. ¿El sistema proporciona las funciones que dan el mejor soporte a las necesidades del cliente?
Consistencia. ¿Hay algún conflicto de requerimientos?
Completitud. ¿Están incluidas todas las funciones requeridas por el cliente?
Realismo. ¿Pueden los requerimientos ser implementados dados el presupuesto y la tecnología disponibles?
Verificabilidad. ¿Los requisitos pueden verificarse?
13/04/23 307
Técnicas de validación de requerimientos
Revisiones de requerimientos El análisis manual sistemático de los
requerimientos. Prototipado
Usando un modelo ejecutable del sistema para verificar los requerimientos. Cubierto en Capítulo 17.
Generación de casos de prueba Desarrollo pruebas de los requerimientos para
verificar la comprobabilidad.
13/04/23 308
Revisión de requerimientos Deben sostenerse las revisiones regulares
mientras la definición de requerimientos estén formulándose.
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.
13/04/23 309
Comprobación de la revisión
Verificabilidad. ¿El requerimiento es realísticamente 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?
13/04/23 310
Gestión de requerimientos La gestión de requerimientos es el proceso de manejar
los requerimientos cambiantes durante el proceso de ingeniería de requerimientos y desarrollo del sistema.
Los requisitos están 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.
13/04/23 311
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 técnico del sistema cambian durante su desarrollo.
13/04/23 312
Evolución de los requerimientos
Entendimiento inicial del problema
Entendimiento inicial del problema
Cambio del entendimiento del problema
Cambio del entendimiento del problema
Requerimientos iniciales
Requerimientos iniciales
Cambio de los requerimientosCambio de los requerimientos
Tiempo
13/04/23 313
Resistencia y requerimientos volátiles
Requerimientos pacientes. Los requerimientos estables se derivan del centro de actividad de la organización del cliente. Por ejemplo, un hospital siempre tendrá doctores, enfermeras, etc. Pueden se derivado de modelos del dominio
Requerimientos volátiles. Los requerimientos que cambian durante el desarrollo o cuando el sistema está en el uso. En un hospital, los requerimientos se derivan de la política de cuidado de la salud.
13/04/23 314
Clasificación de requerimientosTipo de
requerimiento Descripción
Requerimientos mudables
Requerimientos que cambian debido a los cambios al ambiente en el cual la organización está operando. Por ejemplo, en los sistemas de hospital, el fondo de cuidado paciente puede cambiar y así puede exigir recolectar la información 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 diseño puede revelar nuevos requerimientos emergentes.
Requerimientos consecuenciales
Requerimientos que son el resultado de la introducción del sistema de computadora. Introduciendo el sistema de computadora pueden cambiar el proceso de organización 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 organización. Como éstos cambien, los requerimientos de compatibilidad en el comisionado o entrega, el sistema también puede tener que evolucionar.
13/04/23 315
Planificando la gestión de requerimientos
Durante el proceso de ingeniería de requerimientos, se tiene que planear: Identificación de requerimientos
Cómo se identifican los requerimientos individualmente; Proceso de gestión de cambios
El proceso sigue al analizar un cambio de requerimientos;
Políticas de trazabilidad La cantidad de información 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;
13/04/23 316
Trazabilidad La trazabilidad se preocupa por las interrelaciones entre
los requerimientos, sus fuentes y el diseño 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 diseño Los enlaces de los requerimientos al diseño.
13/04/23 317
Matriz de trazabildad
13/04/23 318
Soporte de herramientas CASE
Almacenamiento de requerimientos Los requerimientos deben gestionarse en un almacén de
datos seguro, gestionado. Gestión de cambios
El proceso de gestión de cambio es un proceso de flujo de trabajo cuyos fases pueden definirse y el flujo de información entre estas fases parcialmente automatizados.
Gestión de trazabilidad La recuperación automatizada de los enlaces entre los
requerimientos.
13/04/23 319
Gestión de cambio de requerimientos
Debe aplicarse a todos los cambios propuestos para los requerimientos.
Fases principales Análisis del problema. Discutir el problema
de los requerimientos y proponer el cambio; Análisis y costos del cambio. Evaluar los
efectos de cambio en otros requerimientos; Implementación del cambio. Modificar el
documento de los requerimientos y otros documentos para reflejar el cambio.
13/04/23 320
Gestión de cambios
Análisis del problema y
especificación del cambio
Análisis del problema y
especificación del cambio
Análisis y costos del cambio
Análisis y costos del cambio
Identificación del problema
Revisión de requerimientos
Implementación del cambio
Implementación del cambio
13/04/23 321
Puntos clave El proceso de ingeniería de requerimientos
incluye un estudio de factibilidad, elicitación de requerimientos y análisis, especificación de requerimientos y gestión de requerimientos.
El elicitación de requerimientos es el entendimiento del dominio involucrado iterativo, recolección de requerimientos , clasificación, estructuración, prioritarización y validación.
Los sistemas tienen múltiples stakeholders con requerimientos diferentes.
13/04/23 322
Puntos clave Los factores social y el organizacional influyen
sobre los requerimientos del sistema. La validación 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 gestión de requerimientos incluye planificación y gestión del cambio.
13/04/23 323
Modelos de sistema
Capítulo 8
13/04/23 324
Objetivos Explicar por qué el contexto de un sistema debe
ser los modelado como la parte del proceso de RE (Ingeniería 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 cómo los bancos de trabajo (workbenches) CASE dan soporte al modelado del sistema
13/04/23 325
Tópicos cubiertosModelos de contextoModelos de comportamientoModelos de datosModelos de objetosBancos de trabajo CASE
13/04/23 326
Modelado del sistema 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.
13/04/23 327
Tipos de modelo Modelo de procesamiento de datos, que muestra
cómo se procesan los datos en diferentes fases. Modelo de composición, que muestra cómo las
entidades están compuestas de otras entidades. Modelo arquitectónico, que nuestra los sub-
sistemas principales. Modelo de clasificación, que muestra cómo las
entidades tienen características comunes. Modelo de estímulo/respuesta, que muestra la
reacción del sistema a los eventos.
13/04/23 328
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 límites del sistema.
Lo social y organizacional pueden afectar la decisión en dónde poner los límites del sistema.
Los modelos arquitectónicos muestran el sistema y su interrelación con otros sistemas.
13/04/23 329
El contexto de un sistema de un CA
Sistema de contabilidad de
sucursal
Sistema de contabilidad de
sucursal
Sistema de contador de
sucursal
Sistema de contador de
sucursal
Sistema de seguridadSistema de seguridad
Sistema de mantenimiento
Sistema de mantenimiento
Base de datos de cuenta
Base de datos de cuenta
Base de datos de usuario
Base de datos de usuario
Sistema de Cajero
Automático
Sistema de Cajero
Automático
13/04/23 330
Modelos de procesoLos 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 información de un proceso a otro.
13/04/23 331
Proceso de obtención de equipo
Requerido por equipo específico
Requerido por equipo específico
Aceptar entrega de
equipo
Aceptar entrega de
equipo
Especificación de validaciónEspecificación de validación
Obtener costo de
estimaciones
Obtener costo de
estimaciones
Revisar entrega de
ítems
Revisar entrega de
ítems
Base de datos del proveedorBase de datos del proveedor
Hacer pedido de equipo
Hacer pedido de equipo
Hallar proveedores
Hallar proveedores
Elegir proveedor
Elegir proveedor
Instalar equipo Instalar equipo
Aceptar entrega de equipo
Aceptar entrega de equipo
Base de datos de equipo
Base de datos de equipo
Especificación de equipo
Especificación revisada
Nota de entrega
Nota de entrega
Especificación de equipo
Lista de proveedores
Especificación + Proveedor +
Estimación
Pedido de detalles +
Formato de pedido en
blanco
Notificación de pedido
Formato de pedido
verificado y revisado
Instrucciones de instalación
Aceptación de instalación
Detalles de equipo
13/04/23 332
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 cómo el datos son procesados y como se mueven a través del sistema;
Modelos de la máquina 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.
13/04/23 333
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 través de un sistema.
Los DFDs son una parte intrínseca de muchos métodos del análisis.
Notación simple e intuitiva que los clientes pueden entender.
Mostrar el procesamiento extremo-a-extremo de datos.
13/04/23 334
DFD de procesamiento de pedido
Completar formato de
pedido
Completar formato de
pedido
Ajustar al presupuesto disponible
Ajustar al presupuesto disponible
Validar
pedidoValidar
pedido
Registrar pedidoRegistrar
pedido
Enviar al proveedor
Enviar al proveedor
Aceptar entrega de equipo
Aceptar entrega de equipo
Archivo de pedidosArchivo de
pedidos
Formato de pedido
completado
Pedido de detalles +
Formato de pedido en
blanco
Detalle de pedido
Cuenta de pedido + Detalles de
cuenta
Formato de pedido firmado
Formato de pedido firmado
Pedido verificado y firmado +
Notificación de pedido
Formato de pedido firmado
13/04/23 335
Diagramas de flujo de datosLos DFDs modelan el sistema desde una
perspectiva funcional.Rastreando y documentando cómo los datos
asociados con un proceso son útiles para desarrollar un entendiendo global del sistema.
Los diagramas de flujo de datos también pueden ser usados mostrando el intercambio de datos entre un sistema y otros sistemas en su ambiente.
13/04/23 336
DFD de bombeo de insulina
Computación de requerimientos
de insulina
Computación de requerimientos
de insulina
Controlador de entrega de insulina
Controlador de entrega de insulina
Análisis de azúcar en la sangre
Análisis de azúcar en la sangre
Bombeo de insulina
Bombeo de insulina
Sensor de azúcar en la
sangre
Sensor de azúcar en la
sangre
Parámetros de sangreSangre
Comandos de control de bombeo Insulina
Nivel de azúcar en la
sangre
Requerimientos de insulina
13/04/23 337
Modelos de máquina de estados Éstos modelan el comportamiento del sistema en
respuesta a los eventos externos e interiores. Ellos muestran las respuestas del sistema a los
estímulos que se usan a menudo para el modelado de sistemas de tiempo real.
Los modelos de la máquina 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 máquina de estados.
13/04/23 338
Diagramas de estadoPermite la descomposición de un modelo
en los sub-modelos (ver la diapositiva siguiente).
Una breve descripción de las acciones es incluido siguiendo lo que “hacen” en cada estado.
Puede complementarse por tablas que describen los estados y los estímulos.
13/04/23 339
Modelo de horno microondas
Esperando
do/ Visualizar tiempo
Máxima potencia
do/ Poner Power = 600
Media potencia
do/ Poner Power = 300
Fijar tiempo
do/ Dar númeroexit/ Fijar tiempo
Deshabilitado
do/ Visualizar "Esperando"
Habilitado
do/ Visualizar "Listo"
Operación
do/ Operar el hornoMedia energía
Cronómetro
Cronómetro
Puerta abierta
Número
Puerta cerrada
Puerta cerrada
Iniciar
Máxima potencia
Media potencia
Cancelar
13/04/23 340
Descripción de estados del horno microondas
Estado DescripciónEsperando 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”.
Máxima potencia
La potencia del horno se pone a 600 vatios. El visualizador muestra “ Máxima potencia”.
Fijar tiempo El tiempo cocción se pone al valor de la entrada del usuario. El visualizador muestra el tiempo de cocción seleccionado y se pone al día 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".
Operación El horno en funcionamiento. La luz del horno interior se enciende. El visualizador muestra la cuenta atrás del cronómetro. En la realización de cocinar, el zumbador suena durante 5 segundos. La luz del horno se enciende. El visualizado muestra "Cocción completa" mientras el zumbador está sonando.
13/04/23 341
Estímulos del horno microondas
Estado DescripciónMedia potencia El usuario ha presionado el botón de media
potencia.Máxima potencia El usuario ha presionado el botón de máxima
potencia.Cronómetro El usuario ha presionado uno de los botones
del cronómetro.Número El usuario ha presionado una llave numérica.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 botón de salida.Cancelar El usuario ha presionado el botón de
cancelación.
13/04/23 342
Operación de horno microondas
OperaciónHorno
Comprobando
do/ Comprobar estado
Cocinando
do/ Ejecutar generador
Alarma
do/ Mostrar evento
Hecho
do/ Sonido durante 5 segundos
Comprobando
do/ Comprobar estado
Cocinando
do/ Ejecutar generador
Alarma
do/ Mostrar evento
Hecho
do/ Sonido durante 5 segundos
Falla de botón giratorio
Falla del emisor
OK
Interrupción
Desactivado EnEspera
Tiempo
Puerta abierta
13/04/23 343
Modelos de datos semánticos Usado para describir la estructura lógica de datos
procesados por el sistema. Un conjunto de modelos de Entidad-interrelación-
atributo fuera las entidades en el sistema, las interrelaciones entre estas entidades y los atributos de la entidad.
Ampliamente usado en el diseño de bases de datos. Puede, sin esfuerzo, implementarse usando las bases de datos relacionales.
No hay ninguna notación específica proporcionada por UML, pero objetos y asociaciones pueden ser usados.
13/04/23 344
Modelo semántico de Librería
Publica_en
En
En
Cuota_pagable_a
Solicita
Coloca
Artículo
ID_artículo
TítuloAutoresArchivo_PDFCuota
Fuente
ID_fuente
TítuloEditorEdiciónFechaPáginas
País
ID_país
ID_fuente (FK)Formato_DRTasa_impuestoId_agencia (FK)
Agencia_DR
Id_agencia
NombreDirecciónID_fuente (FK)
Pedido
Nro_pedido
PagoTotalFechaImpuesto_estadoID_artículo (FK)Id_comprador (FK)
Comprador
Id_comprador
NombreDirecciónE_mailInformeCuenta
13/04/23 345
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 también son incluidos.
Ventajas Soporta la gestión del nombre de apoyo y evita la
duplicación; Almacén del conocimiento organizacional ligado al
análisis, diseño e implementación; Muchos bancos de trabajo CASE apoyan los
diccionarios de datos.
13/04/23 346
Entradas de diccionario de datos
Nombre Descripción Tipo Fecha
Artículo Detalles del artículo publicado que pueden ser pedidas por las personas que usan LIBSYS.
Entidad 30/12/2005
Autores Los nombres de los autores del artículo quienes pueden ser una porción de la cuota.
Atributo 30/12/2005
Comprador La persona u organización que piden una copia del artículo.
Entidad 30/12/2005
Cuota_pagable_a Interrelación entre las entidades Artículo y Agencia_DR que describe la cuota del pago de los derechos reservados.
Interrelación 29/12/2005
Dirección La dirección del comprador. Esto se usa para cualquier papel que factura información que se requiere.
Atributo 31/12/2005
13/04/23 347
Modelos de objetos Los modelos del objetos describen el sistema en
términos de clases de objetos y sus asociaciones. Una clase de objetos es una abstracción 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 agregación; Modelos de interacciones.
13/04/23 348
Modelos de objetos Maneras naturales de reflejar las entidades del
mundo real manipuladas por el sistema. Las entidades más abstractas son más difíciles
de modelar usando esta aproximación. Las entidades más abstractas son más difíciles
de modelar usando esta aproximación. Las clases del objetos que reflejan las entidades
del dominio son reusables por los sistemas.
13/04/23 349
Modelos de herencia Organiza las clases de objetos de dominio en
una jerarquía. Las clases a la cima de la jerarquía reflejan los
rasgos comunes de todas las clases. Las clases del objetos heredan sus atributos y
servicios de uno o más superclases. Estos pueden entonces especializarse cuanto sea necesario.
El diseño de herencia de clases puede ser un proceso difícil si la duplicación en las ramas diferentes debe ser evitada.
13/04/23 350
Modelos de objetos en el UML
El UML es una representación estándar inventada por los diseñadores del ampliamente usado análisis orientado a objetos y métodos de diseño.
Se ha vuelto una estándar eficaz para el modelado orientado a objetos.
Notación Las clases del objeto son rectángulos con el nombre en la
cima, atributos en la media sección y operaciones en la sección del fondo;
Las interrelaciones entre las clases del objetos (conocidas como asociaciones) se muestran como líneas que unen los objetos;
La herencia es referenciada como generalización y se muestra "hacia arriba" en lugar de "hacia abajo" en una jerarquía.
13/04/23 351
Herencia de la clase LibreríaItemLibrería
NúmeroCatálogoFechaAdquisiciónCostoTipoEstadoNúmeroCopias
Adquirir()Catalogar()Disponer()Publicar()Retornar()
ItemPublicadoTítuloEditor
ItemRegistradoTítuloMedio
LibroAutorEdiciónFechaPublicaciónISBN
RevistaAñoNúmero
PelículaDirectorFechaRealizaciónDistribuidor
ProgramaComputadoraVersiónPlataforma
13/04/23 352
Herencia de la clase Usuario
EstudianteTemaMayorDirecciónDomicilio
UsuarioLibreríaNombreDirecciónTeléfonoNúmeroRegistro
Registrar()Desregistrar()
LectorAfiliación
PrestatarioItemsPréstamoMáximoPréstamo
PersonalDepartamentoTeléfonoDepto
13/04/23 353
Herencia múltiple En lugar de heredar los atributos y servicios de una
sola clase-padre, un sistema que apoya la herencia múltiple permite que las clases del objetos heredar de varias superclases.
Esto puede llevar a conflictos semánticos dónde los atributos/servicios con el mismo nombre en diferentes superclases tienen diferente semántica.
La herencia múltiple hace la reorganización de jerarquía de clases más compleja.
13/04/23 354
Herencia múltiple
GrabaciónVozAltavozDuraciónFechaGrabación
LibroAutorEdiciónFechaPublicaciónISBN
LibroParlanteNúmeroCintas
13/04/23 355
Agregación de objetosUn modelo de agregación muestra
cómo clases que son las colecciones están compuestas de otras clases.
Los modelos de agregación son similares a la interrelación "parte_de" en los modelos de los datos semánticos.
13/04/23 356
Agregación de objetos
DiapositivasOHPDiapositivas
NotasLecturaTexto
PaqueteEstudioTítuloCursoNúmeroAñoInstructor
VideocintaIdCinta
EjerciciosNúmeroProblemaDescripción
AsignaciónCréditos
SolucionesTextoDiagramas
13/04/23 357
Modelamiento del comportamiento de objetos
Un modelo de comportamiento muestra las interacciones entre los objetos para producir algún comportamiento del sistema particular que se especifica como un caso de uso.
Los diagramas de secuencia (o diagramas de colaboración) en UML son usados para modelar la interacción entre los objetos.
13/04/23 358
Edición de artículos electrónicos
usLib : UsuarioLibrería
Ecat : Catálogo itLib : ItemLibrería Lib1
1: Mirar
2: Visualizar
3: Publicar
4: Licencia de publicar
5: Aceptar licencia6: Comprimir
7: Entregar
13/04/23 359
Métodos estructurados Los métodos estructurados se incorporan al
modelado de sistemas como una parte inherente del método.
Los métodos 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 método estructurado.
13/04/23 360
Debilidades del método Ellos no modelan los requerimientos del sistema
no-funcionales. Ellos normalmente no incluyen la información
sobre si un método es apropiado para un problema dado.
El puede producir demasiada documentación. Los modelos del sistema a veces también se
detallan y son difíciles de entender para los usuarios
13/04/23 361
Bancos de trabajo CASE Un conjunto coherente de herramientas que se
diseñan para apoyar las actividades del proceso de software relacionadas como el análisis, diseño o pruebas.
Los bancos de trabajo del análisis y diseño apoyan el modelado del sistema durante la ingeniería de requerimientos y el diseño del sistema.
Estos bancos de trabajo pueden apoyar un método de diseño específico o pueden proporcionar apoyo para varios tipos diferentes de creación de modelo del sistema.
13/04/23 362
Un banco de trabajo de análisis y diseño
Generador de
código
Generador de
código
Herramientas de análisis, diseño y
comprobación
Herramientas de análisis, diseño y
comprobación
Herramientas de diagramación estructurada
Herramientas de diagramación estructurada
Almacén de información
central
Almacén de información
central
Recursos de importación / exportación
Recursos de importación / exportación
Recursos de lenguaje de
consulta
Recursos de lenguaje de
consulta
Recursos de generación de
informes
Recursos de generación de
informes
Diccionario
de
datos
Diccionario
de
datos
Herramientas de creación de formularios
Herramientas de creación de formularios
13/04/23 363
Componentes del banco de trabajo del análisis
Editores de diagrama Herramientas de comprobación del modelo de
análisis Almacén y lenguaje de consulta asociado Diccionario de datos Definición de informe y herramientas de
generación Herramientas de definición de formularios Traductores de importación/exportación Herramientas de generación de código
13/04/23 364
Puntos clave Un modelo es una vista abstracta del sistema . Los
tipos complementarios de modelo proporcionan la información del sistema diferente.
Los modelos de contexto muestran la posición 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 máquina de estados modelan el comportamiento del sistema en respuesta a los eventos internos o externos.
13/04/23 365
Puntos clave Los modelos de datos semánticos describen la
estructura lógica de datos que son importados o exportados por los sistemas.
Los modelos del objetos describen entidades del sistema lógicas, su clasificación y agregación.
Los modelos de secuencia muestran las interacciones entre actores y los objetos del sistema que ellos usan.
Los métodos estructurados proporcionan un framework para los modelos del sistema en vías de desarrollo.
13/04/23 366
Especificación de sistemas
críticos
Capítulo 9
13/04/23 367
Objetivos Explicar cómo los requerimientos de confiabilidad
pueden ser identificados analizando los riesgos enfrentados por los sistemas críticos
Explicar cómo se generan los requerimientos de seguridad del análisis de riesgo del sistema
Explicar la derivación de requerimientos de seguridad
Describir métricas usadas para la especificación de fiabilidad
13/04/23 368
Tópicos cubiertosEspecificación de manejo de riesgoEspecificación de seguridad físicaEspecificación de seguridad contra
delitosEspecificación de fiabilidad del
software
13/04/23 369
Requerimientos de confiabilidad
Requerimientos funcionales para definir comprobación de error y medios de recuperación y protección 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.
13/04/23 370
Especificación de manejo de riesgos
La especificación de los sistemas críticos debe manejar riesgos.
Esta aproximación se ha usado ampliamente en la seguridad y los sistemas de seguridad críticos.
El objetivo del proceso de especificación debe ser entender los riesgos (la seguridad física, la seguridad contra delitos, etc.) enfrentados por el sistema y para definir requerimientos que reducen estos riesgos.
13/04/23 371
Estado de análisis basado en riesgos
Identificación del riesgo Identifica riesgos potenciales que pueden surgir.
Análisis y clasificación del riesgo Evalúa la gravedad de cada riesgo.
Descomposición del riesgo Descompone los riesgos para descubrir sus causas de
raíz potenciales. Evaluación de reducción del riesgo
Define cómo cada riesgo debe tomarse para ser eliminado o reducido cuando el sistema es diseñado.
13/04/23 372
Especificación de manejo de riesgos
Identificación del riesgo
Identificación del riesgo
Evaluación de reducción del
riesgo
Evaluación de reducción del
riesgo
Descripción del riesgo
Descripción del riesgo
Evaluación del riesgo
Evaluación del riesgo
Análisis de la causa raíz
Análisis de la causa raíz
Requerimientos de confiabilidadRequerimientos de confiabilidad
Análisis y clasificación del riesgo
Análisis y clasificación del riesgo
Planificación del riesgo
Planificación del riesgo
13/04/23 373
Identificación del riesgo Identificar los riesgos enfrentados por el sistema
crítico. En los sistemas de seguridad física críticos, los
riesgos son los peligros que pueden llevar a los accidentes.
En los sistemas seguridad contra delitos críticos, los riesgos son los ataques potenciales en el sistema.
En la identificación del riesgo, se debe identificar clases de riesgos y la posición del riesgo en estas clases Falla de servicio; Riesgos eléctricos; …
13/04/23 374
Los riesgos de la bomba de insulina
Dosis excesiva de insulina (falla de servicio). Baja dosis de insulina (falla de servicio). Falla de potencia debido a la batería exhausta
(eléctrico). Interferencia eléctrica con otro equipo médico
(eléctrico). Sensor pobre e impulsor de contacto (físico). Partes de interrupción de la máquina fuera del cuerpo
(físico). Infección causada por la introducción de máquina
(biológico). La reacción alérgica a materiales o insulina (biológico).
13/04/23 375
Análisis de riesgo y clasificación 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 práctico (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 ningún costo extra debe incurrirse para reducir la probabilidad de riesgo.
13/04/23 376
Niveles de riesgo
Riego despreciable
Región ALARP
Región aceptable
Región inaceptable
El riesgo no puede ser tolerado
Riesgo tolerado sólo si la reducción del riesgo es es
impráctico o groseramente caro
13/04/23 377
Aceptabilidad social del riesgo
La aceptabilidad de un riesgo está determinada por lo humano, las consideraciones sociales y políticas.
En la mayoría de las sociedades, los límites entre las regiones se empujan más con tiempo, es decir, la sociedad está menos deseosa aceptar el riesgo. Por ejemplo, los costos de limpiar la polución pueden ser
menos costosa que prevenirla, pero esto no puede ser socialmente aceptable.
La valoración de riesgo es subjetiva. Los riesgos se identifican como probable, improbable, etc.
Esto depende en adelante de quién está haciendo la evaluación.
13/04/23 378
Valoración del riesgo Estimar la probabilidad de riesgo y la severidad
del riesgo. No es normalmente posible hacer esto con
precisión, 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.
13/04/23 379
Valoración del riesgo – bomba de insulina
Identificación del riesgo
Probabilidad del riesgo
Severidad del riesgo
Riesgo estimado
Aceptabilidad
Sobredosis de insulina
Media Alta Alta Intolerable
Baja dosis de insulina
Media Baja Baja Aceptable
Falla de potencia Alta Baja Baja AceptableMáquina ajusta incorrectamente
Alta Alta Alta Intolerable
Máquina interrumpe en el paciente
Baja Alta Media ALARP
Máquina causa infección
Media Media Media ALARP
Interferencia eléctrica
Baja Alta Media ALARP
Reacción alérgica
Baja Baja Baja Aceptable
13/04/23 380
Descomposición del riesgo Concerniente con descubrir las causas de raíz de
riesgos en un sistema particular. Las técnicas han sido principalmente derivadas de
los sistemas de seguridad crítica y pueden ser: Inductivo, técnicas de abajo - arriba. Empezar
con una falla del sistema propuesto y evaluar los riesgos que podrían surgir de esa falla;
Deductivo, técnicas de arriba - abajo. Empezar con un riesgo y deducir las posibles causas de esta.
13/04/23 381
Análisis de árbol de falla Una técnica deductiva de arriba-abajo. Poner el riesgo o azar en la raíz del árbol e
identificar los estados del sistema que podrían llevar a ese riesgo.
Donde sea apropiado, unir éstos con condiciones "y" ("and” ) o "o" ( "or” ).
Una meta debe ser minimizar el número de causas simples de falla del sistema.
13/04/23 382
Árbol de falla de la bomba de insulina
Incorrecta dosis de insulina
administrada
Incorrecta dosis de insulina
administrada
Falla de sensorFalla de sensor
Falla de cronómetro
Falla de cronómetro
OrOr
Error algorítmico
Error algorítmico
Error algorítmico
Error algorítmico
OrOr
Incorrecto cálculo de
insulina
Incorrecto cálculo de
insulina
Error de cómputo de azúcar
Error de cómputo de azúcar
OrOr
OrOr
Error aritmético
Error aritmético
OrOr
Error aritmético
Error aritmético
Incorrecta señal de bombeo
Incorrecta señal de bombeo
Incorrecto nivel de azúcar medido
Incorrecto nivel de azúcar medido
Correcta dosis entregada en mal momento
Correcta dosis entregada en mal momento
Falla de sistema de
entrega
Falla de sistema de
entrega
13/04/23 383
Valoración de la reducción del riesgo
El objetivo de este proceso es identificar requerimientos de confiabilidad que especifican que cómo deben manejarse los riesgos y deben asegurarse que esos accidentes/incidentes no surjan.
Estrategias de la reducción del riesgo: Anulación del riesgo; Detección y retiro del riesgo; Limitación del daño.
13/04/23 384
Uso de estrategias Normalmente, en los sistemas críticos, una
mezcla de estrategias de reducción de riesgo es usada.
En un sistema de control de planta químico, el sistema incluirá los sensores para descubrir y corregir el exceso de presión en el reactor.
Sin embargo, también incluirá un un sistema de protección independiente que abre una válvula de auxilio, si se descubre la presión peligrosamente alta .
13/04/23 385
Bomba de insulina – riesgos de software
Error aritmético Un cómputo causa el valor de una variable
para sobreflujo o subflujo; Quizá incluya un manejador de excepción
para cada tipo de error aritmético. Error algorítmico
Compara dosis a ser entregada con dosis anterior o las dosis máximo seguras. Reduce la dosis si es demasiada alta.
13/04/23 386
Requerimientos de seguridad – bomba de insulina
SR1: El sistema no entregará una sola dosis de insulina que sea mayor que una dosis máxima especificada para un usuario del sistema.
SR2: El sistema no entregará una dosis diariamente acumulativa de insulina que sea mayor que un máximo especificado para un usuario del sistema.
SR3: El sistema incluirá un recurso de diagnóstico de hardware que se ejecutará por lo menos 4 veces por hora.
SR4: El sistema incluirá un manejador de excepción para todas las excepciones que se identifican en la Tabla 3.
SR5: La alarma audible sonará cuando cualquier hardware o anomalía del software se descubre y un mensaje de diagnóstico 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.
13/04/23 387
Especificación de seguridad física
Los requerimientos de seguridad de un sistema deben ser especificados separadamente.
Estos requerimientos deben estar basados en un análisis 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 términos de ingeniería de sistemas, la seguridad de un sistema es una propiedad emergente.
13/04/23 388
IEC 61508 Un estándar internacional para gestión de
seguridad física que se diseñó específicamente para los sistemas de protección - no es aplicable a todos los sistemas seguridad críticos.
Incorpora un modelo del ciclo de vida de seguridad física y cubre todos los aspectos de gestión de seguridad física desde la definición del alcance al sistema de decomiso.
13/04/23 389
Requerimientos de seguridad del sistema de control
Requerimientos del sistema
Requerimientos del sistema
Sistema de control
Sistema de control
Requerimientos de seguridad física
Requerimientos de seguridad física
Requerimientos de seguridad física
funcional
Requerimientos de seguridad física
funcional
Requerimientos de integridad de
seguridad física
Requerimientos de integridad de
seguridad física
EquipamientoEquipamiento
Sistema de protecciónSistema de protección
13/04/23 390
Ciclo de vida de la seguridad física
Concepto y definición de alcanceConcepto y definición
de alcance
Derivación de requerimientos de
seguridadDerivación de
requerimientos de seguridad
Análisis de peligro y riesgoAnálisis de peligro y
riesgo
Asignación de requerimientos de
seguridadAsignación de
requerimientos de seguridad
Planeando
Validación O&M Instalación
Desarrollo de sistemas de seguridad relacionados
Desarrollo de sistemas de seguridad relacionados
Recursos de reducción de
riesgos externoRecursos de reducción de
riesgos externo
Planificación y desarrollo
Validación de seguridad de físicaValidación de seguridad
de física
Instalación y comisionadoInstalación y
comisionado
Operación y mantenimientoOperación y
mantenimiento
Decomiso del sistemaDecomiso del
sistema
13/04/23 391
Requerimientos de seguridad física
Los requerimientos de seguridad física funcionales Éstos definen las funciones de seguridad física del
sistema de protección, es decir, define cómo el sistema debe proporcionar protección.
Los requerimientos de integridad de la seguridad física Éstos definen la fiabilidad y disponibilidad del
sistema de protección. Ellos están basados en el uso esperado y son clasificados usando un nivel de integridad de seguridad de 1 a 4.
13/04/23 392
Especificación de la seguridad contra delitos
Tiene un poco de similitud a la especificación de seguridad física. 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 noción bien definida de un ciclo de vida de seguridad contra delitos para la gestión de seguridad; no hay estándares;
Las amenazas genéricas en lugar de peligros específicos del sistema;
La tecnología de seguridad contra delitos es madura (encriptación, 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.
13/04/23 393
El proceso de especificación de seguridad contra delitos
Identificación del recurso
Identificación del recurso
Especificación de requerimientos de
seguridad
Especificación de requerimientos de
seguridad
Lista de recursos del sistema
Lista de recursos del sistema
Matriz de riesgos y amenazas
Matriz de riesgos y amenazas
Descripción de amenaza y
riesgo
Descripción de amenaza y
riesgo
Requerimientos de confiabilidad
Requerimientos de confiabilidad
Análisis de la amenaza y
valoración del riesgo
Análisis de la amenaza y
valoración del riesgo
Tecnología de seguridad y
análisis
Tecnología de seguridad y
análisis
Asignación de amenazaAsignación de amenaza
Análisis de tecnologíaAnálisis de tecnología
13/04/23 394
Especificación de estados en la seguridad contra delitos
Identificación del recurso y evaluación
Los recursos (datos y programas) y su grado requerido de protección son identificados. El grado de protección requerida depende del valor del recurso de modo que una contraseña de archivo (digamos) es más valioso que un conjunto de Web públicas.
Análisis de la amenaza y valoración del riesgo
Se identifican las posibles amenazas de seguridad y los riesgos asociados con cada uno de estas amenazas son estimados.
Asignación de la amenaza
Se relacionan las amenazas identificadas a los recursos para que, para cada recurso identificado, hay una lista de amenazas asociadas.
13/04/23 395
Especificación de estados en la seguridad contra delitos
Análisis de tecnología Se evalúan las tecnologías de seguridad
disponibles y su pertinencia contra las amenazas identificadas.
Especificación de requerimientos de seguridad Los requerimientos de seguridad son
especificados. Donde sea apropiado, serán explícitamente identificadas las tecnologías de seguridad que pueden usarse para proteger contra las amenazas diferentes al sistema.
13/04/23 396
Tipos de requerimientos de seguridad contra delitos
Requerimientos de identificación. Requerimientos de autenticación. Requerimientos de autorización. Requerimientos de inmunidad. Requerimientos de integridad. Requerimientos de detección de intrusión. Requerimientos de no repudio. Requerimientos de privacidad. Requerimientos de auditoria de seguridad contra delitos. Requerimientos de seguridad de mantenimiento del
sistema.
13/04/23 397
Requerimientos de seguridad LIBSYS
SEC1: Todos los usuarios del sistema se identificarán usando su número de tarjeta de biblioteca y la contraseña personal
SEC2: Los privilegios de usuario se asignarán según la clase de usuario (estudiante, personal, personal de biblioteca).
SEC3: Antes de la ejecución 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 incluirán el tiempo del pedido, la identificación del usuario y los artículos pedidos.
SEC5: Todos los datos del sistema serán apoyados una vez por día y las copias guardadas fuera de sitio en una área de almacenamiento segura.
SEC6: No se permitirán a los usuarios tener más de 1 registro simultáneo en LIBSYS.
13/04/23 398
Especificación de fiabilidad de sistemas
Fiabilidad del hardware ¿Cuál es la probabilidad de que un componente del hardware
esté fallando y cuánto tiempo toma reparar ese componente? Fiabilidad del software
Cuán 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 después de que un resultado incorrecto se ha producido.
Fiabilidad del operador ¿Cuán probable es que el operador de un sistema cause un
error?
13/04/23 399
Requerimientos de fiabilidad funcional
Un rango predefinido para todos los valores que se ingresan por el operador serán definidos y el sistema verificará que todo operador ingrese caídas dentro de ese rango predefinido.
El sistema verificará todos los discos para los bloques malos cuando se inicialicen.
El sistema debe usar la versión 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 análisis estático.
13/04/23 400
El nivel requerido de fiabilidad del sistema requerido debe expresarse cuantitativamente.
La fiabilidad es un atributo del sistema dinámico - especificaciones de fiabilidad relacionadas al código fuente no tienen sin sentido. No más de las N fallas/1000 líneas; Esto sólo es útil para un análisis de proceso de post-
entrega dónde se está intentando evaluar cuan buenas son sus técnicas de desarrollo.
Una métrica de fiabilidad apropiada debe ser elegida para especificar la fiabilidad del sistema global.
Especificación de fiabilidad no funcional
13/04/23 401
Las métricas de fiabilidad son unidades de medida de fiabilidad del sistema.
La fiabilidad del sistema es medida contando el número de fallas operacionales y, dónde apropiadamente, se relacionan éstas a las demandas hechas al sistema y el tiempo en que el sistema ha sido operacional.
Un programa de medición a largo plazo se exige evaluar la fiabilidad de sistemas críticos.
Métricas de fiabilidad
13/04/23 402
Métricas de fiabilidadMétrica Explicación
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 proporción 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 métrica 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.
13/04/23 403
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 protección dónde 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 críticos con los componentes de gestión de excepción El sistema de cierre de emergencia en una planta
química.
13/04/23 404
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, transacción que procesa sistemas dónde el sistema tiene que procesar un número grande de demandas similares que son relativamente frecuentes. Sistema de procesamiento de tarjeta de crédito,
sistema de reserva en aerolínea.
13/04/23 405
Tiempo media de falla La medida del tiempo entre las fallas observadas del
sistema. Es el recíproco 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 más largo que la longitud de la transacción. Sistemas del diseño auxiliado por computadora
dónde un diseñador trabajará en un diseño de varias horas, sistemas de procesador de texto.
13/04/23 406
Disponibilidad La medida de la fracción 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 teléfonos, sistemas de
señalamiento de vías férreas.
13/04/23 407
Especificación 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 pérdida o corrupción de datos y pérdida de servicio del sistema.
Puede ser necesario identificar diferentes clases de fallas y usar métricas diferentes para cada una de éstas. La especificación de fiabilidad debe ser estructurada.
13/04/23 408
Consecuencias de fallas Al especificar la fiabilidad, no es sólo el número
de fallas del sistema que importan sino las consecuencias de estas fallas.
Las fallas que tienen consecuencias serias son claramente más perjudiciales que aquéllos dónde se las repara y la recuperación es directa.
En algunos casos, por consiguiente, especificaciones de fiabilidad diferentes para diferentes tipos de falla pueden ser definidas.
13/04/23 409
Clasificación de fallasClase de falla DescripciónTransitoria Sólo ocurre con ciertas entradas.Permanente Ocurre con todas las entradas.Recuperable El sistema puede recuperarla sin la
intervención del operador.Inrecuperable Necesita la intervención del
operador recuperar la falla.No corrupta La falla no corrompe el estado del
sistema o datosCorrupta La falla corrompe el estado del
sistema o datos.
13/04/23 410
Para cada sub-sistema, analizar las consecuencias de posibles fallas del sistema.
Desde el análisis de falla del sistema, fallas de partición dentro de las clases apropiadas.
Para cada clase de falla identificada, presentar la fiabilidad usando una métrica apropiada. Diferentes métricas pueden usarse para los requerimientos de fiabilidad diferentes.
Identificar los requerimientos de fiabilidad funcionales para reducir las oportunidades de fallas críticas.
Pasos para especificación de fiabilidad
13/04/23 411
Sistema de cajero automático
Cada máquina en una red es usada 300 veces por día.
El banco tiene 1000 máquinas. El tiempo de vida de lanzamiento del software es
de 2 años. Cada máquina maneja aproximadamente 200,
000 transacciones. Aproximadamente 300, 000 transacciones de la
base de datos en total por día.
13/04/23 412
Especificación de fiabilidad para un CA
Clases de falla
Ejemplo Métrica de fiabilidad
Permanente no corrupta
El sistema falla para operar con cualquier tarjeta que se entra. El software debe reiniciarse para corregir la falla.
ROCOF1 ocurrencia/1000 días.
Transitoria no corrupta
Los datos de la franja magnética no pueden leerse en una tarjeta no dañada que se ingresa.
ROCOF1 en 1000 transacciones
Transitoria corrupta
Un patrón de transacciones a través de la red causa corrupción de base de datos.
¡No cuantificable!Nunca debe pasar en la vida del sistema.
13/04/23 413
Validación de la especificación
Es imposible validar empíricamente las especificaciones de fiabilidad muy altas.
Ninguna corrupción de base de datos significa POFOD de menos de 1 en 200 millón.
Si una transacción toma 1 segundo, entonces simulando una transacción por día toma 3.5 días.
Tomaría mucho más tiempo que la vida del sistema probarlo para la fiabilidad.
13/04/23 414
Puntos clave El análisis de riesgo es la base por identificar los
requerimientos de fiabilidad del sistema. El análisis de riesgo se preocupa por evaluar las
oportunidades de surgimiento de un riesgo y clasificar los riesgos según su gravedad.
Los requerimientos de seguridad contra delitos deben identificar los recursos y definir cómo deben protegerse éstos.
Pueden definirse los requerimientos de fiabilidad cuantitativamente.
13/04/23 415
Puntos claveLas métricas 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.
13/04/23 416
Especificaciones formales
Capítulo 10
13/04/23 417
Objetivos Explicar por qué las especificaciones técnicas
formales ayudan a descubrir los problemas en los requerimientos del sistema.
Describir el uso de técnicas algebraicas para la especificación de la interfaz.
Describir el uso de técnicas basadas en modelo para la especificación del comportamiento.
13/04/23 418
Tópicos cubiertosEspecificación formal en el proceso
de software Especificación de la interfaz de un
sub-sistemaEspecificación del comportamiento
13/04/23 419
Métodos formales La especificación formal es parte de una
colección más general de técnicas que son conocidas como "los métodos formales".
Ellos están todas basados en la representación matemática y análisis de software.
Los métodos formales incluyen Especificación formal; Análisis de especificación y demostración; Desarrollo transformacional; Verificación de programa.
13/04/23 420
Aceptación de los métodos formales
Los métodos formales no se han vuelto en la corriente principal de las técnicas de desarrollo de software como se predijo una vez. Otras técnicas de ingeniería de software ha sido exitosas en la
calidad creciente de sistemas . De allí que la necesidad para los métodos 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 métodos formales no reducen tiempo el tiempo de comercializar;
El alcance de los métodos formales está limitado. Ellos no están preparados para especificar y analizar las interfaces del usuario e interacción del usuario;
Los métodos formales todavía son difíciles para escalar a los sistemas grandes.
13/04/23 421
Uso de métodos formales Los principales beneficios de los métodos formales
están en la reducción del número de faltas en los sistemas.
Por consiguiente, su área principal de aplicabilidad está en la ingeniería de sistemas críticos. Ha habido varios proyectos exitosos dónde se han usado los métodos formales en este área.
En esta área, el uso de métodos formales es probablemente el más rentable porque deben evitarse los altos costos de falla del sistema .
13/04/23 422
Especificación en el proceso de software
La especificación y el diseño se entremezclan indisolublemente.
El diseño arquitectónico es esencial para estructurar una especificación y el proceso de especificación.
Las especificaciones formales son expresadas en una notación matemática con el vocabulario precisamente definido, sintaxis y semántica.
13/04/23 423
Especificación y diseño
Definición de requerimientos
del usuario
Definición de requerimientos
del usuario
Especificación de requerimientos
del sistema
Especificación de requerimientos
del sistema
Diseño
arquitectónicoDiseño
arquitectónico
Especificación
formalEspecificación
formal
Diseño de alto nivelDiseño de alto nivel
Participación creciente del contratista
Participación decreciente del cliente
Especificación
Diseño
13/04/23 424
Especificación en el proceso de software
Definición de requerimientos
del usuario
Definición de requerimientos
del usuario
Especificación de requerimientos
del sistema
Especificación de requerimientos
del sistema
Modelamiento del sistema
Modelamiento del sistema
Especificación formal
Especificación formal
Diseño
arquitectónicoDiseño
arquitectónico
Diseño de alto nivelDiseño de alto nivel
13/04/23 425
Uso de la especificación formal
La especificación formal se involucra invirtiendo más esfuerzo en las fases tempranas de desarrollo del software.
Esto reduce los errores de requerimientos forzando un análisis detallado de los requerimientos.
Pueden descubrirse estados incompletos e inconsistencias y pueden resolverse.
En consecuencia, economías como la cantidad de retrabajo debido a los problemas de requerimientos, se reducen.
13/04/23 426
El perfil del costo El uso de especificación 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 especificación;
Sin embargo, los costos de implementación y validación deben ser reducidos así como el proceso de la especificación reduce errores y ambigüedades en los requerimientos.
13/04/23 427
Desarrollo de costos con especificación formal
13/04/23 428
Especificaciones técnicas Especificación algebraica
El sistema es especificado en términos de sus operaciones y sus interrelaciones.
Especificación basada en modelo El sistema es especificado en términos de un modelo
de estados que es construido usando construcciones matemáticas tales como conjuntos y sucesiones. Las operaciones son definidas por modificaciones del estado del sistema.
13/04/23 429
Lenguajes de especificación formal
Secuencial Concurrente
Algebraico Larch(Guttag, 1993)
OBJ (Futatsugi, 1985)
Lotos (Bolognesi y Brinksma, 1987)
Basado en modelo
Z (Spivey, 1992)VDM (Jones, 1980)B (Worsworth, 1996)
CSP (Hoare, 1985)Petri Nets (Peterson 1981)
13/04/23 430
Especificación de la interfaz Los sistemas grandes se descomponen en
subsistemas con las interfaces bien definidas entre estos subsistemas.
La especificación 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 aproximación algebraica para la especificación formal está particularmente bien preparada para la especificación de la interfaz como se enfoca en las operaciones definidas en un objeto.
13/04/23 431
Interfaces de subsistema
Objetos de interfaz
Sub - sistema A
Sub - sistema B
13/04/23 432
La estructura de una especificación algebraica<SPECIFICATION NAME>
sort <name>
Imports <LIST OF SPECIFICATION NAMES>
Descripción informal de clase y sus operaciones
Signatura de operaciones que ponen encima los nombres y los tipos de parámetros para las operaciones definidas sobre la clase
Axiomas que definen operaciones sobre la clase
13/04/23 433
Componentes de especificación Introducción
Define la clase (el nombre de tipo) y declara otras especificaciones que son usados.
Descripción Informalmente describe las operaciones en el tipo.
Signatura Define la sintaxis de las operaciones en la interfaz y
sus parámetros. Axiomas
Define las semánticas de la operación por axiomas de definición que caracterizan el comportamiento.
13/04/23 434
Especificación algebraica sistemática
Especificaciones algebraica de un sistema puede ser desarrollada de una manera específica: Estructuración de la especificación; Denominación de la especificación; Selección de operación; Especificación de operación informal; Definición de la sintaxis; Definición del axioma.
13/04/23 435
Operaciones de especificación
Operaciones de constructor. Operaciones que crean entidades de un tipo que es especificado.
Operaciones de inspección. Operaciones que evalúan entidades de un tipo que es especificado.
Para especificar el comportamiento. Define las operaciones de inspector por cada operación constructor.
13/04/23 436
Operaciones en una lista ADT
Operaciones de constructor que evalúan para Lista de clase. Create, Cons y Tail.
Operaciones de inspección que toma lista de la clase como un parámetro 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.
13/04/23 437
Especificación de ListList (Elem)
sort List
Imputs Integer
Define una lista dónde los elementos son agregados al final y retirados del frente. Las operaciones son Create qué trae una lista vacía en existencia, Cons que crea una nueva lista con un miembro agregado, Length que evalúa el tamaño de la lista, Head que evalúa 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)
13/04/23 438
Recursión en especificaciones
Las operaciones se especifican a menudo recursivamente.
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]
13/04/23 439
Especificación de la interfaz en sistemas críticos
Considerar un sistema de control de tráfico aéreo dónde el vuelo del avión a través de los sectores manejados de espacio aéreo.
Cada sector puede incluir varios aviones pero, por razones de seguridad, éstos deben separarse.
En este ejemplo, una separación vertical simple de 300m es propuesta.
El sistema debe advertir al controlador si el avión es instruido para moverse de modo que la regla de la separación abra una brecha.
13/04/23 440
Un objeto de sector Las operaciones críticas en un objeto que
representan un sector controlado son: Enter. Agrega un avión al espacio aéreo
controlado. Leave. Retira un avión desde el espació aéreo
controlado; Move. Mueve un avión de una altura a otra; Lookup. Dado un identificador del avión,
devuelve su altura actual.
13/04/23 441
Operaciones primitivas A veces es necesario introducir operaciones adicionales
para simplificar la especificación. Las otras operaciones pueden entonces ser definidas
usando estas más operaciones primitivas. Operaciones primitivas
Create. Trae una instancia de un sector en existencia;
Put. Agrega un avión sin revisiones de seguridad; In-space. Determina si un avión dado está en el
sector; Occupied. Dada una altura, determina si hay un
avión dentro de 300m de esa altura.
13/04/23 442
Especificación de sector (1)SECTOR
sort Sector
Imputs INTEGER, BOOLEAN
Enter – agrega un avión en el sector si las condiciones de seguridad física.
Leave – retira un avión desde el sector.
Move - mueve un avión desde una altura a otra si está seguro de hacerlo
Lookup – halla la altura de un avión en el sector
Create – crea un sector vacío
Put – agrega un avión a un sector sin controles de restricciones
In-space - controla si un avión 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
13/04/23 443
Especificación de sector (2)Enter (S, CS, H)
If In-space (S, CS) then S exception (Hay avión 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 avión 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 avión en el sector)
elseif not In-space (S, CS) then S exception (No hay avión 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 avión 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)
13/04/23 444
Comentario de especificación
Usar los constructores básicos 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 operación.
Todos las operaciones que producen los cambios para el sector deben verificar el sostenimiento de criterio de seguridad.
13/04/23 445
Especificación del comportamiento
La especificación algebraica puede ser embarazosa cuando las operaciones del objeto no son independientes del estado del objeto.
La especificación basado en modelo expone el estado del sistema y define las operaciones en términos de cambios para ese estado.
La notación Z es una técnica madura para la especificación basada en modelo. Combina descripción formal e informal y usa el resaltado gráfico al presentar las especificaciones.
13/04/23 446
La estructura de un esquema Z
Containercontents N
capacity N
contents ^S = capacity
Nombre del esquema Signatura del esquema Predicado del esquema
13/04/23 447
Modelando la bomba de insulina
El esquema Z para la bomba de insulina declara una variedad de variables de estado incluyendo: ¿Las variables de entrada como interruptor? ¿(el
dispositivo interruptor), ¿Depósito de insulina? (la cantidad actual de insulina en el depósito) ¿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).
13/04/23 448
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 La dosis debe ser menor o igual a la capacidad del
depósito de insulina; Ninguna sola dosis puede estar en más 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 restricción de seguridad;
¡display2! muestra la cantidad de insulina a ser entregada.
13/04/23 449
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
13/04/23 450
Invariantes de estador2 = 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 status = error display1! = “Daily dose exceeded”
// 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?
13/04/23 451
El cálculo 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 información sobre la dosis total entregada es mantenida para permitir que la seguridad verifique invariante a ser aplicada.
Nótese que este invariante siempre aplica - No hay ninguna necesidad de repetirlo en el cálculo de la dosificación.
13/04/23 452
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, don’t 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
13/04/23 453
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
13/04/23 454
Esquema de Azúcar 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)
13/04/23 455
Puntos clave La especificación de un sistema formal complementa
las técnicas de la especificación informales. Las especificaciones formales son precisas e
inequívocas. Ellos quitan áreas de duda en una especificación.
La especificación formal fuerza un análisis de los requerimiento del sistema en una fase temprana. La corrección de errores en esta fase es más barata que modificando un sistema entregado.
Las técnicas de especificación formal son más aplicables en el desarrollo de sistemas críticos y estándares.
13/04/23 456
Puntos clave Las técnicas algebraicas están preparadas para
la especificación de una interfaz, dónde la interfaz se define como un conjunto de clases del objetos.
Las técnicas basadas en modelo modelan el sistema usando conjuntos y funciones. Esto simplifica algunos tipos de especificación del comportamiento.
Las operaciones son definidas en una especificación basada en modelo, definiendo pre y post condiciones en el estado del sistema.
13/04/23 457
Diseño arquitectónico
Capítulo 11
13/04/23 458
Objetivos Introducir el diseño arquitectónico y discutir su
importancia Explicar las decisiones del diseño arquitectónico que
deben ser tomadas Introducir tres estilos arquitectónicos
complementarios que cubren la organización, descomposición y control.
Discutir las arquitecturas de referencia que se usan para comunicar y comparar las arquitecturas
13/04/23 459
Tópicos cubiertosDecisiones del diseño arquitectónicoOrganización del sistemaEstilos de descomposiciónEstilos de controlArquitecturas de referencia
13/04/23 460
Arquitectura del softwareEl proceso de diseño para identificar
los sub-sistemas construyendo un sistema y el framework para el control de sub-sistemas y la comunicación es el diseño arquitectónico.
La salida de este proceso de diseño es una descripción de la arquitectura del software.
13/04/23 461
Diseño arquitectónico Una fase temprana del proceso de diseño del
sistema. Representa el eslabón entre la especificación y
procesos del diseño. A menudo se desarrolla en paralelo con algunas
actividades de especificación. Involucra la identificación de los componentes del
sistema mayor y sus comunicaciones.
13/04/23 462
Ventajas de una arquitectura explícita
Comunicación con los Stakeholder La arquitectura puede usarse como un enfoque
de discusión por los stakeholders del sistema. Análisis del sistema
Significa que el análisis de que si el sistema puede reunir sus requerimientos no funcionales, es posible.
Reuso a gran escala La arquitectura puede ser reusable a través de
un rango de sistemas.
13/04/23 463
Arquitectura y características del sistema
Desempeño Localiza las operaciones críticas y minimiza las comunicaciones.
Usa grandes componentes en lugar de los componentes de grano fino.
Seguridad contra delitos Usa una arquitectura de capas con los recursos críticos en las
capas internas. Seguridad física
Localiza los rasgos de seguridad-crítica en un número pequeño de sub-sistemas.
Disponibilidad Incluye componentes redundantes y mecanismos para la
tolerancia de falla. Mantenibilidad
Usa componentes de grano fino, reemplazables.
13/04/23 464
Conflictos arquitectónicos Usando componentes de grano grande mejora el
desempeño pero reduce la mantenibilidad. Introduciendo datos redundantes mejora la
disponibilidad pero realizar la seguridad es más difícil.
La localización de hechos relacionados con la seguridad física normalmente significa más comunicación así como desempeño degradado.
13/04/23 465
Estructuración del sistema
Concerniente con descomponer el sistema en los subsistemas entrelazados.
El diseño arquitectónico normalmente se expresa como un diagrama del bloque que presenta una apreciación global de la estructura del sistema.
La exhibición de más modelos específicos cómo los sub-sistemas comparten datos, son distribuidos y la interfaz con otros también puede desarrollarse.
13/04/23 466
Sistema de control de robot empaquetado
Sistema de Visión
Sistema de Visión
Sistema de identificación
de objetos
Sistema de identificación
de objetos
Controlador de brazo
Controlador de brazo
Controlador de pinza
Controlador de pinza
Controlador de portadorControlador de portador
Sistema de selección de
empaquetamiento
Sistema de selección de
empaquetamiento
Sistema de condensado
Sistema de condensado
13/04/23 467
Diagramas de caja y líneaMuy abstracto - ellos no muestran la
naturaleza de relaciones de componente ni las propiedades visibles externamente de los sub-sistemas.
Sin embargo, es útil para la comunicación con los stakeholders y para la planificación del proyecto.
13/04/23 468
Decisiones del diseño arquitectónico
El diseño arquitectónico 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 diseño.
13/04/23 469
Decisiones del diseño arquitectónico
¿Hay una arquitectura de aplicación genérica que puede usarse?
¿Cómo se distribuirá el sistema ? ¿Qué estilos arquitectónicos son apropiados? ¿Qué aproximación se usará para estructurar el
sistema? ¿Cómo se descompondrá el sistema en módulos? ¿Qué estrategia del control debe usarse? ¿Cómo se evaluará el diseño arquitectónico? ¿Cómo debe documentarse la arquitectura ?
13/04/23 470
Reuso de la arquitectura Los sistemas en el mismo dominio tienen a
menudo arquitecturas similares que reflejan los conceptos del dominio.
Las líneas de producto de aplicación se construyen alrededor de una arquitectura de centro con variantes que satisfacen los requerimientos del clientes particulares.
Las arquitecturas de aplicación se cubren en el Capítulo 13 y líneas de producto en el Capítulo 18.
13/04/23 471
Estilos de Arquitectura El modelo arquitectónico de un sistema puede
conformar un modelo arquitectónico genérico o estilo.
Un conocimiento de estos estilos puede simplificar el problema de definir las arquitecturas del sistema.
Sin embargo, los sistemas más grandes son heterogéneos y no siguen un solo estilo arquitectónico.
13/04/23 472
Modelos arquitectónicos Usados para documentar el diseño arquitectónico. Modelo estructural estático que muestra los componentes
del sistema mayor. Modelo del proceso dinámico 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 distribución que muestra cómo los
subsistemas son distribuidas a través de las computadoras.
13/04/23 473
Organización del sistema
Refleja la estrategia básica que se usa para estructurar un sistema.
Tres estilos organizacionales son usados ampliamente: Un estilo de almacén de datos compartido; Un estilo de servicios compartido y de
servidores; Un estilo de máquina abstracta o capas.
13/04/23 474
Un modelo de almacén Los subsistemas deben intercambiar datos. Esto
puede hacerse de dos maneras: Los datos compartidos se sostienes en una base de
datos central o almacén y pueden ser accedidos por todos los subsistemas;
Cada subsistema mantiene su propia base de datos y pasa los datos explícitamente a otros subsistemas.
Cuando grandes cantidades de datos serán compartidas, el modelo del almacén de datos compartidos es el más comúnmente usado.
13/04/23 475
Arquitectura del conjunto de herramientas CASE
Editor de diseñoEditor de
diseño
Generador de códigoGenerador de código
Analizador de diseñoAnalizador de diseño
Generador de informes
Generador de informes
Traductor de diseñoTraductor de diseño
Editor de programaEditor de programa
Almacén del proyecto
Almacén del proyecto
13/04/23 476
Características del modelo de almacén
Ventajas Manera eficaz de compartir grandes cantidades de datos; Los subsistemas necesitan no ser involucrados cómo datos
producido por gestión Centralizada por ejemplo, copia de respaldo, la seguridad, etc.,
El modelo compartido es publicado como el esquema del almacén.
Desventajas Los subsistemas deben estar de acuerdo a un modelo de
datos de almacén. Inevitablemente un compromiso; La evolución de los datos es difícil y cara; Ningún alcance para las políticas de gestión específicas; Dificultad para distribuir eficazmente.
13/04/23 477
Modelo cliente-servidor Modelo de sistema distribuido que muestra cómo
los datos y procesamiento son distribuidos a través de un rango de componentes.
Conjunto de servidores autosuficientes que proporcionan servicios específicos como imprimir, la gestión de datos, etc.
Conjunto de clientes que llaman a estos servicios.
Red que les permite a los clientes acceder a los servidores.
13/04/23 478
Librería de película y pinturaCliente 1Cliente 1
InternetInternet
Servidor de catálogo
Catálogo de librería
Servidor de catálogo
Catálogo de librería
Cliente 2Cliente 2 Cliente 3Cliente 3 Cliente 4Cliente 4
Servidor de video
Archivos de películas y
clips
Servidor de video
Archivos de películas y
clips
Servidor de pinturas
Gráficos de fotos
digitalizadas
Servidor de pinturas
Gráficos de fotos
digitalizadas
Servidor de Web
Información de fotos y películas
Servidor de Web
Información de fotos y películas
13/04/23 479
Características de cliente-servidor
Ventajas La distribución de datos es sincera; Hace uso eficaz de sistemas conectados a una red de
computadoras. Puede requerir hardware más barato; Fácil para agregar nuevos servidores o actualizar los
servidores existentes. Desventajas
Ningún modelo de datos compartidos para subsistemas usan organización de datos diferentes. El intercambio de datos puede ser ineficaz;
Gestión redundante en cada servidor; Ningún registro central de nombres y servicios - puede
ser difícil averiguar qué servidores y servicios están disponibles.
13/04/23 480
Modelo de máquina abstracta (capas)
Usado por modelar la interfaz de subsistemas. Organiza el sistema en un conjunto de capas (o
máquinas 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, sólo la capa adyacente es afectada.
Sin embargo, a menudo artificial para estructurar sistemas de esta manera.
13/04/23 481
Sistema de gestión de versión
Capa de sistema de gestión de configuraciónCapa de sistema de gestión de configuración
Capa de sistema de gestión de objetosCapa de sistema de gestión de objetos
Capa de sistema de base de datosCapa de sistema de base de datos
Capa de sistema operativoCapa de sistema operativo
13/04/23 482
Estilos de descomposición modular
Estilos de descomponer subsistemas en los módulos.
Ninguna distinción rígida entre la organización del sistema y la descomposición modular.
13/04/23 483
Subsistemas y módulosUn subsistema es un sistema con propio
derecho ,cuyo funcionamiento es independiente de los servicios proporcionados por otros subsistemas.
Un módulo es un componente del sistema que proporciona servicios a otros componentes, pero normalmente no sería considerado como un sistema separado.
13/04/23 484
Descomposición modular Otro nivel estructural dónde subsistemas son
descompuestos en módulos. Dos modelos de descomposición modular cubiertos
Un modelo de objetos dónde el sistema se descompone en objetos interactivos;
Un segmento (pipeline) o modelo de flujo de datos dónde el sistema se descompone en módulos funcionales que transforman las entradas en salidas
Si es posible, las decisiones acerca de concurrencia deben postergarse hasta que se implementen los módulos.
13/04/23 485
Modelo de objetos Estructura el sistema en un conjunto de objetos
débilmente acoplados con interfaces bien definidas.
La descomposición 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 algún modelo de control es usada para coordinar las operaciones de objetos.
13/04/23 486
Sistema de proceso de factura
ClienteNumClienteNombreDirecciónPeriodoCrédito
PagoNumFacturaFechaCantidadNumCliente
FacturaNumFacturaFechaCantidadCliente
Emitir()EnviarRecordatorio()AceptarPago()EnviarRecibo()
ReciboNumFacturaFechaCantidadNumCliente
13/04/23 487
Ventajas del modelo de objetos
Los objetos son débilmente acoplados para que su implementación puede modificarse sin afectar a otros objetos.
Los objetos pueden reflejar las entidades del mundo real.
Los lenguajes de implementación OO son ampliamente usados.
Sin embargo, los cambios de interfaz de objetos pueden causar problemas y las entidades complejas pueden ser difíciles de representar como objetos.
13/04/23 488
Segmentación orientada a función
Las transformaciones funcionales procesan sus entradas para producir salidas.
Pueda ser referida como un tubo y modelo del filtro (como el shell (intérprete de comandos) de UNIX).
Las variantes de esta aproximación 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.
13/04/23 489
Sistema de procesamiento de factura
Leer facturas emitidas
Leer facturas emitidas
Identificar pagos
Identificar pagos
FacturasFacturas PagosPagos
Emitir recibosEmitir recibos RecibosRecibos
Encontrar la deuda de
pagos
Encontrar la deuda de
pagos
Emitir recordatorio
de pagos
Emitir recordatorio
de pagos
RecordatoriosRecordatorios
13/04/23 490
Ventajas del modelo de segmentación
Soporta reuso de transformación. Organización intuitiva para la comunicación de
los stakeholder. Fácil para agregar nuevas transformaciones. Relativamente simple para implementar como o
un sistema coexistente o secuencial. Sin embargo, requiere un formato común para
transferencia de datos a lo largo de la segmentación y difícil para apoyar eventos basados en la interacción.
13/04/23 491
Estilos de control Se preocupan por el flujo del control entre los
subsistemas. Distinto del modelo de descomposición 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.
13/04/23 492
Estilos de control Se preocupan por el flujo del control entre los
subsistemas. Distinto del modelo de descomposición 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.
13/04/23 493
Control centralizado Un subsistema de control toma la responsabilidad por
manejar la ejecución de otros subsistemas. Modelo de retorno de llamada
Modelo de subrutina arriba-abajo donde el control se inicia en la cima de una jerarquía 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 coordinación de otros procesos del sistema. Puede ser implementado en los sistemas secuenciales como un estamento de caso.
13/04/23 494
Modelo de retorno de llamada
Programa principalPrograma principal
Rutina 2Rutina 2Rutina 1Rutina 1 Rutina 3Rutina 3
Rutina 1.1Rutina 1.1 Rutina 1.2Rutina 1.2 Rutina 3.1Rutina 3.1 Rutina 1.2Rutina 1.2
13/04/23 495
Control de sistemas de tiempo real
Controlador del sistema
Controlador del sistema
Procesos de sensor
Procesos de sensor
Procesos de actuados
Procesos de actuados
Procesos de computación
Procesos de computación
Interfaz de usuario
Interfaz de usuario
Manejador de fallas
Manejador de fallas
13/04/23 496
Sistemas manejados por eventos Manejados por eventos externamente generados dónde la
oportunidad del evento es burlar el control de los subsistemas que procesan el evento.
Dos modelos manejados por eventos principales Modelos de emisión. Un evento es la emisión para todos
los subsistemas. Cualquier subsistema que puede manipular el evento puede hacerlo así;
Modelos de manejo de interrupción. Usado en sistemas de tiempo real dónde las interrupciones son descubiertas por un manejador de interrupción y pasados a algún otro componente por procesar.
Otros modelos manejados por eventos incluyen hojas de cálculo y sistemas de producción.
13/04/23 497
Modelos de emisión Eficaz integrando los subsistemas en diferentes
computadoras en una red. Los subsistemas registran un interés en eventos
específicos. Cuando éstos ocurren, el control es transferido al subsistema que puede ocuparse del evento.
La política del control no es incluida en el evento y manejador del mensaje. Los subsistemas deciden en los eventos de interés para ellos.
Sin embargo, los subsistemas no saben si o cuando un evento será manejado.
13/04/23 498
La emisión selectiva
Subsistema 1
Subsistema 1
Manejador de evento y mensajeManejador de evento y mensaje
Subsistema 2
Subsistema 2
Subsistema 3
Subsistema 3
Subsistema 4
Subsistema 4
13/04/23 499
Sistemas de manejador de eventos
Usado en sistemas de tiempo real dónde la rápida respuesta a un evento es esencial.
Hay tipos conocidos de interrupción con un manejador definido para cada tipo.
Cada tipo es asociado con una ubicación de memoria y un interruptor de hardware causa transferencia a su manejador.
Permite contestación rápida pero compleja para programar y difícil de validar.
13/04/23 500
Control de manejador de interrupción
Proceso 1
Proceso 1
Proceso 2
Proceso 2
Proceso 3
Proceso 3
Proceso 4
Proceso 4
Manejador 1
Manejador 1
Manejador 2
Manejador 2
Manejador 3
Manejador 3
Manejador 4
Manejador 4
Interrupciones
Vector de interrupción
13/04/23 501
Arquitecturas de referencia Los modelos arquitectónicos pueden ser específicos para
algún dominio de aplicación. Dos tipos de modelo de dominio específico
Modelos genéricos que son abstracciones de varios sistemas reales y qué encapsulan las características principales de estos sistemas. Cubierto en el Capítulo 13.
Modelos de referencia que son más abstractos, idealizados. Proporcionan unos medios de información sobre esa clase de sistema y de comparación de diferentes arquitecturas.
Los modelos genéricos son normalmente modelos de abajo-arriba; los modelos de referencia son modelos de arriba-abajo.
13/04/23 502
Arquitecturas de referencia Los modelos de la referencia se derivan de un
estudio del dominio de aplicación en lugar de los sistemas existentes.
Puede usarse como una base para la implementación del sistema o para comparar sistemas diferentes. Actúa como una estándar contra la cual pueden evaluarse los sistemas.
El modelo de OSI es un modelo de capas para los sistemas de comunicación.
13/04/23 503
Modelo de referencia OSI
Aplicación
Presentación
Sesión
Transporte
Red
Enlace de datos
Físico
Red
Enlace de datos
Físico
Aplicación
Presentación
Sesión
Transporte
Red
Enlace de datos
Físico
Medios de comunicaciónMedios de comunicación
7
6
5
4
3
2
1
13/04/23 504
Modelo de referencia a caso
Servicios de almacén de datos Almacenamiento y gestión de ítems de datos.
Servicios de integración de datos Grupos de gerencia de entidades.
Servicios de gestión de tareas Definición y presentación de modelos de proceso.
Servicios de mensajería Comunicación herramienta-herramienta y herramienta-
entorno. Servicios de interfaz de usuario
Desarrollo de interfaz de usuario.
13/04/23 505
El modelo de referencia ECMA
Toolslots
Messageservices
Task management services
User interface services
Data repository services
Data integration services
Servicio de interfaz de usuario
Servicio de interfaz de usuarioServicio de
mensaje
Servicio de almacén de datos
Servicio de integración de datos
Ranura de herramientas
13/04/23 506
Modelos arquitectónicosDiferentes modelos arquitectónicos
pueden ser producidos durante el proceso de diseño.
Cada modelo presenta diferentes perspectivas en la arquitectura
13/04/23 507
Atributos de la arquitectura
Desempeño Localiza operaciones para minimizar la comunicación de
subsistemas. Seguridad contra delitos
Usa una arquitectura de capas con recursos críticos en las capas internas.
Seguridad física Aislar los componentes de seguridad física críticos.
Disponibilidad Incluye componentes redundantes en la arquitectura.
Mantenibilidad Usar componentes de grano fino y autocontenidos.
13/04/23 508
Puntos clave Los modelos de descomposición modular
incluyen a los modelos de objetos y modelos de segmentación.
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 específico y para evaluar y comparar los diseños arquitectónicos.
13/04/23 509
Arquitecturas de Sistemas
Distribuidos
Capítulo 12
13/04/23 510
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 están debajo de los estándares CORBA Introducir las arquitecturas par-a-par y orientadas a
servicios como los nuevos modelos de computación distribuida.
13/04/23 511
Tópicos cubiertosArquitecturas multiprocesador Arquitecturas cliente-servidorArquitecturas distribuidas a objetosComputación inter-organizacional
13/04/23 512
Sistemas distribuidos Virtualmente todos los grandes sistemas
basados en computadora son ahora sistemas distribuidos.
El proceso de información es distribuido sobre varias computadoras en lugar de estar confinada a una sola máquina.
La ingeniería de software es, por consiguiente, muy importante para sistemas de computación empresariales.
13/04/23 513
Tipos de sistemas Sistemas personales que no son distribuidos y que
se diseñan para ejecutarlos en una computadora personal o estación de trabajo.
Sistemas empotrados que ser ejecutados en un solo procesador o en un grupo integrado de procesadores.
Sistemas distribuidos dónde el software del sistema se ejecuta en un grupo débilmente integrado de procesadores cooperativos ligados por una red.
13/04/23 514
Características de sistemas distribuidos
Recursos compartidos Compartiendo recursos de hardware y software.
Franqueza Uso de equipos y software de diferentes vendedores.
Concurrencia Procesamiento concurrente para reforzar el desempeño.
Escalabilidad Crecimiento de volumen procesado agregando nuevos
recursos. Tolerancia de fallas
La habilidad para continuar en operación, después de que ha ocurrido una falla.
13/04/23 515
Desventajas de sistemas distribuidos
Complejidad Típicamente, los sistemas distribuidos son más
complejos que los sistemas distribuidos. Seguridad física
Más susceptible al ataque externo. Manejabilidad
Más esfuerzo requerido para la gestión de sistemas. impredecibilidad
Respuestas imprevisibles que dependen de la organización del sistema y la carga de red.
13/04/23 516
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 distinción entre clientes y servidores.
Cualquier objeto en el sistema puede proporcionar y puede usar los servicios de otros objetos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 517
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 comunicación.
13/04/23 518
Arquitecturas multiprocesador
Modelo de sistema distribuido más simple. Sistema compuesto de múltiples procesadores
que pueden (pero no necesariamente) ejecutar en diferentes procesadores.
Modelo arquitectónico de muchos grandes sistemas de tiempo real.
La distribución de procesos a procesadores puede ser presolicitado o puede estar bajo el control de un distribuidor.
13/04/23 519
Un sistema de control de tráfico multiprocesador
Proceso de control
de proceso
Proceso de
visualizar
Proceso de control
de luz
Procesador de sensor
Procesador de flujo de
tráfico
Procesador de control de luz de tráfico
Sensores de flujo de tráfico y
cámarasConsolas de
operadorLuces de
tráfico
13/04/23 520
Arquitectura cliente-servidor
La aplicación 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 lógicos. La correspondencia de procesadores a procesos
no necesariamente es 1: 1.
13/04/23 521
Un sistema cliente-servidor
Proceso servidor
Proceso cliente
a1a1
a2a2 a3a3
a4a4c1c1
c2c2 c3c3 c4c4
c5c5
c6c6c7c7
c8c8
c9c9
c10c10
c11c11
c12c12
13/04/23 522
Computadoras en una red C/S
Computadora servidor
Computadora cliente
SC1SC1SC2SC2
CC1
CC1
CC2
CC2
CC3
CC3
CC4
CC4
CC5
CC5
CC6
CC6
c1 c2 c3, c4
s3, s4
c10, c11, c12c8, c9c5, c6, c7
s1, s2 Red
13/04/23 523
Arquitectura de aplicación de capas
Capa de presentación Tiene relación con la presentación de los resultados de un
cómputo a los usuarios del sistema y con las entradas de usuario colectivas.
Capa de procesamiento de aplicación Tiene relación con proporcionar a la aplicación la
funcionalidad específica, por ejemplo, en un sistema bancario, funciones de banca como abrir cuenta, cerrar cuenta, etc.
Capa de gestión de datos Tiene relación con manejar las bases de datos del sistema.
13/04/23 524
Capas de aplicaciónCapa de
presentaciónCapa de
presentación
Capa de procesamiento de aplicación
Capa de procesamiento de aplicación
Capa de gestión de bases de datos
Capa de gestión de bases de datos
13/04/23 525
Clientes delgados y gruesos
Modelo de cliente delgado En un modelo de cliente delgado, todo el proceso de
la aplicación y la gestión de datos se lleva a cabo en el servidor. El cliente es absolutamente responsable para ejecutar el software de la presentación.
Modelo de cliente grueso En este modelo, el servidor es sólo es responsable de
la gestión de datos. El software en el cliente implementa la lógica de la aplicación y las interacciones con el usuario del sistema.
13/04/23 526
Clientes delgados y gruesos
Gestión de datos
Procesamiento de aplicación
Gestión de datos
Presentación
Presentación
Procesamiento de aplicación
ClienteCliente
ClienteCliente
Modelo de cliente delgado
Modelo de cliente grueso
Servidor
Servidor
13/04/23 527
Modelo de cliente delgado Usado cuando se emigran los sistemas
legados a las arquitecturas cliente -servidor. El sistema legado actúa como un servidor
con derecho propio con una interfaz gráfica implementada en un cliente.
Una desventaja mayor es que pone una carga de proceso pesada en el servidor y en la red.
13/04/23 528
Modelo de cliente grueso
Más procesamiento es delegado al cliente tal como el procesamiento de aplicación que es localmente ejecutada .
Más conveniente para nuevos sistemas C/S dónde las capacidades del sistema del cliente son conocidas de antemano.
Más complejo que un modelo cliente delgado sobre todo para la gestión. Las nuevas versiones de la aplicación tienen que ser instaladas en todos los clientes.
13/04/23 529
Un sistema de CA cliente-servidor
Monitor de teleproceso
Base de datos de
cuenta del cliente
CACA
CACA
CACA
CACA
Servidor de cuenta
13/04/23 530
Arquitectura de 3 pisos En una arquitectura del tres pisos, cada uno de
las capas de arquitectura de aplicación puede ejecutarse en un procesador separado.
Permite el mejor desempeño que una aproximación a cliente delgado y es más simple de manejar que una aproximación a cliente grueso.
Una arquitectura más escalable - ya que al aumento de demandas, pueden agregarse los servidores extras.
13/04/23 531
Una arquitectura de 3 pisos C/S
Gestión de datosProcesamiento de aplicación
ClienteCliente
Presentación
ServidorServidor
13/04/23 532
Un sistema bancario por Internet
Base de datos de cuenta del
cliente
SQLProvisión de servicio de
cuenta
ClienteCliente
ClienteCliente
ClienteCliente
ClienteCliente
Consulta SQL
Interacción HTTP
Servidor de base de datosServidor WEB
13/04/23 533
Uso de arquitecturas C/S
Arquitectura AplicacionesArquitectura de dos pisos C/S con clientes delgados
Las aplicaciones de sistema legado, dónde la separación del proceso de aplicación y la gestión de datos es impráctica. Las aplicaciones computacionalmente intensivas como los compiladores con pequeño o ninguna gestión de datos. Las aplicaciones de datos intensivos (hojeando y preguntando) con pequeño o ningún procesamiento de aplicación.
Arquitectura de dos pisos C/S con clientes gruesos
Aplicaciones dónde el proceso de aplicación es proporcionado por el software disponible en stock (por ejemplo Microsoft Excel) en el cliente. Las aplicaciones dónde el proceso computationalmente intensivo de datos (por ejemplo el visualización de datos) es requerido. Las aplicaciones con funcionalidad de usuario final relativamente estable usadas en un ambiente con gestión del sistema bien establecida.
Arquitectura de tres pisos o multipisos C/S
Aplicaciones de gran escala con centenares o miles de clientes Aplicaciones dónde los datos y la aplicación son volátiles. Aplicaciones dónde se integran datos de fuentes múltiples.
13/04/23 534
Arquitectura de objetos distribuidos
No hay ninguna distinción 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 comunicación de objetos es a través de un sistema middleware llamado un agente de demanda de objeto.
Sin embargo, las arquitecturas de objeto distribuidos son más complejas de diseñar que los sistemas C/S.
13/04/23 535
Arquitectura de objetos distribuidos
S(o1)
o1
S(o2)
o2
S(o3)
o3
S(o4)
o4
S(o5)
o5
S(o6)
o6
Agente de demanda de objetoAgente de demanda de objeto
13/04/23 536
Ventajas de la arquitectura de objetos distribuidos
Permite al diseñador del sistema retardar las decisiones sobre dónde y cómo 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 dinámicamente con
objetos que emigran a través de la red cuando son requeridos.
13/04/23 537
Usos de la arquitectura de objetos distribuidos
Como un modelo lógico que le permite estructurar y organizar el sistema. En este caso, se piensa sobre cómo proporcionar la funcionalidad de la aplicación solamente en términos de servicios y combinaciones de servicios.
Como una aproximación flexible a la aplicación de sistemas cliente-servidor. El modelo lógico del sistema es un modelo cliente-servidor pero clientes y servidores se comprenden como objetos distribuidos que comunican a través de un framework de comunicación común.
13/04/23 538
Un sistema de minería de datos
Bases de datos 1
Bases de datos 2
Bases de datos 3
Generador de informes
Visualizador
Desplegador
Integrador 1
Integrador 2
13/04/23 539
Sistema de minería de datos
El modelo lógico del sistema no es ninguna provisión de servicio dónde hay servicios de gestión 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 extraídos agregando nuevos objetos del integrador.
13/04/23 540
CORBA CORBA (Common Object Request Broker Architecture) es
un estándar internacional para para un Agente de Demanda de Objeto - el middleware para manejar las comunicaciones entre los objetos distribuidos.
El middleware para la computación distribuida es requerida en 2 niveles: Al nivel de comunicación lógico, el middleware permite
a objetos de computadoras diferentes intercambiar datos e información de control;
Al nivel de componentes, el middleware proporciona una base para el desarrollo de componentes compatibles. Los estándares de componentes CORBA han sido definidos.
13/04/23 541
Estructura de aplicación CORBA
Agente de demanda de objetoAgente de demanda de objeto
Servicios CORBAServicios CORBA
Objetos de aplicación
Objetos de aplicación
Dominio de recursos
Dominio de recursos
Recursos de CORBA horizontal
Recursos de CORBA horizontal
13/04/23 542
Estructura de aplicación Objetos de la aplicación. Objetos estándar, definidos por el OMG, para un
dominio específico, por ejemplo: seguro. Servicios de CORBA fundamental tales como
directorios y gestión de seguridad contra delitos. Horizontal (es decir cortando a través de las
aplicaciones) los recursos tales como los recursos de interfaz de usuario.
13/04/23 543
Estándares CORBA Un modelo de objetos para objetos de la aplicación
Un objeto CORBA es un encapsulamiento de estado bien definido, la interfaz de un lenguaje neutral definido en un IDL (Lenguaje de definición 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.
13/04/23 544
Objetos CORBA Los objetos CORBA son comparables, en
principios, a objetos en C++ y Java. Ellos DEBEN tener una definición separada de la
interfaz que se expresa usando un lenguaje común (IDL) similar a C++.
Hay una correspondencia de este IDL a los lenguajes de programación (C++, Java, etc.).
Por consiguiente, objetos escritos en diferentes lenguajes pueden comunicarse entre sí.
13/04/23 545
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 talón de IDL que define la interfaz del objeto.
Llamando estos resultados del talón en las llamadas al ORB que entonces llama al objeto requerido a través de un esqueleto de IDL publicado que une la interfaz a la aplicación de servicio.
13/04/23 546
Comunicaciones de objeto basados en ORB
S(o1)
o1
S(o2)
o2
Agente de demanda de objetoAgente de demanda de objeto
Talón de IDL
Talón de IDL
Esqueleto de IDL
Esqueleto de IDL
13/04/23 547
Comunicaciones Inter-ORB Los ORB no son los programas normalmente, pero
son un conjunto de objetos en una biblioteca que se une con una aplicación cuando se desarrolla.
Los ORB manejan comunicaciones entre objetos que se ejecutan en la máquina 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.
13/04/23 548
Comunicaciones Inter-ORB
S(o1)
o1
S(o2)
o2
Agente de demanda de objeto
Agente de demanda de objeto
Talón de IDL
Talón de IDL
Esqueleto de IDL
Esqueleto de IDL
S(o3)
o3
S(o4)
o4
Agente de demanda de objeto
Agente de demanda de objeto
Talón de IDL
Talón de IDL
Esqueleto de IDL
Esqueleto de IDL
Red
13/04/23 549
Servicios CORBA Nombrando y traficando servicios
Éstos permiten a los objetos descubrir y referirse a otros objetos en la red.
Servicios de notificación Éstos permiten a los objetos notificar a otros objetos
que un evento ha ocurrido. Servicios de transacción
Estos apoyan transacciones atómicas y reducción en fallas.
13/04/23 550
Computación inter-organizacional
Por razones de seguridad contra delitos y de interoperatividad, más computación distribuida se ha implementado a nivel de empresa.
Estándares locales, gestión y aplicar procesos operacionales.
Nuevos modelos de computación distribuida han sido diseñados para apoyar computación inter-organizacional donde se localizan nodos diferentes en organizaciones diferentes.
13/04/23 551
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 diseña para tomar ventaja del poder computacional y almacenamiento de un número grande de computadoras conectadas a una red.
La mayoría de los sistemas p2p han sido sistemas personales pero hay uso creciente de esta tecnología.
13/04/23 552
Modelos arquitectónicos p2p La arquitectura de red lógica
Arquitecturas descentralizadas; Arquitecturas semicentralizadas.
Arquitectura de aplicación La organización genérica de componentes que
constituyen una aplicación p2p. Enfocar aquí las arquitecturas de red.
13/04/23 553
Arquitectura p2p descentralizada
n1n1
n2n2 n3n3
n4n4 n5n5
n8n8
n6n6
n7n7
n9n9 n10
n10
n14n14
n13
n13
n12
n12
n11n11
13/04/23 554
Arquitectura p2p descentralizada
n1n1
n2n2 n3n3
n4n4 n5n5
n8n8
n6n6
n7n7
n9n9 n10
n10
n14n14
n13
n13
n12
n12
n11n11
13/04/23 555
Arquitectura p2p semicentralizada
n1n1
n3n3
n2n2 n5n5
n6n6
n4n4
Servidor de descubrimiento
Servidor de descubrimiento
13/04/23 556
Arquitectura orientada al servicio
Basada alrededor de la noción de servicio provisto externamente (servicios de la Web).
Un servicio de la Web es una aproximación estándar para hacer un componente reusable disponible y accesible a través de la Web.
Un servicio de limado de impuesto podría proporcionar soporte a los usuarios para llenar sus formularios de impuesto y someter éstos a las autoridades de impuestos.
13/04/23 557
Un servicio genérico Un acto o desempeño ofrecidos por una fiesta
para otro. Aunque el proceso puede atarse a un producto físico, la actuación es esencialmente intangible y normalmente no resulta en propiedad de cualquiera de los factores de producción.
La provisión de servicio es por consiguiente independiente de la aplicación que usa el servicio.
13/04/23 558
Servicios de la Web
Registro de
servicio
Registro de
servicio
Demandador de
servicio
Demandador de
servicio
Proveedor de
servicios
Proveedor de
servicios
Buscar Publicar
Enlazar
13/04/23 559
Servicios y objetos distribuidos Independencia del proveedor. Publicidad pública de disponibilidad de
servicio. Potencialmente, ligadura de servicio de tiempo
de ejecución. Construcción oportuna de nuevos servicios a
través de la composición. Pago por el uso de servicios. Pequeñas, aplicaciones más compactas. Aplicaciones reactivas y adaptables.
13/04/23 560
Estándares de servicios Los servicios están basado en estándares convenidos basados
en XML para que puede ser proporcionados en cualquier plataforma y pueden escribirse en cualquier lenguaje de programación.
Estándares cales SOAP - Simple Object Access Protocol = Protocolo de
acceso a objeto simple; WSDL - Web Services Description Language = Lenguaje de
descripción de servicios de la Web; UDDI - Universal Description, Discovery and Integration =
Descripción universal, Descubrimiento e integración.
13/04/23 561
Escenario de servicios Un sistema de información en automóvil
proporciona información a chóferes sobre el tiempo, las condiciones de tráfico del camino, información local, etc. Esto se une a la radio del automóvil para que se entregue la información como una señal en un canal específico de la radio.
El automóvil está provisto con un receptor GPS para descubrir su posición y, basado en esa posición, el sistema accede un rango de servicios de información. La información puede ser entregada en el lenguaje especificado del chofer.
13/04/23 562
Sistema automotor
Recibe información de
servicios
Receptor
Envía posición e información
requerida para servicios
Transmisor
Recibe demanda para
usuario
Interfaz de usuario
Traduce flujos de información digital a señal
de radio
Radio
Descubre posición del
carro
Localizador
Ensamblar información
Servicio de información móvil
Halla servicios disponibles
Descubrimiento de servicio
Información de tráfico del camino
Localizador de
camino
Localizador de
camino
Información de
tráfico
Información de
tráfico
TraductorTraductor
Información de recursosInformación
de recursosInformación de tiempoInformación
de tiempo
Flujo de información
Información de lenguaje
Comando de coordenadas GPS
Coordenadas GPS
Coordenadas GPS
Coordenadas GPS
13/04/23 563
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 gestión de datos en el servidor. La funcionalidad de la aplicación puede estar en el cliente o en el servidor.
En la arquitectura de objetos distribuidos no hay diferencia entre clientes y servidores.
Puntos clave
13/04/23 564
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 estándares CORBA son un conjunto de estándares middleware que soportan arquitecturas de objetos distribuidos.
La arquitecturas par a par son arquitecturas descentralizadas donde no hay distinción entre clientes y servidores.
Los sistemas orientados a servicios son creados por enlace de servicios proporcionados por diferentes proveedores de servicios.
13/04/23 565
Arquitecturas de aplicación
Capítulo 13
13/04/23 566
Objetivos Explicar la organización de dos modelos
fundamentales de sistemas comerciales -proceso por lotes y sistemas de procesamiento de transacción
Describir la arquitectura abstracta de sistemas de gestión de recurso
Explicar cómo los editores genéricos son sistemas de procesamiento de eventos
Describir la estructura de sistemas de procesamiento de lenguajes
13/04/23 567
Tópicos cubiertosSistemas de procesamiento de datosSistemas de procesamiento de
transacción Sistemas de procesamiento de
eventosSistemas de procesamiento de
lenguaje
13/04/23 568
Arquitecturas de aplicación genérica
Los sistemas de la aplicación son diseñados para satisfacer una necesidad organizacional.
Cuando los negocios tienen mucho en común, sus sistemas de aplicación también tienden a tener una arquitectura común, que refleja los requerimientos de la aplicación.
Una arquitectura genérica es configurada y adaptada para crear un sistema que reúne los requerimientos específicos.
13/04/23 569
Uso de arquitecturas de aplicación
Como un punto de partida para el diseño arquitectónico
Como una lista de control del diseño. Como una manera de organizar el trabajo del
equipo de desarrollo. Como una manera de organizar el trabajo del
equipo de desarrollo. Como un vocabulario para hablar sobre los tipos
de aplicación.
13/04/23 570
Tipos de aplicación Aplicaciones de procesamiento de datos
Aplicaciones de manejo de datos que procesan los datos en lotes sin la intervención explícita del usuario durante el proceso.
Aplicaciones de procesamiento de transacción Aplicaciones de datos centrados que procesan pedidos de usuario
y actualizan la información en una base de datos del sistema. Sistemas de procesamiento de evento
Aplicaciones dónde las acciones del sistema dependen de interpretar los eventos del ambiente del sistema.
Sistemas de procesamiento de lenguaje Aplicaciones dónde las intenciones de los usuarios son
especificadas en un lenguaje formal que es procesado e interpretado por el sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 571
Ejemplo de tipos de aplicación
Sistemas de procesamiento de datos Sistema de cargo de cuenta; Sistemas de nómina.
Sistemas de procesamiento de transacción Sistemas de comercio electrónico; Sistemas de reservación.
Sistemas de procesamiento de evento Procesadores de palabra; Sistemas de tiempo real.
Sistemas de procesamiento de lenguaje Compiladores; Intérpretes de comandos.
13/04/23 572
Sistemas de procesamiento de datos
Sistemas que son centrados de datos donde las bases de datos usadas son normalmente ordenes de magnitud más grande que el propio software.
Los datos tienen entrada y salida por lotes Entrada: Un conjunto de números de cliente y
lecturas asociadas de un medida de electricidad; Salida: Un conjunto correspondiente de factura, uno
por cada número de cliente. Sistemas de procesamiento de datos que normalmente
tienen una estructura de entrada-proceso-salida.
13/04/23 573
Modelo entrada-proceso-salida
Sistema Sistema
EntradaEntrada ProcesoProceso Salida Salida
Base de datos Base de datos
Impresora
13/04/23 574
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 válidos por procesar.
El componente de proceso toma una transacción de la cola (entrada), realiza los cómputos y crea un nuevo registro con los resultados del cómputo.
El componente de salida lee estos archivos, los estructura de acuerdo con un formato y los escribe para la base de datos o los envía a una impresora.
13/04/23 575
Diagramas de flujo de datos
Muestra cómo los datos son procesados y como se mueven a través de un sistema.
Las transformaciones se representan como rectángulos de bordes redondo, los flujos de datos como flechas entre ellos y el los archivos de datos como rectángulos.
13/04/23 576
DFD de pago de salarioRegistros de empleadosRegistros de
empleados
Leer registro de empleadoLeer registro
de empleado
Leer datos de pago mensualLeer datos de
pago mensual
Datos de pago mensualDatos de pago
mensual
Validar datos de empleadoValidar datos
de empleado
Información de pago
Registro de empleado descifrado
Tasas de pago mensualTasas de pago
mensual
Tabla de impuestosTabla de
impuestos
calcular salariocalcular
salario
Registro de empleado válido
Escribir transacciones de impuesto
Escribir transacciones de impuesto
Deducción de impuesto +
Número SS + Oficina de impuesto
Escribir datos de pensiónEscribir datos
de pensiónDeducción de
impuesto + Número SS
Imprimir tira de pagoImprimir tira
de pago
Datos de empleado + deducciones
IMPRESORA
Escribir transacción de
banco
Escribir transacción de
banco
Pago de red +Información de cuenta bancaria
Escribir datos de seguridad
social
Escribir datos de seguridad
social
Deducción de seguridad social +
Número SS Datos de seguridad socialDatos de
seguridad social
Transacciones de bancosTransacciones
de bancos
Datos de pensiónDatos de
pensión
Transacciones de impuestoTransacciones
de impuesto
13/04/23 577
Sistemas de procesamiento de transacciones
Procesa demandas de usuario para información de una base de datos o pide actualizar la base de datos.
Desde una perspectiva del usuario una transacción es: Una secuencia coherente de operaciones que
satisfacen una meta; Por ejemplo – hallar el tiempo de vuelo de Londres a
París. Los usuarios hacen demandas asíncronas para servicios
que son entonces procesados por un gerente de transacción.
13/04/23 578
Procesamiento de transacción
Procesamiento E/S
Procesamiento E/S
Aplicación lógica
Aplicación lógica
Gerente de transacciónGerente de transacción
Base de datos
Base de datos
13/04/23 579
Organización de un sistema CA
Entrada Proceso Salida
CA Base de datos CA
Obtener Id. de cuenta de clienteObtener Id. de
cuenta de cliente
Validar tarjetaValidar tarjeta
Seleccionar servicio
Seleccionar servicio
Consultar cuenta
Consultar cuenta
Actualizar cuenta
Actualizar cuenta
Imprimir detallesImprimir detalles
Devolver tarjeta
Devolver tarjeta
Expender dinero en efectivo
Expender dinero en efectivo
13/04/23 580
Middleware para procesamiento de transacciones
Middleware para gestión 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 envía para procesarlos.
El procesamiento de consultas tiene lugar en la base de datos del sistema y se envían los resultados atrás a través del gerente de transacción al terminal del usuario.
13/04/23 581
Gestión de transacciones
Monitor de teleprocesamiento
Monitor de teleprocesamiento
Base de datos de cuentas
Base de datos de cuentas
Transacciones en serie
CAs y terminales
Consultas y actualizaciones
de cuenta
13/04/23 582
Arquitectura de sistemas de información
Los sistemas de información tienen una arquitectura genérica que puede organizarse como una arquitectura en capas.
Las capas incluyen: La interfaz de usuario Comunicaciones de usuario Recuperación de información Base de datos del sistema
13/04/23 583
Estructura de sistema de información
Interfaz de usuario Interfaz de usuario
Comunicaciones de usuario Comunicaciones de usuario
Recuperación de información y modificaciónRecuperación de información y modificación
Gestión de transacciones
Base de datos Gestión de transacciones
Base de datos
13/04/23 584
Arquitectura LIBSYS El sistema de biblioteca LIBSYS es un ejemplo
de un sistema de información.. Capa de comunicaciones de usuario:
Componente de identificador de LIBSYS; Formulario y gestión de consulta; Gerente de impresora;
Capa de recuperación de información Búsqueda distribuida; Documenta recuperación; Gerente de derechos; Contabilidad.
13/04/23 585
Organización de LIBSYS Interfaz de navegador de la Web Interfaz de navegador de la Web
Índice de libreríaÍndice de librería
Identificación
LIBSYS
Formulario y gerente de consultas
Gerente de impresión
Búsqueda distribuida
Documento de recuperación
ContabilidadGerente de derechos
BD1BD1 BD2BD2 BD3BD3 BD4BD4 BDnBDn
13/04/23 586
Sistema de asignación de recursos
Sistemas que manejan una cantidad fija de algún recurso (boletos del juego del fútbol, libros en una librería, etc.) y asigna estos a los usuarios.
Ejemplos de sistemas de asignación de recursos: Sistemas de cronograma dónde el recurso a
asignarse es un periodo de tiempo; Sistemas de biblioteca dónde el recurso a manejarse
son libros y otros artículos para el préstamo; Sistemas de control de tráfico aéreo dónde el recurso
a manejarse es el espacio aéreo.
13/04/23 587
Arquitectura de asignación de recursos
Sistema de asignación de recursos son también sistemas de capas que incluyen: Una base de datos de recursos; Un conjunto de reglas que describen cómo serán
asignados los recursos; Un gerente de recursos; Un asignador de recursos; Autentificación de usuario; Gestión de consultas; Componente de entrega de recursos; Interfaz de usuario.
13/04/23 588
Asignación de recursos por capas
Interfaz de usuario Interfaz de usuario
Gestión de transacciones
Base de datos de recursos
Gestión de transacciones
Base de datos de recursos
Identificación
De usuario
Entrega de recursos
Gerente de consultas
Gestión de recursos
Control de política de recursos
Asignación de recursos
13/04/23 589
Implementación 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 arquitectónico más comúnmente usado para los sistemas basados en la Web.
En una sola máquina, las capas medias son implementadas como un programa separado que se comunica con la base de datos a través de su API.
Los componentes de grano fino dentro de las capas pueden ser implementadas como servicios de la Web.
13/04/23 590
Arquitectura de sistemas E-Comercio
Los sistemas E-comercio son sistemas de gestión de recursos basados en Internet que acepta ordenes electrónicas para productos o servicios.
Ellos son normalmente organizados una arquitectura multi-piso con capas de aplicación asociadas con cada piso.
Navegador Web
Navegador Web
Servidor Web
Servidor Web
Servidor de aplicación
Servidor de aplicación
Servidor de base de datosServidor de
base de datos
13/04/23 591
Sistemas de procesamiento de eventos Estos sistemas responden a los eventos en el
entorno del sistema. Su característica 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.
13/04/23 592
Sistemas de edición Sistemas de tiempo real (Capítulo 15) y sistemas de
edición son los tipos más comunes de sistemas de procesamiento de eventos.
Características de sistemas de edición: Sistemas de usuario simple; Deba proporcionar la retroalimentación rápida a las
acciones del usuario; Organizado alrededor de grandes transacciones tal
que pueden incluir los recursos de recuperación.
13/04/23 593
Componentes de sistemas de edición
Los sistemas de edición 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; Visualización – actualiza el despliegue por pantalla.
13/04/23 594
Arquitectura de sistemas de edición
Grabar
Abrir
Sistema de archivo
Comandos auxiliares
Datos auxiliares
Comandos de edición
Datos de editor
Actualizar
VisualizaciónInterpretes
Comandos
Procesar
Eventos
Refrescar
Pantalla
13/04/23 595
Sistemas de procesamiento de lenguaje
Acepta un lenguaje natural o artificial como entrada y genera alguna otra representación de ese lenguaje.
Puede incluir un intérprete para actuar en las instrucciones en el lenguaje que está procesándose.
Usado en situaciones dónde la manera más fácil de resolver un problema es describir un algoritmo o describir los datos del sistema Las herramientas meta-casos procesan descripciones
de herramientas, reglas de métodos, etc., y genera las herramientas.
13/04/23 596
Un sistema de procesamiento de lenguaje
Chequea sintaxis
Chequea semántica
Genera
Traductor
Sacar
Extraer
Intérprete
Instrucciones m/c abstracto
Instrucciones m/c abstracto
DatosDatos ResultadosResultados
InstruccionesInstrucciones
13/04/23 597
Componentes de procesamiento de lenguaje
Analizador léxicoTabla de símbolosAnalizador de sintaxisÁrbol de sintaxisAnalizador de sintaxisGenerador de código
13/04/23 598
Compilador de modelo de flujo de datos
Árbol de sintaxis
Tabla de símbolos
Análisis léxico
Análisis léxico
Análisis sintáctico
Análisis sintáctico
Análisis semántico
Análisis semántico
Generador de código
Generador de código
13/04/23 599
Modelo de repositorio de un compilador
Árbol de sintaxis
abstracto
Árbol de sintaxis
abstracto
Definición de gramática
Definición de gramática
Tabla de símbolosTabla de símbolos
Definición de salida
Definición de salida
Impresora bonita
Impresora bonita
EditorEditor
OptimizadorOptimizador
Generador de código
Generador de código
Analizador léxico
Analizador léxico
Analizador sintáctico
Analizador sintáctico
Analizador semántico
Analizador semántico
Depósito
13/04/23 600
Modelos genéricos de arquitecturas de comportamiento nos ayudan a entender y comparar las aplicaciones.
Importantes clases de aplicación son sistemas de procesamiento de datos, sistemas de procesamiento de transacción, 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.
Puntos clave
13/04/23 601
Puntos clave Los sistemas de procesamiento de transacción
permite información en una base de datos a ser accedida remotamente y modificada por múltiples usuarios.
Los sistemas de procesamiento incluye editores y sistemas de tiempo real.
En un editor, eventos de interfaz de usuario son detectadas y un estructura de datos en almacén es modificada.
Los sistemas de procesamiento de lenguaje traducen textos desde un lenguaje a otro y puede interpretar las instrucciones específicas.
13/04/23 602
Diseño orientado a objetos
Capítulo 14
13/04/23 603
Objetivos Explicar como un diseño 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 diseño orientado a objetos
Introducir varios modelos que pueden ser usados para describir el diseño orientado a objetos
Mostrar como el UML puede ser usado para representar esos modelos
13/04/23 604
Tópicos cubiertosObjetos y clases de objetos Un proceso de diseño orientado a
objetosEvolución del diseño
13/04/23 605
Desarrollo orientado a objetos
El análisis orientado a objetos, el diseño orientado a objetos y la programación están relacionadas pero son distintas.
El AOO se preocupa por desarrollar un modelo de objetos del dominio de la aplicación.
El DOO se preocupa por desarrollar un modelo de sistema orientado a objetos para implementar los requerimientos.
La POO se preocupa por la realización de un DOO usando un lenguaje de programación OO tal como Java o C++.
13/04/23 606
Los objetos son abstracciones del mundo real o entidades del sistema y se manejan así mismos.
Los objetos son independientes y encapsulan estado y representación de información.
La funcionalidad del sistema es expresada en términos 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.
Características del DOO
13/04/23 607
Objetos interactuando
Operaciones1()
o1:C1
Estado de o1
o3:C3
Estado de o3
o4:C4
Estado de o4
o2:C3
Estado de o2
o6:C1
Estado de o6
o5:C5
Estado de o5
Operaciones3() Operaciones4()
Operaciones3() Operaciones1() Operaciones5()
13/04/23 608
Ventajas del DOOFácil 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.
13/04/23 609
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.
13/04/23 610
Objetos y clases de objetosUn 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 algún cómputo es requerido.
Los objetos son creados de acuerdo a alguna definición de clase de objeto. Una definición 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.
13/04/23 611
El Lenguaje de Modelamiento Unificado
Varias notaciones diferentes parar describir los diseños orientados a objetos han sido propuestos en los 1980 y 1990.
El Lenguaje de Modelamiento Unificado es una integración de esas notaciones.
Describe las notaciones para una variedad de diferentes modelos que pueden producirse durante el análisis y diseño OO.
Actualmente es un estándar de facto para el modelado OO.
13/04/23 612
Clase de objeto Empleado (UML)
EmpleadoNombre : StringDirección : StringFechaNacimiento : DateNumEmpleado : IntegerNumSeguroSocial : StringDepartamento : StringCargo : StringSalario : CurrencyEstado : StringCodigoImpuesto : Integer
Alta()Baja()Retirar()CambiarDetalle()
13/04/23 613
Comunicación 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 información requerida para ejecutar el servicio y el nombre de un titular para el resultado del servicio.
En la práctica, los mensajes son a menudo implementados por llamamiento a procedimientos Nombre = nombre del procedimiento; Información = lista de parámetros.
13/04/23 614
Ejemplos de mensaje// Llamada a un método asociado con un objeto //buffer (memoria intermediaria) que devuelve un próximo valor en el //buffer
v = circularBuffer.Get () ;
// Llamada a un método asociado con un objeto // termostato que pone la temperatura a ser // mantenida
thermostat.setTemp (20) ;
13/04/23 615
Generalización y herencia Los objetos son miembros de clases que definen tipos
de atributo y operaciones. Las clases pueden ser colocadas en una jerarquía de
clases donde una clase (una super-clase) es una generalización de una o más clases (sub-clases).
Una sub-clase hereda los atributos y operaciones desde una super clase y puede agregar nuevos métodos o atributos a si mismo.
La generalización in el UML es implementado como herencia en los lenguajes de programación OO.
13/04/23 616
Una herencia de generalizaciónEmpleado
GerentePresupuestosControladosFechaFijada
ProgramadorProyectosLenguajeProg
GerenteProyectoProyectos
GerenteDeptoDepto
GerenteEstratégicoResponsabilidades
13/04/23 617
Ventajas de herenciaEs un mecanismo de abstracción que
puede usarse para clasificar las entidades.Es un mecanismo de reuso en el nivel de
diseño y programación.El gráfico de herencia es una fuente de
conocimiento organizacional sobre los dominios y sistemas.
13/04/23 618
Problemas con la herencia Las clases del objeto no son autocontenidas.
Ellas no pueden ser entendidas sin la referencia a sus super-clases.
Los diseñadores tienen la tendencia a reusar los gráficos de herencia creados durante el análisis. Puede llevar a la ineficacia significativa.
Los gráficos de herencia del análisis, diseño e implementación tienen diferentes funciones y serán separadamente mantenidas.
13/04/23 619
Asociaciones UML Los objetos y clases de objetos participan en
interrelaciones con otros objetos y clases de objetos.
En el UML, una interrelación generalizada es indicada por una asociación.
Las asociaciones pueden ser notadas con información que describe la asociación.
Las asociaciones son generales pero pueden indicar que un atributo de un objeto es un objeto asociado o que un método cuenta en un objeto asociado.
13/04/23 620
Un modelo de asociación
DepartamentoEmpleado
Gerente
Es_miembro_de
+Es_dirigido_por
+Dirige
13/04/23 621
Objetos concurrentesLa naturaleza de objetos como las
entidades autónomas los hace convenientes para la implementación concurrente.
El modelo de pase de mensajes de comunicación de objeto puede ser directamente implementada si los objetos están corriendo en procesadores separados en un sistema distribuido.
13/04/23 622
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.
13/04/23 623
Objeto repetidor activo Los objetos activos puede tener sus atributos
modificados por operaciones pero ellos también pueden ser actualizados autónomamente usando operaciones internas.
Un objeto repetidor transmite la posición de un avión. La posición puede ser actualizada usando el sistema de posesionamiento de satélite. El objeto actualiza periódicamente por la triangulación de los satélites.
13/04/23 624
Un objeto repetidor activoclass 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
13/04/23 625
Hilos Java Los hilos (threads) en Java son un
constructores simples para implementar objetos concurrentes.
Los hilos pueden incluir a un método llamado run() y este es iniciado por un sistema Java run-time (ejecución).
Los objetos activos típicamente incluyen un bucle infinito para que ellos siempre estén llevando a cabo el cómputo.
13/04/23 626
Proceso de diseño orientado a objeto
Los procesos de diseño 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 pequeños, esto puede ser no rentable.
Sin embargo para grandes sistemas desarrollados por diferentes grupos diseñar modelos es un mecanismo esencial de comunicación.
13/04/23 627
Fases del proceso Los rasgos salientes codifican las actividades a
menos que atándose para cualquier proceso propietario como el RUP. Define el contexto y modos de uso del sistema; Diseño de la arquitectura del sistema; Identificar los principales objetos del sistema; Desarrollar modelos de diseño; Especificar interfaces de objetos.
13/04/23 628
Descripción 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 satélites. Las estaciones de tiempo transmiten sus datos a la computadora del área en respuesta a una demanda de esa máquina.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 distribución en una impresora de propósito especial o pueden desplegarse en varios formatos diferentes.
13/04/23 629
Contexto del sistema y modelos de uso
Desarrollar una comprensión de la interrelaciones entre el software el software a ser diseñado y su entorno externo
Contexto del sistema Un modelo estático 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 estación de tiempo.
Modelo de uso del sistema Un modelo dinámico que describe como el sistema
interactúa con el entorno. Usa casos de uso para mostrar interacciones.
13/04/23 630
Arquitectura de capas
La capa de procesamiento donde los objetos se preocupan con la recisión e integración de los datos recolectados.
Despliegue de datos
<<subsystem>>
Archivamiento de datos
<<subsystem>>
Procesamiento de datos
<<subsystem>>
Recolección de datos
<<subsystem>>
La capa de despliegue de datos donde los objetos se preocupan con la preparación y presentación 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 recolección de datos donde los objetos se preocupan con la adquisición de datos desde fuentes remotas.
13/04/23 631
Subsistemas en el sistema correspondencia en el tiempo
Recolección de datos<<subsystem>>
Despliegue de datos<<subsystem>>
Procesamiento de datos<<subsystem>> Archivamiento de datos
<<subsystem>>
Observador Satélite
Estación de tiempo
Globo
Revisión de datos
Integración de datos
Almacenamiento de datos
Almacen de mapas
Almacen de datos
Comandos
Interfaz de usuario
Despliegue de mapa
Mapa Impresora de mapa
13/04/23 632
Modelos de casos de uso
Los modelos de casos de uso son usados para representar cada interacción con el sistema.
Un modelo de caos de uso muestran los hechos del sistema como elipses y las entidades como una figura de palo.
13/04/23 633
Casos de uso para la estación de tiempo
Iniciar
Cerrar
Informe
Calibración
Pruebas
13/04/23 634
Descripción de un casos de uso
Sistema Estación de tiempo.
Casos de uso Informe.
Actores Sistema de colección de datos de tiempo. Estación de tiempo.
Datos La estación de tiempo envía un resumen de los datos de tiempo que han sido reunidos de los instrumentos en el periodo de la recolección para el sistema de recolección de datos del tiempo. Los datos enviados son el mínimo máximo y promedio de temperaturas de tierra y aire, el máximo, mínimo y promedio de presiones atmosféricas, el máximo, el mínimo y el promedio de aceleración del viento, la lluvia total y la dirección del viento como muestras de intervalos de 5 minutos.
Estímulos El sistema de recolección de datos del tiempo datos establece un módem de enlace con la estación del tiempo y transmisión de demandas de los datos.
Respuestas Los datos resumidos se envían al sistema de recolección de datos.
Comentarios Las estaciones de tiempo normalmente interrogadas para informar una vez por hora pero esta frecuencia puede diferir de una estación a otra y puede modificarse en el futuro.
13/04/23 635
Diseño arquitectónico Una vez que las interacciones entre el sistema y su
ambiente se han entendido, se usa esta información por diseñar la arquitectura del sistema.
Una arquitectura de capas como la discutida en el Capítulo 11 es apropiado para la estación de tiempo Capa de interfaz para manejar las
comunicaciones; Capa de recolección de datos pata instrumentos de
manejo; Capa de instrumento para la recolección de datos.
Debe haber normalmente no más de 7 entidades en un modelo arquitectónico.
13/04/23 636
Arquitectura de estación de tiempo
Estación de tiempo
Interfaz<<subsystem>>
Recolección de datos
<<subsystem>>
Instrumentos<<subsystem>>
Maneja todas las comunicaciones externas.
Recolecta y compendia todos los datos dl tiempo.
Paquete de instrumentos de recolección de datos crudos.
13/04/23 637
Identificación de objetosLa identificación de objetos (o clases de
objetos) es la parte más difícil del diseño orientado a objetos.
No hay “formula mágica” para la identificación de objetos. Se confía en la habilidad, experiencia y conocimiento del dominio de los diseñadores del sistema.
La identificación de objetos es un proceso iterativo. La identificación del objeto es un proceso iterativo. Es improbable corregir el tiempo primero.
13/04/23 638
Aproximaciones para la identificación
Usar una aproximación gramatical basada en una descripción del sistema en lenguaje natural (usada en el método Hood de DOO).
Basa la identificación en las cosas tangibles en el dominio de la aplicación.
Usa una aproximación del comportamiento e identifica objetos basados en qué participa en qué comportamiento.
Usar el análisis basado en escenario. Los objetos, atributos y métodos en cada escenario son identificados.
13/04/23 639
Descripción de una estación de tiempo
Una estación de tiempo es que un paquete de software que controla instrumentos que recoleccionan datos, realiza algunos procesamientos de datos y transmite este datos más allá del procesamiento. Los instrumentos incluyen termómetros de aire y tierra, un anemómetro, una veleta del viento, un barómetro y un medidor de lluvia. Los datos son periódicamente recolectados.
Cuando un comando es emitido para transmitir los datos de tiempo, lla estación de tiempo procesa y compendian los datos recolectados. El datos compendiados se transmiten a la computadora correspondiente cuando una demanda es recibida.
13/04/23 640
Clases de objetos de la estación de tiempo
Termómetro de tierra, Anemómetro, Barómetro Los objetos del dominio de aplicación que son objetos
del "hardware" relacionados a los instrumentos en el sistema.
Estación de tiempo La interfaz básica de la estación de tiempo para su
entorno. La interfaz básica 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.
13/04/23 641
Clases de objetos de la estación de tiempo
EstaciónTiempoIdentificador
ImformeTiempo()Calibrar(Instrumentos)Prueba()PonerEnMarcha(Instrumentos)Cerrar(Instrumentos)
DatosTiempoTemperaturaAireTemperaturaTierraVelocidadVientoDirecciónVientoPresionesLluvia
Coleccionar()Compendiar()
TermómetroTierraTemperatura
Prueba()Calibrar()
TermómetroAireVelocidadVientoDirecciónViento
Prueba()
BarómetroPresiónAltura
Prueba()Calibrar()
13/04/23 642
Los objetos extensos y refinamiento del objeto
Usa el conocimiento del dominio para identificar más 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 automáticamente. 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 autónomamente. Esto introduce la flexibilidad en el gasto del controlador que procesa tiempo.
13/04/23 643
Modelos de diseño Los modelos de diseño muestran los
objetos y clases de objetos y las interrelaciones entre dichas entidades.
Los modelos estáticos describen la estructura estática del sistema por lo que se refiere a las clases del objeto en interrelaciones.
Los modelos dinámicos describen las interacciones dinámicas entre objetos
13/04/23 644
Ejemplos de modelos de diseño
Modelos de subsistemas que muestran los agrupamientos lógicos de objetos en subsistemas coherentes.
Modelos secuenciales que muestran la secuencia de interacciones de objetos.
Modelos de máquina 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 agregación, modelos de generalización, etc.
13/04/23 645
Modelos de subsistemasMuestran cómo el diseño es organizado
dentro de los grupos de objetos lógicamente relacionados.
En el UML, éstos se muestran usando los paquetes - una estructura del encapsulamiento. Éste es un modelo lógico. La actual organización de objetos en el sistema puede ser diferente.
13/04/23 646
Subsistemas de una estación de tiempo
Interfaz
<<subsystem>>
Recolección de datos
<<subsystem>>
ControladorComandos
EstaciónTiempo EstadoInstrumentos
DatosTiempo
Instrumentos
<<subsystem>>
TermómetroAire MedidaLluvia Anemómetro
VeletaVientoTermómetroTierra Barómetro
13/04/23 647
Modelos de secuencia 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 leídos de arriba hacia abajo; Las interacciones son representadas por fechas
etiquetadas. Diferentes tipos de flechas representan diferentes tipos de interacción;
Un rectángulo delgado en la línea de vida de un objeto representa el tiempo que un objeto es el objeto controlando en el sistema.
13/04/23 648
Secuencia de recolección de datos
: Usuario : ControladorComandos I : EstaciónTiempo C : DatosTiempo
1: Demanda(Información)2: Información()
3: Compendiar()
4:
5: Enviar(Información)
6: Respouesta(Información)
7: Reconocer()
13/04/23 649
Diagramas de estado Muestra cómo 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 señal de reloj
es recibida.
13/04/23 650
Diagrama de estado de una estación de tiempo
Operación
Esperando
Calibrando
Probando
Transmitiendo
Recoleccionando
Compendiando
Cierre Esperando
Calibrando
Probando
Iniciar
Transmitiendo
Recoleccionando
Compendiando
Recolección hecha
Calibración OK
Prueba completaCerrar
Reloj
InformeTiempo
Probar
Calibrar
Transmisión hecha
Tiempo compendiado completo
13/04/23 651
Especificación de la interfaz de objeto
Las interfaces de objeto tienen que ser especificadas de modo que los objetos y otros componentes pueden ser diseñados en paralelo.
Los diseñadores deben evitar diseñar la representación 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 métodos proporcionados.
El UML usa diagramas de clase para la especificación de la interfaz, pero Java también pude ser usado.
13/04/23 652
Interfaz de la estación 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 () ;
} //WeatherStation
13/04/23 653
Evolución del diseño Esconder información dentro de los objetos significa
que los cambios hechos a un objeto no afectan a otros objetos de una manera imprevisible.
El asumir polución monitoreando los recursos será agregado para las estaciones de tiempo. Éstos sacan muestra del aire y computan la cantidad de contaminantes diferentes en la atmósfera.
Las lecturas de polución serán transmitidas con los datos del tiempo.
13/04/23 654
Cambios requeridos Agregar una clase de objetos llamada Calidad
de aire como parte de EstaciónTiempo. Agregar una operación informeCalidadAire
para EstaciónTiempo. Modificar el software de control para recolectar lecturas de polución.
Agregar objetos que representan instrumentos de monitoreo de polución.
13/04/23 655
Monitoreando la poluciónEstaciónTiempo
Identificador
ImformeTiempo()InformeCalidad()Calibrar(Instrumentos)Prueba()Iniciar(Instrumentos)Cerrar(Instrumentos)
Calidad del aireNODatosDatosHumoBatosBenceno
Recolectar()Compendiar()
Instrumentos de monitoreo de polución
NoMedir MedirHumo
MedirBenceno
13/04/23 656
El DOO es una aproximación para el diseño, de modo que los componentes de diseño tengan su propio estado privado y sus operaciones.
Los objetos deben tener operaciones de constructor e inspección. 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.
Puntos clave
13/04/23 657
Puntos clave Un rango de diferentes modelos pueden ser
producidos durante el proceso de diseño orientado a objetos. Ellos incluyen modelos de sistemas estáticos y dinámicos.
Las interfaces de objetos deben ser definidas precisamente usando, por ejemplo, lenguajes de programación como Java.
El diseño orientado a objetos potencialmente simplifica la evolución de sistemas.
13/04/23 658
Diseño de software de tiempo real
Capítulo 15
13/04/23 659
Objetivos Explicar el concepto de tiempo real y por qué
estos sistemas son normalmente implementados como procesos concurrentes
Describir un proceso de diseño para sistemas de tiempo real
Explicar el rol de sistemas operativos de tiempo real
Introducir arquitectura de procesos genéricos para monitoreo y control y sistemas de adquisición de datos
13/04/23 660
Tópicos cubiertosDiseño de sistemaSistemas operativos de tiempo realSistemas de monitoreo y controlSistemas de adquisición de datos
13/04/23 661
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 crítico. Los sistemas de tiempo real
DEBEN responder dentro de los tiempos especificados.
13/04/23 662
Definición 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.
13/04/23 663
Sistemas de Estímulo/Respuesta
Dado un estímulo, el sistema debe producir una contestación dentro de un tiempo especificado.
Estímulos periódicos. Estímulos que ocurren a los intervalos de tiempo predecibles Por ejemplo, un sensor de temperatura puede ser
registrado 10 veces por segundo. Estímulos aperiódicos. Estímulos que ocurren en los
momentos imprevisibles Por ejemplo, una falla de un sistema de potencia
puede activar una interrupción que debe ser procesada por el sistema.
13/04/23 664
Consideraciones arquitectónicos
Debido a la necesidad de responder a los tiempos de demanda hechas por diferentes estímulos/respuestas, la arquitectura del sistema debe permitir cambiar rápidamente entre manejadores del estímulo.
Los tiempos de demandas de diferentes estímulos son diferentes, así un bucle secuencial simple no es normalmente adecuado.
Los sistemas de tiempo real por consiguiente son normalmente diseñados como procesos cooperativos con un ejecutor de tiempo real que controla estos procesos.
13/04/23 665
Modelo de un sistema de tiempo real
Sistema de control de tiempo real
Sistema de control de tiempo real
SensorSensor SensorSensor SensorSensor SensorSensor SensorSensor SensorSensor
ActuadorActuador ActuadorActuador ActuadorActuador ActuadorActuador
13/04/23 666
Procesos de sensor/actuador
SensorSensorActuadorActuador
Control de sensor
Control de sensor
Procesador de datos
Procesador de datos
Control de actuador
Control de actuador
Estímulo Respuesta
13/04/23 667
Elementos del sistema Procesos de control de sensor
Recolecta la información de los sensores. Es posible una memoria intermedia de información recolectada en respuesta para un estímulo del sensor.
Procesador de datos Lleva a cabo un procesamiento de la información
recolectada y computa la respuesta del sistema. Procesos de control de actuador
Genera señales de control para los actuadores.
13/04/23 668
Programando en tiempo real
Los sistemas de tiempo duro-reales pueden tener que programar en lenguaje ensamblador para asegurar que fechas límite se encuentran.
Lenguajes tales como C permiten escribir los programas eficaces pero no tienen las estructuras para apoyar concurrencia la gestión de recursos compartidos.
13/04/23 669
Java como un lenguaje de tiempo real
Java soporta la concurrencia ligera (los hilos y los métodos sincronizados) y puede usarse para algunos sistemas de tiempo real suaves.
Java 2.0 no es apropiada para la programación en TR dura, pero las versiones de Java está ahora disponible para los problemas de dirección como No es posible especificar tiempo de ejecución del hilo; Diferentes tiempos en las máquinas virtuales diferentes; La recolección de basura incontrolable; No es posible descubrir los tamaños de cola para los
recursos compartidos; No es posible acceder al hardware del sistema; No es posible espaciar o cronometrar el análisis.
13/04/23 670
Diseño del sistema Diseña el hardware y el software asociado con el
sistema. La partición funciona para el hardware o el software.
Las decisiones de diseño deben tomarse en la base a los requerimientos del sistema no funcionales.
El hardware entrega buen desempeño, pero desarrollo potencialmente más largo y menos alcance para el cambio.
13/04/23 671
Proceso de diseño de sistemas de T-R
Identifica los estímulos a ser procesados y las respuestas requeridas a estos estímulos.
Para cada estímulo y respuesta, identifica las restricciones de oportunidad.
Agrega el estímulo y respuesta que procesa en los procesos concurrentes. Un proceso puede asociarse con cada clase de estímulo y respuesta.
13/04/23 672
Proceso de diseño de sistemas de T-R
Diseña los algoritmos para procesar cada clase de estímulo y respuestas. Éstos deben enfrentarse dada la oportunidad de los requerimientos.
Diseña un sistema de planificación que asegurará que se empiezan los procesos a tiempo a encontrarse sus fechas límite.
Se integra usando un sistema operativo del tiempo real.
13/04/23 673
Restricciones de oportunidad
Puede requerir la simulación extensa y experimento para asegurar que éstos se reúnen por el sistema.
Puede significar que ciertas estrategias de diseño, como el diseño orientado a objetos, no puede usarse debido al adicional encabezado involucrado.
Puede significar que los rasgos del lenguaje de programación de bajo nivel tienen que ser usados por razones de desempeño.
13/04/23 674
Modelamiento de sistemas de tiempo real
El efecto de un estímulo en un sistema del tiempo real puede activar una transición de un estado a otro.
Las máquinas 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 máquina de estados.
Ver el Capítulo 8 para los ejemplos extensos de modelos de máquinas de estado.
13/04/23 675
Modelo de estado de bomba de gasolina
Esperando
do/ Visualiza bienvenida
Ley endo
do/ Recibir T, Detalles T
Validando
do/ Validar tarjeta de crédito
Reiniciando
do/ Visulaizar T, error de T
Tarjeta insertada en la lectora
Tarjeta remov ida
Tarjeta inv alida
Interrupción
Inicializando
do/ Inicializa despliegue
Tarjeta OK
Interrupción
Pagando
do/ Cargar T, Cuenta de TConf irmar pago
Listo
Parada
Entregando
do/ Entregar gasolina, Actualiza despliegue
Sacar manguera f uera del brazo
Apretar gatillo
Soltar gatillo
Apretar gatillo
Dev olv er manguera al brazo
13/04/23 676
Sistemas operativos de tiempo real
Los sistemas operativos de tiempo real son sistemas operativos que manejan los procesos en los STR.
Responsable para la gestión del proceso y la asignación del recurso (procesador y memoria).
Puede estar basado en un núcleo estándar que es usado tal como está o modificado para una aplicación particular.
Normalmente no incluye recursos como la administración de archivos.
14
13/04/23 677
Componentes del sistema operativo
Reloj de tiempo real Provee la información la planificación del proceso.
Manejador de interrupción Maneja demandas aperiódicas pide para el servicio.
Programa Elige el próximo proceso a ser ejecutado.
Administrador de recurso Asigna memoria y recursos del procesador.
Distribuidor Inicia proceso de ejecución.
13/04/23 678
Componentes de un sistema sin para
Administrador de configuración Responsable para la reconfiguración dinámica de un
sistema de software y hardware. Los módulos 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 operación.
13/04/23 679
Componentes de un SO de tiempo real
Programación de la información
Programación de la información
ProgramadorProgramador
Proceso de requerimientos
de recursos
Proceso de requerimientos
de recursos
Manejador de recursos
Manejador de recursos
DistribuidorDistribuidor
Reloj de tiempo real
Reloj de tiempo real
Proceso de evaluación de
recursos
Proceso de evaluación de
recursos
Lista preparadaLista preparada
Manejador de interrupción
Manejador de interrupción
Lista de recursos disponibles
Lista de recursos disponibles
Lista del procesadorLista del
procesador
Proceso listoRecursos
libres
Proceso de ejecución
13/04/23 680
Procesar la prioridad El procesamiento de algunos tipos de estímulos
debe tomar a veces la prioridad. La prioridad a nivel de interrupción. La prioridad
más alta que se asigna a procesos que requieren una respuesta muy rápida.
La prioridad a nivel del reloj. Asignado a los procesos periódicos.
Dentro de éstos, pueden asignarse niveles extensos de prioridad.
13/04/23 681
Servicio de interrupción El control es transferido automáticamente a una
ubicación de memoria predeterminada. Esta situación contiene una instrucción para
saltar a una rutina de servicio de interrupción. Las interrupciones extensas son inválidas, la
interrupción es reparada y devuelve el control al devolvió al proceso interrumpido.
Las rutinas del servicio de interrupción DEBEN se cortas, simples y rápidas.
13/04/23 682
Servicio de proceso periódico En más sistemas de tiempo real, habrá varias clases
de proceso periódico, cada uno con los diferentes periodos (tiempo entre las ejecuciones), los tiempos de ejecución y fechas límite (el tiempo en el cual el procesamiento debe completarse).
El reloj de tiempo real hace tictac periódicamente y cada tictac causa una interrupción que fija al administrador del proceso para los procesos periódicos.
El administrador del proceso selecciona un proceso que está listo para la ejecución.
13/04/23 683
Gestión de procesos Tiene relación con manejar el conjunto de
procesos concurrentes. Los procesos periódicos 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: Proceso periódico – tiempo entre ejecuciones. Proceso de fecha límite – el tiempo en el cual un
procesamiento debe ser completado.
13/04/23 684
Gestión de procesos TRE
Elige procesos para ejecución
Planificador
Asigna memoria y procesador
Manejador de recursos
Inicia ejecución en un procesador
disponible
Distribuidor
13/04/23 685
Cambiando el proceso El planificador elige el próximo proceso para
ser ejecutado por el procesador. Esto depende de una estrategia de planificación 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.
13/04/23 686
Estrategias de planificación Planificación no preventiva
Una vez que un proceso se ha planificado para la ejecución, corre para completarla o hasta que se bloquee por alguna razón (por ejemplo, esperando por E/S).
Planificación preventiva La ejecución de un proceso ejecutándose puede detenerse
si un proceso de prioridad más alto requiere el servicio. Algoritmos de planificación
Robin round (Turno rotatorio); Rate monotonic (Prioridades fijas); Shortest deadline first (Primero la tarea con menor tempo
de holgura).
13/04/23 687
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.
13/04/23 688
Arquitectura genérica
Proceso de monitoreo
Proceso de monitoreo
Proceso de control
Proceso de control
P(S1)P(S1)
A1A1
Proceso de prueba
Proceso de prueba
Proceso de panel de control
Proceso de panel de control
P(S2)P(S2)
P(S3)P(S3)
P(A2)P(A2)
P(A3)P(A3)
P(A4)P(A4)
P(A1)P(A1)
A2A2
A3A3
A4A4
S1S1
S2S2
S3S3
13/04/23 689
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 policía automáticamente.
El sistema debe incluir la provisión para el funcionamiento sin un suministro principal de poder.
13/04/23 690
El proceso de diseños de sistemas de TR
Identifica estímulos y respuestas asociadas. Define las restricciones de tiempo asociados con
cada estímulo y respuesta. Asigna las funciones del sistema a los procesos
concurrentes. Diseña algoritmos para estimular procesamiento y
generación de respuestas. Diseña un sistema de planificación que asegure que
el proceso siempre se planificará para cumplir con las fechas límite.
13/04/23 691
Estímulo para ser procesado
Falla de energía Generado aperiódicamente por un monitor de
circuito. Cuando es recibida el sistema debe cambiar la energía de respaldo dentro de 50 ms.
Alarma de intruso Estímulo generado por sensores del sistema.
La respuesta es llamar a la policía encender las luces de la construcción y una alarma audible.
13/04/23 692
Requerimientos de tiempoEstímulo/Respuesta Requerimientos de tiempo
Interrupción de falla de energía El interruptor de energía 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 policía 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.
13/04/23 693
Proceso de sistema de alarma contra robos
Proceso de sensor de puerta
Proceso de sensor de puerta
Proceso de construcción de monitor
Proceso de construcción de monitor
Proceso de sistema de alarma
Proceso de sistema de alarma
Proceso de control de encendido de luz
Proceso de control de encendido de luz
Proceso de detector de movimiento
Proceso de detector de movimiento
Proceso de interruptor de energía
Proceso de interruptor de energía
Proceso de alarma audible
Proceso de alarma audible
Proceso de sensor de ventana
Proceso de sensor de ventana
Proceso de comunicaciónProceso de
comunicación
Proceso de sintetizador de voz
Proceso de sintetizador de voz
400 Hz 60 Hz 100 Hz
Estatus de detector
Estatus de sensor
Estatus de sensor 560 Hz
Sistema de alarma
Interruptor de falla de energía Construcción
de monitor Número de pieza
Mensaje de alerta
Número de pieza
Sistema de alarma
Número de pieza
Sistema de alarma
13/04/23 694
Proceso 1 de construcción 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 processessiren.start () ; lights.start () ;synthesizer.start () ; windows.start () ;doors.start () ; movements.start () ; pm.start () ;
}
13/04/23 695
Proceso 2 de construcción 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 ;
}}
13/04/23 696
Proceso 3 de construcción de monitor
lights.shutdown () ; siren.shutdown () ; synthesizer.shutdown () ;windows.shutdown () ; doors.shutdown () ; movements.shutdown () ;
} // run} //BuildingMonitor
13/04/23 697
Sistemas de control Un sistema de alarma contra robos es
principalmente un sistema de monitoreo. Recolecta los datos de los sensores pero ningún control de actuador de tiempo real.
Los sistemas de control son similares pero, en respuesta para valores del sensor, el sistema envía señales 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).
13/04/23 698
Un sistema de control de temperatura
Proceso de
sensorProceso de
sensor
Proceso de termostato
Proceso de termostato
Proceso de control de calentador
Proceso de control de calentador
Proceso de control de horno
Proceso de control de horno
Valores de sensor
500 Hz
Comando de cambio
Número de pieza
500 Hz
500 Hz
Proceso de termostato
13/04/23 699
Sistemas de adquisición de datos
Recolecta los datos de los sensores para el proceso subsecuente y el análisis.
Los procesos de recolección de datos y los procesos de procesamiento pueden tener periodo diferentes y fechas tope.
La recolección de los datos puede ser más rápida que procesando, por ejemplo, la información colectiva sobre una explosión.
Las memorias intermediarias (buffers) circulares o en anillo son un mecanismo para las diferencias de velocidad suavizadoras.
13/04/23 700
Arquitectura de adquisición de datos
Buffer de datos de sensor
Buffer de datos de sensor
Proceso de sensor
Proceso de sensor
s1s1
s2s2
s3s3
Datos del proceso
Datos del proceso
DesplegarDesplegar
Buffer de datos de sensor
Buffer de datos de sensor
Proceso de sensor
Proceso de sensor
s4s4
s5s5
s6s6
Datos del proceso
Datos del proceso
Sensor (cada flujo de datos es un valor del sensor)
Identificador de sensor y valor
Identificador de sensor y valor
Identificador de sensor y valor
Identificador de sensor y valor
13/04/23 701
Recolección de datos de reactor
Un sistema recolectan datos desde un conjunto de sensores que monitorean el flujo del neutrón 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.
13/04/23 702
Monitoreando el flujo del reactor
Buffer de datos de flujo
Buffer de datos de flujo
Convertidor A-D
Convertidor A-D
Procesamiento de flujo
Procesamiento de flujo
Despliega operador
Despliega operador
Identificador de sensor y valores de flujo
Sensores de flujos de neutrón
Nivel de flujo procesado
13/04/23 703
Un buffer en anillo
Proceso productorProceso
productor
Proceso consumidorProceso
consumidor
13/04/23 704
Exclusión 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 información para un buffer lleno y el proceso consumidor prueba a tomar información desde un buffer vacío.
13/04/23 705
Implementación 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
13/04/23 706
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
Implementación de un buffer en anillo 2
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 707
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
Implementación de un buffer en anillo 3
13/04/23 708
Puntos clave La correctitud de un sistema de tiempo real
depende no sólo den lo que el sistema hace, sino también de cuan rápido reacciona.
Un modelo de sistema de TR involucra procesos asociados con sensores y actuadores.
Las arquitecturas de sistemas de tiempo real son normalmente diseñadas como una variedad de procesos concurrentes.
13/04/23 709
Puntos clave Los sistemas operativos de tiempo real son
responsables para el proceso y gestión de recursos.
Los sistemas de monitoreo y controla registran los sensores y envían la señal de control para los actuadores.
Los sistemas de adquisición son normalmente organizados de acuerdo al modelo productor consumidor.
13/04/23 710
Diseño de interfaz de
usuario
Capítulo 16
13/04/23 711
Objetivos Sugerir algunos principios de diseño general para
el diseño de interfaz de usuario Explicar diferentes estilos de interacción y su uso Explicar cuando usar presentación gráfica y
textual de información Explicar las principales actividades y el proceso
de interfaz de usuario Introducir atributos de usuabilidad y aproximación
para evaluación de sistemas
13/04/23 712
Tópicos cubiertosProblemas de diseñoProceso de diseño para interfaz de
usuarioAnálisis de usuarioPrototipado de interfaz de usuarioEvaluación de interfaz
13/04/23 713
La interfaz de usuario Las interfaces de usuario deben ser diseñadas
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 diseñada puede causar que el usuario cometa errores catastróficos.
Un diseño pobre de la interfaz de usuario es la razón por la cual muchos sistemas de software no se usan nunca.
13/04/23 714
Diseño de interfaz de factores humanos
Memoria de corto plaza limitada Las personas pueden recordar instantáneamente alrededor
de 7 temas de información. Si superan este límite, ellos son más 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 tensión y la probabilidad de más errores.
Las personas son diferentes Las personas tienen una gama amplia de capacidades
físicas. Los diseñadores no deben diseñar solamente para sus propias capacidades.
Las personas tienen diferentes preferencias de interacción Algunos gustan de gráficos, otros gustan de textos.
13/04/23 715
Principios del diseño de IU El diseño IU debe tomar en cuenta las necesidades,
experiencia y capacidades de los usuarios del sistema.
Los diseñadores deben ser conscientes de las limitaciones físicas y mentales de personas (por ejemplo, la memoria a corto plazo limitada) y debe reconocer que las personas cometen errores.
Los principios de diseño de IU están supeditados a los diseños de interfaz, aunque no todos los principios son aplicables a todos los diseño.
13/04/23 716
Principios del diseño de interfaz de usuario
Principio DescripciónFamiliaridad del usuario
La familiaridad del usuario: La interfaz debe usar las condiciones y conceptos que son delineados a partir de la experiencia de las personas que harán más 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 mínima 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.
Guía del usuario La interfaz debe proporcionar la regeneración 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 interacción apropiados los tipos diferentes del sistema de usuario.
13/04/23 717
Principios de diseño Familiaridad de usuario
La interfaz debe estar basada en términos 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 menús deben tener el mismo formato, la puntuación del comando debe ser similar, etc.
Sorpresa mínima Si un comando opera de una manera conocida, el usuario
debe poder predecir la operación de comandos comprables.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 718
Principios de diseño Recuperabilidad
El sistema debe proporcionar un poco de elasticidad para los errores de usuario y debe permitirle al usuario recuperarse de los errores. Esto podría incluir facilidad de cancelar, la confirmación de acciones destructivas, borrar “soft” , etc.
Guía de usuario Alguna guía del usuario como los sistemas de ayuda, los
manuales en línea, etc. debe ser proporcionada. Diversidad de usuario
Recursos de interacción para los tipos diferentes de usuario deben ser soportados. Por ejemplo, algunos usuarios tienen dificultades de vista y los texto con tipos más grandes deben estar disponibles.
13/04/23 719
Los problemas de diseño en IUs
Dos problemas deben ser dirigidos en el diseño de sistemas interactivos ¿Cómo debe proporcionarse la información del usuario
al sistema de computadora? ¿Cómo debe presentarse la información del sistema de
computadora al usuario? La interacción del usuario y la presentación de
información pueden integrarse a través de un framework coherente como una metáfora de interfaz de usuario.
13/04/23 720
Estilos de interacciónManipulación directaSelección de menúLlenado en formularioLenguaje de comandosLenguaje natural
13/04/23 721
Estilos de interacciónEstilos de
interacciónPrincipales
ventajasPrincipales desventajas Ejemplos de
aplicaciónManipulación directa Interacción rápida e
intuitiva.Fácil de aprender
Puede ser duro de implementar.Sólo es conveniente donde hay una metáfora visual para las tareas y objetos.
Juegos de video.Sistemas CAD.
Selección de menú Evita el error de usuario.Mecanografía requerida pequeña.
Lento para usuarios experimentados.Puede volverse complejo si hay muchas opciones para el menú.
La mayoría de sistemas de propósito general.
Llenado en formulario
Entrada de datos simple.Fácil 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 préstamos personales.
Lenguaje de comandos
Poderoso y flexible. Difícil de aprender.Pobre gestión de error.
Sistemas operativos.Sistemas de control y comandos.
Lenguaje natural Accesible a usuarios casuales.Se extiende fácilmente.
Requiere más mecanografía.Los sistemas de interpretación del lenguaje natural son inestables.
Sistemas de recuperación de información.
13/04/23 722
Interfaces de múltiple usuario
Interfaz gráfica de usuario
(Gnome /KDE)
Interfaz gráfica de usuario
(Gnome /KDE)
Interfaz de apariencia de Unix
(ksh /csh)
Interfaz de apariencia de Unix
(ksh /csh)
Administrador GUI X-
Windows
Administrador GUI X-
Windows
Intérprete de lenguaje de comandos
Intérprete de lenguaje de comandos
Sistema Operativo Linux Sistema Operativo Linux
13/04/23 723
Interacción LIBSYS Búsqueda de documento
Los usuarios necesitan poder usar los medios de búsqueda para encontrar los documentos que ellos necesitan.
Demanda de documento Los usuarios piden que un documento se
entregue a su máquina o a un servidor para imprimir.
13/04/23 724
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 menús, entrada de texto libre, botones radio, etc.
En el ejemplo LIBSYS, los usuarios hacen uso de una opción de menú, para buscar un documento tipeando una frase dentro de un campo de texto.
13/04/23 725
Formulario de búsqueda LIBSYS
LIBSYS: Búsqueda
Elegir colección
Clave o frase
Buscar usando
Palabra adyacente
Todo
Título
Si No
Buscar Restaurar Cancelar
13/04/23 726
Presentación de información
La presentación de información se preocupa por presentar la información del sistema a los usuarios del sistema.
La información puede ser presentada directamente (por ejemplo, el texto en un procesador de texto) o puede transformarse de alguna forma de presentación (por ejemplo, en alguna forma gráfica).
La aproximación Controlador-Vista-Modelo es una manera de presentaciones múltiples de soporte de datos.
13/04/23 727
Presentación de información
Información para ser visualizado
Información para ser visualizado
Software de presentaciónSoftware de
presentación
Visualizador
13/04/23 728
Controlador-Vista-Modelo
Métodos de controlador
Estado controlador
Métodos de vista
Estado vista
Métodos de modelo
Estado modelo
Entradas de usuario
Mensajes de modificación
de vista
Consultas de modelo y
actualizaciones
Editar modelo
13/04/23 729
Presentación de información
Información estática Inicializado al principio de una sesión. No
cambia durante la sesión. Puede ser numérica o textual.
Información dinámica Cambia durante una sesión y el cambio debe
ser comunicada al usuario del sistema. Puede ser numérica o textual.
13/04/23 730
Factores de despliegue de información
¿Está el usuario interesado en información precisa o interrelaciones de los datos?
¿Cuán rápidamente cambian los valores de información? ¿Debe indicarse el cambio inmediatamente?
¿El usuario debe tomar alguna acción en respuesta a un cambio?
¿Hay una interfaz de manipulación directa? ¿La información es textual o numérica? ¿Son
importantes los valores relativos?
13/04/23 731
Presentaciones de información alternativas
2842 28513164
2789
1273
2835
0
500
1000
1500
2000
2500
3000
3500
Enero Febrero Marzo Abril Mayo Junio
13/04/23 732
¿Presentación análoga o digital?
Presentación digital Compacto – toma un pequeño espacio de la pantalla; Valores precisos pueden ser comunicados.
Presentación análoga Mucha facilidad para conseguir una impresión de
valores '"de un vistazo"; Posibilidad de mostrar valores relativos; Mucha facilidad para ver valores de datos
excepcionales.
13/04/23 733
Métodos de presentación
Marcar con aguja Diagrama de
pastelTermómetro
Barra horizontal
10 20 30 40 50 60 70 80 90
13/04/23 734
Visualizando valores relativos
0 100 200 300 400
0 25 70 75 100
Presión Temperatura
13/04/23 735
Visualización de datos Tiene relación con las técnicas para desplegar grandes
cantidades de información. Visualización puede revelar las interrelaciones entre las
entidades y tendencias en los datos. Las posibles visualizaciones de datos son:
Información del tiempo recolectada desde varias fuentes; El estado de una red de teléfonos como un conjunto de
nodos enlazados; Una planta química visualizada por visualización de
presiones y temperaturas en un conjunto enlazado de tanques y cañerías;
Un modelo de visualización de molécula en 3 dimensiones; Visualización de páginas Web Web como un árbol
hiperbólico.
13/04/23 736
Pantallas de color El color agrega una dimensión extra para una
interfaz y puede ayudar al usuario a entender estructuras de información completa.
El color puede ser usado para resaltar eventos excepcionales.
Los confusiones comunes en el uso de color en el diseño de interfaz incluyen: El uso del color par comunicar el significado; El sobreuso de color en el despliegue.
13/04/23 737
Guías para el uso de color Limitar el número 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 código de colores para dar soporte a las
tareas que el usuario intenta realizar. Usar un código de colores de una manera
razonada y consistente. Tener cuidado en la combinación de colores.
13/04/23 738
Mensajes de error El diseño de mensajes de error es críticamente
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 formación y experiencia de los usuarios deben ser el factor determinante en el diseño del mensajes.
13/04/23 739
Los factores de diseño en la redacción de mensajes
Factor DescripciónContexto 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 difícil de entender declaraciones muy concisas de un problema. Se debe proporcionar ambos tipos de mensaje y debe permitir al usuario controlar la concisión 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 terminología 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 dirección. Ellos nunca deben ser insultantes o deben intentar ser humorísticos.
Cultura Dondequiera sea posible, el diseñador de mensajes debe estar familiarizado con la cultura del país dónde el sistema se vende. Hay diferencias culturales distintas entre Europa, Asia y América. Un mensaje conveniente para una cultura podría ser inaceptable en otro.
13/04/23 740
Error de usuario Asumir que una enfermera deletrea mal el nombre de un
paciente cuyos registros está intentando recuperar.
Nombre del paciente
Por favor escribir el nombre del paciente en la caja y entonces hacer click en OK
Por favor escribir el nombre del paciente en la caja y entonces hacer click en OK
RODRIGUEZ SANCHEZ, J.RODRIGUEZ SANCHEZ, J.
OKOK CancelarCancelar
13/04/23 741
Diseño de buen y mal mensaje
Mensaje de error orientado al sistema
Error # 27
Paciente inválido
Error # 27
Paciente inválido
OKOK CancelarCancelar
??
Mensaje de error orientado al usuario
J. RODRIGUEZ SANCHEZ no es un paciente registrado.
Click en Pacientes para una lista de pacientes.
Click en Reintentar para reingresar el nombre de un paciente.
Click en Ayuda para mayor información
J. RODRIGUEZ SANCHEZ no es un paciente registrado.
Click en Pacientes para una lista de pacientes.
Click en Reintentar para reingresar el nombre de un paciente.
Click en Ayuda para mayor información
PacientesPacientesAyudaAyuda
ReintentarReintentarCancelarCancelar
13/04/23 742
El proceso de diseño de IU El diseño de IU es un proceso interactivo que
involucra los enlaces íntimos entre usuarios y diseñadores.
Las 3 actividades centrales en este proceso son: Análisis de usuario: Entendimiento de lo que los
usuarios harán con el sistema; Prototipado del sistema: Desarrollar una serie de
prototipos para experimentar; Evaluación de la interfaz: Experimentar estos
prototipos con los usuarios.
13/04/23 743
El proceso de diseño
Analizar y entender las
actividades del usuario
Analizar y entender las
actividades del usuario
Producir diseños de prototipos
basados en papel
Producir diseños de prototipos
basados en papel
Evaluar el diseño con los usuarios
finales
Evaluar el diseño con los usuarios
finales
Prototipo de diseño
Prototipo de diseño
Producir prototipo de
diseño dinámico
Producir prototipo de
diseño dinámico
Evaluar diseño con los
usuarios finales
Evaluar diseño con los
usuarios finales
Prototipo ejecutablePrototipo ejecutable
Implementar la interfaz del
usuario final
Implementar la interfaz del
usuario final
13/04/23 744
Análisis de usuario Si no se entiende lo que los usuarios quieren
hacer con un sistema, no se tiene ninguna perspectiva realista de diseñar una interfaz eficaz.
Los análisis del usuario tienen que ser descritos en términos que los usuarios y otros diseñadores puedan entender.
Escenarios donde se describe episodios típicos de uso, es una manera de describir estos análisis.
13/04/23 745
Escenario de interacción de usuario
Jane es un estudiante de Estudios Religiosos y está trabajando en un ensayo en la arquitectura india y cómo ha sido influenciado por las prácticas religiosas. Para ayudarse a entender esto, le gustaría 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 búsqueda que podrían usarse. También le hace pensar en algunas bibliotecas en Nueva Delhi y Londres que podrían tener este material para que ellos registren los catálogos de la biblioteca y hacen algún uso escrutador en estas condiciones. Ellos encuentran algún material de la fuente y solicitan fotocopias de los cuadros con detalle arquitectónico y que pueden ser ser enviados directamente por correo a Jane.
13/04/23 746
Requerimientos desde el escenario
Los usuarios pueden no ser conscientes de los términos de búsqueda apropiadas, de modo que hay necesidad de una forma de ayudarlos para escoger estos términos.
Los usuarios tienen que poder seleccionar las colecciones para investigar.
Los usuarios necesitan poder llevar a cabo las búsquedas y copias de la demanda del material pertinente.
13/04/23 747
Técnicas de análisis Análisis de tareas
Modelar los pasos involucrados en completar una tarea.
Entrevistas y encuestas Preguntar a los usuarios acerca del trabajo que
hacen. Etnografía
Observar al usuario en su trabajo.
13/04/23 748
Análisis de las tareas jerárquicasRecuperar los
cuadros de bibliotecas remotas
Recuperar los cuadros de bibliotecas remotas
Describir posibles fuentes
Describir posibles fuentes
Establecer términos de búsqueda
Establecer términos de búsqueda
Búsqueda para
cuadros
Búsqueda para
cuadros
Demanda de artículos
encontrados
Demanda de artículos
encontrados
Seleccionar
libreríaSeleccionar
librería
Registrar en catálogo Registrar
en catálogo
Búsqueda para cuadrosBúsqueda
para cuadros
Modificar términos de búsqueda
Modificar términos de búsqueda
Registro de artículos
relevantes
Registro de artículos
relevantes
Ingresar términos de búsqueda
Ingresar términos de búsqueda
Iniciar la
búsquedaIniciar la
búsqueda
Revisar los
resultados
Revisar los
resultados
1 2 3 4
3.1 3.2 3.3 3.4 3.5
3.3.1 3.3.2 3.3.3
Hacer 1, 2, 3 hasta encontrar los cuadros, 4
Hacer 3.1, 3.2, 3.3 hasta encontrar los cuadros, 3.4 si es necesario, 3.5
Hacer 3.3.1, 3.3.2, 3.3.3
13/04/23 749
EntrevistaDiseñar entrevistas semiestructuradas
basadas en preguntas abiertas. Los usuarios pueden, entonces, proporcionar
información que ellos piensan que es esencial; no sólo información 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í.
13/04/23 750
Etnografía 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 difíciles de describir y explicar.
También ayudan a entender el papel social y organizacional que influencian en el trabajo.
13/04/23 751
Registros etnográficosEl control de tráfico aéreo involucra varias series de controles dónde se localizan las series que controlan sectores adyacentes de espacio aéreo físicamente 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 posición en el sector. Si no hay bastantes hendeduras en la percha (es decir cuando el espacio aéreo está muy ocupado), los controladores extienden las tiras fuera del escritorio delante de la percha.
Cuando nosotros estábamos observando a los controladores, notamos que ellos regularmente han echado una mirada a las perchas de tiras en el sector adyacente. Nosotros señalamos esto a ellos y les preguntamos por qué hacían esto. Ellos contestaron que, si el controlador adyacente tiene tiras en su escritorio, entonces esto significa que ellos tendrán muchos vuelos que entran en su sector. Ellos, por consiguiente, intentaron aumentar la velocidad de avión en el sector ‘'espacio limpio" para el avión entrante .
13/04/23 752
Las visiones de la etnografía
Los controladores tenían que ver todos los vuelos en un sector. Por consiguiente los despliegues de desplazamiento dónde los vuelos desaparecen fuera de la cima o fondo del despliegue deben ser evitados.
La interfaz debía tener, alguna manera de decirles a los controladores, cuántos vuelos estaban en los sectores adyacentes, para que ellos pudieran planear su trabajo.
13/04/23 753
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 diseño es entonces refinado y prototipos
automatizados cada vez más sofisticados son desarrollados.
13/04/23 754
Prototipado en papelTrabajar a través 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 diseño.
13/04/23 755
Técnicas de prototipado Prototipado basado en guiones
Desarrollar un conjunto de guiones y pantallas usando una herramienta como Macromedia Director. Cuando el usuario interactúa con ellos, la pantalla cambia al próximo despliegue.
Programación visual Usar un lenguaje diseñado para desarrollo rápido tal
como Visual Basic. Ver el Capítulo 17. Prototipado basado en Internet
Usar un navegado de la Web y guiones asociados.
13/04/23 756
Evaluación de la interfaz de usuario
Alguna evaluación de un diseño de interfaz de usuario debe llevarse a cabo para evaluar su conveniencia.
La evaluación a escala completa es muy costosa e impracticable para la mayoría de sistemas.
Idealmente, una interfaz debe ser evaluada en contraste a una especificación de utilidad. Sin embargo, esto es raro para tales especificaciones a ser producidas.
13/04/23 757
Atributos de utilidadAtributo DescripciónAprendibilidad ¿Cuánto tiempo toma a un nuevo usuario
ponerse productivo con el sistema? Velocidad de operación
¿Cuán bien responde el sistema en cuanto a la práctica de trabajo del usuario?
Robustez ¿Cuán tolerante es el sistema con los errores del usuario?
Recuperabilidad ¿Cuán bueno es el sistema para recuperarse de los errores del usuario?
Adaptabilidad ¿Cuán estrechamente está el sistema ligado a un solo modelo de trabajo?
13/04/23 758
Técnicas de evaluación simple
Cuestionarios para la retroalimentación del usuario.
Grabación de video del uso de un sistema y la subsiguiente evaluación de la cinta.
Instrumentación de código para recolectar información acerca de la facilidad de uso y errores de usuario.
La provisión de código en el software para recolectar en línea, la retroalimentación del usuario.
13/04/23 759
Puntos clave Los principios de diseño de interfaz de usuario deben
servir como guía para el diseño de interfaces de usuario.
Los estilos de interacción de usuario incluyen manipulación directa, sistemas de menú, llenado de formularios, lenguajes de comandos y lenguaje natural.
Los despliegues gráficos deben ser usados para presentar tendencias y valores aproximados. Los despliegues digitales cuando la precisión es requerida.
El color debe ser usado económica y consistentemente.
13/04/23 760
Puntos clave El proceso de diseño de la interfaz de usuario involucra
análisis del usuario, prototipado del sistema y la evaluación del prototipo.
El objetivo del análisis del usuario es sensibilizar a los diseñadores 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 evaluación de la IU son obtener la retroalimentación en como mejorar el diseño de la interfaz y para evaluar si la interfaz reúne los requerimientos de utilidad.
13/04/23 761
Desarrollo rápido de software
Capítulo 17
13/04/23 762
Objetivos Explicar cómo un proceso de desarrollo iterativo,
incremental lleva a la entrega rápida de software más útil
Discutir la esencia de los métodos de desarrollo ágiles
Explicar los principios y prácticas de la programación extrema
Explicar los roles del prototipado en el proceso de software
13/04/23 763
Tópicos cubiertosMétodos ágilesProgramación extremaDesarrollo rápido de aplicacionesPrototipado de software
13/04/23 764
Desarrollo rápido de aplicaciones
Debido a los ambientes de negocios rápidamente cambiantes, los negocios tienen que responder a las nuevas oportunidades y la competencia.
Esto requiere de software, desarrollo rápido y la entrega no es, a menudo, el requerimiento más crítico para los sistemas de software.
Los negocios pueden estar dispuesto a aceptar software de baja calidad si la entrega rápida y si la funcionalidad esencial es posible.
13/04/23 765
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 aproximación de desarrollo basado en una especificación interactiva y entrega es el único camino para entregar software rápidamente.
13/04/23 766
Características del proceso DRA
Los procesos de especificación, diseño e implementación son concurrentes. No hay especificación detallada y la documentación del diseño es minimizada.
El sistema es desarrollado en una serie de incrementos. Los usuarios finales evalúan cada incremento y hacen propuestas para incrementos posteriores.
Las interfaces de usuarios del sistema son normalmente desarrollados usando un sistema de desarrollo interactivo.
13/04/23 767
Un proceso de desarrollo interactivo
Definir los entregables del
sistema
Definir los entregables del
sistema
Diseñar la arquitectura del
sistema
Diseñar la arquitectura del
sistema
Especificar los incrementos del
sistema
Especificar los incrementos del
sistema
Construir los incrementos del
sistema
Construir los incrementos del
sistema
Validar los
incrementos
Validar los
incrementos
Integrar los
incrementos
Integrar los
incrementos
Validar el sistema
Validar el sistema
Sistema final
entregado
Sistema final
entregado
¿El sistema
está completo?
¿El sistema
está completo?
NO
SI
13/04/23 768
Ventajas del desarrollo incremental
Entrega acelerada de servicios del cliente. Cada incremento entrega la funcionalidad de prioridad más alta al cliente.
Compromiso del cliente con el sistema. Los usuarios tienen que ser involucrados en el desarrollo, lo cual significa que el sistema más capaz de reunir sus requerimientos y que los usuarios se compromete más al sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 769
Problemas con el desarrollo incremental
Problemas de gestión El progreso puede ser difícil de juzgar y los problemas difíciles de
encontrar porque no hay ninguna documentación para demostrar lo que se ha hecho.
Problemas contractual El contrato normal puede incluir una especificación; sin una
especificación, diferentes formas de contrato tienen que ser usadas.
Problemas de validación ¿Sin una especificación, contra qué se está probando se el
sistema? Problemas de mantenimiento
El cambio incesante tiende a adulterar la construcción de la estructura del software, resulta más caro cambiar y evolucionar para reunir los nuevos requerimientos.
13/04/23 770
Prototipado Para algunos sistemas grandes, el desarrollo
iterativo incremental y entrega puede ser impracticable; esto es verdad especialmente cuando múltiples equipos trabajan en diferentes sitios.
El prototipado, donde un sistema experimental es desarrollado como una base para la formulación de requerimientos puede se usado. Este sistema se lanza cuando la especificación del sistema ha sido convenida.
13/04/23 771
Prototipado y desarrollo incremental
Perfil de los requerimientosPerfil de los
requerimientos
Desarrollo incrementalDesarrollo
incremental
Prototipado de una manera
Prototipado de una manera
Sistema de entrega
Sistema de entrega
Prototipo ejecutable +
Especificación del sistema
Prototipo ejecutable +
Especificación del sistema
13/04/23 772
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.
13/04/23 773
Métodos ágiles El descontento con todo los métodos de diseño arriba
mencionados llevó a la creación de los métodos ágiles. Estos métodos destacan: Enfoque en el código, en lugar del diseño; Están basados en la aproximación iterativa para el
desarrollo de software; Se piensa en la entrega de software que funciona
rápidamente y evolucionar rápidamente para reunir los requerimientos cambiantes.
Los métodos ágiles son probablemente los más adecuados para pequeños /medios sistemas de negocios clasificados por su tamaño, o productos para PC.
13/04/23 774
Principios de métodos ágiles
Atributo Descripción
Involucrar al cliente
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.
Entrega incremental
El software se desarrolla en incrementos con el cliente que especifica los requerimientos a ser incluidos en cada incremento.
Las personas no procesan
Las habilidades del equipo de desarrollo deben ser reconocidas y deben explotarse. El equipo debe salirse de lo habitual para desarrollar sus propias maneras de trabajar sin procesos prescriptivos.
Adaptación al cambio
Esperar los requerimientos del sistema para cambiar y diseñar el sistema para que pueda acomodarse a estos cambios.
Mantener la simplicidad
Enfocar la simplicidad en el software a desarrollarse y en el proceso de desarrollo usado. Dondequiera que sea posible, trabajar activamente para eliminar la complejidad del sistema.
13/04/23 775
Problemas con los métodos ágiles
Puede ser difícil de mantener el interés de clientes que están involucrados en el proceso.
Los miembros del equipo pueden ser inaptos para la intensa participación que caracteriza los métodos ágiles.
La priorización de cambios puede ser difícil cuando hay múltiples involucrados (stakeholders).
Mantener la simplicidad requiere de trabajo extra. Los contratos pueden ser un problema como con
otras aproximaciones al desarrollo iterativo.
13/04/23 776
Programación extrema Quizás el mejor conocido y el más usado método ágil. La Programación Extrema (XP) toma una aproximación
“extrema” para el desarrollo iterativo. Pueden ser construidas nuevas versiones varias
veces por día; Los incrementos y entregas para clientes cada dos
semanas; Las pruebas deben ejecutarse para cada producto y
cada producto se acepta sólo si han superado la prueba suficientemente.
13/04/23 777
El ciclo de lanzamiento XP
Historias de usuario selectas
para este lanzamiento
Historias de usuario selectas
para este lanzamiento
Defectos de historias para
tareas
Defectos de historias para
tareas
Lanzamiento del plan
Lanzamiento del plan
Evaluación del sistema
Evaluación del sistema
Lanzamiento del software
Lanzamiento del software
Desarrollo /integración /prueba
del software
Desarrollo /integración /prueba
del software
13/04/23 778
Prácticas de programación extrema 1
Planificación 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 diseñadores interrumpen estas Historias en el desarrollo de "Tareas".
Pequeños 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.
Diseño simple Bastante diseño se lleva a cabo para reunir los requerimientos actuales y ninguno más.
El primer desarrollo
Un framework de prueba de unidad automatizada se usa para escribir las pruebas para un nuevo pedazo de funcionalidad, antes que esa funcionalidad sea implementada.
Refactorización
Todos los desarrolladores están esperado para refactorizar el código continuamente para que lo más pronto posible se encuentren las mejoras del código. Esto permite guardar el código simple y mantenible.
13/04/23 779
Prácticas de programación extrema 2
Programación por pares
Los diseñadores 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 código. Cualquiera puede cambiar algo.
Integración continua
En cuanto el trabajo de una tarea esté completo se integra al sistema entero. Después de cualquier integración, 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 código 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 programación extrema, el cliente es un miembro del equipo de desarrollo y es responsable para traer los requerimientos del sistema al equipo para la implementación.
13/04/23 780
XP y los principio ágiles El desarrollo incremental es soportado a través de
pequeños 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 través de lanzamientos del sistema regulares.
El mantenimiento de simplicidad a través del la constante refactorización de código.
13/04/23 781
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 implementación. Estas tareas son la base del horario y las estimaciones del costo.
El cliente escoge las historias para la inclusión en el próximo lanzamiento basado en sus prioridades y las estimaciones del programa.
13/04/23 782
Tarjeta de historia para transmisión de documentoBajando e imprimiendo un artículo
Primero, se selecciona el artículo de una lista del despliegue. Entonces se tiene que decir al sistema cómo se pagará por él - o puede ser un a través de una suscripción, a través de una cuenta de la compañía o por tarjeta del crédito.
Después de esto, usted recibe los derechos de propiedad literaria del sistema para llenar, y, cuando ha cumplido con esto, el artículo transmite la necesidad hacia su computadora.
Usted escoge una copiadora y una copia del artículo entonces será impresa. Usted comunicará al sistema que la impresión ha terminado por completo.
Si el artículo es un artículo de sólo impresión, usted no puede guardar la versión de PDF porque se anula automáticamente de su computadora.
13/04/23 783
XP y cambio La sabiduría convencional en la ingeniería de
software diseñar 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.
Más bien, propone la mejora constante del código (refactorización) para hacer los cambios más fácilmente cuando ellos tienen que implementarse.
13/04/23 784
Pruebas en XP Desarrollo de primera prueba. Desarrollo de pruebas incrementales desde
escenarios. Involucrar al usuario en el desarrollo de pruebas
y validación. Los enseres de prueba automatizada son usadas
para ejecutar cada vez que un nuevo lanzamiento se construye.
13/04/23 785
Tarjetas de tarea para transmisión de documento
Tarea 1: Implementar el flujo de trabajo principal
Tarea 2: Implementar el catálogo del artículo y selección
Tarea 3: Implementar la colección de pago
El pago puede ser hecho de 3 maneras. El usuario selecciona una de las maneras de pagar. Si el usuario tiene una suscripción de librería, entonces puede ingresar las clave de suscripción que será verificada por el sistema; alternativamente puede ingresar un número de cuenta organizacional. Si es válido una nota con el costo del artículo será enviado por correo a esa cuenta. Finalmente pueden ingresar 16 dígitos del número de cuenta de una tarjeta de crédito 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 crédito.
13/04/23 786
Descripción de caso de prueba
Tarea 4: Validación de la tarjeta de crédito
Entrada:
Una cadena que representa el número de cuenta de la tarjeta de crédito y dos enteros que representan el mes y el año de expiración de la tarjeta.
Pruebas:
Revisar que todos los bytes de la cadena sean dígitos.
Revisar que el mes este entre 1 y 12 y que el año sea mayor o igual al año en curso.
Usando los 4 primeros dígitos del número de la tarjeta de crédito revisar que el emisor de la tarjeta es válido, buscando la tabla de emisores de tarjeta. Revisar la validez de la tarjeta de crédito sometiendo el número de tarjeta y la información de la fecha de expiración del emisor de la tarjeta.
Salida:
OK en el mensaje de error, indica que la tarjeta no es válida.
13/04/23 787
Desarrollo de primera prueba
Escribir las pruebas antes que el código clarifique los requerimientos a ser implementados.
Las pruebas son escritas como programas en lugar de los datos de modo que puedan ejecutarse automáticamente. La prueba incluye una revisión de que se ha ejecutado correctamente.
Todas las pruebas previas y nuevas son automáticamente ejecutadas cuando una nueva funcionalidad es añadida. Así se verifica que la nueva funcionalidad no introduce errores.
13/04/23 788
Programación por pares En XP, los programadores trabajan por pares,
sentándose juntos para desarrollar código. Esto ayuda a desarrollar una propiedad común del
código y extender el conocimiento a través del equipo. Sirve como un proceso de revisión informal puesto que
cada línea de código ha sido mirado por más de una persona.
Alienta la refactorización de modo que todo el equipo puede beneficiarse con esto.
Las mediciones sugieren que la productividad del desarrollo con la programación por pares es similar a la de dos personas que trabajan independientemente.
13/04/23 789
Desarrollo rápido de aplicaciones
Los métodos ágiles han recibido mucha atención, pero otras aproximaciones para el desarrollo rápido de aplicaciones han sido usados durante muchos años.
Estas son diseñadas para desarrollar aplicaciones de negocios de datos intensivos y confiar en la programación y presentación de información desde una base de datos.
13/04/23 790
Herramientas del ambiente DRA
Lenguaje de programación de base de datos
Generador de interfazEnlace con aplicaciones para oficinaGenerador de informes
13/04/23 791
Un ambiente DRA
Ambiente del desarrollo rápido de aplicaciones
Lenguaje de programación de
BD
Lenguaje de programación de
BD
Generador de interfaz
Generador de interfaz
Sistemas de Oficina
Sistemas de Oficina
Generador de informes
Generador de informes
Sistema de gestión de bases de datosSistema de gestión de bases de datos
13/04/23 792
Generación de interfaz Muchas aplicaciones están 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 generación de pantallas que incluye: Definición de formularios interactivos usando técnicas
de arrastrar y soltar; Enlace de formularios donde la secuencia de
formularios para ser presentadas está especificada; Verificación de los formularios cuando se definen
rangos permitidos en los campos del formulario.
13/04/23 793
Programación visual Los lenguajes de guiones tales como Visual
Basic soportan programación visual donde el prototipo es desarrollado por creación de una interfaz de usuario a partir de artículos estándares y componentes asociados con esos artículos.
Existe una librería grande de componentes para dar soporte este tipo de desarrollos.
Estos pueden ser adecuados para satisfacer los requerimientos de una aplicación específica.
13/04/23 794
Programación visual con reuso
Archivo Editar Ver Configurar Opciones Ayuda
General Índice
3.876
12 de enero, 2006
Componente de fecha
Componente de fecha
Guión que verifica rangoGuión que
verifica rango
Componente de dibujo Canvas
Componente de dibujo Canvas
Componente de menú
Componente de menú
Componente de despliegue de árbolComponente de
despliegue de árbol
Componente de aviso al usuario +
Guión
Componente de aviso al usuario +
Guión
13/04/23 795
Problemas con el desarrollo visual
Dificultad para coordinar el desarrollo basado en equipo.
Ninguna arquitectura explícita del sistema.Dependencias complejas entre las partes
de un programa pueden causar problemas de mantenimiento.
13/04/23 796
Reuso de COTS Un acercamiento eficaz al desarrollo rápido es
para configurar y ligar con sistemas existentes fuera del anaquel.
Por ejemplo, un sistema de gestión de requerimientos podría construirse usando: Una base de datos para almacenar requerimientos; Un procesador de textos para capturar requerimientos
y un formato de informes; Una hoja de cálculo para gestión de trazabilidad.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 797
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 cálculo) que permite cálculos del usuario.
Cada elemento activo tiene una aplicación asociada que se invoca cuando ese elemento se selecciona.
El propio documento es el integrador para las aplicaciones diferentes.
13/04/23 798
Vinculación de la aplicación
Documentos del compuesto
Texto 1Texto 1 Tabla 1Tabla 1 Texto 2Texto 2 Texto 3Texto 3 Sonido 1Sonido 1
Tabla 2Tabla 2 Texto 4Texto 4 Texto 5Texto 5Sonido 2Sonido 2
Procesador de textos
Procesador de textos
Hoja de cálculo
Hoja de cálculo
Ejecutor de audio
Ejecutor de audio
13/04/23 799
Prototipado de software Un prototipo es una versión inicial de un sistema usado
para demostrar conceptos y probar opciones de diseño. Un prototipo puede ser usado en:
El proceso de ingeniería de requerimientos para ayudar con la elicitación de requerimientos y validación;
En los procesos de diseño para explorar opciones y desarrollar un diseño de IU;
En el proceso de pruebas para correr pruebas de fondo a fondo.
13/04/23 800
Beneficios del prototipado
Mejora la utilidad del sistema.Un partido íntimo para las necesidades
reales de los usuarios.Mejora la calidad del diseño.Mejora la mantenibilidad.Reduce el esfuerzo de desarrollo.
13/04/23 801
Prueba fondo a fondoDatos de prueba
Datos de prueba
Prototipo del sistema
Prototipo del sistema Sistema de
aplicación
Sistema de aplicación
Comparador de resultados
Comparador de resultados
Informe de resultados
Informe de resultados
13/04/23 802
El proceso de prototipado
Establecer los objetivos del
prototipo
Establecer los objetivos del
prototipo
Plan del prototipado
Plan del prototipado
Definir la funcionalidad del prototipo
Definir la funcionalidad del prototipo
Desarrollar el
prototipo
Desarrollar el
prototipo
Evaluar el
prototipo
Evaluar el
prototipo
Definición del contorno
Definición del contorno
Prototipo ejecutable
Prototipo ejecutable
Informe de evaluación
Informe de evaluación
13/04/23 803
Los prototipos desechables Los prototipos deben ser desechables después
del desarrollo, de modo que ellos no son buena base para un sistema de producción: 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
través del cambio rápido; El prototipo probablemente no reunirá los estándares
de calidad organizacional normal.
13/04/23 804
Puntos clave Una aproximación iterativa para el desarrollo del
software lleva a la entrega rápida del software. Los métodos ágiles son métodos de desarrollo iterativo
que apunta a reducir el desarrollo sobre la cabeza y así producir software más rápidamente.
La programación extrema incluye prácticas como las pruebas sistemáticas, mejora continua y participación del cliente.
La aproximación de pruebas en XP es un fuerza particular donde pruebas ejecutables son desarrolladas antes de que el código sea escrito.
13/04/23 805
Puntos clave Los ambientes del desarrollo rápido de aplicaciones
incluye lenguajes de programación de bases de datos, herramientas de generación de formularios y enlaces con aplicación de oficina.
Un prototipo desechable es usado para explorar los requerimientos y opciones de diseño.
Cuando se implementa un prototipo desechable, empieza con los requerimientos que se entienda menos; en desarrollo incremental; empieza con los requerimientos bien entendidos.
13/04/23 806
Reuso del software
Capítulo 18
13/04/23 807
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 líneas de producto de
software
13/04/23 808
Tópicos cubiertosEl reuso del paisajePatrones de diseñoReuso basado en generadorFrameworks de aplicaciónReuso de sistemas de aplicación
13/04/23 809
Reuso de software En más disciplinas de ingeniería, los sistemas
son diseñados por composición de componentes existentes que han sido usados en otros sistemas.
La ingeniería de software ha sido enfocada en el desarrollo original, pero ahora se reconoce que para lograr un buen software, más rápidamente y con un menor costo, necesitamos adoptar procesos basados en el reuso de software sistemático.
13/04/23 810
Ingeniería de software basada en el reuso
Reuso de sistemas de aplicación El total de un sistema de aplicación puede ser reusado
incorporándolo sin cambios en otros sistemas (reuso de COTS) o por desarrollo de familias de aplicaciones.
Reuso de componentes Los componentes de una aplicación desde un subsistema
para objetos singulares pueden ser reusados. Cubierto en el capítulo 19.
Objeto y reuso de función Componentes de software que implementan un objeto solo
bien definido o una función puede ser reusada.
13/04/23 811
Beneficios del reuso 1Confiabilidad creciente
El software reusado, que ha sido ensayado y probado en sistemas activos, debe ser más fidedigno que el nuevo software. El uso inicial del software revela algún diseño y fallas de implementación. Estos son entonces fijados, y de esa manera van reduciendo el número de fallas cuando el software es reusado.
Riesgo de proceso reducido
Si el software existe, hay menos incertidumbre en los costos de reusar este software que en los costos de desarrollo. Este es un factor importante para la gestión del proyecto, puesto que reduce el margen de error en la estimación del costo del proyecto . Esto es particularmente verdadero cuando se reusan componentes del software relativamente grandes como los subsistemas.
Uso efectivo de especialistas
En lugar de especialistas de la aplicación que hacen el mismo trabajo en proyectos diferentes, estos especialistas pueden desarrollar software reusable que encapsula su conocimiento.
13/04/23 812
Beneficios del reuso 2Complacencia de los estándares
Algunos estándares, como los estándares de interfaz del usuario, pueden ser implementados, como un conjunto de componentes reusables estándares. Por ejemplo, si se implementan menús en unas interfaces de usuario, usando componentes reusables, todas las aplicaciones presentan la misma estructura de menús a los usuarios. El uso de estándares 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 acelerado
Traer un sistema para comercializar lo más pronto posible, es a menudo, más importante que los costos de desarrollo globales. Reusando el software, se puede acelerar la producción del sistema, porque el desarrollo y el tiempo de validación deben ser reducidos.
13/04/23 813
Problemas del reuso 1Costos de mantenimiento crecientes
Si el código 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 soporte de herramientas
Los conjuntos de herramientas CASE no pueden dar soporte al desarrollo con reuso. Puede ser difícil o imposible de integrar estas herramientas con un sistema de librería de componentes. El proceso del software asumido por estas herramientas no puede tomar en cuenta el reuso.
No inventar aquí el síndrome
Algunos ingenieros del software, a veces, prefieren reescribir los componentes, cuando ellos creen que pueden mejorar el componente reusable. Este es en 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 más desafiante, que reusar el software de otras personas.
13/04/23 814
Problemas del reuso 2Creación y mantenimiento de una biblioteca de componentes
Si el código 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 librería, entender y, a veces, adaptar, para trabajar en un nuevo ambiente. Los ingenieros deben estar bastante seguros de hallar un componente en la librería, antes de que ellos hagan que rutinariamente se incluya una búsqueda del componente, como parte de su proceso de desarrollo normal.
13/04/23 815
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 aplicación.
El reuso de paisaje cubre el rango de técnicas de reuso posibles.
13/04/23 816
El reuso de paisajePatrones de diseño
Framework de componentes
Líneas de producto de aplicación
Desarrollo de software orientado
a aspectosDesarrollo basado en componentes La envoltura de
sistemas legadosIntegración de
COTSGeneración
de programas
Aplicaciones verticales
configurablesLibrería de programas
Sistemas orientados a
servicios
13/04/23 817
Aproximaciones de reuso 1Patrones de diseño Las abstracciones genéricas que ocurren a través de
aplicaciones son representadas como patrones de diseño que muestran objetos abstractos y concretos e interacciones.
Desarrollo basado en componentes
Los sistemas son desarrollados integrando los componentes (colecciones de objetos) que conforman los estándares del modelo de componentes. Esto se cubre en el Capítulo 19.
Framework de componentes
Las colecciones de clases abstractas y concretas que pueden adaptarse y pueden extenderse para crear los sistemas de aplicación.
Envoltura de sistemas legados
Los sistemas legados (ver Capítulo 2) que pueden ser "cubiertos" definiendo un conjunto de interfaces y proporcionando el acceso a éstos sistemas legados a través de estas interfaces.
Sistemas orientados a servicios
Los sistemas son desarrollados ligando servicios compartidos que pueden ser proporcionados externamente.
13/04/23 818
Aproximaciones de reuso 2Líneas de producto de aplicación
Un tipo de la aplicación es generalizado alrededor de una arquitectura común, para que pueda adaptarse a las diferentes maneras para diferentes clientes.
Integración de COTS
Los sistemas son desarrollados por integración de sistemas de aplicación existentes.
Aplicaciones verticales de configuración
Un sistema genérico es diseñado para que pueda configurarse a las necesidades de los clientes del sistema específico.
Librerías de programas
Las clases y bibliotecas de funciones que implementan las abstracciones comúnmente usadas están disponibles para el reuso.
Generadores de programas
Un sistema generador empotra conocimiento de unos tipos particulares de aplicación y puede generar sistemas o fragmentos del sistema en ese dominio.
Desarrollo de software orientado a aspectos
Los componentes compartidos se entrelazan en una aplicación, en los diferentes lugares cuando el programa se compila.
13/04/23 819
Factores de planificación de reuso
El programa de desarrollo para el software. La expectativa del tiempo de vida de software. Los antecedentes, habilidades y experiencia del
equipo de desarrollo. La criticidad del software y sus requerimientos
no funcionales. El dominio de aplicación. La plataforma de ejecución para el software.
13/04/23 820
Reuso de conceptos Cuando se reusa programas o componentes de diseño, se
tiene que seguir las decisiones de diseño hechas por el desarrollador original del componente.
Esto puede limitar las oportunidades de reuso. Sin embargo, una forma más abstracta de reuso, es el
concepto de reuso cuando una aproximación particular es descrita en una manera de implementación independiente y una implementación es entonces desarrollada.
Las dos principales aproximaciones para el reuso de conceptos son: Patrones de diseño; Programación generativa.
13/04/23 821
Patrones de diseño Un patrón de diseño es una manera de reuso de
un conocimiento abstracto acerca de un problema y su solución.
Un patrón es una descripción de un problema y la esencia de su solución.
Debe ser lo suficientemente abstracto para ser reusado en diferentes configuraciones.
Los modelos a menudo confían en las características del objeto, como la herencia y el polimorfismo.
13/04/23 822
Elementos de un patrón Nombre
Un identificador significativo del patrón. Descripción del problema. Descripción de la solución
No un diseño concreto, pero es una plantilla para una solución de diseño que pude ser instanciado de diferentes maneras.
Consecuencias Los resultados y los intercambios de la aplicación del
patrón.
13/04/23 823
Múltiples despliegues
40%
25%
15%
20%
A
B
C
D
40%
25%
15%
20%
A
B
C
D
0
10
20
30
40
A B C D0
10
20
30
40
A B C D
Asunto
A 40
B 25
C 15
D 20
Observador 1Observador 1 Observador 2Observador 2
13/04/23 824
El patrón del observador
Nombre Observador.
Descripción Separa el despliegue de estado de objetos desde el
mismo objeto. Descripción del problema
Usado cuando se necesita múltiples despliegues de estado.
Descripción de la solución Ver la transparencia con una descripción UML.
Consecuencias Las optimizaciones para reforzar el desempeño del
despliegue son impracticables.
13/04/23 825
El patrón del observador
AsuntoConcretoestadoAsunto
DarEstado()
ObservadorConcretoestadoObservador
Actualizar()
Asunto
Atar(Observador)Desatar(Observador)Notificar()
Observador
Actualizar()**
Devuelve estadoAsunto
estadoObservador = Asunto -> DarEstado()
Para todos los usuarios permitidoso -> Actualizar()
13/04/23 826
Reuso basado en generador
Los generadores de programa involucran el reuso de patrones estándar y algoritmos.
Estos son incluidos en el generador y parametrizados por los comandos del usuario. Entonces se genera automáticamente un programa.
El reuso basado en generador es posible cuando pueden identificarse las abstracciones del dominio y su correspondencia con el código ejecutable.
Un lenguaje de un dominio específico se usa componer y controlar estas abstracciones.
13/04/23 827
Tipos de generador de programa
Tipos de generador de programa Generador de aplicaciones para procesamiento de
datos de negocios; Generador de analizador gramatical y de léxico para
procesamiento de lenguaje; Generadores de código en herramientas CASE.
El reuso basado en generadores es muy rentable, pero su aplicabilidad está limitada para un número relativamente pequeño de dominios de aplicación.
Es más fácil para los usuarios finales desarrollar programas que usan los generadores comparados con otras aproximaciones de reuso basados en componentes.
13/04/23 828
Reuso a través de generación de programa
Descripción de la
aplicación
Descripción de la
aplicaciónGenerador de
programa
Generador de programa
Programa generado
Programa generado
Conocimiento del dominio del problema
Conocimiento del dominio del problema
Base de datos
Base de datos
13/04/23 829
Desarrollo orientado a aspectos
El desarrollo orientado a aspectos se dirige a un problema mayor de ingeniería de software – la separación de intereses.
Las preocupaciones no están a menudo asociadas absolutamente con la funcionalidad de la aplicación, pero están 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 dinámicamente en un programa. El código concerniente es reusar y el nuevo sistema se genera por el entrelazador del aspecto.
13/04/23 830
El desarrollo orientado a aspectos
<estamento 1>
punto de unión 1
<estamento 2>
punto de unión 2
Ingresar código fuente
<estamento 1>
Aspecto 1
<estamento 2>
Aspecto 2
Generador de código
Entrelazador de Aspecto
Entrelazador de Aspecto
Aspecto 1 Aspecto 1 Aspecto 2 Aspecto 2
13/04/23 831
Frameworks de aplicación Los frameworks son un diseño de subsistema
compuesto de una colección de clases abstractas y concretas y las interfaces entre ellas.
El subsistema es implementado por adición de componentes para llenar en partes del diseño y por instanciación de clases abstractas en el framework.
Los frameworks son entidades moderadamente grandes que pueden ser reusadas.
13/04/23 832
Clases de frameworks Frameworks de infraestructura de sistemas
Suporta el desarrollo de las infraestructuras de sistemas tales como comunicaciones, interfaces de usuario y compiladores.
Frameworks de integración de middleware Estándares y clases que soportan comunicación de
componentes e intercambio de información. Frameworks de aplicación empresarial
Soporta el desarrollo de tipos específicos de aplicación, tales como telecomunicaciones o sistemas financieros.
13/04/23 833
Extendiendo de frameworks Las frameworks son genéricos y son extendidos para
crear una aplicación más específica o subsistema. La extensión del framework involucra
Adición de clases concretas que heredan operaciones desde clases abstractas en el framework;
Adición de métodos 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.
13/04/23 834
Controlador del modelo vista
El framework de la infraestructura de sistema para el diseño IGU.
Permite múltiples presentaciones de un objeto y las interacciones separadas con estas presentaciones.
El framework CMV involucra la instanciación de un número de patrones (como discutido antes bajo el concepto de reuso).
13/04/23 835
Controlador del modelo vista
Métodos del controlador
Estado del controlador
Métodos de la vista
Estado de la vista
Métodos del modelo
Estado del modelo
Entradas del usuario
Ediciones del modelo
Consultas ya actualizaciones
del modelo
Mensajes de modificación de las vistas
13/04/23 836
Reuso de sistemas de aplicación
Involucra el reuso de sistemas de aplicación enteras o por configuración de un sistema para un ambiente o por integración de dos o más sistemas para crear una nueva aplicación.
Dos aproximaciones cubiertas aquí: Integración de producto COTS; Desarrollo de línea de producto.
13/04/23 837
Reuso de producto COTS COTS - Commercial Off-The-Shelf systems= Stock
comercial disponible Los sistemas COTS son normalmente usados en
sistemas de aplicación completos que ofrecen un API (Application Programming Interface = Interfaz de Programas de Aplicación).
Construyendo sistemas grandes por integración de sistemas COTS es nuevo es ahora una estrategia de desarrollo viable para algunos tipos de sistemas tales como sistema de comercio electrónico (E-commerce).
El beneficio clave es el desarrollo de aplicación más rápido y normalmente bajos costos de desarrollo.
13/04/23 838
Opciones de diseño COTS ¿Qué productos COTS ofrecen la funcionalidad más
adecuada? Puede haber varios productos similares que pueden
usarse. ¿Cómo se intercambiarán los datos?
Los productos individuales usan sus propias estructuras de datos y formatos.
¿Qué aspectos del producto serán realmente usados? La mayoría de los productos tienen más
funcionalidad de la que se necesita. Se debe intentar negar el acceso a la funcionalidad no usada.
13/04/23 839
Sistema de E-procuración
ClienteNavegador de la Web
Navegador de la Web
Sistema de Correo Electrónico
Sistema de Correo Electrónico
Sistema de Comercio
Electrónico
Sistema de Comercio
Electrónico
AdaptadorAdaptadorSistema de Pedido y
facturación
Sistema de Pedido y
facturación
Sistema de Correo Electrónico
Sistema de Correo Electrónico
AdaptadorAdaptador
Servidor
13/04/23 840
Productos COTS reusados En el cliente, el correo electrónico estándar y los
navegadores de la Web son usados. En el servidor, una plataforma de comercio electrónico tiene
que ser integrada con un sistema de clasificación existente. Esto involucra escritura de un adaptador de modo que
ellos pueden intercambiar datos. Un sistema del correo electrónico también se integra para
generar el correo electrónico para los clientes. Esto también exige un adaptador para recibir los datos de la clasificación y un sistema de facturación.
13/04/23 841
Problemas de integración de los sistemas COTS
Falta de control sobre la funcionalidad y el desempeño 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 integración es difícil.
Ningún control sobre la evolución de sistemas Los vendedores de COTS y no lo usuarios del sistema
controlan la evolución. El soporte de los vendedores de COTS
Los vendedores de COTS no pueden ofrecer soporte sobre el tiempo de vida del producto.
13/04/23 842
Líneas de producto de software
Las líneas de producto de software o familias se aplicaciones son aplicaciones con funcionalidad genérica que pueden ser adaptadas y configuradas para su uso en un contexto específico.
La adaptación puede involucrar: Configuración de componentes y sistemas; Adición de nuevos componentes para el sistema; Seleccionando desde una librería de componentes
existentes; Modificando componentes para reunir nuevos
requerimientos.
13/04/23 843
Especialización de producto COTS Especialización de plataforma
Diferentes versiones de la aplicación son desarrolladas para diferentes plataformas.
Especialización del ambiente Diferentes versiones de la aplicación son creadas para
manejar diferentes ambientes de operación, por ejemplo, diferentes tipos de equipos de comunicación.
Especialización funcional Diferentes versiones de la aplicación son creadas para
clientes con diferentes requerimientos. Especialización de procesos
Diferentes versiones de la aplicación son creadas para dar soporte a diferentes procesos de negocios.
13/04/23 844
Configuración de COTS Configuración del tiempo de despliegue
Un sistema genérico es configurado por conocimiento encajado de los requerimientos de los clientes y procesos de negocios. El software en si no se cambia.
Configuración del tiempo de diseño Un código genérico común es adaptado y cambiado
de acuerdo a los requerimientos de clientes particulares.
13/04/23 845
Organización del sistema ERP
Herramientas de planificación de configuración
Herramientas de planificación de configuración
Base de datos de la
configuración
Base de datos de la
configuración
Base de datos del sistemaBase de datos del sistema
Sistema genérico PRE
13/04/23 846
Sistemas PRE Un sistema de Planificación de Recursos de la
Empresa (PRE) (ERP= Enterprise Resource Planning) es un sistema genérico que da soporte a procesos comunes de negocios como pedidos y facturación, manufactura, etc.
Estos son muy ampliamente usados en las compañías grandes - ellos representan probablemente la forma más común de reuso de software.
El centro genérico es adaptado por inclusión de módulos e incorporando conocimiento de procesos de negocios y reglas.
13/04/23 847
Configuración del tiempo de diseño
Las líneas de producto de software que han sido configuradas en tiempo de diseño son instanciaciones de arquitecturas de aplicación genérica como se discute en el Capítulo 13.
Normalmente los productos genéricos emergen después de la experiencia con productos específicos.
13/04/23 848
Arquitecturas de línea de producto
Las arquitecturas deben ser estructuradas de tal manera que separa diferentes subsistemas y les permite ser modificadas.
La arquitectura también debe separar entidades y sus descripciones y los más altos niveles en que el sistema accede a las entidades a través de descripciones en lugar de directamente.
13/04/23 849
Un sistema de gestión de recursos
Interfaz de usuarioInterfaz de usuario
Autenticación del usuario
Entrega del recurso
Gestión de consultas
Gestión de recursos
Control de política de recursos
Asignación de recursos
Gestión de la transacción
Base de datos del recurso
13/04/23 850
Despacho de vehículos Un sistema de gestión de recurso especializado donde el
objetivo es asignar recursos (vehículos) para manejar incidentes.
Las adaptaciones incluyen: Al nivel de IU, hay componentes para el despliegue del
operador y comunicaciones; Al nivel de gestión de I/O; hay componentes me manejan
la autenticación, informe y planificación de ruta; Al nivel de gestión del recurso, hay componentes par
ubicación de vehículos y despacho, estado del vehículo manejado y registro de incidente;
La base de dato incluye equipo, vehículo y base de datos de mapas.
13/04/23 851
Despacho de vehículos
Interfaz de usuarioInterfaz de sistema de
comandos
Autenticación del operador
Planificador de mapa y ruta
Generador de informes
Generador de consultas
Manejador del estado del vehículo
Registrador del incidente
Despachador del vehículo
Manejador del evento
Localizador de vehículo
Base de datos del equipo
Gestión de transacciones
Registro de incidente
Base de datos del vehículo
Base de datos mapas
13/04/23 852
Desarrollo de instancia del producto
Elicitar los requerimientos
de los involucrados
Elicitar los requerimientos
de los involucrados
Elegir los miembros de familia más adecuados
Elegir los miembros de familia más adecuados
Adaptar al sistema
existente
Adaptar al sistema
existente
Renegociar los requerimientos
Renegociar los requerimientos
Entregar nueva familia de miembros
Entregar nueva familia de miembros
13/04/23 853
Desarrollo de instancia del producto
Elicitar los requerimientos del involucrado (stakeholder) Usar miembro de la familia como un prototipo.
Elegir el miembro de familia más 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 módulos 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.
13/04/23 854
Las ventajas del reuso son los bajos costos , desarrollo rápido del software y más bajos riesgos.
Los patrones de diseño son abstracciones de alto nivel que documentan suficientemente las soluciones de diseño.
Los generadores de programa también se preocupan por el reuso del software – los conceptos reusables son incluidos en el sistema generador.
Los frameworks de aplicación son colecciones de objetos concretos y abstractos que son diseñados para el reuso a través de la especialización.
Puntos clave
13/04/23 855
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, desempeño y evolución, y problemas con la interoperación.
Los sistemas PRE son creados ERP por configuración de un sistema genérico con información acerca de los negocios de los clientes.
Las líneas de producto de software son el desarrollo de aplicaciones relacionadas alrededor de un centro común de funcionalidad compartida.
13/04/23 856
Ingeniería del software basada en componentes
Capítulo 19
13/04/23 857
Objetivos Explicar que la ISBC (Ingeniería de software basada en
componentes) [CBSE = Component-based software engineering] se preocupa por el desarrollo de componentes estandarizadas y la composición 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 composición de componentes y problemas que pueden levantarse
13/04/23 858
Tópicos cubiertosComponentes y modelos de
componentesEl proceso de ISBCComposición de componentes
13/04/23 859
Desarrollo basado en componentes
La Ingeniería de software basada en componentes (ISBC) es una aproximación para el desarrollo de software que confía en el reuso de software.
Emerge del fracaso del desarrollo orientado a objetos para soportar el reuso efectivo. Las clases de objetos singulares son también detallados y especificados.
Los componentes son más abstractos que las clases de objetos y pueden considerarse que son los proveedores de servicios autosuficientes.
13/04/23 860
Lo esencial de ISBC Componentes independientes especificados
por sus interfaces. Estándares de componentes para facilitar la
integración de componentes. Middleware que provee de soporte para la
interoperatividad de componentes. Un proceso de desarrollo que es engranado
para el reuso.
13/04/23 861
ISBC y principios de diseño
Aparte de los beneficios de reuso, la ISBC se basa en principios de diseño de ingeniería de software sólidos: Las componentes son independientes para que no
interfieran entre sí; Las implementaciones de componentes están ocultas; La comunicación es a través de interfaces bien
definidas; Las plataformas de componentes son compartidas y
reducen los costos de desarrollo.
13/04/23 862
Problemas de la ISBC Fidelidad de componentes - ¿cómo se puede
confiar en un componente sin el código fuente disponible?
Certificación de componentes - ¿quién certificará la calidad de los componentes?
Predicción de propiedades emergentes - ¿cómo las propiedades emergentes de la composición de componentes pueden predecirse?
Los intercambios de requerimientos - ¿cómo hacemos el análisis del intercambio entre los rasgos de un componente y otro?
13/04/23 863
Componentes Los componentes proporcionan un servicio sin
tener en cuenta dónde se está ejecutando el componente o el lenguaje de programación. 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 través de la interfaz publicada;
13/04/23 864
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 modificación según un estándar de composición.
Szyperski: Un componente de software sólo es una unidad de
composición con las interfaces especificadas contractualmente y las dependencias del contexto explícitas. Un componente del software puede ser desplegada independientemente y está sujeto a la composición de terceras partes.
13/04/23 865
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 están de hecho disponible a través de una interfaz y todas las interacciones del componente tienen lugar a través de esa interfaz.
13/04/23 866
Características de componente 1
Estandarizado La estandarización de componentes significa que un componente que es usado en un proceso de ISBC tiene que conformar algún modelo de componentes estandarizado. Este modelo puede definir interfaces de componente, metadatos de componentes, composición y despliegue.
Independiente Un componente debe ser independiente - debe ser posible componer y desplegarlo sin tener que usar otros componentes específicos. En situaciones dónde el componente necesita servicios proveídos externamente, éstos deben ser explícitamente colocados fuera de una especificación de interfaz "pedida".
Componible Para que un componente sea componible, todas las interacciones externas deben tener lugar a través de las interfaces públicamente definidas para un componente. Además, debe proporcionar el acceso externo a la información sobre sí misma, así como sus métodos y atributos.
13/04/23 867
Características de componente 2
Desplegable Para ser desplegable, un componente tiene que ser autónomo 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 semántica de todas las interfaces del componente tienen que ser especificadas.
13/04/23 868
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.
13/04/23 869
Interfaces de componente
Componente
Proporciona interfaz
Define los servicios que son proporcionados
por el componente a
otros componentes.
Define los servicios desde el ambiente de los componentes que
usa
Requiere interfaz
13/04/23 870
Un componente de recolector de datos
Recolector de datos
Proporciona interfaz
gestiónSensor
Requiere interfaz
datosSensor
agregarSensor
quitarSensor
iniciarSensor
pararSensor
probarSensor
inicializar
informe
listarTodo
13/04/23 871
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 están estandarizados.
13/04/23 872
Modelos de componentes Un modelo de componente es una definición de
estándares para la implementación 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 cómo deben definirse las interfaces y los elementos que deben ser incluidos en una definición de la interfaz.
13/04/23 873
Elementos de un modelo de componente
Modelo de componentes
Interfaces Información de uso
Despliegue y uso
Definición de interfaz
Especificar la interfaz
Composición
Acceso a metadatos Embalaje
Soporte de evolución
Convención de nominación
Adaptación
Documentación
13/04/23 874
Soporte middleware Los modelos de componentes son la base para el
middleware que proporciona soporte para la ejecución 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 aplicación
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.
13/04/23 875
Servicios del modelo de componentes
Servicios horizontales
Gestión de componentes
Concurrencia
Gestión de transacciones
Persistencia
Gestión de recursos
Seguridad
Servicios de plataforma
Direccionamiento Definición de interfaz
Gestión de excepción
Comunicación de componentes
13/04/23 876
Desarrollo de componentes para reuso
Los componentes son desarrollados para una aplicación específica normalmente tienen que ser generalizados para hacerlos reusables.
Un componente es lo más probablemente a ser reusable si es asociado con una abstracción de dominio estable (objeto de negocios).
Por ejemplo, en un hospital las abstracciones son asociados con el propósito fundamental – enfermeras, pacientes, tratamientos, etc.
13/04/23 877
Desarrollo de componentes para reuso
Los componentes para reuso puede ser construidos especialmente por generalización de componentes existentes.
Reutilidad de componentes Debe reflejar abstracciones de un dominio estable; Debe ocultar la representación de estado; Debe ser tan independiente como sea posible; Debe publicar excepciones a través de la interfaz de
componente. Hay un intercambio entre reutilidad y utilidad
Lo más general la interfaz, lo mayor la reutilidad pero es entonces de lo más complejo y de lo menos usable.
13/04/23 878
Cambios para reutilidad Quitar los métodos de aplicación específicos. Los cambios de nombre para hacerlo general. Agregar métodos para ensanchar la cobertura. Hacer un consistente manejo de la excepción. Agregar una interfaz de configuración para la
adaptación del componente. Integrar los componentes requeridos para
reducir dependencias.
13/04/23 879
Componentes de un sistema legado
Los sistemas de legado existentes que cumplen una función 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.
13/04/23 880
Componentes reusables El costo de componentes reusables puede ser
más alto que el costo de equivalentes específicos. Este costo de perfeccionamiento de reutilidad extra debe ser una organización antes que un costo del proyecto.
Componentes genéricos pueden ser menos eficientes en espacio y pueden tener el tiempo de ejecución más largo que sus equivalentes específicos.
13/04/23 881
El proceso de ISBC 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 reúnan los requerimientos revisados.
13/04/23 882
El proceso de ISBC
Requerimientos de entorno del
sistema
Requerimientos de entorno del
sistema
Identificar componentes
candidatos
Identificar componentes
candidatos
Modificar los requerimientos de acuerdo a componentes descubiertos
Modificar los requerimientos de acuerdo a componentes descubiertos
Diseño arquitectónico
Diseño arquitectónico
Identificar componentes
candidatos
Identificar componentes
candidatos
Componer componentes para crear el
sistema
Componer componentes para crear el
sistema
13/04/23 883
El proceso de identificación de componentes
Búsqueda de componentesBúsqueda de componentes
Selección de componentes Selección de
componentes Validación de componentes Validación de componentes
13/04/23 884
Problemas de identificación 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 según lo ha anunciado, y en el peor de los casos puede abrir su brecha de seguridad.
Requerimientos. Diferentes grupos de componentes satisfarán diferentes requerimientos.
Validación. La especificación 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. ¿Cómo puede usted probar que esto no interferirá con su aplicación?
13/04/23 885
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 después del despegue.
El problema se debió a un componente reusado desde una versión anterior del lanzador (Sistema de Navegación 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.
13/04/23 886
Composición de componentes
El proceso de ensamblaje de componentes para crear un sistema.
La composición involucra los componentes entre sí y con la infraestructura de componentes.
Normalmente usted tiene que escribir "pegando código" para integrar los componentes.
13/04/23 887
Tipos de composición Composición secuencial donde la composición de
componentes son ejecutados en secuencia. Esto involucra la composición para proporcionar interfaces para cada componente.
Composición jerárquica donde un componente llama los servicios de otro. El proporciona una interfaz de un componente y esta requiere la interfaz de otro.
Composición aditiva donde las interfaces de dos componentes se ponen juntas a crear un nuevo componente.
13/04/23 888
Tipos de composición
A
B
A
B
A A
(a) (b) (c)
13/04/23 889
Incompatibilidad de interfaz Incompatibilidad de parámetro donde las
operaciones tienen el mismo nombre pero son de diferentes tipos.
Incompatibilidad de operación donde los nombres de la operación en las interfaces son diferentes.
Incompletitud de operación donde la interfaz proporcionada de un componente es un subconjunto que requiere la interfaz de otro.
13/04/23 890
Componentes incompatibles
Ubicación de cadena (cadena pn)fonoBaseDatos(comando de cadena)
Propietario de cadena (cadena pn)
Cadena propiedadTipo(cadena pn)
despliegaMapa (cadena código postal, escala)
mapaBD(comando de cadena)
imprimeMapa (cadena código postal, escala)
halladorDirección
mapeador
13/04/23 891
Componentes de adaptador Dirigir el problema de incompatibilidad del
componente reconciliando las interfaces de los componentes que están compuestos.
Diferentes tipos de adaptador son requeridos dependiendo del tipo de composición.
Un halladorDirección y un componente mapeador pueden ser compuestos a través de un adaptador que despeja el código postal de una dirección y lo pasa a un componente del mapeador.
13/04/23 892
dirección = halladorDirección.ubicación (númeroTelefónico);
códigoPostal = códigoPostalDespojador.obtenerCódigoPostal (dirección);
mapeador.desplegarMapa(postalCódigo, 10000)
Composición a través de un adaptador
El componente códigoPostalDespojador es el adaptador que facilita la composición secuencial de halladorDirección y componentes del mapeador.
13/04/23 893
Adaptador para el recolector de datos
Recolector de datos
gestiónSensor
datosSensor
agregarSensor
quitarSensor
iniciarSensor
pararSensor
probarSensor
inicializar
informe
listarTodo
AdaptadorSensor
iniciar
parar
obtenerDato
13/04/23 894
Semánticas de la interfaz Se tiene que confiar en la documentación del
componente para decidir si las interfaces que son sintácticamente compatibles son realmente compatibles.
Considerar una interfaz para un componente LibreríaFotos:
public void agregarItem (Identificador pid ; Fotografía p; EntradaCatálogo descfoto) ;
public RecuperarFotografía (Identificador pid) ;
public EntradaCatálogo EntCata (Identificador pid) ;
13/04/23 895
Composición de librería de Fotos
Gestor de ImagenAdaptador
Interfaz de usuario
Librería de Fotos
agregarItem
recuperar
entCata
obtenerImagen
obtenerEntradaCatálogo
13/04/23 896
Documentación de librería de fotos
“Este método agrega una fotografía a la librería y asocia el identificador de la fotografía y el descriptor del catálogo con la fotografía.”
“¿qué pasa si el identificador de la fotografía ya está asociado con una fotografía en la librería?”
“¿está el descriptor de la fotografía asociado con la entrada del catálogo además de la fotografía, es decir si yo anulo la fotografía, también anulo la información del catálogo?”
13/04/23 897
El lenguaje de restricción de objetos
El lenguaje de restricción de objetos (LRO) [OCL = Object Constraint Language] ha sido diseñado para definir las restricciones que están asociadas con los modelos UML.
Está basada alrededor de la noción de especificación de pre y post condiciones - similar a la aproximación usada en Z como la descrita en el Capítulo 10.
13/04/23 898
Descripción formal de la librería 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 ejecución de addItem
pre: PhotoLibrary.libSize ()> 0
PhotoLibrary.retrieve(pid) = null
--Los post condiciones especifican lo que es verdad después de la ejecución
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
13/04/23 899
Condiciones de la librería de fotos
Como se ha especificado, el LRO se asocia con los estados de componentes de la Librería de Fotos que: No debe haber una fotografía en la librería con el mismo
identificador tal como la fotografía ha sido ingresada; La librería debe existir - asume que se crea una librería
agregando un artículo simple a ella. Cada nueva entrada aumenta el tamaño de la librería en
1; Si se recupera usando el mismo identificador entonces se
recupera la foto que se ha agregado; Si se busca el catálogo que usa ese identificador,
entonces se vuelve a la entrada del catálogo que se hizo.
13/04/23 900
Los cambios de composición 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 rápida y la evolución del sistema.
Se necesita tomar decisiones como: ¿Cuál composición de componentes es eficaz para
la entrega de los requerimientos funcionales? ¿Cuál composición de componentes es permite el
cambio futuro? ¿Cuáles serán las propiedades emergentes de los
sistemas compuestos?
13/04/23 901
Recolección de datos y generación de informe
Generador de informe
Gestión de datos Informe
Recolección de datos
Base de datos
Recolección de datos
(a)
(b) Informe
13/04/23 902
Puntos clave La ISBC es una aproximación basada en el reuso para
la definición e implementación de componentes débilmente acoplados en el sistema.
Un componente es una unidad de software cuya funcionalidad y dependencias están completamente definidas por sus interfaces.
Un modelo de componentes define un conjunto estándares que los proveedores de componentes y los compositores deben seguir.
Durante el proceso de ISBC, el proceso de ingeniería de requerimientos y el diseño de sistema se entrelazan.
13/04/23 903
Puntos clave La composición 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 evolución del sistema.
13/04/23 904
Desarrollo de sistemas críticos
Capítulo 20
13/04/23 905
Objetivos Explicar cómo la tolerancia de falla y anulación
de falla contribuyen al desarrollo de sistemas fidedignos
Describir las características de procesos de software fidedignos
Introducir técnicas de programación para la anulación de falla
Describir los mecanismos de tolerancia de falla y su uso de diversidad y redundancia
13/04/23 906
Tópicos cubiertosProcesos fidedignosProgramación fidedignaTolerancia de fallaArquitecturas tolerantes de fallas
13/04/23 907
Confiabilidad del software En general, los clientes del software esperan
todo del software para ser fidedigno. Sin embargo, para las aplicaciones no críticas, pueden estar dispuestos a aceptar algunas fallas del sistema.
Algunas aplicaciones, sin embargo, tienen los requerimientos de confiabilidad muy altos y las técnicas de ingeniería de software especiales puede ser usadas para lograr esto.
13/04/23 908
Logro de la confiabilidad Anulación 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.
Detección de falla Las técnicas verificación y validación son usados para
descubrir y remover fallas en un sistema antes que este sea desarrollado.
Tolerancia de falla El sistema es diseñado para que las faltas en el software
entregado no produzcan falla del sistema.
13/04/23 909
Diversidad y redundancia Redundancia
Guardar más de un aversión en un componente crítico 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 fallarán 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.
13/04/23 910
Ejemplos de redundancia y diversidad
Redundancia. Donde la disponibilidad es crítica (por ejemplo, en los sistemas de comercio electrónico), las compañías normalmente guardan los servidores de resguardo y cambian automáticamente 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).
13/04/23 911
Software libre de falla Los métodos actuales de la ingeniería de software ahora
permiten la producción de software libre de falla, por lo menos para los sistemas relativamente pequeños.
Software libre de falla significa software que está conforme a su especificación. Ello NO significa que el software siempre se desempeñará correctamente porque pude tener errores de especificación.
El costo de producción de falla de software libre es muy alto. Esto solo es rentable en situaciones excepcionales. A menudo, es más barato aceptar las fallas del software y pagar por sus consecuencias que expender los recursos en el desarrollo de software libre de falla.
13/04/23 912
Desarrollo de software libre de falla
Procesos de software fidedignoGestión de la calidadEspecificación formalVerificación estáticaMecanografía fuerteProgramación segura Información protegida
13/04/23 913
Costo de liberación de falla
Costo de liberación de fallas
0200400600800
1000
Muchos Pocos Muy pocos
Número de errores residuales
Co
sto
Costos
13/04/23 914
Procesos fidedignos Para asegurar un mínimo número 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; más bien puede ser presentado por diferentes personas.
Para la detección de fallas, está claro que las actividades del proceso deben incluir el desarrollo de significativo esfuerzo para la verificación y validación.
13/04/23 915
Características de procesos fidedignos
Documentable El proceso debe tener un modelo del proceso definido que presenta las actividades en el proceso y la documentación que será producida durante estas actividades.
Estandarizado Un conjunto comprensivo de estándares de desarrollo de software que definen cómo 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 estándares del proceso, debe continuarse y hacer las sugerencias para la mejorar del proceso.
Diverso El proceso debe incluir comprobación redundante y diversa y actividades de validación.
Robusto El proceso debe poder recuperar de las fallas de actividades del proceso individuales.
13/04/23 916
Actividades de validación Las inspecciones de requerimientos. Gestión de requerimientos. Chequeo del modelo. Inspección de diseño y código. Análisis estático. Planificación de prueba y gestión. Gestión de configuración discutido en el Capítulo
29, es también esencial .
13/04/23 917
Programación fidedigna Usar estructuras de programación y técnicas que
contribuyan a la anulación de falla y tolerancia de falla Diseño para la simplicidad; Proteger la información contra accesos no
autorizados; Minimizar el uso de estructuras de
programación inseguras.
13/04/23 918
Protección de información Sólo debe exponerse la información a las partes del programa
que se necesita acceder. Esto involucra la creación 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 corrupción accidental de información está
reducida; la información está rodeada por "cortafuegos", de modo que
los problemas están menos probablemente expuestos a expandirse a otras partes del programa;
como toda la información es localizada, es menos probable cometer errores y los inspectores más probablemente encontrarán errores.
13/04/23 919
Una especificación de cola en Java
interface Cola {
public void put (Object o) ;
public void remove (Object o) ;
public int tamaño () ;
} //Cola
13/04/23 920
Declaración de señal en Java
class Señal {
static public final int rojo = 1 ;
static public final int ambar = 2 ;
static public final int verde = 3 ;
public int señalEstado ;
}
13/04/23 921
Programación 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 programación son más propensas a error que otras, evitando así que su uso reduzca los errores del programador.
13/04/23 922
Programación estructurada Propuesta primero propuesto en 1968 como
una aproximación al desarrollo que hace los programas más fáciles 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. Diseño Top - down (Arriba – abajo). Un desarrollo importante porque promovió
pensamiento y discusión acerca de la programación.
13/04/23 923
Estructuras propensas a error Números de punto flotante
Inherentemente impreciso. La imprecisión puede llevar a comparaciones inválidas.
Puntero Los punteros que hacen referencia a áreas de memoria
erróneas pueden corromper datos. Los alias pueden hacer los programas difíciles de entender y cambiar.
Asignación de memoria dinámica La asignación de ejecución de programas puede causar
desborde de memoria. Paralelismo
Puede causar errores de sincronización sutiles a causa de interacción imprevista de procesos paralelos.
Recursión Errores en la recursión pueden causar desborde de memoria.
13/04/23 924
Estructuras propensas a error
Interrupciones Las interrupciones pueden causar una operación crítica para ser
terminada y hacer un programa difícil de entender. Herencia
El código no es localizado. Esto puede producir un comportamiento inesperado cuando son hechos los cambios y problemas de entendimiento.
Alias Usando más 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 comprobación de los límites en arreglos.
Procesamiento de entradas predefinidas Una acción de entrada que ocurre independientemente de la
entrada.
13/04/23 925
Manejo de excepción Una excepción del programa es un error o algún
evento inesperado tal como una falla de energía. Las estructuras de manejo de excepción permiten
que tales eventos sean manejados sin la necesidad para la revisión 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 propensión al error.
13/04/23 926
Excepciones en Java 1class ExcepciónFallaSensor extends Excepción {
ExcepciónFallaSensor (String msg) {
super (msg) ;
Alarma.activate (msg) ;
}
} // ExcepciónFallaSensor
13/04/23 927
Excepciones en Java 2class Sensor {
int readVal () throws ExcepciónFallaSensor {
try {
int elValor = DeviceIO.readInteger () ;
if (elValor < 0)
throw new ExcepciónFallaSensor (“Falla del Sensor") ;
return elValor ;
}
catch (deviceIOExcepción e)
{
throw new ExcepciónFallaSensor (“ Error de lectura del Sensor ”) ;
}
} // readVal
} // Sensor
13/04/23 928
Un controlador de temperatura
Las excepciones pueden ser usadas como un a técnica normal de programación 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 máxima temperatura permitida es excedida.
Usar excepciones como una técnica normal de programación.
13/04/23 929
Controlador de congelador 1class 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) ;
}
13/04/23 930
Controlador de congelador 2if (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
13/04/23 931
Tolerancia de fallas En situaciones críticas, 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 operación a pesar de fallas del software.
Aun cuando se ha demostrado que el sistema está conforme a su especificación, también debe ser tolerante a fallas, de modo que pueden haber errores en la especificación o la validación puede ser incorrecta.
13/04/23 932
Acciones de tolerancia de fallas
Detección de falla El sistema detectar que una falla (un estado incorrecto del
sistema) ha ocurrido. Valoración de falla
Las partes del estado del sistema afectadas por la falla deben ser detectadas.
Recuperación de la falla El sistema debe restaurar su estado a un estado seguro
conocido. Reparación 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.
13/04/23 933
Detección de falla y valoración del daño
La primera fase de la tolerancia de falla es para detectar que una falla (un estado erróneo del sistema) ha ocurrido o va a ocurrir.
La tolerancia de falla involucra la definición de restricciones que deben sostenerse para todos los estados legales y revisando los estados contra estas restricciones.
13/04/23 934
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 máximo de una dosis simple
dosis_insulina >= 0 & dosis_ insulina <= contenido_reserva_insulina
/ / La cantidad total de insulina entregada por un día debe ser menor
// que o igual a una dosis máxima diaria definida
dosis_acumulativa <= el maxima_dosis_diaria
13/04/23 935
Detección de falla Detección de falla preventiva
El mecanismo de detección de falla es iniciado antes de que el cambio de estado se ha realizado. Si un estado erróneo es detectado el cambio no es hecho.
Detección de falla retrospectiva El mecanismo de detección de falla es iniciado
después de que el estado ha sido cambiado. Esto es un usado cuando una secuencia de acciones correctas lleva a un estado erróneo o cuando una detección de falla preventiva involucra mucho desbordamiento.
13/04/23 936
La detección de falla preventiva involucra la extensión de sistema tipo por inclusión de restricciones como parte de la definición del tipo.
Estas restricciones se implementan por definición de operaciones básicas dentro de la definición de clase.
Extensión de sistemas tipo
13/04/23 937
EnteroParPositivo 1class EnteroParPositivo {
int val = 0 ;
EnteroParPositivo (int n) throws ExcepciónNumérica
{
if (n < 0 | n%2 == 1)
throw new ExcepciónNumérica () ;
else
val = n ;
}// EnteroParPositivo
13/04/23 938
EnteroParPositivo 2public void assign (int n) throws ExcepciónNumérica
{
if (n < 0 | n%2 == 1)
throw new ExcepciónNumérica ();
else
val = n ;
} // Asignar
int paraEntero ()
{
return val ;
} //Para entero
boolean equals (EnteroParPositivo n)
{
return (val == n.val) ;
} // equals
} //ParPositivo
13/04/23 939
Valoración de daño Analizar el estado del sistema para juzgar la
extensión de corrupción causada por la falla del sistema.
La valoración debe revisar que partes del espacio de estado han sido afectadas por la falla.
Basada generalmente en las “funciones de validación” que puede ser aplicada a los elementos de estado para evaluar si los valores están dentro del rango permitido.
13/04/23 940
Arreglo robusto 1class 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
13/04/23 941
Arreglo robusto 2public 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
13/04/23 942
Los checksums son usados para la valoración del daño en los datos de transmisión.
Punteros redundantes pueden se usados para revisar la integridad de las estructuras de datos.
Los cronómetros guardianes pueden revisar los procesos no terminados. Si no responde antes de cierto tiempo, un problema es asumido.
Técnicas de valoración de daño
13/04/23 943
Recuperación hacia adelante Aplicar reparaciones para un estado de sistema corrupto.
Recuperación hacia atrás Restaurar el estado de sistema para un estado seguro
conocido. La recuperación hacia delante es normalmente una
aplicación específica – es requerido el para calcular las posibles correcciones de estado.
La recuperación de error hacia atrás es más simple. Los detalles de un estado seguro son mantenidos y esto reemplaza el estado de sistema corrupto.
Recuperación de falla y reparación
13/04/23 944
Corrupción de codificación de datos Las técnicas de codificación de error que agrega la
redundancia para datos codificados puede ser usado para reparar datos corruptos durante la transmisión.
Punteros redundantes Cuando los punteros redundantes son incluidos en las
estructuras de datos (pro ejemplo, las listas bidireccionales), una lista corrupta o un almacén de archivos puede ser reconstruido si un número suficiente de punteros son incorruptos.
A menudo es usado para bases de datos y reparo de sistemas de archivo.
Recuperación hacia adelante
13/04/23 945
Las transacciones son un método frecuentemente usado para la recuperación hacia adelante. Los cambios no son aplicados hasta que la computación sea completa. Si ocurre un error, el sistema se va al estado precedente de la transacción.
Los puntos de control periódicos permiten al sistema “regresar a la situación anterior” de un estado correcto.
Recuperación hacia atrás
13/04/23 946
Procedimiento de orden seguro
Una operación de orden monitorea su propia ejecución y evalúa 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 identificación y manejo de excepciones.
Posible en este caso cuando la condición para un orden “válido” es conocida. Sin embargo en muchos casos. Sin embargo en muchos casos es difícil escribir revisiones de validación.
13/04/23 947
Orden seguro 1class 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) ;
13/04/23 948
Orden seguro 2if (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
13/04/23 949
Arquitectura tolerante de falla La programación 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 código asociado son incorrectos.
Cuando los sistemas tienen alta disponibilidad de requerimientos, una arquitectura específica diseñada para soportar tolerancia a fallas puede ser requerida.
Esto debe tolerar fallas entre hardware y software.
13/04/23 950
Tolerancia a fallas de hardware
Depende de la redundancia-modular-triple (RMT). Hay tres componentes idénticas 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 mayoría de fallas resultantes desde fallas de componentes, en lugar de las fallas de diseño y una baja probabilidad de falla de componentes simultanea.
13/04/23 951
Fiabilidad de hardware con RMT
A1A1
A2A2
A3A3
Comparador de salida
Comparador de salida
13/04/23 952
Selección de salida El comparador de salida es un (relativamente)
simple unidad de hardware. Compara sus señales de salida, si una es
diferente de los otros, lo rechaza. Esencialmente, la selección de la salida efectiva depende de la mayoría de votos.
El comparador de salida está conectada a la unidad de gestión de falla que puede intentar reparar la unidad defectuosa o sacarla fuera de servicio.
13/04/23 953
Arquitecturas de software tolerante a fallas
El éxito de RTM a proporcionar tolerancia de fallas está basada en dos fundamentales asunciones Los componentes de hardware no incluyen fallas de diseño
comunes; Los componentes fallan al azar y hay baja probabilidad de falla de
componente simultanea. Ninguna de estas asunciones es verdadera para el
software No es posible simplemente replicar el mismo componente cuando
ellos tuvieran fallas de diseño comunes; La falla de componentes simultanea es por lo tanto virtualmente
inevitable. Los sistemas de software deben, por lo tanto ser diversas.
13/04/23 954
Diversidad de diseño Diferentes versiones del sistema son diseñados e
implementados de diferentes maneras. Ellos, por consiguiente, deben tener diferentes modos de falla.
Diferentes aproximaciones para el diseño (por ejemplo, orientado a objetos y orientado a funciones) Implementación en diferentes lenguajes de
programación; Uso de diferentes herramientas y ambientes de
desarrollo; Use de diferentes algoritmos en la implementación.
13/04/23 955
Analogías de software de RMT
Programación versión N La misma especificación es implementada en varias
versiones diferentes por equipos diferentes. Todas las versiones computan simultáneamente y la salida de la mayoría es seleccionada usando un sistema de votación.
Esta es la aproximación más comúnmente usada, por ejemplo, en muchos modelos del avión comercial Airbus.
Bloques de recuperación Un número de explícitamente diferentes versiones de la
misma especificación son escritas y ejecutadas en secuencia.
Una prueba de aceptación es usada para seleccionar la salida a ser transmitida.
13/04/23 956
Programación versión-N
Versión 1Versión 1
Versión 2Versión 2
Versión 3Versión 3
Comparador de salida
Comparador de salida
Entrada
N versiones
Resultado convenido
Resultado convenido
13/04/23 957
Comparación de salidasComo en los sistemas de hardware, el
comparador de salidas es una simple pieza de software que usa el mecanismo de votación 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.
13/04/23 958
Programación de la versión N Las diferentes versiones del sistema son
diseñados 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 empírica que los equipos normalmente malentienden las especificaciones de la misma manera y escogen los mismos algoritmos en sus sistemas.
13/04/23 959
Bloques de recuperación
Algoritmo 1Algoritmo 1
Algoritmo 2Algoritmo 2 Algoritmo 3Algoritmo 3
Prueba de aceptación
Prueba de aceptación
Bloques de recuperación
Probar el algoritmo 1
Pruebas para sucesos
Pruebas de aceptación
Reintentar fallas Re-prueba
ReintentarRe-prueba
Continua la ejecución si sucede la prueba de aceptación. Señalar excepción si todos los algoritmos fallan
13/04/23 960
Bloques de recuperación Estos obligan a usar un diferente algoritmo para
para cada versión para que ellos reduzcan la probabilidad de errores comunes.
Sin embargo, el diseño de las pruebas de aceptación es difícil puesto que debe ser independiente de la computación usada.
Hay problemas con la aproximación para sistemas de tiempo real debido a la operación secuencial de las versiones redundantes.
13/04/23 961
Problemas con la diversidad del diseño
Los equipos no son culturalmente diversos para que ellos tiendan a tomar los problemas de la misma manera.
Errores característicos Equipos diferentes cometen los mismos errores. Algunas partes
de una implementación son más difíciles que otras de modo que todos los equipos tienden a cometer errores en el mismo lugar;
Errores de especificación; Si hay un error en la especificación, entonces esto se refleja en
todas las implementaciones; Esto puede ser dirigida a alguna extensión usando
representaciones de especificación múltiple.
13/04/23 962
Dependencia de la especificación
Ambas aproximaciones para la redundancia de software son susceptibles a errores en la especificación. Si la especificación es incorrecta el sistema podría fallar.
Esto es también un problema con el hardware, pero las especificaciones de software normalmente son más complejas que las especificaciones del hardware y más difícil para validar.
Esto ha sido dirigido en algunos casos por desarrollo separado de las especificaciones de software desde las mismas especificaciones del usuario.
13/04/23 963
La confiabilidad en un sistema puede ser logrado a través de la anulación de falta, detección 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 serán minimizadas.
Algunas estructuras de construcción son la inherentemente propensos a error – su uso debe evitarse dondequiera sea posible.
Puntos clave
13/04/23 964
Puntos clave Las excepciones son usadas para soportar la
gestión de error en sistemas fidedignos. Los 4 aspectos de la tolerancia de falla de
programa son la detección de falla, valoración del daño, recuperación de falla y reparación de falla.
La programación de la versión N y los bloques de recuperación son aproximaciones alternativas para las arquitecturas tolerantes a fallas.
13/04/23 965
Evaluación del software
Capítulo 21
13/04/23 966
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 evolución
del software Discutir una aproximación para evaluar las
estrategias de evolución y las estrategias para sistemas legados.
13/04/23 967
Tópicos cubiertosDinámicas de la evolución de
programaMantenimiento del softwareProcesos de evoluciónEvolución de procesos legados
13/04/23 968
Cambio del software 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 desempeño o fiabilidad del sistema pueden ser
mejorados. Un problema clave para las organizaciones es la
implementación y el manejo de cambios para los sistemas de software existentes.
13/04/23 969
Importancia de la evolución
Las organizaciones tienen grandes inversiones en sus sistemas de software – ellos son los recursos comerciales críticos.
Para mantener el valor de estos recursos de los negocios, ellos deben ser cambiados y actualizados.
La mayoría de los presupuestos de software en grandes compañías se consagran a la evolución del software existentes antes que el desarrollo de software nuevo.
13/04/23 970
Modelo en espiral de la evolución
EspecificaciónEspecificación ImplementaciónImplementación
ValidaciónValidaciónOperaciónOperación
Inicio
Lanzamiento 1
Lanzamiento 2
Lanzamiento 3
13/04/23 971
Dinámicas de evolución del programa es el estudio de los procesos de cambio de sistemas.
Después de que los empíricos mayores, Lehman y Belady propusieron que hay habían 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. Quizás menos aplicables en otros sistemas
Dinámicas de la evolución de programa
13/04/23 972
Reglas de LehmanLey Descripción
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 más compleja. Deben consagrarse recursos extras para conservar y simplificar la estructura.
Evolución del programa largo La evolución del programa es un proceso autorregulador. Los atributos del sistema como el tamaño, tiempo entre lanzamientos y el número de errores informados es aproximadamente invariante para cada lanzamiento del sistema.
Estabilidad organizacional Sobre el tiempo de vida de un programa, su proporción de desarrollo es aproximadamente constante e independiente de los recursos consagrados al desarrollo del sistema.
Conservación 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 satisfacción 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 retroalimentación El proceso de evolución incorpora multiagentes, sistemas de retroalimentación multiciclo y se tienen que tratarlos como sistemas de retroalimentación para lograr la mejora significativa del producto.
13/04/23 973
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 más reciente trabajo de Lehman el proyecto
FEAST [FIESTA] (ver y leer el libro mas allá de la Website del libro).
No está claro cómo debe modificarse ellos para Productos de software compacto envueltos; Sistemas que incorporan un número significativo de
componentes COTS; Pequeñas organizaciones; Sistemas de tamaño mediano.
13/04/23 974
Modificando un programa después de que ha sido puesto en uso.
El mantenimiento normalmente no incluye mayores cambios en la arquitectura del sistema.
Los cambios son implementados por modificación de componentes existentes y por adición de nuevos componentes par el sistema.
Mantenimiento del software
13/04/23 975
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 herméticamente 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.
El mantenimiento es inevitable
13/04/23 976
Mantenimiento para reparar fallas del software Cambiando un sistema para corregir deficiencias las
deficiencias de una manera que reúnan 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 implementación inicial.
Mantenimiento para agregar o modificar la funcionalidad del sistema Modificando el sistema para satisfacer nuevos
requerimientos.
Tipos de mantenimiento
13/04/23 977
Distribución del esfuerzo de mantenimiento
Reparar falla17%
Adición de funcionalidad o
modif icación65%
Adaptación del softw are
18%
13/04/23 978
Normalmente mayor que los costos de desarrollo (de 2* a 100* dependiendo en la aplicación).
Afectado por los factores técnicos y no técnicos. El crecimiento como el software es mantenido. El
mantenimiento corrompe la estructura del software, lo que hace el mantenimiento más dificultoso.
El software viejo puede tener altos costos de soporte (por ejemplo, viejos lenguajes, compiladores, etc. ).
Costos de mantenimiento
13/04/23 979
Costos de desarrollo/mantenimiento
0 50 100 150 200 150 200 250 300 350 400 450 500
Sistema 1
Sistema 2
$
Costos de desarrollo Costos de mantenimiento
13/04/23 980
Estabilidad del equipo Los costos de mantenimiento están reducidos si el mismo
personal está involucrado con ellos por algún tiempo. Responsabilidad contractual
Los desarrolladores de un sistema pueden no tener responsabilidad contractual para el mantenimiento, de modo que no hay incentivo para diseñar 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 más difíciles de entender y cambiar.
Factores de costo de mantenimiento
13/04/23 981
Predicción del mantenimiento
La predicción de mantenimiento se preocupa para evaluar que partes del sistema pueden causar problemas y tener altos costos de mantenimiento La aceptación del cambio depende de la mantenibilidad
de los componentes afectados por el cambio; La implementación de cambios degrada el sistema y
reduce su mantenibilidad; Los costos de mantenimiento dependen del número de
cambios y los costos de cambio dependen de la mantenibilidad.
13/04/23 982
Predicción del mantenimiento
Prediciendo mantenibilidad
Prediciendo cambios del
sistema
Prediciendo costos de
mantenimiento
¿Qué partes del sistema pueden ser más caras para el mantenimiento?
¿Qué partes del sistema pueden ser más caras para el mantenimiento?
¿Cuál será el tiempo de vida de los
costos de mantenimiento de
este sistema?
¿Cuál será el tiempo de vida de los
costos de mantenimiento de
este sistema?
¿Cuáles serán los costos de mantenimiento del
sistema mantenimiento para el próximo año?
¿Cuáles serán los costos de mantenimiento del
sistema mantenimiento para el próximo año?
¿Cuántas demandas de cambio pueden
esperarse?
¿Cuántas demandas de cambio pueden
esperarse?
¿Qué partes del sistema serán más
probablemente afectadas por las
demandas de cambio?
¿Qué partes del sistema serán más
probablemente afectadas por las
demandas de cambio?
13/04/23 983
Predicción del cambio Prediciendo el número de cambios que requiere y
entendiendo las interrelaciones entre el sistema y su ambiente.
Los sistemas herméticamente acoplados requieren cambios siempre que el ambiente es cambiado.
Los factores que influyen en estas interrelaciones son Número y complejidad de las interfaces del sistema; Número de requerimientos del sistema
inherentemente volátiles; Los procesos de negocios donde el sistema es usado.
13/04/23 984
Métricas de complejidad Las predicciones de mantenibilidad pueden ser
hechas evaluando la complejidad de componentes del sistema.
Los estudios han mostrado más esfuerzo de mantenimiento está gastando en un número relativamente pequeño de componente de sistemas.
La complejidad depende de La complejidad de las estructuras de control; La complejidad de estructuras de datos; Objeto, método (procedimiento) y tamaño de
modulo.
13/04/23 985
Métricas del proceso Las mediciones del proceso pueden ser usadas
para evaluar la mantenibilidad Número de demandas para mantenimiento
correctivo; Tiempo promedio requerido por el análisis de
impacto; Tiempo medio tomado para implementar una
demanda de cambio; Número de demandas de cambio pendientes.
Si uno o cualquiera de estos está creciendo, esto puede indicar una declinación en la mantenibilidad.
13/04/23 986
Proceso de evolución El proceso de evolución 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 evolución del sistema. Se identifica el cambio y la evolución continua a través del tiempo de vida del sistema.
13/04/23 987
Identificación del cambio y evolución
Propuesta de cambios
Propuesta de cambios
Nuevo sistema
Nuevo sistema
Proceso de evolución del
software
Proceso de evolución del
software
Proceso de identificación del
cambio
Proceso de identificación del
cambio
13/04/23 988
El proceso de evolución del sistema
Demanda de cambios
Demanda de cambios
Análisis de impacto
Análisis de impacto
Planificación de lanzamiento
Planificación de lanzamiento
Implementación del cambio
Implementación del cambio
Lanzamiento del sistema
Lanzamiento del sistema
Reparación de falla
Reparación de falla
Adaptación de plataforma
Adaptación de plataforma
Perfeccionamiento del sistema
Perfeccionamiento del sistema
13/04/23 989
Implementación del cambio
Cambios propuestos
Cambios propuestos
Análisis de requerimientos
Análisis de requerimientos
Actualización de requerimientos
Actualización de requerimientos
Desarrollo de software
Desarrollo de software
13/04/23 990
Demandas de cambio urgente
Los cambios urgentes pueden ser implementados sin pasar a través de todas las fases del proceso de ingeniería 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 rápida (por ejemplo, el lanzamiento de un producto competitivo).
13/04/23 991
Reparar una emergencia
Demanda de cambios
Demanda de cambios
Analizar código fuente
Analizar código fuente
Modificar código fuente
Modificar código fuente
Entregar sistema modificado
Entregar sistema modificado
13/04/23 992
Reingeniería 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 reingeniería involucra el esfuerzo de la adición para hacer más fácil el mantenimiento. El sistema puede ser reestructurado y redocumentado.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 993
Ventajas de la reingeniería 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 especificación.
Costo reducido El costo de reingeniería es significativamente
menor que el costo de desarrollar nuevo software.
13/04/23 994
Adelante y reingeniería
Especificación del sistema
Especificación del sistema
Diseño e implementación
Diseño e implementación
Nuevo sistema
Nuevo sistema
Ingeniería hacia adelante
Sistema de software existente
Sistema de software existente
Entendimiento y transformación
Entendimiento y transformación
Sistema con reingeniería
Sistema con reingeniería
Reingeniería de software
13/04/23 995
Los procesos de reingienería
Programa original
Programa original
Traslación de código fuente
Traslación de código fuente
Ingeniería reversa
Ingeniería reversa
Mejora de la estructura
de programa
Mejora de la estructura
de programa
Documentación de programa
Documentación de programa
Programa modularizado
Programa modularizado
Datos originales
Datos originales
Modularización de programa
Modularización de programa
Programa estructurado
Programa estructurado
Reingienería de datos
Reingienería de datos
Datos con reingienería
Datos con reingienería
13/04/23 996
Actividades del proceso de reingienería
Traducción de código fuente Convertir código a nuevo lenguaje.
Ingeniería reversa Analizar el programa para entenderlo;
Mejoramiento de la estructura de programa Reestructurar automáticamente para la entendibilidad;
Modularización de programa Reorganizar la estructura de programa;
Reingienería de datos Limpiar y reestructurar los datos del sistema.
13/04/23 997
Aproximación de reingienería
Reestructuración de programa automatizado
Reestructuración de datos del programa
Conversión de código fuente automatizado
Reestructuración automatizada con cambios manuales
Reestructuración más cambios
arquitectónicos
Costo incrementado
13/04/23 998
Factores de costo de la reingienería
La calidad del software para aplicar reingeniería. Las herramientas de soporte disponibles para la
reingienería. La magnitud de conversión de datos que son
requeridos. La disponibilidad de personal experto para la
reingienería. Esto puede ser un problema con sistemas
viejos basados en tecnología que no ha sido ampliamente usada.
13/04/23 999
Evolución de sistemas legados
Las organizaciones que confían 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 más requerido; Continuar el mantenimiento del sistema; Transformar el sistema por reingienería 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.
13/04/23 1000
Calidad del sistema y valor comercial
Calidad del sistema
Va
lor
co
me
rcia
l
21 3 4
5
76
8
9 10
Alto valor comercial
Baja calidad
Alto valor comercial
Alta calidad
Bajo valor comercial
Baja calidad
Bajo valor comercial
Alta calidad
13/04/23 1001
Categorías de sistemas legados
Baja calidad, bajo valor comercial Estos sistemas deben rechazarse.
Baja calidad, alto valor comercial Estos hacen una importante contribución comercial pero
son costosos de mantener. Debe aplicarse reingienería 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 operación usando el mantenimiento normal del sistema.
13/04/23 1002
Valoración del valor comercial
La valoración debe tener en cuenta diferentes puntos de vista Usuarios finales del sistema; Clientes comerciales; Gerentes en líneas; Gerentes de IT; Gerentes mayores.
Entrevista de diferentes stakeholders y resultados intercalados.
13/04/23 1003
Valoración de la calidad del sistema
Valoración del proceso de negocios ¿Qué tan bien el proceso de negocios apoya las
metas actuales del negocio? Valoración del ambiente
¿Cuán efectiva es el ambiente del sistema es y cuán costoso es mantenerlo?
Valoración de la aplicación ¿Cuál es la calidad del sistema de software de
aplicación?
13/04/23 1004
Valoración del proceso de negocio
Usar una aproximación 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 organización usan procesos
diferentes para la misma función? ¿Cómo ha sido adaptado el proceso? ¿Cuáles son las interrelaciones con otros procesos de negocio
y son estos necesarios? ¿El proceso es efectivamente apoyado por el sistema legado de
software de aplicación? Ejemplo – Un sistema de pedido de viaje puede tener un bajo valor
comercial debido al uso extendido de pedidos basados en la Web.
13/04/23 1005
Valoración del ambiente 1Factor PreguntasEstabilidad del proveedor
¿Está todavía el proveedor en existencia? ¿El proveedor es financieramente estable y probablemente continúe en existencia? ¿Si el proveedor no está mucho tiempo en el negocio, alguien más mantiene los sistemas?
Proporción de falla ¿El hardware tiene una proporción alta de fallas reportadas? ¿El software de soporte cae y fuerza el reinicio del sistema?
Edad ¿Cuántos años tienen el hardware y software? El más viejo hardware y software de soporte, será el más obsoleto. Todavía puede funcionar correctamente, pero allí podrían estar los beneficios económicos y comerciales significativos para mover a los sistemas más modernos.
Desempeño ¿El desempeño del sistema es adecuado? ¿Los problemas de desempeño tienen un efecto significativo en los usuarios del sistema?
13/04/23 1006
Valoración del ambiente 2Requerimientos 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 mantenimiento
¿Cuáles son los costos de mantenimiento del hardware y licencias de software de soporte? El hardware más viejo puede tener el mantenimiento de costo más alto que los sistemas modernos. El software de soporte puede tener los costos de licencia anuales altos.
Interoperatividad ¿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 emulación del hardware?
13/04/23 1007
Valoración de la aplicación 1Factor PreguntasEntendibilidad ¿Cuán difícil es el entendimiento del código fuente
del sistema actual? ¿Cuán complejas son las estructuras del control que se usan? ¿ Tienen las variables nombres significativos que reflejan su función?
Documentación ¿Qué documentación del sistema está disponible? ¿La documentación está completa, consistente y moderna?
Datos ¿Hay un explícito 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?
Desempeño ¿Es adecuado el desempeño de la aplicación ? ¿Los problemas de desempeño tienen un efecto significativo en los usuarios del sistema?
13/04/23 1008
Valoración de la aplicación 2Lenguaje de programación
¿Los compiladores modernos están disponibles para el lenguaje de programación para desarrollar el sistema? ¿El lenguaje de programación todavía se usa para el nuevo desarrollo del sistema?
Gestión de la configuración
¿Son todas las versiones o las partes del sistema manejados por un sistema de gestión de configuración? ¿Hay una descripción explícita de las versiones de componentes que se usan en el sistema actual?
Datos de prueba
¿Existen los datos de prueba del sistema? ¿Hay un registro de pruebas de regresión llevado a cabo cuándo se han agregado los nuevos rasgos al sistema?
Habilidades personales
¿Hay personas disponibles quién tiene las habilidades para mantener la aplicación? ¿Hay sólo un número limitado de personas que entienden el sistema?
13/04/23 1009
Medida del sistema Se pueden recolectar datos cuantitativos
para hacer una valoración de la calidad del sistema de aplicación El número de demandas de cambio del
sistema; El número de diferentes interfaces de
usuarios usados por el sistema; El volumen de datos usados por el
sistema.
13/04/23 1010
Puntos clave El desarrollo del software y evolución será un
simple proceso iterativo. Las leyes de Lehman describen varias visiones
dentro de la evolución del sistema. Tres tipos de mantenimiento son la fijación de
problema, modificación del software para un nuevo ambiente y la implementación de nuevos requerimientos.
Para sistemas de hábitos, los costos de mantenimiento normalmente usados exceden los costos de desarrollo.
13/04/23 1011
Puntos clave Los procesos de evolución se maneja por las
demandas para cambios desde los stakeholders del sistema.
La reingeniería de software se preocupa de reestructurar y redocumentación para hacer más fácil el cambio.
El valor comercial de sistemas legados y su calidad debe determinar la estrategia de evolución que es usado.
13/04/23 1012
Verificación y Validación
Capítulo 22
13/04/23 1013
Objetivos Introducir la verificación y validación del software
y para discutir la distinción entre ellos. Describir el proceso de inspección del programa
y su rol en V & V Explicar el análisis estático y como una técnica
de verificación Describir el proceso de software sala limpia
13/04/23 1014
Tópicos cubiertosPlanificación de verificación y
validaciónInspecciones de softwareAnálisis estático automatizadoDesarrollo de software de sala limpia
13/04/23 1015
Verificación: “Somos nosotros construyendo el
derecho del producto”. El software debe estar conforme a su
especificación. Validación:
“Somos nosotros construyendo el producto correcto”.
El software debe hacer lo que el usuario realmente requiere.
Verificación vs validación
13/04/23 1016
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 valoración de que si el sistema es o no
útil y usable en una situación operacional.
El proceso V & V
13/04/23 1017
Metas de V & V La verificación y validación deben establecer la
confianza de que el software es capaz de cumplir sus propósito.
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.
13/04/23 1018
Confianza de V & V Depende del propósito del sistema, las expectativas del
usuario y el ambiente de comercialización Función del software
El nivel de confianza depende de cuán crítico es el software a la organización.
Expectativas del usuario Los usuarios pueden tener altas expectativas de ciertos
tipos de software. Ambiente de la comercialización
Conseguir un producto para comercializarlo temprano puede ser más importante que encontrar defectos en el programa.
13/04/23 1019
Inspecciones de software. Concierne al análisis e la representación del sistema estático para descubrir los problemas (verificación estática) Pueda ser completada por documento basado en
herramientas y el análisis del código Prueba de software. Concierne a ejercer y observar
el comportamiento del producto observado (verificación dinámica) El sistema es ejecutado con datos de prueba y su
comportamiento operacional es observado.
Verificación estática y dinámica
13/04/23 1020
V&V estático y dinámico
Inspecciones de software
Inspecciones de software
Especificación de requerimientos
Especificación de requerimientos
Diseño de alto nivel
Diseño de alto nivel
Especificación formal
Especificación formal
Diseño detallado
Diseño detallado
ProgramaPrograma
PrototipadoPrototipadoPrueba de programa
Prueba de programa
13/04/23 1021
Puede revelar la presencia de errores NO su ausencia.
La única técnica de validación para los requerimientos no funcionales puesto que el software tiene que ser ejecutada para ver cómo se comporta.
Debe ser usado en conjunción con verificación estática para proporcionar toda la cobertura de V&V.
Prueba de programa
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1022
Prueba por omisión Las pruebas se diseñaron para descubrir los defectos del
sistema. Una prueba por omisión exitosa es uno que revela la
presencia de defectos en un sistema. Cubierto en el Capítulo 23.
Prueba de validación Pensado para mostrar que el software reúne sus
requerimientos. Una prueba exitosa es una que muestra que unos
requerimientos se han implementado propiamente.
Tipos de prueba
13/04/23 1023
La prueba y depuración son procesos distintos. La verificación y la validación se preocupan por
establecer la existencia de defectos en un programa
La depuración se preocupa por localizar y reparar estos errores.
La depuración involucra la formulación de una hipótesis sobre el comportamiento del programa, entonces se prueban estas hipótesis para encontrar el error del sistema.
Prueba y depuración
13/04/23 1024
El proceso de depuración
Resultados de prueba
Resultados de prueba
Localizar error
Localizar error
Diseñar reparación de
error
Diseñar reparación de
errorReparar
error
Reparar error
Programa de reprueba
Programa de reprueba
Casos de prueba
Casos de prueba
EspecificaciónEspecificación
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1025
La planificación cuidadosa es requerida para conseguir lo más fuera de pruebas y procesos de inspección.
La planificación debe empezar temprano en el proceso de desarrollo.
El plan debe identificar el equilibrio entre la verificación estática y prueba.
La planificación de prueba está alrededor de definición de estándares para el proceso de prueba en lugar de la descripción de pruebas del producto.
Planificación V & V
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1026
El modelo V de desarrollo
Especificación de requerimientos
Especificación de requerimientos
Especificación del sistema
Especificación del sistema
Diseño del sistema
Diseño del sistema
Diseño detallado
Diseño detallado
Módulo y unidad de código y prueba
Módulo y unidad de código y prueba
Plan de prueba de aceptación
Plan de prueba de aceptación
Plan de prueba de integración
del sistema
Plan de prueba de integración
del sistema
Plan de prueba de integración del subsistema
Plan de prueba de integración del subsistema
ServicioServicio Prueba de aceptación
Prueba de aceptación
Prueba de integración del sistema
Prueba de integración del sistema
Prueba de integración del
subsistema
Prueba de integración del
subsistema
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1027
La estructura de un plan de prueba de software
El proceso de prueba. Trazabilidad de requerimientos. Artículos probados. Programación de prueba. Los procedimientos magnetofónicos. Requerimientos de hardware y software. Restricciones.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1028
El plan de prueba de software El proceso de prueba
Una descripción de las fases mayores del proceso de la comprobación. Éstos podrían ser como descrito antes en este capítulo.
La trazabilidad de requerimientos
Los usuarios son los más interesados en que el sistema reúna sus requerimientos y la prueba debe planificarse de modo que todos los requerimientos se prueben individualmente.
Los artículos probados
Deben especificarse los productos del proceso del software que serán probados.
La programación de prueba
Una programación de la prueba global y la asignación del recurso para esta programación. Esto, obviamente, se une a la programación del desarrollo de proyecto más general.
Procedimientos magnetofónicos de prueba
Simplemente no es bastante para ejecutar las pruebas. Deben grabarse los resultados de las pruebas sistemáticamente. Debe ser posible intervenir en el proceso de prueba para verificar que se llevará a cabo correctamente.
Los requerimientos de hardware y software
Esta sección debe presentar las herramientas del software requeridas y debe estimar la utilización del hardware.
Las restricciones
Deben preverse las restricciones que afectan el proceso de prueba como las escasez de personal en esta sección.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1029
Inspecciones de software Éstos involucran a las personas que examinan la
representación de la fuente con el objetivo de descubrir anomalías y defectos.
Las inspecciones no requieren la ejecución de un sistema, de modo que pueden ser usados antes de la implementación.
Ellos pueden aplicarse a cualquier representación del sistema (requerimientos, diseño, datos de configuración, datos de prueba, etc.).
Ellos se han mostrado para ser una técnica efectiva para el descubrimiento de errores de programa.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1030
El éxito de la inspección Muchos defectos diferentes pueden ser
descubiertos en una sola inspección. 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 programación, de modo que los revisores probablemente habrán visto los tipos de error que normalmente surgen.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1031
Inspecciones y pruebas Las inspecciones y pruebas son complementarias
y no se oponen las técnicas de verificación. Ambas pueden se usadas en el proceso V & V. Las inspecciones pueden verificar la conformidad
con una especificación, pero no la conformidad con los requerimientos reales del cliente.
Las inspecciones no pueden verificar las características no funcionales como el desempeño, la utilidad, etc.,
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1032
Inspecciones de programa
Aproximación formalizada para documentar revisiones.
Propuesto explícitamente para la detección de defectos (no corrección).
Los defectos pueden ser errores lógicos, anomalías en el código que podrían indicar una condición errónea (Por ejemplo, una variable no inicializada) o incumplimiento de los estándares.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1033
Pre-condiciones de la inspección Una especificación precisa debe estar disponible. Los miembros del equipo deben estar familiarizados con
los estándares de la organización. Código sintácticamente correcto u otras representaciones
del sistema deben estar disponibles. Una lista de control de error debe estar preparada. La gestión debe aceptar que la inspección aumentará los
costos tempranamente en el proceso de software. La gestión no debe usar inspecciones para la apreciación
personal, esto es, encontrar fuera de los que cometen errores.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1034
El proceso de inspección
PlanificaciónPlanificación
Vista globalVista global
Preparación individual
Preparación individual
Reunión de inspección
Reunión de inspección
RetrabajoRetrabajo
Seguir aSeguir a
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1035
Procedimiento de inspección
La vista global del sistema presentada por el equipo de inspección.
El código y los documentos asociados son distribuidos de antemano al equipo de inspección.
La inspección tiene lugar y los errores descubiertos son anotados.
Las modificaciones son hechas para reparar los errores descubiertos.
La reinspección puede o no ser requerida.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1036
Roles de la inspecciónAutor o propietario
El programador o diseñador responsable para producir el programa o documento. Responsable por arreglar defectos descubiertos durante el proceso de inspección.
Inspector Encuentra los errores, omisiones e inconsistencias en los programas y documentos. También pueda identificar problemas más extensos que están fuera del alcance del equipo de la inspección.
Lector Presenta el código o documenta en una reunión de inspección.
Escriba Registra los resultados de la reunión de inspección.
Presidente o moderador
Maneja el proceso y facilita la inspección. Informa los resultados del proceso al moderador Principal.
Moderador principal
Responsable por las mejoras de proceso inspección, actualización de la lista de control, desarrollo de los estándares, etc.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1037
Listas de revisión de la inspección
La lista de control de errores comunes debe ser usado para manejar la inspección.
Las listas de revisión de errores son programadas en un lenguaje dependiente y refleja los errores característicos que son probables de levantarlos en el lenguaje.
In general, el “débil” comprobación de tipo, el mayor de la lista de control.
Ejemplos: Inicialización, denominación Constante, terminación del bucle, límites de arreglos, etc.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1038
Revisiones de inspección 1Fallas de datos ¿Todas las variables del programa se inicializan antes de que sus valores
sean usados? ¿Se han nominado todas las constantes? ¿Debe el límite superior de arreglos ser igual al del arreglo o Tamaño -1? ¿Si las cadenas de carácter son usadas, hay un delimitador explícitamente asignado? ¿Hay cualquier posibilidad de desborde de memoria intermediaria?
Fallas de control ¿Para cada estamento condicional, la condición es correcta? ¿Hay seguridad de terminar cada bucle? ¿Se ponen correctamente entre paréntesis las declaraciones compuestas? ¿En los estamentos case, son considerados todos los posibles casos for? ¿Si una interrupción es requerida después de cada caso en los estamentos case, han sido incluidos?
Fallas de Entrada/Salida
¿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 corrupción?
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1039
Revisiones de inspección 2Fallas de interfaz ¿Todas las funciones y llamadas del método tienen el
número correcto de parámetros? ¿Los tipos del parámetro formales y reales emparejan? ¿Están los parámetros 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 de almacenamiento
¿Si una estructura enlazada es modificada, todos los enlaces han sido correctamente reasignadas? ¿Si el almacenamiento dinámico es usado, el espacio se ha asignado correctamente? ¿Es el espacio explícitamente desasignado después de que ya no se le requiere?
Fallas de manejo de excepciones
¿Todas las posibles condiciones de error se han tenido en cuenta?
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1040
Proporción de inspección 500 estamentos /hora durante la vista global. 125 estamentos fuente /hora durante la
preparación individual. 90-125 estamentos /hora pueden
inspeccionados. La inspección, por consiguiente, es un proceso
caro. Los costos de inspeccionar 500 líneas
aproximadamente esfuerzo de 40 horas/hombre aproximadamente £2800 a la proporción del Reino Unido.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1041
Análisis estático automatizado
Los analizadores automáticos son herramientas de software para el procesamiento de texto fuente.
Ellos analizan el texto del programa e intentas descubrir las condiciones potencialmente erróneas y traer la atención 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1042
Revisiones del análisis estático
Clases de falla Revisión de análisis estático
Fallas de datos Variables usadas antes de la inicialización.Variables declaradas pero no usadas.Variables asignadas dos veces pero nunca usados entre
asignaciones.Posibles violaciones de límites de arreglos.Variables no declaradas.
Fallas de control Código inalcanzable.Bifurcaciones sin condición en los bucles.
Fallas de entrada/salida
Variables de salida repetidas sin asignación intermedia.
Fallas de interfaz Tipos de parámetros desiguales.Número de parámetros desiguales.Resultados de funciones no usadas.Funciones y procedimientos no llamados.
Fallas de manejo de almacenamiento
Punteros no asignados.Aritmética de punteros.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1043
Fases de análisis estático Análisis de flujo de control. Revisa bucles con
salida múltiple puntos de entrada, halla código inalcanzable, etc.
Análisis de uso de datos. Detecta variables no inicializadas, variables escritas dos veces sin una asignación intermedia, variables que son declaradas pero nunca usadas, etc.
Análisis de interfaz. Revisa la consistencia de rutina y declaraciones de procedimientos y su uso.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1044
Fases de análisis estático Análisis de flujo de información. Identifica las
dependencias de variables de salida. No detecta anomalías, por si misma pero resalta información para inspección de código o revisión.
Análisis de camino. Identifica caminos a través del programa y conjuntos fuera de los estamentos ejecutados en ese camino. Nuevamente es potencialmente útil en el proceso de revisión.
Ambas fases generan gran cantidad de información. Ellas deben usarse con cuidado.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1045
Análisis estático 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
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1046
Uso de análisis estáticoParticularmente valioso cuando un
lenguaje como C usa comprobación de tipos débil y muchos errores no son detectados por el compilador.
Menos rentable para lenguajes como Java que tienen comprobación fuerte de tipos y puede, por consiguiente, detectar muchos errores durante la compilación.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1047
Verificación y métodos formales
Los métodos formales pueden ser usados cuando una especificación matemática del sistema se produce.
Ellos son la última técnica de verificación técnica. Ellos involucran análisis matemático detallado de
la especificación y pueden desarrollar argumentos formales que un programa conforme a su especificación matemática.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1048
Argumentos para métodos formales
La producción de una especificación formal requiere un análisis detallado de los requerimientos y esto es probablemente para destapar errores.
Ellos pueden detectar errores de implementación antes de la prueba cuando el programa es analizado junto con la especificación.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1049
Argumentos contra los métodos formales
Requiere notación especializada que puede ser no entendida por los expertos del dominio.
Muy caro para desarrollar una especificación y y más caro aun para mostrar que un programa reúne esa especificación.
Puede ser posible para alcanzar el mismo nivel de confianza en un programa más barato que usar técnicas V & V.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1050
El nombre es derivado del proceso de “Sala limpia” en la fabricación de semiconductor. La filosofía es la anulación de defectos antes que el levantamiento de defectos.
El proceso de desarrollo de software es basado en: Desarrollo incremental; Especificación formal; Verificación estática usando argumentos de
correctitud; Pruebas estadísticas para determinar la fiabilidad de
programas.
Desarrollo de software de sala limpia
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1051
El proceso de Sala limpia
Especificar el sistema
formalmente
Especificar el sistema
formalmente
Desarrollo de perfil
operacional
Desarrollo de perfil
operacional
Definir incrementos de software
Definir incrementos de software
Construir programas
estructurado
Construir programas
estructurado
Verificar el código
formalmente
Verificar el código
formalmente
Incremento integrado
Incremento integrado
Diseñar pruebas
estadísticas
Diseñar pruebas
estadísticas Probar sistema
integrados
Probar sistema integrados
Retrabajo de error
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1052
Características del proceso de Sala limpia
Especificación formal usando un modelo de transición de estado.
Desarrollo incremental donde el cliente prioriza los incrementos.
Programación estructurada – control limitado y estructuras de abstracción son usados en el programa.
Verificación estática usando inspecciones rigurosas. La prueba estadística del sistema (cubierto en el
Cap. 24 ).
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1053
Especificación formal e inspecciones
El modelo basado en estado es una especificación de sistema y el proceso de especificación revisa el programa contra este modelo.
La aproximación de programación es definida de modo que la correspondencia entre el modelo y el sistema está claro.
Los argumentos matemáticos (no las pruebas) son usados para aumentar la confianza en el proceso de inspección.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1054
Equipo de especificación. Responsable del desarrollo y mantenimiento de la especificación 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 certificación. Responsable para desarrollar un conjunto de pruebas estadísticas para ejercitar el software antes del desarrollo. Los modelos de crecimiento de fiabilidad usados para determinar si la fiabilidad es aceptable.
Los equipos del proceso de sala limpia
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1055
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 más caro que otras aproximaciones.
Había menos errores que un proceso de desarrollo “tradicional”.
Sin embargo, el proceso no es usado ampliamente. No está claro como esta aproximación es transformada para un ambiente con los ingenieros de software menos experimentados o menos motivados.
Evaluación del proceso de Sala limpia
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1056
Puntos clave La verificación y validación no son la misma
cosa. La verificación muestra la conformidad co la especificación; la validación muestra que el programa reúne las necesidades del cliente.
Los planes de prueba deben prepararse para guiar el proceso de prueba.
Las técnicas de verificación estática involucra el examen y el análisis de un programa para detección de error.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1057
Puntos clave Las inspecciones de programa son muy eficaces
descubriendo errores. El código del programa en las inspecciones se
verifica sistemáticamente por un equipo pequeño para localizar las faltas del software.
Las herramientas del análisis estáticas pueden descubrir anomalías del programa que pueden ser una indicación de faltas en el código.
El proceso de desarrollo de Sala limpia depende del desarrollo incremental, comprobación estática y comprobación estadística.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1058
Pruebas del software
Capítulo 22
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1059
Objetivos Discutir las distinciones entre pruebas de
validación y pruebas de defectos Describir los principios del sistema y pruebas de
componentes Describir estrategias para generación de casos
de prueba de sistemas Entender las características esenciales de
herramientas usadas para la automatización de prueba
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1060
Tópicos cubiertosPrueba de sistemaPrueba de componenteDiseño de caso de pruebaAutomatización de prueba
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1061
El proceso de prueba Prueba de componente
Prueba de componentes de programa individuales; Normalmente la responsabilidad del desarrollo de
componentes (exceptuando algunas veces para sistemas críticos);
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 están basadas en una especificación de
sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1062
Fases de prueba
Desarrollo de software
Equipo de prueba independiente
Prueba de componente
Prueba de componente
Prueba de sistema
Prueba de sistema
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1063
Prueba de defectosLa 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 anómala.
La prueba muestra la presencia no la ausencia de defectos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1064
Metas del proceso de prueba
Prueba de validación Para demostrar al desarrollador y al cliente del sistema que el
software reúne 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 especificación;
Una prueba exitosa es una prueba que hace que el sistema tena tenga desempeño incorrecto y así exponga un defecto en el sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1065
El proceso de prueba del sistema
Diseño de casos de prueba
Diseño de casos de prueba
Preparar datos de prueba
Preparar datos de prueba
Ejecutar programa con
datos de prueba
Ejecutar programa con
datos de prueba
Preparar datos de prueba
Preparar datos de prueba
Casos de prueba
Casos de prueba
Datos de prueba
Datos de prueba
Resultados de prueba
Resultados de prueba
Informes de prueba
Informes de prueba
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1066
Sólo una prueba exhaustiva puede mostrar si un programa está libre de defectos. Sin embargo, una prueba exhaustiva es imposible.
Las políticas de prueba define la aproximación para ser usada en la selección de pruebas de sistema: Todas las funciones accedidas a través de menús
deben ser probadas; Las combinaciones de funciones accedidas a través
del mismo menú deben ser probadas; Donde la entrada de usuario es requerida, todas las
funciones deben ser probadas con entradas correctas e incorrectas.
Políticas de prueba
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1067
Prueba de sistema Involucra la integración 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 integración – el equipo de prueba tiene acceso para el código 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1068
Prueba de integración Involucra la construcción de un sistema desde sus
componentes y pruebas para problemas que se levantan de las interacciones de componentes.
Integración de Arriba-abajo (Top-down) Desarrollar el esqueleto del sistema y poblarlo con los
componentes. Integración de Abajo-arriba (Bottom -up)
Integrar los componentes de infraestructura que entonces agregan componentes funcionales.
Para simplificar la localización de error, los sistemas deberán ser integradas incrementalmente.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1069
Prueba de integración incremental
AA
T1
T1
BB
T3
T3
AA
CC
T1
T1
T4
T4
AA
DD
T1
T1
T5
T5
T2
T2
BB
T2
T2
T3
T3
BB
CC
T2
T2
T3
T3
T4
T4
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1070
Aproximación de prueba
Validación arquitectónica Las pruebas de integración de Arriba-abajo son buenas para
descubrir errores en la arquitectura del sistema. Demostración de sistema
Las pruebas de integración de Arriba-abajo permiten una demostración limitada en un estado temprano en el desarrollo.
Implementación de prueba A menudo es más fácil una prueba de integración de Abajo-
arriba. Observación de prueba
Problemas con ambas aproximaciones. Puede ser requerido código extra para observar pruebas.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1071
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 reúne sus requerimientos.
La prueba de lanzamiento es normalmente una caja negra o prueba funcional Basado sólo en la especificación del sistema. Los probadores no tienen conocimiento de la
implementación del sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1072
Prueba de caja negraLas entradas causan
comportamiento anómalo
Las salidas que revelan la presencia de
defectos
Entrada de datos de prueba
Salida de resultados de
prueba
Ie
Oe
SistemaSistema
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1073
Directrices de prueba Las directrices de prueba son indicaciones para el equipo de
prueba para ayudar a escoger pruebas que revelarán defectos en el sistema Escoger entradas que fuercen al sistema para generara
todos los mensajes de error; Diseñar entradas que causan memorias intermediarias
para el desborde Design; Repetir las mismas entradas o series entradas en varios
tiempos; Forzar salidas inválidas para ser generadas; Forzar resultados de computación para ser demasiada
grandes o demasiada pequeñas.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1074
Escenario de pruebaUna 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 búsqueda 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 confirmación de su universidad que es una estudiante genuina y el uso es para propósitos 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 librería y es impreso para ella. Ella recibe un mensaje de LIBSYS que le dice que ella recibirá un mensaje del correo electrónico cuando el documento impreso está disponible para la colección.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1075
Pruebas de sistema1. Probar el mecanismo de registro usando registros correctos e
incorrectos para verificar que los usuarios válidos se aceptan y los usuarios inválidos se rechazan
2. Probar la facilidad de búsqueda que usando diferentes consultas a las fuentes conocidas para verificar que el mecanismo de búsqueda está realmente encontrando los documentos .
3. Probar la facilidad de presentación del sistema, para verificar que que esa información sobre los documentos sea desplegada propiamente.
4. Probar el mecanismo para pedir el permiso para descargar.
5. Probar que la respuesta por correo electrónico que indica que el documento transmitido está disponible.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1076
Casos de usoLos 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 diseñar 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1077
Recolectar el diagrama de secuencia de datos del tiempo
: ControladorComandos : Usuario : EstaciónTiempo : DatosTiempo
1: Demanda (informe)
2: Reconocer()3: Informe()
4: Resumir()
5:
6: Enviar(informe)
7: Responder(informe)
8: Reconocer
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1078
Prueba de desempeño Parte de la prueba de lanzamiento puede
involucrar prueba de propiedades emergentes de un sistema como el desempeño y la fiabilidad.
Normalmente las pruebas de desempeño involucra la planificación de una serie de pruebas donde la carga es incrementada firmemente antes de que el desempeño del sistema se haga aceptable.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1079
Prueba de stress Practicar el sistema más allá de su carga de diseño
máxima. Estresar el sistema a menudo causa defectos a ser descubiertos.
Estresando el sistema se prueba el comportamiento de falla. Los sistemas no fallarán catastróficamente. La prueba de stress verifica la pérdida inaceptable del servicio o de datos.
La prueba del stress es particularmente relevante para sistemas distribuidos que puede exhibir degradación severa como una sobrecarga en la red.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1080
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 métodos dentro de un objeto;
Clases de objetos con varios atributos y métodos;
Los componentes compuestos con interfaces definidas se usan para acceder s funcionalidad.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1081
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 más difícil el diseño de pruebas
de clases de objetos puesto que la la información as ser probada no es localizada.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1082
Interfaz de objeto estación de tiempo
EstaciónTiempoIndentificador
InformeTiempo()Calibrar(instrumento)Prueba()Iniciar(instrumento)Cerrar(instrumento)
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1083
Prueba de estación 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
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1084
Los objetivos son detectar fallas debidas a errores de interfaz o asunciones inválidas acerca de las interfaces.
Particularmente importante para el desarrollo orientado a objetos de modo que los objetos son definidos por sus interfaces.
Prueba de interfaz
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1085
Prueba de interfazCasos de
prueba
Casos de prueba
A B
C
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1086
Tipos de interfaz Interfaces de parámetro
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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1087
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 parámetros en un mal pedido.
Equivocación 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 información anticuada es accedida.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1088
Directrices de pruebas de interfaz
Diseñar pruebas de modo que los parámetros a un procedimiento llamado están en los extremos finales de sus rangos.
Siempre los parámetros de punteros a pruebas con punteros nulos.
Diseñar 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1089
Diseño de casos de prueba Involucra el diseño de los casos de pruebas
(entradas y salidas) usados para probar el sistema. La meta del diseño de casos de prueba es crear un
conjunto de pruebas que son efectivas en la validación y pruebas de detección.
Aproximaciones de diseño: Prueba basada en requerimientos; Prueba de partición; Prueba estructural.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1090
Prueba basada en requerimientos
Un principio general de la ingeniería de requerimientos es que los requerimientos deben ser probables (ser sometidos a prueba).
La prueba basada en requerimientos es una técnica de prueba de validación donde se considera cada requerimiento y deriva un conjunto de prueba por ese requerimiento.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1091
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 almacén del documento.
Cada orden se asignará un único identificador (ID_PEDIDO) que el usuario podrá copiar al área del almacenamiento permanente de la cuenta.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1092
Pruebas de LIBSYS Iniciar la búsqueda de usuario para búsquedas de artículos que se conocen y están presentes y otros conocidos que no están presenten, dónde el conjunto de bases de datos incluye 1 base de datos.
Iniciar las búsquedas de usuario para artículos que se conocen y están presentes y otros conocidos que no están presentes, dónde el conjunto de bases de datos incluyen 2 bases de datos.
Iniciar las búsquedas de usuario para artículos que se conocen y están presentes y otros conocidos que no están presentes, donde el conjunto de bases de datos incluyen más de 2 bases de datos.
Seleccionar una base de datos del conjunto de bases de datos e iniciar búsquedas de usuario para artículos que se conocen y están presentes y otros conocidos que no están presentes,
Seleccionar más de una base de datos del conjunto de bases de datos e iniciar búsquedas para artículos que se conocen y están presentes y otros conocidos que no están presentes.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1093
Prueba de partición 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 están relacionados.
Cada una de estas clases es una partición 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 partición.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1094
Partición de equivalencia
Entradas inválidas
Salidas
SistemaSistema
Entradas válidas
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1095
Particiones de equivalencia
Menor que 4 Entre 4 y 10 Mayor que 10
Menor que 10000 Entre 10000 y 99999
Mayor que 99999
Valores de entrada
Número de valores de entrada
999910000 99999
10000050000
34 10
117
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1096
Especificación de rutina de búsqueda
procedure Search (Key : ELEM ; T: SEQ of ELEM; Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pre-condition-- la sucesión tiene al menos un elementoT’FIRST <= T’LAST
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
not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1097
Entradas que conforman a las precondiciones.
Entradas donde una precondición no se lleva a cabo.
Entradas donde el elemento clave es un miembro del arreglo.
Entradas donde el elemento clave no es miembro del arreglo
Rutina de búsqueda – particiones de entrada
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1098
Directivas de prueba (secuencias)
Probar el software con secuencias que tienen un solo valor.
Usar secuencias de diferentes tamaños 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1099
Rutina de búsqueda – particiones de entrada
Secuencia Elemento
Un sólo valorUn sólo valor Más de un valorMás de un valorMás de un valorMás de un valor
En secuenciaNo en secuenciaPrimer elemento en la secuenciaÚltimo elemento en la secuenciaElemento central en la secuenciaNo en secuencia
Secuencia de entrada (T) Clave(clave) Salida(Encontrar, L)
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
17
0
17
45
23
25
Verdadero, 1
Falso, ??
Verdadero, 1
Verdadero, 7
Verdadero, 4
Falso, ??
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1100
Algunas veces llamada prueba de caja negra. La derivación 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).
Prueba estructural
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1101
Prueba estructural
Datos de prueba
Datos de prueba
Código de componente
Código de componente
Salida de prueba
Salida de prueba
Prueba Deriva
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1102
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 número par de valores. Arreglo de entrada tiene un número impar de valores.
Búsqueda binaria – particiones de equivalencia
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1103
Búsqueda binaria particiones de equivalencia
Elementos < Medio Elementos > Medio
Punto medio
Límites de clases de equivalencia
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1104
Búsqueda binaria – casos de prueba
Arreglo de entrada (T) Clave(clave) Salida(Encontrar, L)
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
17
0
17
45
23
21
23
25
Verdadero, 1
Falso, ??
Verdadero, 1
Verdadero, 7
Verdadero, 4
Verdadero, 3
Verdadero, 4
Falso, ??
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1105
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 través 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1106
Grafo de flujo de búsqueda binaria
11
22
33
44
55
66
77
88
99
10
10
11
11
12
12
13
13
14
14
fondo > tope MIENTRAS fondo<= tope
elemArreglo[mid] = clave
elemArreglo[mid] != clave
elemArreglo[mid] > clave
elemArreglo[mid] < clave
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1107
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 dinámico puede ser
usado para verificar que los caminos sean bien ejecutados.
Caminos independientes
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1108
Automatización 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 ejecución automática de pruebas.
Más bancos de trabajo de prueba son sistemas abiertos porque las necesidades de prueba son específicas de una organización.
Ellas son a veces difíciles de integrar con diseño cerrado y bancos de trabajo de análisis.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1109
Un banco de trabajo de prueba
Código fuente
Código fuente
Analizador dinámico
Analizador dinámico
Informe de ejecución
Informe de ejecución
Manejador de prueba
Manejador de prueba
Programa probado
Programa probado
SimuladorSimulador
Datos de prueba
Datos de prueba
Resultados de prueba
Resultados de prueba
OracleOracle
Precondiciones de prueba
Precondiciones de prueba
EspecificaciónEspecificaciónGenerador de
datos de prueba
Generador de datos de prueba
Comparador de archivo
Comparador de archivo
Generador de informe
Generador de informe
Informe de resultados de
prueba
Informe de resultados de
prueba
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1110
Adaptación 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 comparación.
Los comparadores de archivo de propósito especial pueden ser desarrollados.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1111
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 integración 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 diseñar casos de prueba en la prueba de defectos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1112
Puntos clave La prueba de interfaz está diseñada para descubrir
defectos en las interfaces de componentes compuestos.
La partición de equivalencia es una manera de descubrimiento de casos de prueba deberán comportarse de la misma manera.
El análisis estructural confía en el análisis de un programa y derivar las pruebas a partir de este análisis.
La automatización de prueba reduce los costos de prueba, soportando el proceso de prueba con un rango de herramientas del software.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1113
Validación de Sistemas Críticos
Capítulo 23
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1114
Objetivos Explicar cómo la fiabilidad del sistema puede ser
medida y cómo pueden usarse los modelos de crecimiento de fiabilidad para la predicción de la fiabilidad
Describir los argumentos de seguridad física y cómo estos serán usados
Discutir los problemas de certidumbre de seguridad física
Introducir casos de seguridad física y cómo estos serán usados en la validación de la seguridad física
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1115
Tópicos cubiertosValidación de la fiabilidadCertidumbre de seguridad físicaValoración de la seguridad físicaSeguridad física y casos de
confiabilidad
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1116
Validación de sistemas críticos
Los costos de verificación y validación para sistemas críticos involucran procesos de validación adicional para sistemas no críticos: Los costos y consecuencias de falla son altos de modo
que es más 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 reúne sus requerimientos de confiabilidad. Este caso de confiabilidad puede requerir actividades V & V específicas para ser llevadas a cabo.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1117
Costos de validaciónDebido a las actividades adicionales
involucradas, los costos de validación para sistemas críticos son normalmente significativamente altos que para los sistemas no críticos.
Normalmente, los costos V & V suben más del 50% del total de costos del desarrollo del sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1118
Validación de la fiabilidad
La validación de la fiabilidad involucra la práctica 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) atípico de datos de uso reales.
La medida de fiabilidad, por consiguiente, requiere de conjunto de datos especialmente diseñados que reproduzcan el patrón de entradas para ser procesados por el sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1119
El proceso de medida de la fiabilidad
Identificar perfiles
operacionales
Identificar perfiles
operacionales
Preparar conjunto de
datos de prueba
Preparar conjunto de
datos de prueba
Aplicar pruebas para
el sistema
Aplicar pruebas para
el sistema
calcular la confiabilidad observada
calcular la confiabilidad observada
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1120
Actividades de validación de fiabilidad
Establecer el perfil operacional para el sistema.
Construir datos de prueba que reflejan el perfil operacional.
Probar el sistema y observar el número de fallas y las veces de esas fallas.
calcular la fiabilidad después de que un número estadísticamente significativo de fallas han sido observadas.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1121
Pruebas estadísticas Probar el software para la fiabilidad, en lugar de
la detección de falla. Medir el número de errores permite predecir la
fiabilidad del software. Notar que, por razones estadísticas, más errores que son permitidos para que la especificación 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1122
Problemas de medida de fiabilidad
Incertidumbre de perfil operacional El perfil operacional no puede ser una reflexión
exacta del uso real del sistema. Altos costos de generación de datos de prueba
Los costos pueden ser muy altos si los datos de prueba para el sistema no son generados automáticamente.
Incertidumbre estadística Se necesita un número estadísticamente
significativo de fallas para calcular la fiabilidad, pero los sistemas muy fiables raramente fallarán.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1123
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 (más a menudo) depende de asunciones hechas sobre el patrón de uso del sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1124
Un perfil operacional
Clases de entrada
Nu
me
ro d
e e
mn
tra
da
s
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1125
Generación del perfil operacional
Debe generarse automáticamente siempre que sea posible.
La generación de perfil automático es difícil para sistemas interactivos.
Puede ser sincero para entradas “normales” pero es difícil para predecir “improbables” entradas y crear datos de prueba para ellas.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1126
Predicción de fiabilidad Un modelo de crecimiento de fiabilidad es un
matemático modelo del cambio de fiabilidad del sistema, tal como es probada y las fallas son retiradas.
Es usado como un medio de predicción de fiabilidad por extrapolación desde los datos actuales Simplifica la planificación de la prueba y
negociaciones del cliente. Se puede predecir cuando las pruebas se
completarán y demostrarán a clientes, si alguna vez, el crecimiento de la fiabilidad se logrará o no.
La predicción depende del uso de pruebas estadísticas para medir la fiabilidad de una versión del sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1127
El crecimiento de fiabilidad de paso – igual
0
2
4
6
8
10
12
14
T1 T2 T3 T4 T5
Tiempo
Fia
bli
dad
(R
OC
OF
)
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1128
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 proporción 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 fluctúan puede ser una reflexión más exacta de cambios reales de la fiabilidad.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1129
El crecimiento de fiabilidad de paso – aleatorio
0
2
4
6
8
10
12
14
T1 T2 T3 T4 T5
Tiempo
Fia
bli
dad
(R
OC
OF
)Notar diferentes
mejoras de fiabilidadReparación de falla
agregar fallas y fiabilidad decreciente (incremento ROCOF)
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1130
Selección 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 más apropiado puede, entonces, ser usado para la predicción de fiabilidad.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1131
Predicción de fiabilidad
Tiempo
Fia
bili
dad
Fiabilidad requerida
Logro de tiempo estimado de
fiabilidad
Curva modelo de fiabilidad
adecuada
= Medida de fiabilidad
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1132
Certidumbre de seguridad física
La certidumbre de seguridad física y medición de la fiabilidad son bastante diferentes: Dentro de los límites de error de medición, se
conoce si se ha logrado o no el nivel requerido de fiabilidad;
Sin embargo, la medición cuantitativa de la seguridad física es imposible. La certidumbre de fiabilidad física se preocupa por establecer un nivel de confianza en el sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1133
Confianza de seguridad física
La confianza en la seguridad física de un sistema puede variar de muy baja a muy alta.
La confianza se desarrolla a través de: Experiencia pasada con la compañía que
desarrolla software; El uso de procesos fidedignas y actividades del
proceso engranado a la seguridad física; El V & V extensivo que incluye las técnicas de
validación estática y dinámica.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1134
Revisiones de seguridad física
Revisar la función intencional correcta. Revisar para la estructura mantenible,
entendible. Revisar para verificar algoritmo y diseñar
estructura de dato contra la especificación. Revisar para verificar la consistencia del código
con diseño de algoritmo y estructura de datos. Revisar la suficiencia de prueba de sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1135
Revisar la guía Hacer el software tan simple como sea posible. Usar las técnicas más simples de desarrollo de
software que evita las estructuras propensas a error, tales como los punteros y la recursión.
Usar información que oculta la localización del efecto de alguna corrupción de datos.
Hacer uso apropiado de técnicas tolerantes a fallas pero no debe ser seducido a pensar que el software tolerante a falla es necesariamente segura físicamente.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1136
Argumentos de seguridad física Los argumentos de seguridad física se han propuesto
para mostrar que el sistema no puede alcanzarse en un estado inseguro.
Estos son más débiles que los argumentos de correctitud que deben mostrar que el código del sistema está conforma a su especificación.
Ellos generalmente están basados en la demostración por contradicción Asume que un estado inseguro puede ser alcanzado; Demostrar que esto es una contradicción por el código
del programa. A modelo gráfico de una argumento de seguridad física
puede ser desarrollado.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1137
Construcción de un argumento de seguridad física
Establecer las condiciones de salida de la seguridad física para un componente o un programa.
Empezando desde el FIN del código, trabajar hasta que se haya identificado todos los caminos que llevan a la salida del código.
Asumir que la condición de salida es falso. Mostrar que, para cada camino que lleva a la salida,
las asignaciones hicieron que ese camino contradiga la asunción de una salida insegura del componente.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1138
Código 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) ;
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1139
Modelo de argumento de seguridad física
Sobredosis administrada
Sobredosis administrada
administrarInsulinaadministrarInsulina
dosisActual > maxDosis
dosisActual > maxDosis
oo Pre-condición para un
estado inseguro
ContradicciónContradicción
dosisActual = maxDosis
dosisActual = maxDosisdosisActual = 0
dosisActual = 0Si estamento 2 no es ejecutado
Si estamento 2 no es ejecutado
Contradicción
AsignarAsignar
Si estamento 2 entonces la rama es
ejecutada
Si estamento 2 entonces la rama es
ejecutadaSi estamento 2 otra
rama alterna es ejecutada
Si estamento 2 otra rama alterna es
ejecutada
dosisActual = 0dosisActual = 0 dosisActual =
maxDosis
dosisActual = maxDosis
dosisActual > minDosis y
dosisActual <= maxDosis
dosisActual > minDosis y
dosisActual <= maxDosis
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1140
Caminos de programa Ninguna rama del if - estamento 2 es ejecutada
Sólo puede pasar si dosisActual => minDosis y <= maxDosis. then (entonces) una rama del if - estamento 2 es
ejecutada dosisActual = 0.
else (en otro caso) otra rama del if – estamento 2 es ejecutada dosisActual = maxDosis.
En todos los casos, las post condiciones contradicen la condición de inseguridad que la dosis administrada es mayor que la maxDosis.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1141
Certidumbre del proceso
La certidumbre del proceso involucra la definición de un proceso fidedigno y asegura que este proceso es seguido durante el desarrollo del sistema.
Tal como es discutido en el Capítulo 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 física, a veces “no
deben ser” requerimientos de modo que no pueden demostrarse a través de la prueba.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1142
Actividades del proceso relacionado con la seguridad física
La creación de un riesgo registrado y nonitoreo del sistema.
La designación de los ingenieros de seguridad física del proyecto.
Uso extensivo de las revisiones de seguridad física.
Creación de un sistema de certificación de seguridad física.
Gestión de configuración detallada (ver el Capítulo 29).
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1143
Análisis de riesgo El análisis de riesgo involucra los riesgos y sus
causas de raíz. Debe haber trazabilidad clara desde los riesgos
identificados a través del análisis 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 través del proceso.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1144
Entrada de registro de riesgo
Registro de riesgo Página 4: Impreso. 20/02/2003 Sistema : Sistema de bomba de insulinaIngeniero de seguridad: James Brown
Archivo: Bomba de Insulina/Seguridad/ RegistroRiesgoVersión de registro: 1/3
Riesgo identificado: Sobredosis de insulina entregada al paciente.
Identificado por: Jane Williams
Clase crítica: 1
Riesgo de identificación Alto
Árbol de falta identificado YES Fecha 24.01.99 Ubicación: Registro.Riesgo.Pág 5
Creadores del árbol de falta Jane Williams y Bill Smith
Árbol de falta revisado YES Fecha 28.01.99 Revisión: James Brown.
Requerimientos de diseño de seguridad de diseño
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 dónde 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 sustitución debe limitarse para ser no mayor que un valor del prefijado que se fija cuando el sistema se configura por el personal médico.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1145
La comprobación de seguridad física en tiempo de ejecución
Durante la ejecución de programa, las revisiones de seguridad física 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 declaración en algunos lenguajes). El código puede ser generado automáticamente para revisar esas declaraciones.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1146
Administración de insulina con aserciones
static void administerInsulin ( ) throws SafetyException {
int maxIncrements = InsulinPump.maxDose / 8 ;
int increments = InsulinPump.currentDose / 8 ;
// aserción 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
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1147
La valoración de seguridad contra delitos
La valoración de seguridad contra delitos tiene algo en común con la valoración de seguridad física.
Se piensa que demuestra que el sistema el sistema no puede entrar en algún estado (peligroso o un estado inseguro) en lugar de demostrar que el sistema puede hacer algo.
Sin embargo, hay diferencias Los problemas de seguridad física son accidentales; los
problemas de seguridad contra delitos son deliberados; Los problemas de seguridad contra delitos son más
genéricos – muchos sistemas padecen los mismos problemas; los problemas de seguridad física son principalmente al dominio de aplicación.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1148
Validación de la seguridad contra delitos
Validación basada en la experiencia El sistema es revisado y analizado contra los tipos de
ataques que son conocidos por el equipo de validación. Validación basada en herramientas
Varias herramientas de seguridad contra delitos como verificadores de contraseña son usados para el análisis del sistema en operación.
Equipos del tigre Un equipo es establecido cuya meta es abrir la brecha de
seguridad del sistema para la simulación de ataques en el sistema.
Verificación formal El sistema es verificado contra una especificación formal de
seguridad contra delitos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1149
Lista de control de seguridad contra delitos
¿Hacer que todos los archivos que se crean en la aplicación 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 automáticamente después de un periodo de inactividad? Las sesiones que quedan activas pueden permitir el acceso desautorizado a través de una computadora desatendida.
¿Si el sistema está escrito en un lenguaje de programación sin control de límite de arreglo, hay situaciones dónde el desborde de memoria intermediaria puede ser explotada? El desborde de memoria intermediaria puede permitir a los asaltadores enviar las cadenas de código al sistema y entonces ejecutarlos.
Si las contraseñas son fijas, hace que el sistema que controla esa contraseña sea "fuerte". Las contraseñas fuertes consisten en letras mezcladas, números y puntuación y no son entradas del diccionario normales. Ellos son más difíciles de romper que las contraseñas simples.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1150
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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1151
El caso de seguridad física de sistema
Es ahora una práctica normal, para un caso de seguridad física formal, ser requerido por toda la seguridad crítica de los sistemas basados en computadora, por ejemplo, el señalado de vía férrea, control de tráfico aéreo, etc.
Un caso de seguridad física es: Un cuerpo documentado de evidencia que proporciona un
convencimiento y argumento válido que un sistema está adecuadamente seguro para una aplicación dada en un ambiento dado.
Los argumentos en una seguridad física o un caso de confiabilidad pueden estar basados en una comprobación formal, razón de diseño, comprobación de seguridad física, etc. Los factores del proceso pueden, también, ser incluidos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1152
Componentes de un caso de seguridad física
Componente Descripción
Descripción del sistema
Una apreciación global del sistema y una descripción de sus componentes críticos.
Requerimientos de seguridad física
Los requerimientos de seguridad física resumidos de la especificación de requerimientos de sistema.
Peligro y análisis de riesgo
Documentos que describen los peligros y riesgos que se han identificado y las medidas tomadas para reducir el riesgo.
Análisis de diseño Un conjunto de argumentos estructurados que justifican por qué el diseño es seguro.
Verificación y validación
Una descripción de los procedimientos V & V usados y, dónde son apropiados, las pruebas se planean para el sistema. Los resultados de sistema V &V.
Informe de revisiones
Los registros de todos los diseños y revisiones de seguridad física.
Competencias de equipo
La evidencia de la competencia de todo el equipo involucrado en el desarrollo de sistemas relacionados con la seguridad física y la validación.
Proceso QA Los registros de los procesos de certidumbre de calidad llevadas a cabo durante el desarrollo del sistema.
Procesos de gestión de cambio
Los registros de todos los cambios propuestos, acciones tomadas y, dónde sea apropiado, la justificación de la seguridad física de estos cambios.
Casos de seguridad física asociados
Las referencias a otros casos de seguridad física que pueden impactar en estos casos de seguridad física.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1153
Estructura de argumento
EVIDENCIAEVIDENCIA
EVIDENCIAEVIDENCIA
EVIDENCIAEVIDENCIA
DEMANDADEMANDA<<ARGUMENTO>>
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1154
Argumento de bomba de insulina
Demanda: La sola dosis máxima 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 análisis estático para el software de bomba de insulina
Argumento: El argumento de seguridad presentado las muestras que la dosis máxima 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 análisis estático de control del software no reveló ninguna anomalía.
En conjunto, es razonable asumir que la demanda está justificada.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1155
Demandar jerarquíaLa bomba de insulina no entregará una dosis simple de insulina que es insegura
La bomba de insulina no entregará una dosis simple de insulina que es insegura
maxDosis es presentada cuando la bomba de insulina es configurada
maxDosis es presentada cuando la bomba de insulina es configurada
maxDosis es una dosis segura para el usuario de la bomba de insulina
maxDosis es una dosis segura para el usuario de la bomba de insulina
La máxima simple dosis computada por el software que no excede maxDosis
La máxima simple dosis computada por el software que no excede maxDosis
En operación normal, la máxima dosis computada no excederá maxDosis
En operación normal, la máxima dosis computada no excederá maxDosis
Si el software falla, entonces, la máxima dosis computada no excederá maxDosis
Si el software falla, entonces, la máxima dosis computada no excederá maxDosis
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1156
Puntos clave La medida de fiabilidad confía 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 cómo la fiabilidad de un sistema de software mejora de modo que es probado y las faltas son removidas.
Los argumentos de seguridad física o comprobaciones son una forma de demostración que una condición arriesgada nunca puede ocurrir.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1157
Puntos clave Es importante tener un proceso fidedigno para el
desarrollo de sistemas de seguridad física críticas. El proceso incluirá identificación del peligro y actividades de monitoreo.
La validación de seguridad puede incluir el análisis basado en la experiencia, el análisis basado en herramientas o el uso de “equipos tigre” para atacar el sistema.
Los casos de seguridad física recolectan al mismo tiempo la evidencia que un sistema es seguro.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1158
Capítulo 24
Personal de gerencia
Las personas de gerencia que trabajan como individuos y en
grupos
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1159
Objetivos Explicar algunos de los problemas involucrados
seleccionando y reteniendo el personal Describir factores que influencian en la motivación
individual Discutir problemas clave de equipos de trabajo
incluyendo composición, cohesividad y comunicaciones
Introducir el modelo de capacidad de madurez del personal (MCM-P) – una armazón para reforzar capacidades de las personas en una organización
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1160
Tópicos cubiertosSelección de personalMotivación de personasGestión de gruposEl modelo de madurez de capacidad
de personas
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1161
Las personas en el proceso Las personas son en una organización el
recurso más importante. Las tareas de un gerente son esencialmente
orientadas a personas. A menos que haya un poco de comprensión de las personas la gestión será infructuoso.
La pobre gestión de personas es un contribuyente importante para el fracaso del proyecto.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1162
Factores de gestión de personal
Consistencia Los miembros del equipo deben ser todos tratados de
una manera comparable sin favoritos o discriminación. Respeto
Diferentes miembros de equipo tienen habilidades diferentes y estas diferencias deben ser respetadas.
Inclusión 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1163
Selección de personal Una tarea de gestión de proyecto importante es
la selección de personal. La información en la selección viene de:
Información proporcionada por los candidatos. Información 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1164
Estudio de caso de selección de personal 1
Alicia es una gerente de proyecto de software que trabaja en una compañía que desarrolla sistemas de alarma. Esta compañía desea entrar en el mercado creciente de tecnología del asistencia para ayudar al anciano y a las personas inválidas a vivir independientemente. Alicia ha pedido llevar un equipo de 6 desarrolladores que pueden desarrollar nuevos productos basados alrededor de la tecnología de alarma de la compañía. Su primer papel es seleccionar a los miembros del equipo de ingenieros de software en la compañía o de fuera de ella.
Para ayudar a seleccionar un equipo, Alicia evalúa las habilidades que ella necesitará primero: Estas son:
1. Experiencia con la tecnología de alarma existente de modo que es reusado.
2. La experiencia en diseño de interfaz de usuario, porque los usuarios son inexpertos y pueden ser descartados y de necesidad de servicios como los tamaños de fuente de las variables, etc.
3. Idealmente, alguien que tiene experiencia en diseño de sistemas de tecnología de asistencia . Por otra parte, alguien con experiencia de comunicación física con las unidades del hardware, puesto que todos los sistemas a ser desarrollados involucran algún control del hardware.
Las habilidades de desarrollo de propósito general
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1165
Estudio de caso de selección de personal 2
La próxima fase es intentar y hallar las personas desde dentro de la compañía con las habilidades necesarias. Sin embargo, la compañía 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 días/semana. Ella, por consiguiente decide anunciar para el nuevo personal del proyecto, la lista de atributos que le gustaría:
1. Experiencia en programación con C. Ella ha decidido desarrollar todo el software de control de tecnología de asistencia en C.
2. Experiencia en diseño de interfaz de usuario. Un diseñador de IU es esencial ,pero no puede haber una necesidad por un nombramiento por jornada a tempo completo.
3. Experiencia en el la comunicación física 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 simpática para que ellos puedan relacionarse y puedan trabajar con la mayoría de personas que están proporcionando los requerimientos y que están probando el sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1166
Lecciones Los gerentes de una compañía no pueden desear
perder a las personas en un nuevo proyecto. La participación a tiempo parcial puede ser inevitable.
Las habilidades como el diseño de IU y las comunicaciones físicas con el hardware son para abreviar el suministro.
Los recién graduados pueden no tener habilidades específicas, pero pueden ser una manera de introducir nuevas habilidades.
La habilidad técnica puede ser menos importante que las habilidades sociales.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1167
Factores de selección de personal 1
Experiencia en el dominio de aplicación
Para desarrollar un sistema exitoso, los desarrolladores deben entender el dominio de la aplicación para un proyecto. Es esencial que algunos miembros de un equipo de desarrollo tengan un poco de experiencia del dominio.
Experiencia en la plataforma
Esto puede ser significativo si la programación de bajo nivel está involucrada. Por otra parte, no es normalmente un atributo crítico.
Experiencia en lenguajes de programación
Esto normalmente sólo es significativo para proyectos de duración corta dónde no hay bastante tiempo para aprender un nuevo leguaje. Mientras que el aprendizaje de un lenguaje no es difícil, toma varios meses para ponerse hábil usando las librerías asociadas y componentes.
Habilidad en la solución de problemas
Esto es muy importante para los ingenieros del software que constantemente tienen que resolver los problemas técnicos. Sin embargo, es casi imposible de juzgar sin saber el trabajo de un miembro potencial del equipo.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1168
Factores de selección de personal 2
Formación educacional
Esto puede proporcionar un indicador de los principios básicos 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 comunicación
Esto es importante debido a la necesidad del personal del proyecto 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 difícil de evaluar.
Personalidad Este es un atributo importante pero difícil de evaluar. Los candidatos deben ser bastante compatibles con los otros miembros del equipo. Ningún tipo particular de personalidad satisface más o menos a la ingeniería de software.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1169
Motivando personas Un rol importante de un gerente es motivar el trabajo
de las personas en un proyecto. La motivación es un problema complejo, pero
aparecen diferentes tipos de motivación basados en: Necesidades básicas (por ejemplo, comida, sueño,
etc.); Necesidades personales (por ejemplo, respeto,
autoestima); Necesidades sociales (por ejemplo, ser aceptado
como parte de un grupo).
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1170
Jerarquía de necesidades humanas
Necesidades de realización personal
Necesidades de estima
Necesidades sociales
Necesidades de seguridad física
Necesidades psicológicas
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1171
Necesidad de satisfacción Social
Proporcionar los recursos comunales; Permitir la comunicación informal.
Estima Reconocimiento de los logros; Premios apropiados.
Auto-realización Entrenamiento de personas que quieren aprender
más; Responsabilidad.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1172
Motivación individualEl proyecto de tecnología 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 diseño de hardware, empieza llegando tarde al trabajo, la calidad de su trabajo deteriora y, cada vez más, ella no parece estar comunicándose 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 podría estar afectando su trabajo. Ellos no conocen nada, para que Alicia decida hablar con Dorothy, para intentar entender el problema.
Después de negar que haya un problema, Dorothy admite que ella parece haber perdido el interés en el trabajo. Ella esperó un trabajo dónde desarrollaría y usaría sus conocimientos de interfaz con el hardware que aproveche sus habilidades. Sin embargo, ella está trabajando básicamente 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á difícil de encontrar un trabajo después 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 próximo proyecto, ha decidido que es mejor minimizar la conversación con ellos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1173
Tipos de personalidad La jerarquía de necesidades es casi con certeza
un sobre – simplificación de motivación en la práctica.
La motivación también debe tener en cuenta, los tipos de personalidades diferentes: Orientadas a la tarea; Orientada a si mismas; Orientadas a la interacción.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1174
Tipos de personalidad Orientadas a la tarea
La motivación 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 interacción La principal motivación es la presencia y acciones de
colaboradores. Las personas van a trabajar porque les gusta ir a trabajar.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1175
Equilibrio de la motivación 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 están justamente
motivadas por factores personales pero también por ser parte de un grupo y cultura.
Las personas van a trabajar porque están motivadas por las personas con que ellas trabajan.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1176
Gerencia de grupos La mayoría de la ingeniería de software son actividades
de grupo. El programa de desarrollo para más proyectos del
software no triviales es tal que ellos no pueden completarse por una sola persona que trabaja exclusivamente.
La interacción del grupo es una clave determinante del desempeño del grupo.
La flexibilidad en la composición del grupo está limitada Los gerentes deben hacer lo mejor que ellos pueden
con las personas disponibles.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1177
Factores que influyen en el funcionamiento del grupo
Composición del grupo.Cohesividad del grupo.Comunicaciones del grupo.Organización del grupo.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1178
Composición del grupo Grupo compuesto de miembros que comparten la misma
motivación que puede ser problemático Orientado a tareas – todos quieren hacer su propia cosa; Orientado a si mismo – todos quieren ser el jefe; Orientado a la interacción – demasiada conversación, no
bastante trabajo. Un grupo efectivo tiene un equilibrio de todos los tipos. Esto puede ser difícil de lograr para los ingenieros de
software que son a menudo orientados a tareas. La gente orientada a la interacción son muy importantes
puesto que ellos pueden detectar y calmar las tensiones que se levantan.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1179
Composición del grupoEl la creación de un grupo para el desarrollo de tecnología 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 interacción orientó. Ella se sentía que era principalmente del tipo orientado a si mismo, cuando ella se sentía que este proyecto era una manera en que ella se notaría por la gerencia mayor y sería promovida. Ella buscaba 1 o quizás 2 personalidades orientadas a la interacción, por consiguiente con el resto orientado a la tarea. La última valoración a que ella llegó era:
Alicia - orientada a si misma
Brian - orientado a tareas
Bob - orientado a tareas
Carol - orientada a la interacción
Dorothy - orientada a si misma
Ed - orientado a la interacción
Fred - orientado a tareas
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1180
La dirección depende del respeto del estado no titular
Puede haber un líder técnico y un líder administrativo.
La dirección democrática es más efectiva que la dirección autocrática.
La dirección del grupo
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1181
Cohesividad del grupo En un grupo cohesivo, los miembros consideran que el
grupo es más importante que cualquier individuo en él. La s ventajas de un grupo cohesivo son:
Los estándares 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 programación Egoless donde los miembros se esfuerzan por mejorar cada uno de los otros programas que pueden ser practicados
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1182
Espíritu de equipoAlicia 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 especificación del producto y diseña haciéndoles discutir la posible tecnología 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 sesión de información dónde Alicia les dice lo que ella sabe sobre las noticias de la organización a los miembros del grupo, las políticas, las estrategias, el etc. Cada miembro del equipo resume brevemente lo que ellos han estado haciendo entonces y el grupo discute algún tema general como las nuevas ideas del producto de los parientes más viejos.
Cada ciertos meses, Alicia organiza un "día libre" para el grupo dónde el equipo se pasa dos días "actualización de tecnología". Cada miembro del equipo prepara una actualización en un poco de tecnología pertinente y regalos de él al grupo. Esto es una reunión fuera del sitio habitual, que se encuentra en un buen hotel y se fija tiempo suficiente a para la discusión y la interacción social.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1183
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 través de Eventos sociales Desarrollando una identidad de grupo y territorio; Las actividades del grupo de construcción explícitas.
La franqueza con la información es una simple manera de asegurar a todos los miembros del equipo que se sientan parte del grupo.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1184
Los miembros de grupo tienden a ser leales s grupos cohesivos.
El “Pensamiento de grupo” es la preservación del grupo independiente de consideraciones técnicas u organizacionales.
La dirección debe actuar positivamente para evitar el pensamiento de grupo, forzando la participación externa con cada grupo.
Lealtades de grupo
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1185
Comunicaciones del grupo
Las buenas comunicaciones son esenciales para el efectivo grupo de trabajo.
La información debe ser intercambiada sobre el estado de trabajo, decisiones de diseño y cambios para decisiones previas.
Las buenas comunicaciones también fortalecen la cohesión de grupo así como pruebe la comprensión.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1186
Tamaño del grupo El más grande del grupo, lo más duro de las
personas para comunicarse con otros miembros del grupo.
Estructura del grupo La comunicación es buena en grupos estructurados
informalmente que en los grupos, que en los grupos estructurados jerárquicamente.
Composición del grupo La comunicación es buena cuando hay tipos de
personalidad diferente en un grupo y cuando los grupos son mixtos , en lugar de un solo sexo.
Comunicaciones del grupo
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1187
Organización del grupoGrupos de ingeniería de software pequeños
so normalmente organizados informalmente sin una estructura rígida.
Para grandes proyectos puede haber una estructura jerárquica donde diferentes grupos son responsables para diferentes subproyectos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1188
Grupos informales Los actos de grupo como un todo y vienen para un
consenso en las decisiones que afectan al sistema. Los servicios del líder del grupo como la interfaz externa
del grupo pero no asigna los artículos de trabajo específico.
Mas bien, el trabajo es discutido por el grupo en conjunto y las tareas se asignan de acuerdo a la habilidad y experiencia.
Esta aproximación tiene éxito para grupos donde todos los miembros experiencia y competencia.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1189
Grupos de programación extrema
Los grupos de programación extrema son variantes de una informal, organización democrática.
En los grupos de programación extrema, algunas decisiones de “dirección” son desarrollados por los miembros del grupos.
Los programadores trabajan en pares y toman una responsabilidad colectiva para el código que es desarrollado.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1190
Equipos de programadores principales
Consiste en un núcleo de especialistas ayudados por otros agregados al proyecto como requeridos.
La motivación detrás 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 mayoría del desarrollo del sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1191
Problemas Esta aproximación del programador principal, en formas
diferentes, ha tenido éxito en algunas escenas. Sin embargo, padece varios problemas
Los diseñadores talentosos y programadores son difíciles 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 crédito 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 están indisponibles.
Las estructuras organizacionales y las calidades en una compañía pueden ser incapaces de acomodarse a este tipo de grupo.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1192
La provisión del lugar de trabajo tiene un efecto importante en la productividad individual y satisfacción Confort; Privacidad; Recursos.
Salud y consideraciones de seguridad deben tenerse en cuenta Alumbrado; Calefacción; Mobiliario.
Ambientes de trabajo
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1193
Privacidad – cada ingeniero requiere un área de trabajo ininterrumpido.
Fuera del conocimiento – las personas prefieren trabajar con luz natural.
Personalización – los individuos adoptan diferentes prácticas de trabajo y gustan organizar su ambiente de diferentes maneras.
Factores ambientales
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1194
Organización de espacios de trabajo
Los espacios de trabajo deben proporcionar espacios privados donde la gente puede trabajar sin interrupción Proporcionando oficinas individuales para el
personal para aumentar la productividad. Sin embargo, los equipos que trabajan juntos
también requieren espacios donde reuniones formales e informales pueden sostenerse.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1195
Diseño de oficina
Sala de reunión
Oficina
Oficina
Oficina
Oficina
Oficina
Oficina
Oficina
Oficina
Área comunal
Ventana
Documentación compartida
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1196
El Modelo de Madurez de Capacidad del Personal
Pensado como una armazón para la gestión y desarrollo de la gente involucrada en el desarrollo del software.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1197
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 pequeño número de individuos.
Alinear la motivación de los individuos con esa de la organización
Ayudar a retener a las personas con conocimiento crítico y habilidades.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1198
Niveles del MMC-P Modelo de 5 fases
Inicial. Adecuado para la dirección de personas. Repetible. Las políticas desarrolladas para la mejora
de capacidad Definido. La dirección de las personas
estandarizadas a través de la organización Manejado. Las metas cuantitativas para la dirección
de las personas en el lugar Optimizando. El enfoque continuo en mejorar la
competencia individual y motivación de la mano de obra
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1199
El modelo de capacidad de personas
InicialInicial
RepetibleCompensaciónEntrenamientoGestión de desempeñoProvisión de personalComunicaciónAmbiente de trabajo
RepetibleCompensaciónEntrenamientoGestión de desempeñoProvisión de personalComunicaciónAmbiente de trabajo
DefinidoCultura participatoriaPrácticas basadas en la competenciaDesarrollo de carreraDesarrollo de competenciaPlanificación de mano de obraAnálisis de conocimiento y habilidades
DefinidoCultura participatoriaPrácticas basadas en la competenciaDesarrollo de carreraDesarrollo de competenciaPlanificación de mano de obraAnálisis de conocimiento y habilidades
ManejadoAlienación de desempeño personalDirección de competencia organizacionalPrácticas basadas en equipoConstrucción de equipoGuiando
ManejadoAlienación de desempeño personalDirección de competencia organizacionalPrácticas basadas en equipoConstrucción de equipoGuiando
OptimizandoInnovación de mano de obra continuaAdiestrandoDesarrollo de competencia personal
OptimizandoInnovación de mano de obra continuaAdiestrandoDesarrollo de competencia personal
Continuamente mejora de métodos para desarrollo personal y competencia
organizacional
Cuantitativamente manejo organizacional del crecimiento de las habilidades de mano de obra y
establecimiento de equipos basados en la competencia
Identificación de competencias primarias y actividades de
alineación de mano de obra con ellas
Introducir la disciplina dentro básica dentro de las
actividades de mano de obra
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1200
Puntos clave Los factores de selección de personal incluyen
educación, experiencia del dominio, adaptabilidad y personalidad.
Las personas son motivadas por la interacción, reconocimiento y desarrollo personal.
Los grupos de desarrollo de software deben ser pequeños y cohesivos. Los líderes deben ser competentes y deben tener soporte administrativo y técnico.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1201
Puntos clave Las comunicaciones entre grupos son
afectadas por el estado, tamaño de grupo, organización del grupo, y género y composición de la personalidad del grupo.
Los ambientes de trabajo serán incluidos espacios para la interacción y espacios para el trabajo privada.
El Modelo de Madurez de Capacidad de Personal es la armazón para mejorar las capacidades del personal en la organización.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1202
Estimation del costo del software
Capítulo 25
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1203
Objetivos Introducir los fundamentos de costos y precios
del software Describir tres métricas para evaluar la
productividad del software Explicar por qué deben ser usadas diferentes
técnicas para la estimación del software Describir los principios del modelo de estimación
del costo algorítmico COCOMO 2
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1204
Tópicos cubiertosProductividad del softwareTécnicas de estimación Modelo de costo algorítmicoDuración del proyecto y provisión del
personal
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1205
Preguntas de la estimación fundamentales
¿Cuánto esfuerzo se requiere para completar una actividad?
¿Cuánto tiempo del calendario es necesario para completar una actividad?
¿Cuál es el costo total de una actividad? Proyectar la estimación y planificación que
son actividades entrelazadas.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1206
Componentes del costo del software
Costos de hardware y software. Costos de viaje y entrenamiento. Costos de esfuerzo (el factor dominante de la mayoría 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 construcción, calefacción, alumbrado. Costos de redes de computadoras y comunicaciones. Costos de servicios compartidos (por ejemplo, librería,
restaurante del personal, etc.).
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1207
Costos y preciosLas estimaciones se hacen para descubrir
el costo, para el desarrollador, de producción de un sistema de software.
No hay una simple relación entre el costo de desarrollo y el precio cobrado al cliente.
La organización más ancha, económica, política y consideraciones comerciales influyen en el precio cobrado.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1208
Factores del precio del software
Oportunidad de mercado
Una organización 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 más ganancia después. La experiencia ganada puede permitir desarrollar los nuevos productos.
Incertidumbre en la estimación del costo
Si una organización está insegura de su estimación del costo, puede aumentar su precio por alguna contingencia de nuevo y por encima de su ganancia normal.
Condiciones contractuales
Un cliente puede estar deseoso de permitirle al diseñador retener la propiedad del código fuente y reusarlo en otros proyectos. El precio cobrado puede ser entonces menor, si el código fuente de software se entrega al cliente.
Volatilidad de requerimientos
Si es probable que los requerimientos cambien, una organización puede bajar su precio para ganar un contrato. Después de que el contrato se otorga, pueden cobrarse los precios altos por los cambios a los requerimientos.
Salud financiera Los desarrolladores en dificultad financiera pueden bajar su precio para ganar un contrato. Es bueno hacer uno más pequeño que la ganancia normal o incluso romper para salir del negocio.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1209
Un medida que es la proporción en la cual los ingenieros individuales involucran en el desarrollo del software, el producto software y documentación asociada.
No orientada a la calidad a pesar de que la certidumbre de calidad es un factor en la evaluación de la productividad.
Esencialmente, queremos medir la funcionalidad útil producida por unidad de tiempo.
Productividad del software
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1210
Medidas relacionadas al tamaño basadas en alguna salida del proceso del software. Estos pueden ser líneas de código fuente entregas, instrucciones de código objeto, etc.
Medidas relacionadas a la función basadas en una estimación de la funcionalidad del software entregado. Los puntos de función es la más conocida de este tipo de medidas.
Medidas de productividad
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1211
Estimación del tamaño de la medida (por ejemplo, cuántos puntos de función).
Estimación del número total de meses de programador que han pasado.
Estimación de la productividad del contratista (por ejemplo, el equipo de documentación) e incorporando esta estimación en la estimación global.
Problemas de la medición
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1212
¿Qué es una línea de código? La medida fue propuesta primero cuando los programas
eran tipeadas en tarjetas con una línea por tarjeta; Cómo hacer que esto corresponda para estamentos en
Java en la cual se puede medir por palmos de varias líneas o donde puede haber varios estamentos en una línea.
¿Qué programas deben contarse como parte del sistema? Este modelo asume que hay una relación lineal entre el
tamaño del sistema y el volumen de la documentación.
Líneas de código
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1213
A nivel más bajo del lenguaje, más productivo el programador La misma funcionalidad toma más código para
implementar en un lenguaje de bajo nivel que en un lenguaje de alto nivel.
A programador más verboso, más alta la productividad Las medidas de productividad basadas en líneas
de código sugiere que los programadores que escriben código verboso son más productivos que escriben código compactado.
Comparación de productividad
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1214
Tiempos de desarrollo del sistema
Análisis Diseño Codificación Prueba Documentación
Código Assembler
3 semanas 5 semanas 8 semanas 10 semanas
2 semanas
Lenguaje de alto nivel
3 semanas 5 semanas 4 semanas 6 semanas 2 semanas
Tamaño Esfuerzo Productividad
Código Assembler
5000 líneas 28 semanas 714 líneas /mes
Lenguaje de alto nivel
1500 líneas 20 semanas 300 líneas /mes
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1215
Puntos de función Basado en una combinación de características 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 función es computada por multiplicación de la cuenta de cada cuenta por el peso y la suma de todos los valores.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1216
Puntos de función El punto de función La cuenta del punto de función es
modificada por la complejidad del proyecto Los PFs pueden ser usados para estimar la LDC
dependiendo del promedio del número de LDC usadas por PF de un lenguaje dado LDC = PRC * número de puntos de función; PRC es un factor dependiente del lenguaje que
varía desde 200-300 para el lenguaje Assembler hasta 2-40 para un L4G;
Los PFs son muy subjetivos. Ellos dependen del estimador El conteo automático de los puntos de función es
imposible.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1217
Puntos objeto Los puntos objeto (alternativamente llamado puntos de
aplicación) son una alternativa de medida relacionada con función para puntos de función cuando L4G o lenguajes similares son usados para el desarrolladores
Los puntos objeto NO son lo mismo que las clases de objeto. El número puntos objeto en un programa es una estimación
pesada de El número de pantallas separadas que son desplegadas; El número de informes que son producidos por el sistema; El número de módulos de programa que deben ser
desarrollados para complementar el código de bases de datos;
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1218
Estimación de puntos objeto
Los puntos objeto son más fáciles de estimar desde una especificación que los puntos de función, puesto que ellos están interesados con pantallas, informes y módulos de lenguajes de programación.
Ellos pueden, por consiguiente, ser estimados en un punto bastante temprano del proceso de desarrollo.
En esta fase, es muy difícil estimar el número de líneas de código en un sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1219
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.
Estimación de productividad
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1220
Factores que afectan la productividad
Experiencia en el dominio de aplicación
El conocimiento del dominio de la aplicación es esencial para el desarrollo de un software eficaz. Es probable que los ingenieros que ya entienden un dominio sean los más productivos.
Calidad del proceso El proceso de desarrollo usado puede tener un efecto significativo en la productividad. Esto se cubre en el Capítulo 28.
Tamaño del proyecto
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.
Soporte tecnológico
El buen soporte de la tecnología como las herramientas CASE, sistemas de gestión de configuración, etc. puede mejorar la productividad.
Ambiente de trabajo
Cuando yo discutí en el Capítulo 25, un ambiente de trabajo quieto con áreas de trabajo privadas contribuye a mejorar la productividad.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1221
Todas las métricas 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 cómo la las métricas de productividad /calidad están relacionadas.
Si los requerimientos están cambiando constantemente entonces una aproximación basada en la cuenta de líneas de código no es significativa como el propio programa no es estático.
Calidad y productividad
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1222
Técnicas de estimación No hay ninguna manera simple para hacer una estimación
exacta del esfuerzo requerido para desarrollar un sistema de software Las estimaciones iniciales están basadas en la información
inadecuada y en una definición de requerimientos del usuario;
El software puede ejecutarse en computadoras poco familiares o usar nueva tecnología;
La gente en un proyecto puede ser desconocida. Las estimaciones del costo del proyecto puede estar
cumpliendo por si mismo. La estimación define el presupuesto y el producto es
ajustado para estar en el presupuesto.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1223
Cambio de tecnologías El cambio de tecnologías puede significar que la
experiencia de estimación previa no se lleva para los nuevos sistemas Sistemas de objetos distribuidos en lugar de sistemas
de sistema informático 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1224
Técnicas de estimaciónModelo de costo algorítmico.Juicio experto.Estimación por analogía.Leyes de Parkinson.Precio para ganar.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1225
Técnicas de estimaciónModelo de costo algorítmico
Un modelo basado en información histórica del costo que relaciona alguna métrica del software (normalmente su tamaño) al costo del proyecto es usado. Una estimación es hecha de esa métrica y el modelo predice el esfuerzo requerido.
Juicio experto Varios expertos en las técnicas de desarrollo de software propuestas y el dominio de la aplicación son consultados. Cada uno de ellos estima el costo del proyecto. Estas estimaciones son comparadas y discutidas. El proceso de estimación se itera hasta que una estimación concordada sea alcanzada.
Estimación por analogía
Esta técnica es aplicable cuando se han completado otros proyectos en el mismo dominio de la aplicación. El costo de un nuevo proyecto se estima por la analogía con estos proyectos completados. Myers (Myers 1989) da una descripción muy clara de este acercamiento.
Leyes de Parkinson
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 valoración objetiva. Si el software tiene que ser entregado en 12 meses y 5 personas están disponibles, el esfuerzo requerido se estima para ser 60 persona-meses.
Precio para ganar 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1226
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 pequeña. Los costos no reflejan precisamente el trabajo requerido.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1227
Estimación de arriba-abajo 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 más alto y accede a la
funcionalidad global y cómo esto es entregado a través de subsistemas.
De abajo-arriba Empieza a nivel de componente y estima el
esfuerzo requerido por cada componente. Agrega esos esfuerzos para hallar la estimación final.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1228
Estimación de arriba-abajoUtilizable sin el conocimiento de la
arquitectura y los componentes que podrían ser parte del sistema.
Toma en cuenta costos como la integración, gestión de configuración y documentación.
Puede subestimar el costo de resolver problemas técnicos de bajo nivel de dificultad.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1229
Estimación de abajo-arribaUtilizable cuando la arquitectura del
sistema es conocida y los componentes identificados.
Este puede ser un método exacto si el sistema ha sido diseñado en detalle.
Puede subestimar los costos al nivel de actividades del sistema como los de integración y documentación.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1230
Métodos de estimación Cada método tiene fortalezas y debilidades. La estimación debe estar basada en varios métodos. Si estos no devuelven aproximadamente el mismo
resultado, entonces se tiene insuficiente información disponible para hacer una estimación.
Alguna acción debe ser tomada para buscar más en orden para hacer estimaciones más exactas.
Precio para ganar es a veces el único método aplicable.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1231
Precio para ganar Esta aproximación puede parecer no ética y no
comercial. Sin embargo, cuando esté faltando información
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 especificación detallada puede ser negociada o una aproximación evolutiva usada por el desarrollo del sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1232
Modelamiento del costo algorítmico
El costo es estimado como una función matemática del producto, atributos del proceso y el proyecto cuyos valores son estimados por los gerentes del proyecto: Esfuerzo = A TamañoB M A es una constante dependendiente de la organización, B
refleja el esfuerzo desproporcionado para proyectos y M es un multiplicador que refleja atributos del producto, del proceso y de las personas.
El más comúnmente usado atributo del producto para la estimación del costo es el tamaño de código.
La mayoría de modelos son similares, pero usan diferentes valores parar A, B y M.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1233
Exactitud de la estimación
El tamaño de un sistema de software sólo puede conocerse con exactitud cuando esté terminado.
Varios factores influencian en el tamaño final Use de COTS y componentes; Lenguaje de programación; Distribución del sistema.
Como el desarrollo del programa progresa, entonces la estimación del tamaño se hace más exacta.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1234
Estimar la Incertidumbre
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1235
El modelo COCOMO Un modelo empírico basado en la experiencia
del proyecto. Bien documentado, modelo “independiente” que
no está atado a un vendedor específico de software.
La larga de la versión inicial publicada en 1981 (COCOMO-81) a través de varias instanciaciones para COCOMO 2.
COCOMO 2 toma en cuenta diferentes aproximaciones para el desarrollo del software, reuso, etc.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1236
COCOMO 81Complejidad del proyecto
Fórmula Descripción
Simple PM = 2.4(KDSI)1.05xM Aplicaciones bien entendidas desarrolladas por equipos pequeños.
Moderado PM = 3.0(KDSI)1.12xM Proyectos más complejos dónde los miembros del equipo pueden tener limitada experiencia en sistemas relacionados.
Empotrado PM = 3.6(KDSI)1.20xM Proyectos complejos dónde el software es parte de un complejo fuertemente acoplado al hardware, software, regulaciones y procedimientos operacionales.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1237
COCOMO 2COCOMO 81 fue desarrollado con la asunción
de un proceso de cascada será usado y que todo el software se desarrollará desde el principio.
Subsecuentemente su formulación, ha habido muchos cambios en la práctica de ingeniería de software y COCOMO 2 es diseñado para acomodar diferentes aproximaciones para el desarrollo del software.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1238
Modelos de COCOMO 2 COCOMO 2 incorpora un rango de submodelos que
producen las estimaciones de software cada vez más detalladas.
Los submodelos en COCOMO 2 son: Modelo de composición de aplicación. Usado cuando el
software es compuesto desde partes existentes. Modelo de diseño temprano. Usado cuando los
requerimientos están disponibles, pero el diseño no ha empezado todavía.
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 diseñado y más información acerca del sistema está disponible.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1239
Uso de modelos de COCOMO 2
Número de puntos de aplicación
Número de puntos de aplicación
Modelo de composición de
aplicación
Modelo de composición de
aplicación
Desarrollo de sistemas prototipo usando
guiones y programación de BD
Desarrollo de sistemas prototipo usando
guiones y programación de BD
Basado en Usado por
Número de puntos de
función
Número de puntos de
función
Modelo de diseño
temprano
Modelo de diseño
temprano
Estimación del esfuerzo inicial basado en requerimientos del sistema y opciones de
diseño
Estimación del esfuerzo inicial basado en requerimientos del sistema y opciones de
diseño
Basado en Usado por
Número de líneas de código
reusado o generado
Número de líneas de código
reusado o generado
Modelo de reuso
Modelo de reuso
Esfuerzo para integrar componentes
reusables o código generado
automáticamente
Esfuerzo para integrar componentes
reusables o código generado
automáticamente
Basado en Usado por
Número de líneas de código
fuente
Número de líneas de código
fuente
Modelo Post-arquitectónico
Modelo Post-arquitectónico
Basado en Usado porDesarrollo de esfuerzo
basado en la especificación de
diseño de sistemas
Desarrollo de esfuerzo basado en la
especificación de diseño de sistemas
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1240
Modelo de composición de aplicación
Soporta proyectos de prototipado y proyectos donde hay ruso extensivo.
Basado en estimaciones estándares de productividad de desarrollador en aplicación (objeto) puntos/mes.
Toma en cuenta el uso de herramienta CASE. La fórmula es
PM = ( NPA (1 - %reuso/100 ) ) / PROD
PM es el esfuerzo en personas – meses, NPA es el número de puntos de aplicación y PROD es la productividad.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1241
Productividad del punto objeto
Experiencia del desarrollador y capacidad
Muy alta
Baja Nominal Alto Muy alto
Madurez y capacidad del ICASE
Muy alta
Baja Nominal Alto Muy alto
PROD (NPO/mes)
4 7 13 25 50
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1242
Modelo de diseño temprano Las estimaciones pueden ser hechas después de que
los requerimientos han sido convenidos. Basado en una fórmula estándar para modelos
algorítmicos PM = A TamañoB M donde M = PERS RCPX RUSE PDIF PREX FCIL
SCED; A = 2.94 en la calibración inicial, Tamaño en KLDC, B
varia de 1.1 a 1.24 dependiendo de la novedad del proyecto, flexibilidad de desarrollo, aproximaciones en la gestión del riego y la madurez del proceso.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1243
Multiplicadores Los multiplicadores reflejan la capacidad de los
desarrolladores, los requerimientos no funcionales, la familiaridad con la plataforma de desarrollo, etc. RCPX – Fiabilidad del producto y complejidad; RUSE – Reuso requerido; PDIF – Dificultad de la plataforma; PREX – Experiencia personal; PERS – Capacidad personal; SCED – Planificación requerida; FCIL – los recursos de soporte del equipo.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1244
El modelo de reuso Toma en cuenta el código de caja negra que es
reusado sin cambio y código que ha sido adaptado para integrarlo con el nuevo código.
Hay dos versiones: El reuso de caja negra donde el código no es
modificado. Una estimación del esfuerzo (PM) es computada.
El reuso de caja blanca donde el código es modificado. Una estimación de tamaño equivalente para el número de líneas de nuevo código fuente es computada. Esto ajusta, entonces, la estimación del tamaño para el nuevo código.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1245
Estimación del modelo de reuso 1
Para el código generado: PM = (ASLOC * AT/100)/ATPROD ASLOC es el número de líneas de código
generado. AT es el porcentaje de código
automáticamente generado. ATPROD es la productividad de los ingenieros
en la integración de este código.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1246
Estimación del modelo de reuso 2
Cuando el código ha sido entendido e integrado: ESLOC = ASLOC * (1-AT/100) * AAM. ASLOC y AT como antes. AAM es el multiplicador de ajuste de
adaptación computado desde los costos de cambio del código reusado, los costos de entender cómo integrar el código y los costos de hacer la decisión de reuso.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1247
Nivel post-arquitectónico Se usa la misma fórmula del diseño temprano pero
con 17 en lugar de 7 multiplicadores asociados. El tamaño del código es estimado como:
Número de líneas de código a ser desarrollado Estimar el número equivalente de líneas de nuevo
código computado usando el modelo de reuso; Una estimación del número de líneas de código
que tienen que ser modificados de acuerdo al cambio de requerimientos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1248
Esto depende de 5 factores de la balanza (ver la próxima diapositiva). Su suma/100 se agrega a 1.01
Una compañía asume un proyecto en un nuevo dominio. El cliente no ha definido el proceso a ser usado y no ha permitido tiempo el análisis de riesgo. La compañía tiene un nivel de razón CMM 2 . Precedente- Nuevo proyecto(4) Flexibilidad en el desarrollo – ninguna participación del
cliente - Muy alto (1) Resolución Arquitectura/riesgo - Ningún análisis de riesgo -
Muy bajo.(5) Cohesión del equipo - nuevo equipo - nominal (3). Madurez del proceso - algún control - nominal (3)
El factor de equilibrio es por consiguiente 1.17.
El término exponente
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1249
Factores de equilibrio de exponente
Precedente Refleja la experiencia anterior de la organización con este tipo de proyecto. Las medias muy bajos indican ninguna experiencia anterior: Las medios extra altas indican que la organización está completamente familiarizado con este dominio de aplicación.
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 sólo fijan las metas generales.
Resolución arquitectura/ riesgo
Refleja la magnitud de análisis de riesgo llevada a cabo. La media baja indica análisis pequeño, las medias extra altas indican un análisis de riesgo completo.
Cohesión de equipo
Refleja cuan bien el equipo de desarrollo se conocen y trabajen juntos. Las medias muy bajos indican interacciones muy difíciles. Las medias extras altas indican un equipo integrado y efectivo sin los problemas de comunicación.
Madurez del proceso
Refleja la madurez del proceso del organización. El cómputo de este valor depende de la encuesta de madurez del MMC, pero una estimación puede lograrse substrayendo el proceso de madurez MMC del nivel 5.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1250
Atributos del producto Tiene relación con las características 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
Tiene relación con las características particulares del proyecto de desarrollo de software.
Multiplicadores
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1251
Efectos de manejadores de costo
Valor del exponente 1.17
Tamaño del sistema (incluye factores de reuso y volatilidad de requerimientos)
128.000 DSI
Estimación del COCOMO sin tener en cuenta los manejadores de costos
730 personas-mes
Confiabilidad Muy alta, multiplicador =1.39
Complejidad Muy alta, multiplicador =1.3
Restricciones de memoria Alta, multiplicador =1.21
Uso de herramienta Baja, multiplicador =1.12
Planificación Acelerada, multiplicador = 1.29
Estimación 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 Muy alta, multiplicador =0.72
Planificación Normal, multiplicador = 1
Estimación del COCOMO ajustado 295 personas-mes
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1252
Los modelos de costo algorítmico mantienen una base de planificación del proyecto cuando ellos permiten comparar las estrategias alternativas.
Sistema de nave espacial empotrado Debe ser fiable; Debe minimizar el peso (número de chips); Multiplicadores de fiabilidad y restricciones de computadora
> 1. Componentes de costo
Hardware designado; Plataforma de desarrollo; Esfuerzo de desarrollo.
Planificación del proyecto
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1253
Opciones de gestiónA. Uso de hardware existente, desarrollo
del sistema y desarrollo del equipo
A. Uso de hardware existente, desarrollo
del sistema y desarrollo del equipo
B. Procesador y memoria actualizada
Aumento del costo de hardware
Decrece experiencia
B. Procesador y memoria actualizada
Aumento del costo de hardware
Decrece experiencia
B. Memoria actualizada solamente
Aumento del costo de hardware
B. Memoria actualizada solamente
Aumento del costo de hardware
D. Personal de mayor experiencia
D. Personal de mayor experiencia
E. Nuevo desarrollo del sistema
Aumento del costo de hardware
Decrece experiencia
E. Nuevo desarrollo del sistema
Aumento del costo de hardware
Decrece experiencia
F. Personal con experiencia en hardware
F. Personal con experiencia en hardware
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1254
Costos de opción de costos
Opción CONF ALMAC
TIEMPO
HERRA LTEX Esfuerzo
total
Costo software
Costo hardware
Costo total
A 1.39 1.06 1.11 0.86 1 63 949399 100000 1049393
B 1.39 1 1 1.12 1.22 88 1313550 120000 1402025
C 1.39 1 1.11 0.86 1 60 895653 105000 1000635
D 1.39 1.06 1.11 0.86 0.84 51 769008 100000 897490
E 1.39 1 1 0.72 1.22 56 844425 220000 1044159
F 1.39 1 1 1.12 0.84 57 851180 120000 1002706
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1255
Elegir opción Opción D (usar personal más experimentado)
parece la mejor alternativa Sin embargo, tiene un alto riesgo asociado puesto
que el personal experimentado puede ser difícil de encontrar.
Opción 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1256
Duración del proyecto y provisión de personal
Así como la estimación 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 fórmula de COCOMO 2 TDEV = 3 (PM)(0.33+0.2*(B-1.01))
PM es el cálculo del esfuerzo y B es el exponente calculado como el anteriormente discutido (B es 1 para el modelo de prototipado temprano). Este cálculo predice el calendario nominal para el proyecto.
El tiempo requerido es independiente del número de personas que trabajan en el proyecto.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1257
Requerimientos de provisión de personal
El personal requerido no puede calcularse sumergiéndose en el tiempo de desarrollo de la planificación requerida.
El número de personas que trabajan en un proyecto varía dependiendo de la fase de un proyecto.
A más personas que trabajan en un proyecto, más esfuerzo total es normalmente requerido.
Un aumento muy rápido de personas a menudo pone en relación con el desprendimiento de la planificación.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1258
Puntos clave No hay una simple relación 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 tamaño 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1259
Puntos clave Técnicas diferentes de estimación del costo serán
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 algorítmico soporta el análisis de opción cuantitativa de modo que permite comparar los costos de diferentes opciones.
El tiempo para completar un proyecto no es proporcional para el número de personas que trabajan en el proyecto.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1260
Gestión de calidad
Capítulo 26
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1261
Objetivos Introducir el proceso de gestión y actividades de
gestión de calidad claves Explicar el rol de los estándares en la gestión de
calidad Explicar el concepto de métrica del software,
métricas de predicción y métricas de control Explicar cómo la medida puede ser usada en la
evaluación del software y las limitaciones de la medida del software
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1262
Tópicos cubiertosCalidad del proceso y el productoLa certidumbre de calidad y
estándaresPlanificación de calidadControl de calidad
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1263
Gestión de la calidad del software
Se preocupa por asegurar el nivel requerido de calidad logrado en un producto del software.
Involucra una definición apropiada de los estándares 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1264
¿Qué es la calidad?
Calidad, simplemente, significa que un producto debe cumplir con su especificación.
Esto es problemático para los sistemas de software Hay una tensión 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 difíciles de especificar de una manera no ambigua;
Las especificaciones del software son normalmente incompletas y a veces inconsistentes.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1265
El compromiso de la calidad
Nosotros no podemos esperar las especificaciones para mejorar, antes de una provechosa atención a la gestión de la calidad.
Nosotros debemos poner los procedimientos de gestión en lugar de mejorar la calidad a pesar de la especificación imperfecta.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1266
Alcance de la gestión de calidad
La gestión de calidad es particularmente importante para grandes, complejos sistemas. La documentación de la calidad es un registro del progreso y continuidad del soporte del desarrollo como los cambios del equipo de desarrollo.
Para los más pequeños sistemas, la gestión de calidad necesita menos documentación y se debe enfocar en establecer una cultura de calidad.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1267
Actividades de gestión de calidad
La certidumbre de calidad Establecer procedimientos organizacionales y estándares
para la calidad. Planificación de calidad
Seleccionar procedimientos aplicables y estándares para un proyecto particular y modificar estos como es requerido.
Control de calidad Asegurar que los procedimientos y estándares sean
seguidas por el equipo de desarrollo de software. La gestión de calidad debe estar separada de la gestión del
proyecto para asegurar la independencia.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1268
Gestión de calidad y desarrollo de software
Proceso de desarrollo del
software
Proceso de gestión de
calidad
Estándares y procesos
D1 D2 D3 D4 D5
Plan de calidad
Informes de revisión de calidad
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1269
La calidad del desarrollo de un producto está influenciada por la calidad del proceso de producción.
Esto es importante en el desarrollo del software, puesto que algunos atributos de calidad son difíciles de evaluar.
Sin embargo, hay una muy complejo y pobremente entendida relación entre el proceso de software y la calidad del producto.
Proceso y calidad del producto
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1270
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 aplicación de habilidades individuales y la experiencia
son particularmente importantes en el desarrollo del software;
Los factores externos como la novedad de una aplicación o la necesidad para un plan acelerado de desarrollo pueden dañar la calidad del producto.
El cuidado que debe tenerse para no imponer estándares de procesos inapropiados – estos podrán reducir en lugar de mejorar la calidad del producto.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1271
Calidad basada en el proceso
Definir el proceso
Definir el proceso
Desarrollar el producto
Desarrollar el producto
Acceder la calidad del
producto
Acceder la calidad del
producto
Proceso de mejora
Proceso de mejora
Proceso de estandarización
Proceso de estandarización
Calidad OK
Calidad OK
SiNo
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1272
Definir los estándares del proceso tal como deben conducirse las revisiones, la gestión de configuración, etc.
Supervisar el proceso de desarrollo para asegurar que se están siguiendo los estándares.
Informe del proceso para la gestión del proyecto y terceros del software.
No usar prácticas impropias simplemente porque se han establecido los estándares.
La calidad del proceso práctica
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1273
Los estándares son la clave para una gestión de calidad efectiva.
Estos pueden ser internacionales, nacionales, organizacionales o estándares de proyecto.
Estándares del producto define características que todos los componentes deben exhibir, por ejemplo, un estilo común de programación.
Estándares del proceso define como el proceso del software debe promulgarse.
Certidumbre de la calidad y estándares
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1274
Encapsulamiento de mejor práctica – evita la repetición de errores del pasado.
Ellos son una armazón para la certidumbre de calidad del proceso – ellos involucran la complacencia de comprobación de los estándares.
Ellos proporcionan continuidad – el nuevo personal puede entender la organización por entendimiento de los estándares que son usados.
Importancia de los estándares
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1275
Producto y estándares del proceso
Estándares del producto Estándares del procesoFormulario de revisión del diseño
Conducta de revisión del diseño
Estructura del documento de requerimientos
La sumisión de documento para MC
Formato de encabezamiento del método
Proceso de lanzamiento de versión
Estilo de programación en Java
Plan del proyecto de aprobación del proceso
Formato del plan del proyecto
Proceso de control de cambio
Formulario de demanda del cambio
Prueba del proceso magnetofónico
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1276
Problemas con los estándaresEllos pueden no verse como relevantes y
actualizados por los ingenieros de software.Ellos a veces involucran demasiadas formas
burocráticas de completar.Si ellos no son soportados por herramientas
de software, el trabajo manual tedioso es a menudo para mantener la documentación asociada con los estándares.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1277
Involucrar a los practicantes en el desarrollo. Los ingenieros deben entender la razón que está debajo de un estándar.
Revisar estándares y su uso regularmente. Los estándares pueden rápidamente volverse anticuadas y esto reduce su credibilidad entre los practicantes.
Los estándares detalladas deben tener asociadas herramientas de soporte. El excesivo trabajo de oficina es la más significativa queja contra los estándares.
Desarrollo de estándares
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1278
ISO 9000 Un conjunto internacional de estándares
para la gestión de calidad. Aplicable para un rango de organizaciones
desde fábricas para reparar las industrias. ISO 9001 aplicable para organizaciones que
diseñan, desarrollan y mantienen productos. ISO 9001 es un modelo genérico del
proceso de calidad que puede ser instanciado para cada organización usando el estándar.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1279
ISO 9001Responsabilidad de gestión Sistema de calidad
Control de productos no conformes
Control de diseño
Manejo, almacenamiento, empaquetamiento y entrega
Compra
Productos proporcionados por el comprador
Identificación del producto y trazabilidad
Control del proceso Inspección y pruebaInspección y equipo de prueba Inspección y estado de pruebaRevisión del contrato Acción correctivaControl del documento Registros de calidadAuditorias de calidad interna EntrenamientoReparación Técnicas estadísticas
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1280
Certificación ISO 9000 Los estándares 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 estándares ISO 9000.
Algunos clientes demandan a los proveedores que sean ISO 9000 certificados aunque la necesidad de flexibilidad aquí se reconoce cada vez más.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1281
ISO 9000 y gestión de calidadModelos de
calidad ISO 9000
Modelos de calidad ISO 9000
Manual de calidad de la organización
Manual de calidad de la organización
Plan de calidad del Proyecto 1
Plan de calidad del Proyecto 1
Plan de calidad del Proyecto 2
Plan de calidad del Proyecto 2
Plan de calidad del Proyecto 3
Plan de calidad del Proyecto 3
Gestión de calidad del proyecto
Gestión de calidad del proyecto
Proceso de calidad de la organización
Proceso de calidad de la organización
Instanciado como
Es usado para desarrollo
Documentos
Instanciado como
Soportes
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1282
Estándares de documentación
Particularmente importante – los documentos son la manifestación tangible del software.
Estándares del proceso de documentación Relacionado con cómo debe ser desarrollado, validado y
mantenido. Documentar estándares
Relacionado con contenido de documentos, estructura, y apariencia.
Documentar estándares de intercambio Relacionado con la compatibilidad de documentos
electrónicos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1283
Proceso de documentación
Crear boceto inicial
Crear boceto inicial
Revisar boceto
Revisar boceto
Incorporara comentarios de revisión
Incorporara comentarios de revisión
Rebosquejar documento
Rebosquejar documento
Corregir textoCorregir texto Producir boceto final
Producir boceto final
Chequear boceto final
Chequear boceto final
Configurar texto
Configurar texto
Revisar esquema
Revisar esquema
Producir de matrices de impresión
Producir de matrices de impresión
Imprimir copias
Imprimir copias
Fase 1: Creación
Fase 1: Publicación
Fase 3: Producción
Documento aprobado
Documento aprobado
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1284
Estándares de documento Documentar estándares de identificación
Como son singularmente identificados los documentos.
Documentar estándares de estructuras Estructura estándar para documentos del
proyecto. Documentar estándares de presentación
Define fuentes y estilos, use de logotipos, etc. Documentar estándares de actualización
Define cómo cambian las versiones previas y se reflejan en un documento.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1285
Estándares de intercambio de documentos
Los estándares de intercambio permiten documentos electrónicos para ser intercambiados, envíos por correo, etc.
Los documentos son producidos usando diferentes sistemas y en diferentes computadoras. Incluso cuando se usan herramientas estándares 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 estándar de archivo puede ser definido para asegurar que el documento puede ser accedido en el futuro.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1286
Planificación de calidad Un plan de calidad presenta las calidades
deseadas del producto y cómo estas son evaluadas y define los atributos de calidad más significativos.
El plan de calidad debe definirse el proceso de valoración de calidad.
Deben presentarse que estándares organizacionales y donde sea necesario, definir nuevos estándares a ser usados.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1287
Planes de calidad Estructura del plan de calidad
Introducción del producto; Planes del producto; Descripciones del proceso; Metas de calidad; Riesgos y gestión de riesgos.
Planes de calidad deben ser documentos cortos, sucintos Si ellos son demasiado largos, nadie los leerá
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1288
Atributos de calidad del software
Seguridad física Comprensibilidad Portabilidad
Seguridad contra delitos
Comprobabilidad Usabilidad
Fiabilidad Adaptabilidad Reusabilidad
Elasticidad Modularidad Eficiencia
Robustez Complejidad Aprendebilidad
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1289
Control de calidadEsto involucra la comprobación del
proceso de desarrollo de software para asegurar que los procedimientos y estándares serán seguidos.
Hay dos aproximaciones para el control de calidad Revisiones de calidad; Valoración del software automatizada y
medida del software.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1290
Revisiones de calidad Es el principal método de validación de calidad de un
proceso o producto. Un grupo examina parte o todo de un proceso o
sistema y su documentación para encontrar problemas potenciales.
Hay diferentes tipos de revisión y con diferentes objetivos Inspecciones para remover defectos (producto); Revisiones para la valoración del progreso
(producto y proceso); Revisiones de calidad (producto y proceso).
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1291
Tipos de revisiónTipos de revisión
Propósito principal
Inspecciones de diseño o programa
Para detectar los errores detallados en los requerimientos, diseño o código. Una lista de control de posibles errores debe manejar la revisión.
Revisiones del progreso
Para mantener la información para la gestión acerca del progreso global del proyecto. Este es un proceso y una revisión del producto y se preocupa por los costos, planes y horarios.
Revisiones de calidad
Llevar a cabo un análisis técnico de componentes del producto o documentación para encontrar las desigualdades entre la especificación y el diseño del componente, código o documentación y asegurar los estándares de calidad definidos se han seguido.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1292
Un grupo de gente examina cuidadosamente parte o todo un sistema de software y la documentación asociada.
Código, diseños, especificaciones, planes de prueba, estándares, etc., pueden todos ser revisados.
El software o documentos pueden ser “fuera de contrato” en una revisión que significa que ese progreso para la próxima fase de desarrollo, ha sido aceptado por la dirección.
Revisiones de calidad
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1293
Funciones de revisión Función de calidad – ellas son parte del
proceso de gestión de calidad general. Función de gestión de proyecto – ellas
proveen de información para los gerentes del proyecto.
Entrenamiento y función de comunicación – el conocimiento del producto es pasado entre los miembros del equipo de desarrollo.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1294
Revisiones de calidad El objetivo es el descubrimiento de los defectos e
inconsistencias del sistema. Cualquier documento producido en el proceso
puede ser revisado. Los equipos de revisión deben ser relativamente
pequeños y las revisiones deben ser bastante cortas.
Los registros de revisión de calidad siempre deben ser mantenidos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1295
Los comentarios hechos durante la revisión serán clasificados Ninguna acción. Ningún cambio para el software o
documentación es requerido; Refiere para reparar. El diseñador o programador
debe corregir una falla identificada; Reconsiderar el diseño global. El problema
identificado en la revisión impacta en otras partes del diseño. Algún juicio global debe hacerse acerca de la manera más rentable de solución del problema;
Los requerimientos y especificación de errores pueden tener que ser enviados al cliente.
Resultados de la revisión
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1296
Medidas y métricas del software La medida del software está relacionada con la
derivación de un valor numérico para un atributo del producto software o proceso.
Esto permite comparaciones objetivas entre técnicas y procesos.
Aunque algunas compañías han introducido programas de medidas, la mayoría de organizaciones aun no hacen uso sistemático de la medida del software.
Hay alguno que estableció estándares en esta área.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1297
Algún tipo de mediada que relaciona a un sistema de software, proceso o documentación relacionada Líneas de código en un programa, el índice Fog,
número de persona – días 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 métricas del producto pueden ser usadas para predicciones generales o para identificar componentes anómalos.
Métricas del software
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1298
Métricas de control y predicción
Proceso de software
Proceso de software
Medidas de control
Medidas de control
Decisiones de gestión
Decisiones de gestión
Medidas de predicción
Medidas de predicción
Producto software
Producto software
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1299
Una propiedad del software puede ser mediada. La interrelación existe entre lo que nosotros
podemos saber y lo que nosotros queremos saber know. Nosotros sólo podemos medir atributos internos, pero a menudo son más interesantes los atributos externos del software
Esta interrelación se ha formalizado y validado. Puede ser más difícil relacionar lo que puede ser
medido para los atributos de calidad externos deseables.
Asunciones de métricas
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1300
Atributos internos y externos
MantenibilidadMantenibilidad
FiabilidadFiabilidad
PortabilidadPortabilidad
UsabilidadUsabilidad
Número de parámetros de procedimiento
Número de parámetros de procedimiento
Complejidad ciclomática
Complejidad ciclomática
Tamaño del programa en líneas de código
Tamaño del programa en líneas de código
Número de mensajes de error
Número de mensajes de error
Longitud de manual del usuario
Longitud de manual del usuario
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1301
El proceso de medidaUn proceso de mediada del software puede
ser parte del proceso de control de calidad.La recolección 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 través de proyectos se hacen posibles.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1302
Proceso de medida del producto
Elegir medidas a ser hechas
Elegir medidas a ser hechas
Seleccionar componentes ser evaluadas
Seleccionar componentes ser evaluadas
Medir características de
componentes
Medir características de
componentes
Identificar medidas
anómalas
Identificar medidas
anómalas
Analizar componentes
anómalas
Analizar componentes
anómalas
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1303
Recolección de datos Un programa de métricas 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, automáticamente.
Tres tipos de recolección automática de datos Análisis del producto estático; Análisis del producto dinámico; Procesar comparación de datos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1304
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 evaluación del
personal. No confiar en la memoria
Recolectar los datos cuando no son generado después de que un proyecto ha finalizado.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1305
Una métrica de calidad debe ser un predictor de calidad del producto.
Clases de métricas del producto Las métricas dinámicas son recolectadas por medidas
hechas en una ejecución de programa; Las métricas estáticas son recolectadas por medidas
hechas de las representaciones del sistema; Las métricas dinámicas ayudan a evaluar la eficiencia y
la fiabilidad, las métricas estáticas ayudan a evaluar la complejidad, la comprensibilidad y la mantenibilidad.
Métricas del producto
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1306
Métricas dinámicas y estáticas
Las métricas dinámicas están estrechamente relacionadas a los atributos de calidad del software Es relativamente fácil para medir el tempo de
respuesta de un sistema (atributo de desempeño) o el número de fallas (atributo de fiabilidad).
La métricas dinámicas tienen un relación indirecta con los atributos de calidad Se necesita intentar y derivar una interrelación
entre estas métricas y propiedades como la complejidad, comprensibilidad y mantenibilidad.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1307
Métricas del producto software
Métricas del software Descripción
Fan-in /Fan-out Fan-in es una medida del número de funciones o métodos que llaman alguna otra función o método (digamos X). Fan-out es el número de funciones que son llamadas por la función X. Un alto valor para fan-in significa que X se acopla herméticamente al resto del diseño y los cambios para X tendrán 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 lógica del control necesario para coordinar los componentes llamados.
Longitud del código Ésta es una medida del tamaño de programa. Es probable que esta sea, la más grande de tamaños de código de un componente, ea más compleja y propensa a error. La longitud de código ha mostrado ser una de las métricas más fiables por predecir la propensión a error de los componentes.
Complejidad ciclomática
Esta es una medida de la complejidad del control de un programa. Esta complejidad del control puede relacionarse para programar la comprensibilidad. Yo discuto cómo calcular la complejidad ciclomática en el Capítulo 22.
Longitud de identificadores
Esta es una medida de la media longitud de identificadores distintos en un programa. El más largo de los identificadores, el más probablemente de ser significativo y el más entendible del programa.
Profundidad de anidación 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 están potencialmente propensas a error.
Índices Fog Esta es una medida de la media de la longitud de palabras y frases en los documentos. El más alto el valor para el índice Fog, el más difícil el documento es el entendimiento.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1308
Métricas orientadas al objeto
Métricas orientadas al objeto
Descripción
Profundidad del árbol de herencia
Esta representa el número de niveles discretos en el árbol de la herencia dónde las subclases heredan atributos y operaciones (métodos) de las superclases. El más profundo árbol de herencia, el más complejo del diseño. Muchas clases de objetos diferentes pueden tener que ser entendidas para entenderlas clases de objetos en las hojas del árbol.
Método Fan-in /Fan-out
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 distinción entre las llamadas de otros métodos dentro del objeto y que puede llamar de métodos externos.
Métodos pesados por la clase
Esta es el número de métodos que son incluidos en una clase pesada por la complejidad de cada método. Por consiguiente, un método simple puede tener una complejidad de 1 y un método grande y complejo un valor mucho más alto. El más grande el valor para este métrica, el más complejo la clase de objetos. Los objetos complejos son más probablemente difíciles de entender. Ellos no pueden ser lógicamente cohesivos de modo que no puede reusarse eficazmente como las superclases en un árbol de herencia.
Número de operaciones de desborde
Esta es el número de operaciones en una superclase que se sobreponen en una subclase. Un valor alto para este métrica indica que la superclase usada no puede ser un padre apropiado para la subclase.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1309
Análisis de la medidaNo siempre es obvio que datos
significan Analizar los datos recolectados es
difícil.Los profesionales de estadística deben
ser consultados si están disponibles.El análisis de datos debe tener en
cuenta las circunstancias locales.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1310
Sorpresas de la medida Reduciendo el número de fallas de un programa
lleva a un número aumentado de llamadas de oficina de ayuda El programa es ahora pensado como más 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 más fiable es usado de una manera diferente en un sistema donde los usuarios trabajan alrededor de las fallas Esto lleva a más llamadas de la oficina de ayuda
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1311
Puntos clave La gestión de calidad del software se preocupa por
asegurar que ese software reúne sus estándares requeridos.
Los procedimientos de certidumbre de calidad deben ser documentados en un manual de calidad organizacional
Los estándares son un encapsulamiento de la mejor práctica.
Las revisiones son las más ampliamente usadas aproximaciones para evaluar la calidad del software
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1312
Puntos claveLa medida del software recoge información
acerca del proceso de software y el producto software.
Las métricas de calidad del software deben ser usadas para identificar componentes potencialmente problemáticos.
No hay métricas de software estandarizadas y universalmente aplicables.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1313
Mejora del proceso
Capítulo 27
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1314
Explicar los principios de mejora del proceso de software
Explicar cómo los factores del proceso de software influyen en la calidad del software y la productividad
Explicar cómo desarrollar los modelos simples de desarrollo de software
Explicar la noción de capacidad del proceso en el modelo de mejora del proceso MCMI
Objetivos
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1315
Calidad del proceso y del productoClasificación del procesoMedida del procesoAnálisis del proceso y modelamientoCambio del procesoLa armazón de mejora del proceso CMMI
Tópicos cubiertos
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1316
El entendimiento del proceso existente y la introducción de cambios al proceso para mejorar la calidad del producto, reduce los costo o acelera los calendarios.
Más trabajo de mejora del proceso se ha enfocado hasta ahora en la reducción del defecto. Esto refleja la creciente atención pagada por la industria para la calidad.
Sin embargo, otros atributos del proceso pueden se también el enfoque de mejora.
Mejora del proceso
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1317
Atributos del procesoCaracterísticas del
procesoDescripción
Comprensibilidad ¿Hasta qué punto el proceso se define explícitamente y cómo de fácil es él entender la definición 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 diseña 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 ¿Cuán rápido pueda el proceso entregar un sistema desde que una especificación dada se ha completado?
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1318
El ciclo de mejora del proceso
MedidaMedida
Análisis Análisis CambioCambio
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1319
Medida del proceso Los atributos del proceso actual son medidos.
Estos son una línea de base para evaluar mejoras. Análisis 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 análisis son introducidos.
Fases de la mejora del proceso
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1320
La calidad del proceso y calidad del producto están 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 diseño, otros factores están también involucrados, especialmente las capacidades de los diseñadores.
Calidad del proceso y del producto
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1321
Factores de calidad de producto principales
Tecnología de desarrollo
Costo, tiempo y calendario
Calidad del
proceso
Calidad de la gente
Calidad del producto
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1322
Factores de calidad Para proyectos grandes con capacidades
“promedio”, proceso de desarrollo determina la calidad del producto.
Para pequeños proyectos, la capacidad de los desarrolladores es el principal determinante.
La tecnología de desarrollo es particularmente significativa para pequeños proyectos.
En todos los casos, si un calendario poco realista es impuesto, entonces, la calidad del producto sufrirá.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1323
Informal Ningún 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.
Metódico Procesos apoyados por algún método de desarrollo como
el RUP. Apoyado
Proceso apoyado por herramientas CASE automatizadas.
Clasificación del proceso
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1324
Aplicabilidad del proceso
Proceso informal
Proceso informal
Proceso manejado
Proceso manejado
Proceso metódico
Proceso metódico
Prototipos
Sistemas de tiempo de vida cortos
Sistemas de negocios L4G
Sistemas de tamaño pequeño/mediano
Prototipos
Sistemas de tiempo de vida cortos
Sistemas de negocios L4G
Sistemas de tamaño pequeño/mediano
Sistemas grandes
Productos de tiempo de vida largo
Sistemas grandes
Productos de tiempo de vida largo
Dominios de aplicación bien entendidos
Sistemas de reingienería
Dominios de aplicación bien entendidos
Sistemas de reingienería
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1325
El proceso usado debe depender del tipo de producto que se está desarrollando
Para grandes sistemas, la gestión es normalmente el principal problema que se necesita para un proceso estrictamente manejado;
Para pequeños sistemas, más informalidad es posible. No hay ningún proceso uniformemente aplicable que pueda ser
estandarizado dentro de una organización Puede incurrirse en altos costos si se fuerza un proceso inapropiado
a un equipo de desarrollo; Métodos inapropiados puede también incrementar los costos y
pueden llevar a reducir la calidad.
Elegir proceso
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1326
Soporte de herramientas del proceso
Proceso informal
Proceso informal
Proceso manejado
Proceso manejado
Proceso metódico
Proceso metódico
Proceso de mejora
Proceso de mejora
Herramientas genéricas
Herramientas de gestión de configuración
Herramientas de gestión de
proyecto
Herramientas especializadas
Análisis y bancos de trabajo del
diseño
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1327
Dondequiera sea posible, los datos de procesos cuantitativos deben ser recolectados Sin embargo, donde las organizaciones no han definido
claramente los estándares del proceso esto es muy difícil 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 organización.
Medida del proceso
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1328
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-días.
Número de ocurrencias de un evento particular Por ejemplo, el número de defectos
descubiertos.
Clases de medidas del proceso
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1329
Metas ¿Qué está probando la organización 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.
Métricas Las medidas a ser recolectadas para responder
las preguntas.
Paradigma Meta-Pregunta-Métrica
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1330
Análisis del proceso y modelamiento
Análisis 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 documentación de un proceso que registra
las tareas, los roles y las entidades usadas; Los modelos de proceso pueden presentarse
desde diferentes perspectivas.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1331
Estudiar un proceso existente para entender sus actividades.
Producir un modelo abstracto del proceso. Se debe representar normalmente esto gráficamente. Varias vistas diferentes (por ejemplo, actividades, entregables) pueden ser requeridas.
Analizar el modelo para descubrir problemas del proceso. Esto involucra la discusión de actividades del proceso con los stakeholders y el descubrimiento de problemas y posibles cambios del proceso.
Análisis del proceso y modelamiento
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1332
Modelos del proceso publicados y estándares del proceso Siempre es mejor empezar el proceso de análisis con un
modelo existente. Las personas, entonces, pueden extenderse y cambiar esto.
Cuestionarios y entrevistas Deben ser cuidadosamente diseñadas. Los participantes
pueden decir lo que ellos piensan de lo que se quiere oír. Análisis etnográfico
Involucra la asimilación del conocimiento del proceso por observación. La mejor para una análisis a fondo de fragmentos del proceso en lugar de la comprensión del proceso total.
Técnicas de análisis del proceso
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1333
Elementos del modelo de proceso 1
Actividad (mostrada como un rectángulo con sombra)
Una actividad tiene un objetivo claramente definido, condiciones de entrada y salida. Ejemplos de actividades son la preparación de un conjunto de datos para probar un módulo, codificación de una función o un módulo, prueba de lectura de un documento, etc. Generalmente, una actividad es atómica, es decir es la responsabilidad de una persona o grupo. No se descompone en las subactividades.
Proceso(mostrado como un rectángulo 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 organización. Ejemplos de procesos son el análisis de requerimientos, el diseño arquitectónico, la planificación de prueba, etc.
Entregable(mostrado como un rectángulo con sombra)
Un entregable es una salida tangible de una actividad que es predecida en un plan del proyecto.
Condición(mostrada como un paralelogramo)
Una condición es una pre-condición que debe cumplirse antes de que un proceso o actividad pueda empezar o un post-condición que se cumple después de que un proceso o actividad ha terminado.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1334
Elementos del modelo de proceso 2
Rol(mostrada como un círculo con sombra)
Un rol es una área limitada de responsabilidad. Ejemplos de roles podrían ser gerente de configuración, ingeniero de prueba, diseñador de software, etc. Una persona puede tener varios roles diferentes y un solo rol puede estar asociado con varias personas diferentes.
Excepción(no mostrado en los ejemplos aquí pero puede representarse como una caja afilada doble)
Una excepción es una descripción de cómo 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 excepción.
Comunicación(mostrada como una flecha)
Un intercambio de información entre las personas o entre las personas y los sistemas de computadora de soporte. Las comunicaciones pueden ser informales o formales. Las comunicaciones formales podrían ser la aprobación de un entregable por un gerente del proyecto; las comunicaciones informales podrían ser el intercambio de correo electrónico para resolverse las ambigüedades en un documento.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1335
El módulo de actividad de prueba
El módulo compila sin errores de
sintaxis
El módulo compila sin errores de
sintaxis
Especificación del módulo
Especificación del módulo
Prueba de módulo
Prueba de módulo
Ingeniero de
prueba
Ingeniero de
pruebaTodas las
pruebas definidas ejecutan en el
módulo
Todas las pruebas definidas
ejecutan en el módulo
Datos de prueba del módulo
Datos de prueba del módulo
Firmado fuera del registro de prueba
Firmado fuera del registro de prueba
Pre-condición
Post-condición
Rol
Entrada
Salidas
Proceso
Responsable de
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1336
Actividades en la prueba de módulo
PREPARACION DE DATOS DE PRUEBA
PREPARACION DE LAS PARTES DE PRUEBA DE MODULO
EJECUCION DE PRUEBA
INFORME DE PRUEBA
Leer especificación
del módulo
Preparar datos de prueba de acuerdo a la especificación
Someter datos de prueba a
revisión
Revisar datos de prueba
Comprobar el módulo del sistema
de gestión de configuración
Leer y comprender la
interfaz del módulo
Preparar partes de prueba para el
módulo
Compilar las partes de
prueba
Incorporar módulo con sus partes de
prueba
Ejecutar las pruebas
aprobadas del módulos
Registrar los resultados de pruebas
para pruebas de regresión
Escribir informe de pruebas de módulo incluyendo
detalles de descubrimiento de problemas
Someter informe a aprobación
Someter resultados de prueba a CM
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1337
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 revisión crítica; Una brecha en la seguridad contra delitos puede significar
que todas las comunicaciones externas están fuera de acción por varios días;
Reorganización organizacional; Una necesidad de responder a una demanda no
anticipada para nuevos propuestas. Bajo estas circunstancias el módulo es suspendido y los
gerentes usan su iniciativa para tratar con la excepción.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1338
Cambios del proceso Involucra hacer modificaciones al proceso
existente. Esto puede involucrar:
Introducción de nuevas prácticas, métodos o procesos;
Cambiar el ordenamiento de las actividades del proceso;
Introducción o remoción de entregables; Introducción de nuevos roles o
responsabilidades. El cambio debe ser manejado por las metas de
medida.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1339
El proceso de cambio del proceso
Identificar mejoras
Priorizar mejoras
Introducir cambios de
proceso
Entrenar ingenieros
Afinar cambios de
proceso
Modelo del proceso
Plan de cambio del
proceso
Plan de entrenamiento
Retroalimentación en mejoras
Modelo del proceso revisado
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1340
Fases del cambio de proceso
Identificación de mejora.Priorización de mejora.Introducción de cambio de proceso.Entrenamiento de cambio de
proceso.Afinamiento del cambio
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1341
La armazón de CMMI La armazón de CMMI es la fase actual de trabajo en
la valoración del proceso y mejora que empezó el Instituto de Ingeniería de Software en los años ochenta.
La misión del SEI es promover la transferencia de tecnología 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 armazón de madurez revisada (CMMI)
introducida en 2001.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1342
Valoración de la capacidad del proceso
Pensado como un medio para evaluar hasta que pinto los procesos de una organización siguen la mejor práctica.
Proporcionando un medio para la valoración, 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1343
Inicial Esencialmente incontrolado
Repetible Procedimientos de gestión del producto definidos y
usados Definido
Procedimientos de gestión del proceso y estrategias definidas y usadas
Manejado Estrategias ge gestión de calidad definidas y usadas
Optimizado Estrategias de mejora del proceso definidas y usadas
El modelo de madurez de capacidad del SEI
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1344
Problemas con el CMM Prácticas asociadas con los niveles del modelos
Las compañías podrían estar usando prácticas de diferentes niveles al mismo tiempo, pero si no se usaron todas las prácticas del nivel más bajo no es posibles ir más allá de ese nivel.
Discreto en lugar de continuo No reconoce distinciones entre el tope y el fondo de los
niveles Orientada a la práctica
Comprometido en cómo se hicieron las cosas (las prácticas) en lugar de que las metas sean logradas.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1345
El modelo CMMI Un modelo de capacidad integrado que incluye el
software y valoración de la capacidad de ingeniería de sistemas.
El modelo tiene dos instanciaciones Puesto en escena donde el modelo es
expresado en términos de niveles de capacidad;
Continuo donde la tasa de capacidad se calcula.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1346
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 organización. Cada área de proceso tiene metas asociada.
Prácticas Las prácticas son maneras de alcanzar una meta – sin
embargo ellos son asesores y otras aproximaciones para alcanzar las metas pueden ser usadas.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1347
Áreas de procesos CMMI 1Gestión de procesos Definición de procesos organizacionales
Enfoque de procesos organizacionalesEntrenamiento organizacionalDesempeño de proceso organizacionalInnovación y despliegue organizacional
Gestión de proyectos Planificación del proyectoMonitoreo y control del proyectoGestión de acuerdo al proveedorGestión del proyecto integradoGestión de riesgosEnganchamiento integradoGestión del proyecto cuantitativo
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1348
Áreas de procesos CMMI 2Ingeniería Gestión de requerimientos
Desarrollo de requerimientosSolución técnicaIntegración del productoVerificaciónValidación
Soporte Gestión de configuraciónGestión de calidad del proceso y el productoMedida y análisisAnálisis de decisión y resoluciónAmbiente organizacional para integraciónAnálisis causal y resolución
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1349
Metas de CMMI Meta Área de proceso
Las acciones correctivas son manejadas para el cierre cuando la actuación del proyecto o los resultados se desvían significativamente del plan.
Meta específica en el Proyecto.
Monitoreo y Control.
El desempeño real y el progreso del proyecto es supervisado contra el plan del proyecto.
La meta específica en proyecto que supervisa y controla.
Los requerimientos son analizados y validados y una definición de la funcionalidad requerida se desarrolla.
La meta específica en el desarrollo de requerimientos.
Las causas de la raíz de los defectos y otros problemas son sistemáticamente determinadas.
La meta específica en el análisis causal y resolución.
El proceso se institucionaliza como un proceso definido.
Meta genérica.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1350
Prácticas CMMI Práctica Meta asociada
Analizar los requerimientos derivados para asegurar que ellos son necesarios y suficientes
Los requerimientos son analizados y validados y una definición de la funcionalidad requerida es desarrollada.
Validar los requerimientos para asegurar que el producto resultante se desempeñará tal como se intentó en el ambiente del usuario usando múltiples técnicas que sean apropiadas.
Seleccionar los defectos y otros problemas para el análisis. Las causas de raíz de los defectos y otros problemas son sistemáticamente determinadas.
Realizar análisis causal de defectos seleccionados y otros problemas y proponer las acciones a realizar.
Establecer y mantener una política organizacional para planificar y realizar el proceso de desarrollo de requerimientos.
El proceso se institucionaliza como un proceso definido.
Asignar responsabilidad y autoridad por realizar el proceso, desarrollando los productos de trabajo y proporcionando los servicios del proceso de desarrollo de requerimientos.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1351
Valoración del CMMI Examinar los procesos usados en la organización
y evaluar su madurez en cada área del proceso. Basado en una escala de 6 puntos;
No realizado; Realizado; Definido; Cuantitativamente manejado; Optimizado.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1352
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: Gestión de requerimientos; Planificación de proyectos; Monitoreo del proyecto y control; La gestión de acuerdo al proveedor; Medida y análisis; Certidumbre de calidad del proceso y el producto.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1353
El modelo CMMI organizado
Nivel 1 Inicial
Nivel 2 Manejado
Nivel 3 Definido
Nivel 4 Cuantitativamente
manejado
Nivel 5 Optimizado
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1354
Prácticas institucionales Instituciones que operan al nivel manejado deben de
haber institucionalizado prácticas que se engranan para la estandarización. Establecer y mantener políticas para realizar el
proceso de gestión del proyecto; Proveer recursos adecuados para realizar el
proceso de gestión del proyecto; Monitorear y controlar el proceso de planificación
del proyecto; Revisar las actividades, estados y resultados del
proceso de planificación del proyecto.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1355
El modelo CMMI continuo Este es un modelo de grano fino que considera
individuos o grupos de prácticas y evalúan su uso. La valoración de madurez no es sólo 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1356
Un perfil de capacidad del proceso
0 1 2 3 4 5
Monitoreo y control del proyecto
Gestión de acuerdo a los proveedores
Gestión de riesgo
Gestión de configuración
Gestión de requerimientos
Verificación
Validación
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1357
La mejora del proceso involucra análisis del proceso, estandarización, medida y cambio.
Los procesos pueden ser clasificados como informal, manejado, metódico y mejorado. Esta clasificación puede usarse para identificar el apoyo de herramienta de proceso.
El ciclo de mejora de proceso involucra medida del proceso, análisis del proceso y cambio del proceso.
La medida del proceso debe ser usado para contestar las preguntas específicas del proceso , basado en las metas de mejora organizacional.
Puntos clave
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1358
Los tres tipos de métricas del proceso usadas en el proceso son métricas del tiempo, métricas de utilización de recursos y métricas de evento.
Los modelos de proceso incluyen descripción de tareas, actividades, roles, excepciones, comunicaciones, entregables y otros procesos.
El modelo de madurez del proceso CMMI integra software y mejora del proceso de ingeniería de sistemas.
La mejora del proceso en el modelo CMMI está basado en alcanzar un conjunto de metas relacionados para una buena practica de ingeniería de sistemas.
Puntos clave
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1359
Gestión de configuración
Capítulo 28
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1360
Objetivos Explicar la importancia de la gestión de
configuración del software (CM) Describir las actividades clave de CM a saber
planificación CM, gestión de cambio, gestión de versión y construcción del sistema
Discutir el uso de herramientas CASE para dar soporte a los procesos de gestión de configuración
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1361
Tópicos cubiertosPlanificación de gestión de
configuraciónGestión de cambioGestión de versión y lanzamientoConstrucción del sistemaHerramientas CASE para gestión de
configuración
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1362
Nuevas versiones de sistemas de software son creados cuando ellos cambian: Para diferentes máquinas/SO; Ofreciendo diferentes funcionalidades; Adecuando para requerimientos de usuario particulares.
La gestión de configuración se preocupa por manejar la evolución 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.
Gestión de configuración
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1363
Gestión de configuración Involucra el desarrollo y aplicación de
procedimientos y estándares para manejar y evolucionar un producto de software.
CM puede ser visto como parte un proceso más general de gestión de calidad.
Cuando es lanzado para CM, los sistemas de software son a veces llamadas líneas de base puesto que ellos son un punto de partida para el desarrollo extenso.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1364
Familias de sistemas
Sistema inicial
Sistema inicial
Versión HP
Versión HP
Versión PC
Versión PC
Versión Sun
Versión Sun
Versión Windows XP
Versión Windows XP
Versión LinuxVersión Linux
Versión PC
Versión PC
Versión Servidor
Versión Servidor
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1365
Estándares CM CM siempre debe estar basado en un conjunto de
estándares que son aplicados dentro de una organización.
Los estándares deben definir cómo se identifican los artículos y cómo son controlados los cambios y con son manejadas las nuevas versiones.
Los estándares pueden estar basados en estándares externos de CM (Por ejemplo, estándares IEEE para CM).
Algunos estándares existentes están basados en un modelo de proceso de cascada – los nuevos estándares CM son necesitados para el desarrollo evolutivo.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1366
Desarrollo concurrente y prueba
Una hora (digamos 2pm) para la entrega de componentes del sistema es convenida.
Una nueva versión de un sistema es construida a partir de esos componentes por compilación y ligándolos a él.
Esta nueva versión 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1367
Construcción de un sistema frecuente
Es más fácil encontrar problemas que provienen de las interacciones de componente tempranas en el proceso.
Esto alienta una prueba de unidad completa – los desarrolladores no están bajo presión de “romper la estructura”’.
Un proceso de gestión de cambio rígido es requerido para guardar las huellas de los problemas que han sido descubiertos y reparados.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1368
Todos los productos de un proceso de software pueden tener que ser manejados: Especificaciones; Diseños; Programas; Datos de prueba; Manuales de usuario.
Miles de documentos separados pueden ser generados para un grande y complejo sistema de software.
Planificación de la gestión de configuración
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1369
Definir los tipos de documentos para ser manejados y y un esquema de denominación del documento.
Definir quién toma la responsabilidad para los procedimientos CM y la creación de líneas de base.
Definir las políticas para el control de cambio y gestión de versión.
Definir los registros de CM que deben ser mantenidos.
El plan CM
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1370
El plan CM Describir las herramientas que deben ser usadas
para asistir los procesos de CM y cualquier limitación en su uso.
Definir el proceso de uso de la herramienta. Definir la base de datos de CM usada para
registro de la información de la configuración. Puede incluir información tal como el CM de
software externo, procesos de auditoría, etc.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1371
Los grandes proyectos típicamente 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 denominación de documento debe ser definido de modo que los documentos relacionados tengan nombres relacionados.
Un esquema jerárquico con los nombres multi-nivel es probablemente la aproximación más flexible PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE
Identificación del artículo de configuración
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1372
Jerarquía de configuraciónPCL TOOLS
COMPILE BIND EDIT MAKEGEN
FORM STRUCTURE HELP
DISPLAY QUERY
FORM - SPECS AST - INTERFACE FORM - IO
OBJECTS CODE TESTS
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1373
Toda la información de CM debe ser mantenida en una base de datos de la configuración.
Esto debe permitir consultas acerca de la configuración a ser respondidas: ¿Qué tiene una particular versión del sistema? ¿Qué plataforma es requerida para una particular versión? ¿Qué versiones serán afectadas por un cambio al
componente X? ¿Cuántas fallas informadas en la versión T?
La base de datos de CM debe ser ligada preferentemente al software a ser manejado.
La base de datos de la configuración
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1374
Implementación 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 relación entre las herramientas CASE y las herramientas CM.
Más normalmente, la base de datos de CM es mantenida separadamente puesto que esto es más barato y más flexible.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1375
Sistemas de software están sujetos a las demandas de cambio continuas: De los usuarios; De los desarrolladores; De las fuerzas del mercado.
La gestión de cambio se preocupa por guardar huellas de esos cambios y asegurar que ellos se llevan a cabo de la manera más rentable.
Gestión del cambio
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1376
El proceso de gestión del cambio
Pedir cambio completando una forma de demanda de cambio
Analizar demanda de cambio
si el cambio es válido entonces
Evaluar cómo el cambio podría 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 aprobación de calidad
hasta que la calidad del software sea adecuada
crear la nueva versión del sistema
si no
rechazar la demanda de cambio
si no
rechazar la demanda de cambio
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1377
La definición de una forma de demanda de cambio es parte del proceso de planificación de CM.
Esta forma registra el cambio propuesto, el demandador de cambio, la razón de por qué el cambio fue sugerido y la urgencia del cambio (desde el demandador del cambio).
También registra la evaluación del cambio, el análisis del impacto, costo del cambio y recomendaciones (personal de mantenimiento del cambio).
Formulario de demanda de cambio
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1378
Formulario de demanda de cambio
Formulario de demanda del cambio
Proyecto: Proteus /PCL-Tools Número: 23/02Demandador de cambio: I. Somerville Fecha: 01/12/06Demanda 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 análisis: 10/12/06 Componentes afectados: Display-Icon-Select, Display-Icon-Display Componente asociado: Tabla Archivo Valoración del cambio: Relativamente simple de implementar puesto que una tabal de nombre archivo esta disponible. Requiere el diseño e implementación de un campo de despliegue. No son requeridos cambios para asociar componentes.Prioridad del cambio: Bajo Implementación del cambio:Esfuerzo estimado: 0.5 días,Fecha para CCB: 15/02/02 Fecha de demanda de CCB: 01/02/03 Implementador del cambio: Fecha de cambio:Fecha sometida a QA: Decisión QA:Fecha sometida a CM:Comentarios
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1379
Un problema mayor en la gestión del cambio es el estado de rastreo de cambio.
Las herramientas de rastreo de cambio guardan el estado de cada demanda de cambio y automáticamente asegura que esas demandas de cambio son enviadas a las personas correctas en el momento correcto.
Integrado con los sistemas de correo electrónico que permiten la distribución de demanda de cambio electrónica.
Herramientas de rastreo de cambio
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1380
Los cambios deben ser revisados por un grupo externo que decide si ellos son o no rentables desde un punto de vista estratégico y organizacional en lugar de un punto de vista técnica.
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.
Tablero de control de cambio
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1381
Este es un registro de los cambios aplicados a un documento o un componente de código.
Debe registrar, en el contorno, el cambio hecho, la razón del cambio, quién hizo el cambio y cuando fue implementado.
Puede ser incluido como un comentario en el código. Si un estilo de prólogo estándar es usado para la historia de la derivación, las herramientas pueden procesar esto automáticamente.
Historia de la derivación
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1382
La información del título del componente
/ / Proyecto BANKSEC (IST 6087)
/ /
/ / BANKSEC-TOOLS/AUTH/RBAC/USER_ROLE
/ /
/ /Objeto: el currentRole
/ / Autor: N. PERWAIZ
/ / Fecha de creación: 10 de noviembre del 2002
/ /
/ / © Universidad de Lancaster 2002
/ /
/ /Historia de la modificación
/ / Versión Modificador Fecha Cambio Razón
/ / 1.0 J. Jones 1/12/2002 Agrega título Sometido al CM
/ / 1.1 N. Perwaiz 9/4/2003 Nuevo campo Req. de Cambio R07/02
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1383
Inventar un esquema de identificación para versiones del sistema.
Planear cuando una nueva versión del sistema será producida.
Asegurar que los procedimientos de gestión de versión y herramientas serán propiamente aplicadas.
Planear y distribuir lanzamientos de un nuevo sistema.
Versión y gestión de lanzamiento
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1384
Versión Una instancia de un sistema que es funcionalmente distinta de alguna manera de otras instancias del sistema.
Variante Una instancia de un sistema que es funcionalmente idéntica pero funcionalmente no distinta de otras instancias del sistema.
Lanzamiento Una instancia del sistema que es distribuida a usuarios fuera del equipo de desarrollo.
Versiones/variantes/
lanzamientos
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1385
Identificación de la versión Los procedimientos para identificación de la
versión deben definir una manera no ambigua de identificar versiones de componentes.
Hay 3 técnicas básicas ara la identificación de componentes Enumeración de la versión; Identificación basada en atributos; Identificación orientada al cambio.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1386
El esquema de denominación simple usa una derivación lineal V1, V1.1, V1.2, V2.1, V2.2 etc.
La actual estructura de derivación es un árbol o una red en lugar de una secuencia.
Los nombres no son significativos. Un esquema de denominación jerárquica
lleva a menos errores en la identificación de la versión.
Enumeración de la versión
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1387
Estructura de derivación de la versión
V 1.0V 1.0 V 1.1V 1.1
V 1.1aV 1.1a
V 1.1bV 1.1b V 1.1.1V 1.1.1
V 1.2V 1.2 V 2.0V 2.0 V 2.1V 2.1 V 2.2V 2.2
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1388
Los atributos pueden ser asociadas con una versión con la combinación de atributos que identifican esa versión Ejemplos de atributos son Fecha, Creador,
Lenguaje de Programación, Cliente, Estado, etc. Esto es más flexible que un esquema de denominación
explícita para la recuperación de la versión; 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 práctica una versión también necesita un nombre asociado para la referencia fácil.
Identificación basada en atributo
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1389
Consultas basadas en atributo
Una importante ventaja de la identificación basada en atributo es que puede soportar consultas de modo que se puede encontrar “ la más reciente versión en Java” etc.
La consulta selecciona una versión dependiente de valores de atributos AC3D (lenguaje =Java, plataforma = XP,
fecha = Enero 2003).
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1390
Identificación 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 versión de un sistema que incorpora un conjunto arbitrario de cambios pueda ser creada.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1391
Los lanzamientos deben incorporar cambios forzados en el sistema por errores descubiertos por usuarios y por cambios de hardware.
Ellos también deben incorporar la nueva funcionalidad del sistema.
La planificación del lanzamiento está interesada con cuándo emitir una versión del sistema como un lanzamiento
Gestión de lanzamiento
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1392
Lanzamiento del sistema No sólo un conjunto de programas ejecutables. Puede también incluir:
Los archivos de configuración definen cómo el lanzamiento es configurado para una instalación particular;
Los archivos de datos necesarios para una operación del sistema;
Un programa de instalación o un guión de apariencia para instalar el sistema en el hardware de destino;
Documentación electrónica y en papel; Publicidad empaquetada y asociada.
Los sistemas son ahora normalmente lanzados en discos ópticos (CD o DVD) o como archivos de instalación descargables desde la Web.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1393
El cliente puede no querer una nueva versión del sistema Ellos pueden estar contentos con su actual
sistema de modo que la nueva versión puede proporcionar una funcionalidad no deseada.
La gestión 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.
Problemas de lanzamiento
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1394
Hacer la decisión de lanzamiento
La preparación y la distribución un lanzamiento del sistema es un proceso expansivo.
Los factores como la calidad técnica del sistema, competencia, requerimientos de comercialización, y demandas de cambio del usuario tienen todos influencia en la decisión de cuando emitir un nuevo lanzamiento del sistema.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1395
Estrategia de lanzamiento de sistema
Factor Descripción
Calidad técnica del sistema
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 reparación 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 versión de una aplicación del software cuando una nueva versión de la plataforma del sistema operativo es lanzada.
La quinta ley de Lehman (ver Capítulo 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 reparación.
Competencia Un nuevo lanzamiento del sistema puede ser necesario porque un producto de la competencia está disponible.
Requerimientos de comercialización
La sección de comercialización de una organización 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 específico de propuestas de cambio del sistema y ellos esperan un lanzamiento del sistema en cuanto éstos se hayan implementado.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1396
Creación del lanzamiento
La creación del lanzamiento involucra un colectivo de todos los archivos y documentos requeridos para crear un lanzamiento del sistema.
Las descripciones de configuración tiene que ser escritas para diferente hardware y las guías de instalación tiene que ser escritas.
El lanzamiento específico debe ser documentado para registrar exactamente que archivos serán usados para crearlo Esto le permite ser recreado si es necesario.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1397
El proceso de compilación 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 construcción”.
Construcción del sistema
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1398
¿Las instrucciones de construcción incluyen todos los componentes requeridos? Cuando hay muchos cientos de componentes que constituyen
un sistema, es fácil de encontrar uno afuera. Esto normalmente debe ser detectado por el enlazador.
¿Es la versión de componente apropiada especificada? Un problema más significativa. Un sistema construido con una
mala versión puede trabajar inicialmente pero falla antes de la entrega.
¿Están todos los archivos de datos disponibles? La estructuran debe confiar en archivos de datos “estándar” .
Los estándares varían de lugar a lugar.
Problemas de construcción del sistema
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1399
¿Son los archivos de datos las referencias dentro de los componentes correctos? Los nombres absolutos empotrados en el código casi siempre
causan problemas como las convenciones de denominación que difieren de lugar a lugar.
¿Está construyéndose el sistema para la plataforma correcta? A veces se debe construir para una versión de SO específico o
una configuración de hardware. ¿Están la versión correcta del compilador y otras herramientas de
software especificadas? Diferentes versiones de compilador pueden generar ahora
diferente código y los componentes compilados exhibirán diferente comportamiento.
Problemas de construcción del sistema
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1400
Construcción del sistema
Constructor del sistema
Constructor del sistema
Sistema de gestión de
versión
Sistema de gestión de
versión
Compiladores Compiladores Enlazador Enlazador
Construir guión
Construir guión
Versiones de componente de código fuente
Versiones de componente de código fuente
Componentes de código
fuente
Componentes de código
fuente
Código ejecutable Código
ejecutable
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1401
Herramientas CASE para la gestión de configuración
Los procesos CM son estandarizados e involucran la aplicación 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 gestión de configuración están disponibles fluctuando desde herramientas autosuficientes hasta bancos de trabajo CM integradas.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1402
Bancos de trabajo CM Bancos de trabajo abiertos
Las herramientas de cada estado en el proceso CM son integradas a través de procedimientos organizacionales y guiones. Dan la flexibilidad en la selección de herramientas.
Bancos de trabajo integrados Proporcionan procesos enteros, soporte
integrado para gestión de configuración. Más herramientas herméticamente integradas fáciles de usar. Sin embargo, el costo es menos flexible en las herramientas usadas.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1403
Herramientas de gestión de cambio
La gestión de cambio es un proceso procedural de modo que puede ser modelado e integrado con un sistema de gestión de versión.
Herramientas de gestión de cambio Editor de formulario para apoyar procesando los
formularios de demanda de cambios; Sistema de flujo de trabajo para definir quién hace qué y
para automatizar la transferencia de información; 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
gestión en los estados de demanda de cambio.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1404
Herramientas de gestión de versión
Identificación de versión y lanzamiento Los sistemas asignan identificadores automáticamente cuando una
nueva versión es sometida al sistema. Gestión de almacenamiento
El sistema guarda las diferencias entre versiones en lugar de todo el código de la versión.
Registro de historia de cambio Registra las razones para la creación de versión.
Desarrollo independiente Sólo una versión 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.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1405
Versiones basadas en delta
Versión 1.0
Versión 1.0
Versión 1.1
Versión 1.1
Versión 1.2
Versión 1.2
Versión 1.3
Versión 1.3
D 1 D 1 D 2D 2 D 3D 3
Datos de creación
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1406
Construcción del sistema La construcción 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 especificación de dependencia e
interprete; Selección de herramienta y apoyo de instanciación; Compilación distribuida; Gestión de objetos derivada.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1407
Dependencia de componentes
compcomp
scan.0scan.0 syn.0syn.0 sem.0sem.0 cgen.0cgen.0
scan.0scan.0 syn.0syn.0 sem.0sem.0 cgen.0cgen.0
defs.hdefs.h
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1408
Puntos clave La gestión de configuración es la gestión de cambios
del sistema para productos del software. Un esquema de denominación de documento formal
debe ser establecida y los documentos deben ser manejados en una base de datos.
La base de datos de configuración debe registrar la información acerca de los cambios y demandas de cambios.
Un esquema consistente de identificación de versión debe ser establecida usando números, atributos o conjuntos de cambios .
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1409
Puntos clave Los lanzamientos del sistema incluyen código
ejecutable, datos, archivos de configuración y documentación.
La construcción del sistema involucra componentes ensamblados dentro del sistema ..
Las herramientas CASE están disponibles para apoyar todas las actividades CM
Las herramientas CASE pueden ser herramientas autosuficientes o pueden ser sistemas integrados que integran apoyo para la gestión de versión, construcción del sistema y gestión de cambios.
13/04/23 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 1410