06 Ingeniería De Requerimientos.ppt

30
Ingeniería De Requerimientos

Transcript of 06 Ingeniería De Requerimientos.ppt

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    1/30

    Ingeniera De Requerimientos

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    2/30

    Introduccin

    cmo explicamos la alta incidencia defallos en los proyectos de software?

    Por qu existen tantos proyectos de

    software vctimas de retrasos,presupuestos sobregirados y conproblemas de calidad?

    Cmo podemos tener una produccin ouna economa de calidad, cuandonuestras actividades diarias dependen dela calidad del sistema?

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    3/30

    Ingeniera de Requerimientos

    Cumple un papel primordial en elproceso de produccin de software, ya

    que enfoca un rea fundamental: ladefinicin de lo que se desea producir.

    Su principal tarea es la generacin deespecificaciones correctas quedescriban con claridad, sinambigedades, en forma consistente ycompacta, el comportamiento del

    sistema

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    4/30

    13 12 127 6

    50

    0

    10

    20

    30

    40

    50

    60

    Informacin

    errneadel

    usuario

    Requisitos

    incompletos

    Cambiosen

    los

    requisitos

    Habilidades

    tcnicas

    pobres

    Mala

    direcin

    Otros

    Ms de 37% de los proyectos de software

    fracasan debido a problemas en los

    requerimientos.

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    5/30

    Requerimientos

    Tipos:

    Funcionales

    No funcionales

    Caractersticas Necesario

    Conciso

    Completo Consistente

    No ambiguo

    verificable

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    6/30

    Ingeniera de Requerimientos

    El proceso de recopilar, analizar y

    verificar las necesidades del cliente

    para un sistema es llamado Ingenierade Requerimientos.

    La meta de la ingeniera de

    requerimientos (IR) es entregar unaespecificacin de requisitos de

    software correcta y completa.

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    7/30

    Personal involucrado en la

    Ingeniera de Requerimientos

    Usuario final

    Usuario Lder

    Analistas y programadores

    Personal de pruebas

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    8/30

    Puntos a considerar durante la

    Ingeniera de Requerimientos

    Barreras de comunicacin: intensa

    comunicacin entre clientes y

    analistas de requerimientos Evolucin e integracin del sistema:

    quizs comprender sistemas ya

    existentes Documentacin de requerimientos:

    dificultad para comprender

    documentos largos.

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    9/30

    Actividades de la IR

    Anlisis del Problema

    Evaluacin y Negociacin

    Especificacin

    Validacin

    Evolucin

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    10/30

    Anlisis del Problema

    entender las verdaderas necesidades

    del negocio

    Pasos:

    Comprender el problema que se est

    resolviendo: perspectiva tcnica como la

    del negocio Construir un vocabulario comn. Ej:

    glosario

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    11/30

    Anlisis del Problema

    Identificar a los afectados por el sistema Quin usar el sistema que se va a construir?

    Quin desarrollar el sistema?

    Quin probar el sistema? Quin documentar el sistema?

    Quin dar soporte al sistema?

    Quin dar mantenimiento al sistema?

    Quin vender, y/o distribuir el sistema? Quin se beneficiar por el retorno de inversin

    del sistema?

    Definir los lmites y restricciones del sistema

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    12/30

    Evaluacin y negociacin de los

    requerimientos

    pasos

    Descubrir problemas potenciales

    Clasificar los requerimientos: prioridad.

    Mandatorio

    Deseable

    Innecesario

    =>hecha esta categorizacin, se puede tomar como

    estrategia general el incluir los mandatorios,discutir los deseables y descartar los

    innecesarios

    Evaluar factibilidades y riesgos

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    13/30

    Especificacin de Requisitos de

    Software (SRS)

    actividad en la cual se genera eldocumento con descripcin completa delas necesidades y funcionalidades del

    sistema describe el alcance del sistema

    Define requerimientos funcionales y los

    no funcionales requerimientos de hardware y software

    Diagramas

    modelos de sistemas

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    14/30

    Especificacin de Requisitos de

    Software (SRS)

    Los clientes y usuarios utilizan la SRS paracomparar si lo que se est proponiendo, coincidecon las necesidades de la empresa.

    Los analistas y programadores la utilizan paradeterminar el producto que debe desarrollarse.

    El personal de pruebas elaborar las pruebasfuncionales y de sistemas en base a este

    documento. Para el administrador del proyecto sirve como

    referencia y control de la evolucin del sistema.

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    15/30

    Validacin de Requisitos

    Es la actividad de la IR que permite demostrarque los requerimientos definidos en el sistemason los que realmente quiere el cliente; ademsrevisa que no se haya omitido ninguno, que nosean ambiguos, inconsistentes o redundantes Estn incluidas todas las funciones requeridas por

    el cliente? (completa)

    Existen conflictos en los requerimientos?

    (consistencia) Tiene alguno de los requerimientos ms de una

    interpretacin? (no ambigua)

    Est cada requerimiento claramente representado?

    (entendible)

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    16/30

    Validacin de Requisitos

    Pueden los requerimientos ser implementados

    con la tecnologa y el presupuesto disponible?

    (factible)

    Est la SRS escrita en un lenguaje apropiado?

    (clara)

    Est claramente definido el origen de cada

    requisito? (rastreable) Pueden los requerimientos ser sometidos a

    medidas cuantitativas? (verificable)

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    17/30

    Evolucin de los

    requerimientos

    esencial planear posibles cambios a

    los requerimientos cuando el sistema

    sea desarrollado y utilizado es un proceso externo que ocurre a lo

    largo del ciclo de vida del proyecto

    Ojo !!

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    18/30

    Tcnicas y herramientas

    utilizadas en la IR

    Entrevistas y Cuestionarios

    Lluvia de Ideas (Brainstorm)

    Prototipos

    Prototipo rpido (o concept prototipe):

    Prototipo evolutivo

    Administracin de Requerimientos con

    Casos de Uso

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    19/30

    Qu son los Casos de Uso?

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    20/30

    Casos de Uso

    Son una tcnica para especificar el

    comportamiento de un sistema: "Un caso de

    uso es una secuencia de interacciones entre un

    sistema y alguien o algo que usa alguno de susservicios.

    Por ejemplo: un sistema de ventas, si pretende

    tener xito, debe ofrecer un servicio para

    ingresar un nuevo pedido de un cliente. Cuandoun usuario accede a este servicio, podemos

    decir que est "ejecutando" el caso de uso

    ingresando pedido.

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    21/30

    Los Casos de Uso y UML

    Son una excelente forma de

    especificar el comportamiento externo

    de un sistema fue incorporada al lenguaje estndar

    de modelado UML (Unified Modeling

    Language) propuesto por IvarJacobson, James Rumbaugh y Grady

    Booch

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    22/30

    Definiciones y Notaciones

    Actores

    Casos de uso

    Extensiones

    Relaciones

    Abstraccin

    Herencia

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    23/30

    Actores

    Un actor es una agrupacin uniforme de

    personas, sistemas o mquinas que

    interactan con el sistema que estamos

    construyendo de la misma forma.

    Por ejemplo, para una empresa que recibe

    pedidos en forma telefnica, todos los

    operadores que reciban pedidos y losingresen en un sistema de ventas, si

    pueden hacer las mismas cosas con el

    sistema, son considerados un nico actor:

    "Empleado de Ventas".

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    24/30

    Actores

    Es importante tener clara la diferencia

    entre usuario y actor.

    Un actor es una clase de rol, mientrasque un usuario es una persona que,

    cuando usa el sistema, asume un rol

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    25/30

    Actores

    Los actores se

    representan

    con dibujossimplificados

    de personas,

    llamados en

    ingls "stickman" (hombres

    de palo).

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    26/30

    Actores

    Otro sistema

    que interacta

    con el queestamos

    construyendo

    tambin es un

    actor

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    27/30

    Casos de Uso

    Las flechas pueden usarse para indicar el

    flujo de informacin entre el sistema y el

    actor. El nombre se expresa con un verbo en

    gerundio, seguido generalmente por el

    principal objeto o entidad del sistema que

    es afectado por el caso. Grficamente, los casos de uso se

    representan con un valo, con el nombre

    del caso en su interior.

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    28/30

    Casos de Uso Grficamente,

    los casos de

    uso se

    representan

    con un valo,con el nombre

    del caso en su

    interior. Importante: el nombre del

    caso siempre estexpresado desde el punto

    de vista del actor y no desde

    el punto de vista del

    sistema.

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    29/30

    Conclusiones y recomendaciones

    A pesar de la importancia que tiene la Ingenierade Requerimientos, ha costado mucho que se lepreste la atencin adecuada a esta actividad.

    No existe un modelo de proceso ideal para la IR IR no depende solamente de la forma en cmo

    se percibe el problema, sino tambin, del nivelde experiencia que tengan los involucrados.

    tomarse el tiempo necesario para conocer anuestros clientes y usuarios, as como suambiente de trabajo.

  • 5/21/2018 06 Ingenier a De Requerimientos.ppt

    30/30

    Conclusiones y recomendaciones

    El uso de la tcnica de Casos de uso

    es independiente del mtodo de

    diseo a usar. Finalmente, entregar software de

    calidad, a tiempo y dentro del

    presupuesto, har que nuestrosclientes confen y asegurar el

    crecimiento y madurez de la relacin

    de negocio