Monografias.com > Ingeniería
Descargar Imprimir Comentar Ver trabajos relacionados

Ingeniería De Requerimientos Ingeniería De Software




Enviado por johany



Partes: 1, 2

    Indice
    1.
    Introducción

    2.
    La ingeniería de requerimientos y sus principales
    actividades

    3. Técnicas y
    herramientas utilizadas en la ingeniería de
    requerimientos

    4. Análisis
    comparativo de las técnicas de ingeniería de
    requerimientos

    5. Conclusiones Y
    Recomendaciones

    6. Referencias
    Bibliográficas

    1.
    Introducción
    En la actualidad, son
    muchos los procesos de
    desarrollo de
    software que
    existen. Con el pasar de los años, la Ingeniería de
    Software ha introducido y popularizado una serie de
    estándares para medir y certificar la calidad, tanto
    del sistema a
    desarrollar, como del proceso de
    desarrollo en
    sí. Se han publicado muchos libros y
    artículos relacionados con este tema, con el modelado de
    procesos del
    negocio y la reingeniería. Un número creciente de
    herramientas
    automatizadas han surgido para ayudar a definir y aplicar un
    proceso de
    desarrollo de software efectivo. Hoy en
    día la economía global
    depende más de sistemas
    automatizados que en épocas pasadas; esto ha llevado a los
    equipos de desarrollo a enfrentarse con una nueva década
    de procesos y estándares de calidad.

    Sin embargo, ¿cómo explicamos la alta
    incidencia de fallos en los proyectos de
    software? ¿Por qué existen tantos proyectos de
    software víctimas de retrasos, presupuestos
    sobregirados y con problemas de
    calidad? ¿Cómo podemos tener una producción o una economía de calidad,
    cuando nuestras actividades diarias dependen de la calidad del
    sistema?

    Tal vez suene ilógico pero, a pesar de los
    avances que ha dado la tecnología,
    aún existen procesos de producción informales, parciales y en
    algunos casos no confiables.

    La Ingeniería de Requerimientos 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 ambigüedades, en forma consistente y compacta,
    el comportamiento
    del sistema; de esta manera, se pretende minimizar los problemas
    relacionados al desarrollo de sistemas.

    La razón principal para escoger este tema se
    fundamentó en la gran cantidad de proyectos de software
    que no llegan a cumplir sus objetivos. En
    nuestro país somos partícipes de este problema a
    diario, en donde se ha vuelto común la compra de sistemas
    extranjeros, para luego "personalizarlos" supuestamente a la
    medida de las empresas.

    Tal "personalización", la mayoría de las
    veces, termina retrasando el proyecto en
    meses, o incluso en años. La problemática del
    año 2000 trajo como consecuencia una serie de cambios
    apresurados en los sistemas existentes; cambios que, desde mi
    punto de vista, no fueron bien planificados.

    El reemplazo de plataformas y tecnologías
    obsoletas, la compra de sistemas completamente nuevos, las
    modificaciones de todos o de casi todos los programas que
    forman un sistema, entre otras razones, llevan a desarrollar
    proyectos en calendarios sumamente ajustados y en algunos casos
    irreales; esto ocasiona que se omitan muchos pasos importantes en
    el ciclo de vida
    de desarrollo, entre estos, la definición de los
    requerimientos.

    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.

    Con este trabajo se pretende alcanzar los siguientes
    objetivos:

    • Resaltar la importancia que tiene la
      Ingeniería de Requerimientos dentro del ciclo de
      desarrollo.
    • Dar a conocer las diferentes alternativas que existen
      para identificar requerimientos.
    • Ayudar a comprender la diferencia que existe entre
      las diferentes técnicas
      utilizadas en la IR.
    • Minimizar las dudas que se tiene sobre los casos de
      uso.
    • Mostrar la utilización de herramientas
      CASE dentro de la administración de requisitos.

    2. La ingeniería de
    requerimientos y sus principales
    actividades

    ¿Qué son
    Requerimientos?
    Normalmente, un tema de la Ingeniería de
    Software tiene diferentes significados. De las muchas
    definiciones que existen para requerimiento, ha
    continuación se presenta la definición que aparece
    en el glosario de la
    IEEE .

    (1) Una condición o necesidad de un usuario para
    resolver un problema o alcanzar un objetivo. (2)
    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.
    (3) Una representación documentada de una condición
    o capacidad como en (1) o (2).

    Los requerimientos puedes dividirse en requerimientos
    funcionales y requerimientos no funcionales.
    Los requerimientos funcionales definen las funciones que el
    sistema será capaz de realizar. Describen las
    transformaciones que el sistema realiza sobre las entradas para
    producir salidas.
    Los requerimientos no funcionales tienen que ver con características que de una u otra forma
    puedan 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
    Las características de un requerimiento son sus
    propiedades principales. Un conjunto de requerimientos en
    estado de
    madurez, deben presentar una serie de características
    tanto individualmente como en grupo. A
    continuación se presentan las más importantes.
    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 del
    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 está 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.
    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 o 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 en un proyecto puede
      ser difícil 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.

    Ingeniería de Requerimientos vs. Administración de Requerimientos
    El proceso de recopilar, analizar y verificar las necesidades
    del cliente para un
    sistema es llamado Ingeniería de Requerimientos. La meta de la
    ingeniería de requerimientos (IR) es entregar una
    especificación de requisitos de software correcta y
    completa.

    A continuación se darán algunas
    definiciones para ingeniería de requerimientos.
    "Ingeniería de Requerimientos es la disciplina
    para desarrollar una especificación completa, consistente
    y no ambigua, la cual servirá como base para acuerdos
    comunes entre todas las partes involucradas y en dónde se
    describen las funciones que
    realizará el sistema" Boehm 1979.

    "Ingeniería de Requerimientos es el proceso por
    el cual se transforman los requerimientos declarados por los
    clientes , ya
    sean hablados o escritos, a especificaciones precisas, no
    ambiguas, consistentes y completas del comportamiento
    del sistema, incluyendo funciones, interfaces, rendimiento y
    limitaciones". STARTS Guide 1987.

    "Es el proceso mediante el cual se intercambian
    diferentes puntos de vista para recopilar y modelar lo que el
    sistema va a realizar. Este proceso utiliza una
    combinación de métodos,
    herramientas y
    actores, cuyo producto es un
    modelo del
    cual se genera un documento de requerimientos" Leite
    1987.

    "Ingeniería de requerimientos es un enfoque
    sistémico para recolectar, organizar y documentar los
    requerimientos del sistema; es también el proceso que
    establece y mantiene acuerdos sobre los cambios de
    requerimientos, entre los clientes y el
    equipo del proyecto" Rational Software

    Importancia de la Ingeniería de
    Requerimientos
    Los principales beneficios que se obtienen de la
    Ingeniería de Requerimientos son:

    • Permite gestionar las necesidades del proyecto en
      forma estructurada: Cada actividad de la IR consiste de una
      serie de pasos organizados y bien definidos.
    • Mejora la capacidad de predecir cronogramas de
      proyectos, así como sus resultados: La IR proporciona un
      punto de partida para controles subsecuentes y actividades de
      mantenimiento, tales como estimación de
      costos,
      tiempo y
      recursos
      necesarios.
    • Disminuye los costos y
      retrasos del proyecto: Muchos estudios han demostrado que
      reparar errores por un mal desarrollo no descubierto a tiempo,
      es sumamente caro; especialmente aquellas decisiones tomadas
      durante la RE.
    • Mejora la calidad del software: La calidad en el
      software tiene que ver con cumplir un conjunto de
      requerimientos (funcionalidad, facilidad de uso, confiabilidad,
      desempeño, etc.).
    • Mejora la
      comunicación entre equipos: La especificación
      de requerimientos representa una forma de consenso entre
      clientes y desarrolladores. Si este consenso no ocurre, el
      proyecto no será exitoso.
    • Evita rechazos de usuarios finales: La
      ingeniería de requerimientos obliga al cliente a
      considerar sus requerimientos cuidadosamente y revisarlos
      dentro del marco del problema, por lo que se le involucra
      durante todo el desarrollo del proyecto.

    Personal involucrado en la Ingeniería de
    Requerimientos

    Realmente, son muchas las personas involucradas en el
    desarrollo de los requerimientos de un sistema. Es importante
    saber que cada una de esas personas tienen diversos intereses y
    juegan roles específicos dentro de la planificación del proyecto; el
    conocimiento de cada papel
    desempeñado, asegura que se involucren a las personas
    correctas en las diferentes fases del ciclo de vida,
    y en las diferentes actividades de la IR.

    No conocer estos intereses puede ocasionar una comunicación poco efectiva entre clientes y
    desarrolladores, que a la vez traería impactos negativos
    tanto en tiempo como en presupuesto. Los
    roles más importantes pueden clasificarse como
    sigue:

    • Usuario final: Son las personas que usarán el
      sistema desarrollado. Ellos están relacionados con la
      usabilidad, la disponibilidad y la fiabilidad del sistema;
      están familiarizados con los procesos específicos
      que debe realizar el software, dentro de los parámetros
      de su ambiente
      laboral.
      Serán quienes utilicen las interfaces y los manuales de
      usuario.
    • Usuario Líder: Son los individuos que comprenden
      el ambiente del
      sistema o el dominio del
      problema en donde será empleado el software
      desarrollado. Ellos proporcionan al equipo técnico los
      detalles y requerimientos de las interfaces del
      sistema.
    • Personal de Mantenimiento: Para proyectos que
      requieran un mantenimiento eventual, éstas personas son
      las responsables de la
      administración de cambios, de la
      implementación y resolución de anomalías.
      Su trabajo consiste en revisar y mejorar los procesos del
      producto ya finalizado.
    • Analistas y programadores: Son los responsables del
      desarrollo del producto en sí; ellos interactúan
      directamente con el cliente.
    • Personal de pruebas: Se
      encargan de elaborar y ejecutar el plan de pruebas
      para asegurar que las condiciones presentadas por el sistema
      son las adecuadas. Son quienes van a validar si los
      requerimientos satisfacen las necesidades del
      cliente.

    Otras personas que pueden estar involucradas,
    dependiendo de la magnitud del proyecto, pueden ser:
    administradores de proyecto, documentadores, diseñadores
    de base de datos,
    entre otros.

    Puntos a considerar durante la Ingeniería de
    Requerimientos
    Aunque la lista no está completa, se enumeran los puntos
    más importantes.
    Objetivos del negocio y ambiente de trabajo
    Aunque los objetivos del negocio están definidos
    frecuentemente en términos generales, son usados para
    descomponer el trabajo en
    tareas específicas. En ciertas situaciones IR se enfoca en
    la descripción de las tareas y en el análisis de
    sistemas similares. Esta información proporciona la base para
    especificar el sistema que será construido; aunque
    frecuentemente se añadan al sistema tareas que no encajan
    con el ambiente de trabajo planificado.

    El nuevo sistema cambiará el ambiente de trabajo,
    sin embargo, es muy difícil anticipar los efectos actuales
    sobre la
    organización. Los cambios no ocurren solamente cuando
    un nuevo software es implementado y puesto en producción;
    también ocurren cuando cambia el ambiente que lo rodea
    (nuevas soluciones a
    problemas, nuevo equipo para instalar, etc.). La necesidad de
    cambio es
    sustentada por el enorme costo de
    mantenimiento; aunque existen diversas razones que dificultan el
    mantenimiento del software, la falta de atención a la IR es la
    principal.

    Frecuentemente la especificación inicial es
    también la especificación final, lo que obstaculiza
    la
    comunicación y el proceso de aprendizaje de
    las personas involucradas; esta es una de las razones por las
    cuales existen sistemas inadecuados.

    Punto de vista de los clientes

    Muchos sistemas tienen diferentes tipos de clientes.
    Cada grupo de
    clientes tiene necesidades diferentes y, diferentes
    requerimientos tienen diferentes grados de importancia para
    ellos. Por otro lado, escasas veces tenemos que los clientes son
    los mismos usuarios; trayendo como consecuencia que los clientes
    soliciten procesos que causan conflictos con
    los solicitados por el usuario.

    Diferentes puntos de vistas también pueden tener
    consecuencias negativas, tales como datos
    redundantes, inconsistentes y ambiguos.

    El tamaño y complejidad de los requerimientos
    ocasiona desentendimiento, dificultad para enfocarse en un solo
    aspecto a la vez y dificultad para visualizar relaciones
    existentes entre requerimientos.

    • Barreras de comunicación

    La ingeniería de requerimientos depende de una
    intensa comunicación entre clientes y analistas
    de requerimientos; sin embargo, existen problemas que no pueden
    ser resueltos mediante la comunicación.

    Para remediar esto, se deben abordar nuevas
    técnicas operacionales que ayuden a superar estas
    barreras y así ganar experiencia dentro del marco del
    sistema propuesto.

    Pocos sistemas son construidos desde cero. En la
    práctica, los proyectos se derivan de sistemas ya
    existentes. Por lo tanto, los analistas de requerimientos deben
    comprender esos sistemas, que por lo general son una integración de componentes de varios
    proveedores.

    Para encontrar una solución a problemas de este
    tipo, es muy importante hacer planeamientos entre los
    requerimientos y la fase de diseño; esto minimizará la
    cantidad de fallas directas en el código.

    • Documentación de requerimientos

    Los documentos de
    ingeniería de requerimientos son largos. La
    mayoría están compuestos de cientos o miles de
    páginas; cada página contiene muchos detalles que
    pueden tener efectos profundos en el resto del
    sistema.

    Normalmente, las personas se encuentran con
    dificultades para comprender documentos de
    este tamaño, sobre todo si lo leen cuidadosamente. Es
    casi imposible leer un documento de especificación de
    gran tamaño, pues difícilmente una persona puede
    memorizar los detalles del documento. Esto causa problemas y
    errores que no son detectados hasta después de haberse
    construido el sistema.

    Actividades de la Ingeniería de
    Requerimientos

    En el proceso de IR son esenciales diversas actividades.
    En este documento serán presentadas secuencialmente, sin
    embargo, en un proceso de ingeniería de requerimientos
    efectivo, estas actividades son aplicadas de manera continua y en
    orden variado.

    Dependiendo del tamaño del proyecto y del
    modelo de
    proceso de software utilizado para el ciclo de desarrollo, las
    actividades de la IR varían tanto en número como en
    nombres. La tabla #1 muestra algunos
    ejemplos de las actividades identificadas para cada
    proceso.

    A pesar de las diferentes interpretaciones que cada
    desarrollador tenga sobre el conjunto de actividades mostradas en
    la tabla anterior, podemos identificar y extraer cinco
    actividades principales que son:

    • Análisis del Problema
    • Evaluación y Negociación
    • Especificación
    • Validación
    • Evolución

    Tabla 1. Actividades de la IR para diferentes
    modelos de procesos de Ingeniería
    de Software

    MODELO

    Oliver and Steiner 1996

    EIA / IS-632

    IEEE Std 1220- 1994

    CMM nivel Repetitivo (2)

    RUP

     

     

     

     

     

     

    Actividades

    Evaluar la información
    disponible

    Análisis de requerimientos

    Análisis de Requerimientos

    Identificación de
    requerimientos

    Análisis del Problema

    Definir métricas efectivas

    Análisis funcional

    Estudio de los requerimientos

    Identificación de restricciones del
    sistema a desarrollar

    Comprender las necesidades de los
    involucrados

    Crear un modelo del comportamiento del
    sistema

    Síntesis

    Validación de requerimientos

    Análisis de los requerimientos

    Definir el sistema

    Crear un modelo de los objetos

    Análisis y control del sistema

    Análisis funcional

    Representación de los
    requerimientos

    Analizar el alcance del proyecto

    Ejecutar el análisis

     

    Evaluación y estudio de
    funciones

    Comunicación de los
    requerimientos

    Modificar la definición del
    sistema

    Crear un plan
    secuencial de construcción y pruebas

     

    Verificación de funciones

    Validación de requerimientos

    Administrar los cambios de
    requerimientos

     

     

    Síntesis

     

     

     

     

    Estudio y evaluación del
    diseño

     

     

     

     

    Verificación física

     

     

     

     

    Control

     

     

    A continuación se explicará
    cada una de ellas, presentándolas en el orden en que deben
    ser aplicadas para un nuevo proyecto.
    Análisis del Problema
    El objetivo de
    esta actividad es entender las verdaderas necesidades del
    negocio.
    Antes de describir qué pasos deben cumplirse en esta
    actividad, debemos tener una definición clara del
    término "Problema".
    "Un problema puede ser definido como la diferencia entre las
    cosas como se perciben y las cosas como se desean" . Aquí
    vemos nuevamente la importancia que tiene una buena
    comunicación entre desarrolladores y clientes; de esta
    comunicación con el cliente depende que entendamos sus
    necesidades.

    A través de la definición de problema,
    podemos ver entonces que la actividad de "Análisis del
    Problema" tiene por objetivo que se comprendan los problemas del
    negocio, se evalúen las necesidades iniciales de todos los
    involucrados en el proyecto y que se proponga una solución
    de alto nivel para resolverlo.

    Durante el análisis del problema, se realizan una
    serie de pasos para garantizar un acuerdo entre los involucrados,
    basados en los problemas reales del negocio.

    Estos pasos son los siguientes

    Comprender el problema que se está resolviendo:
    Es importante determinar quién tiene el problema
    realmente, considerar dicho problema desde una variedad de
    perspectivas y explorar muchas soluciones
    desde diferentes puntos de vista. Veamos la siguiente necesidad:
    "El cliente se queja mucho por la enorme fila que debe formar
    para realizar una transacción bancaria".

    Perspectiva del cliente = Pérdida de tiempo
    Perspectiva del banco = Posibles
    pérdidas de clientes

    Posibles soluciones pueden ser, determinar por
    qué demoran los cajeros, colocar una nueva caja (implica
    contratación de nuevos cajeros), abrir una nueva sucursal
    (involucra personal nuevo y
    estudio de
    mercado), realizar transacciones por otros medios
    (teléfono, internet, mediante cajeros
    automáticos, autobancos, etc).

    Como puede verse, 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 cuanta tanto la perspectiva
    técnica como la del negocio.

    Construir un vocabulario común: Debe
    confeccionarse un glosario en
    dónde se definan todos los términos que tengan
    significados comunes (sinónimos) y que serán
    utilizados durante el proyecto. Por ejemplo, las palabras
    pignoración, retención, valor en
    suspenso, custodia, garantía, entre otras, son utilizadas
    para referirse a la acción de dejar una prenda (puede ser
    cualquier forma de ahorros) como garantía de una deuda
    adquirida.

    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 están en la misma página,
    además de ser reutilizable en otros proyectos.

    Identificar a 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
    de ingeniería de requerimientos, aunque esto no garantiza
    que vaya a estar disponible toda la información necesaria
    para especificar un sistema adecuado.

    Para saber quiénes son las personas,
    departamentos, organizaciones
    internas o externas que se verán afectadas por el sistema,
    debemos realizar algunas preguntas.

    • ¿Quién usará el sistema que se
      va a construir?
    • ¿Quién desarrollará el
      sistema?
    • ¿Quién probará el
      sistema?
    • ¿Quién documentará el
      sistema?
    • ¿Quién dará soporte al
      sistema?
    • ¿Quién dará mantenimiento al
      sistema?
    • ¿Quién mercadeará,
      venderá, y/o distribuirá el sistema?
    • ¿Quién se beneficiará por el
      retorno de inversión del sistema?

    Como vemos, debe conocerse la opinión de todo
    aquél que de una u otra forma está involucrado con
    el sistema, ya sea directa o indirectamente.

    Definir los límites y
    restricciones del sistema: Este punto es importante pues debemos
    saber lo que se está construyendo, y lo que no se
    está construyendo, para así 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

    La diversa gama de fuentes de las
    cuales provienen los requerimientos, hacen necesaria una evaluación
    de los mismos antes de definir si son adecuados para el cliente.
    El término "adecuado" significa que ha sido percibido a un
    nivel aceptable de riesgo tomando en
    cuenta las factibilidades técnicas y económicas, a
    la vez que se buscan resultados completos, correctos y sin
    ambigüedades.

    En esta etapa se pretende limitar las expectativas del
    cliente apropiadamente, tomando como referencia los niveles de
    abstracción y descomposición de cada problema
    presentado.

    Los principales pasos de esta actividad son:

    Descubrir problemas potenciales: En este paso se asegura
    que todas las características descritas en el punto 1.1
    estén presentes en cada uno de los requerimientos, es
    decir, se identifican aquellos requerimientos ambiguos,
    incompletos, inconsistentes, etc.

    Clasificar los requerimientos:

    En este paso se busca identificar la importancia que
    tiene un requerimiento en términos de
    implementación. A esta característica se le conoce
    como 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.

    En base a la prioridad, cada requerimiento puede ser
    clasificados como mandatorio, deseables o innecesarios. Un
    requerimiento es mandatorio si afecta una operación
    crítica del negocio. Si existe algún proceso que se
    quiera incluir para mejorar los procesos actuales, estamos ante
    un requerimiento deseable; y si se trata de un requerimiento
    informativo o que puede esperar para fases posteriores, el
    requerimiento es catalogado como innecesario.

    Una vez hecha esta categorización de los
    requerimientos, puedo tomar como estrategia
    general el incluir los mandatorios, discutir los deseables y
    descartar los innecesarios. Antes de decidir la inclusión
    de un requerimiento, también debe analizarse su costo,
    complejidad, y una cantidad de otros factores. Por ejemplo, si un
    requerimiento fuera trivial de implementar, puede ser una buena
    idea incluirlo por más que éste sea sólo
    deseable.

    Evaluar factibilidades y riesgos:
    Involucra la evaluación de factibilidades técnicas
    (¿pueden implementarse los requerimientos con la tecnología actual?);
    factibilidades operacionales (¿puede ser el sistema
    utilizado sin alterar el organigrama
    actual?); factibilidades económicas (¿ha sido
    aprobado por los clientes el presupuesto?).

    En la actividad de evaluación y
    negociación, se incrementa la comunicación entre el
    equipo de desarrollo y los afectados. Para que los requerimientos
    puedan ser comunicados 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 a
      requerimientos 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 Requisitos de Software
    (SRS)

    La especificación de requisitos de software es la
    actividad en la cual se genera el documento, con el mismo nombre,
    que contiene una descripción completa de las necesidades y
    funcionalidades del sistema que será desarrollado;
    describe el alcance del sistema y la forma en como hará
    sus funciones, definiendo los requerimientos funcionales y los no
    funcionales.

    En la SRS se definen todos los requerimientos de
    hardware y
    software, diagramas,
    modelos de
    sistemas y cualquier otra información que sirva de soporte
    y guía para fases posteriores.

    Es importante destacar que la especificación de
    requisitos es el resultado final de las actividades de
    análisis y evaluación de requerimientos; este
    documento resultante será utilizado como fuente
    básica de comunicación entre los clientes, usuarios
    finales, analistas de sistema, personal de
    pruebas, y todo aquel involucrado en la implementación del
    sistema.

    Los clientes y usuarios utilizan la SRS para comparar si
    lo que se está proponiendo, coincide con las necesidades
    de la empresa. Los
    analistas y programadores la utilizan para determinar el producto
    que debe desarrollarse. El personal de pruebas elaborará
    las pruebas funcionales y de sistemas en base a este documento.
    Para el administrador del
    proyecto sirve como referencia y control de la
    evolución del sistema.

    La SRS posee las mismas características de los
    requerimientos: completa, consistente, verificable, no ambigua,
    factible, modificable, rastreable, precisa, entre otras. Para que
    cada característica de la SRS sea considerada, cada uno de
    los requerimientos debe cumplirlas; por ejemplo, para que una SRS
    se considere verificable, cada requerimiento definido en ella
    debe ser verificable; para que una SRS se considere modificable,
    cada requerimiento debe ser modificable y así
    sucesivamente. Las características de la SRS son
    verificadas en la actividad de Validación, descrita en el
    punto 3.4.

    La estandarización de la SRS es fundamental pues
    ayudará, entre otras cosas, a facilitar la lectura y
    escritura de
    la misma. Será un documento familiar para todos los
    involucrados, además de asegurar que se cubren todos los
    tópicos importantes.

    Existen plantillas creadas para la SRS, sin embargo,
    cada uno tiene la potestad de crear su propia plantilla. En el
    anexo #1 se muestra una
    plantilla completa para la especificación de
    requisitos.

    Validación de Requisitos

    La validación 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.

    En este punto es necesario recordar que la SRS debe
    estar libre de errores, por lo tanto, la validación
    garantiza que todos los requerimientos presentes en el documento
    de especificación sigan los estándares de
    calidad.

    No debe confundirse la actividad de evaluación de
    requerimientos con la validación de requerimientos. La
    evaluación verifica las propiedades de cada requerimiento,
    mientras que la validación revisa el cumplimiento de las
    características de la especificación de
    requisitos.

    Durante la actividad de validación pueden hacerse
    preguntas en base a cada una de las características que se
    desean revisar. A continuación se presentan varios
    ejemplos:

    • ¿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 y el presupuesto disponible?
      (factible)
    • ¿Está la SRS escrita en un lenguaje
      apropiado? (clara)
    • ¿Existe facilidad para hacer cambios en los
      requerimientos? (modificable)
    • ¿Está claramente definido el origen de
      cada requisito? (rastreable)
    • ¿Pueden los requerimientos ser sometidos a
      medidas cuantitativas? (verificable)

    La validación de requerimientos es importante
    pues de ella depende que no existan elevados costos de
    mantenimiento para el software desarrollado.

    Evolución de los requerimientos

    Los requerimientos son una manera de comprender mejor el
    desarrollo de las necesidades de los usuarios y cómo los
    objetivos de la organización pueden cambiar, por lo
    tanto,

    es esencial planear posibles cambios a los
    requerimientos cuando el sistema sea desarrollado y utilizado. La
    actividad de evolución es un proceso externo

    que ocurre a lo largo del ciclo de vida del
    proyecto.

    Los requerimientos cambian por diferentes razones. Las
    más frecuentes son:

    • Porque al analizar el problema, no se hacen las
      preguntas correctas a las personas correctas.
    • Porque cambió el problema que se estaba
      resolviendo.
    • Porque los usuarios cambiaron su forma de pensar o
      sus percepciones.
    • Porque cambió el ambiente de negocios.
    • Porque cambió el mercado en
      el cual se desenvuelve el negocio.

    Cambios a los requisitos involucra modificar el tiempo
    en el que se va a implementar una característica en
    particular, modificación que a la vez puede tener impacto
    en otros requerimientos. Por esto, la administración de
    cambios involucra actividades como establecer políticas,
    guardar históricos de cada requerimiento, identificar
    dependencias entre ellos y mantener un control de
    versiones.

    Tener versiones de los requerimientos es tan importante
    como tener versiones del código, ya que evita tener
    requerimientos emparchados en un proyecto

    Entre algunos de los beneficios que proporciona el
    control de versiones están:

    • Prevenir cambios no autorizados.
    • Guardar revisiones de los documentos de
      requerimientos.
    • Recuperar versiones previas de los
      documentos.
    • Administrar una estrategia de "releases".
    • Prevenir la modificación simultánea a
      los requisitos.

    En vista que las peticiones de cambios provienen de
    muchas fuentes, las mismas deben ser enrutadas en un solo
    proceso. Esto se hace con la finalidad de evitar problemas y
    conseguir estabilidad en los requerimientos.

    Partes: 1, 2

    Página siguiente 

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter
    Comments
    All comments.
    Comments