Análisis de requisitos y estudio de viabilidad

1. 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.

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.

6. Estudio de viabilidad • Antes de comenzar un proyecto se realizará un estudio de viabilidad. Recogerá: • Análisis de alternativas • Evaluación de cada una de las alternativas, incluyendo su viabilidad técnica, legal, operativa, etc. • Especificación detallada de la alternativa escogida. • Establecimiento de fechas y compromisos de trabajo por parte de las personas y departamentos implicados. Se llevará a cabo el PLAN DEL PROYECTO

7. 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.

8. 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?

12. 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.

13. 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).

14. 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.

15. 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? • …

16. 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.

17. 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.

18. 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.

20. 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.

21. 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.”

22. ¿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”