Please enable JavaScript.

Coggle requires JavaScript to display documents.

Ingeniería de requisitos - Coggle Diagram

- - - - "Un marco común para los procesos del ciclo de vida de los programas informáticos, con una terminología bien definida, a la que pueda remitirse la industria del software. Contiene procesos, actividades y tareas aplicables durante la adquisición, el suministro, el desarrollo, el funcionamiento, el mantenimiento o la eliminación de sistemas, productos y servicios informáticos. Estos procesos del ciclo de vida se llevan a cabo mediante la participación de los interesados, con el objetivo final de lograr la satisfacción del cliente (s.p.)".
  - - - Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales).
        
        Las fases del modelo de ciclo del software son:
        
        Planificación
        
        En esta primera fase se realiza el planteamiento del problema, se definen alcances y objetivos del software.
        
        Objetivos: estudio de viabilidad, realizar planificación detallada.
        
        Análisis
        
        Esta fase busca definir los requisitos que son los que dirigirán el desarrollo del proyecto de software.
        
        Objetivos: conocer los requisitos, asegurar que los requisitos son alcanzables, formalizar acuerdo con el cliente.
        
        Diseño
        
        En esta fase se estudian posibles opciones de implementación para el software que hay que construir, estructura general del mismo.
        
        Objetivos: Identificar soluciones tecnológicas, asignar recursos materiales, proponer identificar y seleccionar, establecer métodos de validación, ajustar especificaciones.
        
        Implementación
        
        Pruebas
        
        Esta fase busca detectar fallos cometidos en las etapas anteriores para corregirlos.
        
        Objetivos: Realizar los ajustes necesarios para corregir posibles errores o inconsistencias.
        
        Mantenimiento
        
        En esta fase se realizan tres puntos referenciados: mantenimiento correctivo, mantenimiento adaptativo y mantenimiento perfectivo.
        
        Objetivos: Operación asegurar que el uso del proyecto es el que se pretendía, mantenimiento.
    - - Son los productos intermedios que generan las fases. Pueden ser materiales o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecido.
  - - - Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software e intenta determinar el orden de las etapas involucradas y los criterios de transición asociados entre estas.
        
        Existen modelos preestablecidos con los cuales se pude elaborar un proyecto:
        
        Paradigma tradicional
        
        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.
        
        Su desventaja es la pérdida de tiempo si se encuentran errores en una fase avanzada porque al devolverse se debe pasar nuevamente por todas las fases y reestructurar de acuerdo con las modificaciones.
        
        Modelos del paradigma tradicional más utilizados:
        
        3 more items...
        
        Paradigma 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.
        
        Paradigma de 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.
        
        Una de las principales diferencias con los paradigmas anteriores es que el cliente se ve involucrado en el proyecto durante el desarrollo de este, así, el cliente sugiere mejoras, propone ideas y se mantiene al tanto del desarrollo del producto, a diferencia del paradigma tradicional y el orientado objeto donde el cliente únicamente está al principio.
        
        Estos se caracterizan por estar basados en etapas del ciclo de vida del software tradicional, pero combinándolas con algunas técnica
        
        3 more items...
- - - - El problema que se presenta es que al inicio del desarrollo el cliente no sepa exactamente lo que necesita; por tanto, se debe averiguar con ayuda de distintas técnicas.
        
        Se estima que 25% de los requerimientos iniciales de un sistema cambian antes de que el sistema comience a utilizarse. Por ello, muchas prácticas resultan efectivas para gestionar adecuadamente los requerimientos de un sistema y, en cierto modo, controlar su evolución.
        
        En la siguiente tabla, se describen las actividades y los artefactos que se realizan en la fase de definición de requisitos.
        
        Fase
        
        Análisis (definición de requisitos).
        
        Actividades
        
        Artefactos
        
        1 more item...
        
        Definición del alcance del proyecto
        
        1 more item...
- - - - Establecen el alcance del trabajo subsecuente, pueden definir estrategias de desarrollo, riesgos, tomar decisiones de negocio (viabilidad de negocio), de proyecto (tiempo, recursos), de sistema (arquitectura).
      - Indican al equipo del proyecto qué requieren los usuarios (necesidades de negocio).
      - El éxito o fracaso de un proyecto está altamente influenciado por la calidad de los requisitos y el proceso para gestionarlos durante el desarrollo de un producto.
  - - - la primera clasificación se encuentra relacionada con el nivel de descripción con la que cuentan estos
        
        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
        
        Estos requerimientos establecen con detalle las funciones, servicios y restricciones operativas del sistema. El documento de requerimientos del sistema deberá ser preciso, y definir exactamente lo que se va a desarrollar.
      - En la siguiente clasificación se observa la que se da a los requerimientos del sistema
        
        Requerimientos 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.
        
        Ejemplos:
        
        Se debe ingresar cédula, nombre y teléfono de cada cliente.
        
        Se requiere un listado de clientes por zona.
        
        Requerimientos 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.
        
        Ejemplos:
        
        Las consultas deben resolverse en menos de 3 segundos.
        
        El lenguaje de programación debe ser Java.
- - - - 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.
        
        Los principales objetivos:
        
        Conocer el dominio del problema
        
        Descubrir necesidades reales entre clientes y usuarios
        
        Consensuar los requisitos entre los propios clientes y usuarios hasta obtener una visión común de los mismos.
    - - tiene como propósito descubrir problemas con los requisitos del sistema identificados hasta el momento
        
        Los principales objetivos:
        
        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
    - - Aquí se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle.
    - - Por último, la 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.