Gestin de la

Configuracin (SCM)
Introduccin a la Ingeniera de
Software
Ao 2007

Temario
Configuracin del software
Gestin de la Configuracin
Versiones

Control de Cambios
Lnea base

Auditoria de la configuracin
Herramientas
2

Problemas
Cambios hechos por distintos
programadores se pierden?
Que versin hay que instalar en el cliente?
Un error corregido, reaparece?
Se implement un cambio que no estaba
confirmado?
Cuales son los fuentes que se
corresponden con un ejecutable?
Cual es la ultima versin del Manual de
Usuario?
3

Configuracin
Configuracin del software: Los elementos
que componen toda la informacin
producida como parte del proceso de
ingeniera de software

Fuentes
Ejecutables
Documentos
Datos, etc

A medida que los elementos cambian se

obtienen nuevas versiones, las cuales se
deben identificar de forma nica
Suele ser necesario recuperar versiones
antiguas
4

Gestin de la Configuracin
(SCM)
Identifica, organiza y controla las modificaciones
del software a travs del ciclo de vida.
Actividades de SCM:

Identificacin de elementos
Control de versiones
Control de cambios
Auditar la configuracin
Generacin de informes

Interesa identificar los elementos de configuracin

y localizarlos, seleccionando la versin apropiada,
saber su historia y la razn de sus cambios
Seguir la evolucin del producto, administrar los
requerimientos de cambio e implementarlos en
forma consistente
5

Identificacin de elementos
Cada elemento se identifica de forma
nica
Cada elemento consta de :
Nombre: Texto sin ambigedad
Versin
Tipo: documento, programa, datos, etc
Proyecto
Informacin del cambio o la versin
6

Control de versiones
Combina los procedimientos y
herramientas para gestionar las
versiones de los elementos
Se puede versionar asociando
un
1.3
1.4
numero a cada versin
1.0

1.1

1.1.1

1.2

2.0

2.1

1.1.2

Controlar el Cambio
Lnea Base
Elemento de configuracin que se ha revisado
formalmente y que se ha llegado a un acuerdo
Sirve como base para desarrollos posteriores y
puede cambiarse solo a travs de los
procedimientos de control de cambios

Un elemento de configuracin se convierte

en lnea base si fue revisado y aprobado
Un cambio es el paso de una lnea base a
la siguiente

Controlar el Cambio
Los elementos de la configuracin se cambian
rpida e informalmente hasta que en un
momento se convierte en lnea base, a partir
de ah el cambio se controla mediante
procedimientos formales

Los desarrollos posteriores se hacen a partir

de elementos en lnea base
9

Lnea base (baseline)

Controlar el cambio:
Cambio 2

A2

B2

A1

B1

Lnea base L1
Cambio 1

C1

D1

E1

Una vez que el cambio es aprobado:

Lnea base L2
Cambio 2
Lnea base L1
Cambio 1

A2

B2

A1

B1

C1

D1

E1
10

Las Lneas base permiten

Ir atrs en el tiempo y reproducir el entorno de
desarrrollo en un momento dado del proyecto
Trazabilidad: Permiten establecer relaciones de
predecesor-sucesor entre artefactos. (seguir la pista
y correspondencia)

Definicin de Requerimientos
Especificacin
Mdulos de Diseo
Cdigo que implementa los mdulos
las pruebas para verificar la funcionalidad
los documentos que describen el sistema

Comparar el contenido de una lnea base contra otra

11

Auditoria de Configuracin
Auditoria de la configuracin: Verificar que en un
momento dado, el Sistema en desarrollo es una
coleccin de productos consistente y bien definida .
Determinar que todos los elementos de configuracin estn
presentes en la lnea base del Software, estableciendo la
correctitud de la versin de cada elemento de configuracin
Prevenir problemas

Generacin de Informes
Los informes intentan responder las
siguientes preguntas:

qu pas?
Quin lo hizo?
cundo?
Qu mas se vi afectado?

12

Herramientas
Uso de repositorio delta storage

Modelo checkin/checkout

Modelo usado por algunas herramientas

Los archivos son almacenados y versionados en el
repositorio
El usuario debe hacer un check out del archivo para
ver o escribir
Los archivos modificados se devuelven al repositorio
mediante checkin, creando una nueva versin
Tres formas de evolucin:
Versionado
Merge
1.0
Branch
CVS, ClearCase, Visual Soucesafe
Branch

1.1
1.1.1

1.2
1.1.2

1.3

1.4

2.0

2.1
Merge
13

Requisitos
Introduccin a la Ingeniera de
Software
Ao 2007

Temario
Definiciones
Documentos de Requisitos
Requisitos funcionales y no funcionales
Tipos de Requisitos
Proceso de los Requisitos
Modelado del Sistema - Tcnicas
Obtencin de Requisitos - Tcnicas
Validacin Tcnicas
Administracin de los Requisitos
Medicin
Especificacin Formal - Z
15

Bibliografa
Pfleeger: Captulo 4
Sommerville: Captulos
5 Requisitos del software
6 Procesos de la Ing. De Requisitos
9 Especificacin formal

16

Motivacin

17

Definiciones
Requisitos:
Descripcin de los servicios que debe
brindar un sistema y sus restricciones

Ingeniera de Requisitos
Proceso de descubrir, analizar,
documentar y verificar esos servicios y
restricciones
18

Definiciones
Sistema
Incluye hardware, software, firmware,
personas, informacin, tcnicas, servicios, y
otros elementos de soporte

Requisitos del Sistema

Son los requisitos para el sistema entero

Requisitos del Software

Se refieren solo al SW
19

Requisitos vs. Diseo

Requisitos definen el Qu (el
problema) del sistema
El Diseo define el Cmo (la
solucin)

20

Reporte CHAOS de Standish Group

350 orgs., 8000 proyectos`94 Causas
(Standish Gr.1994)

Causas

%
Respuestas

Requisitos incompletos

13.10%

Falta de involucramiento de
usuarios

12.40%

Falta de Recursos

10.60%

Expectativas no realistas

9.90%

Falta de Soporte de Ejecutivos

9.30%

Requisitos y Especificaciones
cambiantes

8.70%

Falta de planificacin

8.10%

Sistema no se precisaba ms

7.50%

21

Costos de errores en los

Costo de corregir
un error en los
Requisitos
requisitos (Boehm-Papaccio,1988)

22

Documentos de Requisitos

Definicin de Requisitos: lista completa de lo

que el cliente espera que el sistema haga, escrita
de forma que el cliente la pueda entender
1. Se debe proveer un medio para acceder a archivos
externos creados por otras herramientas

Especificacin de Requisitos (SRS): reformula

la definicin en trminos tcnicos para que los
diseadores puedan comenzar el diseo
1.1 Se proveer al usuario los recursos para definir el tipo de
archivo externo
1.2 Cada tipo de archivo tendr una herramienta asociada y
un icono que lo identifica
1.3 Cuando el usuario seleccione el icono que representa un
archivo externo, el efecto es aplicar la herramienta
asociada con ese tipo de archivo al archivo seleccionado
23

Documentos de Requisitos
(2) Entendimiento comn
Usar un mismo documento:

entre Cliente, usuario, analistas, desarrolladores

Usar dos documentos: Se debe aplicar SCM
Gestin de Configuracin: necesaria para asegurar la
correspondencia entre ambos (si existen por
separado)
Permite seguir la pista y correspondencia

Definicin de Requisitos
Especificacin de Requisitos
Mdulos de Diseo
Cdigo que implementa los mdulos
las pruebas para verificar la funcionalidad
los documentos que describen el sistema
24

Caractersticas deseables
de su Especificacin (IEEE
830)
Correctos: Todos los Requisitos son requeridos en el
sistema
No existe herramienta que asegure esto
Debe ser revisado por el cliente y desarrolladores
Revisado contra otros documentos existentes

No Ambiguos: Tiene una nica interpretacin

Completos: Define todos los Requisitos asociados
con funcionalidad, desempeo, restricciones de
diseo, atributos o interfaces externas
Externa: Todos los servicios especificados por el cliente estn
definidos
Interna: No hay referencias sin definir en la especificacin
25

Caractersticas deseables
de su Especificacin (IEEE
830)
Consistentes: No son contradictorios entre s
Ordenados por Importancia y estabilidad
Otra forma de categorizar: Esencial/Condicional/Opcional

Verificables: Un requerimiento es verificable si

existe un proceso finito para determinar que el
sistema lo cumple
Preparar pruebas para demostrar que se cumplen

Modificables: Su estructura y estilo son tales que

cualquier cambio en los Requisitos puede ser hecho
fcilmente en forma completa y consistente
26

Caractersticas deseables
de su Especificacin (IEEE
830)
Trazables: El origen de cada requerimiento es
claro, y es posible seguirle la pista en futuros
desarrollos o mejora de la documentacin
Realistas
Ej.: tiempo de respuesta local=remoto
Ej.: El cliente quiere adelantarse a la tecnologa

Entendibles: Tanto por los usuarios como por

los desarrolladores
27

Documento Definicin de
Requisitos
Registrar los Requisitos en los trminos del cliente
1. Delinear el propsito general del sistema: Incluir
referencias a otros sistemas, glosario y abreviaciones
2. Describir el contexto y objetivos del desarrollo del
sistema
3. Delinear visin global del sistema: Incluir
restricciones generales
4. Definir en detalle las caractersticas del sistema
propuesto, definir la frontera del sistema e interfaces.
5. Discutir el ambiente en el que el sistema va a operar
(hardware, comunicaciones, personal).

28

Requisitos funcionales y NO
funcionales
Funcionales:

describen la interaccin entre el sistema y su

entorno
Servicios o funciones que proveer el sistema
Ejemplos:
Se deben ingresar cdula, nombre y telfono de cada cliente
Se quiere un listado de los clientes por zona

No-funcional:

Restricciones a los servicios o funciones

ofrecidos por el sistema
describen restricciones que limitan las
elecciones para construir una solucin
Ejemplos:
Las consultas deben resolverse en menos de 3 segundos
El lenguaje de programacin debe ser Java

29

Requisitos NO funcionales
Del Producto: Especifican restricciones al comportamiento
del producto
Ejemplos: desempeo, confiabilidad, portabilidad, usabilidad

De la Organizacin: Se derivan de las polticas y

procedimientos existentes en la organizacin del cliente y
en la del desarrollador
Ejemplos: estndares, lenguajes de programacin, mtodo de
diseo

Externos: Se derivan de factores externos, como:

Interoperabilidad: con otros sistemas
Legislativos: privacidad, seguridad
ticos: dependen del contexto, las personas, etc
30

Requisitos - Tipos (1)

Al describir Requisitos se deben tener en cuenta los
siguientes aspectos:
Ubicacin y Entorno Fsicos
dnde, uno o varios, restricciones ambientales

Interfaces
Entrada de 1 o + sistemas, Salida a 1 o + sistemas, restricciones
de formato, soporte

Usuarios y Factores Humanos

capacidad de cada tipo de usuario, tipo de entrenamiento, facilidad
de uso, posibilidad de mal uso

Funcionalidad y Restricciones asociadas

qu debe hacer, cundo, modos de operacin, cmo y cundo se
puede modificar el sistema, restricciones de velocidad, tiempo de
respuesta, capacidad de proceso
31

Requisitos - Tipos (2)

Documentacin
cunta, formato, para quin

Datos
formatos E/S, frecuencia, fuentes, destinos, calidad
requerida, precisin en clculos, flujo en el sistema

Recursos
materiales, personal y otros para construir, usar y
mantener el sistema, habilidades de los
desarrolladores, necesidades de espacio y
ambientales, calendario prescrito, limitaciones en
presupuesto
32

Requisitos - Tipos (3)

Seguridad
control de acceso a las funciones/datos, aislamiento
de los programas, respaldos-frecuencia
,disponibilidad-, seguridad fsica

Aseguramiento de la Calidad
Confiabilidad -tiempo medio entre fallas, robustez,
tolerancia a fallas
Disponibilidad - tiempo para estar operativo luego de
falla- mantenimiento estando activo- tiempo mximo
de no disponibilidad
mantenibilidad
seguridad
portabilidad
33

Requisitos - Fuentes
Necesidades del Cliente, usuario, otros
interesados
Modelos del Dominio
Revisar la situacin actual
Organizacin actual y sistemas
Documentos existentes (antecedentes)
Sistemas anlogos ya existentes
(antecedentes)
34

Proceso
Estudio de
factibilidad

Obtencin y
Anlisis de
Requisitos

Actividad
es

Especificacin
de
Requisitos

Validacin
de
Requisitos

Artefacto
s
Informe
de
factibilida
d

Documento
de
Requisitos

Modelo del
Sistema

Especificacin
de Requisitos

35

Estudio de factibilidad
Estudio corto para resolver si es
posible y conveniente construir el
sistema con la tecnologa existente, las
restricciones de costo y tiempo, etc.
Informe de Factibilidad: Documento
donde se recomienda si seguir con el
sistema, proponiendo cambiar el
alcance, presupuesto, agenda, etc.
36

Proceso
Estudio de
factibilidad

Obtencin y
Anlisis de
Requisitos

Actividad
es

Especificacin
de
Requisitos

Validacin
de
Requisitos

Artefacto
s
Informe
de
factibilida
d

Documento
de
Requisitos

Modelo del
Sistema

Especificacin
de Requisitos

37

Obtencin & Anlisis de Requisitos

Se trabaja en conjunto con los usuarios y clientes
Problemas comunes:
No saben lo que quieren del sistema, slo en trminos
generales, no conocen el costo de sus peticiones
Los Requisitos estn en sus trminos y con
conocimiento implcito de su propio trabajo
Distintos usuarios tienen distintos Requisitos, se
deben encontrar todas las fuentes
Influyen factores polticos
La importancia de los Requisitos vara con el tiempo
Aparecen nuevos Requisitos
38

Brecha en la Comunicacin
Segn desarrolladores,
usuarios...

los

Segn usuarios,

(Scharer 90)

los desarrolladores...

no saben lo que quieren

no captan las necesidades operativas

no pueden articular lo que quieren

ponen excesivo nfasis en aspectos meramente

tcnicos

muchas necesidades por motivos polticos

pretenden indicarnos cmo hacer nuestro trabajo

quieren todo ya

no son capaces de traducir necesidades claramente

establecidas en un sistema

son incapaces de definir prioridades entre

sus necesidades

siempre dicen que no

rehsan asumir responsabilidades por el

sistema

siempre estn pasados del presupuesto

incapaces de dar un enunciado utilizable de

sus necesidades

siempre estn atrasados

no estn comprometidos con los proyectos

de desarrollo

nos exigen tiempo y esfuerzo an a costa de las

obligaciones esenciales

no aceptan soluciones de compromiso

establecen estndares no realistas para la

definicin de Requisitos

no pueden mantener el cronograma

son incapaces de responder rpidamente a cambios

39
en las necesidades

Obtencin & Anlisis de Requisitos

(modelo genrico)

Comprensin
del dominio

Verificacin
de Requisitos

Recoleccin de
Requisitos

Priorizacin

Clasificacin

Resolucin de
Conflictos

40

Proceso
Estudio de
factibilidad

Obtencin y
Anlisis de
Requisitos

Actividad
es

Especificacin
de
Requisitos

Validacin
de
Requisitos

Artefacto
s
Informe
de
factibilida
d

Documento
de
Requisitos

Modelo del
Sistema

Especificacin
de Requisitos

41

Especificacin de los
Requisitos
Lenguaje Natural
Comprensible para el Cliente/Usuario
Ambiguo (glosario)
Poca legibilidad (plantilla, formateo del texto)
Difcil de tratar (Verificar correctitud, consistencia,
completitud)

Notaciones Especiales (ms formales)

Poca o ninguna ambigedad
Facilita tratamiento
Necesidad de entrenamiento en la notacin
Dificultades de comprensin por Cliente/Usuario
42

Notaciones Especiales
Grficas vs. Basadas en texto
Estticas vs. Dinmicas
Descripciones Estticas
Se especifican entidades y sus atributos, los Requisitos
se pueden ver como las relaciones entre las entidades.
No describe como cambian las relaciones con el tiempo

Descripciones Dinmicas
Especifican estados y las transiciones entre estados en
el tiempo

43

Proceso
Estudio de
factibilidad

Obtencin y
Anlisis de
Requisitos

Actividad
es

Especificacin
de
Requisitos

Validacin
de
Requisitos

Artefacto
s
Informe
de
factibilida
d

Documento
de
Requisitos

Modelo del
Sistema

Especificacin
de Requisitos

44

Validacin de Requisitos
Proceso por el cual se determina si la especificacin es
consistente con las necesidades del cliente
Incluye verificar trazabilidad entre la especificacin y el
documento de Requisitos
Se trabaja con un bosquejo completo del documento a
diferencia de la verificacin del Anlisis
Se realizan las siguientes verificaciones en el doc de
Requisitos:
Validez: compromiso con el usuario, que valide que es lo que quiere
Consistencia: que no haya contradicciones
Realismo: que se puedan implementar (incluye: tecnologa,
presupuesto y calendario)
Verificabilidad: Disear conjunto de pruebas para demostrar que el
sistema cumple esos Requisitos
45

Verificacin de Requisitos
NO funcionales

Son difciles de verificar

Se deben expresar de manera cuantitativa utilizando
mtricas que se puedan probar de forma objetiva
( esto es IDEAL)
Propiedad

Medida

Rapidez

Transacciones por seg

Tamao

KB

Fiabilidad

Tiempo promedio entre fallas

Portabilidad

Nmero de sistemas, especificar

Facilidad de
uso

Tiempo de capacitacin

Para los usuarios es difcil especificarlos en forma

cuantitativa
46

Participantes en el Proceso
de Requisitos

Cliente y Usuarios

Requisitos adecuados a sus necesidades

Diseadores
Comprenderlos para lograr diseo que los
satisfaga

Supervisores del Contrato, sugieren:

Hitos de Control, cronogramas

Gerentes del Negocio, entienden:

Impacto en la Organizacin

Verificadores
Comprenderlos para poder verificar si el sistema
los satisface
47

Proceso
Estudio de
factibilidad

Obtencin y
Anlisis de
Requisitos

Actividad
es

Especificacin
de
Requisitos

Validacin
de
Requisitos

Artefacto
s
Informe
de
factibilida
d

Documento
de
Requisitos

Modelo del
Sistema

Especificacin
de Requisitos

48

Modelado del Sistema

Tablas de Decisin
Redes de Petri
Diagramas de Flujo de Datos (DFD)
Casos de Uso
UML
Diagramas de Casos de Uso
Diagramas de Actividad
Diagramas de estado
Diagrama de clases
Modelo Conceptual
49

Tablas de Decisin

Descripcin dinmica
Conjunto de condiciones posibles en un cierto
instante
Estados donde se verifica una combinacin
Estados
determinada de las condiciones
Acciones a tomar
1
2
3
4
Condicion
es
Acciones

Importe > 1000

Buenos Antecedentes

Ya oper antes

Autorizar Crdito

Analizar antecedentes

X
X

Nro estados = 2^nro Condiciones => tablas extensas

50

Redes de Petri
Descripcin dinmica
Permiten describir:
Concurrencia
Sincronizacin

Grafo dirigido con dos tipos de nodos:

Lugares
y Transiciones
Arcos slo pueden unir Lugares con
Transiciones y Transiciones con Lugares
51

Redes de Petri (2)

El estado inicial de una red

de Petri se le llama marca,
L1 -Lugar con marcaesta dado por los Tokens
(marcas) iniciales
Transicin

L2 -Lugar

Significado:
Transiciones: Modelan
eventos o acciones
Lugares con marca:
Cumplimiento de una
condicin
Transicin activada:
Ocurrencia del evento o
ejecucin de la accin

52

habilitada:de
TransicinRedes
Existe al menos un
token en cada uno de
sus lugares de entrada
L1

L3

L2

L4

Petri (3)
Al activarse una
transicin, los tokens
que activaron la
transicin
desaparecen de los
lugaresL1
de entrada
L2y
se generan tokens en
los lugares de salida
deT1la transicin

L5

L3

L4

L5

53

L1

Redes de Petri Algunas

Secuencia primitivas L4
Conflicto

T1
T3
T6

L2

L5

T2

L3

T4

T7

T5
L8

L6

T8
Concurrencia

L7

T9

L9

L10

T10

L11
Sincronizacin
54

Redes de Petri - Ejemplo

Mquina
L2- pronta

dispensadora

T1-Inserta moneda
L1- Tiene moneda
T4-dispensa

T2- rechaza
moneda

T3- acepta
moneda
L3- pronto para
dispensar

Se dispararon las transiciones:

t1,t3,t4
Otra secuencia posible seria t1,t2

55

Diagrama de Flujo de Datos

Descripcin dinmica
(DFD)
Proviene de Metodologa de Anlisis y Diseo
Estructurado
fin de la dcada del 70
Usados en versin original de OMT (Rumbaugh 91), no
incorporados a UML
Antes de los Casos de Uso era una de las formas ms usadas para
describir un sistema

Elementos

Proceso del sistema que recibe datos y genera otros

Archivo de datos (almacenamiento)
Flujo de Datos
Entidad Externa al
sistema a modelar (actor)
Archivo

Datos que entran

Proceso

Datos que salen

56

DFD - Ejemplo
Experiencia y
conocimiento

Sntomas

Diagnstico

Examen

Medicacin

Mdico

Lista de exmenes y
servicios brindados
Diagnstico

Contabilidad
Factura
Exmenes y

Historia Clnica servicios

Precios

Paciente

Registro Contable
57

DFD
Permite visualizar cmo fluye la informacin por el sistema
est asociado a una realizacin particular del sistema
El diagrama no es suficiente para precisar el comportamiento:
por un flujo que entra a un proceso desde un archivo,
fluye un registro o todo el archivo?
No estipula sincronizacin, un flujo llega a una entidad externa y otro
sale Estn relacionados? Uno es respuesta del otro?

No permite definir procesos (bucles, condiciones, etc.)

Se complementa con un diccionario de datos que describe:
estructura de los flujos y otros detalles
los procesos (lenguaje natural estructurado) con lo que el
comportamiento queda determinado

Permite distintos niveles de abstraccin, anidando DFDs

A menudo sistemas legados estn documentados con DFD
58

Casos de Uso
Tcnica para entender y describir Requisitos
Los casos de uso son Requisitos, describen
Requisitos funcionales
Pone el acento en el uso del producto
Describen como el sistema debe comportarse
desde el punto de vista del usuario
Casos de Uso como caja negra: Especifican que es
lo que el sistema debe hacer sin especificar cmo
debe hacerlo
Se describen mediante documentos de texto
Introducido por Ivar Jacobson (1992)
59

Actor
Entidad externa que interacta con el sistema
( persona identificada por un rol o sistema
externo)
Actor principal: Sus objetivos son cumplidos al
realizar el caso de uso
Los actores son externos al sistema que vamos a
desarrollar.
Al identificar actores estamos delimitando el
sistema
Usuario: persona que cuando usa el sistema,
<<actor>>
asume un rol.
Sistema

Actor

60

Cajero Automtico - Ejemplo

Cliente

Retiro

Servicio de
Cajeros

Actor principal: Cliente

Actores: Servicio de Cajeros
Caso de Uso: Retiro
Descripcin: Un cliente de un banco retira dinero de una
cuenta a travs del cajero automtico utilizando una tarjeta
bancaria, el Servicio de Cajeros verifica que el PIN sea
vlido y que el monto de la cuenta sea suficiente para
realizar el retiro
61

Caso de Uso

Caso de Uso

Escenario:
Secuencia de acciones e interacciones entre los actores
y el sistema, dando un resultado de valor observable
para un actor particular
Tambin se conoce como instancia de caso de uso
Es una forma particular de usar el sistema, un camino a
travs de un caso de uso.

Caso de uso: conjunto de escenarios posibles que

puede encarar un actor (o varios) con el sistema
para el logro de cierto objetivo
un resultado observable de valor se basa en
entregar sistemas que hagan lo que las personas
realmente necesitan
62

Caso de Uso : Retiro

Flujo principal:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

Cliente inserta una tarjeta bancaria en el lector del CA.

El CA lee el cdigo de la tarjeta y verifica que es correcto
El CA pide el cdigo de PIN de 4 dgitos
EL Cliente ingresa el PIN
El CA enva cdigo de Tarjeta y PIN al SC
El SC verifica que el PIN sea correcto y contesta: OK
El CA despliega las distintas alternativas disponibles:
retiro, depsito, consulta
El Cliente elige Retiro
El CA pide cuenta y monto
El Cliente los ingresa
CA enva cdigo de Tarjeta, PIN, cuenta y monto al SC
El SC contesta: OK
El CA dispensa el dinero
El CA devuelve la tarjeta
63
El CA imprime el recibo

Caso de Uso : Retiro

Flujo principal: (otra forma)

Cliente

Sistema

Servicio de Cajeros

1. Inserta una tarjeta bancaria en el

lector del CA.
2. Lee el cdigo de la tarjeta y
verifica que es correcto
3 Pide el cdigo de PIN de 4 dgitos
4 Ingresa el PIN
5 Enva Id. De tarjeta y PIN
6 Verifica que el PIN sea correcto
7- Despliega las distintas
alternativas disponibles
8- Elige la opcin: Retiro
9. Pide cuenta y monto
10- Ingresa cuenta y monto
11. Enva al SC el Id. Tarjeta, PIN,
cuenta y monto
12 Contesta: Continuar (OK)
13 Dispensa el dinero
14 Devuelve la tarjeta
15 Imprime recibo

64

Casos de Uso
Forma de encontrarlos: Mirar cada uno de los
actores del sistema y preguntarse que es lo que
buscan cuando usan el sistema
Cada caso de uso modela partes de la dinmica
Diagrama de Casos de Uso descripcin esttica
Los casos de uso son independientes del mtodo
de diseo que se utilice, y por lo tanto del mtodo
de programacin, no son parte del anlisis OO,
pero son una excelente entrada para ello
Los casos de uso pueden dirigir el proceso de
desarrollo. Guan el diseo, la implementacin y la
prueba del sistema
65

Casos de Uso - Conceptos

Precondiciones: Establece que cosas deben ser siempre
verdaderas antes de comenzar un caso de uso. Las
precondiciones no se verifican dentro del caso de uso ya que
se asume que son verdaderas dentro de l.
Poscondiciones: Establece que cosas ocurren al completar el
caso de uso
Flujo principal ( o bsico): Describe el escenario del caso de
uso de mayor inters para el actor. Tpicamente no incluye
condiciones ni bifurcaciones
Flujos alternativos: Son todos los otros escenarios. Los flujos
alternativos son bifurcaciones en el flujo principal
Requisitos Especiales: Son los Requisitos no funcionales,
atributos de calidad o restricciones especficas relacionadas
con el caso de uso.
66

Caso de Uso : Retiro

Flujos Alternativos :
2A. La tarjeta no es vlida
2A1. El CA devuelve la tarjeta con el mensaje tarjeta no vlida
6A. PIN invlido y menos de 3 intentos
El Cliente puede realizar tres intentos para ingresar el PIN vlido. Sino, el CA
retiene la tarjeta.
6A1. El SC contesta indicando PIN invlido
6A2. El CA muestra el mensaje PIN incorrecto y sigue en punto 3
6B. PIN invlido y 3 intentos
El CA debe retener la tarjeta
6B1. El SC contesta indicando PIN invlido
6B2. El CA muestra el mensaje Se le retiene la tarjeta
8A. El CA no tiene dinero
8A1.La opcin Retiro en esta situacin no es una alternativa posible, y el CA
despliega la advertencia: Sin dinero.
67

Flujos Alternativos (cont.

Caso de Uso : Retiro

9A. Monto insuficiente para el cajero

El monto indicado por el cliente no puede obtenerse a partir de los billetes de
que dispone el CA
9A1 El CA despliega el mensaje No se cuenta con ese monto en este cajero
9A2 Vuelve a 9.
12C. No hay suficiente saldo en la cuenta.
12C1. CA despliega mensaje Su saldo no permite extraer ese monto
12C2. El CA devuelve la tarjeta
12D. No hay contacto con el Servicio de Cajeros (SC)
12D1. CA despliega el mensaje sin conexin a la red de cajeros
12D2 . El CA devuelve la tarjeta
12E. Enlace con el computador central se cae durante la transaccin
Hay que asegurar que el SC considera slo los retiros efectivamente
realizados
13A. El dinero no es retirado de la bandeja.
Si despus de YY segundos el dinero est todava en la bandeja, el CA lo
recupera y lo deja en el depsito de dinero usado
14A. La tarjeta se tranca al intentar devolverla.
14A1. CA trata de devolverla durante xx segundos.
14A2. Si en ese tiempo no puede devolverla, CA avisa a mantenimiento
68

Diagrama de Casos de Uso

UML provee notacin para los casos de uso para

ilustrar los actores, los casos de uso y las relaciones
entre ellos
Permite realizar un diagrama del contexto del
sistema
Muestra los bordes del sistema
Retiro

Cliente

Depsito

Transferencia

Servicio de Cajeros

69

Construccin del Modelo Pasos

Definir frontera
Identificar Actores
Para cada Actor, identificar qu cosas quiere hacer
cada uno va a determinar un caso de uso
darle un nombre

Dado un caso de uso

Identificar si participan otros actores
describirlo brevemente de forma narrativa, centrndose en el
flujo principal (distintas variantes de presentacin y contenido)

Una vez definido el conjunto de casos de uso relevante:

refinarlos incluyendo condiciones especiales
identificar casos de uso comunes y particulares (incluye y
extiende), generalizacin
70

Include Relaciones entre

Escenarios comunes a ms de un caso de uso
CU
El Caso de Uso incluido no depende del Caso de Uso base
Cuando una instancia del Caso de Uso llega al lugar donde el
comportamiento de otro Caso de Uso debe ser incluido, ejecuta
todo el comportamiento descrito por el Caso de Uso incluido y
luego contina de acuerdo a su Caso de Uso original.
El Caso de Uso incluido representa comportamiento
encapsulado que puede ser reusado en varios Casos de Uso
En el caso del Cajero:
Desconoce la
existencia de los
Identificar Cliente
que lo usan
<<include>>

<<include>>
<<include>>

Retiro

Transferencia
Depsito

71

Caso de Uso : Retiro

Flujo principal:
1.
2.

Incluye el caso de uso: Identificar Cliente

El CA despliega las distintas alternativas disponibles:
retiro, depsito, consulta
3. El Cliente elige Retiro
4. El CA pide cuenta y monto
5. El Cliente los ingresa
6. CA enva cdigo de Tarjeta, PIN, cuenta y monto al SC
7. El SC contesta: OK
8. El CA dispensa el dinero
9. El CA devuelve la tarjeta
10. El CA imprime el recibo

72

Caso de Uso: Identificar

Descripcin Breve:
Cliente
Verifica que la tarjeta y el PIN sean vlidos

Flujo Principal:
1.
2.
3.
4.
5.
6.

Cliente inserta una tarjeta bancaria en el lector del CA.

El CA lee el cdigo de la tarjeta y verifica que es correcto
El CA pide el cdigo de PIN de 4 dgitos
EL Cliente ingresa el PIN
El CA enva cdigo de Tarjeta y PIN al SC
El SC verifica que el PIN sea correcto y contesta: OK

Flujos Alternativos :
2A. La tarjeta no es vlida
2A1. El CA devuelve la tarjeta con el mensaje tarjeta no vlida
6A. PIN invlido y menos de 3 intentos
El Cliente puede realizar tres intentos para ingresar el PIN vlido. Sino, el CA retiene la
tarjeta.
6A1. El SC contesta indicando PIN invlido
6A2. El CA muestra el mensaje PIN incorrecto y sigue en punto 3
6B. PIN invlido y 3 intentos
El CA debe retener la tarjeta
6B1. El SC contesta indicando PIN invlido
6B2. El CA muestra el mensaje Se le retiene la tarjeta
73

Extend Relaciones entre

CU
Es un fragmento de un caso de uso, que agrega
comportamiento a otro caso de uso
Se usan para explicar escenarios que sera complejo
presentar como flujo alternativo, o que se desea destacar
Representan una parte de la funcionalidad del caso que
no siempre ocurre (condicional).
Se ejecuta solo si la condicin se cumple
El caso de uso extendido referencia a su caso de uso base
Punto de extensin: Punto dentro del caso de uso donde
se puede insertar comportamiento adicional
Al terminar el caso de uso extendido, se vuelve al caso de
uso base, en la sentencia siguiente al punto de extensin
74

Extend - Ejemplo
El Cliente puede querer retirar
monedas adems de billetes
<<include>>
Identificar Cliente
Retiro

<<extend>>

Retirar Monedas
75

Caso de Uso : Retiro

Flujo principal:
1.
2.

Incluye el caso de uso: Identificar Cliente

El CA despliega las distintas alternativas disponibles:
retiro, depsito, consulta
3. El Cliente elige Retiro
4. El CA pide cuenta y monto
5. El Cliente los ingresa
6. CA enva cdigo de Tarjeta, PIN, cuenta y monto al SC
7. El SC contesta: OK
8. El CA dispensa el dinero
9. El CA devuelve la tarjeta
10. El CA imprime el recibo

Puntos de Extensin:
Retiro de Monedas: En el punto 3 del flujo principal76

Caso de Uso: Retiro de

Monedas Punto de extensin

Descripcin Breve: El cliente opcionalmente

puedepor
querer
indicado
un
retirar Monedas
nombre
Flujo Principal:

Extensin de Retiro en el punto Retiro de Monedas, el cliente tambin

puede elegir monedas, en ese caso:
1.
2.
3.
4.
5.
6.
7.

El Cliente especifica el importe a retirar eligiendo tipos de monedas y la

cantidad de rollos para cada uno.
El CA calcula el importe a retirar para cada moneda y el total y lo muestra
El Cliente confirma
CA enva cdigo de Tarjeta, PIN, cuenta y monto
El SC contesta: OK
CA dispensa los rollos de monedas
CA imprime recibo

Flujos Alternativos:
3A El cliente puede querer cambiar la seleccin, se vuelve a 1
77

Generalizacin Relaciones
entre CU
Algunas veces existe ms de un escenario principal
para un caso de uso
Se puede crear un caso de uso abstracto, crear un
caso de uso para cada escenario principal y que
estos hereden del caso abstracto
el Caso de Uso hijo hereda los escenarios, puntos de
extensin y relaciones definidos en el Caso de Uso
padre
El Caso de Uso hijo puede definir nuevas
operaciones, como tambin redefinir o enriquecer
Validar
Cliente
con nuevas secuencias
de
acciones operaciones ya
existentes en el Caso de Uso padre
Validar con PIN

78

Validar con Scaner de Retina

Actividades

Encontrar actores y casos de uso

Priorizar los casos de uso
Detallar un caso de uso
Estructurar el modelo de casos de
uso

79

Bibliografa Casos de Uso

Larman: Applying UML and Patterns: An
Introduction to Object-Oriented Analysis and
Design and the Unified Process (2nd Edition)
Artculos en la pgina:
Captulo 6 del libro de Craig Larman: Applaying
UML and Patterns 2nd Edition
Captulo 19 del libro de Alistair Cockbourn:
Writting Effective Use Cases
Is the clock an actor? Artculo de la revista
Rational Edge
80

UML

Unified Modeling Language

Objetivo: Proveer un lenguaje comn que puede ser
usado para el desarrollo de software
Lenguaje que permite:
Visualizar: La comunicacin es a travs de grficos
Especificar: construyendo modelos para el anlisis, diseo,
implementacin
Construir: Permite la generacin de cdigo a partir de un
modelo UML, y la construccin de un modelo a partir del
cdigo (ingeniera reversa)
Documentar: Permite la documentacin completa de todo el
sistema

Aprobado como estndar por la OMG en 1997

Actualmente se encuentra en la versin 2.1.1
81

Diagramas en UML

82

Tipos de Diagramas
Modelo Esttico
Construye y documenta los aspectos estticos de un
sistema.
Refleja la estructura bsica y estable de un sistema
software.
Crea una representacin de los principales elementos del
dominio del problema

Modelo Dinmico
Crea los diagramas que muestran el comportamiento de un
sistema
Se compone de los siguientes diagramas:

83

Diagramas para representar

Requisitos
Diagrama de Casos de Uso
Diagrama de clases (modelo
conceptual)
Diagrama de Actividad
Diagramas de Estados

84

Diagrama de Casos de Uso

Permite visualizar en una forma compacta los casos de
uso del sistema y que actores participan en cada caso
de uso
Presenta las relaciones que existen entre los casos de
uso
Muestra los lmites del sistema
Visin esttica de los Casos de Uso de un sistema
Consta de los siguientes elementos:
Actor
Caso de Uso
Relaciones

include
extend
Generalizacin
85

Diagrama de Casos de Uso Ejemplo

<<extend>>
Retiro de Monedas
<<include>>
Retiro
Cliente

Validar con PIN

<<include>>
Validar Cliente

Depsito
<<include>>
Validar con Scaner de Retina

Transferencia

86

Nombre Clase

Diagrama de Clases

Atributos
Operaciones

Muestra las clases e interfaces que componen el

sistema y las relaciones que existen entre ellas
Muestra aspectos estticos
Clase: conjunto de objetos que comparten:

Atributos
Operaciones
Relaciones
Semntica

Modelo de Dominio (Conceptual): ayudan a entender los

conceptos del dominio del problema y el vocabulario del
mismo. Se excluyen detalles referentes a la implementacin o
al lenguaje de programacin.
Diagramas de clases de implementacin: muestran todos
los mtodos y atributos necesarios para implementar cada
clase. Es un diagrama dependiente de la implementacin y del
lenguaje.
87

Modelo del Dominio

Permite describir
las entidades que conforman el
(Conceptual)
Dominio, sus relaciones y atributos

Se representan los conceptos del dominio

Muestra aspectos estticos

Cliente.
nombre

usa

0..1

0..n
Tarjeta
Nmero
PIN

Banco
Nombre
expide
n
tiene
0..1
0..n

1
n
Cuenta
saldo

Retiro.

Cajero.
saldo
1
realiza
n
Transaccin
monto

Depsito.

Transferencia.
88

Diagrama de Actividad

Se construye para modelar el flujo del control

(workflow)
Elementos:
Estado de Actividad (o de Accin)
Estado Inicial
Estado Final
Transiciones
Actividades concurrentes
Bifurcaciones
Condiciones de la bifurcacin
[ guarda ]
Andariveles

Permite modelar el flujo del trabajo

En un sistema
En una organizacin
89

Diagrama de Actividad Ejemplo

Guarda de
decisin

Se abren
Flujos
Paralelos

Sincronizaci
n
90

Diagrama de Estados
Muestra el comportamiento de un objeto
representando los estados en que se puede
encontrar y los eventos que le hace pasar de uno a
otro.
Se utiliza para:
Modelar el estado interno de una clase
Modelar el estado de un caso de uso

Da una vista dinmica del sistema

Permite:
Anidamiento: un estado con subestados
Estados paralelos: reduce el nro. de estados necesarios en
el modelo
Condiciones de bifurcacin
91

Diagrama de Estados Ejemplo

ingreso PIN [PIN incorrecto]

Esperar
Tarjeta

ingreso tarjeta

Pedir PIN

ingresar PIN[ PIN correcto ]

Seleccionar
cuenta y monto

ingreso cuenta y monto

Verificar
fondos

fondos insuficientes

Devolver
Tarjeta

retiro de tarjeta

contesta[ fondos suficientes ]

efectivo retirado
Dar Dinero
Contar

dinero suficiente

Dispensar

92

Bibliografa UML
http://www.uml.org/
Artculos en la pgina:
Introduccin a UML - Artculo de la
revista Rational Edge
Diagramas de Actividad - Artculo de la
revista Rational Edge
93

Eleccin de una Tcnica

para Especificar Requisitos
No existe un nico enfoque aplicable
a todos los sistemas, depende de
cada proyecto
Puede ser necesario combinar varios
enfoques

94

Proceso
Estudio de
factibilidad

Obtencin y
Anlisis de
Requisitos

Actividad
es

Especificacin
de
Requisitos

Validacin
de
Requisitos

Artefacto
s
Informe
de
factibilida
d

Documento
de
Requisitos

Modelo del
Sistema

Especificacin
de Requisitos

95

Obtencin de Requisitos
Tcnicas :
Investigar antecedentes
Entrevistas individuales/grupales
Encuestas/Cuestionarios
Tormenta de ideas
Workshop
Casos de Uso
Observacin/Participacin
Prototipado
96

Investigar antecedentes

Estudio, muestreo, visitas,

Buena forma de comenzar un proyecto
Interna: Estructura de la organizacin, Polticas y
procedimientos, Formularios e informes,
Documentacin de sistemas
Externa: Publicaciones de la industria y comercio,
Encuentros profesionales, Visitas, Literatura y
presentaciones de vendedores

Ventajas
Ahorra tiempo de otros
Prepara para otros
enfoques
Puede llevarse a cabo
fuera de la organizacin

Desventajas
Perspectiva limitada
Desactualizado
Demasiado genrico
97

Entrevista individual/grupal
Usar para:

Pasos para las

Entender el problema de negocio
Entrevistas

Entender el ambiente de
operacin
Evitar omisin de Requisitos
Mejorar las relaciones con el
cliente

Ventajas
Orientado a las personas
Interactivo/flexible
Rico

Desventajas
Costoso
Depende de las habilidades
interpersonales

Seleccionar participantes
Aprender tanto como sea
posible de antemano

Preparar la entrevista
Utilizar un patrn de
estructura

Conducirla
Apertura, desarrollo,
conclusin

Enviar un memo con

resultado
Seguimiento

98

Entrevista Patrn para

Datos de las Personas:
Usuarios, interesados, disparador
conducirla
del proyecto
Que trabajo realizan? Para quin?
Que interfiere con su trabajo?
Que cosas hacen su trabajo mas fcil o mas difcil?

Datos: Entradas y Salidas clave, datos ya existentes

Listar las entradas y salidas
Cual es el problema? Como se resuelve ahora? Como le gustara que se
resolviera?

Procesos: Propsito, Objetivos y metas

Quien necesita la aplicacin?
Cuantos usuarios la van a usar y de que tipo?

Ubicaciones: Lugares involucrados, contexto de los

usuarios
Entorno de los usuarios, computadoras, plataformas
Aplicaciones relevantes existentes
Experiencia de los usuarios con este tipo de aplicacin, expectativas de
tiempo de training
99

Entrevista Patrn para

conducirla
Evaluar Confiabillidad,
Desempeo (2)
y soporte necesario:

Cuales son las expectativas respecto a la confiabilidad?

Y respecto a la performance?
Que tipo de mantenimiento se espera?
Que nivel de control y seguridad?
Que Requisitos de instalacin existen?, cmo se distribuye el software?
, debe ser empaquetado?

Otros
Existen Requisitos legales, regulatorios u otros estndares que deban
ser tenidos en cuenta?

Factores crticos de xito:

Qu se considera una buena solucin?

Tener en cuenta:
Si el entrevistado comienza a hablar sobre los problemas
existentes, no cortarlo con una prxima pregunta
Luego de la entrevista y mientras los datos an estn en
mente, resumir los principales req .( aprox. 3) de este
entrevistado

100

Encuesta/Cuestionario

No substituye la entrevista
Antes de usar el enfoque:

Determinar la informacin que se precisa

Determinar el enfoque ms adecuado:
Abierto, cerrado, combinado
Mltiple opcin, valor en escala, orden relativo

Desarrollar cuestionario
Probarlo con perfil tpico
Analizar resultado de las pruebas

Su principal uso es para validar asunciones y obtener datos estadsticos

sobre preferencias

Ventajas
Economa de escala
Conveniente para quien
contesta
Respuestas annimas

Desventajas
Menos rico
Problemas por no-respuesta
Esfuerzo de desarrollo
101

Observacin/Participacin

Poco utilizado
Antes de usarlo

Determinar informacin necesaria

Comunicar a los involucrados
Considerar perodos normales y atpicos
Planificar las anotaciones

Ventajas
Confiable
Muy rico
Desarrolla empata

Desventajas
Efecto Hawthorne
Cuidado con generalizar
demasiado (sesgo
particular/local)
102

Tormenta de ideas
(brainstorming)
Objetivo: Lograr consenso sobre los Requisitos
Ayuda a la participacin de todos los
involucrados
Permite pensar en otras ideas
Un secretario saca notas de todo lo discutido
Reglas
No se permite criticar ni debatir
Dejar volar la imaginacin
Generar tantas ideas como sea posible
Mutar y combinar ideas
103

Tormenta de ideas Fase de

generacin
Los principales stakeholders se juntan en un
cuarto
Se explican las reglas
Se establece el objetivo:
Que caractersticas esperan en el producto?
Que servicios esperan que provea?
Los objetivos permiten decidir cuando terminar

Se pide que cada participante escriba sus ideas,

luego las ideas son ledas para que otros piensen
en ideas relacionadas y de esa forma las ideas
mutan y se combinan
104

Tormenta de ideas Fase de

reduccin
El secretario lee cada idea y pregunta si es vlida
Si hay cualquier desacuerdo, la idea se queda

Agrupamiento de ideas
Nombrar los grupos

Definicin
Se escribe una breve descripcin de lo que la idea significa para la
persona que la escribi
Ayuda a tener un entendimiento comn del requerimiento
Lleva unos minutos por idea

Priorizacin (opcional)
Test de los $100: Cada persona tiene dinero para comprar ideas, se
ordena segn ideas mas compradas
Solo se puede hacer una vez
Se debe limitar la cantidad a gastar en 1 sola idea
105

Sesiones de trabajo
(Workshop)
mbito para las tormentas de ideas

Preparacin

Venderlo a los posibles miembros de la reunin

Asegurarse que asisten los stakeholders correctos
Estructurar la invitacin, el lugar, etc.
Enviar material previo a la reunin
Doc de Requisitos
Entrevistas, defectos de los sistemas existentes, etc.
Asegurarse de enviar lo necesario, sin exagerar

Organizar la Agenda

Introduccin
Tormenta de ideas generacin
Tormenta de ideas reduccin
Priorizacin
Resumen
106

Casos de Uso

Formato simple y estructurado donde los usuarios y

desarrolladores pueden trabajar juntos
No son de gran ayuda para identificar aspectos no
funcionales
Mientras se definen los casos de uso, puede ser un
buen momento para definir pantallas u otros objetos
con los que el usuario interacta
Pueden ser usados en el diseo y en el testing del
sistema

Usarlo
Cuando el sistema est
orientado a la
funcionalidad, con varios
tipos de usuarios
Cuando la
implementacin se va a
hacer OO y con UML

No son la mejor
eleccin:

Sistemas sin usuarios y

con pocas interfaces
Sistemas dominados
primariamente por
Requisitos no funcionales
107
y restricciones de diseo

Prototipado
Implementacin parcial, permite a los desarrolladores y
usuarios:
entender mejor los Requisitos
cuales son necesarios, deseables
Acotar riesgos

Prototipo deshechable: El propsito es solo establecer

que algo se puede hacer, luego se parte de cero en la
construccin, quedando el conocimiento aprendido
Prototipo evolutivo: Es implementado sobre la
arquitectura del producto final, el sistema final se
obtiene de evolucionar el prototipo
Aspectos para los que es frecuente construir prototipos:
Apariencia y percepcin de la interfaz de usuario
Arquitectura (riesgos tecnolgicos, tiempos de respuesta)
Otros aspectos riesgosos
108

Mismos datos, pero

Ingrese
ao:

____

mes:

____

da:

____

Julio 1998

1998

1
Ene

2025

31
Dic
Martes 16 Oct. 2002
109

Proceso
Estudio de
factibilidad

Obtencin y
Anlisis de
Requisitos

Actividad
es

Especificacin
de
Requisitos

Validacin
de
Requisitos

Artefacto
s
Informe
de
factibilida
d

Documento
de
Requisitos

Modelo del
Sistema

Especificacin
de Requisitos

110

Validacin de Requisitos
Tcnicas de Validacin:
Manuales

Lectura, Referencias cruzadas Manuales

Entrevistas, Revisiones, Listas de Comprobacin
Modelos Manuales para verificar funciones y relaciones
Escenarios
Generacin de Casos de Prueba
Pruebas Matemticas: Si se us un lenguaje formal, por ejemplo
Z

Automatizadas
Referencias cruzadas automticas: Si los Requisitos se expresan
formalmente, las herramientas CASE verifican su consistencia
Ejecucin de Modelos
Construccin de Prototipos

111

Revisin de Requisitos
Participan representantes
del cliente: operadores, quienes realicen entradas, utilicen salidas, y
sus gerentes
del equipo de desarrollo: analistas de Requisitos, diseadores,
encargados de pruebas y gestin de configuracin

Incluye:

revisar objetivos del sistema

Evaluar alineamiento de Requisitos con los objetivos (necesidad)
revisar el ambiente de operacin y las interfaces con otros sistemas
funciones completas, restricciones realistas
evaluar riesgos
cmo asegurar que la
reunin es efectiva?
considerar:

Moderador, Secretario y
pruebas del sistema
Responsables
por
cambios en los Requisitos en el proyecto, su verificacin
y validacin
Acciones

112

Ingeniera de Requisitos
Ingeniera de Requisitos

Proceso de los Requisitos

Especificacin
Especificacin
de
de
Requisitos
Requisitos

Validacin
Validacin
de
de
Requisitos
Requisitos

Proceso de los Requisitos

Lnea Base de Requisitos

Obtencin
Obtencin yy
Anlisis
Anlisis de
de
Requisitos
Requisitos

Administracin de los Requisitos

Lnea base corregida

Planificacin
Planificacin

Administracin
Administracin
del
del Cambio
Cambio

Lnea base actual

Proceso del cambio en los Req

Cambios
En
Requisitos

Cambios
en el proyecto
113

Administracin de los
Requisitos
Los Requisitos cambian, debido a:
Muchos usuarios
Quienes pagan por el sistema y los usuarios no son las
mismas personas
Cambios en el negocio
Cambios en la tecnologa

Proceso de comprender y controlar los cambios en los

Requisitos del sistema
Se hace en paralelo con el Proceso de Requisitos, dos
etapas:
Planificacin: Se realiza al comenzar el anlisis de Requisitos
Administracin del cambio: Comienza una vez que se tiene
una primera versin del documento de Requisitos
114

Cambios en los Requisitos

Cuando se propone un cambio, debe rastrearse
el impacto
Informacin de rastreo que se debe mantener
La fuente: Quin propuso el requerimiento y porqu
Requisitos dependientes: Vincula los Requisitos
dependientes entre s, se usa para el anlisis del
cambio
Rastreo al diseo: Vincula el req con los mdulos
de diseo que lo implementan

Uso de matrices de trazabilidad

115

Planificacin
Muchas actividades son tomadas de las tcnicas de SCM
Se debe decidir sobre:
Identificacin de Requisitos: Cada Requisitos debe
identificarse en forma nica
Ejemplo:
<Tipo> < nro> donde Tipo: F Funcional, D- Datos, etc.
Ejemplo: F12

Proceso de Administracin del cambio: Actividades que

evalan el impacto y costo del cambio
Polticas de rastreo: Cmo se registra y como se mantiene
Herramientas CASE: Definir uso para
Almacenar los Requisitos
Administrar el cambio
Administrar el rastreo
116

Administracin del cambio

Etapas:
1. Especificacin del cambio
2. Anlisis del cambio y costo: Se usa la
informacin del rastreo, costo en trminos de:
Modificaciones a docs de Requisitos
Diseo e implementacin

3. Implementar el cambio: se modifican los

artefactos necesario
Siguiendo estos pasos se logra
Todos los cambios se tratan en forma consistente
Los cambios a los docs de Requisitos se hacen en
forma controlada
117

Metodologas de desarrollo
Los mtodos giles fueron desarrollados en
respuesta a la necesidad de tener una
alternativa a los procesos de desarrollo de
software pesados, guiados por documentos
(AgileAlliance 2002)
Cada metodologa trata distinto los Requisitos
Ejemplo de metodologa gil: eXtreme
Programming (XP)
Ejemplo de metodologa pesada: Rational
Unified Process
118

eXtreme Programming
Cliente en el lugar
Un cliente real debe sentarse en el lugar, disponible para escribir
historias, contestar preguntas, resolver disputas y prioridades de
pequea escala.

Historias de usuario

Su propsito es anlogo al de los casos de uso

Son escritas por el cliente, son las cosas que el sistema debe hacer
No son casos de uso, pero describen escenarios
Su formato son tres sentencias de texto escritas por el cliente, en su
terminologa sin sintaxis tcnica.
Cuando llega el momento de implementarla, los dasarrolladores van
con el cliente y reciben una descripcin detallada de los requisitos,
cara a cara
Se usan para planificar el proyecto: se estiman y el cliente las
prioriza definiendo el alcance
119

Rational Unified Process

Disciplina de Requisitos

120

RUP detalle de actividades

121

Medir y evaluar los

Requisitos
Medir caractersticas de los Requisitos para
obtener detalles
Proceso de los Requisitos
Calidad de los Requisitos

Las mediciones van a estar relacionadas con:

Producto (de los Requisitos)
tamao, calidad, atributos tcnicos, ....

Proceso
actividades,...

Recursos
personas, equipos, tiempo, dinero,...
122

Medir y evaluar Requisitos

Medir
# Requisitos
Entrada para estimacin del producto

# cambios introducidos
Requisitos Agregados, Modificados, Desechados en el
tiempo
Estabilidad

# Requisitos por tipo de Requisitos

Permite luego ver en que parte se encuentra el cambio

# Requisitos validados

Tamao del producto y del proyecto (ej.:PF, LoC)

planificar
123

Especificacin Formal
Ventajas:
permite detectar omisiones e inconsistencias en los
Requisitos
Deteccin temprana de defectos
Necesario para demostrar que un programa es correcto

Desventajas:
Exige entrenamiento
En general no es comprensible para el cliente
Funcionan bien en escalas reducidas, pero se complican a
medida que crece la escala del producto

Su aplicacin suele estar restringida a sistemas

crticos
124

Sistema crtico, un ejemplo

Bomba personal de insulina que intenta emular
el comportamiento del pncreas (alternativa
frente a inyecciones de insulina)
Un sensor mide el nivel de azcar en la sangre
Requisitos relativos a la criticidad
Disponibilidad el sistema debe funcionar cuando el
paciente necesite insulina
Confiabilidad debe proveer insulina en momento y
cantidad adecuada
Seguridad (safety) una dosis excesiva podra
poner en riesgo la vida del paciente
125

Conectado a la
bomba, inyecta
insulina en el
cuerpo

Bomba de Insulina Depsito

Componentes

Bombea insulina
del depsito a la
aguja

aguj
a
Sensor
Mide nivel
de azcar
en la sangre

Controla todo
el sistema

bomba

Controlador

reloj

Alarma
Suena en caso
de problemas

Pantalla
Fuente de Energa

Muestra la ultima
lectura de azcar
y mensajes de
estado
126

Concepto de operacin
A partir de la lectura del sensor, el sistema evala el
nivel de glucosa en sangre del paciente
El sistema compara lecturas consecutivas para detectar
una posible tendencia al crecimiento del nivel. En este
caso inyecta insulina para actuar en contra de esa
tendencia
La situacin ideal es que el nivel de azcar se encuentre
sistemticamente en la banda de seguridad
Niveles de azcar en sangre:
Inseguro menos de 3 unidades (posible coma)
Seguro- entre 3 y 7 unidades
No deseable (ms de 7 unidades)

Nota: los valores mencionados slo son a ttulo ilustrativo

127

Inyeccin de Insulina
Segn nivel de azcar, tendencia e inyecciones anteriores
Escenarios relativos al nivel de azcar en sangre:
en la banda insegura
No inyectar
Alarma para el paciente

En las otras dos bandas

cayendo
En banda segura no inyectar
En banda no deseable si cae tasa de descenso, inyectar

estable
En banda segura no inyectar
En banda no deseable inyectar de acuerdo a lo indeseado del nivel

Creciendo
En la banda segura inyectar si tasa de crecimiento constante o creciente
En banda no deseable inyectar de acuerdo a la tasa de crecimiento

128

Lenguaje de especificacin
Z
Se han desarrollado diversos lenguajes y herramientas para
la especificacin (y verificacin) de software.
Z (Hayes 87, Spivey 92) est basado en la teora de
conjuntos tipados
modela un sistema en base a conjuntos y sus relaciones
introduce elementos que facilitan la especificacin de pre y post
condiciones asociadas a estados
los modelos se construyen a partir de esquemas

Esquema: Introducen variables de estado y definen

restricciones y operaciones sobre los estados
Una especificacin es representada como un conjunto de
esquemas
Los esquemas pueden ser combinados y usados en otros
esquemas
129

Lenguaje de especificacin
Z
Schema
name

Schema
signature

Schema
predicate

Container
contents:
capacity:
contents <= capacity

Schema signature: Declara nombres y tipos de

las entidades
Schema predicate: Define relaciones entre las
entidades de la signature mediante expresiones
lgicas que deben ser verdaderas (invariantes)
130

Lenguaje de especificacin
Z
Nombres seguidos por ? son entradas y
por ! , salidas
Nombre seguido por significa el valor
despus de la operacin
precediendo a un nombre significa que los
valores no son cambiados por la operacin
precediendo a un nombre significa que los
valores son cambiados por la operacin
Incluir el esquema A en el esquema B significa
que B hereda los nombres y predicados de A
131

Z para la bomba de insulina

Conjunto de variables de estado:
reading? : Lectura del sensor de glucosa en la sangre
dose, cumulative_dose: dosis a suministrar y dosis acumulada en
un perodo
r0, r1, r2: 3 ltimas lecturas, se usa para calcular la razn del
cambio de glucosa en la sangre
Capacity: capacidad del deposito
alarm!: alarma
pump!: seal de control enviada a la bomba
display1!, display2! : msg de estado y dosis a administrar

Para la bomba de insulina:

dosis<=contenido del depsito
dosis<=5 unidades y suma de dosis en perodo <=50
display1! muestra el estado del depsito
132

Esquema para la bomba de

insulina
Insulin_pump

reading? :
dose, cumulative_dose:
r0, r1, r2:
// para registrar las 3 ltimas lecturas tomadas
capacity:
alarm!: {off, on}
pump!:
display1!, display2!: STRING
dose<=capacity dose<= 5 cumulative_dose<= 50
capacity>= 40 display1! = " "
capacity<= 39 capacity >=10 display1! = "Insulina baja
capacity<= 9 alarm! = on display1! = "Insulina muy baja
r2 = reading?

133

Clculo de la dosis

DOSAGE
Insulin_Pump

Delta indica que

cambia el estado

(
El programa:
dose = 0
Compara el valor actual
(
r1>=r0) ( r2 = r1))
del nivel de azcar con los
(( r1 > r0) (r2<= r1))
dos anteriores
(( r1 < r0) ((r1-r2) > (r0-r1)))
si est subiendo, la
)
bomba inyecta insulina
dose = 4
mantiene total de
(
insulina inyectada para
(( r1<=r0) (r2=r1))
(( r1 < r0) ((r1-r2) <=(r0-r1)))
controlar el mximo
)
seguro
dose =(r2 -r1) * 4
(
(( r1<=r0) (r2 > r1))
aplicado a una variable
(( r1 > r0) ((r2 - r1) >=(r1 - r0)))
refiere al valor luego
)
)
de cambiar el estado
capacity ' =capacity - dose
cumulative_dose' = cumulative_dose + dose
r0' = r1 r1' = r2
134

Esquemas de salida

Modelan lo que despliega el sistema:

La pantalla muestra la dosis calculada y un mensaje de
advertencia
DISPLAY
La
alarma suena si el azcar en la sangre es muy baja
Insulin_Pump
-debe ingerir azcar

display2!' = Nat_to_string (dose)

(reading? < 3 display1! ' = "Azcar baja
reading? > 30 display1! ' = "Azcar muy baja
reading? >=3 and reading?<=30 display1!' = "OK")
ALARM
Insulin_Pump
( re ading? < 3 re ading? > 30 ) alarm!' = on
reading? >= 3 reading?<=30 ) alarm!' = off

135