Proyecto Integrador III Sesión 5 Requerimientos de Software

Transcripción

1 2018-I Proyecto Integrador III Sesión 5 Requerimientos de Software Mg. Jymmy Dextre Alarcón

2 Agenda Requerimientos funcionales Requerimientos no funcionales Documento de Requerimientos Casos de Uso

3 Ingenieria de Requerimientos Se define como el proceso de establecer los servicios que el consumidor requiere de un sistema y las restricciones sobre las cuales de funcionar y ser desarrollado. Sommerville. Es una de las etapas mas criticas del proceso de software, determina que se va realizar. Mas del 30% de los proyectos de software que fracasan lo realizan por causa de los requerimientos.

4 Tipos de Especificación Requerimientos de Usuarios: Están definidos en lenguaje natural que esbozan los servicios y restricciones del sistema, Escrito para consumidores. Requerimientos del Sistema: Están definidos de una manera estructurada, y además de los servicios y restricciones del sistema, da nociones concisas de como debería ser implementado.

5 Tipos de Especificación Requerimientos de Usuarios: Administradores Clientes. Usuarios Finales del Sistema. Administradores Contratistas Requerimientos del Sistema: Arquitectos del sistema. Desarrolladores del Software. Usuarios Finales del sistema

6 Tipos de Especificación -> Ejemplo Este ejemplo de un sistema de administración de pacientes para apoyar la atención a la salud mental (MHC-PMS) muestra cómo los requerimientos del usuario se extienden hacia varios requerimientos del sistema. En la figura 1 se observa que el requerimiento del usuario es muy general. Los requerimientos del sistema ofrecen información más específica sobre los servicios y las funciones del sistema que se implementará.

7 Tipos de Especificación -> Ejemplo Este ejemplo de un sistema de administración de pacientes para apoyar la atención a la salud mental (MHC-PMS) muestra cómo los requerimientos del usuario se extienden hacia varios requerimientos del sistema. En la figura 1 se observa que el requerimiento del usuario es muy general. Los requerimientos del sistema ofrecen información más específica sobre los servicios y las funciones del sistema que se implementará.

8 Tipos de Especificación -> Ejemplo Definición del requerimiento del usuario El MHC-PMS elaborará mensualmente informes administrativos que revelen el costo de los medicamentos prescritos por cada clínica durante ese mes. Definición de los requerimientos del sistema 1.1 En el último día laboral de cada mes se redactará un resumen de los medicamentos prescritos, su costo y las clínicas que los prescriben. 1.2 El sistema elaborará automáticamente el informe que se imprimirá después de las 17:30 del último día laboral del mes. 1.3 Se realizará un reporte para cada clínica junto con los nombres de cada medicamento, el número de prescripciones, las dosis prescritas y el costo total de los medicamentos prescritos. 1.4 Si los medicamentos están disponibles en diferentes unidades de dosis (por ejemplo, 10 mg, 20 mg) se harán informes por separado para cada unidad de dosis. 1.5 El acceso a los informes de costos se restringirá a usuarios autorizados en la lista de control de acceso administrativo.

9 Tipos de Requerimientos Requerimientos Funcionales Definición de los servicios que el un sistema de proveer, su comportamientos a las diferentes entradas y situaciones. Requerimientos No Funcionales Restricciones aplicadas sobre las funcionalidades del sistema como: restricciones de tiempo, sobre el proceso de desarrollo, recursos, dominio del negocio.

10 Requerimientos Funcionales Describe las funcionalidades y servicios del sistema. Ejemplos El sistema deberá almacenar la información personal de los pacientes. El sistema deberá poder desplegar la historia clínica en cualquiera de los nodos de acceso. El sistema deberá registrar cualquier acceso o modificación sobre una historia clínica. Un usuario podrá buscar en todas las clínicas las listas de citas. El sistema elaborará diariamente, para cada clínica, una lista de pacientes que se espera que asistan a cita ese día. Cada miembro del personal que usa el sistema debe identificarse de manera individual con su número de ocho dígitos.

11 Requerimientos Ambiguos Muchos problemas relacionados con requerimientos están asociados a la diferentes interpretación que se le pueden dar a los mismos. Las ambigüedad puede ser usada para sacar partido de las diversas situaciones Un desarrollador puede tomar la interpretación mas simple (Por presión de tiempo). Un cliente puede tomar la interpretación mas compleja (Para obtener más por su inversión).

12 Caracteristicas Deseadas Para evitar problemas, se espera que una especificación de requerimientos de tener las siguientes características: (IEEE-830). Correcto:Lo que se especifica es lo que se quiere Completo: Todas las necesidades deben estar reflejadas. Consistente: No debe existir contradicción entre requerimientos. Comprobable: Se debe poder determinar si se cumple o no.

13 Requerimientos No Funcionales Definen las propiedades y restricciones del sistema a construir o sobre el proceso que lo construirá: Los requerimientos no funcionales, suelen ser mas críticos que los funcionales, dado que su incumplimiento puede hacer inútil el sistema. Estos están clasificados según el tipo de restricción que se quiera implementar. Los requerimientos no funcionales afectan más la arquitectura global de un sistema que los componentes individuales. Por ejemplo, para garantizar que se cumplan los requerimientos de rendimiento, quizá se deba organizar el sistema para minimizar las comunicaciones entre componentes.

14 Clasificación Requerimientos del Producto: Requerimientos que especifican que el productos deba comportarse de una determinada manera. Requerimientos Organizacionales : Requerimientos que surgen de políticas y procedimientos del organización (Creadora o Usuaria). Requerimientos Externos : Requerimientos surgidos por factores externos al proyecto de desarrollo como tal.

15

16 Requerimientos No Funcionales -> Ejemplo del Sistema MHC - PMS REQUERIMIENTO DEL PRODUCTO El MHC-PMS estará disponible en todas las clínicas durante las horas de trabajo normales (lunes a viernes, de 8:30 a 17:30). En cualquier día, los tiempos muertos dentro de las horas laborales normales no rebasarán los cinco segundos. REQUERIMIENTOS DE LA ORGANIZACIÓN Los usuarios del sistema MHC-PMS se acreditarán a sí mismos con el uso de la tarjeta de identidad de la autoridad sanitaria. REQUERIMIENTOS EXTERNOS Como establece la HStan priv, el sistema implementará provisiones para la privacidad del paciente. La información medica de un paciente, no debe estar al alcance del publico general.

17 Factores claves de comunicación Tamaño del Grupo: Entre mas grande sea el grupo, se dificultara mas la comunicación. (Recomendado 4 a 7 Personas). Es tructura del Grupo: Los grupos informales facilitan la comunicación. Composición del grupo: Las comunicación es mejor en un grupo diverso. Espacio Físico: Una correcta organización del espacio pude beneficiar la comunicación.

18 Medición de Requerimientos Algunos requerimientos son difíciles de verificar, principalmente los no funcionales. Se debe determinar en los posible crear métricas que permitan verificar el requerimiento Ejemplo La interfaz debe ser de fácil uso (Poco Verificable) La interfaz debe estar diseñada para que pueda ser usada después de dos horas de capacitación, después de lo cual la media de errores no excederá de dos por día.

19 Medidas de Requerimientos Rapidez: Transacciones procesadas por minuto, Tiempo de respuesta al usuario y a eventos, tiempo de actualización de la pantalla Tamaño: Cantidad de Memoria o Disco duro requerido. Facilidad de Uso: Tiempo de Formación requerido, Cantidad de mensajes y documentación de ayuda, efectividad de los usuarios. Fiabilidad: Tiempo medio entre fallos, Porcentaje de disponibilidad. Robustez: Tiempo de reinicio después de fallo, numero de eventos que producen fallos, Probabilidad de corrupción de datos después de fallos

20 Documento de Requerimientos Es el documento formal en el cual se especifican los requerimientos del sistema. Debe contener los requerimientos de usuario y del sistema. Este documento es una especificación de que debe cumplir el sistema, y no contiene ningún aspecto de diseño

21 Usuario del documento de Requerimientos

22 Contenido del Documento -> Según la norma IEEE

23 Contenido del Documento

24 Contenido del Documento

25 Casos de Uso: Los casos de uso son una técnica de descubrimiento de requerimientos que se introdujo por primera vez en el método Objectory (Jacobson et al., 1993).

26 Proxima clase: - Presentar el Diseño de la Base de Datos

27 Bibliografía - Ingeniería de Software, Ian Sommerville. 9na Edición. (Capitulo 4).