Ingeniería de Requisitos
Etapas
Elicitación
Actividad involucrada en el descubrimiento de los requisitos del sistema. Aquí los analistas deben trabajar junto con el cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar y las restricciones que se pueden presentar.
Conocer el dominio del problema, de forma tal que los analistas puedan entenderse con los clientes y usuarios y sean capaces de transmitir dicho conocimiento al resto del equipo.
Descubrir necesidades reales entre clientes y usuarios, haciendo énfasis en aquellas que la mayor parte de las veces se asumen y toman por implícitas.
Consensuar los requisitos entre los propios clientes y usuarios hasta obtener una visión común de los mismos.
Análisis
Sobre la base de la obtención realizada previamente, comienza esta fase la cual tiene como propósito descubrir problemas con los requisitos del sistema identificados hasta el momento
Detectar conflicto en los requisitos que suelen provenir de distintas fuentes y presentar contradicciones o ambigüedades debido a su naturaleza informal.
Profundizar en el conocimiento del dominio del problema puede facilitar el proceso de construir un producto útil para clientes y usuarios (Durán, 2000).
Especificación
Aquí se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle. Empleando estándares que garanticen que se ha revisado los detalles de cada requerimiento.
Validación
Garantiza que los requisitos, una vez analizados y resueltos los posibles conflictos, correspondan realmente a las necesidades de clientes y usuarios, para evitar que, a pesar de que el producto final sea técnicamente correcto, no sea satisfactorio.
Ciclo de Vida del Software
Fases
Fase de Planificación
Se realiza el planteamiento del problema, se definen alcances y objetivos del software.
Fase de Análisis
Busca definir los requisitos que son los que dirigirán el desarrollo del proyecto de software.
Fase de Diseño
Se estudian posibles opciones de implementación para el software que hay que construir, estructura general del mismo.
Fase de Pruebas
Busca detectar fallos cometidos en las etapas anteriores para corregirlos.
Fase de Mantenimiento
Se realizan tres puntos referenciados: mantenimiento correctivo, mantenimiento adaptativo y mantenimiento perfectivo.
Modelos
Cascada
En su concepción básica, cada una de las actividades genera, como salidas, productos y modelos que son utilizados como entradas para el proceso subsiguiente; esto supone que una actividad debe terminarse (por lo menos, en algún grado) para empezar la siguiente.
Espiral
Fue diseñado por Boehm en el año 1988 y se basa en una serie de ciclos repetitivos para ir ganando madurez en el producto final. El espiral se repite las veces que sea necesario hasta que el cliente o el usuario obtenga la satisfacción de sus necesidades.
En este modelo hay 4 actividades que envuelven a las etapas: planificación, análisis de riesgo, implementación y evaluación. Una de sus principales ventajas es que los riesgos van disminuyendo conforme avanzan los ciclos o interacciones.
Iterativo o por prototipos
Este modelo consiste en un procedimiento que permite al equipo de desarrollo diseñar y analizar una aplicación que represente el sistema que será implementado (McCracken y Jackson, 1982).
Scrum
El Scrum consiste en realizar un análisis de los requerimientos del sistema (Product Backlog), señalar cuáles serán los objetivos a corto o mediano plazo dentro de un sprint, o sea, la fase de desarrollo. Posteriormente, los desarrolladores harán lo suyo, se realizarán algunas pruebas y se retroalimentará de acuerdo con lo conseguido al terminar la última fase.
Kanban
El modelo Kanban es uno de los modelos más visuales de las metodologías ágiles; este consiste en la creación de un tablero con etiquetas, donde se seccionan cada una de las fases de su desarrollo, además se clasifican de acuerdo con los equipos de trabajo y se les asignan objetivos a corto, mediano y largo plazo.
Xp o Programación Extrema
La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre este tema: Extreme Programming Explained: Embrace Change (1999). Esta metodología es adaptable según las necesidades y requerimientos a implementar, además, el cliente se encuentra involucrado en el proceso de desarrollo lo que hace que el producto pueda ser terminado en un menor tiempo.
Paradigmas
Tradicional
Los paradigmas tradicionales se identifican, fundamentalmente, por ser lineales, es decir se trata de completar cada proceso de principio a fin hasta que quede listo para avanzar a la segunda fase del ciclo del software.
Lineal.
Base para nuevas metodologías.
Orientado a Objetos
Las etapas de desarrollo de software en el paradigma orientado a objetos, se conforma principalmente por la creación de clases, análisis de requisitos y el diseño. Con este paradigma se pretende que el código fuente sea reutilizable para otros proyectos.
Código fuente reutilizable.
Desarrollo Ágil
El objetivo de este paradigma es el desarrollo de proyectos en poco tiempo, se simplifican procesos tediosos, se agilizan las fases del desarrollo y las interacciones se hacen en corto tiempo.
Terminar en poco tiempo
Involucra a los clientes durante el desarrollo
Sugiere Ideas.
Propone mejoras.
Se mantiene al tanto.
Requisitos
Requerimientos de Usuario
Son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
Requerimientos de Sistema
Requerimiento Funcionales
Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que este debe reaccionar a entradas particulares; o también pueden declarar explícitamente lo que el sistema no debe hacer.
Requerimiento No Funcionales
Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Dentro de estos requerimientos se encuentra todo lo referente a la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento.
Objetivos que debe alcanzar esta etapa
El analista proporciona un sistema de retroalimentación que refina el entendimiento conseguido en la etapa de obtención.
Ha surgido para englobar los procesos de desarrollo y gestión de requisitos en el ciclo de vida del software
La ingeniería de requisitos 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).
Algunas Definiciones
La ingeniería de requisitos es el proceso de estudiar las necesidades del usuario para llegar a una definición de requisitos de sistema, hardware o software. - (IEEE, 1990).
La ingeniería de requisitos puede considerarse como un proceso de descubrimiento y comunicación de las necesidades de clientes y usuarios y la gestión de los cambios de dichas necesidades. - (Amador, 2000)
Analizar y definir
Actividades
Definición del alcance del proyecto.
Identificación del negocio.
Toma de requerimientos
Estudio de procesos de negocio.
Calendarización del proyecto.
Artefactos
Modelo de Negocio.
Análisis y realización de casos de uso.
Modelo de procesos y actividades de negocio.
Cronograma de proyecto.
Descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de los requerimientos del sistema
Importantes
deben ser
Necesario
Completo
Consistente
Correcto
Factible
Modificable
Priorizado
Verificable
Rastreable
Claro
Deben cumplirse
