Sesión 312 Técnicas de Auditoría Aplicadas a la Ingeniería de Software

1. Sesión 312Técnicas de Auditoría Aplicadas a la Ingeniería de Software Pablo José Caneo, CISA Jefe de Proyectos, Auditor Computacional Ultramar Agencia Marítima Ltda.

2. Ingeniería de Requerimientos • El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema, es llamado Ingeniería de Requerimientos. La meta es entregar una especificación de requisitos de software correcta y completa. • Cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental : la definición de lo que se desea producir • Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambiguedades, en forma consistente y compacta, el comportamiento del sistema.

3. Ingeniería de Requerimientos • De esta manera, se pretende minimizar los problemas relacionados con el desarrollo de sistemas. • Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. • Otros factores como falta de participación del usuario, requerimientos incompletos y el cambio a los requerimientos, también ocupan sitiales altos en los motivos de fracasos.

4. Ingeniería de Requerimientos • ¿Que son los requerimientos? • Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo • Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

5. Ingeniería de Requerimientos • Los requerimientos pueden dividirse en requerimientos funcionales y requerimientos no funcionales • Requerimientos funcionales definen : • Las funciones que el sistema será capaz de hacer • Las transformaciones que el sistema realiza sobre las entradas para producir las salidas. • Requerimientos no funcionales definen : • Las características que pueden limitar el sistema, como por ejemplo : • El rendimiento (en tiempo y espacio) • Interfaces de usuario • Fiabilidad (robustez del sistema, disponibilidad de equipo) • Mantenimiento, seguridad, portabilidad, estándares, etc.

6. Características de los Requerimientos • Necesario : Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o proceso. • Conciso : Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. • Completo : Un requerimiento esta completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. • Consistente : Un requerimiento es consistente si no es contradictorio con otro requerimiento.

7. Características de los Requerimientos • No ambiguo : Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector. • Verificable : Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación : • Inspección • Análisis • Demostración • Pruebas

8. Dificultades para definir los Requerimientos • Los requerimientos no son obvios y vienen de muchas fuentes • Son difíciles de expresar en palabras (el lenguaje es ambiguo) • Existen muchos tipos de requerimientos y diferentes niveles de detalle • La cantidad de requerimientos es un proyecto pueden ser difíciles de manejar • Nunca son iguales, algunos son más difíciles, más riesgosos, más importantes o más estables que otros • Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso • Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas • Un requerimiento puede cambiar a lo largo del ciclo de desarrollo • Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

9. Beneficios de la IR • Los principales beneficios que se obtienen de la IR son : • Permite gestionar las necesidades del proyecto en forma estructurada • Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados • Disminuye los costos y retrasos del proyecto • Mejora la calidad del software • Mejora la comunicación entre equipos • Evita rechazos de usuarios finales.

10. Puntos a considerar en el proceso de IR • Objetivos del Negocio y ambiente de trabajo • Esta información proporciona la base para especificar el sistema que será construído • Punto de vista de los clientes • Cada grupo de clientes tiene necesidades diferentes, y diferentes requerimientos tienen diferentes grados de importancia para ellos. • A veces los clientes no son los mismos usuarios trayendo como consecuencia que los clientes soliciten procesos que causan conflictos con los solicitados por los usuarios. • Problemas por el tamaño y complejidad • Barreras de comunicación • Evolución e integración del sistema • Documentación de Requerimientos.

11. Actividades de la IR • Análisis del problema • Evaluación y Negociación • Especificación • Validación • Evolución

12. Análisis del Problema • Objetivo : Entender las verdaderas necesidades del negocio. • Comprender el problema que se está resolviendo • Múltiples soluciones aplican para el mismo problema, sin embargo, sólo una de ellas será la más factible. • Las soluciones iniciales deben ser definidas tomando en cuenta tanto la perspectiva técnica como la del negocio. • Construir un vocabulario común • La creación de un glosario es sumamente beneficiosa ya que reduce los términos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunión entiendan lo mismo.

13. Análisis del Problema • Identificar los afectados por el sistema • Identificar a todos los afectados, evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate durante la IR, aunque esto no garantiza que vaya a estar disponible toda la información necesaria para especificar un sistema adecuado. • ¿Quién usará el sistema que se va a construir? • ¿Quién mercadeará, venderá yo distribuirá el sistema? • ¿Quién se beneficiará por el retorno de inversión del sistema? • Definir los límites y restricciones del sistema • Debemos saber : • Lo que se está construyendo • Lo que no se está construyendo • Entender la estrategia del producto a corto y largo plazo • Debe determinarse cualquier restricción ambiental, presupuestaria, de tiempo, técnica y de factibilidad que limite el sistema que se va a construir.

14. Evaluación y Negociación de los Requerimientos • Objetivo : Limitar las expectativas del cliente, tomando como referencia los niveles de abtracción y descomposición de cada problema presentado. • Descubir problemas potenciales • Se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc. • Clasificar los requerimientos • Se identifica la importancia que tiene un requerimiento en términos de implementación • Para ello se utiliza la prioridad y debe ser usada para establecer la secuencia en que ocurrirán las actividades de diseño y prueba de cada requisito. • La prioridad de cada requerimiento dependerá de las necesidades que tenga el negocio

15. Evaluación y Negociación de los Requerimientos • Evaluar Factibilidades y Riesgos • Factibilidades técnicas • Factibilidades operacionales • Factibilidades económicas • Negociación • Para que los requerimientos puedan ser negociados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta, entre las principales tenemos : • Documentar todos los requerimientos a un nivel de detalle apropiado • Mostrar todos los requerimientos a los involucrados en el sistema • Analizar el impacto que causen los cambios antes de aceptarlos • Establecer las relaciones entre requerimientos que indiquen dependencias • Negociar con flexibilidad para que exista un beneficio mutuo • Enfocarse en intereses y no en posiciones

16. Especificación de Requerimientos de Software Alcance NecesidadesEª Req.No Funcionales Req.Funcionales Documento Especificación de Requerimientos de Software Pruebas Producto Controles Clientes Usuarios Finales Analistas Personal de Pruebas Personal de implementación

17. Validación de Requerimientos • Es la actividad de la IR, que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente, además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes. • Durante la actividad de validación se deben hacer preguntas en base a cada una de las características que se deseen revisar. • ¿Están incluidas todas las funciones requeridas por el cliente? (completa) • ¿Existen conflictos en los requerimientos? (consistencia) • ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua) • ¿Está cada requerimiento claramente representado? (entendible) • ¿Pueden los requerimientos ser implementados con la tecnología disponible? (factible)

18. Validación de Requerimientos • (continuación) • ¿Esta la especificación de requerimientos escrita en un lenguaje apropiado? (clara) • ¿Existe facilidad para hacer cambios en los requerimientos? (modificable) • ¿Esta claramente definido el origen de cada requisito? (rastreable) • ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable)

19. Evolución de Requerimientos • Es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto • Las razones más frecuentes por las que cambian los requerimientos son : • Al analizar el problema no se hicieron las preguntas correctas a las personas correctas • Cambio el problema que se estaba resolviendo • Los usuarios cambiaron su forma de pensar o sus percepciones • Cambio el ambiente de negocio • Cambio el mercado en el cuál se desenvuelve el negocio • Cambio de procedimientos o forma de trabajo • Definición de políticas de control de versiones de requerimientos.

20. Técnicas utilizadas en la IR • Entrevistas y cuestionarios • Lluvia de ideas • Proceso de análisis jerárquico • Administración de requerimientos con Casos de Uso

21. Aplicación Metodológica • Conceptos fundamentales • Asegurar, en forma explicita que se obtuvo todo el conocimiento que poseen los expertos del proceso productivo • Documentar el conocimiento a través de los medios que permitan la comprensión de todos los involucrados • Lo más relevante es que el proceso de conocimiento considere todas las variables, reglas de negocio, procesos, etc.

22. Acuerdo Metodológico • A pesar de ser considerada una técnica de Análisis Orientado a los Objetos, es importante destacar que los casos de uso poco tienen que ver con entender a un sistema como un conjunto de objetos que interactúan, que es la premisa básica del análisis orientado a objetos “clásico”. En este sentido, el éxito de los casos de uso no hace más que dar la razón al análisis estructurado, que propone que la mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno, independiente de los objetos que interactúan dentro del sistema para proveerlos.

23. Acuerdo Metodológico • A partir del acuerdo anterior, la propuesta es la siguiente : “La forma más adecuada de realizar la Captura de Requerimientos es a través de un proceso combinado de Análisis Estructurado y búsqueda de Casos de Uso a través de entrevistas”.

24. Algunos conceptos necesarios Proceso : Reglas Normas Conjunto de tareas y operaciones que están diseñados para cumplir una o varias funciones específicas, realizadas en forma secuencial o simultánea para lograr un objetivo Entradas Salidas Recursos Usuarios

25. Procedimiento Formal • Análisis de Requerimientos • Obtener MacroFunciones • El método se basa en un conocimiento previo a nivel general de las Macro Funciones que debe cumplir el sistema. • Como su nombre lo indica, consiste en separar el sistema en grandes bloques que posean algo en común. • Las MacroFunciones están formadas por Procesos y estos a su vez por Actividades. • Son en la descripción de estas actividades donde se utilizan los casos de uso.

26. Procedimiento Formal • Análisis Detallado • Establecer los procesos que considera la MacroFunción. • Establecer el conocimiento de cada proceso • Identificar las entidades que participan en cada proceso • Especificar actividades o casos de uso de cada proceso.

27. Para mayor información Pablo José Caneo, CISA Jefe de Proyectos, Auditor Computacional Ultramar Agencia Marítima Ltda. Pcaneo@ultramar.cl

28. Thank you!