Ingeniería de Software 2005 Ingeniería de Requerimientos Análisis de Riesgo UML Costeo Calidad...

Ingeniería de Software 2005

Ingeniería de RequerimientosAnálisis de Riesgo

UMLCosteoCalidad

Mg. Rodolfo [email protected]

UNPSJB – Sede Comodoro RivadaviaUNPSJB – Sede Comodoro Rivadavia

UNPSJB - 2005 Ingeniería de Software - Clase 1 2

© 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


© 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


© RB

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


© 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, 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)


© 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?


© RB

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


© RB

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


© RB

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.


© RB

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)

IS conceptos básicosIntroducción a la Ingeniería de

RequerimientosClase 1

Un Juego Introducción – Bases de IR


© 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. Sistemas embebidos Procesos, métodos y técnicas

Desarrollo de producto y proceso


© 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


© 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

Visión general de estos conceptos


© RBEntendemos un problema o creemos que lo entendemos

Tomemos el siguiente juego1. 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!!!!


© RB

Qué vemos?????

Analizar cuidadosamente estos gráficos, que vemos?????


© RB

Que vemos????

Sigamos, juguemos un rato


© RB

Que vemos????

Sigamos


© RB

Una quimera


© 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, 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


© RB

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.


© 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, 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


© 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

1

10

100

1000

Rquerimientos Diseño codigo prueba unidad prueba de sistema sistema operando

Co

sto

de

co

rre

gir

err

or


© RB

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 IRImportante para IR


© 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

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

Implementación

Diseño detallado

Diseño arquitectónico

Esp. del sistemaEspecificación de

requerimiento


© 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, 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)


© 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. 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.


© RB

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


© RB

Puntos de vista de requerimientos

Dos puntos de vista Manejados por el mercado Especificados por el cliente

Determinado por el mercadoDeterminado por el mercado Especificado por el clienteEspecificado por el cliente

Requerimientos pequeños e informales Requerimientos voluminosos y más formales

Usar técnicas lejanas de IS Usa técnicas de IS

La especificación se logra como marketing

Especificación a través de documentación

No se identifica un cliente Se tiene una idea del dominio del problema

Muy informal su estructuración La estructuración tiene políticas definidas


© 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. 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


© RB

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.


© RB

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.

percepción deuna necesidad

integración

testeo

codificación

diseño

requerimientos


© RB


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

requeri-miento

testeo deprototipo

construcción de

prototipo

diseñode

prototipo

documento derequeriementos

testeocodificacióndiseño integración


© RB


Modelo en espiral Dos versiones

Determinar metas,alternativas ylimitaciones

Evaluar alternativasde riesgo

Desarrollo y testPlan

Planificación

Comunicacióncon elcliente

Análisis deriesgo

Ingeniería

configuracióny adaptación

Evaluación delcliente

Cuatro ciclos


© RB


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


© RB


Modelo VRequerimientos

del sistema

Test eintegración

Análisis ydiseño

integración delsistema

preuba deaceptación

Integración delsoftware

prueba decomponentes

prueba deunidad

Codificación yverificación

DiseñoDetallado

Diseñopreliminar

Requerimientosdel software

Niv

el d

e ab

stra

cció

n

Tiempo


© RB

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

Mundo Real

Problema

Implementación

Sistema

Cor

resp

onde

ncia

Cor

rect

itud

Verif

icac

ión

Valid

ació

n


© RB

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


© RB

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


© RB

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


© RB

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.


© 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, entregas, etc.) para cada proyecto particular

Actividades protectoras (garantía, gestión de configuración


© RB


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


© RB


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


© RB


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)


© RB


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


© RB

Las tres dimensiones de la IR

Representación

Aceptacion

Especificación

Informal

Vistacomún

vistapersonal

Completa

cercana

Vaga

FormalSemiformal


© RB

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


© RB

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

Requeri-miento

Requeri-miento

Requeri-miento

Diseño

Diseño

DiseñoUnidad

Qué

Sistema

Sub-Sistema

Qué

Cómo

Qué

Cómo

Cómo


© 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


© 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,y) de nota que y es la madre de z Notar el tipo de representación!!


© 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, 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)


© 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”


© RB

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


© RB

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.


© RB

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)


© RB

IR involucra modelado

Puede haber un fenómeno en el dominio de aplicación que no esté en el modelo

El mundoDominio deaplicación

Propiedadessolo

verdaderasen el dominiode modelado

Descripcióncompartida

Propiedades soloverdaderas en eldominio deaplicación

Dominiode

modelado

Designaciones


© 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, 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???


© RB

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


© 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, 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


© 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.

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


© 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 Visibilidad

La interaccion entre subsistemas son internas al sistema

Interacciones entre los subsistemas y el ambinete son externas

Se intenta ocultar las interacciones internas


© RBEstados 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.


© 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, control y algoritmos

Determinismo vs. No determinismo


© RB


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


© RB


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.


© RB

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.


© RB

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


© 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.

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.


© RB


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


© RB


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


© 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.

Ingeniería de Software 2005 Ingeniería de Requerimientos Análisis de Riesgo UML Costeo Calidad...

Documents

Transcript of Ingeniería de Software 2005 Ingeniería de Requerimientos Análisis de Riesgo UML Costeo Calidad...