Ingeniería de Software - profesores.fi-b.unam.mxprofesores.fi-b.unam.mx/adanzg/SwEng/Presentaciones/05VisionProyecto.pdf · Ingeniería de Software Visión del Proyecto Página 20

Ingeniería de Software Visión del Proyecto Página 0

Ingeniería de Software.

La Disciplina de Determinación

de Requerimientos:

Visión del Proyecto.


Mapa del Proceso.


Entrevistas con el "dueño" del proyecto.

Para determinar la visión del proyecto, primero hay que

entrevistar al "dueño" del proyecto para definir los

requerimientos funcionales de alto nivel:

• El "dueño" del proyecto es cualquier persona con poder

de decisión en la empresa que es responsable de que

el sistema funcione.

• Un requerimiento funcional es una descripción de que

actividades debe llevar a cabo el proyecto para un

actor.


Tipos de Requerimientos.

Requerimientos Funcionales (FRs):

• Describen las características de un sistema que implican un actor

realizando operaciones de la empresa.

• Por ejemplo: el sistema debe registrar la siguiente información del

cliente: nombre y dirección.

Requerimientos No-funcionales (NFRs):

• Describen las características de un sistema que implican como se

debe llevar a cabo una operación.

• Por ejemplo: el sistema debe soportar 10 usuarios simultáneos en

una aplicación Web.


Habilidades del Entrevistador.

• Siempre prepararse aunque se tenga experiencia.

• Escuchar cuidadosamente.

• Construir rapport (confianza) con el entrevistado.

• Empezar con conversación ligera (NO chistes).


• Llevar la entrevista en la dirección deseada, no interrumpir al

entrevistado a menos que se salga demasiado del tema, pero

hacerlo con mucho cuidado.

Entrevistar no es algo fácil. Se requiere práctica y

experiencia. Agunos tips:


Habilidades del Entrevistador (2).


• Refrasear ideas no muy claras y validarlas preguntando.


• Tomar notas detalladas.


• De preferencia no usar grabadora y si se decide hacerlo

solamente con permiso.



Enfoque de la Entrevista de Visión.

Las entrevistas iniciales para determinar la visión del

sistema se deben enfocar en los siguientes aspectos:

• Importancia real del proyecto (business case).

• Requerimientos funcionales.

• Riesgos.

• Restricciones.

• Involucrados (stakeholders).


Preguntas para Determinar la Importancia.

Lograr que el dueño del sistema explique por qué necesita

el software.

• ¿Cómo opera la empresa actualmente?

• ¿Qué hace, fabrica o vende la compañía?

• ¿Cómo está estructurada la empresa?

• ¿Es posible obtener un organigrama de la empresa?

• ¿Cómo va a soportar el nuevo software los procesos de la

compañía?

• ¿Cómo está cambiando su negocio?

• ¿Hay planes de expansión?

• ¿Cómo se podría reorganizar la compañía?


Preguntas para Descubir los Requerimientos

Funcionales.

Lograr que el dueño del sistema explique que debe hacer

el software para el negocio.

• ¿Cuáles son los principales casos de uso del sistema?

(Normalmente entre 5 y 10.)

• Reiterar los casos de uso.

• Verificar la comprensión de los casos de uso.

• ¿Cuáles son las prioridades de los casos? En términos de esenciales, requeridos, deseables (o algo similar).

• Reiterar la lista de los casos de uso y preguntar siempre si pueden faltar algunos.


Preguntas para Descubrir Riesgos.

Hay 5 áreas principales de riesgo. Algunas preguntas que

ayudan a identificar riesgos del proyecto.

• ¿Hay otros grupos en la empresa haciendo funciones similares?

• ¿Se piensa usar nuevas tecnologías de software en el proyecto?

• ¿Se cuenta con recursos de desarrollo internos o se planea subcontratar a empresas externas (outsourcing)?

• ¿Los miembros del equipo tienen las habilidades necesarias?

• ¿Qué partes del negocio relacionadas con el sistema es probable que cambien?


Preguntas para Descubrir Restricciones.

Este tipo de preguntas ayudan a descubrir restricciones

ocultas en los proyectos:

• ¿Se debe usar una plataforma específica?

• ¿Se requiere alguna tecnología en particular?

• ¿Hay una fecha límite fija?

• ¿El sistema debe interaccionar con otros sistemas

externos?

• ¿Cuáles son las restricciones en el lado operacional del

software?


Preguntas para Descubrir Involucrados.

Preguntar los nombres de los involucrados con preguntas

como las siguientes:

• ¿Quiénes tienen autoridad para tomar decisiones respecto a

los requerimientos funcionales del sistema?

• ¿Quiénes usarán el sistema?

• ¿Quiénes supervisarán a los usarios del sistema?

• ¿Quiénes manejarán la operación del sistema?

• ¿Quiénes manejarán el desarrollo del proyecto?


Análisis de la Entrevista de Visión.

A partir de las notas de la entrevista el ingeniero de

software debe identificar:

• Requerimientos funcionales.

• Requerimientos no-funcionales.

• Riesgos.

• Restricciones.


Identificación de Requerimientos No-funcionales.

En ocasiones, el dueño del negocio puede sugerir

requerimientos no-funcionales, principalmente respecto

a la calidad del servicio, que se deben registrar.

• Frases como las siguientes pueden ser NFRs:– El tiempo de respuesta debe ser realmente rápido.

– Tenemos muchos registros de clientes en la base de datos.

– El sistema debe soportar hasta 100 usuarios.

• Tecnologías específicas mencionadas pueden ser restricciones o NFRs: – Queremos que nuestros clientes usen el sistema vía Web.

– Usamos ORACLE en otro proyecto.


Riesgos y Restricciones.

• Los riesgos y las restricciones “van de la mano”.

• Generalmente las restricciones implican ciertos riesgos y

los riesgos pueden provenir de restricciones impuestas.

• Por ejemplo:

– Restricción: fecha límite fija.

– Riesgo: no terminar en esa fecha.


Identificación de Riesgos.

• Los riesgos no atendidos son la razón principal porque

los proyectos fracasan.

• Se deben identificar los riesgos lo más pronto posible y

crear una estrategia para manejarlos.

• Hay 5 áreas de riesgos principales:

– Políticos.

– Tecnológicos.

– De recursos.

– De habilidades.

– De requerimientos.


Riesgos Políticos.

Existen riesgos políticos cuando:

• Hay un proyecto similar o un competidor.

• El jefe del administrador del proyecto ha cancelado o

disminuido fondos, equipo o recursos humanos en el

pasado.

• Hay problemas interpersonales o incluso "pleitos" entre

el grupo de desarrollo o la jerarquía gerencial.

• El proyecto tiene conflictos con leyes o regulaciones

gubernamentales.


Riesgos Tecnológicos.

• Existen riesgos tecnológicos cuando el proyecto podría

usar una tecnología no suficientemente probada,

demasiado nueva o difícil de utilizar.

• Algunos signos de advertencia:

– El dueño del proyecto usa muchas palabras de tecnología

avanzada aunque no entiende claramente su significado.

– El dueño insiste en que el proyecto tome una dirección

tecnológica específica.

– El dueño del proyecto quiere usar tecnología de punta para

resolver un problema de negocio.

– El nuevo sistema debe integrarse con un sistema antiguo

(legacy).


Riesgos de Recursos.

• Existen riesgos de recursos cuando el proyecto no tiene

todos los recursos (humanos, equipo, dinero) requeridos

para su terminación existosa.


– El dueño del proyecto menciona restricciones presupuestales.

– El personal técnico esta sobrecargado de trabajo.

– El proyecto tiene un calendario demasiado estrecho.


Riesgos de Habilidades.

• Existen riesgos de habiidades cuando el equipo de

desarrollo no tiene los conocimientos o experiencia

necesarios para llevar a cabo el trabajo.


– El proyecto debe usar una tecnología específica pero no se ha

proporcionado entrenamiento en esa área.

– El proyecto se va a programar en cierto lenguaje que no

conocen los desarrolladores.


Riesgos de Requerimientos.

• Existen riesgos de requerimientos cuando algún caso de

uso o un requerimiento funcional no se conocen

completamente.


– Cuando el dueño del sistema dice algo así: "lo sabré cuando lo

vea".

– Cuando el dueño del sistema no puede visualizar los detalles de

un caso de uso.

– Cuando el dueño del sistema no conoce que existe un caso de

uso.


Creación del Documento de Visión.

• El Documento de Visión registra la Visión General del

sistema de software y documenta los riesgos y

restricciones.

• Generalmente hay cinco secciones en el documento:

1. Introducción que incluya el postulado del problema.

2. Oportunidades de negocio.

3. Solución Propuesta incluyendo FRs y NFRs.

4. Riesgos.

5. Restricciones.

• El Documento de Visión debe ser tan claro y conciso

como sea posible.


El Postulado del Problema.

• El Postulado del Problema es un sumario del problema de la

empresa. No tiene que incluir necesariamente todos los FRs o casos

de uso, pero sí los más importantes.

• Ejemplo:

El Sistema de Reservaciones de Bay View Hotels será responsable

del manejo de las reservaciones para varios tipos de hoteles que

incluyen al menos hoteles familiares y de negocios. El sistema debe

incluir una aplicación web que permita a los clientes ver fotografías

de los hoteles y de los cuartos, así como las reservaciones activas y

pasadas y hacer nuevas reservaciones. El sistema también debe

programar conferencias o convenciones de negocios.


Las Oportunidades de Negocio.

• Esta sección del Documento de visión debe registrar la visiónpresente y pasada de la compañía y de que manera el sistema desoftware va a ayudar al negocio.

• Ejemplo:

Bay View Hotels es una compañía hotelera familiar que empezó en1987 en Santa Cruz, California por los copropietarios Peter and MaryJane Parker que fundaron un hotel familiar. En 1995 compraron otrohotel orientado a viajeros de negocios en Sonoma, California. Elnegocio ha crecido satisfactoriamente en estos años. Recientementeen unas vacaciones los dueños conocieron un hotel de descanso,cuyo dueño quería retirarse. Esta es la oportunidad que esperabanpara expandir el negocio, de manera que actualmente están a puntode cerrar esta nueva compra. El Sistema de Reservaciones de BayView Hotels se propone para integrar las 3 localidades actuales y lasfuturas.


La Solución Propuesta.

• Esta sección del Documento de visión registra todos los requerimientos funcionales (FRs) y no-funcionales (NFRs) identificados por el dueño del sistema.

• Incluye una lista de los FRs como frases breves que describen como usan los actores el sistema.

• Por ejemplo: – El sistema debe incluir una aplicación web, en varios idiomas,

que incluya fotografías de los hoteles y los cuartos.

– El sistema debe integrar las reservaciones en todos los hoteles.

– Los recepcionistas deben poder recibir (check-in) y despedir (check-out) a los clientes.

• Agrupar los FRs en categorías por prioridad.


La Solución Propuesta (2).

• También se deben describir los NFRs identificados durante las entrevistas iniciales.

• Ejemplo:

– Las reservaciones on-line vía web, no deben tomar más de 10 minutos de principio a fin.

– Habrá a lo sumo 10 reservaciones por minuto actualmente.

– Se espera un incremento a 20 transacciones por minuto en 5 años.

– Posiblemente se llegue a 50 transacciones por minuto en 10 años.

– El sistema debe ser capaz de aceptar la integración de más hoteles en el futuro.


Riesgos

• Esta sección del Documento de Visión debe registrar todos los

riesgos que se identificaron en las entrevistas iniciales.

• Ejemplo:

El riesgo principal de este proyecto que los datos actuales

existentes en hojas de cálculo en los hoteles de negocios y archivos

planos en los familares, parece que no tienen información muy

confiable y se tienen que converitir a base de datos. Otro riesgo

potencial es el punto de inflexión costo/beneficio de outsourcing o

desarrollo interno, puesto que hay restricciones presupuestales. El

plan para mitigar estos riesgos se presentará en el documento de

Especificaciones de Requerimientos del Sistema (SRS).


Restricciones.

• Esta sección del Documento de Visión registra todas las

restriciones que se identificaron en las entrevistas

iniciales.

• Ejemplo:

Debido a los gastos de compra del nuevo hotel, los dueños no pueden

adquirir herramientas caras como un Manejador de Bases de Datos o

un Servidor de Aplicaciones. Debemos utilizar herramientas Open

Source probadas.


Ejercicio 1: Características del Documento de Visión.

Sección Descripción.

a. Introducción. 4 1 Contiene la visión pasada y presente de la compañía.

b.Oportunidades

de negocio. 12 Contiene requerimientos de alto nivel.

c. Solución

Propuesta. 23 Contiene problemas potenciales que pueden afectar el

proyecto.

d. Riesgos. 3 4 Contiene el Postulado del Problema.

e. Restricciones. 5 5 Puede definir límites impuestos a los recursos del

proyecto.

Relacione la sección del Documento de visión con su contenido.


Ejercicio 2: Entrevista.

• Prepare cuidadosamente la entrevista inicial con el

Director General de la Arrendora de Coches Limón,

S.A. para determinar los requerimientos iniciales del

sistema que desea desarrollar.

• Lleve a cabo la entrevista.


Ejercicio 3: Desarrollo del Documento de Visión.

Basado en los resultados de la entrevista con el Dueño y Director

General de la Arrendadora de Coches Limón, S.A., escriba el

Documento de Visión del Sistema de Control de Renta Limón (RentLimo),

que incluya las cinco secciones:

1. Introducción, postulado del problema.

2. Oportunidades de negocio.

3. Solución Propuesta incluyendo FRs y NFRs.

4. Restricciones.

5. Riesgos.

Documents

Ingeniería de Software - profesores.fi-b.unam.mxprofesores.fi-b.unam.mx/adanzg/SwEng/Presentaciones/05VisionProyecto.pdf · Ingeniería de Software Visión del Proyecto Página 20