Requisitos No Funcionales

Transcripción

1 Requisitos No Funcionales GUILHERME SIQUEIRA SIMÕES 13/06/2017 FATTO CONSULTORIA Y SISTEMAS FATTO Consultoría y Sistemas - 1

2 2 ORIENTACIONES INICIALES De preferencia al uso de una conexión de banda ancha Este evento no tendrá video (webcam), solamente la presentación y audio Si es necesario, ajuste el idioma de la sala en la barra de herramientas superior Tendrá una duración de ~45 min. de presentación y ~15 min. finales para preguntas Puedes enviar tus preguntas por el chat durante la presentación Para aquellos que poseen certificación PMP, el webinar otorga un crédito de 1 PDU La grabación y material serán publicados posteriormente en nuestra página web y redes sociales:

3 3 FATTO Consultoría y Sistemas Misión: Ayudar nuestros clientes a planificar y controlar mejor sus proyectos de software. Consultoría y Entrenamiento en Medición, Estimación y Requerimientos de Software: Puntos de Función (IFPUG, NESMA, COSMIC) Estimaciones de proyectos de software Ingeniería de Requerimientos Medición y auditoría en medición de software Análisis de productividad en proyectos de software El libro más vendido de FPA en Brasil fue escrito por nosotros Formó 25% de expertos certificados (CFPS) en Brasil

4 4 Cursos FATTO Estimación de Proyectos de Software con COCOMOII 16 horas Ingeniería de Requerimientos de Software 24 horas Taller de Requerimientos Sesiones de 8 ~ 40 horas Preparación para el Examen CCFL (COSMIC) 40 horas (EAD y presencial) Medición y Estimación de Software con el Método COSMIC 16 horas (presencial) Taller de Medición de Puntos de Función Sesiones de 8 ~ 40 horas Estimaciones de Software: Fundamentos y Técnicas 24 horas (EAD y presencial) Capacitación en FPA: Medición y Estimación de Software 16 horas (EAD y presencial) Workshop FPA: Metodología y Prácticas de Medición 16 horas (presencial) Preparación para el Examen CFPS (IFPUG) 96 horas (EAD y presencial)

5 Agenda Dos dimensiones del software Requisitos funcionales Requisitos no funcionales ISO/IEC FURPS+ Checklists FATTO Consultoría y Sistemas - 5

6 Las dos dimensiones del software Los requerimientos de del software están subdivididos en Funcionales Describen lo que el software hace: procesos o tareas de la solución (y de transición) que apoyan una práctica o procedimiento de uno interesado No Funcionales Expresan atributos o restricciones inherentes a los requerimientos funcionales y como ellos serán atendidos FATTO Consultoría y Sistemas - 6

7 Describe lo que el software debe hacer en términos de tareas o servicios de usuario No aborda la implementación Doc. Visión Lista requisitos Historia de usuario Caso de Uso Requisitos Funcionales Modelo de proceso Intercambio de información entre el software y el usuario en dirección a su objetivo Empieza una nueva tarea El objetivo del usuario es concluir una tarea bajo su responsabilidad Resultados que pasan a ser usados en otras tareas por usuarios con otras responsabilidades Resultados que pasan a ser usados en otras tareas mas adelante en el flujo operacional, incluso bajo la misma responsabilidad FATTO Consultoría y Sistemas - 7

8 8 Niveles de Objetivo de los RFs (Granularidad)* Objetivos asociados Efectuar gestión de los cursos Agregado Requisitos relativos a tareas y servicios de usuario transferidas al software Emitir certificado de participación Usuario Reglas Pasos Subfunción Solamente alumnos con frecuencia 75% pueden emitir su certificado *

9 9 Requisitos No Funcionales Abordan el CÓMO las funcionalidades serán ofrecidas al usuario Incluye aspectos relacionados a Calidad: usabilidad, confiabilidad, eficiencia, portabilidad, facilidad de mantenimiento Implementación: plataforma de software, hardware, lenguaje de programación Ambiente: interoperabilidad, seguridad, privacidad, confidencialidad Organización: locales para funcionamiento, hardware objetivo, adhesión a estándares corporativos. Ejemplo: Web Content Accessibility Guidelines (WCAG) 2.0

10 10 Requisitos No Funcionales En general se acostumbra a tener una buena visibilidad de estos requisitos en las primeras etapas del proyecto Por lo general son menos numerosos que los requisitos funcionales Tienden a ser constantes entre los proyectos de una misma compañía, lo que también facilita su identificación Para las organizaciones que poseen una metodología madura de desarrollo de software, la identificación de la mayoría de los RNF queda facilitada pues muchos aspectos técnicos y de calidad de los proyectos son estandarizados por la metodología

11 11 Requisitos No Funcionales La clasificación de los tipos de requisitos no funcionales es muy útil para apoyar el trabajo de identificación No hay consenso en la literatura acerca de esta clasificación Cada organización puede definir categorías para su contexto Algunos modelos pueden ser usados para esta definición local: ISO/IEC (SQUaRE) FURPS o FURPS+ No se preocupe si clasifica incorrectamente el requisito: lo importante es que sea identificado!

12 ISO/IEC SQuaRE (Systems and software Quality Requirements and Evaluation) Calidad del Sistema/Software Adecuación Funcional Eficiencia Compati bilidad Usabilidad (Facilidad de uso) Confiabilidad (Fiabilidad) Seguridad Manteni miento Portabilidad Completitud Funcional Corrección Funcional Conformidad Funcional Tiempo de respuesta Utilización de Recursos Capacidad Coexistencia Interoper abilidad Reconoci miento Adecuado Facilidad de Aprendizaje Operatividad Protección a Errores de Usuario Estética de la Interfaz Madurez Disponibilidad Toleranci a a errores Capacidad de Recuperació n Confidenci alidad Integridad Irrefutabilidad Responsa bilidad Autentic idad Modularidad Reusabilidad Análisis Cambios Pruebas Adaptación Instalación Intercambio Accesibilidad FATTO Consultoría y Sistemas

13 FURPS y FURPS+ Parte del IBM Rational Unified Process (RUP) Functionality Usability Reliability Performance Supportability (Funcionalidad) (Usabilidad) (Confiabilidad) (Desempeño) (Facilidad de Soporte) Ya estudiado anteriormente + Restricciones de diseño Restricciones de implementación Restricciones de interfaz Restricciones físicas FATTO Consultoría y Sistemas

14 14 FURPS - Usabilidad Evalúa la facilidad de uso. Posee diversas subcategorías, entre ellas: Factores humanos Estética Consistencia en la interfaz de usuario Ayuda on-line y contextual Asistentes Documentación Materiales de capacitación Ejemplos: La lectura del código de barras debe ser automática para reducir la entrada de datos manual, agilizando la transacción y evitando errores La documentación en cuanto a la utilización y el funcionamiento debe proporcionarse a través de ayuda en línea

15 15 FURPS - Confiabilidad Integridad, conformidad e interoperabilidad de software y tratan cuestiones como: La frecuencia y la gravedad de errores Posibilidad de recuperación de errores Previsibilidad Exactitud Tiempo medio entre fallas Ejemplos: El Microsoft Word recupera un documento no guardado después de un apagado inesperado del ordenador Si el proceso de importación de cuentas recaudadoras fuera interrumpido por una falla, el sistema debe permitir recuperar los dados ya importados y continuar a partir del punto en que ocurrió la falla

16 16 Usa como medida diversos aspectos del software, entre ellos Ejemplos: FURPS - Desempeño Velocidad Eficiencia Tasa de transferencia Tiempo de respuesta Uso de recursos El sistema debe soportar hasta 100 usuarios simultáneos El tiempo de respuesta de cualquier pantalla del sistema no debe exceder a los 2 segundos

17 FURPS Facilidad de Soporte Facilidad de efectuar cambios en el sistema después de ser entregado. Agrupa varias características como: Testeabilidad Adaptabilidad Mantenimiento Compatibilidad Configurabilidad Instalabilidad Escalabilidad Localización Ejemplos: La instalación del software debe ser realizada de forma semiautomática, es decir, con la mínima intervención humana La solución debe ofrecer soporte a los idiomas: inglés, portugués y español El sistema debe correr en los navegadores Internet Explorer, Firefox o Chrome FATTO Consultoría y Sistemas

18 18 Qué es el Checklist? El uso de listas de verificación (checklists) es una manera muy eficaz de identificar requisitos no funcionales Es un conjunto de preguntas/afirmaciones que tratan sobre el criterio de calidad de un determinado artefacto de software Proporciona una forma estructurada para la identificación de errores en proyectos, evidenciando que una o más cuestiones de la lista no fueron atendidas Conjunto de cuestiones abordadas en la lista que reflejen lecciones aprendidas de proyectos pasados y buenas prácticas de mercado

19 19 Surgimiento de los Checklists La técnica Checklist surgió durante la fase final de evaluaciones de aeronaves bajo la especificación del Ejército de los EUA, en 1934 Un accidente en un vuelo de prueba fue el detonante para la adopción de los checklists Cuatro listas de verificación (Checklists) fueron desarrolladas: despegue, vuelo, antes de aterrizar, después del desembarque Con su uso, un planeamiento cuidadoso y riguroso entrenamiento, la aeronave consiguió volar 290 mil km sin un único accidente

20 20 Ejemplo Checklist para Fiabilidad Pregunta 1. El software tendrá usuarios externos a la empresa? Observación 2. El software deberá funcionar sólo en días hábiles y horario comercial? 3. El funcionamiento del software deberá ser 24x7? 4. Es necesario proveer alguna contingencia en caso de fallo de alguna interfaz externa? 5. Es aceptable interrumpir la operación para actualización de versión del software? 6. Hay algún proceso que puede degradar el rendimiento del software y perjudicar la operación normal?

21 21 Ejemplo Checklist para Desempeño Pregunta 1. Cuál es el tiempo promedio (en segundos) de respuesta para transacciones interactivas? (Duración entre el comando de inicio hasta la respuesta final) 2. Cuál es la cantidad de transacciones procesadas por minuto (throughput)? 3. Cuál es la tasa media de transacciones (throughput)? 4. Cuánto tiempo de CPU se utiliza para concluir una transacción con respeto al tiempo total? 5. Cuánto tiempo de E/S se utiliza para concluir una transacción con respeto al tiempo total? 6. Cuántas solicitudes de transacciones online pueden ser procesadas por segundo? 7. Cuántos usuarios pueden acceder al sistema de manera simultánea por minuto? Observación

22 22 Conclusión El requisito no funcional describe el CÓMO las funcionalidades son entregadas al usuario Hay buena visibilidad sobre ellos en etapas tempranas del proyecto Cambian poco entre proyectos de la misma empresa La categorización ayuda en la identificación Pueden ser más fácilmente levantados por medio de los checklists

23 23 ENCUESTA!

24 24 PRÓXIMOS EVENTOS WEBINARS: Tutorial práctico del análisis de los puntos de función IFPUG de un app Google Fecha: 04 de Julio de 2017 Inscripción: CURSOS SUGERIDOS: Curso Ingeniería de Requerimientos: Software orientado al negocio

25 PREGUNTAS? Muchas gracias por la atención! GUILHERME SIQUEIRA SIMÕES Linkedin: Skype: guilherme.s.simoes FATTO Consultoría y Sistemas