Ingeniería de Software 2005 Ingeniería de Requerimientos Análisis de Riesgo UML Costeo Calidad Mg. Rodolfo Bertone UNPSJB.

Presentación del tema: "Ingeniería de Software 2005 Ingeniería de Requerimientos Análisis de Riesgo UML Costeo Calidad Mg. Rodolfo Bertone UNPSJB."— Transcripción de la presentación:

1 Ingeniería de Software 2005 Ingeniería de Requerimientos Análisis de Riesgo UML Costeo Calidad Mg. Rodolfo Bertone pbertone@lidi.info.unlp.edu.ar UNPSJB – Sede Comodoro Rivadavia

2 © RB UNPSJB - 2005Ingeniería de Software - Clase 12 Glosario de Clase  Objetivos del curso  Forma de trabajo  Contenido  Bibliografía  Jugando a entender un problema  Introducción a IR  Aproximación a IR

3 © RB UNPSJB - 2005Ingeniería de Software - Clase 13 Objetivos del curso  Comprender el objetivo de la IR  Ganar experiencia en las técnicas básica para IR  Entender la naturaleza de la IR  Evaluar el estado del arte de la IR, su nivel en la investigación científica y en la práctica  Comprender como influyen los factores de riesgo en un proyecto  Técnicas de modelado de información  UML  Estimar el costo de un proyecto de software  Calidad  conceptos, normas, CMM

4 © RB UNPSJB - 2005Ingeniería de Software - Clase 14 Forma de trabajo  Clase teóricas Se prevén 5/6 clases teóricas  Marzo, Abril, Mayo, Junio, Julio, Agosto  A partir de Abril deberán preparar trabajos, leer papers, preparar material  Clases prácticas Semanalmente   Práctica guía (5 en total)  Trabajo a realizar también podrán ser consultados

5 © RB UNPSJB - 2005Ingeniería de Software - Clase 15 Forma de Trabajo  Aprobación Un parcial (con un recuperatorio)  Basado en los temas de la práctica Un trabajo integrador realizado en grupo Promoción  Para aquellos alumnos que aprueben la cursada con nota mayor que 7 (entre el trabajo y el parcial promediado, teniendo en cuenta además la participación en clase y la resolución de los trabajos de teoría)  Posibilidad de rendir un examen teórico en fecha a determinar (posiblemente noviembre)

6 © RB UNPSJB - 2005Ingeniería de Software - Clase 16 Contenido (1)  Algunos conceptos básicos de IS Procesos de modelado Dinámica de trabajo en grupos JAD  Análisis de Riesgo  Ingeniería de Requerimientos Introducción a la IR  Que es la IR?  Por qué es importante?

7 © RB UNPSJB - 2005Ingeniería de Software - Clase 17 Contenido (2) Bases de la IR  Aspectos interdisciplinarios de la IR Actividades básica de IR  Toma de requerimientos  Modelado y Análisis de requerimientos  Comunicando Requerimientos  Aceptando Requerimientos  Evolucionando requerimientos  Costeo  UML  Mantenimiento del software  Calidad de software

8 © RB UNPSJB - 2005Ingeniería de Software - Clase 18 Bibliografía  Conjunto de libros, papers y materiales de otros cursos Ningún libro se adpata en su totalidad a la asignatura El alumno deberá obtener, investigando la información.  Algunos materiales  Libros  Systems Requeriments Engineering. Pericles Loucopoulos. Vassilios Karakosas. McGraw Hill. Book Company. 1995

9 © RB UNPSJB - 2005Ingeniería de Software - Clase 19 Bibliografía (cont)  Software Requeriments. Objects, functions, & States. Alan Davis. Prentice Hall 1993.+  Requeriments Engineering, Agood practice guide. Wileyt 1997.  The Mythical Man Month. Frederick Brooks. Addison Wesley 1995.  Ingeniería de Software. Ian Sommerville. Addison Weslesy. 2002  Ingeniería de Software. Teoría y Práctica. Shari Pflegger. Addision Wesley. 2002  Ingeniería de Software, un enfoque práctico. Roger Pressman. McGraw 1998.

10 © RB UNPSJB - 2005Ingeniería de Software - Clase 110 Bibliografía (cont)  Assessment and Control of Software Risk. Caper Jones. Yourdon Press. 1994  UML gota a gota. Martin Fowler. Pearson. 1999  El lenguaje Unificado de Modelado. Grady Booch. James Rumbaugh. Ivar Jacobson. Addison Wesley. 1999.  El lenguaje Unificado de Modelado. Manual de Referencia. Grady Booch. James Rumbaugh. Ivar Jacobson  Bibliografía de CMM (en profundidad con el material de dicho tema)

11 IS conceptos básicos Introducción a la Ingeniería de Requerimientos Clase 1 Un Juego Introducción – Bases de IR

12 © RB UNPSJB - 2005Ingeniería de Software - Clase 112 Contenido Clase 1  Un poco de juego  Introducción IR en el ciclo de vida del soft  Dimensión de la IR  Proceso escencial de IR Qué es un requerimiento? Importancia de los requerimientos El rol de la especificación Dominio de aplicación  Sistemas de información vs. Sistemas embebidos Procesos, métodos y técnicas  Desarrollo de producto y proceso

13 © RB UNPSJB - 2005Ingeniería de Software - Clase 113 Contenido Clase 1 Trabajo de campo de la IR  Riesgo  desarrollado en la clase siguiente  Desarrollo centrado en el humano  Bases Teoría de sistemas  Qué es un sistema?  Evolución de los sistemas Ingeniería de sistema  Ciclos de desarrollo

14 © RB UNPSJB - 2005Ingeniería de Software - Clase 114 Contenido Clase 1 Matemática y Lógica Ciencia de la computación Ciencias Sociales Ciencias Cognitivas Filosofía Visión general de estos conceptos

15 © RB UNPSJB - 2005Ingeniería de Software - Clase 115 Entendemos un problema o creemos que lo entendemos  Tomemos el siguiente juego 1. Nos dictan un dibujo, tratar de hacerlo, tenga en cuenta que no se repetirá el enunciado!!!!!!! 2. Repasemos el dibujo obtenido, lo modificamos 3. Y el dibujo era!!!!

16 © RB UNPSJB - 2005Ingeniería de Software - Clase 116 Qué vemos?????  Analizar cuidadosamente estos gráficos, que vemos?????

17 © RB UNPSJB - 2005Ingeniería de Software - Clase 117 Que vemos????  Sigamos, juguemos un rato

18 © RB UNPSJB - 2005Ingeniería de Software - Clase 118 Que vemos????  Sigamos

19 © RB UNPSJB - 2005Ingeniería de Software - Clase 119 Una quimera

20 © RB UNPSJB - 2005Ingeniería de Software - Clase 120 Importancia de la IR  Problemas Incrementa la dependencia sobre el software El soft es ahora el mayor elemento de costo de sistemas de misión crítica  Ej software de aviones, centrales nucleares, etc.  Aún para soft de negocios su desarrollo puede ser crítico Gran desperdicio producido por fallos en proyectos Altas y graves consecuencias en casos de fallos  Cohetes francés

21 © RB UNPSJB - 2005Ingeniería de Software - Clase 121 Importancia de la IR  Factores claves Certificación de costos  Pérdidas producidas durante el testeo, por errores latentes Rehacer gran cantidad de trabajo  remoción de defectos Cambios en los requerimientos  Por parte del usuario / cliente.

22 © RB UNPSJB - 2005Ingeniería de Software - Clase 122 Soluciones  No existe la “bala de plata” El soft es complejo por su tamaño El soft es invisible y abstracto El soft no se fabrica,  se hace  Análisis y modelado temprano es importante Los defectos se remueven en forma más barata  Modelado y análisis temprano no es suficiente Se necesita comunicar los requerimientos a todos Se necesitan congeniar múltiples agentes involucrados Se necesitan entender el contexto del sistema

23 © RB UNPSJB - 2005Ingeniería de Software - Clase 123 Soluciones Se necesita entender el contexto del proceso de desarrollo Se necesita mantener la fecha de evolución de los requerimientos

24 © RB UNPSJB - 2005Ingeniería de Software - Clase 124 Visión de la IS  Pasos Análisis Diseño Construcción Verificación Gestión  Preguntas Cual es el problema a resolver? Cuales son las características de los usuarios del sistema a construir? Como se construirá la solución? Como se contemplarán los errores? Como se apoyarán a los usuarios del sistema? Originalmente  separar el que del como, este concepto ya no se analiza igual Importante para IR

25 © RB UNPSJB - 2005Ingeniería de Software - Clase 125 Requerimientos e IS  Visión general de los componentes del desarrollo del soft  IS proceso que consiste de múltiples actividades  Características del desarrollo de soft El proceso de desarrollo del soft involucra generar diferentes modelos Puede verse como una serie de pasos Los pasos son objetivos conducidos y pueden verse como transiciones entre representaciones

26 © RB UNPSJB - 2005Ingeniería de Software - Clase 126 Definiciones  Que es un requerimiento? IEEE: una condición o capacidad que debe se encontrada por un sistema o componente del mismo para satisfacer un contrato, estándar, especificación u otra formalidad impuesta en un documento. El conjunto de todos los requerimientos forman la base para el desarrollo ded un sistema de soft.  Qué es la IR? La IR es la parte de la ingeniería de sistema concentrada en las metas del mundo real. La IR se concentra también en la relación entre los factores (metas) y la especificaciones precisas del comportamiento del sistema y su evolución a lo largo del tiempo (Zave94)

27 © RB UNPSJB - 2005Ingeniería de Software - Clase 127 Definiciones IR se concentra en la identificación del propósito de un sistema de software y el contexto en el cual el mismo se utiliza. IR actúa como el puente entre las necesidades del mundo real de usuarios, clientes y otros elementos afectados por el sistema de software y las capacidades y oportunidades alcanzadas por las tecnologías del soft. La IR es el proceso de descubrir el propósito, identificando los aspectos de interés y sus necesidades y documentando esto en forma amena para analizar, comunicar y posteriormente implementar. la definición de requerimientos es una valoración clara de las necesidades que un sistema debe alcanzar. Debe decir que necesita el sistema, basado en condiciones corrientes y previsibles. Debe decir que rasgos del sistema servirán para satisfacer el contexto del mismo. Además debe decir como el sistema debe ser construido.

28 © RB UNPSJB - 2005Ingeniería de Software - Clase 128 Importancia de los requerimientos  El argumento de Ingeniero El ingeniero debe desarrollar soluciones a problemas Una buena solución puede solo ser desarrollada si el ingeniero tiene un buen entendimiento del problema  El argumento económico Los costos de errores aumentan si pasa más tiempo sin detectarlos  Argumento empírico Los errores latentes de entender y manejar requerimientos son la mayor causa de exceso de costos  Argumento de seguridad Los mayores riesgo de seguridad están centrado en requerimientos inadecuados o mal entendidos

29 © RB UNPSJB - 2005Ingeniería de Software - Clase 129 Puntos de vista de requerimientos  Dos puntos de vista Manejados por el mercado Especificados por el cliente Determinado por el mercado Especificado por el cliente Requerimientos pequeños e informalesRequerimientos voluminosos y más formales Usar técnicas lejanas de ISUsa técnicas de IS La especificación se logra como marketing Especificación a través de documentación No se identifica un clienteSe tiene una idea del dominio del problema Muy informal su estructuraciónLa estructuración tiene políticas definidas

30 © RB UNPSJB - 2005Ingeniería de Software - Clase 130 Puntos de vista de requerimientos  Organizaciones  necesitan Definir en forma clara el propósito del negocio definir una visión a la que se apunta  metas. Alinear estrategias corporativas y el desarrollo de sistema de información  Requerimientos específicos  apuntan Administrar el cambio Integrar vistas de la empresa Relacionar los sistemas de información con estrategias de negocio

31 © RB UNPSJB - 2005Ingeniería de Software - Clase 131 IR vs. Análisis de sistemas  IR va más allá del análisis de sistemas El análisis de sistemas se centra en sistemas de información dentro de una organización Ha desarrollado notaciones informales, herramientas y metodologías  DFD, ER, diagramas OO Ampliamente utilizado  IR Acompaña la formalización entera del problema  Desde las necesidades de negocio hasta la especificación precisa Expande el alcance más allá de los sistemas de información  Sistemas de TR por ej.

32 © RB UNPSJB - 2005Ingeniería de Software - Clase 132 Modelos de desarrollo de soft  Modelo en cascada Enfoque sistemático y secuencial del desarrollo Problemas  Toma una visión estática de los requerimientos ignorando la volatilidad  Poca participación de usuario una vez que la especificación es obtenida  Separación poco realista de la especificación contra el diseño  No hay lugar para prototipos, reuso, etc  El sistema está listo muy al final.

33 © RB UNPSJB - 2005Ingeniería de Software - Clase 133 Modelos de desarrollo de soft  Prototipación Beneficios  Entiende los requerimientos para la interfaz de usuario  Examina la veracidad del diseño propuesto  Explora características de performance del sistema Problemas  Los usuarios ven al prototipo como solución  Los prototipos solo obtienen especificación parcial Tipos de prototipos  Evolucionables  desechables

34 © RB UNPSJB - 2005Ingeniería de Software - Clase 134 Modelos de desarrollo de soft  Modelo en espiral Dos versiones

35 © RB UNPSJB - 2005Ingeniería de Software - Clase 135 Modelos de desarrollo de soft Modelo en espiral  modelo orientado al análisis de riesgo Cuatro ciclos básicos  Proyecto de desarrollo de conceptos  Proyecto de desarrollo de producto nuevo  Proyecto de mejora de producto  Proyecto de mantenimiento de productos En cada iteración o ciclo:  Se planea la siguiente fase  Se determinan objetivos y limitaciones  Se evalúan alternativas  Se resuelven casos de riesgo  Se desarrolla el producto Qué diferencias encuentra entre las dos alternativas? Qué incluye  Análisis de riesgo de requerimientos (usando prototipos y simulación  Planificación de diseño Problemas  Convencer que el enfoque evolutivo es controlable  Si se escapa del análisis un riesgo puede traer problemas

36 © RB UNPSJB - 2005Ingeniería de Software - Clase 136 Modelos de desarrollo de soft  Modelo V

37 © RB UNPSJB - 2005Ingeniería de Software - Clase 137 Lo escencial en el proceso de Req.  Entender el problema Tomar requerimientos, comprenderlos, etc.  Formalmente describir el problema Especificar, modelar, etc.  Confrontar el problema con la realidad Validar, solucionar conflictos, negociar Adminitrar los requerimientos

38 © RB UNPSJB - 2005Ingeniería de Software - Clase 138 Verificación y validación  Para V y V se necesita tener en cuenta Las propiedades del hardware (C) Las propiedades del programa (P) Las propiedades del dominio del problema (D) Los requerimientos (R) La especificación (S) [propiedades de la máquina en el dominio de aplicación]  Se debe demostrar que P satisface R  proceso de dos pasos P y C implican S? (verificación) S y D implican R? (validación) Dominio de la aplicación Dominio de la máquina Intersección Dominio de la aplicación Dominio de la máquina Intersección

39 © RB UNPSJB - 2005Ingeniería de Software - Clase 139 Tipos de dominios de problema  Diseño normal o revolucionario Normal  problemas clásicos, soluciones conocidas  Existen estándares suficientemente probados  El Ingeniero elige el método más apropiado o el que considera más apropiado Revolucionario  nunca fue hecho o se hizo anteriormente mal  Muchos problemas de riesgos  conviene hacer???  Tipos de software Estáticos o dinámicos  Tenemos toda la información a priori o se adquiere durante el proceso Secuencial o paralelo  En que se complica?? Determinístico o no determinístico? Complejidad de  Datos  Control  algoritmo

40 © RB UNPSJB - 2005Ingeniería de Software - Clase 140 Tipos de proyectos  Fuente de requerimientos Para cliente  un problema una solución Para mercado  un mercado una solución Híbrido  Naturaleza del producto A medida o un paquete Sistema simple o familia (office) Sistema nuevo o evolución de uno existente

41 © RB UNPSJB - 2005Ingeniería de Software - Clase 141 Tipos de software  Sistemas de información Soft para soporte de trabajo organizacional Incluye aplicaciones de BD Lenguajes ???  Sistemas de TR  Sistemas empotrados Donde aparecen?? Qué características básicas tienen??  Sistemas para uso masivo Se pueden considerar como el primer grupo?? Office por ej.  Sistemas genéricos Sistemas que proveen servicio genérico  aplicaciones de internet por ej. Sistemas desarrollados en JAVA, HTML, Etc.

42 © RB UNPSJB - 2005Ingeniería de Software - Clase 142 Gestión del proyecto  Espectro de la gestión Personal   parte de personal tomará los requerimientos del problema  Es muy importante decidir la forma de trabajo Problema  Objetivo y Ámbito  Toma de requerimientos Proceso  Involucra el proceso de desarrollo  no es nuestro objetivo (como parte del curso)  estructura de plan detallado de desarrollo Actividades estructurales (aplicables a todos los proyectos) Conjunto de tareas (hitos, entregas, etc.) para cada proyecto particular Actividades protectoras (garantía, gestión de configuración

43 © RB UNPSJB - 2005Ingeniería de Software - Clase 143 Gestión del proyecto  Personal Participantes  Gestores supervisores (aspecto de negocios)  Gestores de proyectos (planificar, motivar y controlar el personal)  Profesionales (hacen el desarrollo)  Clientes  Usuarios finales Jefes de equipo  Profesionales que hacen el control directo. Actividades MOI: Motivación Organización (modelar procesos existentes) Ideas o innovación  Otras actividades Resolución del problema Dotes de gestión Incentivo de los logros Influencia y construcción de equipo

44 © RB UNPSJB - 2005Ingeniería de Software - Clase 144 Gestión del proyecto Equipos de software  Tres posibilidades Cada personal tiene tareas independientes  coordinador gestor Hay equipos informales  existe un líder coordinador entre equipos Equipos formales  tareas funcionales a cargo  Coordinación por equipo o general  Organigrama de equipos Descentralizado democrático (DD)  Sin jefe permanente, decisiones por consenso) Descentralizado controlado (DC)  Jefe coordinador y jefes secundarios  Actividades de grupo, comunicación horizontal Centralizado controlado (CC)  Jefe encargado de resolución de problemasde alto nivel y coordinación  Comunicación vertical

45 © RB UNPSJB - 2005Ingeniería de Software - Clase 145 Gestión del proyecto  Siete factores que inciden Dificultad  Alta (DD) Baja (DC, CC) Tamaño  Grande (DC,CC) Chica (DD) Duración del equipo  Corto (DC, CC) Grande (DD) en un proyecto Modularidad  Alta (DC, CC)Baja (DD) Fiabilidad  Alta (DD, CC)Baja (DC) Fecha de Entrega  Estricta (CC) Flexible (DD, DC) Comunicación  Alta (DD)Baja (DC, CC)

46 © RB UNPSJB - 2005Ingeniería de Software - Clase 146 Gestión del proyecto  Cuatro paradigmas Cerrado  Jerarquía de autoridades  Menos innovadores, más clásicos Aleatorio  Equipo libre, iniciativa individual  Mucha innovación, menos orden de organización Abierto  Genera punto intermedio entre anteriores  Trabajo colaborativo  Buena comunicación, decisiones se toman por consenso Sincronizado  Compartimentación del problema  Poca comuncación

47 © RB UNPSJB - 2005Ingeniería de Software - Clase 147 Las tres dimensiones de la IR

48 © RB UNPSJB - 2005Ingeniería de Software - Clase 148 Procesos, métodos,técnicas...  Una notación es un lenguaje de representación para una expresión. Ej. Lógica de primer órden, UML  Una técnica identifica como hacer una actividad particular, y, eventualmente, describe el producto de esa actividad con una notación particular. Ej DFD  Un método provee una descripción técnica para llevar a cabo un conjunto de actividades  Un modelo de proceso es una descripción abstracta de cómo llevar a cabo una colección de actividades, poniendo énfasis en el uso de recursos y dependencias entre actividades.  Un proceso es una instancia del modelo de proceso anterior, que describe el comportamiento para uno o más agentes y el manejo de recursos por parte de los mismos

49 © RB UNPSJB - 2005Ingeniería de Software - Clase 149 Qué vs. Cómo  Históricamente Requerimiento especificaba que sin decir como.  Pero, de esta forma, no es fácil distinguir Que hace.....? Alcanza para definirlo  El como en un nivel de abstracción forma el que del siguiente nivel.  Jackson provee una distinción El que se refiere al propósito del sistema  Es externo al sistema  Es una propiedad del dominio de aplicación El como se refiere a la estructura del sistema y al comportamiento  Es interno al sistema  Es una propiedad del dominio de la máquina

50 © RB UNPSJB - 2005Ingeniería de Software - Clase 150 Requerimientos   Ambiente  Algunas definiciones que se encuentran en la bibliografía Máquina  Es el sistema de soft que se debe desarrollar  El hard es parte de la máquina, desde el punto de vista que sirve para ejecutar el soft Dominio de aplicación  Una máquina interactúa con su ambiente  Una máquina se construye para servir un propósito en el mundo  Los aspectos del ambiente que define el propósito de la máquina es el dominio de aplicación  El dominio de aplicación es usualmente parte de la actividad humana

51 © RB UNPSJB - 2005Ingeniería de Software - Clase 151 IR   Descripción  La IR trata sobre descripción de elementos que conforman el problema Una designación  Selecciona un fenómeno de interés Dice como reconocerlo Le da un nombre  Es informal  Ej: Madre(z,y) de nota que y es la madre de z  Notar el tipo de representación!!

52 © RB UNPSJB - 2005Ingeniería de Software - Clase 152 IR   Descripción Una definición  Entrega una definición formal de un término que puede ser utilizado en otras descripciones Las definiciones pueden o no ser útiles, pero no se pude hablar de bien o mal.  Ej: Hijo(x,y) es definido como madre(y,x) o padre(y,x) Descripción refutable  Establece una propiedad del dominio que podría, en principio ser refutada Puede o no ser práctico hacer la refutación pero es viable  Ej: Para todo Z y X. Madre(x,z) implica ~ madre(z,x)

53 © RB UNPSJB - 2005Ingeniería de Software - Clase 153 IR   Descripción Dibujo de borrador  Descripción tentativa de lo que se va a desarrollar Puede contener términos no definidos  Ej: “ cada uno de nosotros pertenece solo a una familia”

54 © RB UNPSJB - 2005Ingeniería de Software - Clase 154 Requerimientos  optativos  Tradicionalmente, un requerimiento incluye la palabra “podría” o “debería” Se debe aclarar (por contrato) que siempre se habla en potencial Veamos un ejemplo en ingles  I shall drown. No one will save me. (pedido de ayuda) Me ahogaré. Nadie podrá salvarme.  I will drown. No one shall save me. (determinación de suicidio )  Discutamos, y encontremos en castellano el equivalente

55 © RB UNPSJB - 2005Ingeniería de Software - Clase 155 Requerimientos  optativos  El modo de los verbos Indicativo: establece un hecho (gana Boca) Interrogativo: pregunta (gana Boca?) Imperativo: establece una orden (Boca, ganá!!!) Subjuntivo: establece una posibilidad (puede que gane Boca) Optativo: expresa un deseo (podría ganar Boca)  Para IR Se debe utilizar el modo indicativo para propiedades del dominio El modo optativo es el adecuado para requerimientos No se deben mezclar modos en la misma descripción Es posible cambiar los modos a medida que se evoluciona.

56 © RB UNPSJB - 2005Ingeniería de Software - Clase 156 IR  involucra modelado  Tres tipos de modelo Analítico  ej. modelos matemáticos Analógico  ej modelo a escala del problema Icónico  ej una maqueta.  Un modelo es más que una descripción Describe un fenómeno del mundo real y las relaciones entre el fenómeno El modelo nunca es perfecto  Puede haber fenómenos en el modelo que no estén presentes en el dominio de aplicación (quedan fuera de él)

57 © RB UNPSJB - 2005Ingeniería de Software - Clase 157 IR  involucra modelado  Puede haber un fenómeno en el dominio de aplicación que no esté en el modelo

58 © RB UNPSJB - 2005Ingeniería de Software - Clase 158 Qué es un sistema?  Es una parte actual o visible de la realidad que puede ser observada o que interactúa con su ambiente Ej:  Autos, ciudades, edificios, etc.  SO, DBMS, internet, una organización Que cosa no son sistemas  Números, letras Hay sistemas cerrados que no interactúan con su ambiente Ej???  Existe realmente un sistema cerrado???

59 © RB UNPSJB - 2005Ingeniería de Software - Clase 159 Tipos de sistemas  Sistemas naturales Tiempo, cuerpo humano, un panal de abejas  Sistemas abstractos Ecuaciones matemáticas, programas de computadora, etc.  Sistemas designados Autos, aviones, edificios, rutas, internet  Sistemas de actividad humana Clubs, mercados, bolsa de comercio  Un sistema puede ser Soft  de difícil representación, sistemas poco precisos Hard  el sistema es preciso, bien definido y cuantificable

60 © RB UNPSJB - 2005Ingeniería de Software - Clase 160 Límites de un sistema  El ambiente de un sistema Es parte del mundo con el que interactúa  Cada sistema tiene su ambiente  El ambiente en si mismo es un sistema Ej: el sistema es para una organización, la cual en si es otro sistema La distinción entre sistema y ambiente depende del punto de vista de cada uno Los límites de un sistema es el conjunto de todas las posibles interacciones entre el sistema y el ambiente

61 © RB UNPSJB - 2005Ingeniería de Software - Clase 161 Límites de un sistema  La elección de los límites Se debe elegir el límite que maximice la modularidad Características  Excluir cosas que no tengan efectos funcionales en el sistema  Excluir cosas que influyan en el sistema pero que no puedan ser influenciadas o controladas por él.  Incluir cosas que sean fuertemente controladas o influenciadas por el sistema Elegir los límites que  Incrementen la regularidad en el comportamiento del sistema  Simplifique el comportamiento del sistema

62 © RB UNPSJB - 2005Ingeniería de Software - Clase 162 Estructura de un sistema  Subsistema Un sistema se organiza como una colección de subsistemas que actúan como un todo Los límites de un subsistema debe elegirse de manra que los mismos sean modulares  Visibilidad La interaccion entre subsistemas son internas al sistema Interacciones entre los subsistemas y el ambinete son externas Se intenta ocultar las interacciones internas

63 © RB UNPSJB - 2005Ingeniería de Software - Clase 163 Estados y Propiedades de un sistema  Estado El estado de un sistema es la memora de acciones pasadas del mismo El espacio de estados de un sistema es la colección de todos los posibles estados.  Una propiedad Es un aspecto del comportamiento del sistema  normalmente se refiere a ellos como atributo Una propiedad es especificada por su comportamiento.

64 © RB UNPSJB - 2005Ingeniería de Software - Clase 164 Taxonomía de sistemas  Clases de aplicaciones o sistemas informáticos Cinco ejes ortogonales  Dificultad del problema  Relaciones entre datos y proceso  Número de tareas simultáneas para llevar a cabo  Dificultad relativa de aspectos del problema como: datos, control y algoritmos  Determinismo vs. No determinismo

65 © RB UNPSJB - 2005Ingeniería de Software - Clase 165 Taxonomía de sistemas Dificultad del problema  Difíciles (HA) Llevar a alguien de La Rioja a Japón en dos horas, sistematizar toda actividad humana con computadoras  No difíciles (NH) Comunicación telefónica, tener un editor de texto interactivo a distancia Relaciones de tiempo...  Estático (ST) Sistema de sueldos  Dinámico (DY) Monitoreo de pacientes, reactor nuclear número de tareas  Secuencial (SE) Juegos, compilación  Paralelo (PA) Control de procesos, monitoreo de alarmas Aplicaciones en tres dominios  Datos (DA) Ppal. Proceso de especificación de requerimientos (descripción, organización)  Control (CO) Definición y descripción del ambiente, aplicaciones restrictivas de tiempo  Algoritmo (AL) Transformaciones de funciones entre las entradas y las salidas

66 © RB UNPSJB - 2005Ingeniería de Software - Clase 166 Taxonomía de sistemas Deter. No determ  Determinísticos (DE) Control de inventario, compilación, edición  No Determinístico (ND) Las respuestas del sistema no son bien entendidas Ej. Juego de ajedrez IA.

67 © RB UNPSJB - 2005Ingeniería de Software - Clase 167 Resumiendo  La IR es la rama de la IS concentrada con los objetivos del mundo real para un sistema (problema), que tiene en cuenta sus funciones y sus limitaciones. También se centra en las relaciones de los factores de influencia para precisar la especificación del comportamiento del soft y su evolución a lo largo de tiempo.

68 © RB UNPSJB - 2005Ingeniería de Software - Clase 168 Resumiendo  IR  actividad humana, trabaja sobre Ciencia cognitiva: psicología cognitiva provee un entendimiento de las dificultades personales que se pueden tener para describir necesidades Antropología: aproximación metodológica para observar actividades humanas y comprenderlas mejor. Sociología: entender el contexto de la sociedad y los cambios culturales causados (en particular por las computadoras y su uso) Lingüística: por un problema de comunicaciones entre personas

69 © RB UNPSJB - 2005Ingeniería de Software - Clase 169 Un avance de lo que veremos  La IR consta de etapas Tomar requerimientos  Encontrar las necesidades del problema, y como derivar desde aquí los límites del sistema.  Identificar aspectos de interés y los casos de uso  Individualizar los actores involucrados  Describir las metas que denotan los objetivos del sistema. Modelar y analizar requerimientos  Modelar consiste en la construcción de una descripción abstracta que sea fácil de interpretar.

70 © RB UNPSJB - 2005Ingeniería de Software - Clase 170 Un avance de lo que veremos  El modelo abarca De la empresa Datos Comportamiento Dominio Requerimientos no funcionales Comunicación de requerimientos  Trazabilidad de los mismos  Compartir los requerimientos con todos Aceptar requerimientos  Tarea compleja  inspecciones, análisis formal, estudio de coherencia y consistencia

71 © RB UNPSJB - 2005Ingeniería de Software - Clase 171 Un avance de lo que veremos  Complejidad de la validación La naturaleza filosófica. La prueba de campo sirve para refutar una idea no para afianzarla Razón social: posibles desacuerdos entre actores involucrados. Evolución de requerimientos  El sistema de soft evoluciona, los requerimientos cambian  El cambio es una actividad principal en la IR.  La administración de los cambios es una necesidad

72 © RB UNPSJB - 2005Ingeniería de Software - Clase 172 Material para la próxima  Leer el paper c  Buscar los siguientes papers Engineering Requeriment a Roadmap Engineering Requeriment in year 2000 The Four dark corners in Engineering Requeriment  Están todos en el material del 2003.