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

Slides:



Advertisements
Presentaciones similares
También conocido como Diseño Lógico Rodrigo Salvatierra Alberú.
Advertisements

Ingeniería del Software UMG Ingeniería en Sistemas
Los Principios del Sistema de Gestión de la Calidad
ANÁLISIS DE REQUERIMIENTOS
Ingeniería de Software
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
Guia Diseño Robert Echeverria
INGENIERIA DE REQUERIMIENTOS
Procesos de la Ingeniería
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
Sistema de Gestión de la Calidad
INSTITUTO TECNOLÓGICO SUPERIO DE LIBRES
REQUISITOS DE SOFTWARE
Ciclo de formulación del proyecto.
Electivo Integración Normas de Calidad, Seguridad, Medio Ambiente y Riesgos en la Gestión de la Empresa. Profesor : Fernando Vargas Gálvez Ingeniero Civil.
“Especificación de Requerimientos”
IS ILic. Patricia Pesado.1 INGENIERIA DE REQUERIMIENTOS.
ADMINISTRACIÓN DE REQUERIMIENTOS
Técnicas para la obtención de requerimientos
Fundamentos de Ingeniería de Software Facultad de Ingenieria Universidad Distrital Francisco José de Caldas ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS.
Ingeniería de Requisitos
5.3 APROXIMACIONES AL DISEÑO
Gestión de Proyectos Informáticos Sesión N° 5 Ciclo de Vida de un Proyecto Roberto Jijena I.
REQUERIMIENTOS DE SOFTWARE
Administración Proyectos Jorge Baracaldo Robin Ochoa.
Gestión de la Continuidad del negocio BS BCI
Análisis de Requerimientos
El Concepto de Requerimiento
Ingeniería de Requerimiento
Plan de Sistemas de Información (PSI)
Análisis y Diseño de Sistemas
INGENIERÍA DE SOFTWARE
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
VISIÓN GENERAL DE LA IS Con independencia del modelo de proceso hay tres fases genéricas: Fase de definición Fase de desarrollo Fase de mantenimiento Cada.
Trainning DFD.
Estudio de Viabilidad del Sistema (EVS)
Alexander Aristizabal Ángelo flores herrera
Diseño de Sistemas.
Factores y Métricas que determinan la Calidad de un producto
Ciclo de vida de un sistema
Unidad ll Equipo #2 Juan Carlos Martínez Ramos
FACTIBILIDAD DE LOS SISTEMAS DE INFORMACIÓN
RUTA DE LA CALIDAD.
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
Conceptos sobre GESTIÓN DE PROYECTOS
Organización para la calidad.
Ingeniería de Requerimientos
Introducción al proceso de verificación y validación.
NOMBRE DE LA ASIGNATURA: VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE
problemas de la calidad del software
Determinación de Requerimientos
Mejores Prácticas para el Desarrollo de Software Omar de Jesús Rosales Hernández.
ANGIE PAOLA SOLANO CASTIBLANCO DAR SOPORTE A LOS PROCESOS NORMAS ISO DOC. JOHANA LÓPEZ CHAVEZ SENA 2010.
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
De Informaciòn Gerencial Lcda. Oly Mata.
Análisis de Requerimientos
LILIANA JIMENEZ GARCIA FERANANDO CANO GOMEZ. El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería.
República Bolivariana de Venezuela Universidad Nacional Experimental Politécnica de la Fuerza Armada (UNEFA) Carrera: Ingeniería de Sistemas Cátedra: Análisis.
Fundamentos de Computación
Las fases del ciclo de la vida de desarrollo de sistemas
SISTEMA DE GESTIÓN DE LA CALIDAD ISO 9001: AUDITORÍA INTERNA
ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS
Identificación de entradas, salidas y herramientas de procesos de gestión del PMI Jairo A. Orozco L.
Taller de investigación 1
ANALISIS DE SISTEMAS PROFESOR HECTOR ARCIA.
Modelo de procesos de software
Verificación y Validación del Software
VERIFICACIÓN Y VALIDACIÓN DE SISTEMAS 3.10 Fase de manejo de requerimientos 4.1 Modelado de pruebas en UML Ponente: ing. Alejandro tapia vazquez.
GESTIÓN DE PROYECTOS.
Gestión del Alcance del Proyecto
Transcripción de la presentación:

Sesión 312 Té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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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

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

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

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)

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)

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.

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

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.

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.

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”.

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

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.

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.

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

Thank you!