Ingeniería de Software

Presentación del tema: "Ingeniería de Software"— Transcripción de la presentación:

1 Ingeniería de Software
Especificación de Requisitos de Usuario según la ESA

2 Revisiones del URD Las salidas de esta etapa deben ser formalmente revisadas durante la actividad de revisión de Requisitos de Usuarios (UR/R). Están involucrados los: usuarios, clientes, analistas, administradores del proyecto, y los tésters. Es aconsejable realizar revisiones periódicas, antes de la revisión final. Eso mejorará la calidad y la disponibilidad del producto final de la fase (URD).

3 UR: Salidas de la Fase Documento de Requisitos de Usuario (URD).
1. Introducción 1.1 Propósito. Narrativa que describe el propósito del documento en particular. 1.2 Alcance o Ámbito. Narrativa consistente, que identifica el producto a ser producido, nombrándolo, explicando lo que el software hará, sus beneficios, objetivos y metas precisas, establece el alcance del sistema a desarrollar. 1.3 Glosario o Definiciones. Listado de acrónimos, con su significado. 1.4 Referencias. Se colocan una lista completa de las referencias de los documentos utilizados para construir el URD, identificadas por el título, autor y fecha, identificando aquellos documentos que son aplicables o solo son referencia. 1.5 Visión general, o apreciación global. Narrativa que describe a grandes rasgos, el sistema a desarrollar.

4 Ejemplo Propósito El propósito de este documento es presentar de manera detallada y formal el acuerdo que se ha realizado con el usuario, contemplando los requerimientos entregados por éste. De esta forma el equipo de desarrollo podrá llevar a cabo la implementación del sistema. El objetivo particular de esta fase, consiste en formar una base completa que pueda solventar las etapas posteriores. En consecuencia, el usuario y el equipo de desarrollo se comprometen a cumplir lo estipulado en el documento.

5 Ejemplo Alcance o Ámbito El sistema, definido según los requerimientos del usuario, tendrá como función principal mostrar y comprobar la trazabilidad de proyectos, trabajados bajo los términos del Estándar ESA para proyectos de Ingeniería de Software, particularmente bajo el Modelo de Desarrollo Iterativo e Incremental. El sistema contará con 3 tipos de usuario: Un "Administrador", varios "Jefe de proyecto" y varios "Supervisores". El Jefe de proyecto tiene la función de ingresar y modificar la información necesaria para la visualización de la traza. Por otra parte el Supervisor tendrá la labor de asignar, vigilar y aprobar/desaprobar cada Fase trabajada.

6 Ejemplo Visión General
En este documento se desarrollarán los requerimientos previamente entregados por el usuario. Este, además de tener un título, una descripción y un correlativo, tiene una clasificación por prioridades, lo cual ayudará para una próxima revisión del usuario de los requisitos formalizados. Además se definen todos los aspectos complementarios al proyecto, tales como: requerimientos de hardware, tipos de usuarios que ingresarán al sistema, descripción general del mismo, etc. En resumen, el documento detalla los aspectos iníciales del proyecto, los cuales son la base para el desarrollo del sistema.

7 UR: Salidas de la Fase Documento de requisitos de usuarios (URD).
2. Descripción General 2.1 Perspectivas del Producto. Narrativa que establece que es lo que se espera obtener con el producto de software en desarrollo. 2.2 Capacidades Generales. Se deben describir las capacidades principales y el porque son necesarios, asimismo se debe indicar los procesos que serán apoyados por el software 2.3 Restricciones Generales. Narrativa que establece cuáles son las restricciones de funcionamiento del software. 2.4 Características de los Usuarios. Narrativa que describe las características de los usuarios que afectan los requerimientos específicos.

8 Ejemplo Perspectiva del Producto
El sistema a desarrollar consistirá en demostrar la trazabilidad de proyectos bajo el estándar ESA PSS y el modelo iterativo incremental. Que además permitirá, de acuerdo al tipo de usuario, ver los errores en la trazabilidad del proyecto, y sobre quienes recae la responsabilidad de dicho error.

9 Ejemplo Capacidades Generales
El sistema permite según el privilegio del tipo de usuario administrar o visualizar la traza del proyecto. El sistema informará acerca de los errores de la traza de acuerdo al tipo de usuario, y dejará un registro de esto para su posterior control. También existirán instancias de usuarios que aprobarán las fases en que se encuentre el proyecto y los que gestionarán la información básica de este.

10 UR: Salidas de la Fase Documento de requisitos de usuarios (URD).
2.5 Ambiente Operacional. Narrativa que establece las características del escenario de trabajo del software, el cual debe estar apoyado por un Diagrama de Contexto.

11

12 UR: Salidas de la Fase Documento de requisitos de usuarios.
3. Especificación de Requerimientos 3.1 Requisitos de Capacidad. Listado de requisitos que especifican las capacidades que debe poseer el software (lo que debe poder realizar el software), para satisfacer las necesidades del cliente/usuario. Estos requisitos se deben especificar según el formato preestablecido. Velocidad. El tema de la velocidad esta dada por el medio o servicio que lo otorga. Exactitud. Dependerá de la plataforma o hardware que soporte este software. 3.1 Requisitos de Calidad. Listado de requisitos de calidad del producto de software. Estos requisitos se deben especificar según el formato preestablecido.

13 UR: Salidas de la Fase 3.1.3 Requisitos de Restricciones. Listado de requisitos que especifican restricciones a cerca de cómo debe ser construido (se refiere a conexiones con otros sistemas, o adhesión a los estándares de la empresa) y operado el software. Estos requisitos se deben especificar según el formato preestablecido.

14 Definición de los Requerimientos
Tabla de Atributos NECESIDAD 1 ESCENCIAL Requerimiento vital, importante y esencial del software no son negociables. 2 NEGOCIABLE Menos vital, importantes y conforme a negociación PRIORIDAD    ALTA Cada requisito del software incluirá una medida de la prioridad del modo que el desarrollador pueda decidir un plan de fabricación MEDIANA 3 BAJA ESTABILIDAD Algunos requisitos pueden ser estables durante la vida de software, otros pueden ser más dependientes a partir de la fase del diseño y otros pueden estar conforme a cambios durante el ciclo de vida del software CLARIDAD PRECISA Respecto a la interpretación implica carencia de ambigüedad. Si un término usado en un contexto particular tiene significados múltiples se debe sustituir por uno más específico. AMBIGUA NO CLARA VERIFICABILIDAD SI Cada requisito es comprobable que se incorpore en el diseño y ejecución. Se debe comprobar que el software pone en ejecución el requerimiento. NO FUENTE REQ. DE .USUARIO Las referencias acompañarán cada requerimiento de software EQUIPO PROYECTO

15 Tabla de Requerimientos de Usuario
ID Descripción Necesidad Prioridad Estabilidad Claridad Verificabilidad Fuente 1.- Ambiente Operacional UR 1.1 Aplicación desarrollada sobre plataforma Windows XP. 1 Este requerimiento de usuario exige que el sitio del foro se desarrolle sobre una plataforma de sistema operativo Windows XP 2.1 Acceder a través de un browser compatible Explorer 6.0 2 El acceso al sistema ya sea por parte del Administrador como de los usuarios debe ser por medio de un browser compartible con el utilitario Explorer 6.0, que se incluye en el sistema operativo Windows XP 3.1 Desarrollo en página Web. El desarrollo debe ser bajo un ambiente Web, con el objeto de que esta página pueda ser visitada por cualquier usuario que tenga acceso a Internet.

16 Especificación de Requisitos de Usuarios
Atributos de requisitos de usuarios: La forma completa de especificar requisitos, es similar a la propuesta de Tom Gilb (vista en transparencias anteriores). Por razones de background del equipo de trabajo, y de tiempo para desarrollar el proyecto, especificaremos los requisitos de la siguiente manera: Para Requisitos Funcionales y de Restricción, especificar: Identificador. Identifica unívocamente al requisito. Descripción. Describe el requisito. Prioridad. Indica una prioridad. Por ej.(alta-media-baja) Usuarios. Identifica los tipos de usuario que se verán afectados por este requisito. Fuente. Referencia a la fuente de donde surgió el requisito (documento, grupo, entrevista, etc.).

17 Especificación de Requisitos de Usuarios
Atributos de requisitos de software: Para Requisitos de Calidad relevantes, se recomienda utilizar el formato completo de especificación. Para Requisitos de Calidad poco relevantes, se recomienda utilizar el mismo formato (simplificado) que para los Requisitos Funcionales y de Restricción.

18 Revisiones del URD Las salidas de esta etapa deben ser formalmente revisadas durante la actividad de revisión de Requisitos de Usuarios (UR/R). Están involucrados los: usuarios, clientes, analistas, administ. del proyecto, y los tésters. Es aconsejable realizar revisiones periódicas, antes de la revisión final. Eso mejorará la calidad y la disponibilidad del producto final de la fase (URD).

19 UR: Salidas de la Fase Documento de requisitos de usuarios.
2. Descripción General 2.4 Suposiciones y Dependencias. Narrativa que establece (por escrito) todas aquellas suposiciones, que se han hecho (con el consentimiento del cliente/usuario), sobre alguna característica del software a desarrollar. 2.5 Restricciones Generales. Narrativa que establece cuáles son las restricciones de funcionamiento del software. Por ej. que funcione en Windows y UNIX, que funcione en el actual ambiente operacional, etc. 2.6 Descripción del Modelo. Diagrama + explicación del modelo de funcionamiento global actual. Se puede utilizar DFD, diagramas de procesos, de transición de estados, etc.

20 UR: Salidas de la Fase Documento de requisitos de usuarios.
3. Requisitos del Sistema 3.1 Requisitos de Usuario. Listado de requisitos que representan la necesidad del usuario/cliente. 3.1.1 Requisitos de Capacidad. Listado de requisitos que especifican las capacidades que debe poseer el software (lo que debe poder realizar el software), para satisfacer las necesidades del cliente/usuario. Estos requisitos se deben especificar según el formato preestablecido. 3.1.2 Requisitos de Calidad. Listado de requisitos de calidad del producto de software. Estos requisitos se deben especificar según el formato preestablecido. 3.1.3 Requisitos de Restricciones. Listado de requisitos que especifican restricciones a cerca de cómo debe ser construido (se refiere a conexiones con otros sistemas, o adhesión a los estándares de la empresa) y operado el software. Estos requisitos se deben especificar según el formato preestablecido.

21 4. Matriz de Trazado

22 Administración de Requisitos durante un Proyecto
Los documentos URD y SRD deben ser “documentos completos”. Esto significa que todos los requisitos conocidos deben ser incluidos cuando son producidos. Sin embargo, es altamente probable que aparezcan nuevos requisitos después de las aprobaciones de los documentos. Por ello, es necesario establecer al inicio del proyecto, procedimientos para manejar nuevos requisitos. Es necesario no comprometer la integridad del diseño cuando se incorporan nuevos requisitos. Dichos requisitos, si es que son aceptados tanto por el usuario como por el diseñador, debiesen ser manejados de la misma forma que los requisitos originales.

23 Administración de Requisitos durante un Proyecto
El procedimiento para incorporar un nuevo requisito de usuario es el siguiente: Generar un nuevo manuscrito del URD. Convenir una revisión de los UR, y si el cambio es aceptado, Repetir las fases SR, AD, y DD para incorporar el nuevo requisito y sus consecuencias. El procedimiento para incorporar un nuevo requisito de software es similar.

24 Administración de Requisitos durante un Proyecto
Otra forma de manejar nuevos requisitos es el de instituir un Comité de Revisión de Software después de UR/R en vez de DD/R. Otra forma es el uso de un enfoque de ciclo de vida de desarrollo evolutivo. Sin embargo, esto sólo alarga la administración de los nuevos requisitos para el release posterior al que está en preparación, lo que puede no ser suficiente. La calidad del trabajo hecho para las fases UR y SR puede ser medido por el número de requisitos que aparecen en fases posteriores. Especial énfasis debe dársele a la aparición de nuevos requisitos. Un número de apariciones importantes es un signo claro que el software muy probablemente no será un éxito.

25 Administración de Requisitos durante un Proyecto
La disponibilidad de herramientas puede ser crítica para un proyecto con cambios de requisitos frecuentes. En proyectos donde se conviene (entre el cliente y el desarrollador) en congelar los requisitos en la fase SR, el uso de métodos basados en papel para realizar análisis de requisitos y especificación de diseño pueden ser suficientes. En proyectos donde no es posible congelar los requisitos, puede ser esencial el uso de herramientas de ingeniería de software que permitan que nuevos requisitos y cambios al diseño sean asimilados rápidamente para evitar atrasos serios.

26 Bibliografía y Casos I. Sommerville, P. Sawyer. Requirements Engineering, A Good Practice Guide.Wiley, 1999. S. Robertson, J. Robertson. Mastering the Requirements Process. Addison- Wesley, 1999. A. Davis. Software Requirements, Revision. Prentice Hall, 1993. ESA, SOFTWARE ENGINEERING STANDARDS, ISSUE 2. Preparado por: ESA Board for Software Standardisation and Control (BSSC). R. L. Kliem, Collecting Project Information. R. H. Deane, Linking Project Outcomes to Customer Needs. Principles of Software Engineering Management, Tom Gilb, Addison-Wesley,