Essays.club - Ensayos gratis, notas de cursos, notas de libros, tareas, monografías y trabajos de investigación
Buscar

Componentes de la ingeniería de requisitos.

Enviado por   •  13 de Febrero de 2018  •  2.875 Palabras (12 Páginas)  •  276 Visitas

Página 1 de 12

...

Alcance

- Este procedimiento se aplica en todos los proyectos de desarrollo de software "manejados" de Cubika.

Controles

Controles serán llevados a cabo por lo procedimientos definidos dentro de la disciplina PPQA.

Roles definidos y responsabilidades

- Analista (Funcional)

El analista funcional es el rol que releva y especifica los requerimientos, modelando y especificando los casos de uso, delineando la funcionalidad del sistema y delimitando su alcance.

Es el responsable de:

- Obtener y analizar en detalle los requerimientos de los stakeholders.

- Elaborar y administrar el Plan de Administración de Requerimientos junto con el PM del proyecto.

- Definir en detalle el alcance del sistema.

- Analizar el impacto de los requerimientos de cambio, realizados sobre la funcionalidad ya definida.

- Armar y mantener actualizado el glosario de términos comunes en el sistema.

- Identificar actores y casos de uso de negocio y de implementación.

- Especificar casos de uso, modelo de caso de uso, especificaciones suplementarias, y demás artefactos que se utilicen para comenzar con el desarrollo del producto.

- Desarrollar y mantener actualizado el Documento de Visión.

- Administrar y mantener las dependencias entre casos de uso y actores, así como también la trazabilidad funcional.

- Líder de Proyecto:

El líder de proyecto es el rol que gestiona el proyecto y es el responsable final por el éxito del mismo. En relación a requerimientos, debe validar y gestionar el alcance del producto durante el ciclo de vida del proyecto.

Es el responsable de:

- Validar la línea base de requerimientos, el Documento de Visión y el SRS

- Armar la planificación en función de los requerimientos definidos

- Gestionar el alcance a lo largo del ciclo de vida

- Participar como miembro del CCB en la resolución de los pedidos de cambio

- QA-Quality Assurance:

El QA es el rol que verifica la calidad en los artefactos de requerimientos.

Es el responsable de:

- Verificar consistencia y coherencia de artefactos de requerimientos.

- Asegurar la calidad del proceso de requerimientos.

- Verificar que los cambios hayan sido correctamente impactados en los requerimientos.

- Arquitecto de software:

El arquitecto tiene la responsabilidad de conducir las principales decisiones técnicas, denominadas "arquitectura del software". Esto incluye identificar y documentar los aspectos más significativos de la arquitectura, incluyendo requerimientos no funcionales, diseño, implementación y deployments del sistema.

Es el responsable de:

- Análisis de la arquitectura.

- Asegurar la viabilidad de la arquitectura requerida.

- Identifica mecanismos de diseño.

- Estructura el modelo de implementación.

- Describe la arquitectura en tiempo de ejecución.

- Describe la distribución del sistema en las distintas etapas.

Diagrama de Actividades del Proceso

[pic 1]

Actividades para levantar Requerimientos

Objetivo

- El objetivo principal de este workflow es mejorar los conocimientos acerca del problema a ser resuelto, identificar a los stakeholders, definir el entorno, las funcionalidades clave y las restricciones de la solución propuesta.

Frecuencia

- Las tareas de este workflow se deberán realizar en reiteradas oportunidades durante la fase de Incepción. Luego, a lo largo del ciclo de vida del proyecto será necesario repetirlo para poder atender a los inevitables requerimientos de cambios que se presenten.

- Esta tarea se realiza normalmente al principio de cada iteración.

Entradas

- Modelo de Casos de Uso de Negocio

- Modelo de Entidades de Dominio

- Realizaciones de Casos de Uso de Negocio

- RFP

- Project Charter

- Propuesta Económica

Salidas

- Documento de Visión Inicial

Paso a Paso

Actividad

Descripción

Responsable

Conocer en totalidad el problema a ser resuelto

Analizar la información relevada del negocio (Modelo de Casos de Uso de Negocio, RFP) para comprender la totalidad del problema a ser resuelto.

En este punto no deben quedar dudas sobre el entendimiento del problema entre todos los stakeholders.

Analista Funcional

Identificar las restricciones impuestas sobre el sistema

Identificar las restricciones que se hayan detectado durante el relevamiento impuestas al nuevo sistema.

Las restricciones deben ser detalladas en el documento de Visión inicial.

Analista Funcional

Definir las características del sistema

...

Descargar como  txt (22 Kb)   pdf (79.5 Kb)   docx (28.8 Kb)  
Leer 11 páginas más »
Disponible sólo en Essays.club