Análisis y Diseño de

Software
Importancia del
Análisis y Diseño
01 Modelado de
Software
Elementos usados en Desarrollo de
Software Notación
p.e. UML, DFDs, ER,
etc.

Herramientas Proceso
p.e. Rational Rose p.e. Rational Unified
StarUML, Poseidon, Process
etc. Métrica 3.0, XP, etc.
Modelos y Diagramas
 Analizar y Diseñar conlleva modelar, es decir, NO estamos escribiendo código …
pero debe existir alguna conexión entre los modelos y el código ¿no?
 Un modelo captura una vista de un sistema del mundo real. Es una abstracción de
dicho sistema, considerando un cierto propósito. Así, el modelo describe
completamente aquellos aspectos del sistema que son relevantes al propósito del
modelo, y a un apropiado nivel de detalle
 Diagrama: una representación gráfica de una colección de elementos de
modelado, a menudo dibujada como un grafo con vértices conectados por arcos
 Un modelo se representa a través de 1 o más diagramas
Modelos y Diagramas
 Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que
permitan expresar el producto desde cada una de las perspectivas de interés

 El código fuente del sistema es el modelo más detallado del sistema (y además es
ejecutable!!). Sin embargo, se requieren otros modelos ...

 Cada modelo es completo desde su punto de vista del sistema, sin

embargo, existen relaciones de trazabilidad entre los diferentes modelos
¿Por qué modelar el Software?
 Modelo: Representación del software => abstracción

 El modelado facilita:
• Comunicación de ideas
• Evaluar alternativas
• Aproximación gradual al producto
• “Visualizar” el producto

 ¿Cuánto y cómo modelar?

Depende de la envergadura y/o complejidad del producto y debe
además estar acorde con la explotación que se haga de los modelos
Grado de modelado
Según envergadura/complejidad del producto

Construcción de una Puede hacerlo una sola persona

casa Requiere:
para una mascota Modelado mínimo
Proceso simple
Herramientas simples
 Grado de modelado:
Según envergadura/complejidad del producto

Construcción de
una casa familiar

• Construida eficientemente y en un
tiempo razonable por un equipo
• Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas
Grado de modelado
Según envergadura/complejidad del producto

Sin
comentarios
Grado de modelado: Según su
explotación
Generar parcial o totalmente una

Nivel de aprovechamiento
3 implementación a partir de los modelos

de los modelos
2 Tomar decisiones de análisis/diseño
que condicionen la implementación

1 Comunicar ideas y estudiar alternativas

0 “Documentar” (a posteriori)
¿Qué es Análisis y Diseño?
 “Una especificación de análisis es independiente de la plataforma de
implementación”
 Otras frases usuales: “Análisis es establecer el qué, mientras que diseño es
establecer el cómo”
 El análisis “clásico” actualmente se divide en Requisitos y Análisis.
 En un enfoque OO normalmente se encadenan Análisis y Diseño sin enfatizar
sus diferencias
 MDA (Model-Driven Architecture) establece CIM (Computer Independent
Model),
PIM (Platform Independent Model) y PSM (Platform Specific Model)
Enfoques para
especificación/modelado de
software
Especificación / Modelado Implementación

Fron t-End

?
IU
App (nativa o mixta),
Web, o Deskstop

Bac k-End
Servicios

BD

Presentación / IU & UX
+
Software = Lógica / Procesos / Comportamiento
+
Datos / BD / Estructura
Enfoques para
especificación/modelado de
software Especificación / Modelado Implementación

Requisitos Análisis Diseño Fron t-End

Diagramas de
IU
Diagramas de Flujo App (nativa o mixta),
Estructura
de Datos Web, o Deskstop
Enfoque
Estructurado
Modelo
Diagramas E-R
Relacional
Back-End

Servicios
Enfoque
Orientado a Diagramas de UML
Objetos
Modelo BD
Relacional !!

Presentación / IU & UX
+
Software = Lógica / Procesos / Comportamiento
+
Datos / BD / Estructura
 ¿Qué rescato o creo que es
¡1 Cosa! importante recordar el modelado
¿Qué recuerdas? de software?
02 Enfoque
Estructurado
Modelado de
Procesos
Diagrama de Flujo de Datos (DFD)
Libros
Editores
pedido
Cliente detalle libro
dirección

2.1 2.2
Verificar si Armar
el pedido requisición
es válido a editores
Estado de crédito
orden de compra

pedido valido
pedido por lote
Editor
Clientes
Pedidos Pendientes
Procesos BPMN
Modelado de
Datos
Diagramas Entidad-Relación –
Ejemplo 1
Diagramas Entidad-Relación –
Ejemplo 2
 ¿Qué rescato o creo que es
¡1 Cosa! importante recordar sobre los
¿Qué recuerdas? modelos estructurados?
Micro Break
03
Enfoque
Orientado a
Objetos
Ventajas del Enfoque Orientado a
Objetos
 Proximidad de los conceptos de modelado respecto de las entidades del mundo
real
• Mejora captura y validación de requisitos
• Acerca el “espacio del problema” y el “espacio de la solución”

 Modelado integrado de propiedades estáticas y dinámicas del ámbito del problema

• Facilita construcción, mantenimiento y reutilización

 Conceptos comunes de modelado durante el análisis, diseño e implementación

• Facilita la transición entre distintas fases
• Favorece el desarrollo iterativo del sistema
• Disipa la barrera entre el “qué” y el “cómo”
 Modelado usando UML
Los diagramas expresan gráficamente partes de un modelo
 UML es la notación más
amplia/exhaustiva/extensa para modelado
de software existente en la actualidad
 “El 80% de la mayoría de los problemas
pueden modelarse usando alrededor del 20%
de UML” (Grady Booch)
 UML combina notaciones
provenientes desde:
• Modelado Orientado a Objetos
• Modelado de Datos
• Modelado de Componentes
• Modelado de Flujos de Trabajo
(Workflows)
Modelo de
Requisitos
 ¿Cómo modelar requisitos?
 Un modelo de requisitos expresa el producto desde la perspectiva del usuario (visión
externa, caja negra)

 En el enfoque OO usando UML, claramente el Diagrama de Casos de Uso

complementado con otros diagramas (p.e. Diagrama de Clases, Diagrama de Estado,
de Diagrama de Actividad) permite modelar requisitos

 En el enfoque estructurado la parte alta de la jerarquía de DFDs (p.e. DFD 0) podrían

ser procesos que correspondan a servicios del sistema (no a una descomposición
funcional interna de ellos). Un Diagrama E-R muy general puede complementar
dicho DFD en cuanto a datos.
 Definir Requerimientos
• Listar requerimientos funcionales, lo que el sistema
mínimo debe cumplir

• Observar los alcances para los atributos del sistema:

Requerimientos No Funcionales

• Comenzar a definir el sistema que soluciona el

problema
 Diagrama de Casos de Uso
Gestionar Usuarios

Consultar Medidas
Ciudadano Administrador

Consultar registro de accesos

Consultar y Validar Medidas

Gestionar Estaciones Apagar Alarma Umbral

Gestionar Sondas ClearAlarms al pasar 24 horas

Gestionar Bandas
Editlocation al publicar o ClearLocation al
no publicar una ubicación
Servicio Web GIS

Gestionar Configuraciones Gestionar Ubicaciones

Almacenadas ChangeLocationState al
Controlador terminar una
asignación

Gestionar Asignaciones

Consultar Alarmar y Alertas SetAlarms al encender

alerta umbral

Terminar Automáticamente
Gestionar Incidencias Descargar a Fichero Asignaciones
Cuadro de Mandos Autoimport

SMS Estación de Medición SMS

Notificar Alertas por email Recibir alarmas desde Persona Notificada

estación por SMS

Email Email
SMS

Persona Notificada Notificar Alertas por SMS

por email
 ¿Cómo modelar requisitos NO
funcionales?
 Ni las notaciones del enfoque estructurado ni UML abordan la especificación de
requisitos no funcionales.
Reliability
Understability
 ISO/IEC 25010. Complianc
Recoverabilit e
Learnability
Operability
y Fault Tolerance
Attractiveness
Maturity
Usability
Suitability Reliabilit Usability Complianc
e
y
Accurac Time
Requisitos funcionales y Calidad behavior
Interoperability Interna Resource
utilizatio
y
Security Functionality Efficiency n
Externa
Efficiency
Fucntionalit
Complianc
y Portabilit Maintainability e
Complianc Maintainabili
e Adaptabilit
y ty Compliance
y Testeability
Installability
Stabilit
Co-exitence
y
Changeability
Replaceability Portability Analyzability
Complianc ISO/IEC 9126  ISO 25010
e
Requisitos No Funcionales
Principalmente Importante para:
Usuarios Desarrolladores
Availability Disponibilidad Maintainability Mantenibilidad
Efficiency Eficiencia Portability Portabilidad
Flexibility Flexibilidad Reusability Reusabilidad
Integrity Integridad Testability Testeabilidad
Interoperability Interoperabilidad
Reliability Confiabilidad
Robustness Robustez
Usability Usabilidad
RNF - Usuarios
El sistema deberá́ estar 99.5% disponible en los días de la semana
Disponibilidad entre las 6:00hrs y las 24:00hrs y al menos 99.95% disponible entre
(Availability) lasa 16:00hrs y 18:00hrs.

Al menos 25% de la capacidad del procesador y de la memoria RAM

Eficiencia del computador deberá́ estar libre en las horas de mayor cargar de
(Efficiency) trabajo (16:00hrs a 18:00hrs).

Un programador que tenga al menos seis meses de experiencia

Flexibilidad dando soporte a este producto deberá́ ser capaz de lograr que el
(Flexibility) producto pueda imprimir en un nuevo dispositivo de impresión en
menos de una hora de trabajo.

Integridad Únicamente los usuarios que tengan privilegios de acceso como

(Integrity) auditores podrán ver los históricos de transacciones de los clientes.
RNF - Usuarios
El sistema deberá́ poder importar los datos de reservas del hotel
Interoperabilidad desde los archivos DBF de la aplicación que actualmente es usada
(Interoperability) en recepción.

Confiabilidad No más de 3 transacciones de ventas mayores a $500.000 pesos

(Reliability) pueden perderse por fallas del software.

Si el editor de textos deja de responder antes de que el usuario

Robustez grabe el archivo, el editor deberá́ poder recuperar todos los
(Robustness) cambios hechos hasta 1 minuto antes de que el editor dejo de
funcionar.

Usabilidad Un usuario entrenado debe ser capaz de registrar una reserva de

(Usability) habitación en un máximo de 4 minutos.
RNF - Desarrolladores
Mantenibilid
Si la empresa decide cambiar de BD, un programador deberá poder
ad modificar las rutinas de conexión hacia la nueva BD en no mas de
(Maintainabi 20HH.
lity)

El módulo de impresión remota del sistema deberá poder funcionar

Portabilidad en versiones de Windows 7, Windows 10, Mac OSx 10.13.6 y
(Portability) Ubuntu (versiones 16.04 en adelante).

Reusabilida
d El modulo de exportación de reportes en formato XML deberá poder
(Reusability ser reusado en todas las aplicaciones para retail.
)

Testeabilida
d La complejidad ciclomática de un modulo no deberá exceder de 20.
(Testability)
 Modelo de
Análisis y Diseño
 Diagrama de Clases
 El Diagrama de Clases es el diagrama principal para
el análisis y diseño del sistema
 Un diagrama de clases presenta las clases del
sistema con sus relaciones estructurales y de
herencia
 La definición de clase incluye definiciones para
atributos y operaciones

 El modelo de casos de uso debería aportar

información para establecer las clases, objetos,
atributos y operaciones
Ejemplos - Asociación
dirige directo
Departamento Profesor
r
0..1 1

empleador trabajadores
Empresa Empleado
* 1..*

Cargo
superior
nomb
re 0..1
sueldo
subordinado 1..*
Ejemplos - Generalización
Trabajador

{ disjunta, completa }

Directivo Administrativo Obrero

Ejemplos – Mezcla de abstracciones
Motor Piloto Vendedor de billetes

1..4 1..2 1

1 n
n
1 n 1 n
Avión Vuelo Reserva

n
{ disjunta, completa }

Avión militar Avión comercial Línea aérea

{ disjunta, completa }

Avión de carga Avión de pasajeros

Diagrama de Clases como Modelo
de Análisis
DECTNumb
er
Plac
e
1 *
EIBAddre
ss
+address: String
formato
address:
+number: +deviceType: 999/999/999
String DeviceType
* 0.. 0..
1 1
*
*
DECTGro
up * 0.. Locatio * Roo Even
+name: String 1 n m t
+notyfyFrom: +name: 1 +number: -dateTime:
Hour String String Date
+notifyUntil: -type:
Hour 1 EventType
1..*

* 0..
1 1
* Be
d Presenc
NotificationDefiniti +name: e Needed only when NO
on String -state:
+event: PresenceState control record is stored
0..
EventType 0..
1
+message: 1 *
String
+tono: Int 1 *
ControlRecor 0..
Reside d 1 Employe
nt +controlName: String e
+name: +controlTableName: String 1 +name:
1 *
<<enumeration>> String * String
EventType +recordType: Int[0..1]
<<enumeration>>
<<newWF>>+call PresenceState Persistence of classes
<<enumeration> controlTableName and recordType
+presence > coloured
+called must be included in this class only if
+cancel DeviceType in ligth red is provided by
+presence
+timeOutDismissed +PC ResiPlus Database. Their the solution
+cancelled
+timeOutCancelled +PP includes ResiPlus. Furthermore, only if tableName is
+finished data should be stored in DE
+dismiss +TB "ResiRegistros", recordType indicates the "IDTipoRegistro"
+dismissed Database in case of ResiPlus
+control
wasn't included in the used as a
+finish
solution foreign key to the ResiPlus table "TiposRegistros"
Diagrama de Clases como Modelo
de Análisis
if the place has already an open presence.
cal cal Record new calls if they came from a
l l different addresses and with 1 value, else
timeOutDismiss ignore them
Dismiss ed Called
ed

presenc
e call:
canc cal
Events It is the reception of NotiFyEvent
el l
timeOutDissmissed, with one address of type PC o TB
timeOutCancelled, and Presenc associated
cancel generate e to the place, and with value 1.0. In case of
deactivation of devices Cancelled repeated reception on this notification it will
(sending '0' to the timeOutCancell be recorded
correspondings addresses). ed but the presence will stay in the same state.
presence:
Events It is the reception of NotiFyEvent
control(Employee,ControlRecor with one address of type PP
ds) and finish(Employee) associated
control(Employee,
generate the same action ControlRecords) to the place, and with value 1.0
only when they came from the control(Employee, cancel:
Presence state ControlRecords) It is the reception of NotiFyEvent
finish(Employe finish(Employe with one address of type PP
e) e) associated
Finishe to the place, and with value 0.0
d
Any reception of NotiFyEvent that does not
accomplish these conditions will be ignored.

If ControlRecords is empty then this event must be

interpreted and recorded as one finish(Employee)
event
Modelo de Datos
Modelado de Datos en el Enfoque
OO
• En un “mundo OO ideal” no sería necesario el modelado de datos!!
• Los objetos se crearían y existirían mientras no se destruyan.
• La persistencia de un objeto sería transparente para el programador.
• El lenguaje de programación o el OODBMS se encargaría de persistir los objetos.

• En el “mundo OO actual” el uso de BD relacionales conlleva

sacrificios/incongruencias en la implementación.
• El programador escribe sentencias SQL en los métodos y explícitamente
materializa o desmaterializa objetos.
• De momento los frameworks de persistencia (p.e. Hibernate, ADO .NET Entity
Framework) constituyen una mejora.
 Modelado de Datos en el Enfoque
OO
 Si usamos una BD Relacional debemos obtener un Modelo Lógico Relacional (MLR) tal como
se hace en el enfoque estructurado
 ¿Cómo derivar un MLR a partir del Modelo de Análisis/Diseño expresado en Diagramas de
Clases?
• Transformar Diagramas de Clases en Diagramas E-R y posteriormente derivar el MLR.
• “Ver” los Diagramas de Clases como Diagramas E-R, considerando sólo las clases
persistentes y sus atributos persistentes. Derivar el MLR a partir de esta “visualización”.
Las pautas de derivación son similares a las usadas a partir de un Diagrama E-R
 ¿Qué notación y herramienta utilizar?
• Profile UML para modelado de datos junto a herramienta CASE
• Directamente modelar/implementar la BD a través de un editor de diagramas de tablas
provisto por el gestor de BD 
 Modelo de
Componentes y
Despliegue
Diagrama Componentes
Interfaz de Terminal Control y Análisis

Gestión de Cuentas Rutinas de conexión Acceso a BD

Diagrama de Despliegue
Servidor Central Control y Análisis

Acceso a BD

R
u
t
i
n
a
s

d
e

C
o Terminal de Consulta
n Interfaz de Terminal
e Rutinas de Coneccion
c
c
i
Punto de Venta o
Rutinas de Coneccion
n

Gestión de Cuentas Interfaz de Terminal

Diagrama de Componentes
. de Componentes y D. de
Ack indicate the acknowledge from the receptor, it takes "OK" (no error or
warning) or a string value representing some kind of warning or error

Despliegue
Operations:
- NotifyEvent(EIBAddesses: string[ ], Value: float, Ack: string)
with the list of EIBAddress and 0.0 as the value indicating deactivation of such
Operation:
addresses
- NotifyEvent(EIBAddesses: string, Value: float, Ack:string) with the list of EIBAddress and 1.0
-SendMessageDECT(DECTNumbers: string(3)[ ], Message: string(25), Tono: int,
as value, indicating activation of such addresses, or 0.0 in case of the event "cancel"
Ack: string) with the list of DECT numbers and the message
asociated to a PP device
- CheckAddresses(EIBAddresses: string[], Value: bit[], Ack: string)
- ImportAddresses(EIBAAddresses: string[], Ack: string)

ResiPlus DE Clien ResiPlus DE

KNX t Visualizer
<<WCF DE_Manager
KNX_Servic
Service>> <<ResiPlus TE
es Module>>
Principal

<<ResiPlus TE
UCPersonal Module>>
UCRegistrar

ResiPlus ResiPlus DE
Server Coordinator
DE_EventNotifier <<WCF DE_Monitorin
Service>> <<ResiPlus TE
g Module>>
DE_Services
UCControles

BD ResiPlus
DE <<ResiPlus TE
Historical Module>>
UCEResidentes
WorkFlowManag
BD DE er

It informs events finish(Employee) and control(Employee,

Controls) which ocurr in ResiPlus DE Visualizer. In addition
the open presences are updated asking to DE Coordinator
with a frecuency of 5 seconds
Micro Break
 ¿Qué rescato o creo que es
¡1 Cosa! importante recordar el modelado
¿Qué recuerdas? Orientado a Objetos?
Modelo de
Interfaz de
Usuario
 Diseño Interfaz Usuario
• El diseño de la interfaz de usuario es una parte esencial del proceso
de diseño de software.
• A través este diseño debemos asegurar que la interacción entre lo
humano y la máquina permitirá una operación y control efectivos del
hardware y software.
• Además, debe estar diseñado para que coincida con las habilidades,
experiencia y expectativas de sus usuarios antes de su uso.
 Representando la Interfaz de
Usuario
El concepto de experiencia de Usuario (UX) considera los factores y elementos
relativos a la interacción del usuario con un entorno de software o dispositivo
concretos, generando una percepción positiva o negativa de dicho servicio,
producto o dispositivo, en nuestro caso del software, por ello que es importante
conocer a nuestro usuario, su comportamiento, necesidades e intereses , para
lo cual se apoya en diversas disciplinas que estudian el comportamiento del usuario,
entre ellas, design thinking.
Prototipado
• El Prototipado de software se refiere a la generación de diseños o
implementaciones parciales de un sistema que simula el sistema final
que se desea lograr, con la finalidad de realizar revisiones sobre diversos
aspectos del sistema durante su desarrollo y permitir a los usuarios
interactuar y explorar sus posibilidades.
Prototipos • Generalmente, los prototipos se utilizan
para evaluar aspectos de usabilidad y
accesibilidad, permitiendo al equipo de
desarrollo comprobar requisitos, elegir
el diseño de las interfases de usuarios
y permiten otorgar una visibilidad al
concepto de diseño centrado en el
usuario de forma temprana en las
primeras fases del desarrollo.
Micro Break
 ¿Qué rescato o creo que es
¡1 Cosa! importante recordar el modelado
¿Qué recuerdas? de Interfaz de Usuario?
04 Modelado en
metodologías para
desarrollo de SW
Especificación de
Requisitos Basada
en Problemas
(Sugerida)

Souza, R. G. M., & Stadzisz, P. C. (2016). PROBLEM-BASED SOFTWARE

REQUIREMENTS SPECIFICATION. Revista Eletrônica de Sistemas de
Informação, 15(2), 2. https://doi.org/10.21529/RESI.2016.1502002
 Qué es un “Problema”
• Artículo - PROBLEM-BASED SOFTWARE REQUIREMENTS SPECIFICATION
• Analizando el contexto de negocio del cliente, los problemas pueden ser definidos y su severidad especificada. De acuerdo a la
intensidad percibida del problema, el cliente puede estar motivado a resolver todo o un subconjunto de este.
• El problema es lo mismo que los propósitos, necesidades o objetivos del negocio.
• La existencia del problema podría sugerir una solución que puede variar desde un aspecto técnico como un software hasta la
contratación de nuevo personal.
• Si un cliente plantea un problema y sugiere una solución tecnológica, está describiendo una necesidad para el negocio.
• La descripción de la necesidad es lo que se obtiene producto de la solución implementada.

Souza, R. G. M., & Stadzisz, P. C. (2016). PROBLEM-BASED SOFTWARE REQUIREMENTS SPECIFICATION. Revista Eletrônica de Sistemas
de Informação, 15(2), 2. https://doi.org/10.21529/RESI.2016.1502002
 Qué es un “Problema”
• Tenemos una nueva oportunidad de negocios para llegar a este nuevo mercado digital
• Hemos crecido, pero los costos en nuestra bodega son muy altos debido a la falta de
control en nuestro inventario
• Tenemos multas que pagar al SII por no llevar una contabilidad ordenada.
• Sabemos que el negocio va bien, pero no tenemos datos que nos permitan entender bien
qué es lo que les gusta a nuestros clientes
• Tenemos fuga de clientes y la competencia está quitándonos los clientes. Creemos que
puede ser su nueva tecnología
• Tenemos una visión para los próximos 5 años y tenemos que realizar un cambio
corporativo. Es importante realizar una transformación digital para responder al mercado.
 Necesidades del Cliente
• Mientras exista un problema, existe una necesidad
no satisfecha, por lo tanto resolver la necesidad es
el resultado de la solución al problema.
• La necesidad está definida por clientes reales y
son parte del alcance del problema.
• Las necesidades tendrán, en general, un lenguaje
no técnico y simple para expresar lo que resuelve
el problema. Pero no son una descripción de una
funcionalidad.
 Necesidades del Cliente
• Tenemos una nueva oportunidad de negocios para llegar a este nuevo mercado digital
• Necesitamos un Ecommerce para atender a estos nuevos clientes
• Hemos crecido, pero los costos en nuestra bodega son muy altos debido a la falta de control en
nuestro inventario
• Necesitamos un sistema que nos ayude a gestionar nuestra bodega, un WMS podría
servirnos
• Tenemos multas que pagar al SII por no llevar una contabilidad ordenada.
• Tenemos que implementar un ERP para mejorar la contabilidad de la empresa
• Sabemos que el negocio va bien, pero no tenemos datos que nos permitan entender bien qué
es lo que les gusta a nuestros clientes
• Podría ser que un CRM sea lo mejor para obtener información de nuestros clientes
• Tenemos fuga de clientes y la competencia está quitándonos los clientes. Creemos que puede
ser su nueva tecnología
• Tenemos que desarrollar una nueva plataforma para entregar un servicio distinto
 Conceptos Claves
• Problema del cliente: Aquello
relativo a una dificultad que
requiere de una solución y que
representa un dolor o riesgo
• Concepto de software: Es la
referencia de la necesidad de
software que tiene el cliente.
• Visión de Software: Es una
mirada macro del tipo de
solución o software al que se
quiere llegar. Dependencia causal entre problemas, necesidades y requisitos
 Concepto de Software (elemplo)
Una empresa tiene fuertes dificultades para entablar relaciones de manera eficaz con sus
clientes y está convencida de que un sistema de información como CRM puede contribuir a
reducir estas dificultades.
 Visión del Software (ejemplo)
Una empresa tiene fuertes dificultades para entablar relaciones de manera eficaz con sus
clientes y está convencida de que un sistema de información como CRM puede contribuir a
reducir estas dificultades.
Cómo listamos los problemas
• Sustantivo: Indica quien está sufriendo el problema
• Verbo: Indica la severidad y la forma en que afecta al sujeto
• Objeto: El problema en sí que está
• Penalidad: El costo o dolor o dificultad, que es la consecuencia

• La empresa [Sustantivo] DEBE [Verbo] enviar un reporte dentro de 10 días posterior al

evento [Objeto] o se genera un 10% de multa sobre la facturación mensual [Penalidad]
 Cómo listamos la necesidades
• Sustantivo: Indica quien lo está necesitando
• Verbo: Indica lo que se desea
• Objeto: La solución
• Medio: Lo que producirá o proveerá el objeto. Siempre será el sistema informático
• Condición: Restricciones como plazos, precisión, entre otros

• El gerente [Sustantivo] necesita [Verbo] un sistema de información [Medio] para conocer el

balance de la cuenta del cliente [Objeto] cada trimestre [Condición].
 Especificación de requisitos
Ejemplo de un requerimiento (tradicional)
• El Sistema [Sustantivo] establecerá [Verbo] el bit recibido de la señal X [Objeto] dentro de los 2 segundos [Restricción] cuando se
reciba la señal [Condición]

Ejemplo de una Historia de Usuario (ágil)

• Como vendedor [Rol] quiero registrar los productos y cantidades que me solicita un cliente [Necesidad] para crear un pedido de venta
[Objetivo]
 Generación
04
05 ágil de
productos =>
Modelado Ágil
Core Ágil : Necesidades … deseos …
caprichos

“No tenemos sueños baratos”

¿Y si hay que esperar “demasiado”
para tenerlo?
¿Realmente necesitamos “tanto”, y
de inmediato?
7% Nunca
13% Rara vez
45% A veces
16% A menudo
Siempre
19%
Core Ágil: Discriminación de
Características
Elementos
“Conseguir cuanto antes NO
la solución más simple esenciales
que sea satisfactoria
para el cliente.
Es decir, que satisfaga
sus necesidades Elementos
esenciales de este
momento”. esenciales

Producto/Servicio
Proceso Iterativo e Incremental
Vs1 Vs2 Vs3

Backlog
Especificación y modelado Ágil
 Especificación y modelado realizados de forma iterativa e incremental.

 Postergar decisiones de diseño hasta justo antes de implementar la

especificación o modelado.

 Especificar o modelar con más intensidad solo cuando el esfuerzo en

hacerlo se rentabilice.

 Asumir posible re-trabajo.

 ¡1 Cosa!
¿Qué rescato o creo que es
¿Qué recuerdas? importante sobre el los requisitos
y necesidades del cliente?
04
06 Conclusiones
y Resumen
Modelado de SI: Algunas Reflexiones
 No todos aspectos de un sistema se especifican adecuadamente con
modelos UML. Por ejemplo, las pruebas, el diseño y navegación en las
IUs.
 Pragmatismo, los modelos deben ser útiles. Principio básico: “Sencillez
y Elegancia”
 Gestión de modelos
 Distintos nivel de abstracción, diferentes modelos
 Seguimiento de transformaciones durante el proceso (Traceability)
 Sincronización de modelos
 Dificultades para la introducción de notaciones y herramientas de
modelado. La importancia del Proceso de Desarrollo
Modelado de SI: Algunas Reflexiones
 ¿Cuál es el propósito de nuestros modelos?
• “Documentar” (a posteriori)
• Comunicar ideas y estudiar alternativas
• Tomar decisiones de análisis/diseño que dirijan la
implementación
• Generar parcial o totalmente una implementación a partir de los
modelos
 Generación automática de código a partir de modelos. ¿Es posible
generar el 100% del código? ¿el código generado debería “tocarse”
para ajustarlo?
 Próxima clase
• La próxima clase trabajaremos en una actividad práctica basada
en la adaptación de una metodología ágil según las necesidades
específicas de una organización.
 Demuestra lo
que aprendiste
Bibliografía
 8 consejos para realizar una gestión ágil de requisitos.
http://agilismoatwork.blogspot.com.es/2014/11/8-consejos-para-realizar-una-gestion.html

 Gestión ágil de requisitos o ¿cuál y cuánta documentación / especificación

es suficiente?. http://agilismoatwork.blogspot.com.es/2014/03/gestion-agil-de-requisitos-o-cual-y.html
 "Bueno, bonito y barato", ¿puede conseguirse esto con un método ágil?.
http://agilismoatwork.blogspot.com.es/2013/12/bueno-bonito-y-barato-puede-conseguirse.html

 Gestión "Ágil" de Requisitos

http://agilismoatwork.blogspot.com.es/2011/12/gestion-de-requisitos-agil.html
 Modelos de proceso para desarrollo ágil.
http://agilismoatwork.blogspot.com.es/2014/10/modelos-de-proceso-para-desarrollo-agil.html