ANALISIS DEL NEGOCIO

Abstracción - Modelado Visual (MV)

“El modelado captura las

partes esenciales del sistema”

Orden

Item

envío

Proceso de Negocios

Sistema Computacional
MODELADO DE NEGOCIO
 El “Modelado de Negocios” se define como un proceso de
representación de uno o más aspectos o elementos de una
empresa, tales como:
 Su propósito
 Su estructura
 Su funcionalidad
 Su dinámica
 Su lógica de negocios
 Sus componentes:
 Fines
 Procesos de negocio
 Reglas de negocio
 Objetos de negocio
 Actores
IDENTIFICACIÓN DE PARTICIPANTES
BPMN en el Modelado del Negocio
 La notación para gestión de procesos del negocio
(BPMN) es Notation (el estándar más reciente para
modelado de procesos del negocio y servicios web.

 BPMN es una notación necesaria para expresar los

processos de negocio en un único diagrama de proceso
de negocio (Business Process Diagram – BPD)

 BPMN permite hacer un mejor uso de la gestión de

procesos del negocio (BPM), ya que normaliza el
método de notación que sirve como ayuda en la
automatización de los procesos.
Ejemplo: Cuando en la solicitud de crédito, el analista de fábrica
decide solicitar nuevos documentos se deberán retomar las
actividades previas de recepción de documentación y análisis de la
misma. Este ciclo será llevado a cabo hasta cuando el analista
considere que la documentación y la información es la adecuada
para tomar la decisión.
Técnicas de relevamiento
(recolección) de información
 Entrevista.- Se selecciona a un conjunto de personas que represente a todos
los sectores críticos de la organización, con el énfasis puesto en los sectores más
afectados o que harán un uso más frecuente del nuevo sistema.
 Cuestionarios.- Consiste en el llenado formularios o contratos indicando
los requerimientos. En sistemas muy complejos éstos pueden tener centenares
de páginas. Y se usan cuando hay muchos usuarios, y es difícil entrevistarlos a
todos.
 Talleres.- Reuniones con varios usuarios para concertar requerimientos. Los
requisitos tienen a menudo implicaciones cruzadas desconocidas para las
personas implicadas individuales y que a menudo no se descubren en las
entrevistas o quedan incompletamente definidas durante la misma.
 Observación
 Revisión documental

10
10
Técnicas/Herramientas
 Prototipos.- Un prototipo es una pequeña muestra, de funcionalidad
limitada, de cómo sería el producto final una vez terminado. Ayudan a
conocer la opinión de los usuarios y rectificar algunos aspectos antes de
llegar al producto terminado.
 Casos de Uso.- Un caso de uso es una técnica para documentar
posibles requerimientos, graficando la relación del sistema con los usuarios
u otros sistemas.
 DFD’s

11
Fuentes de información
 Personas:
 Usuarios directos e indirectos del sistema
 Colegas con experiencia
 Otros sistemas
 Internet
 Documentos de la empresa/ Reglamentos
 Libros relacionados con el software a construir

De todas estas fuentes las personas son la fuente más

relevante .

12
Especificación y análisis de requerimientos
Que es un requisito?
 Es una condición o capacidad que debe cumplir o
poseer un sistema o componente de un sistema para
satisfacer un contrato, Standard, o especificación o
algún otro documento impuesto.
 El conjunto de requisitos forma la base para el
desarrollo de un sistema o un componente de sistema.
Qué es un Requerimiento?
 Puede variar desde unos estatutos abstractos en alto
nivel de un servicio o unas restricciones del sistema
hasta una especificación funcional matemática
detallada.
 Los Requerimientos pueden servir como una función
dual
 Puede ser la base para la declaración de un contrato, por
lo tanto, deber estar abierto a interpretación.
 Puede ser la base para el contrato en sí, por lo tanto,
debe ser definido en detalle.
 Ambas declaraciones serán llamadas Requerimientos.
Qué es un Requerimiento?
 Es un aspecto del contenido o comportamiento del
producto, requerido o deseado por el cliente.
 Requerimientos funcionales. (Debe hacer)
 Requerimientos no-funcionales.(Debe tener)

 Una restricción es un requerimiento que afecta a todo el

producto.
Requisitos funcionales y no funcionales
 Requisitos funcionales: describen lo que el sistema
debería hacer
Ej.: el sistema debe proveer autenticación de la identidad de un usuario
Ej.: el sistema debe emitir una factura

 Requisitos no funcionales: establecen restricciones

de cómo estos requisitos funcionales son
implementados.
EJ.:el proceso de autenticación debería completarse en menos de 4
segundos
EJ.: la emisión de factura debe poder hacerse desde cualquier terminal
de trabajo
 PROCESO
Estudio de Análisis de
Factibilidad Requerimientos

Definición de
Reporte de Requerimientos
Factibilidad
Especificación
Modelos del de Requerimientos
Sistema
Definición de
Requerimientos
Documento de
Requerimientos Especificación de
Requerimientos
El Analista de Requerimientos
Patrocinador del Proyecto Administrador del Proyecto

requerimientos Factibilidad,
del negocio Tiempos y costos

requerimientos
requerimientos funcionales
del cliente/usuario
y no-funcionales

Cliente y Desarrolladores
Usuarios

Analista de Requerimientos
restricciones y requerimientos funcionales
requerimientos y no-funcionales

Otros interesados Pruebas

en el sistema
Fases de la especificación y análisis de
requerimientos
 Blastoff (arranque)
 Recolección de requerimientos
 Prototipos
 Verificación y validación
 Revisiones
 Post-Mortem
 Blastoff
Preparación para el inicio del proyecto
 Reunión entre los principales desarrolladores, clientes
y usuarios
 Del Blastoff se obtienen:
 El contexto
 Propósito del proyecto
 Lista de principales riesgos
 Estimación inicial del esfuerzo
 Decisión de seguir adelante o no
 Identificación clara de los interesados
 Compromiso con el proyecto
 Formación de equipos
 Blastoff (continuación)

 Determinar el propósito del producto:

1. Escribir el una frase el objetivo/propósito del producto
2. Cuál es la ventaja/solución que ofrece?
3. Definir cómo medir el éxito.
Además:
4. Es realista / factible?
5. Lo desean todos los interesados (stakeholder)?
Propósito del producto:

 Todos los demás requerimientos son

verificados/validados en torno a su contribución al
propósito del producto.
 Qué ventaja o solución queremos que ofrezca el
producto?
 El producto tiene un criterio de validación
medible/verificable.
 La satisfacción es un factor en el valor del producto.
Identificación de las personas
interesadas:
 Patrocinadores
 Clientes
 Usuarios
 Especialistas
 Ingeniero de requerimientos
Estimado inicial de costo/esfuerzo
 Primera medición del tamaño del sistema:
 Número de sistemas adyacentes
 de dominios,
 entradas y
 salidas.
Recolección de Requerimientos
 En esta etapa se deben
 Extraer los requerimientos de los usuarios
 Descubrir el mayor número posible de
requerimientos
 Utilizar diferentes métodos para los
requerimientos conscientes, inconscientes
y los no-imaginados
 Identificación de eventos y
Casos de uso
 Los eventos se identifican por las
entradas y salidas del trabajo
 Los eventos son:
 algo que sucede fuera del trabajo y a lo
que el trabajo debe responder.
 Importante
 Reconocible.
Tipos de Requerimientos

 Restricciones globales
 Requerimientos Funcionales
 Requerimientos No-Funcionales
 Restricciones globales
 Afectan a todo el producto y son determinadas por el
usuario y los que administran el proyecto/producto.
1. Propósito del sistema
2. El cliente
3. El usurio
4. Convenciones para la nomenclatura y las definiciones
5. Hechos relevantes
6. Restricciones del proyecto
7. Suposiciones
Requerimientos Funcionales
 Lo que el producto debe hacer
Alcance del sistema
Requerimientos Funcionales y de datos
 Requerimientos No-Funcionales

 Apoyan a las funciones, son las propiedades que el

producto debe tener.
10. Apariencia y sensación
11. Usabilidad
12. Performance
13. Operabilidad
14. Mantenibilidad
15. Seguridad
16. Requerimientos Políticas
17. Requerimientos legales
 Registro de los requerimientos:
 Para manejar los requerimientos, estos deben tener:
 Un número único de ID
 Tipo
 Lista de los eventos y casos de uso que lo contienen.
 Descripción: una frase que describe la intención del
requerimiento.
 Propósito: Por qué se considera importante?
 Fuente: ¿Quién determinó este requerimiento
Registro de los requerimientos (cont.)
 Criterio de evaluación: Prueba no-ambigua que indica si
una solución cumple este requerimiento
 Satisfacción del cliente: Grado de satisfacción si el
criterio se cumple exitosamente (1=no importa mucho-
5=muy satisfecho)
 Insatisfacción del cliente: Grado de insatisfacción si el
criterio no se cumple (1=no importa mucho-5=muy
molesto)
Registro de los requerimientos (cont.)

 Dependencias: requerimientos que usan la misma

información o que ocasionan cambios.
 Conflictos: requerimientos que estan en conflicto con
este
 Materiales de apoyo: Indicación a las definiciones y
documentos que lo ilistran.
 Historia: Creación, cambios y eliminación
 Requerimientos Funcionales
 Describir una acción que debe realizar el producto
 No escribir soluciones
Cada evento/caso de uso tiene muchos requerimientos
funcionales
 Algunos son parte también de otros eventos
 Iniciar descomponiendo los casos de uso en pasos:
 serie de pasos para completar el trabajo de un caso de uso
 Acciones que puede reconocer el usuario
 Posiblemente una interacción entre usuario y máquina
 número limitado de pasos

El uso del formato ayuda para determinar qué tan completa está la
especificación de requerimientos.
 Requerimientos No-Funcionales
 Describen las propiedades o características que el producto debe tener.
 Cada requerimiento funcional tiene asociados requerimientos no-
funcionales
 Algunos pueden afectar a nivel de eventos, otros a todo el producto.
 Requerimientos no-funcionales:
 Apariencia y sensación: (Bosquejos)

 Usabilidad: Depende de la definición de los usuarios, cuantificable

por los criterios de evaluación.
 Performance: Requerimientos reales del performance, velocidad,
presición, disponibilidad, seguridad, nivel de servicio, volúmenes de
datos, etc.
 Operacional: Ambiente en el que el usuario operará el producto y
productos con los que colabora.
 Verificación y Validación de Requerimientos

 Prevenir la infiltración de requerimientos: los que entran

al producto depués del proceso de análisis de
requerimientos.
 Prevenir la fuga de requerimientos: aquellos cuya fuente se
desconoce
 Estos incrementan desmesuradamente el costo y el tamaño
del producto.
 Se pueden usar métricas de función para controlar la
infiltración de requerimientos.
 El número de function points puede ser una medida para
limitar el tamaño del desarrollo.
Criterios de Validación
 Es una meta numérica que la solución debe cumplir.
 No se puede diseñar una solución a un requerimiento sin una manera
de saber si se ha logrado resolverlo o no.
 Para los requerimientos funcionales el criterio especifica cómo
establecer si cumple sus objetivos.
 Para los requerimientos no-funcionales cuantifican el comportamiento
resultante.
 Reutilización de Requerimientos
 Generalmente los sistemas no son completamente únicos en
todos sus componentes
 Hay oportunidad de reutilizar requerimientos
 Aunque puede ser difícil reconocer los componentes
reusables
 Con la ayuda de abstracción y el uso de patrones de
requerimientos es mas fácil
 Patrones: guías reusables que se pueden adaptar a
circunstancias específicas, se pueden abstraer de cualquier
tipo de sistema.
 Estos patrones se pueden basar en los casos de uso.