Analizando el Problema

1
Analizando el Problema
2
El Dominio del Problema

• Hogar de los usuarios y otros stakeholders
• Gente cuyas necesidades deben ser atendidas
• Gente que necesita el producto
• Gente que no es como nosotros!
• Diferentes antecedentes técnicos y económicos
• Uso de lenguaje diferente al nuestro.
• Motivaciones que parecen extrañas y fuera de lugar

3
El Dominio del Problema
4
Características

• Un servicio que el sistema provee para satisfacer
  una o mas necesidades de los stakeholders
• Descripciones simples en el lenguaje del usuario
  usadas como referencia para comunicar al usuario
  como el sistema enfrenta el problema

5
Dominios de problema/solución
necesidades
Dominio del Problema
características
Requerimientos de Software
Dominio de la solucion
6
Software una actividad de Equipo

• El desarrollo de software se ha convertido en un
  deporte de conjunto-Booch 1998
• COCOMO Capacidades/Habilidades del equipo tiene
  un gran impacto en la productividad del software

7
Habilidades Equipo de Requerimientos.

• Análisis del dominio del problema
• Entender las necesidades del usuario.
• Definir el sistema.
• Administrar el alcance del sistema
• Refinar la definición del sistema.
• Construir el sistema correcto.

8
Habilidades Diferentes

• Trabajar con clientes
• Programación
• Conducción y Ejecución de Pruebas
• Habilidades de Diseño y Arquitectura
• Administración de Requerimientos !

9
Análisis del Problema

• Algunas aplicaciones resuelven problemas
• Otras aplicaciones toma ventaja de oportunidades
  en el mercado (la existencia del problema puede
  no ser clara)
• Análisis del problema
• El proceso de entender el problema del mundo real
  y las necesidades del usuario. Y proponer
  soluciones que satisfagan esas necesidades.

10
Que es un problema?

• Un problema puede ser definido como la diferencia
  entre lo se necesita y lo que se tiene
• A veces la solución mas simple es tomar un atajo
  o revisar el plan del negocio, en lugar de crear
  un nuevo sistema.
• Cambiar el deseo o percepción puede ser la
  solución mas rentable!

11
Análisis del Problema

• La meta del análisis del problema es obtener un
  mejor entendimiento del problema siendo
  solucionado antes de empezar el desarrollo.
• Obtener un acuerdo en la definición del problema
• Entender las causas raíz- el problema detrás del
  problema.
• Identificar los stakeholders y usuarios
• Definir la frontera del sistema
• Identificar las restricciones que se impondrán en
  la solución

12
1. Obtener un acuerdo en la definición del
problema

• Escribir el problema y ver si todo mundo esta de
  acuerdo.
• Pedirle al cliente que escriba los beneficios.
• Puede parecer simple pero este paso puede causar
  mucha discusión e involucrar emociones.

13
Formato para Especificar el Problema
14
2. Entender las Causas Raíz

• Obtener el entendimiento del problema real y de
  las causas reales
• Análisis de Causas Raíz
• Técnicas de Administración Total de la Calidad
  (TQM)
• Preguntarle a los directamente involucrados
  cuales son los problemas!

15
Diagramas fishbone
Inaccurate sales orders
Damaged in shipment
Customer returns
Too much scrap
Finished goods Obsolescence
Other
Manufacturing defects
16
Enfrentando la causa raíz

• La calidad de los datos puede demostrar que
  muchas causas simplemente no vale la pena
  arreglarlas.

17
Sales order problem statement
18
3. Identificar a los stakeholders y a los
usuarios

• Stakeholder
• Cualquiera persona que pudiera ser afectado por
  la implementación del sistema o aplicación.
• Muchos stakeholders son usuarios
• Otros son usuarios indirectos
• Afectados por las respuestas del negocio que son
  influenciadas por el sistema.
• Las necesidades de los stakeholders que
  no-usuarios también deben ser identificadas y
  tratadas.

19
Preguntas

• Quienes son los usuarios del sistema?
• Quién es el cliente (comprador) del sistema?
• Quién mas puede ser afectado por las salidas que
  el sistema produce?
• Quién evaluará y bendecirá el sistema cuando
  éste sea entregado?
• Quién mantendrá el sistema?

20
Users and stakeholders of new system
21
4. Definir la frontera del sistema solución

• La frontera define la división entre la solución
  y el mundo real que rodea a la solución.

inputs
outputs
system
22
Frontera del sistema

• El mundo dividido en dos partes
• Nuestro sistema
• Las cosas que interactúan con nuestro sistema

23
Actores

• Alguien o algo fuera del sistema que interactúa
  con el sistema

System boundary
I/O
Our solution
Other systems
I/O
users
24
Encontrando los actores

• Quien proveerá, usara o borrara información del
  sistema?
• Quien operará el sistema?
• Quien realizará el mantenimiento?
• Dónde será usado el sistema?
• De donde obtiene su información el sistema?

25
Perspectiva del sistema
Sales Order clerk
Legacy System With Pricing data
New sales Order entry
Billing clerk
System boundary
Shipping clerk
Production foreman
26
5. Identificar las restricciones del sistema.

• Las restricciones son las limitantes en el grado
  de libertad que tenemos en proveer una solución.
• Varias fuentes de restricciones.
• Calendario
• Valor de retorno
• Presupuesto para mano de obra y equipo.
• Cuestiones ambientales
• Sistemas operativos
• Bases de Datos
• Etc.

27
Restricciones

• Restricciones nos pueden ser dadas antes de
  empezar o podemos de manera activa
  identificarlas.
• Se deberá entender la perspectiva de la
  restricción.
• Se deberá saber cuando la restricción ya no
  aplica a la solución.
• Mientras menos restricciones, mejor !!

28
Restricciones Potenciales
29
Restricciones Potenciales
30
Resumen 5 pasos para análisis de problema

• Obtener acuerdo en la definición del problema
• Entender las causas raíz
• Identificar stakeholders y usuarios
• Identificar las fronteras del sistema
• Identificar las restricciones del sistema

31
Restricciones

• Propósito del producto
• Clientes, patrocinadores y otros involucrados.
• Usuarios del producto
• Restricciones en los requerimientos
• Convenciones en el uso de nombres y definiciones.
• Hechos y datos relevantes
• Suposiciones

32
Otros aspectos del proyecto

• Aspectos abiertos.
• Soluciones Off the shelf (COTS)
• Problemas nuevos
• Tareas
• Terminación
• Riesgos
• Costos
• Documentación de Usuario
• Tiempo