Sesi

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
Necesidades Eª
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_at_ultramar.cl

28
Thank you!