Ingenieria del software

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 ComodoroUNPSJB – Sede Comodoro
RivadaviaRivadavia

UNPSJB - 2005 Ingeniería de Software - Clase 12
© 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á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

© 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

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

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

© 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ñodetallado
Diseñoarquitectónico
Esp.delsistema
Especificaciónde
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ónde
unanecesidad
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
testeode
prototipo
construc
ciónde
prototipo
diseño
de
prototipo
documentode
requeriementos
testeocodificacióndiseño integración

© RB
 Modelo en espiral
 Dos versiones
Determinarmetas,
alternativasy
limitaciones
Evaluaralternativas
deriesgo
DesarrolloytestPlan
Planificación
Comunicación
conel
cliente
Análisisde
riesgo
Ingeniería
configuración
yadaptación
Evaluacióndel
cliente
Cuatrociclos

© 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 V
Requerimientos
delsistema
Teste
integración
Análisisy
diseño
integracióndel
sistema
preubade
aceptación
Integracióndel
software
pruebade
componentes
pruebade
unidad
Codificacióny
verificación
Diseño
Detallado
Diseño
preliminar
Requerimientos
delsoftware
Niveldeabstracció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
MundoReal
Problema
Implementación
Sistema
Correspondencia
Correctitud
Verificación
Validació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
Vista
común
vista
personal
Completa
cercana
Vaga
FormalSemi
formal

© 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ño
Unidad
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
 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
 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
Elmundo
Dominiode
aplicación
Propiedades
solo
verdaderas
eneldominio
demodelado
Descripción
compartida
Propiedadessolo
verdaderasenel
dominiode
aplicación
Dominio
de
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

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

Ingenieria del software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Ingenieria del software

Similar a Ingenieria del software (20)

Ingenieria del software