INGENIERÍA DE REQUISITOS V1
-
Upload
marlon-ricardo-cueva -
Category
Documents
-
view
278 -
download
0
Transcript of INGENIERÍA DE REQUISITOS V1
* INGENIERA DEREQUISITOSCecilia Hinojosa R. Marzo Julio 2012
*La IR es un factor crtico de xito en los
proyectos de desarrollo de software, segn Curtis, el exacto conocimiento del dominio del problema es crtico para el xito del proyecto.
*Boehm 1981: la etapa de requisitos demanda: *6% del costo *9% al 12% del tiempo *Stockman y Norris: *55% de los fallos se producen en la etapa de anlisis yespecificacin de requisitos
*Importancia
En 1979, la Government Account Office, (GAO) realiz un estudio en el que seleccionaron nueve proyectos de desarrollo de software para el gobierno norteamericano.
*Importancia
Factores de xito: 1. Implicacin de los usuarios 2. Apoyo de los directivos 3. Enunciado claro de los requisitos
CHAOS Report 1995 Standish Group
Factores de fracaso : 1. Falta de informacin por parte de los usuarios 2. Especificaciones y requisitos incompletos 3. especificaciones y requisitos cambiantes
*Importancia
*Segn la IEEE, requisito es:1. 2.Una condicin o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. Una condicin o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificacin u otro documento formal. Una representacin en forma de documento de una condicin o capacidad como las expresadas en (1) o en (2).
3.
*Requisito Definicin
*Existen varias clasificaciones de los requisitos:* de sistema * de hardware * de software * de usuario * de cliente * funcional * no funcional, entre otros.
*Requisitos -
Clasificacin
Por la naturaleza de la caracterstica deseada En qu mbito se debe entender el requisito Quin debe entender el requisito
*Requisitos -
Dimensiones
* Requerimientos funcionales: Son declaraciones de los servicios que debe proporcionar el sistema, la manera en que debe reaccionar ante peticiones y entradas particulares. Puede declarar explcitamente lo que el sistema no debe hacer. * Requerimientos no funcionales: Se refieren a las propiedades emergentes del sistema, tales como: fiabilidad, tiempo de respuesta, capacidad de almacenamiento. Tambin pueden restringir capacidad de dispositivos de entrada / salida o forma de almacenamiento de datos
*Requisitos tipos
*Requerimientos de usuario: Declaraciones enlenguaje natural y diagramas de los servicios que se espera el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
*Requerimientos
del sistema: Son versiones extendidas de los requerimientos del usuario que son utilizados por los ingenieros de software, como punto de partida para el diseo del sistema.
*Requisitos - tipos
* Comprensible por clientes y usuarios * Correcta * No ambigua * Completa * Consistente * Verificable * Modificable * Rastreable * Anotada con importancia y estabilidad * Independiente del diseo y la implementacin
Caractersticas
*Requisitos
*Davis sugiere que la Ingeniera de Requisitosconsiste en el anlisis, documentacin y posterior evolucin de las necesidades del usuario y el comportamiento externo del sistema a ser construido [Davis90].
*Thayer define la Ingeniera de Requisitos como
la ciencia y disciplina interesada en establecer y documentar los requisitos de software. Consiste en la elicitacin, el anlisis, la especificacin, la verificacin y la administracin de los requisitos.
* Ingeniera de Requisitos Definicin
USO DE:
PARA:
Eficiencia
Calidad
*Definicin
LOS
Tcnicas Herramientas Lenguajes Mtodos
Descubrir Refinar Modelar Especificar
Requisitos del software
Cliente: Debe ser experto en los procesos relacionados con el software Estar comprometido con el proyecto de desarrollo
Desarrollador: Investigador Cuestionador Consultor Solucionador de problemas Alta capacidad de abstraccinAl finalizar el proceso de requerimientos, el desarrollador conocer ms del proceso y el cliente se involucrar en temas informticos
*Participantes
Todos aquellos que tienen algn inters en el cambio que est siendo considerado, que tienen algo que ganar o perder (Stakeholders)
* Jefe del proyecto * Diseadores del software * Expertos tcnicos * Analistas de negocios * Expertos de mercados * Responsables de venta o compra * Administradores * Usuarios
*Participantes
USUARIOS Estar familiarizado con sistemas de computacin Buen conocimiento del dominio de la aplicacin Tener conocimiento de gestin de desarrollo de sistemas Tener conocimientos de gestin y planificacin de implementacin de sistemas computacionales
PERSONAL TCNICO Conocimiento del dominio de la aplicacin y procesos del negocio Tcnicas a utilizar a nivel de hardware y software Facilidad de comunicacin
Proceso de ingeniera de requerimientos, anlisis costo / beneficio, implementacin de sistemas y cambio organizacional
Tener habilidad para tratar y Anlisis y evaluacin de comunicarse con las personas paquetes de software
*Destrezas
* Cite tres motivos por los cuales es importantela Ingeniera de Requisitos.
* Enumere los dominios de los requisitos * Segn la audiencia en qu se dividen losrequisitos?
* Enumere cinco caractersticas de los requisitos.
*IR - Autoevaluacin
ERS Definitivo
EduccinInicio
Declaracin informal de requerimient os
Validacin
Anlisis y Negociacin
ERS Borrador
Especificacin
Requerimient os convenidos
*Proceso de IR
*Objetivos de la Educcin* Conocerel dominio del problema: con el fin de entenderse con los clientes y usuarios y que sean capaces de transmitir dicho conocimiento al resto del equipo de desarrollo. las necesidades reales de clientes y usuarios: adems de aquellas necesidades explcitamente manifestadas por los clientes y usuarios, se debe llegar a descubrir el conocimiento tcito, es decir, aquellas necesidades que la mayor parte de las veces se asumen y toman por implcitas.
* Descubrir
*Educcin
* Se refiere a la captura y descubrimiento de los requisitos. * Es una actividad ms humana que tcnica. Se identificana los interesados (stakeholders) y se establecen las primeras relaciones entre ellos y el equipo de desarrollo.
* Fuentes de Requisitos* Metas: Factores crticos de xito (de la empresa). * Conocimiento del dominio de la aplicacin: Cosas que pueden resultarobvias a los expertos no lo son para los usuarios.
* Los interesados: Los afectados por el sistema. * El entorno fsico que rodea al sistema. * El entorno organizacional: Los procesos de negocio.
*Educcin
* Los usuarios no pueden/saben describir muchas de * Mucha informacin importante no llega averbalizarse.
sus tareas. Pueden hacer demandas irreales, ya que no conocen el costo de sus peticiones.
* La dinmica organizacional puede hacer queemerjan nuevos requerimientos.
* Los factores externos pueden influir en los
requisitos del sistema. Ej: factores polticos.
*Problemas de la
educcin
Brainstorming: Seleccionar un grupo variado de participantes. Eliminar crticas, juicios y evaluaciones mientras los participantes sugieren ideas. Producir muchas ideas. Recogerlas todas por escrito. Otro da, en otra sesin, se evalan las ideas (se puntan). Entrevistas: Es el mtodo tradicional, pero debe usarse en complemento con otras tcnicas, y no debe ser el primer paso de la educcin. Es fundamental: Entrevistar a la(s) persona(s) adecuadas, Preparar las preguntas con antelacin, Utilizar diagramas, modelos, etc.
*Tcnicas de educcin
Observacin y anlisis de tareas (mtodo etnogrfico): Un observador estudia a los futuros usuarios en su entorno de trabajo. A veces se utiliza el video. Anota todo aquello que es susceptible de mejora. Posteriormente, genera una serie de requisitos tentativos. Escenarios: Esquemas de la interaccin, deben incluir: * Lo que el usuario espera del sistema * Descripcin de flujo normal de eventos * Descripcin de situaciones excepcionales * Descripcin de actividades paralelas * Descripcin del estado del sistema cuando el escenario termina. .
*Tcnicas de educcin
Casos de uso: Identifican las interacciones entre los actores y el sistema. Prototipado: tiles cuando la incertidumbre es total acerca del futuro sistema.
*Tcnicas de educcin
Expertos del dominio Literatura del dominio Software similar
Identificar fuentes Adquirir conocimiento Decidir relevancia conocimiento Entender significado e impacto Modelos formales del dominio del problema
Estndares, normativa y base legal
Loucopoulos & Karakostas, 1995
*El proceso de
educcin
Expertos del dominio
Literatura del dominio
Obtener informacin de participantesModelos formales del dominio del problema
Software similar
Identificar requisitosEstndares, normativa y base legal
*El proceso deeduccin
Kotonya & Sommerville, 1998
* Indique cul es el objetivo de la educcin * Enumere tres tcnicas que se utilizan para la
educcin de requisitos * Enumere las actividades que se ejecutan en el proceso de educcin * Cite tres entradas importantes del proceso de educcin * Indique cul es el resultado del proceso de educcin.
autoevaluacin
*Educcin -
El objetivo principal :Asegurar la calidad de los requisitos educidos, antes de que stos pasen a formar parte del documento de especificaciones.
Objetivos secundarios:
* Precisar los lmites del sistema software * Precisar la interaccin entre el entorno y el sistema * Trasladar los requisitos del usuarios a requisitos delsoftware * Documentar los requisitos
*Anlisis
*Consensuar
los requisitos entre los propios clientes y usuarios: puede que distintos grupos de clientes y usuarios presenten distintas necesidades que sean contradictorias entre s. Normalmente es necesario negociar entre los distintos participantes hasta obtener una visin comn de los requisitos.
*Anlisis
*En el anlisis de requisitos se*Clasificacin *Modelizacin Conceptual *Negociacin
realizan tres tareas fundamentales:
*Anlisis
Requerimientos del negocio Ideas y soluciones Casos de uso y escenarios
Definiciones de datos
Reglas del negocio
RestriccionesRequerimientos de interfaces externas Atributos de Calidad
Requerimientosfuncionales y no-funcionales
*Clasificacin
*
Reglas del negocio: Las reglas de negocio definen hechos, restricciones, acciones que habilitan funciones, formulas de cmputo o inferencias derivadas de actividades de la organizacin.
*
Requerimientos funcionales: Los requerimientos funcionales describen el funcionamiento que el sistema observar bajo ciertas condiciones y las acciones que permitir el sistema llevar a cabo a los usuarios.
*Clasificacin
*
Requerimientos de negocio: Todo lo que describa beneficios de mercado, financieros o del negocio para los clientes o su organizacin, y que sean obtenidos del producto de software.
*
Casos de uso y escenarios: Los casos de uso son descripciones generales de metas del cliente o tareas del negocio que los usuarios deben realizar. Un patrn nico del caso de uso se conoce como escenario.
*Clasificacin
*Modelado conceptualCecilia Hinojosa R.
34
* Es una simplificacin de la realidad * Un modelo proporciona los planos
de un sistema, los planos pueden ser detallados o generales * Un buen modelo incluye aquellos elementos que son relevantes para el nivel dado de abstraccin. * Cada modelo es por tanto una abstraccin semnticamente cerrada del sistema. * Un modelo puede ser estructural, haciendo hincapi en la organizacin del sistema, o puede ser el comportamiento, haciendo hincapi en la dinmica del sistema
Grady Booch
*Qu es un modelo?Cecilia Hinojosa R.
35
* Dependiendo de la complejidad del problemase generarn los modelos necesarios, se seleccionarn las herramientas y equipos de trabajoRequiere: Modelado mnimo Proceso simple Herramientas simples 1 persona Requiere: Modelado Proceso bien definido Herramientas ms sofisticadas Un equipo de personas
Requiere: Modelado varias perspectivas Proceso complejo Herramientas complejas Equipos en varias disciplinas
*Cundo hacer modelos?Cecilia Hinojosa R.
36
Ayuda a :
Visualizar de manera global Aumentar gradualmente el conocimiento Proyectar o anticipar la estructura
funcionamiento de algo Simular la manipulacin de algo y observar los resultados. Tomar decisiones. Documentar para revisiones futuras.
o
*Por qu modelar?Cecilia Hinojosa R.
37
* Modelos conceptuales * Modelos orientados a procesos * Modelos orientados a datos/objetos * Modelos orientados a estados
Ingeniera de SoftwareCecilia Hinojosa R.
*Los modelos en la38
* Los modelos
conceptuales favorecen la comprensin de los requisitos del usuario, describen el dominio del discurso. funcionamiento del futuro sistema software
* Los modelos del sistema permiten anticipar el
* Modelos conceptuales vs. ModelosCecilia Hinojosa R.
del sistema
39
Modelo conceptual Objeto Describe el dominio del discurso (tareas cotidianas, reglas de negocio) Variable, generalmente mayor al del modelo del sistema Poco detallado
Modelo del sistema Describe futuro sistema software (clases, mensajes, procesos, mtodos) Se circunscribe estrictamente al mbito del futuro sistema software Contiene gran nivel de detalle para ser til en la implementacin Lo ms precisos posibles
Alcance
Detalle
Formalidad
vs. Modelos del sistemaCecilia Hinojosa R.
*Modelos conceptualesNiveles variados40
* Ontologa subyacenteLos modelos conceptuales tienen un propsito especfico y describen el dominio del discurso con:
* un lxico = smbolos o constructores * una sintaxis, la cual gobierna la combinacin delos smbolos constructores = reglas
*Modelos conceptualesCecilia Hinojosa R.
41
* Ejemplo:
*Modelos conceptualesTomado de Modelos conceptuales Diestes O.
Cecilia Hinojosa R.
42
*IRQA
Diseada para soportar las actividades realizadas en el proceso de especificacin de sistemas. Facilita y formaliza la comunicacin entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo. Facilita la captura, organizacin y anlisis de las condiciones, as como la especificacin de la solucin mediante el apoyo metodolgico adaptable a cada cliente.
43:
* Herramientas de soporte IR
* IRQA
43: Facilita y formaliza la comunicacin entre el
cliente, el proveedor y los distintos miembros del equipo de desarrollo. Facilita la captura, organizacin y anlisis de las condiciones, as como la especificacin de la solucin mediante el apoyo metodolgico adaptable a cada cliente. aspectos funcionales del sistema; la definicin de la Misin del Sistema, la construccin del rbol de Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso. Adems, se introduce un Proceso de Anlisis que permite traducir el Modelo de Requisitos en el Modelo Conceptual, manteniendo la trazabilidad entre ambos.
* RETO: Propone un modelo de requisitos para capturar los
* Herramientas de soporte IR
* CONTROLA: Ofrece recursos importantes tales como:
Administracin de requisitos, administracin de casos de uso, administracin de casos de prueba y error, planeamiento de liberaciones, administracin de implementaciones, control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos. * OSRMT (Open Source Requirements Management Tool)4 Herramienta libre para la gestin de requisitos, cuyas principales caractersticas son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versin 1.3 trae un mdulo para manejar la trazabilidad y lo introduce para el control de cambios; as mismo, genera la documentacin de los requisitos tratados.
* Herramientas de soporte IR
* Documento:
* Descripcin de un proyecto de desarrollo de software:* Tema * Objetivo del sistema * Alcance del sistema * Descripcin de los usuarios y clientes * Descripcin del equipo de desarrollo * Restricciones del proyecto * Nivel de certeza de los requisitos * Riesgos del proyecto * Modelo de proceso de desarrollo de software elegido yjustificacin
*