• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ingenieria software
 

Ingenieria software

on

  • 619 views

 

Statistics

Views

Total Views
619
Views on SlideShare
618
Embed Views
1

Actions

Likes
0
Downloads
37
Comments
0

1 Embed 1

http://localhost 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 7 <br />

Ingenieria software Ingenieria software Presentation Transcript

  • Una introducción a la Ingeniería del software Ian Sommerville Traducción: Ing.
  • Capítulo 1 Introducción 10/01/14 Ing. 2
  • 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. 10/01/14 Ing. 3
  • Temas cubiertos FAQs sobre la ingeniería del software. El profesional y la responsabilidad ética. 10/01/14 Ing. 4
  • 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.  10/01/14 Ing. 5
  • 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. 10/01/14 Ing. 6
  • 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? 10/01/14 Ing. 7
  • 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? 10/01/14 8
  • ¿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. 10/01/14 9
  • ¿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. 10/01/14 10
  • ¿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). 10/01/14 11
  • ¿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.  10/01/14 12
  • ¿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. 10/01/14 13
  • ¿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. 10/01/14 14
  • ¿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.  10/01/14 15
  • Distribución de costos de actividad Modelo de cascada 0 100 25 Especificación 50 Diseño Desarrollo 75 Integración y pruebas Desarrollo iterativo 0 100 25 Especificación 50 Desarrollo iterativo 75 Prueba del sistema Ingeniería de software basada en componentes 0 100 25 Especificación 50 Desarrollo 75 Integración y pruebas Desarrollo y evolución de costos de largo tiempo de vida 0 400 100 Desarrollo del sistema 10/01/14 200 300 Evolución del sistema Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 16
  • Costos de desarrollo del producto 0 25 Especificación 10/01/14 50 Desarrollo 75 100 Prueba del sistema 17
  • ¿Cuáles son los métodos de la ingeniería de software? del Los acercamientos estructurados al desarrollo      10/01/14 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. 18
  • ¿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  10/01/14 de Bajo Nivel Herramientas para apoyar las actividades tardías tales como programación, depuración y pruebas. 19
  • ¿Cuáles son los atributos de un buen software?      10/01/14 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. 20
  • ¿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.  10/01/14 21
  • 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. 10/01/14 22
  • Los problemas de responsabilidad profesional  Confidencialidad Los ingenieros normalmente deben respetar la confidencialidad de sus empleadores o clientes independiente de que haya o no un acuerdo formal de confidencialidad que se haya firmado.  Competencia  Los ingenieros no deben falsear su nivel de competencia. No deben aceptar trabajos que a sabiendas están fuera de su competencia.  10/01/14 23
  • Los problemas de responsabilidad profesional   Leyes de propiedad intelectual  Los ingenieros deben ser conscientes de las leyes de gobierno locales que legislan sobre el uso de propiedad intelectual como las patentes, registros la propiedad de autor, etc. Ellos deben tener el cuidado de asegurar que la propiedad intelectual de empleadores y clientes está protegido. Mal uso de la computadora  Los ingenieros del software no deben usar sus habilidades 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). 10/01/14 24
  • 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. 10/01/14 25
  • 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: 10/01/14 26
  • 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.  10/01/14 27
  • Código de ética - principios    10/01/14 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. 28
  • 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. 10/01/14 29
  • 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. 10/01/14 30
  • 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. 10/01/14 31
  • 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. 10/01/14 32
  • Capítulo 2 Los Sistemas Socio-técnicos 10/01/14 33
  • Objetivos      10/01/14 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. 34
  • Tópicos cubiertos Las propiedades del sistema emergentes La ingeniería de sistemas Las organizaciones, las personas y sistemas de computadora Los sistemas legados 10/01/14 35
  • ¿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  10/01/14 36
  • Categorías de sistemas   10/01/14 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. 37
  • Características de los sistemas Socio-técnicos    10/01/14 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. 38
  • Propiedades emergentes Las propiedades del sistema en conjunto en lugar de propiedades que pueden derivarse de las propiedades de componentes de un sistema.  Las propiedades emergentes son una consecuencia de las interrelaciones entre los componentes del sistema.  Ellos pueden por consiguiente solamente ser evaluados y medidos una vez que los componentes se han integrado en un sistema.  10/01/14 39
  • Ejemplos de propiedades emergentes Propiedades Descripción Volumen 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. 10/01/14 40
  • Tipos de propiedades emergentes  Propiedades funcionales   10/01/14 É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. 41
  • Ingeniería de fiabilidad de sistemas 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.  10/01/14 42
  • Influencias en fiabililidad    10/01/14 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? 43
  • 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. 10/01/14 44
  • 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. 10/01/14 45
  • Ingeniería de sistemas  Especificando, 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. 10/01/14 46
  • 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 diferentes que deben trabajar juntos  10/01/14 de 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. 47
  • Los procesos de la ingeniería de sistemas Definición de Definición de requerimientos requerimientos Retiro del Retiro del sistema sistema Diseño del Diseño del sistema sistema Evolución del Evolución del sistema sistema Desarrollo del Desarrollo del sub - -sistema sub sistema Instalación del Instalación del sistema sistema Integración del Integración del sistema sistema 10/01/14 48
  • Envolvimiento interdisciplinario Ingeniería de Ingeniería de software software Ingeniería Ingeniería estructural estructural Ingeniería Ingeniería civil civil 10/01/14 Ingeniería Ingeniería electrónica electrónica Ingeniería de Ingeniería de sistemas ATC sistemas ATC Ingeniería Ingeniería eléctrica eléctrica Ingeniería Ingeniería mecánica mecánica Diseño de interfaz de Diseño de interfaz de usuario usuario Arquitectura Arquitectura 49
  • 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. 10/01/14 50
  • 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. 10/01/14  51
  • 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.  10/01/14 52
  • El proceso de diseño del sistema      10/01/14 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. 53
  • El proceso de diseño del sistema Definir Definir interfaces de interfaces de sub - -sistemas sub sistemas Requerimientos Requerimientos de partición de partición Identificar sub –– Identificar sub sistemas sistemas Especificar Especificar funcionalidad aa funcionalidad sub - -sistemas sub sistemas Asignación de Asignación de requerimientos requerimientos aasub - -sistemas sub sistemas 10/01/14 54
  • 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. 10/01/14 55
  • 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.  10/01/14 56
  • Modelo en espiral de requerimientos /diseño Requerimientos, Requerimientos, Elicitación yy Elicitación Análisis Análisis Definición del Definición del Problema Problema 10/01/14 Diseño Diseño Arquitectónico Arquitectónico Revisión yy Revisión Valoración Valoración 57
  • Modelamiento del sistema  Un 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. 10/01/14 58
  • El sistema de alarma de ladrón Sensores de Sensores de movimiento movimiento Sensores de Sensores de puerta puerta Controlador de Controlador de alarma alarma Sirena Sirena 10/01/14 Sintetizador Sintetizador de voz de voz Centro de control externo Llamador de Llamador de teléfono teléfono 59
  • Descripción de sub - sistema Sub - sistema Descripción Sensores de movimiento Sensores de puerta Control de alarma Sirena Detecta el movimiento en las salas monitoreadas por el sistema. Detecta puertas que abre en las puertas externas de la construcción. Controla la operación del sistema. Emite una advertencia auditiva cuando un intruso es sospechoso. Sintetizador de Sintetiza un mensaje de voz que da ubicación del voz intruso sospechoso. Llamador de Hace llamadas para notificar a la seguridad, a la teléfono policía, etc. 10/01/14 60
  • Arquitectura de sistemas ATC Sistema de radar Sistema de radar Procesador de Procesador de posición posición Sistema de simulación Sistema de simulación de vuelo de vuelo Sistema de Sistema de transponder transponder Sistema de comandos de Sistema de comandos de datos datos Procesador de posición de Procesador de posición de resguardo resguardo C comandos de vuelo C comandos de vuelo Procesador de Procesador de comandos comandos Sistema de teléfono Sistema de teléfono Procesador de Procesador de comandos de comandos de resguardo resguardo Base de datos del Base de datos del plan de vuelo plan de vuelo Sistema de mapa Sistema de mapa metereólogico metereólogico Consolas de control Consolas de control Sistema de conteo Sistema de conteo 10/01/14 Sistema de control de Sistema de control de información información Sistema de mallas de Sistema de mallas de actividad actividad 61
  • 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.  10/01/14 62
  • Integración del sistema  El proceso de colocar hardware, software y personas juntos para hacer un sistema.  Debe ser incrementalmente abordado de modo que los subsistemas son integrados al mismo tiempo.  Los problemas de interfaz entre sub – sistemas se encuentran normalmente en esta fase.  Pueden haber problemas con entregas no coordinadas de componentes del sistema. 10/01/14 63
  • Instalación del sistema  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.  10/01/14 problemas de cableado); El operador de entrenamiento tiene que ser identificado. 64
  • Evolución del sistema    10/01/14 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. 65
  • 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. 10/01/14 66
  • 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. 10/01/14 67
  • Factores humanos y organizacionales Los cambios del proceso  ¿El sistema requiere los cambios a los procesos de trabajo en el ambiente?  Los cambios del trabajo  ¿Hace el sistema 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?  10/01/14 68
  • Procesos Organizacionales    10/01/14 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. Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 69
  • Procesos de obtención /desarrollo Proceso de Proceso de Obtención Obtención Proceso de Proceso de Desarrollo Desarrollo Proceso Proceso Operacional Operacional 10/01/14 70
  • Obtención del sistema    10/01/14 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. 71
  • El proceso de obtención de sistema Sistema de disponibilidad en stock Adaptar Adaptar requerimientos requerimientos Elegir Elegir sistema sistema Publicar Publicar demanda para la demanda para la oferta oferta Elegir Elegir proveedor proveedor Estudio de mercado Estudio de mercado de sistemas existentes de sistemas existentes Publicar demanda Publicar demanda para vigilante para vigilante Elegir Elegir vigilante vigilante Negociar el Negociar el contrato contrato Permitir contrato Permitir contrato para el desarrollo para el desarrollo Lo requerido por el sistema habitual 10/01/14 72
  • 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. 10/01/14 73
  • 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. 10/01/14 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 74
  • Modelos de Contratista/Subcontratista Sistema del Sistema del Cliente Cliente Contratista Contratista Principal Principal Sub Sub Contratista 11 Contratista 10/01/14 Sub Sub Contratista 2 Contratista 2 Sub Sub Contratista 3 Contratista 3 75
  • 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. 10/01/14 76
  • Sistemas legados Usa Software de Software de soporte soporte Corre en Sistemas de Sistemas de hardware hardware 10/01/14 Software de Software de aplicación aplicación Corre en Usa Datos de Datos de aplicación aplicación Incluye conocimiento de Usa Políticas Políticas comerciales yy comerciales reglas reglas Restringe n Procesos de Procesos de negocios negocios 77
  • Componentes de sistemas legados       10/01/14 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. 78
  • Sistemas socio técnicos Sistemas socio-técnicos Procesos de negocios Software de aplicación Software de soporte Hardware 10/01/14 79
  • 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.  10/01/14 80
  • 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.  10/01/14 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 81
  • Capítulo 3 Sistemas críticos 10/01/14 82
  • 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. 10/01/14 83
  • Temas cubiertos Un sistema simple de seguridad crítica Confiabilidad de sistemas Disponibilidad y fiabilidad Safety (Seguridad física) Security (Seguridad contra delitos) 10/01/14 84
  • Sistemas críticos    10/01/14 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. 85
  • 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. 10/01/14 86
  • Importancia de la confiabilidad  Sistemas que no son confiables y son inestables, no garantizados o inseguros pueden ser rechazados por sus usuarios.  Los costos de falla del sistema pueden ser muy altos.  Los sistemas no confiables pueden causar la pérdida de información con un costo alto de la consecuente recuperación. 10/01/14 87
  • 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. 10/01/14 88
  • Sistemas socio - técnicos    10/01/14 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. 89
  • 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. 10/01/14 90
  • Organización de la bomba de insulina Depósito de insulina Montaje de aguja Bomba Reloj Sensor Controlador Alarma Visual 1 Visual 2 Suministro de fuerza 10/01/14 91
  • Flujo de datos de la bomba de insulina Sangre Sensor de azúcar Sensor de azúcar en la sangre en la sangre Parámetros de sangre Análisis de azúcar Análisis de azúcar en la sangre en la sangre Nivel de azúcar en la de sangre Cómputo de Cómputo de requerimientos de requerimientos de insulina insulina Insulina 10/01/14 Bomba de Bomba de insulina insulina Comandos de control de bomba Controlador de Controlador de entrega de insulina entrega de insulina Corregir insulina requerida 92
  • Requerimientos de confiabilidad  El sistema estará disponible para entregar insulina cuando sea requerido para hacer eso.  El sistema realizará la confiabilidad y entregará la cantidad correcta de insulina para neutralizar el nivel actual del 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. 10/01/14 93
  • Confiabilidad La confiabilidad de un sistema es equivalente a su fidelidad.  Un sistema fidedigno es un sistema confiable por sus usuarios.  Las principales dimensiones de confiabilidad son:  Disponibilidad;  Fiabilidad;  Seguridad física;  Seguridad contra delitos.  10/01/14 94
  • Dimensiones de confiabilidad Confiabilidad Confiabilidad Disponibilidad Disponibilidad Fiabilidad Fiabilidad La habilidad de un La habilidad de un sistema para entregar sistema para entregar servicios cuando son servicios especificados requeridos 10/01/14 Seguridad Seguridad física física Seguridad contra Seguridad contra delitos delitos La habilidad de un La habilidad de un sistema para operar sistema para proteger sin fallas intrusiones contra el catastróficas sistema accidentales o deliberadas 95
  • Otras propiedades de la confiabilidad Reparabilidad  Refleja hasta que punto el sistema puede ser reparado en caso de una falla.  Mantenabilidad  Refleja hasta que punto el sistema puede adaptarse a los nuevos requerimientos.  Supervivencialidad  Refleja hasta que punto el sistema puede entregar los servicios aun bajo ataque hostil.  Tolerancia de error  Refleja que hasta que punto el usuario ingresa errores que pueden evitarse y tolerarse.  10/01/14 96
  • 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.  10/01/14 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 97
  • Supervivencialidad  La habilidad de un sistema de continuar entregando sus servicios a los usuarios enfrentando el ataque deliberado o accidental.  Éste es un atributo de creciente importancia para sistemas distribuidos cuya seguridad puede comprometerse.  La supervivencialidad incluye la noción de elasticidad: la habilidad de un sistema para continuar en operación a pesar de las fallas de componentes. 10/01/14 98
  • 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.  10/01/14 99
  • Costos de confiabilidad Los costos de confiabilidad tienden a aumentar exponencialmente cuando los niveles crecientes de confiabilidad son requeridos.  Hay dos razones para esto:  El uso de mas 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.  10/01/14 100
  • Costos de confiabilidad creciente Costos Costos crecientes de confiablidad 600 500 400 300 200 100 0 Baja 10/01/14 Costos Media Alta Muy alta Ultra Confiabilidad alta 101
  • 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.  10/01/14 102
  • 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.  10/01/14 103
  • 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.  10/01/14 104
  • Terminología de fiabilidad Falla 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. 10/01/14 105
  • Errores y fallas    La fallas son normalmente un resultado de errores del sistema que se derivan de errores en el sistema. Sin embargo, las faltas no necesariamente resultan de los errores del sistema.  El estado defectuoso del sistema puede ser pasajero y ‘corregido' antes de surgir un error. Los errores no necesariamente llevan a fallas del sistema.  El error puede ser corregido por 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. 10/01/14 106
  • 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. 10/01/14 107
  • 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. 10/01/14 108
  • 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. 10/01/14 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. 10/01/14 110
  • Traza de entrada/salida Conjunto de entradas Entradas que causan salidas erróneas Ie Programa Programa Salidas erróneas Conjunto de salidas 10/01/14 Oe 111
  • Percepción de confiabilidad Posibles entradas Usuario 1 Usuario 1 Usuario Usuario 2 2 10/01/14 Usuario Usuario 3 3 Entradas erróneas 112
  • La mejora de confiabilidad    Quitando X% de las faltas en un sistema no necesariamente mejorará la fiabilidad por X%. Un estudio a IBM mostró que quitando 60% de defectos del producto se produce un 3% de mejora en la fiabilidad. Los defectos del programa pueden estar en las secciones raramente ejecutadas del 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. 10/01/14 113
  • 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. 10/01/14 114
  • Criticalidad de la seguridad física    10/01/14 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. 115
  • Seguridad física y fiabilidad  La seguridad física y fiabilidad relacionadas pero son distintas  están 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. 10/01/14 116
  • Los sistemas fiables no seguros físicamente    10/01/14 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. 117
  • 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. 10/01/14 118
  • 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. 10/01/14 119
  • 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.  10/01/14 120
  • Seguridad contra delitos La seguridad contra delitos (security) de un sistema es una propiedad del sistema que refleja la habilidad del sistema de protegerse del ataque externo accidental o deliberado.  La seguridad está 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.  10/01/14 121
  • Seguridad Fundamental Si un sistema es un sistema conectado una red de computadoras y es inseguro, entonces las declaraciones sobre su fiabilidad y su seguridad 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.  10/01/14 122
  • Terminología de seguridad contra delitos Término Exposición Definició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. 10/01/14 123
  • 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. 10/01/14 124
  • 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. 10/01/14 125
  • 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. 10/01/14 126
  • 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.  10/01/14 127
  • Capítulo 4 Procesos de software 10/01/14 128
  • 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  10/01/14 129
  • Tópicos cubiertos Modelos del proceso de Software Iteración del proceso Actividades del proceso El Proceso Unificado Rational Ingeniería de software auxiliado por computadora 10/01/14 130
  • 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.  10/01/14 131
  • Modelos del proceso de software genérico     10/01/14 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. 132
  • Modelo de cascada Definición de Definición de requerimientos requerimientos Diseño de sistema yy Diseño de sistema software software Implementación yy Implementación pruebas de unidad pruebas de unidad Integración yy Integración pruebas de sistema pruebas de sistema Operación yy Operación mantenimiento mantenimiento 10/01/14 133
  • 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. 10/01/14 134
  • Problemas del modelo de cascada     El particionamiento inflexible del proyecto en fases distintas dificulta la respuesta a los requerimientos del cliente cambiantes. Por consiguiente, este modelo 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. 10/01/14 135
  • 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. 10/01/14 136
  • Desarrollo evolutivo Actividades concurrentes Especificación Especificación 10/01/14 Desarrollo Desarrollo Versión Versión intermedia intermedia Validación Validación Descripción Descripción del entorno del entorno Versión inicial Versión inicial Versión final Versión final 137
  • 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. 10/01/14 138
  • 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. 10/01/14 139
  • Desarrollo orientado al reuso Especificación de Especificación de requerimientos requerimientos Análisis de Análisis de componentes componentes Modificación de Modificación de requerimientos requerimientos Modificación de Modificación de requerimientos requerimientos 10/01/14 Diseño de sistemas Diseño de sistemas con reuso con reuso Diseño de sistemas Diseño de sistemas con reuso con reuso 140
  • 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. 10/01/14 141
  • 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.  10/01/14 142
  • Desarrollo incremental Definir requerimientos Definir requerimientos del entorno del entorno Desarrollar incremento Desarrollar incremento del sistema del sistema Asignar requerimientos al Asignar requerimientos al incremento incremento Validar Validar incremento incremento Integrar Integrar incremento incremento Sistema incompleto 10/01/14 Diseñar arquitectura Diseñar arquitectura del sistema del sistema Validar Validar sistema sistema Sistema final 143
  • Ventajas del desarrollo incremental  El valor del cliente puede entregarse con cada incremento para que la funcionalidad del sistema esté disponible antes.  Hechos de incrementos tempranos como un prototipo, ayudan a obtener requisitos para los incrementos 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. 10/01/14 144
  • Programación extrema  Una 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. 10/01/14 145
  • 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.  10/01/14 146
  • Modelo de espiral del proceso de software Determinar objetivos, alternativas y restricciones Evaluar alternativas, identificar y resolver riesgos Análisis de riesgo Análisis de riesgo Análisis de riesgo REVISION Plan de requerimientos Plan de ciclo de vida Plan de desarrollo Planificar próxima fase Integración y plan de pruebas Pro totipo 3 Pro totipo 2 Análisis de riesgo Pro totipo 1 Concepto de Simulaciones, modelos y referencias operación Requerimientos de software Producto Validación de de diseño requerimientos Diseño V & V Servicio 10/01/14 Pro totipo operacional Diseño detallado Código Prueba de Prueba de unidad aceptación Prueba de aceptación Desarrollo y verificación del próximo nivel del producto 147
  • 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.    10/01/14 148
  • Actividades del proceso Especificación del software Diseño e implementación del software Validación de software Evolución del software 10/01/14 149
  • 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. 10/01/14 150
  • El proceso de ingeniería de requerimientos Estudio de Estudio de factibilidad factibilidad Informe de Informe de factibilidad factibilidad Elicitación de Elicitación de requerimientos yy requerimientos análisis análisis Especificación de Especificación de requerimientos requerimientos Validación de Validación de requerimientos requerimientos Modelos del Modelos del sistema sistema Requerimientos Requerimientos del usuario yydel del usuario del sistema sistema Documentos de Documentos de requerimientos requerimientos 10/01/14 151
  • 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 10/01/14 152
  • Actividades del proceso de diseño Diseño arquitectónico Especificación abstracta Diseño de la interfaz Diseño de componentes Diseño de estructuras de datos Diseño de algoritmos 10/01/14 153
  • Proceso de diseño de software Especificación de Especificación de requerimientos requerimientos Diseño Diseño arquitectónico arquitectónico Arquitectura Arquitectura del sistema del sistema Especificación Especificación abstracta abstracta Especificación Especificación del software del software Actividades de diseño Diseño de Diseño de la interfaz la interfaz Especificación Especificación de la interfaz de la interfaz Diseño de Diseño de componentes componentes Especificación Especificación de componentes de componentes Diseño de Diseño de estructura de datos estructura de datos Especificación de Especificación de estructura de datos estructura de datos Diseño de Diseño de algoritmos algoritmos Especificación Especificación de algoritmos de algoritmos Productos de diseño 10/01/14 154
  • 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.  10/01/14 155
  • 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. 10/01/14 156
  • El proceso de depuración Error Error 10/01/14 local local Reparar error Reparar error de diseño de diseño Reparar error Reparar error Programa de Programa de re - -prueba re prueba 157
  • 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. 10/01/14 158
  • El proceso de prueba Prueba de Prueba de componentes componentes 10/01/14 Prueba del Prueba del sistema sistema Prueba de Prueba de aceptación aceptación 159
  • Fases de prueba    10/01/14 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. 160
  • Fases de prueba Especificación de Especificación de requerimientos requerimientos Especificación Especificación del sistema del sistema Plan de prueba Plan de prueba de aceptación de aceptación Servicio Servicio 10/01/14 Diseño del Diseño del sistema sistema Plan de prueba de Plan de prueba de integración del integración del sistema sistema Prueba de Prueba de aceptación aceptación Diseño Diseño detallado detallado Plan de prueba de Plan de prueba de integración del integración del sub - -sistema sub - -sistema Prueba de Prueba de integración del integración del sistema sistema Código de Código de módulo y unidad módulo y unidad y pruebas y pruebas Prueba de Prueba de integración de integración de Sub - sistema Sub - sistema 161
  • 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. 10/01/14 162
  • Evolución del sistema Definición de Definición de requerimientos requerimientos del sistema del sistema Evaluación Evaluación de sistemas de sistemas existentes existentes Sistema Sistema existente existente 10/01/14 Proponer Proponer cambios del cambios del sistema sistema Modificar Modificar el el sistema sistema Nuevo Nuevo sistema sistema 163
  • El Proceso Unificado Rational  Un modelo de proceso moderno derivado del trabajo del proceso asociado en UML.  Normalmente descrito desde 3 perspectivas    10/01/14 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. 164
  • Modelo de fase RUP Fase de integración Comienzo 10/01/14 Elaboración Construcción Transición 165
  • 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  10/01/14 Despliegue del sistema en el ambiente que opera. 166
  • Buena práctica en RUP  Desarrollo de la iteración del software  Manejo de requerimientos  Uso de arquitecturas basadas componentes  Visualización del modelo de software  Verificar la calidad del software  Control de cambios del software 10/01/14 en 167
  • Flujos de trabajo estático Flujos 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 10/01/14 168
  • 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. 10/01/14 169
  • 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. 10/01/14 170
  • 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. 10/01/14 171
  • Clasificación de herramientas funcionales Tipo de herramienta Planificación Ejemplo Herramientas PERT, herramientas de estimación, hojas de cálculo. Edición Cambio de gestión Editores de texto, editores gráficos, procesadores de palabras. 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 Soporte de modelos Lenguaje de procesos Análisis de programa Lenguajes de alto nivel, generadores de interfaz de usuario. Editores de diseño, diccionario de datos, generadores de código. Compiladores, intérpretes. Generadores de referencia cruzada, analizadores estáticos, analizadores dinámicos. Pruebas Generadores de datos de prueba, comparadores de archivos. Depuración Documentación Reingeniería Sistemas de depuración interactivos. Programas de configuración de página, editores de imagen. Sistemas de referencia cruzada, sistemas de reestructuración de programas. 10/01/14 172
  • 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 10/01/14 Verificación y validación 173
  • 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. 10/01/14 174
  • Herramientas, bancos de trabajo, ambientes Tecnología Tecnología CASE CASE Herramientas Herramientas Editores Editores Compiladores Compiladores Comparadores Comparadores de archivo de archivo Análisis y Análisis y Diseño Diseño Bancos de trabajo Bancos de trabajo Multi - métodos Multi - métodos 10/01/14 Ambientes Ambientes Bancos de Bancos de trabajo trabajo Ambientes Ambientes integrados integrados Programación Programación Bancos de trabajo Bancos de trabajo unimodelo unimodelo Ambientes de Ambientes de procesos centrados procesos centrados Pruebas Pruebas Bancos de trabajo de Bancos de trabajo de propósito general propósito general Bancos de trabajo de Bancos de trabajo de lenguajes específicos lenguajes específicos 175
  • 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. 10/01/14 176
  • 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. 10/01/14 177
  • Capítulo 5 Gestión de Proyectos 10/01/14 178
  • 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.  10/01/14 179
  • Tópicos cubiertos Actividades de gestión Planificación del proyecto Programación del proyecto Gestión de riesgos 10/01/14 180
  • Gestión del proyecto de software  Concierne a las actividades involucradas que aseguren que el software se entrega a tiempo y dentro de lo planificado y de acuerdo con los requerimientos de las organizaciones, desarrollando y procurando el software.  La 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. 10/01/14 181
  • Distinciones en la gestión del software 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. 10/01/14 182
  • Actividades de gestión  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. 10/01/14 183
  • Comunidad de gestión  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. 10/01/14 184
  • 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. 10/01/14 185
  • 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.  10/01/14 186
  • Tipos de planes de proyecto Plan Plan de calidad Descripción 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. Describe los procedimientos de gestión de configuración y estructuras a ser usadas. Ver Capítulo 29. Plan de gestión de configuración 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. 10/01/14 187
  • 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 10/01/14 188
  • El plan del proyecto Empezar el plan del proyecto  Los recursos disponibles proyecto;  La avería de trabajo;  Un programa para el trabajo. 10/01/14 del 189
  • 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. 10/01/14 190
  • 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. 10/01/14 191
  • Hitos en el Reproceso Actividades Estudio de Estudio de factibilidad factibilidad Informe de Informe de factibilidad factibilidad Análisis de Análisis de requerimientos requerimientos Requerimientos Requerimientos de usuario de usuario Desarrollo de Desarrollo de prototipo prototipo Informe de Informe de evaluación evaluación Estudio de Estudio de diseño diseño Diseño Diseño arquitectónico arquitectónico Especificación de Especificación de requerimientos requerimientos Requerimientos Requerimientos del sistema del sistema Hitos 10/01/14 192
  • 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. 10/01/14 193
  • El proceso de programación del proyecto Identificación Identificación de las de las actividades actividades Requerimientos de software 10/01/14 Identificación de Identificación de las dependencia las dependencia de las actividades de las actividades Estimación de Estimación de los recursos los recursos para actividades para actividades Colocación de Colocación de gente en las gente en las actividades actividades Creación de Creación de diagramas del diagramas del proyecto proyecto Gráficas de actividades y gráficas de barras 194
  • 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. 10/01/14 195
  • 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. 10/01/14 196
  • Duración de tareas y dependencias Actividad Inicio T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Final 10/01/14 Duración (días) 0 8 15 15 10 10 5 20 25 15 15 7 10 0 Dependencias Inicio Inicio T1 Inicio T2, T4 T1, T2 T1 T4 T3, T6 T5, T7 T9 T11 T8, T10,T12 197
  • Red de actividades 10/01/14 198
  • Calendario de Actividades 10/01/14 199
  • Asignación de personal 10/01/14 200
  • 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.    10/01/14 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. 201
  • Riesgos del software Riego 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 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 producto y Habrá un gran número de cambios en los requerimientos que se anticiparon. Retrasos de la especificación Proyecto y producto Especificaciones de interfaces 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. 10/01/14 esenciales no con estas 202
  • 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.  10/01/14 203
  • El proceso de gestión de riesgos Identificación Identificación de riesgos de riesgos Lista de riegos Lista de riegos potenciales potenciales 10/01/14 Análisis de Análisis de riesgos riesgos Lista de riegos Lista de riegos prioritarios prioritarios Planificación Planificación de riesgos de riesgos Anulación de Anulación de riesgos yyplanes de riesgos planes de contingencia contingencia Monitoreo Monitoreo de riesgos de riesgos Valoración Valoración de riesgos de riesgos 204
  • Identificación de riesgos Riesgos tecnológicos. Riesgos de personas. Riesgos organizacionales. Riesgos de requerimientos. Riesgos de estimación. 10/01/14 205
  • Tipos de riesgos Tipo de riesgo Tecnológico Posibles riesgos 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. 10/01/14 206
  • Análisis de riesgos Evaluar la probabilidad y seriedad de cada riesgo. La probabilidad puede ser muy baja, baja, moderada, alta o muy alta. Los efectos de riesgo podrían ser catastróficos, serios, tolerables o insignificantes. 10/01/14 207
  • Análisis de riesgos (i) Riesgo Probabilidad Problemas funcionales de organización fuerzan Baja a reducir el presupuesto del proyecto. Es imposible reclutar personas con las Alta habilidades requeridas. Efectos Catastrófico Personal importante está enfermo en tiempos Moderada críticos del proyecto. Los componentes de software que van a ser Moderada reusados contienen defectos que limitan su funcionalidad. Serio Los cambios de requerimientos que requieren Moderada mayor diseño proponen retrabajo. La organización es reestructurada, de modo que Alta diferentes gestiones son responsables para el proyecto. Serio 10/01/14 Catastrófico Serio Serio 208
  • Análisis de riesgos (ii) Riesgo Probabilidad La base de datos usada en el sistema no puede Moderada procesar muchas transacciones por segundo como se estera. Efectos Serio El tiempo requerido para desarrollar el software es Alta subestimado. Serio Las herramientas CASE no pueden ser integradas. Los clientes no entienden el impacto de los cambios de requerimientos. El entrenamiento requerido para las personas no está disponible La tasa de reparación de fallas es subestimada. El tamaño del software es subestimado. El código generado por las herramientas CASE es deficiente. Alta Moderada Tolerable Tolerable Moderada Tolerable Moderada Alta Moderada Tolerable Tolerable Insignificante 10/01/14 209
  • 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. 10/01/14 210
  • Estrategias de gestión de riesgos (i) Riesgo Problemas financieros de organización Estrategia 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. 10/01/14 211
  • Estrategias de gestión de riesgos (ii) Riesgo Cambio de requerimientos Estrategia 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 Preparar un documento de información para la organizacional 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 Tiempo de desarrollo subestimado 10/01/14 Investigar la posibilidad de compra una base de datos de alto desempeño. Investigar compra de componentes, investigar el uso de un generador de programas. 212
  • Monitoreo de riesgos  Evaluar cada uno de los riesgos identificados regularmente para decidir si está o no 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. 10/01/14 213
  • Indicadores de riesgo Tipo de riesgo Tecnología Gente Organización Herramientas Requerimientos Estimación 10/01/14 Indicadores potenciales Entrega tardía de hardware o soporte de software, muchos problemas técnicos reportados. Pobre moral del personal, pobre interrelación entre los miembros del equipo, disponibilidad de trabajo. Chisme organizacional, falta de acción de la alta dirección. Repugnancia de los miembros del equipo a usar herramientas , quejas sobre herramientas CASE, demandas de estaciones de trabajo de alto rendimiento. Muchas demandas de cambio de requerimientos, quejas de clientes. Fracaso para reunirse en el horario acordado, falla para borrar los defectos de reporte. 214
  • 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. 10/01/14 215
  • Puntos clave 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.  10/01/14 216
  • Capítulo 6 Requerimientos de software 10/01/14 217
  • Objetivos Introducir los conceptos of usuario y requerimientos del sistema Describir requerimientos funcionales y no funcionales Explicar cual requerimientos de software pueden ser organizados en un documento de requerimientos 10/01/14 218
  • Tópicos cubiertos  Requerimientos funcionales y no funcionales  Requerimientos de usuario  Requerimientos del sistema  Especificación de la interfaz  Documento de requerimientos de software 10/01/14 219
  • 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. 10/01/14 220
  • ¿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. 10/01/14 221
  • 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 ". 10/01/14 222
  • 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. 10/01/14 223
  • Definiciones y especificaciones Definición de requerimientos de usuario 1. 1. El software be proporcionar los medios de representar yyacceder aa archivos externos El software be proporcionar los medios de representar acceder archivos externos creados por otras herramientas creados por otras herramientas Especificación de requerimientos del sistema 1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos. 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 1.2 Cada tipo de archivo externo puede tener una herramienta asociada la cual se aplica al archivo. archivo. 1.3 Cada tipo de archivo externo puede ser representado con un icono especificado en la 1.3 Cada tipo de archivo externo puede ser representado con un icono especificado en la visual del usuario. visual del usuario. 1.4 1.4 Pueden ser proporcionadas facilidades para representar el icono en un tipo de archivo Pueden ser proporcionadas facilidades para representar el icono en un tipo de archivo externo definido por el usuario. externo definido por el usuario. 1.5 Cuando el usuario selecciona un icono que representa un archivo externo, el efecto de 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 esta selección es para aplicar la herramienta asociada con el tipo de archivo externo para el archivo representado por el icono seleccionado. el archivo representado por el icono seleccionado. 10/01/14 224
  • Lectores de requerimientos Requerimientos Requerimientos de usuario de usuario Gestión del cliente Gestión del cliente Usuarios finales del sistema Usuarios finales del sistema Ingenieros del cliente Ingenieros del cliente Gerentes de contrato Gerentes de contrato Arquitectos del sistema Arquitectos del sistema Requerimientos Requerimientos del sistema del sistema Especificación Especificación del diseño de del diseño de software software 10/01/14 Usuarios finales del sistema Usuarios finales del sistema Ingenieros del cliente Ingenieros del cliente Arquitectos del sistema Arquitectos del sistema Desarrolladores de software Desarrolladores de software Ingenieros del cliente (quizás) Ingenieros del cliente (quizás) Arquitectos del sistema Arquitectos del sistema Desarrolladores de software Desarrolladores de software 225
  • 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. 10/01/14 226
  • 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. 10/01/14 227
  • 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. 10/01/14 228
  • Ejemplos de requerimientos funcionales  El usuario podrá ser capaz de investigar cualquiera de todo conjunto inicial de bases de datos o seleccionar un subconjunto de él.  El sistema proporcionará visualizadores apropiados para que el usuario pueda leer los documentos en el 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. 10/01/14 229
  • 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”   10/01/14 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. 230
  • Completitud y consistencia de los requerimientos     En principio, los requerimientos deben estar completos y consistentes. Completo  Ellos deben incluir las descripciones de todos las recursos requeridos. Consistente  No debe haber 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. 10/01/14 231
  • Requerimientos no funcionales    Éstos definen propiedades del sistema y restricciones, por ejemplo la fiabilidad, tiempo de respuesta y requerimientos del almacenamiento. Las restricciones son son la capacidad de dispositivo I/O (entrada/salida), las representaciones del sistema, etc. Los requerimientos de proceso 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. 10/01/14 232
  • Clasificaciones no funcionales    Requerimientos del producto  Requerimientos que especifican que el producto entregado debe comportarse de una manera particular por ejemplo la velocidad de la 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. 10/01/14 233
  • Tipos de requerimientos no funcionales Requerimientos Requerimientos no funcionales no funcionales Requerimientos Requerimientos del producto del producto Requerimientos Requerimientos de eficiencia de eficiencia Requerimientos Requerimientos de fiabilidad de fiabilidad Requerimientos Requerimientos organizacionales organizacionales Requerimientos Requerimientos de portabilidad de portabilidad Requerimientos Requerimientos externos externos Requerimientos de Requerimientos de interoperabilidad interoperabilidad Requerimientos Requerimientos éticos éticos Requerimientos Requerimientos legales legales Requerimientos Requerimientos de utilidad de utilidad Requerimientos Requerimientos de entrega de entrega Requerimientos Requerimientos de desempeño de desempeño 10/01/14 Requerimientos Requerimientos de espacio de espacio Requerimientos de Requerimientos de implementación implementación Requerimientos Requerimientos estándar estándar Requerimientos Requerimientos de privacidad de privacidad Requerimientos de Requerimientos de seguridad física seguridad física 234
  • Ejemplos de requerimientos no funcionales    Requerimientos del producto 8.1 La interfaz del usuario para LIBSYS será implementado como HTML simple sin marcos o applets (aplicaciones o para Internet) de Java. Requerimientos organizacionales 9.3.2 El proceso de desarrollo de sistema y los documentos entregables conforme al proceso y los entregables definidos en XYZCo-SP-STAN-95. Requerimientos externos 7.6.5 El sistema no descubrirán información personal sobre clientes aparte de su nombre y número de referencia para operadores del sistema. 10/01/14 235
  • 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. 10/01/14 236
  • 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. 10/01/14 237
  • 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. 10/01/14 238
  • 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? 10/01/14 239
  • 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. 10/01/14 240
  • 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. 10/01/14 241
  • 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. 10/01/14 242
  • 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 . 10/01/14 243
  • Requerimientos del usuario  Debe describirse los requerimientos funcionales y no funcionales de tal una manera que sean entendibles por los usuarios del sistema que no tienen detallado el conocimiento 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. 10/01/14 244
  • 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. 10/01/14 245
  • Requerimientos de LIBSYS 4 ..5 LIBSYS proporcionará un sistema de contabilidad financiero que mantiene archivos de todos los pagos hecho por los usuarios del sistema. Los gerentes del sistema pueden configurar este sistema para que los usuarios regulares puedan recibir las tasas descontadas. 10/01/14 246
  • Requerimientos del editor de rejilla 2.6 Soporte de rejilla: Para ayudar en el posicionamiento de entidades en un diagrama, el usuario puede mover una rejilla en 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. 10/01/14 247
  • 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). 10/01/14 248
  • Presentación estructurada 2.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. 10/01/14 249
  • 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. 10/01/14 250
  • 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. 10/01/14 251
  • 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.    10/01/14 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. 252
  • 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. 10/01/14 253
  • Alternativas de especificación NL Propiedad Lenguaje natural estructurado Descripción del diseño Medida Esta aproximación depende de definir formas normales o plantillas para expresar la especificación de requerimientos. 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. 10/01/14 254
  • Especificaciones en lenguaje estructurado La libertad de escritura de los requerimientos está limitada por una plantilla predefinida para los requerimientos.  Todos los requerimientos son escritos de una manera 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.  10/01/14 255
  • 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. 10/01/14 256
  • Especificación del nodo basada en formatos Función Descripción Insulin Pump /Control Software/SRS/3.3.2 Computa la dosis de insulina: El nivel de azúcar seguro. 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 Fuente Salidas Destino Acción Lectura actual de azúcar (r2), las dos lecturas previas (el r0 y r1). La lectura actual de azúcar desde e sensor. Otras lecturas desde la memoria. CompDose - la dosis en la insulina para ser entregado. Ciclo de control principal.. 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 Efectos colaterales r0 es reemplazado por r1 entonces r1 es reemplazado por r2. Ninguno. 10/01/14 257
  • 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. 10/01/14 258
  • Especificación tabular Condición Acción Caída de nivel de azúcar (r2 < r1) Nivel de azúcar estable (r2 = r1) Nivel de azúcar aumentando y tasa de incremento decreciendo ((el r2-r1)<(r1-r0)) Nivel de azúcar aumentando y tasa de incremento estable o aumentando.((el r2-r1)? (el r1-r0)) CompDose = 0 10/01/14 CompDose = 0 CompDose = 0 CompDose = redondeo ((el r2-r1)/4) Si el resultado redondeado = 0 entonces CompDose = MinimumDose 259
  • Modelos gráficos Los 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. 10/01/14 260
  • 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. 10/01/14 261
  • Diagrama de secuencia de retiro de CA (Cajero Automático) ca : CajeroAutomático bd : Base de Datos c : Cliente 1: Tarjeta 2: Número de tarjeta 3: Solicitud de PIN 4: Tarjeta OK 5: PIN 6: Menú de Opciones <<excepción>> 7: Tarjeta inválida 8: Pedido de retiro 9: Pedido de balance 10: Pedido de monto 11: Balance 12: Monto 13: Cargar(Monto) <<execpción>> 15: Efectivo insuficiente 14: Rpta de carga 16: Tarjeta 17: Retirar tarjeta 18: Efectivo 19: Retirar efectivo 20: Recibo 10/01/14 262
  • 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. 10/01/14 263
  • Descripción de interfaz PDL nterface PrintServer { // defines an abstract printer server // requires: interface Printer, interface PrintDoc // provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter void initialize ( Printer p ) ; void print ( Printer p, PrintDoc d ) ; void displayPrintQueue ( Printer p ) ; void cancelPrintJob (Printer p, PrintDoc d) ; void switchPrinter (Printer p1, Printer p2, PrintDoc d) ; } //PrintServer 10/01/14 264
  • 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 10/01/14 265
  • Usuarios de un documento de requerimientos Clientes del sistema Clientes del sistema Especifican los requerimientos yylos leen para Especifican los requerimientos los leen para chequear que reúnan sus necesidades. Ellos chequear que reúnan sus necesidades. Ellos especifican los cambios en los requerimientos. especifican los cambios en los requerimientos. Gerentes Gerentes Usan el documento de requerimientos para Usan el documento de requerimientos para planificar una oferta para el sistema yy planificar una oferta para el sistema planifican el proceso de desarrollo del sistema. planifican el proceso de desarrollo del sistema. Ingenieros de Ingenieros de sistemas sistemas Usan los requerimientos del sistema para Usan los requerimientos del sistema para pensar que sistema va aaser desarrollado. pensar que sistema va ser desarrollado. Ingenieros de Ingenieros de pruebas del sistema pruebas del sistema Usan los requerimientos del sistema para Usan los requerimientos del sistema para desarrollar las pruebas de validación del desarrollar las pruebas de validación del sistema sistema Ingenieros de Ingenieros de mantenimiento del mantenimiento del sistema sistema Usan los requerimientos del sistema para Usan los requerimientos del sistema para pensar en el sistema yy las interrelaciones con pensar en el sistema las interrelaciones con sus partes sus partes 10/01/14 266
  • 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 10/01/14 267
  • 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 10/01/14 268
  • Puntos clave  Los requerimientos del sistema son pensados para comunicar las funciones que el sistema debe proporcionar.  Un documento de requerimientos de software es una 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. 10/01/14 269
  • 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.  10/01/14 270
  • Capítulo 7 Proceso de ingeniería de procesos 10/01/14 271
  • 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 10/01/14 272
  • Tópicos cubiertos Estudios de factibilidad Elicitación de requerimientos análisis Validación de requerimientos Gestión de requerimientos 10/01/14 y 273
  • 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. 10/01/14 274
  • Procesos de la ingeniería de requerimientos Estudio de Estudio de factibilidad factibilidad Elicitación de Elicitación de requerimientos requerimientos yyanálisis análisis Especificación de Especificación de requerimientos requerimientos Informe de Informe de factibilidad factibilidad Validación de Validación de requerimientos requerimientos Modelos del Modelos del sistema sistema Requerimientos Requerimientos del usuario yyel del usuario el sistema sistema Documento de Documento de requerimientos requerimientos 10/01/14 275
  • Ingeniería de requerimientos Especificación de Especificación de requerimientos 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 sistema Elicitación de e requerimientos del usuario Elicitación de Elicitación de requerimientos requerimientos Documento de requerimientos del sistema 10/01/14 Estudio de factibilidad Revisiones Prototipado Validación de Validación de requerimientos requerimientos 276
  • Estudio de factibilidad  Un estudio de factibilidad decide si el sistema propuesto vale o no la pena.  Un corto estudio enfocado que verifica:  Si el sistema contribuye a los objetivos del 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. 10/01/14 277
  • Implementación del estudio de factibilidad   10/01/14 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? 278
  • Elicitación y análisis    10/01/14 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. 279
  • 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. 10/01/14 280
  • La espiral de los requerimientos Clasificación de requerimientos y organizacionales Descubrimiento de requerimientos 10/01/14 Prioritarización de requerimientos y negociación Documentación de requerimientos 281
  • 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. 10/01/14 282 
  • 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. 10/01/14 283
  • Stakeholders de un CA  Clientes del banco  Representes de otros bancos  Gerentes del banco  Personal de contadores  Administradores de bases de datos  Gerentes de seguridad  Departamento de marketing  Ingenieros de mantenimiento de hardware y software  Reguladores de la banca 10/01/14 Ing. Otoniel Silva Delgado - Ing. Ivan Pino Tellería 284
  • Puntos de vista  Los puntos de vista son una manera de estructurar los requerimientos para representar las perspectivas de stakeholders diferentes. Los stakeholders pueden ser clasificados bajo los puntos de vista diferentes.  Este análisis multi-perspectiva es importante porque allí no existe una sola manera correcta de analizar los requerimientos del sistema. 10/01/14 285
  • 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. 10/01/14 286
  • Identificación de puntos de vista  Identificar       10/01/14 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. 287
  • Jerarquía de los puntos de vista de LIBSYS Todos los PVs Indirecta Indirecta Gerente de Gerente de librería librería Finanzas Finanzas Estudiantes Estudiantes 10/01/14 Interactor Interactor El artículo El artículo proporciona proporciona Personal Personal Usuarios Externos Externos Personal de librería Dominio Dominio Estándares de UI Gerentes del sistema Sistema de clasificación Catalogadores 288
  • Entrevistando  En una entrevista formal o informal, el equipo de RE pone las preguntas a los stakeholders sobre el sistema que ellos usan y el sistema a ser desarrollado.  Hay dos tipos de entrevista  Entrevistas cerradas 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. 10/01/14 289
  • 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. 10/01/14 290
  • Entrevistadores efectivos  Los entrevistadores deben tener mente abierta , para escuchar a los stakeholders y no debe de tener ideas preconcebidas sobre los requerimientos.  Ellos deben incitar al entrevistado con una pregunta o una propuesta y simplemente no deben esperar que ellos respondan a una pregunta como “que es lo que usted quiere”. 10/01/14 291
  • Escenarios  Los escenarios son los ejemplos de la vida real de cómo un sistema puede usarse.  Ellos deben incluir      10/01/14 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. 292
  • 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. 10/01/14 293
  • Escenario LIBSYS (2) Qué puede salir mal: El usuario no puede rellenar el formato de derechos de propiedad correctamente. En este caso, el formato debe representarse al usuario para la 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”. 10/01/14 294
  • 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. 10/01/14 295
  • Caso de uso: Imprimir artículo Usario 10/01/14 Imprimir artículo 296
  • Casos de uso LIBSYS Buscar artículo Usuario de Librería Imprimir artículo Administración de usuario Proveedor 10/01/14 Personal de Librería Servicio de catálogo 297
  • Imprimir artículo usuario1 : Usuario item : Artículo 1: Petición formDR : Formulario miET : EspacioTrabajo miImpresora : Impresora 2: Petición 3: Retornar 4: Completar 5: DR:=OK 6: Entregar 7: Artículo:=OK 8: Imprimir 11: Informar 9: Enviar 10: Confirmar 12: Eliminar 10/01/14 298
  • Secuencia: Imprimir artículo usuario1 : Usuario item : Artículo 1: Petición formDR : Formulario miET : EspacioTrabajo miImpresora : Impresora 2: Petición 3: Retornar 4: Completar 5: DR:=OK 6: Entregar 7: Artículo:=OK 8: Imprimir 11: Informar 9: Enviar 10: Confirmar 12: Eliminar 10/01/14 299
  • Factores sociales y organizacionales  Los sistemas del software se usan en un contexto social y organizacional. Esto puede influenciar o incluso puede dominar los requerimientos del sistema.  Los factores sociales y organizacionales no son un solo punto de vista, pero son influyentes en todos los puntos de vista.  Los buenos analistas deben ser sensibles a estos factores pero realmente no hay ninguna manera sistemática de acometer su análisis. 10/01/14 300
  • 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. 10/01/14 301
  • 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. 10/01/14 302
  • Etnografía y prototipado Análisis Análisis etnográfico etnográfico Reuniones Reuniones interrogando interrogando Etnografía Etnografía enfocada enfocada Evaluación Evaluación del prototipo del prototipo Desarrollo de Desarrollo de sistemas sistemas genéricos genéricos 10/01/14 Prototipado Prototipado de sistemas de sistemas 303
  • Alcance de la etnografía  Los requerimientos que se derivan de la manera en que las personas realmente trabajan, en lugar de la manera que las definiciones del proceso sugieren que ellos deban trabajar.  Los requerimientos que se derivan de la cooperación y conocimiento de las actividades de otras personas. 10/01/14 304
  • 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. 10/01/14 305
  • 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?  10/01/14 306
  • 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. 10/01/14 307
  • 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. 10/01/14 308
  • 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? 10/01/14 309
  • 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. 10/01/14 310
  • Cambio de requerimientos  La prioridad de los requerimientos desde cambios de diferentes puntos de vista durante el proceso de desarrollo.  Clientes del sistema pueden especificar los requerimientos desde una perspectiva comercial que son conflictivos con los requerimientos del usuario final.  El ambiente comercial y técnico del sistema cambian durante su desarrollo. 10/01/14 311
  • Evolución de los requerimientos Entendimiento Entendimiento inicial del inicial del problema problema Requerimientos Requerimientos iniciales iniciales Cambio del Cambio del entendimiento entendimiento del problema del problema Cambio de los Cambio de los requerimientos requerimientos Tiempo 10/01/14 312
  • 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. 10/01/14 313
  • Clasificación de requerimientos Tipo de requerimiento Requerimientos mudables Descripción 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. 10/01/14 314
  • 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; 10/01/14 315
  • 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. 10/01/14 316
  • Matriz de trazabildad 10/01/14 317
  • 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. 10/01/14 318
  • 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. 10/01/14 319
  • Gestión de cambios Revisión de requerimientos Identificación del problema Análisis del Análisis del problema yy problema especificación del especificación del cambio cambio 10/01/14 Análisis yycostos Análisis costos del cambio del cambio Implementación Implementación del cambio del cambio 320
  • 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. 10/01/14 321
  • 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. 10/01/14 322
  • Capítulo 8 Modelos de sistema 10/01/14 323
  • 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 10/01/14 324
  • Tópicos cubiertos Modelos de contexto Modelos de comportamiento Modelos de datos Modelos de objetos Bancos de trabajo CASE 10/01/14 325
  • Modelado del sistema   10/01/14 El modelado del sistema ayuda que el analista entienda la funcionalidad del sistema y los modelos se usan para comunicarse con clientes. Diferentes modelos presentan el sistema desde perspectivas diferentes  Perspectiva externa, mostrando el contexto del sistema o ambiente;  Perspectiva del comportamiento, mostrando el comportamiento del sistema;  Perspectiva estructural mostrando el sistema o la arquitectura de los datos. 326
  • Tipos de modelo Modelo de procesamiento de datos, que muestra 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 subsistemas 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.  10/01/14 327
  • Modelos de contexto  Los modelos del contexto son usados para ilustrar el contexto operacional de un sistema ellos muestran qué situaciones hay fuera de los 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. 10/01/14 328
  • El contexto de un sistema de un CA Sistema de Sistema de seguridad seguridad Sistema de Sistema de contabilidad de contabilidad de sucursal sucursal Sistema de Sistema de contador de contador de sucursal sucursal Base de datos de Base de datos de cuenta cuenta Sistema de Sistema de Cajero Cajero Automático Automático Base de datos de Base de datos de usuario usuario Sistema de Sistema de mantenimiento mantenimiento 10/01/14 329
  • Modelos de proceso Los modelos de proceso muestran el proceso global y los procesos que son apoyados por el sistema. El modelo de flujo de datos pueden usarse para mostrar los procesos y el flujo de información de un proceso a otro. 10/01/14 330
  • Proceso de obtención de equipo Requerido Requerido por equipo por equipo específico específico Especificación de equipo Especificación de equipo Base de datos Base de datos del proveedor del proveedor Nota de entrega Especificación revisada Especificación Especificación de validación de validación Lista de proveedores Hallar Hallar proveedores proveedores Obtener costo Obtener costo de de estimaciones estimaciones Especificación + Proveedor + Estimación Elegir Elegir proveedor proveedor Pedido de detalles + Formato de pedido en blanco Aceptar Aceptar entrega de entrega de equipo equipo Nota de entrega Notificación de pedido Hacer pedido Hacer pedido de equipo de equipo Revisar Revisar entrega de entrega de ítems ítems Instrucciones de instalación Instalar Instalar equipo equipo Aceptación de instalación Formato de pedido verificado y revisado Aceptar entrega Aceptar entrega de equipo de equipo Detalles de equipo Base de datos Base de datos de equipo de equipo 10/01/14 331
  • Modelos de comportamiento    Los modelos de comportamiento se usan para describir el comportamiento global de un sistema. Los dos tipos del modelos de comportamiento son:  Modelos de procesamiento de datos, que muestran 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. 10/01/14 332
  • Modelos de procesamiento de datos Los diagramas de flujo de fluyen (DFDs) puede usarse para modelar el procesamiento de datos del sistema.  Éstos muestran que el proceso camina como flujos de datos a 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.  10/01/14 333
  • DFD de procesamiento de pedido Pedido de detalles + Formato de pedido en blanco Completar Completar formato de formato de pedido pedido Formato de pedido completado Formato de pedido firmado Formato de pedido firmado Validar Validar pedido pedido Enviar al Enviar al proveedor proveedor Pedido verificado y firmado + Notificación de pedido Registrar Registrar pedido pedido Detalle de pedido Formato de pedido firmado Ajustar al Ajustar al presupuesto presupuesto disponible disponible Cuenta de pedido + Detalles de cuenta Archivo de Archivo de pedidos pedidos 10/01/14 Aceptar entrega Aceptar entrega de equipo de equipo 334
  • Diagramas de flujo de datos  Los 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. 10/01/14 335
  • DFD de bombeo de insulina Sangre Sensor de Sensor de azúcar en la azúcar en la sangre sangre Insulina Bombeo de Bombeo de insulina insulina 10/01/14 Parámetros Nivel de de sangre Análisis de azúcar en la Análisis de azúcar en sangre azúcar en la sangre la sangre Computación de Computación de requerimientos Comandos de requerimientos de insulina control de de insulina bombeo Controlador Controlador Requerimientos de entrega de entrega de insulina de insulina de insulina 336
  • Modelos de máquina de estados     10/01/14 É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. 337
  • Diagramas de estado  Permite 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. 10/01/14 338
  • Modelo de horno microondas Máxim a potencia Máxim a potencia do/ Poner Power = 600 Cronómetro Núm ero Operación Es perando do/ Visualizar tiempo Media energía do/ Operar el horno Fijar tiem po Iniciar do/ Dar número exit/ Fij ar tiempo Cronómetro Media potencia Puerta cerrada Habilitado Puerta abierta do/ Visualizar "Listo" Media potencia do/ Poner Power = 300 Puerta cerrada Deshabilitado do/ Visual izar "Esperando" Cancelar 10/01/14 339
  • Descripción de estados del horno microondas Estado Esperando El horno está esperando por la entrada. El visualizador muestra el tiempo actual. Media potencia La potencia del horno se pone a 300 vatios. El visualizador muestra “Media potencia”. Máxima potencia Fijar tiempo La potencia del horno se pone a 600 vatios. El visualizador muestra “ Máxima potencia”. 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. 10/01/14 Descripción 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. 340
  • Estímulos del horno microondas Estado Media potencia Máxima potencia Cronómetro Número Puerta abierta Puerta cerrada Iniciar Cancelar 10/01/14 Descripción El usuario ha presionado el botón de media potencia. El usuario ha presionado el botón de máxima potencia. El usuario ha presionado uno de los botones del cronómetro. El usuario ha presionado una llave numérica. El interruptor de puerta del horno no está cerrado. El interruptor de puerta del horno está cerrado. El usuario ha presionado el botón de salida. El usuario ha presionado el botón de cancelación. 341
  • Operación de horno microondas OperaciónHorno Tiempo Comprobando OK do/ Comprobar estado Falla de botón giratorio Cocinando do/ Ejecutar generador Interrupción Falla del emisor Hecho do/ Sonido durante 5 segundos Alarma do/ Mostrar evento Desactivado 10/01/14 Puerta abierta EnEspera 342
  • 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ónatributo 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.  10/01/14 343
  • Modelo semántico de Librería Artículo Fuente ID_artículo Título Autores Archivo_PDF Cuota ID_fuente Publica_en Título Editor Edición Fecha Páginas Cuota_pagable_a Solicita En Pedido Nro_pedido PagoTotal Fecha Impuesto_estado ID_artículo (FK) Id_comprador (FK) Agencia_DR País Id_agencia Nombre Dirección ID_fuente (FK) ID_país En ID_fuente (FK) Formato_DR Tasa_impuesto Id_agencia (FK) Coloca Comprador Id_comprador Nombre Dirección E_mail InformeCuenta 10/01/14 344
  • Diccionarios de datos  Los diccionarios de datos son listas de todos los nombres usados en los modelos del sistema. Las descripciones de las entidades, las interrelaciones y atributos 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. 10/01/14 345
  • Entradas de diccionario de datos Nombre Descripción Tipo Fecha Artículo Detalles del artículo publicado que Entidad pueden ser pedidas por las personas que usan LIBSYS. 30/12/2005 Autores Los nombres de los autores del Atributo artículo quienes pueden ser una porción de la cuota. La persona u organización que Entidad piden una copia del artículo. Interrelación entre las entidades Interrelación Artículo y Agencia_DR que describe la cuota del pago de los derechos reservados. 30/12/2005 La dirección del comprador. Esto Atributo se usa para cualquier papel que factura información que se requiere. 31/12/2005 Comprador Cuota_pagable_a Dirección 10/01/14 30/12/2005 29/12/2005 346
  • 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. 10/01/14 347
  • 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. 10/01/14 348
  • 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. 10/01/14 349
  • 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. 10/01/14 350
  • Herencia de la clase Librería ItemLibrería NúmeroCatálogo FechaAdquisición Costo Tipo Estado NúmeroCopias Adquirir() Catalogar() Disponer() Publicar() Retornar() ItemPublicado ItemRegistrado Título Editor Libro Autor Edición FechaPublicación ISBN 10/01/14 T ítulo Medio Revista Año Número Película Director FechaRealización Distribuidor ProgramaComputadora Versión Plataforma 351
  • Herencia de la clase Usuario UsuarioLibrería Nombre Dirección Teléfono NúmeroRegistro Regis trar() Desregistrar() Lector Prestatario Afiliación Items Préstamo Máxim oPrés tam o Personal Departamento TeléfonoDepto 10/01/14 Estudiante TemaMayor DirecciónDomicilio 352
  • 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.  10/01/14 353
  • Herencia múltiple Libro GrabaciónVoz Autor Edición FechaPublicación ISBN Altavoz Duración FechaGrabación LibroParlante NúmeroCintas 10/01/14 354
  • Agregación de objetos Un 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. 10/01/14 355
  • Agregación de objetos PaqueteEstudio TítuloCurso Número Año Instructor DiapositivasOHP Créditos Ejercicios 10/01/14 Videocinta Texto IdCinta Soluciones NúmeroProblema Descripción NotasLectura Diapositivas Asignación Texto Diagramas 356
  • 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. 10/01/14 357
  • Edición de artículos electrónicos Ecat : Catálogo usLib : UsuarioLibrería itLib : ItemLibrería Lib1 1: Mirar 2: Visualizar 3: Publicar 4: Licencia de publicar 5: Aceptar licencia 6: Comprimir 7: Entregar 10/01/14 358
  • 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. 10/01/14 359
  • 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 10/01/14 360
  • 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.  10/01/14 361
  • Un banco de trabajo de análisis y diseño Diccionario Diccionario de de datos datos Generador Generador de de código código Herramientas de Herramientas de creación de creación de formularios formularios 10/01/14 Herramientas de Herramientas de diagramación diagramación estructurada estructurada Recursos de Recursos de generación de generación de informes informes Almacén de Almacén de información información central central Recursos de Recursos de lenguaje de lenguaje de consulta consulta Herramientas de Herramientas de análisis, diseño yy análisis, diseño comprobación comprobación Recursos de Recursos de importación / / importación exportación exportación 362
  • 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 10/01/14 363
  • 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.  10/01/14 364
  •  Los Puntos clave 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. 10/01/14 365
  • Capítulo 9 Especificación de sistemas críticos 10/01/14 366
  • 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 10/01/14 367
  • Tópicos cubiertos Especificación de manejo de riesgo Especificación de seguridad física Especificación de seguridad contra delitos Especificación de fiabilidad del software 10/01/14 368
  • 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. 10/01/14 369
  • 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. 10/01/14 370
  • 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. 10/01/14 371
  • Especificación de manejo de riesgos Identificación Identificación del del riesgo riesgo Análisis yy Análisis clasificación clasificación del riesgo del riesgo Planificación Planificación del del riesgo riesgo Evaluación de Evaluación de reducción del reducción del riesgo riesgo Descripción del Descripción del riesgo riesgo Evaluación del Evaluación del riesgo riesgo Análisis de la Análisis de la causa raíz causa raíz Requerimientos Requerimientos de confiabilidad de confiabilidad 10/01/14 372
  • Identificación del riesgo     10/01/14 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;  … 373
  • Los riesgos de la bomba de insulina         10/01/14 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). 374
  • Análisis de riesgo y clasificación   10/01/14 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. 375
  • Niveles de riesgo 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 Región ALARP Región aceptable Riego despreciable 10/01/14 376
  • 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. 10/01/14 377
  • 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. 10/01/14 378
  • Valoración del riesgo – bomba de insulina Identificación del riesgo Sobredosis de insulina Baja dosis de insulina Falla de potencia Máquina ajusta incorrectamente Probabilidad Severidad del Riesgo del riesgo riesgo estimado Media Alta Alta Intolerable Media Baja Baja Aceptable Alta Alta Baja Alta Baja Alta Aceptable Intolerable Máquina interrumpe en el paciente Máquina causa infección Interferencia eléctrica Reacción alérgica Baja Alta Media ALARP Media Media Media ALARP Baja Alta Media ALARP Baja Baja Baja Aceptable 10/01/14 Aceptabilidad 379
  • 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.  10/01/14 380
  • 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. 10/01/14 381
  • Árbol de falla de la bomba de insulina Incorrecta dosis Incorrecta dosis de insulina de insulina administrada administrada Or Or Incorrecto nivel Incorrecto nivel de azúcar de azúcar medido medido Correcta dosis Correcta dosis entregada en entregada en mal momento mal momento Falla de Falla de sistema de sistema de entrega entrega Or Or Falla de Falla de sensor sensor Or Or Error de Error de cómputo cómputo de azúcar de azúcar Falla de Falla de cronómetro cronómetro Incorrecto Incorrecto cálculo de cálculo de insulina insulina Or Or Or Or Error Error algorítmico algorítmico 10/01/14 Incorrecta Incorrecta señal de señal de bombeo bombeo Error Error aritmético aritmético Error Error algorítmico algorítmico Error Error aritmético aritmético 382
  • 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. 10/01/14 383
  • 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 . 10/01/14 384
  • 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. 10/01/14 385
  • 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. 10/01/14 386
  • 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. 10/01/14 387
  • 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. 10/01/14 388
  • Requerimientos de seguridad del sistema de control Requerimientos Requerimientos del sistema del sistema Sistema de Sistema de control control Equipamiento Equipamiento Sistema de Sistema de protección protección 10/01/14 Requerimientos de Requerimientos de seguridad física seguridad física Requerimientos de Requerimientos de seguridad física seguridad física funcional funcional Requerimientos de Requerimientos de integridad de integridad de seguridad física seguridad física 389
  • Ciclo de vida de la seguridad física Concepto y definición Concepto y definición de alcance de alcance Análisis de peligro y Análisis de peligro y riesgo riesgo Asignación de Asignación de requerimientos de requerimientos de seguridad seguridad Derivación de Derivación de requerimientosde requerimientos de seguridad seguridad Planificación y desarrollo Desarrollo de sistemas Desarrollo de sistemas de seguridad de seguridad relacionados relacionados Planeando Validación O&M Recursos de Recursos de reducción de reducción de riesgos externo riesgos externo Instalación Validación de seguridad Validaciónfísica de de seguridad de física Instalación y Instalación comisionado y comisionado Operación y Operación y mantenimiento mantenimiento Decomiso del Decomiso sistema del sistema 10/01/14 390
  • 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. 10/01/14 391
  • 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. 10/01/14 392
  • El proceso de especificación de seguridad contra delitos Tecnología de Tecnología de seguridad yy seguridad análisis análisis Identificación del Identificación del recurso recurso Lista de recursos Lista de recursos del sistema del sistema 10/01/14 Análisis de la Análisis de la amenaza yy amenaza valoración del valoración del riesgo riesgo Matriz de riesgos yy Matriz de riesgos amenazas amenazas Análisis de Análisis de tecnología tecnología Asignación Asignación de amenaza de amenaza Descripción de Descripción de amenaza yy amenaza riesgo riesgo Especificación de Especificación de requerimientos de requerimientos de seguridad seguridad Requerimientos de Requerimientos de confiabilidad confiabilidad 393
  • Especificación de estados en la seguridad contra delitos  Identificación del recurso y evaluación   Análisis de la amenaza y valoración del riesgo   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. Se identifican las posibles amenazas de seguridad y los riesgos asociados con cada uno de estas amenazas son estimados. Asignación de la amenaza  10/01/14 Se relacionan las amenazas identificadas a los recursos para que, para cada recurso identificado, hay una lista de amenazas asociadas. 394
  • 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. 10/01/14 395
  • 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. 10/01/14 396
  • 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. 10/01/14 397
  • Especificación de fiabilidad de sistemas  Fiabilidad del hardware   Fiabilidad del software   ¿Cuál es la probabilidad de que un componente del hardware esté fallando y cuánto tiempo toma reparar ese componente? 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  10/01/14 ¿Cuán probable es que el operador de un sistema cause un error? 398
  • Requerimientos de fiabilidad funcional Un rango predefinido para todos los valores que se ingresan por el operador 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.  10/01/14 399
  • Especificación de fiabilidad no funcional    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 postentrega 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. 10/01/14 400
  • Métricas de fiabilidad  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. 10/01/14 401
  • Métricas de fiabilidad Métrica POFOD La posibilidad de falla en la demanda Explicación 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. 10/01/14 402
  • Probabilidad de falla en demanda Esta es la probabilidad que el sistema fallará cuando una demanda de servicio sea hecha. Es útil cuando las demandas para el servicio son intermitentes y relativamente poco frecuente.  Apropiado para los sistemas de 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.  10/01/14 403
  • Tasa de ocurrencia de falla (ROCOF) Refleja la tasa de ocurrencia de falla en el sistema.  Un ROCOF de 0.002 significa que 2 fallas son probables en cada 1000 unidades de tiempo operacionales, por ejemplo, 2 fallas por 1000 horas de funcionamiento.  Relevante para los sistemas operativos, transacción que procesa sistemas dónde el sistema tiene que procesar un número grande de demandas similares que son relativamente frecuentes.   10/01/14 Sistema de procesamiento de tarjeta de crédito, sistema de reserva en aerolínea. 404
  • 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. 10/01/14 405
  • 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.  10/01/14 406
  • 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. 10/01/14 407
  • 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. 10/01/14 408
  • Clasificación de fallas Clase de falla Descripción Transitoria 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 datos Corrupta La falla corrompe el estado del sistema o datos. 10/01/14 409
  • Pasos para especificación de fiabilidad  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. 10/01/14 410
  • 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. 10/01/14 411
  • Especificación de fiabilidad para un CA Clases de falla Permanente no corrupta Ejemplo El sistema falla para operar con cualquier tarjeta que se entra. El software debe reiniciarse para corregir la falla. Métrica de fiabilidad ROCOF 1 ocurrencia/1000 días. Transitoria no corrupta Los datos de la franja magnética ROCOF no pueden leerse en una tarjeta 1 en 1000 no dañada que se ingresa. transacciones Transitoria corrupta Un patrón de transacciones a ¡No través de la red causa cuantificable! corrupción de base de datos. Nunca debe pasar en la vida del sistema. 10/01/14 412
  • 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. 10/01/14 413
  • 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.  10/01/14 414
  • Puntos clave  Las 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. 10/01/14 415
  • Capítulo 10 Especificaciones formales 10/01/14 416
  • 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. 10/01/14 417
  • Tópicos cubiertos Especificación formal en el proceso de software Especificación de la interfaz de un sub-sistema Especificación del comportamiento 10/01/14 418
  • 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.  10/01/14 419
  • 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. 10/01/14 420
  • 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 .  10/01/14 421
  • 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. 10/01/14 422
  • Especificación y diseño Participación creciente del contratista Participación decreciente del cliente Definición de Definición de requerimientos requerimientos del usuario del usuario Especificación de Especificación de requerimientos requerimientos del sistema del sistema Diseño Diseño arquitectónico arquitectónico Especificación Especificación formal formal Diseño de Diseño de alto nivel alto nivel Especificación Diseño 10/01/14 423
  • Especificación en el proceso de software Especificación de Especificación de requerimientos requerimientos del sistema del sistema Especificación Especificación formal formal Diseño de Diseño de alto nivel alto nivel Definición de Definición de requerimientos requerimientos del usuario del usuario Modelamiento del Modelamiento del sistema sistema 10/01/14 Diseño Diseño arquitectónico arquitectónico 424
  • 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. 10/01/14 425
  • 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. 10/01/14 426
  • Desarrollo de costos con especificación formal 10/01/14 427
  • 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. 10/01/14 428
  • Lenguajes de especificación formal Algebraico Basado en modelo 10/01/14 Secuencial Concurrente Larch(Guttag, 1993) Lotos (Bolognesi y OBJ (Futatsugi, Brinksma, 1987) 1985) Z (Spivey, 1992) VDM (Jones, 1980) B (Worsworth, 1996) CSP (Hoare, 1985) Petri Nets (Peterson 1981) 429
  • 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.  10/01/14 430
  • Interfaces de subsistema Objetos de interfaz Sub - sistema A 10/01/14 Sub - sistema B 431
  • 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 10/01/14 432
  • 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. 10/01/14 433
  • Especificación algebraica sistemática  Especificaciones algebraica de un sistema puede ser desarrollada de una manera específica:       10/01/14 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. 434
  • 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. 10/01/14 435
  • 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.  10/01/14 436
  • Especificación de List List (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) 10/01/14 437
  • Recursión en especificaciones  Las operaciones se especifican a menudo recursivamente.  10/01/14 Tail (Cons (L, v)) = if L = Create then Create else Cons (Tail (L), v).  Cons ([5, 7], 9) = [5, 7, 9]  Tail ([5, 7, 9]) = Tail (Cons ( [5, 7], 9)) =  Cons (Tail ([5, 7]), 9) = Cons (Tail (Cons ([5], 7)), 9) =  Cons (Cons (Tail ([5]), 7), 9) =  Cons (Cons (Tail (Cons ([], 5)), 7), 9) =  Cons (Cons ([Create], 7), 9) = Cons ([7], 9) = [7, 9] 438
  • 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. 10/01/14 439
  • 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. 10/01/14 440
  • Operaciones primitivas    10/01/14 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. 441
  • 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 10/01/14 442
  • 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) 10/01/14 443
  • 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. 10/01/14 444
  • 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. 10/01/14 445
  • La estructura de un esquema Z Nombre del esquema Signatura del esquema Predicado del esquema Container contents N capacity N contents ^S = capacity 10/01/14 446
  • Modelando la bomba de insulina  El esquema Z para la bomba de insulina declara una variedad de variables de estado incluyendo:   10/01/14 ¿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). 447
  • Invariante del esquema  Cada esquema Z tiene una parte invariante que define condiciones que siempre son verdad.  Para el esquema de bomba de insulina es siempre verdad que    10/01/14 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. 448
  • Esquema de la bomba de insulina INSULIN_PUMP_STATE //Input device definition switch?: (off, manual, auto) ManualDeliveryButton?: N Reading?: N HardwareTest?: (OK, batterylow, pumpfail, sensorfail, deliveryfail) InsulinReservoir?: (present, notpresent) Needle?: (present, notpresent) clock?: TIME //Output device definition alarm! = (on, off) display1!, string display2!: string clock!: TIME dose!: N // State variables used for dose computation status: (running, warning, error) r0, r1, r2: N capacity, insulin_available : N max_daily_dose, max_single_dose, minimum_dose: N safemin, safemax: N CompDose, cumulative_dose: N 10/01/14 449
  • Invariantes de estado r2 = Reading? dose! ^S insulin_available insulin_available ^S capacity // The cumulative dose of insulin delivered is set to zero once every 24 hours clock? = 000000 ⇒ cumulative_dose = 0 // If the cumulative dose exceeds the limit then operation is suspended cumulative_dose ≥ max_daily_dose display1! = “Daily dose exceeded” ∧ status = error ∧ // Pump configuration parameters capacity = 100 ∧ safemin = 6 ∧ safemax = 14 max_daily_dose = 25 ∧ max_single_dose = 4 ∧ minimum_dose = 1 display2! = nat_to_string (dose!) clock! = clock? 10/01/14 450
  • 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. 10/01/14 451
  • Ejecutando esquema (1) RUN ∆INSULIN_PUMP_STATE switch? = auto  status = running ∨ status = warning insulin_available ≥ max_single_dose cumulative_dose < max_daily_dose // The dose of insulin is computed depending on the blood sugar level (SUGAR_LOW ∨ SUGAR_OK ∨ SUGAR_HIGH) // 1. If the computed insulin dose is zero, 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 ∨ 10/01/14 452
  • Ejecutando esquema (2) // 3. The normal situation. If maximum single dose is not exceeded then deliver the computed dose. If the single dose computed is too high, restrict the dose delivered to the maximum single dose CompDose + cumulative_dose < max_daily_dose ⇒ ( CompDose ≤ max_single_dose Þ dose! = CompDose ∨ CompDose > max_single_dose ⇒ dose! = max_single_dose ) insulin_available’ = insulin_available – dose! cumulative_dose’ = cumulative_dose + dose! insulin_available ≤ max_single_dose * 4 ⇒ status’ = warning ∧ display1! = “Insulin low” r1’ = r2 r0’ = r1 10/01/14 453
  • 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) 10/01/14 454
  • Puntos clave     10/01/14 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. 455
  • 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. 10/01/14 456
  • Capítulo 11 Diseño arquitectónico 10/01/14 457
  • 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  10/01/14 458
  • Tópicos cubiertos Decisiones del diseño arquitectónico Organización del sistema Estilos de descomposición Estilos de control Arquitecturas de referencia 10/01/14 459
  • Arquitectura del software El 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. 10/01/14 460
  • 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. 10/01/14 461
  • 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. 10/01/14 462
  • 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. 10/01/14 463
  • 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. 10/01/14 464
  • 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. 10/01/14 465
  • Sistema de control de robot empaquetado Sistema Sistema de Visión de Visión Sistema de Sistema de identificación identificación de objetos de objetos Controlador Controlador de brazo de brazo Controlador Controlador de pinza de pinza Sistema de Sistema de selección de selección de empaquetamiento empaquetamiento Sistema de Sistema de condensado condensado 10/01/14 Controlador Controlador de portador de portador 466
  • Diagramas de caja y línea Muy abstracto - ellos no muestran la naturaleza de relaciones de componente ni las propiedades visibles externamente de los subsistemas. Sin embargo, es útil para la comunicación con los stakeholders y para la planificación del proyecto. 10/01/14 467
  • 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. 10/01/14 468
  • 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 ? 10/01/14 469
  • 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. 10/01/14 470
  • 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. 10/01/14 471
  • 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. 10/01/14 472
  • 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. 10/01/14 473
  • 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. 10/01/14 474
  • Arquitectura del conjunto de herramientas CASE Editor de Editor de diseño diseño Traductor Traductor de diseño de diseño Almacén Almacén del proyecto del proyecto Analizador Analizador de diseño de diseño 10/01/14 Generador Generador de código de código Editor de Editor de programa programa Generador Generador de informes de informes 475
  • Características del modelo de almacén   10/01/14 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. 476
  • 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. 10/01/14 477
  • Librería de película y pintura Cliente 1 Cliente 1 Cliente 2 Cliente 2 Cliente 3 Cliente 3 Cliente 4 Cliente 4 Internet Internet Servidor de Servidor de catálogo catálogo Servidor de Servidor de video video Servidor de Servidor de pinturas pinturas Servidor de Servidor de Web Web Catálogo de Catálogo de librería librería Archivos de Archivos de películas y películas y clips clips Gráficos de Gráficos de fotos fotos digitalizadas digitalizadas Información Información de fotos y de fotos y películas películas 10/01/14 478
  • Características de clienteservidor 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. 10/01/14 479 
  • 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. 10/01/14 480
  • Sistema de gestión de versión Capa de sistema de gestión de configuración Capa de sistema de gestión de configuración Capa de sistema de gestión de objetos Capa de sistema de gestión de objetos Capa de sistema de base de datos Capa de sistema de base de datos Capa de sistema operativo Capa de sistema operativo 10/01/14 481
  • 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. 10/01/14 482
  • Subsistemas y módulos  Un 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. 10/01/14 483
  • 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. 10/01/14 484
  • 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. 10/01/14 485
  • Sistema de proceso de factura Recibo Cliente NumCliente Nombre Dirección PeriodoCrédito Pago NumFactura Fecha Cantidad NumCliente 10/01/14 Factura NumFactura Fecha Cantidad Cliente NumFactura Fecha Cantidad NumCliente Emitir() EnviarRecordatorio() AceptarPago() EnviarRecibo() 486
  • 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.  10/01/14 487
  • 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.  10/01/14 488
  • Sistema de procesamiento de factura Emitir recibos Emitir recibos Leer facturas Leer facturas emitidas emitidas Identificar Identificar pagos pagos Encontrar la Encontrar la deuda de deuda de pagos pagos Facturas Facturas 10/01/14 Recibos Recibos Emitir Emitir recordatorio recordatorio de pagos de pagos Recordatorios Recordatorios Pagos Pagos 489
  • 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. 10/01/14 490
  • 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.  10/01/14 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.  10/01/14 492
  • 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. 10/01/14 493
  • Modelo de retorno de llamada Programa Programa principal principal Rutina 1 Rutina 1 Rutina 1.1 Rutina 1.1 10/01/14 Rutina 2 Rutina 2 Rutina 1.2 Rutina 1.2 Rutina 3 Rutina 3 Rutina 3.1 Rutina 3.1 Rutina 1.2 Rutina 1.2 494
  • Control de sistemas de tiempo real Procesos de Procesos de sensor sensor Procesos de Procesos de actuados actuados Controlador Controlador del sistema del sistema Procesos de Procesos de computación computación 10/01/14 Interfaz de Interfaz de usuario usuario Manejador Manejador de fallas de fallas 495
  • 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 ha