requisitos no funcionalesfattocs.com/files/es/presentaciones/...funcionales...•consultoría y...

© FATTO Consultoría y Sistemas - www.fattocs.com

FATTO CONSULTORIA Y SISTEMAS

GUILHERME SIQUEIRA SIMÕES

13/06/2017

Requisitos No Funcionales

1


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:

ORIENTACIONES INICIALES

2


FATTO Consultoría y Sistemas

3

• Misión: “Ayudar nuestros clientes a planificar y controlar mejor susproyectos de software.”

• Consultoría y Entrenamiento en Medición, Estimación yRequerimientos 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


Cursos FATTO

Preparación para el

Examen CFPS (IFPUG)96 horas (EAD y presencial)

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)

Ingeniería de

Requerimientos de Software 24 horas

Estimación de Proyectos

de Software con COCOMOII 16 horas

Taller de Medición de

Puntos de Función Sesiones de 8 ~ 40 horas

Medición y Estimación de

Software con el Método COSMIC 16 horas

(presencial)

Taller de Requerimientos

Sesiones de 8 ~ 40 horas

Preparación para el

Examen CCFL (COSMIC)40 horas (EAD y presencial)

4


Agenda

Dos dimensiones del software

Requisitos funcionales

Requisitos no funcionales

ISO/IEC 25010

FURPS+

Checklists

5


Las dos dimensiones del software

• Los requerimientos de del software están subdivididos en

6

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

Funcionales

Expresan atributos o restriccionesinherentes a los requerimientos

funcionales y como ellos serán atendidos

No Funcionales


• 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

• Modelo de proceso

Requisitos Funcionales

Empieza una

nueva tarea

Intercambio de

información entre el

software y el usuario

en dirección a su

objetivo

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

7


Agregado

Usuario

SubfunciónReglas Pasos

Objetivos asociados

Requisitos relativos a tareas y

servicios de usuario

transferidas al software

Niveles de Objetivo de los RFs(Granularidad)*

* https://youtu.be/XBVQMR8xQ2M

Efectuar gestión de los cursos

Emitir certificado de participación

Solamente alumnos con frecuencia

≥ 75% pueden emitir su certificado

8

https://youtu.be/XBVQMR8xQ2M


•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


9



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

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

Tienden a ser constantes entre los proyectos de una misma compañía, lo que también facilita su identificación

10


• 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 25010 (SQUaRE)

• FURPS o FURPS+

• No se preocupe si clasifica incorrectamente el requisito: ¡lo importante es que sea identificado!


11


Calidad del

Sistema/Software

Adecuación

Funcional

Completitud

Funcional

Corrección

Funcional

Conformidad

Funcional

Eficiencia

Tiempo de

respuesta

Utilización

de

Recursos

Capacidad

Compati

bilidad

Coexistencia

Usabilidad(Facilidad de

uso)

Confiabilidad(Fiabilidad)

SeguridadPortabilidadManteni

miento

Reconoci

miento

Adecuado

Facilidad de

Aprendizaje

Operatividad

Protección

a

Errores de

UsuarioEstética de

la Interfaz

Accesibilidad

Madurez

Disponibilidad

Toleranci

a a

erroresCapacidad

de

Recuperació

n

Confidenci

alidad

Integridad

Irrefutabilidad

Responsa

bilidad

Autentic

idad

Modularidad

Reusabilidad

Análisis

Cambios

Pruebas

Adaptación

Instalación

IntercambioInteroper

abilidad

ISO/IEC 25010SQuaRE (Systems and software Quality Requirements and

Evaluation)

12


Functionality (Funcionalidad)

Usability (Usabilidad)

Reliability (Confiabilidad)

Performance (Desempeño)

Supportability (Facilidad de Soporte)

FURPS y FURPS+

Parte del IBM Rational Unified Process (RUP)

Ya estudiado

anteriormente

+

Restricciones de diseño

Restricciones de implementación

Restricciones de interfaz

Restricciones físicas

13


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

FURPS - Usabilidad

14


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

FURPS - Confiabilidad

15


Usa como medida diversos aspectos del software, entre ellos

Ejemplos:

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

FURPS - Desempeño

Velocidad

Eficiencia

Tasa de transferencia

Tiempo de respuesta

Uso de recursos

16


Facilidad de efectuar cambios en el sistema después de ser entregado. Agrupa varias características como:

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

FURPS – Facilidad de Soporte

Testeabilidad Configurabilidad

Adaptabilidad Instalabilidad

Mantenimiento Escalabilidad

Compatibilidad Localización

17


¿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

18


Surgimiento de los Checklists

19

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


Ejemplo Checklist para Fiabilidad

Pregunta Observación

1. ¿El software tendrá usuarios externos a la

empresa?

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?

…

20


Ejemplo Checklist para Desempeño

Pregunta Observación

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?

…

21


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

Conclusión

22


¡ENCUESTA!

23


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: https://goo.gl/reoCh7

• CURSOS SUGERIDOS:

Curso Ingeniería de Requerimientos: Software orientado al negocio

http://www.fattocs.com/es/ireq-ead

24

https://goo.gl/reoCh7

http://www.fattocs.com/es/ireq-ead


¿PREGUNTAS?

¡Muchas gracias por la atención!

GUILHERME SIQUEIRA SIMÕES

E-mail: [email protected]

Linkedin: https://br.linkedin.com/in/guilhermesimoes/es

Skype: guilherme.s.simoes

25

requisitos no funcionalesfattocs.com/files/es/presentaciones/...funcionales...•consultoría y...

Documents