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