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

© RB

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

UNPSJB - 2005

Ingeniería de Software - Clase 1

2

© RB

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

UNPSJB - 2005

Ingeniería de Software - Clase 1

3

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

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) UNPSJB .© RB 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.Clase 1 5 .2005 Ingeniería de Software .

© RB 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? UNPSJB .Clase 1 6 .2005 Ingeniería de Software .

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

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

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

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

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

Sistemas embebidos Procesos.Clase 1 12 UNPSJB .© RB 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.2005 . métodos y técnicas  Desarrollo de producto y proceso Ingeniería de Software .

© RB 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 UNPSJB .2005 Ingeniería de Software .Clase 1 13 .

© RB 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 UNPSJB .2005 Ingeniería de Software .Clase 1 14 .

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

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

© RB Que vemos????  Sigamos. juguemos un rato UNPSJB .Clase 1 17 .2005 Ingeniería de Software .

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

Clase 1 19 .© RB Una quimera UNPSJB .2005 Ingeniería de Software .

Clase 1 20 UNPSJB . centrales nucleares.2005 .  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 Ingeniería de Software . etc.© RB 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.

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

 se hace Los defectos se remueven en forma más barata  Análisis y modelado temprano es importante   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 UNPSJB .Clase 1 22 .2005 Ingeniería de Software .© RB 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.

© RB

Soluciones
 

Se necesita entender el contexto del proceso de desarrollo Se necesita mantener la fecha de evolución de los requerimientos
Costo Relativo de corregir un error
1000

Costo de corregir error

100

10

1

Rquerimientos

Diseño

codigo

prueba unidad

prueba de sistema

sistema operando

UNPSJB - 2005

Ingeniería de Software - Clase 1

23

© RB

Visión de la IS

Pasos
   

Análisis Diseño Construcción Verificación Gestión Cual es el problema a resolver? Cuales son las características de los usuarios del sistema a construir?

Preguntas
  

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

UNPSJB - 2005

Ingeniería de Software - Clase 1

24

© RB

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

Implementación Diseño detallado Diseño arquitectónico Especif icación de Esp. del sistema requerimiento

 

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
Ingeniería de Software - Clase 1

UNPSJB - 2005

25

Clase 1 26 . estándar. La IR es la parte de la ingeniería de sistema concentrada en las metas del mundo real. El conjunto de todos los requerimientos forman la base para el desarrollo ded un sistema de soft. especificación u otra formalidad impuesta en un documento.© RB 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.2005 Ingeniería de Software . 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)  Qué es la IR?  UNPSJB .

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

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

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

Alinear estrategias corporativas y el desarrollo de sistema de información Administrar el cambio Integrar vistas de la empresa Relacionar los sistemas de información con estrategias de negocio  Requerimientos específicos  apuntan    UNPSJB .2005 Ingeniería de Software .Clase 1 30 .© RB 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.

© RB IR vs. ER. diagramas OO Acompaña la formalización entera del problema   Expande el alcance más allá de los sistemas de información  Desde las necesidades de negocio hasta la especificación precisa Sistemas de TR por ej.Clase 1 31 . UNPSJB .2005 Ingeniería de Software . herramientas y metodologías    IR  Ampliamente utilizado DFD. 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.

Clase 1  Enfoque sistemático y secuencial del desarrollo Problemas percepción de una necesidad requerimientos diseño codificación testeo integración 32 . UNPSJB . etc  El sistema está listo muy al final.© RB Modelos de desarrollo de soft  Modelo en cascada   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.2005 Ingeniería de Software . reuso.

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

© RB Modelos de desarrollo de soft  Modelo en espiral  Cuatro ciclos Dos versiones Planificación Evaluar alternativas de riesgo Determinar metas.2005 Ingeniería de Software . alternativas y limitaciones Comunicación con el cliente Análisis de riesgo Ingeniería Evaluación del cliente Plan Desarrollo y test configuración y adaptación UNPSJB .Clase 1 34 .

Clase 1 .© RB Modelos de desarrollo de soft   Modelo en espiral  modelo orientado al análisis de riesgo Cuatro ciclos básicos     Se evalúan alternativas Se resuelven casos de riesgo Se desarrolla el producto    Proyecto de desarrollo de conceptos Proyecto de desarrollo de producto nuevo Proyecto de mejora de producto Proyecto de mantenimiento de productos Se planea la siguiente fase Se determinan objetivos y limitaciones   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 Convencer que el enfoque evolutivo es controlable Si se escapa del análisis un riesgo puede traer problemas 35  En cada iteración o ciclo:    Problemas   UNPSJB .2005 Ingeniería de Software .

Clase 1 36 .© RB Modelos de desarrollo de soft  Modelo V Requerimientos del sistema integración del sistema Nivel de abstracción Requerimientos del software preuba de aceptación Diseño preliminar Integración del software Análisis y diseño Diseño Detallado prueba de componentes Test e integración Codificación y verificación prueba de unidad Tiempo UNPSJB .2005 Ingeniería de Software .

negociar Adminitrar los requerimientos Sistema UNPSJB .2005 Ingeniería de Software .© RB Lo escencial en el proceso de Req. modelar. etc.  Confrontar el problema con la realidad   Implementación Validar. etc. comprenderlos. Correspondencia Verificación Correctitud  Formalmente describir el problema  Problema Especificar. solucionar conflictos.  Entender el problema  Mundo Real Validación 37 Tomar requerimientos.Clase 1 .

© RB Verificación y validación  Para V y V se necesita tener en cuenta      Dominio de la aplicación Las propiedades del hardware (C) Dominio de la máquina Las propiedades del programa (P) Las propiedades del dominio del problema (D) Intersección 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) UNPSJB .2005 Ingeniería de Software .Clase 1 38 .

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

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

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

) para cada proyecto particular Actividades protectoras (garantía.Clase 1 42 . gestión de configuración UNPSJB .© RB 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. etc.2005 Ingeniería de Software . entregas.

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 Resolución del problema Dotes de gestión Incentivo de los logros Influencia y construcción de equipo 43  Otras actividades     UNPSJB .© RB Gestión del proyecto  Personal  Participantes  Gestores supervisores (aspecto de negocios)  Gestores de proyectos (planificar.2005 Ingeniería de Software .Clase 1 .

© RB Gestión del proyecto  Equipos de software  Tres posibilidades   Organigrama de equipos    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   Descentralizado democrático (DD)  Sin jefe permanente. comunicación horizontal Centralizado controlado (CC)  Jefe encargado de resolución de problemasde alto nivel y coordinación  Comunicación vertical UNPSJB .2005 Ingeniería de Software . decisiones por consenso) Descentralizado controlado (DC)  Jefe coordinador y jefes secundarios  Actividades de grupo.Clase 1 44 .

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

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

© RB Las tres dimensiones de la IR Especificación Completa Aceptacion cercana Vaga vista personal Vista común Informal UNPSJB .Clase 1 .2005 Semi formal Formal Representación 47 Ingeniería de Software .

© RB Procesos. eventualmente.2005 . describe el producto de esa actividad con una notación particular..      Una notación es un lenguaje de representación para una expresión.Clase 1 48 UNPSJB . y. métodos. 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. que describe el comportamiento para uno o más agentes y el manejo de recursos por parte de los mismos Ingeniería de Software . UML Una técnica identifica como hacer una actividad particular.técnicas. Un proceso es una instancia del modelo de proceso anterior. Ej.. Lógica de primer órden. poniendo énfasis en el uso de recursos y dependencias entre actividades.

Clase 1 49 .? Alcanza para definirlo SubSistema forma Requerimiento Qué Cómo Diseño  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 Cómo Unidad Requerimiento Qué Diseño  El como se refiere a la estructura del sistema y al comportamiento   UNPSJB ... Que hace .. de esta forma.. no es fácil distinguir El como en un nivel de abstracción el que del siguiente nivel.2005 Es interno al sistema Es una propiedad del dominio de la máquina Cómo Diseño Ingeniería de Software . Cómo  Históricamente    Sistema Requerimiento Qué Requerimiento especificaba que sin decir como.© RB Qué vs.  Pero.

2005 .Clase 1 50 UNPSJB .© RB 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 Ingeniería de Software .

y) de nota que y es la madre de z  Notar el tipo de representación!! Ingeniería de Software .© RB 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.Clase 1 51 UNPSJB .2005 .

Madre(x.Clase 1 52  Ej:  UNPSJB . pero no se pude hablar de bien o mal.x)  Ej:   Descripción refutable  Establece una propiedad del dominio que podría.© RB 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. Hijo(x. en principio ser refutada  Puede o no ser práctico hacer la refutación pero es viable Para todo Z y X.z) implica ~ madre(z.x) Ingeniería de Software .2005 .x) o padre(y.y) es definido como madre(y.

2005 Ingeniería de Software .Clase 1 53 .© RB 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” UNPSJB .

© RB Requerimientos  optativos  Tradicionalmente.   I will drown. y encontremos en castellano el equivalente Ingeniería de Software .Clase 1 54 UNPSJB . Nadie podrá salvarme.2005 . No one shall save me. (determinación de suicidio) Discutamos. 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. (pedido de ayuda)  Me ahogaré. No one will save me.

© RB Requerimientos  optativos  El modo de los verbos      Indicativo: establece un hecho (gana Boca) Interrogativo: pregunta (gana Boca?) Imperativo: establece una orden (Boca.Clase 1 55  Para IR     UNPSJB . Ingeniería de Software . ganá!!!) Subjuntivo: establece una posibilidad (puede que gane Boca) Optativo: expresa un deseo (podría ganar Boca) 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.2005 .

2005 . modelos matemáticos Analógico  ej modelo a escala del problema Icónico  ej una maqueta. 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) Ingeniería de Software .© RB IR  involucra modelado  Tres tipos de modelo    Analítico  ej.Clase 1 56  Un modelo es más que una descripción   UNPSJB .

© RB IR  involucra modelado  Puede haber un fenómeno en el dominio de aplicación que no esté en el modelo El mundo Dominio de aplicación Dominio de mode lado Designaciones Propiedades solo verdaderas en el dominio de aplicación De scripción compartida Propiedades solo verdaderas en el dominio de modelado UNPSJB .Clase 1 57 .2005 Ingeniería de Software .

Clase 1 58 .  SO. DBMS. etc. edificios. letras Hay sistemas cerrados que no interactúan con su ambiente Ej???  Existe realmente un sistema cerrado???    UNPSJB . una organización Que cosa no son sistemas  Números. ciudades.2005 Ingeniería de Software . internet.© RB 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.

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

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 UNPSJB .© RB 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.2005 Ingeniería de Software .Clase 1 60 .

2005 .© RB 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.Clase 1 61 UNPSJB .  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 Ingeniería de Software .

Clase 1 62 .© RB 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 La interaccion entre subsistemas son internas al sistema Interacciones entre los subsistemas y el ambinete son externas Se intenta ocultar las interacciones internas  Visibilidad    UNPSJB .2005 Ingeniería de Software .

2005 Ingeniería de Software .© RB 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. Es un aspecto del comportamiento del sistema  normalmente se refiere a ellos como atributo Una propiedad es especificada por su comportamiento.Clase 1 63 .  Una propiedad   UNPSJB .

control y algoritmos  Determinismo vs.© RB 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.Clase 1 64 .2005 Ingeniería de Software . No determinismo  UNPSJB .

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

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

2005 .© RB Resumiendo  La IR es la rama de la IS concentrada con los objetivos del mundo real para un sistema (problema). Ingeniería de Software .Clase 1 67 UNPSJB . 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.

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 UNPSJB .2005 Ingeniería de Software . 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.© RB Resumiendo  IR  actividad humana.Clase 1 68 .

Ingeniería de Software .© RB 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.Clase 1 69 UNPSJB .  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.2005 .

análisis formal.Clase 1 70 .2005 Ingeniería de Software . estudio de coherencia y consistencia UNPSJB .© RB 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.

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

© RB 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. UNPSJB .Clase 1 72 .2005 Ingeniería de Software .

Sign up to vote on this title
UsefulNot useful