Análisis de requisitos y estudio de viabilidad

1º DAI. IES Azarquiel.

2

1. Introducción Todo proyecto tiene un punto de partida

Análisis de las necesidades cliente/usuario del sistema.

Establecer objetivos. Una vez obtenida una idea clara de los

objetivos que se desean conseguir, se debe evaluar la viabilidad del proyecto desde el punto de vista técnico, económico y legal.

Técnicas de recogida de información para análisis de necesidades y estudio de requisitos.

3

2. Cómo comienza un proyecto Para cada proyecto de desarrollo software

existen dos puntos de partida: A nivel de Empresa. A nivel de Proyecto.

El primero precede al segundo.

4

5

Inicio a nivel de empresa Los principales elementos que marcan el inicio de

un proyecto a nivel de empresa son: La decisión de emprender el proyecto.

Desarrollos internos (demanda interna). RFS, Request For Service: Indentificación Nombre Prioridad Plazo de terminación Breve descripción Fecha de recepción

Desarrollos contratados (demanda de un cliente). La selección del director o jefe del proyecto, que es el

responsable de establecer el entorno de inicio del proyecto.

Estudio de viabilidad Antes de comenzar un proyecto se realizará

un estudio de viabilidad. Recogerá:1. Análisis de alternativas2. Evaluación de cada una de las alternativas,

incluyendo su viabilidad técnica, legal, operativa, etc.

3. Especificación detallada de la alternativa escogida.

4. Establecimiento de fechas y compromisos de trabajo por parte de las personas y departamentos implicados. Se llevará a cabo el PLAN DEL PROYECTO

Análisis de alternativas Comprar un producto SW comercial ya

construido que cumpla los requisitos marcados.

Desarrollar el producto internamente. Desarrollar el producto externamente

mediante un contrato. Automatizar sólo parcialmente el sistema para

no tener que afrontar grandes gastos.

Selección del Jefe de proyecto Liderazgo sabe motivar. Capacidad de relación con equipo, clientes,

… Visión de negocio conocimiento,

negociación. Compresión técnica decisiones técnicas. Competencia en la gestión planificar y

controlar. Presteza y decisión capacidad analítica. Versatilidad y flexibilidad imprevistos,

anticipación Integridad reclutar personal adecuado. Previsión anticipación y aporte de

soluciones.

9

Inicio a nivel de proyecto El Jefe de proyecto debería establecer el entorno

inicial de trabajo del proyecto (incluso antes de verificarse la viabilidad).

Esta tarea incluye: Identificación de las áreas de riesgo Establecimiento de presupuestos Calendarios Planes de trabajo del personal Asignaciones de tareas Definir el soporte necesario para el equipo del proyecto Definir las técnicas de comunicación Requisitos de posibles subcontratas Interacción con los clientes

10

Inicio a nivel de proyecto Los resultados de estas actividades se

incluyen en la 1ª versión del Plan del Proyecto da respuestas a: Qué hay que hacer, cómo, quién lo hará, cuándo Qué herramientas y técnicas de gestión y

desarrollo se utilizarán.

11

3. Estudios de viabilidad: económica, técnica y legal … Los estudios de viabilidad deberían abordar los

siguientes aspectos: Económico: Determina si el beneficio obtenido

compensa los costes. Técnico: Estudia si la funcionalidad, el rendimiento y

las restricciones marcadas son realizables. Plazos y calendarios: ¿El plazo propuesto es realista?

¿Las fechas elegidas son apropiadas? Legal: Discutir si los requisitos atentan contra alguna

ley (Ej LOPD) o reglamento o a disposiciones legales de contratos, responsabilidad civil.

Operativo: Determina si se puede implantar de manera efectiva en la empresa. ¿Encaja en la filosofía de la empresa?

4. Análisis de necesidades. Técnicas de comunicación y recopilación de datos. Técnicas de recogida de información, pasos

del proceso de análisis: Identificar fuentes de información. Realizar preguntas apropiadas. Analizar la información. Confirmar con los usuarios. Sintetizar los requisitos.

12

4. Análisis de necesidades. Técnicas de comunicación y recopilación de datos. Técnicas de recogida de información:

Entrevistas. Desarrollo conjunto de aplicaciones (JAD). Prototipado. Observación. Estudio de documentación. Cuestionarios. Tormenta de ideas (Brainstorming).

13

5. Ingeniería de requisitos ¿Qué es? el conjunto de tareas que conducen

a comprender qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software.

¿Quién lo hace? Los ingenieros de software, junto con gerentes, clientes y usuarios.

¿Es importante? Construir un buen programa que resuelve problemas incorrectos no sirve a nadie.

¿Qué pasos tiene? Inicio, obtención, elaboración, negociación y validación.

¿Qué obtenemos? Explicación escrita del problema.

Tareas de la ingeniería de requisitos Inicio.

Identificación de los interesados: los que se benefician del sistema.

Reconocimiento de múltiples puntos de vista. Formulación de las primeras preguntas:

¿Quién ha pedido el trabajo? ¿Quién usará el programa? ¿Existe otra fuente para la solución? ¿Algien más puede proporcionar información adicional? …

Obtención. Recopilación conjunta de requisitos.

Reuniones más formales. Se utiliza un “mecanismo de definición”: hojas de trabajo, gráficos, hojas adheribles, foro electrónico, etc.)

Escenarios de usuario. Llamados frecuentemente casos de uso, proporcionan una descripción de cómo se usará el sistema.

Posibles productos: Enunciado de necesidad y factibilidad. Enunciado limitado del ámbito del sistema o producto. Lista de clientes, usuarios y otros interesados que participaron en la

obtención de requisitos. Descripción del ambiente técnico del sistema. Lista de requisitos (organizados por función) y las restricciones de d ominio. Conjunto de escenarios de suo que proporcionen un discernimiento de la

utilización del sistema o producto en diferentes condiciones de operación. Prototipos desarrollados para definir mejor los requisitos.

Cada uno de los productos los revisará la gente que ha participado en su obtención.

Elaboración. Desarrollo de casos de uso:

Identificar Actores. Caso de uso: historia de alto nivel que describe la

interacción entre el actor y el sistema. Se puede esfecificar de forma textual y/o gráfica:

Nombre. Actores. Meta en el contexto. Condiciones previas. Activador. Escenario. Excepciones.

Negociación. El cliente y desarrollador entran en un proceso en

el que se le debe pedir al cliente un balance de la funcionalidad, el rendimiento y otras caracteristicas del sistema frente al costo y el tiempo de colocación en el mercado.

Especificación. Puede ser un documento escrito, un conjunto de

gráficos, un modelo matemático formal, colección de escenarios de uso, un prototipo o una combinación de éstos.

Validación. Examina la especificación para asegurar que todos

los requisitos de software se han establecido de forma precisa. Detectado inconsistencias, omisiones, errores. Corregido. Se siguen los estándares del proceso, proyecto o

producto.

Gestión. Tablas de rastreabilidad de características, fuente,

dependencia, subsistema o interfaz.A01 A02 A03 …

R01

R02

…

Requisitos funcionales y no funcionales Requisitos funcionales: describen la funcionalidad o los servicios que se

espera que el sistema proveerá, sus entradas y salidas, excepciones, etc.Ejemplos:

1.- “El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella.”

2.- “El sistema deberá ofrecer un explorador (browser) para que el usuario lea documentos en el almacén de documentos.”

Requisitos no funcionales: se refieren a las propiedades emergentes del sistema como la fiabilidad, el tiempo de respuesta, la capacidad de almacenamiento, la capacidad de los dispositivos de entrada/salida, y la representación de datos que se utiliza en las interfaces del sistema. Ejemplos:

1.- “Será necesario que la comunicación requerida entre el APSE y el usuario se pueda expresar utilizando el conjunto de caracteres estándar de ADA.”

2.- “El proceso de desarrollo del sistema y los documentos a entregar estarán sujetos al proceso y a los productos a entregar definidos en XYZCo-SP-STAN-95.”

3.- “El sistema no deberá revelar a sus operadores información personal alguna de los clientes excepto su nombre y número de referencia.”

¿funcionales o no funcionales? “Los participantes tendrán que ser mayores de edad” “Los participantes tendrán que residir en la península” “El valor de las pujas será mostrado en euros” “El IVA aplicado a las pujas ganadoras será del 7%” “La lista de resultados estará preparada para ser

impresa en un folio tamaño A4” “El sistema lanzará una excepción en caso de que un

usuario quiera cargar un importe mayor que el saldo de la cuenta”

“Los accesos a la BD deberán usar el estándar SQL-92” “Los registros de la BD no deben ocupar más de 4 Kb” “El sistema deberá ser capaz de interactuar con 100

usuarios concurrentes”