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
© RB
Glosario de Clase







UNPSJB - 2005
Objetivos del curso
Forma de trabajo
Contenido
Bibliografía
Jugando a entender un problema
Introducción a IR
Aproximación a IR
Ingeniería de Software - Clase 1
2
© RB
Objetivos del curso




UNPSJB - 2005
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
Ingeniería de Software - Clase 1
3
© 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
4
© RB
Forma de Trabajo

Aprobación



UNPSJB - 2005
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)
Ingeniería de Software - Clase 1
5
© RB
Contenido (1)

Algunos conceptos básicos de IS





Análisis de Riesgo
Ingeniería de Requerimientos

UNPSJB - 2005
Procesos de modelado
Dinámica de trabajo en grupos
JAD
Introducción a la IR
 Que es la IR?
 Por qué es importante?
Ingeniería de Software - Clase 1
6
© RB
Contenido (2)

Bases de la IR


Actividades básica de IR









UNPSJB - 2005
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
Ingeniería de Software - Clase 1
7
© RB
Bibliografía

Conjunto de libros, papers y materiales
de otros cursos



Algunos materiales

UNPSJB - 2005
Ningún libro se adpata en su totalidad a la
asignatura
El alumno deberá obtener, investigando la
información.
Libros
 Systems Requeriments Engineering.
Pericles Loucopoulos. Vassilios Karakosas.
McGraw Hill. Book Company. 1995
Ingeniería de Software - Clase 1
8
© 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
9
© 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)

UNPSJB - 2005
Ingeniería de Software - Clase 1
10
IS conceptos básicos
Introducción a la Ingeniería de
Requerimientos
Clase 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
UNPSJB - 2005
Ingeniería de Software - Clase 1
12
© 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

UNPSJB - 2005
Ciclos de desarrollo
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
Entendemos un problema o
creemos que lo entendemos

Tomemos el siguiente juego
1.
2.
3.
UNPSJB - 2005
© RB
Nos dictan un dibujo, tratar de
hacerlo, tenga en cuenta que no se
repetirá el enunciado!!!!!!!
Repasemos el dibujo obtenido, lo
modificamos
Y el dibujo era!!!!
Ingeniería de Software - Clase 1
15
© RB
Qué vemos?????

UNPSJB - 2005
Analizar cuidadosamente estos
gráficos, que vemos?????
Ingeniería de Software - Clase 1
16
© RB
Que vemos????

UNPSJB - 2005
Sigamos, juguemos un rato
Ingeniería de Software - Clase 1
17
© RB
Que vemos????

UNPSJB - 2005
Sigamos
Ingeniería de Software - Clase 1
18
© RB
Una quimera
UNPSJB - 2005
Ingeniería de Software - Clase 1
19
© RB
Importancia de la IR

Problemas




UNPSJB - 2005
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
Ingeniería de Software - Clase 1
20
© RB
Importancia de la IR

Factores claves

Certificación de costos



Rehacer gran cantidad de trabajo 
remoción de defectos
Cambios en los requerimientos

UNPSJB - 2005
Pérdidas producidas durante el testeo, por
errores latentes
Por parte del usuario / cliente.
Ingeniería de Software - Clase 1
21
© RB
Soluciones

No existe la “bala de plata”




Análisis y modelado temprano es importante


Los defectos se remueven en forma más barata
Modelado y análisis temprano no es
suficiente



UNPSJB - 2005
El soft es complejo por su tamaño
El soft es invisible y abstracto
El soft no se fabrica,  se hace
Se necesita comunicar los requerimientos a todos
Se necesitan congeniar múltiples agentes
involucrados
Se necesitan entender el contexto del sistema
Ingeniería de Software - Clase 1
22
© 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
Costo de corregir error
1000
100
10
1
Rquerimientos
UNPSJB - 2005
Diseño
codigo
prueba unidad
Ingeniería de Software - Clase 1
prueba de sistema
sistema operando
23
© 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 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



I m p le m e n t a c ió n
D is e ñ o d e t a lla d o
D is e ñ o a rq u it e c t ó n ic o
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
UNPSJB - 2005
Ingeniería de Software - Clase 1
E s p e c if ic a c ió n d e
E s p . d e l s is t e m a
re q u e rim ie n t o
25
© RB
Definiciones

Que es un requerimiento?


Qué es la IR?

UNPSJB - 2005
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.
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)
Ingeniería de Software - Clase 1
26
© 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
27
© RB
Importancia de los requerimientos

El argumento de Ingeniero



El argumento económico


Los errores latentes de entender y manejar
requerimientos son la mayor causa de exceso de
costos
Argumento de seguridad

UNPSJB - 2005
Los costos de errores aumentan si pasa más tiempo
sin detectarlos
Argumento empírico


El ingeniero debe desarrollar soluciones a
problemas
Una buena solución puede solo ser desarrollada si el
ingeniero tiene un buen entendimiento del
problema
Los mayores riesgo de seguridad están centrado en
requerimientos inadecuados o mal entendidos
Ingeniería de Software - Clase 1
28
© RB
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 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
29
© RB
Puntos de vista de requerimientos

Organizaciones  necesitan




Requerimientos específicos  apuntan



UNPSJB - 2005
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
Administrar el cambio
Integrar vistas de la empresa
Relacionar los sistemas de información con
estrategias de negocio
Ingeniería de Software - Clase 1
30
© 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



IR

Ampliamente utilizado
Acompaña la formalización entera del problema


UNPSJB - 2005
DFD, ER, diagramas OO
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.
Ingeniería de Software - Clase 1
31
© RB
Modelos de desarrollo de soft

Modelo en cascada


Enfoque sistemático y
secuencial del desarrollo
Problemas
pe rce pción de
una nec es id ad
re querim ientos
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.
UNPSJB - 2005
Ingeniería de Software - Clase 1

dise ño
c odifica ción
te steo
inte grac ión
32

© RB
Modelos de desarrollo de soft
Prototipación

Beneficios




requerim iento
diseño
de
prototipo
construc
ción de
prototipo
testeo de
prototipo
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
docum ento de
requeriem entos
diseño
codificación
testeo
integración
Tipos de prototipos

Evolucionables
desechables

UNPSJB - 2005
Ingeniería de Software - Clase 1
33
© RB
Modelos de desarrollo de soft

Modelo en espiral

C ua tro c ic los
Dos versiones
P la n ifica ció n
D eterm in ar m e ta s,
a ltern a tivas y
lim ita cio n es
E va lu ar a ltern a tivas
d e rie sg o
C o m u n ica ció n
co n e l
clie n te
A n á lisis d e
rie sg o
In g e n ie ría
E va lu a ció n d e l
clie n te
P la n
UNPSJB - 2005
D esa rro llo y test
Ingeniería de Software - Clase 1
co n fig u ra ció n
y a d a p ta ció n
34
© 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
UNPSJB - 2005





Qué diferencias encuentra
entre las dos alternativas?
Qué incluye



Se evalúan alternativas
Se resuelven casos de riesgo
Se desarrolla el producto
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
Ingeniería de Software - Clase 1
35
© RB
Modelos de desarrollo de soft

Modelo V
N iv e l d e a b s tr a c c ió n
R eq u e rim ie n to s
d e l sis tem a
in teg ra c ió n d e l
s is tem a
R eq u e rim ie n to s
d e l so ftw a re
p re u b a d e
a ce p ta ció n
D is e ñ o
p re lim in a r
A n á lisis y
d ise ñ o
In teg ra c ió n d e l
s o ftw are
D is e ñ o
D etalla d o
p ru e b a d e
c o m p o n e n te s
C o d ific a ció n y
v erific ac ió n
T e st e
in teg ra c ió n
p ru e b a d e
u n id a d
Tie m po
UNPSJB - 2005
Ingeniería de Software - Clase 1
36
© RB
Lo escencial en el proceso de Req.
Entender el problema


Especificar, modelar,
etc.
Confrontar el problema
con la realidad


Validar, solucionar
conflictos, negociar
Adminitrar los
requerimientos
UNPSJB - 2005
P ro b le m a
Im p le m e n ta c ió n
Ingeniería de Software - Clase 1
V a lid a c ió n
Formalmente describir
el problema
V e r if ic a c ió n

Tomar requerimientos,
comprenderlos, etc.
C o rre c titu d

M u n d o R eal
C o rr e s p o n d e n c ia

S is te m a
37
© 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
© 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???
UNPSJB - 2005
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??


Ingeniería de Software - Clase 1
Determinístico o no
determinístico?
Complejidad de
 Datos


Control
algoritmo
39
© RB
Tipos de proyectos

Fuente de requerimientos




Naturaleza del producto



UNPSJB - 2005
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
Ingeniería de Software - Clase 1
40
© RB
Tipos de software

Sistemas de
información





Sistemas para uso
masivo




Donde aparecen??
Qué características
básicas tienen??
Se pueden considerar
como el primer
grupo??
Office por ej.
Sistemas genéricos

Sistemas de TR
Sistemas empotrados

UNPSJB - 2005
Soft para soporte de
trabajo
organizacional
Incluye aplicaciones
de BD
Lenguajes ???


Ingeniería de Software - Clase 1
Sistemas que
proveen servicio
genérico 
aplicaciones de
internet por ej.
Sistemas
desarrollados en
JAVA, HTML, Etc.
41
© 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
UNPSJB - 2005

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
Ingeniería de Software - Clase 1
42
© 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:




Otras actividades




UNPSJB - 2005
Motivación
Organización (modelar
procesos existentes)
Ideas o innovación
Ingeniería de Software - Clase 1
Resolución del problema
Dotes de gestión
Incentivo de los logros
Influencia y construcción
de equipo
43
© 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
UNPSJB - 2005

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
Ingeniería de Software - Clase 1
44
© RB
Gestión del proyecto

Siete factores que inciden en un proyecto



Dificultad
 Alta (DD) Baja (DC, CC)
Tamaño
 Grande (DC,CC) Chica
(DD)
Duración del equipo
 Corto (DC, CC) Grande
(DD)




UNPSJB - 2005
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)
Ingeniería de Software - Clase 1
45
© RB
Gestión del proyecto

Cuatro paradigmas de organización


Cerrado
 Jerarquía de
autoridades
 Menos innovadores,
más clásicos
Aleatorio
 Equipo libre, iniciativa
individual
 Mucha innovación,
menos orden
UNPSJB - 2005


Abierto
 Genera punto
intermedio entre
anteriores
 Trabajo colaborativo
 Buena
comunicación,
decisiones se toman
por consenso
Sincronizado
 Compartimentación
del problema
 Poca comuncación
Ingeniería de Software - Clase 1
46
© RB
Las tres dimensiones de la IR
E s pe cifica ción
C o m p le ta
A c eptac ion
c e rc a n a
Vaga
v is ta
p e rs o n a l
In fo rm a l
UNPSJB - 2005
V is ta
com ún
Semi
fo rm a l
F o rm a l
Ingeniería de Software - Clase 1
R e pres entac ió n
47
© RB
Procesos, métodos,técnicas...





UNPSJB - 2005
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
Ingeniería de Software - Clase 1
48
© RB
Qué vs. Cómo

Históricamente

Requerimiento especificaba que sin decir
como.


Que hace .....? Alcanza para definirlo
R equerim iento
C óm o
D iseño
C óm o
D iseño
C óm o
D iseño
Q ué
El que se refiere al propósito del sistema



Q ué
S ubS istem a
El como en un nivel de abstracción forma
el que del siguiente nivel.
Jackson provee una distinción

R equerim iento
Pero, de esta forma, no es fácil distinguir


S istem a
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
UNPSJB - 2005
Ingeniería de Software - Clase 1
U nidad
R equerim iento
Q ué
49
© RB
Requerimientos   Ambiente

Algunas definiciones que se encuentran
en la bibliografía


UNPSJB - 2005
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 - Clase 1
50
© 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:



UNPSJB - 2005
Madre(z,y) de nota que y es la madre de z
Notar el tipo de representación!!
Ingeniería de Software - Clase 1
51
© RB
IR   Descripción

Una definición
 Entrega una definición formal de un término
que puede ser utilizado en otras descripciones


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:

UNPSJB - 2005
Las definiciones pueden o no ser útiles, pero no se
pude hablar de bien o mal.
Para todo Z y X. Madre(x,z) implica ~ madre(z,x)
Ingeniería de Software - Clase 1
52
© RB
IR   Descripción

Dibujo de borrador

Descripción tentativa de lo que se va a
desarrollar


Ej:

UNPSJB - 2005
Puede contener términos no definidos
“ cada uno de nosotros pertenece solo a una
familia”
Ingeniería de Software - Clase 1
53
© 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)



UNPSJB - 2005
Me ahogaré. Nadie podrá salvarme.
I will drown. No one shall save me.
(determinación de suicidio)
Discutamos, y encontremos en castellano el
equivalente
Ingeniería de Software - Clase 1
54
© 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




UNPSJB - 2005
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.
Ingeniería de Software - Clase 1
55
© RB
IR  involucra modelado

Tres tipos de modelo




Un modelo es más que una descripción


UNPSJB - 2005
Analítico  ej. 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 - Clase 1
56
© RB
IR  involucra modelado

Puede haber un fenómeno en el dominio
de aplicación que no esté en el modelo
D o m in io
de
m o d e la d o
El m undo
D om inio de
aplic ac ión
D e s ig n a c io n e s
Pro p ie d a d e s s o lo
v e rd a d e ra s e n e l
d o m in io d e
a p lic a c ió n
UNPSJB - 2005
D e s c r ip c ió n
c o m p a r tid a
Ingeniería de Software - Clase 1
Pro p ie d a d e s
s o lo
v e rd a d e ra s
e n e l d o m in io
d e m o d e la d o
57
© 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
58
© RB
Tipos de sistemas

Sistemas naturales


Sistemas abstractos


Clubs, mercados, bolsa de comercio
Un sistema puede ser


UNPSJB - 2005
Autos, aviones, edificios, rutas, internet
Sistemas de actividad humana


Ecuaciones matemáticas, programas de
computadora, etc.
Sistemas designados


Tiempo, cuerpo humano, un panal de abejas
Soft  de difícil representación, sistemas poco
precisos
Hard  el sistema es preciso, bien definido y
cuantificable
Ingeniería de Software - Clase 1
59
© 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



UNPSJB - 2005
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
Ingeniería de Software - Clase 1
60
© RB
Límites de un sistema

La elección de los límites



UNPSJB - 2005
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
Ingeniería de Software - Clase 1
61
© RB
Estructura de un sistema

Subsistema



Visibilidad



UNPSJB - 2005
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
Ingeniería de Software - Clase 1
62
© RB
Estados y Propiedades de un sistema

Estado



Una propiedad


UNPSJB - 2005
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.
Ingeniería de Software - Clase 1
63
© 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
64
© RB
Taxonomía de sistemas
Dificultad


de tiempo...


UNPSJB - 2005
Datos (DA)

Sistema de sueldos
Monitoreo de pacientes, reactor
nuclear
Control de procesos, monitoreo de
alarmas
Aplicaciones en tres dominios

Ppal. Proceso de especificación de
requerimientos (descripción,
organización)
Control (CO)

Dinámico (DY)
Juegos, compilación
Paralelo (PA)


Estático (ST)



Comunicación telefónica, tener
un editor de texto interactivo a
distancia
Secuencial (SE)

Llevar a alguien de La Rioja a
Japón en dos horas, sistematizar
toda actividad humana con
computadoras
Relaciones
número de tareas

No difíciles (NH)



Difíciles (HA)


del problema
Definición y descripción del
ambiente, aplicaciones restrictivas
de tiempo
Algoritmo (AL)

Transformaciones de funciones
entre las entradas y las salidas
Ingeniería de Software - Clase 1
65
© RB
Taxonomía de sistemas

Deter. No determ

Determinísticos (DE)


No Determinístico (ND)


UNPSJB - 2005
Control de inventario, compilación, edición
Las respuestas del sistema no son bien
entendidas
Ej. Juego de ajedrez IA.
Ingeniería de Software - Clase 1
66
© RB
Resumiendo

UNPSJB - 2005
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.
Ingeniería de Software - Clase 1
67
© RB
Resumiendo

IR  actividad humana, trabaja sobre




UNPSJB - 2005
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
Ingeniería de Software - Clase 1
68
© RB
Un avance de lo que veremos

La IR consta de etapas


UNPSJB - 2005
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.
Ingeniería de Software - Clase 1
69
© RB
Un avance de lo que veremos

El modelo abarca







UNPSJB - 2005
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
Ingeniería de Software - Clase 1
70
© 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
71
© 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

UNPSJB - 2005
Están todos en el material del 2003.
Ingeniería de Software - Clase 1
72
Descargar

Ingeniería de Software