Ingeniería de Software 2005 Ingeniería de Requerimientos Análisis de Riesgo UML Costeo Calidad Mg. Rodolfo Bertone [email protected] UNPSJB – Sede Comodoro Rivadavia UNPSJB – Sede Comodoro Rivadavia
Apr 21, 2015
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
UNPSJB - 2005 Ingeniería de Software - Clase 1 3
© 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 4
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 5
© 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)
UNPSJB - 2005 Ingeniería de Software - Clase 1 6
© 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 - 2005 Ingeniería de Software - Clase 1 7
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 8
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 9
© 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.
UNPSJB - 2005 Ingeniería de Software - Clase 1 10
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 12
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 13
© 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 14
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 15
© 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!!!!
UNPSJB - 2005 Ingeniería de Software - Clase 1 16
© RB
Qué vemos?????
Analizar cuidadosamente estos gráficos, que vemos?????
UNPSJB - 2005 Ingeniería de Software - Clase 1 17
© RB
Que vemos????
Sigamos, juguemos un rato
UNPSJB - 2005 Ingeniería de Software - Clase 1 18
© RB
Que vemos????
Sigamos
UNPSJB - 2005 Ingeniería de Software - Clase 1 19
© RB
Una quimera
UNPSJB - 2005 Ingeniería de Software - Clase 1 20
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 21
© 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.
UNPSJB - 2005 Ingeniería de Software - Clase 1 22
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 23
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 24
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 25
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 26
© 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)
UNPSJB - 2005 Ingeniería de Software - Clase 1 27
© 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.
UNPSJB - 2005 Ingeniería de Software - Clase 1 28
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 29
© 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
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. 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 31
© 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.
UNPSJB - 2005 Ingeniería de Software - Clase 1 32
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 33
© RB
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
requeri-miento
testeo deprototipo
construcción de
prototipo
diseñode
prototipo
documento derequeriementos
testeocodificacióndiseño integración
UNPSJB - 2005 Ingeniería de Software - Clase 1 34
© RB
Modelos de desarrollo de soft
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
UNPSJB - 2005 Ingeniería de Software - Clase 1 35
© RB
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
UNPSJB - 2005 Ingeniería de Software - Clase 1 36
© RB
Modelos de desarrollo de soft
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
UNPSJB - 2005 Ingeniería de Software - Clase 1 37
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 38
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 39
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 40
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 41
© 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.
UNPSJB - 2005 Ingeniería de Software - Clase 1 42
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 43
© RB
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
UNPSJB - 2005 Ingeniería de Software - Clase 1 44
© RB
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
UNPSJB - 2005 Ingeniería de Software - Clase 1 45
© RB
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)
UNPSJB - 2005 Ingeniería de Software - Clase 1 46
© RB
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
UNPSJB - 2005 Ingeniería de Software - Clase 1 47
© RB
Las tres dimensiones de la IR
Representación
Aceptacion
Especificación
Informal
Vistacomún
vistapersonal
Completa
cercana
Vaga
FormalSemiformal
UNPSJB - 2005 Ingeniería de Software - Clase 1 48
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 49
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 50
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 51
© 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!!
UNPSJB - 2005 Ingeniería de Software - Clase 1 52
© 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)
UNPSJB - 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 - 2005 Ingeniería de Software - Clase 1 54
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 55
© 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.
UNPSJB - 2005 Ingeniería de Software - Clase 1 56
© 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)
UNPSJB - 2005 Ingeniería de Software - Clase 1 57
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 58
© 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???
UNPSJB - 2005 Ingeniería de Software - Clase 1 59
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 60
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 61
© 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
UNPSJB - 2005 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 Visibilidad
La interaccion entre subsistemas son internas al sistema
Interacciones entre los subsistemas y el ambinete son externas
Se intenta ocultar las interacciones internas
UNPSJB - 2005 Ingeniería de Software - Clase 1 63
© 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.
UNPSJB - 2005 Ingeniería de Software - Clase 1 64
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 65
© RB
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
UNPSJB - 2005 Ingeniería de Software - Clase 1 66
© RB
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.
UNPSJB - 2005 Ingeniería de Software - Clase 1 67
© 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.
UNPSJB - 2005 Ingeniería de Software - Clase 1 68
© 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
UNPSJB - 2005 Ingeniería de Software - Clase 1 69
© 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.
UNPSJB - 2005 Ingeniería de Software - Clase 1 70
© 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, análisis
formal, estudio de coherencia y consistencia
UNPSJB - 2005 Ingeniería de Software - Clase 1 71
© RB
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
UNPSJB - 2005 Ingeniería de Software - Clase 1 72
© 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.