TRABAJO DE ALGORITMO

PRESENTADO POR: Cristian David Paredes Fernández

PRESENTADO A: HUGO FERNANDO POLANIA DUSSAN

CENTRO AGROEMPRESARIAL Y DESARROLLO PECUARIO DEL HUILA

SENA-GARZON

TECNOLOGO EN ANALISIS Y DESARROLLO EN SISTEMAS DE INFORMACION

866036

Metodología Gestión de Requerimientos

Capitulo 1° "IDENTIFICACIÓN DE NECESIDADES CON EL CLIENTE"

Para identificar las necesidades del cliente se debe realizar una entrevista en la cual se debe determinar la manera como el cliente desea adquirir un software, es esta entrevista se determinara el costo y el tiempo de desarrollo de software.

Luego se le facilitara unas técnicas al usuario el cual decidirá para la ejecución del proyecto

Definición del alcance

La definición del alcance tiene como propósito describir y delimitar claramente las necesidades del cliente, las cuales pretenden ser cumplidas con el proyecto.

Fuentes de información claves

Se debe tener información clave para definir el alcance final de una manera detallada

Se recomienda tener en cuente esta información para cumplir cada uno de los objetivos

Beneficios de una buena definición

Se ahorran tiempo y recursos del proyecto

Se asigna con responsabilidad los recursos establecidos

Definir el empeño y control del proyecto

Capítulo 2 TÉCNICAS PARA IDENTIFICAR REQUERIMIENTOS

En la actualidad para la elaboración de un software que usa distintas herramientas se deben primero identificar distintas técnicas de requerimiento las cuales son:

Técnicas generales para la identificación de requerimientos:

Están conformados por tres:

Entrevista: es muy utilizada para la recolección de opiniones e criterios que sirven para desarrollar distintas actividades.

Cuestionario: esta dirigida a un público en específico, para obtener mayor información.

Lluvia de ideas: esta es utilizada por un equipo de trabajo el cual expones ideas para un beneficio.

Técnicas específicas para la identificación de requerimientos

Este consiste en agrupar dos técnicas generales que se complementas en este caso la observación y el escenario .

Observación: esta permite dar a conocer las actividades realizadas.

Escenario: esta permite conocer el comportamiento de evento conformado.

Técnicas para Identificar Requisitos Funcionales y No Funcionales

En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La compleción significa que todos los servicios solicitados por el usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias.

Identificación de Requerimientos no funcionales

Son las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.

Técnicas de investigación de los atributos de las necesidades de los clientes

Esta se encarga de reunir información en los distintos grupos para luego analizarlas.

Grupos focales:

Está conformado reuniendo a un grupo seleccionado de clientes, conjuntamente con un moderador que va a conducir un debate de grupo sobre una serie de aspectos y cuestiones concretas en las que se focaliza la discusión.

Análisis contextual:

Con esta técnica cliente que cuente su experiencia de uso y responda a las sagaces y hábiles preguntas de los métodos anteriores, sino que se le solicita, además, ver cómo utiliza el producto para comprender el porqué de su necesidad y discutir sobre el terreno cada uno de los detalles y particularidades de uso.

Clientes piloto:

Es un Clientes de alto prestigio y conocimiento que pueden ofrecer un formidable campo de pruebas para el nuevo producto. Claro está que no es fácil encontrar este tipo de clientes piloto, pero también es claro que los beneficios de esta técnica son elevados.

Capítulo 3 DEFINICIÓN REQUERIMIENTOS

Para realizar una correcta definición de los requerimientos del proyecto y que éstos satisfactorios para el cliente, se deben tener en cuenta las siguientes actividades:

Requerimientos Funcionales:

Estos determina el software, definiendo las relaciones de su operación y su implementación, también en lo que el sistema no debe hacer y que validaciones se deben realizar, teniendo en cuenta cual será el comportamiento del sistema.

Requerimientos no funcionales:

Estos se basan en las restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, usabilidad, portabilidad, entre otros.

Capítulo 4 TÉCNICAS PARA DEFINIR REQUISITOS:

Para obtener los requisito Técnicas más modernas incluyen los prototipos del cliente se emplear distintas técnica, tales como las entrevistas, utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas

Definición de diagramas:

Cuando se inicia con el desarrollo de un sistema por lo general nos encontramos con la dificultad de no saber como dar inicio a la especificación y descripción de la funcionalidad en general que buscamos apoyar con dicha herramienta, para ello hay muchas herramientas en el mercado que buscan apoyar dicha tarea.

Cuando no Utilizar Diagramas

No dibujar diagramas porque el proceso te lo dice

Porque te sientes culpable de no hacerlo o porque piensas que es buen diseño hacerlo. Los buenos diseñadores escriben código y dibujan diagramas solamente cuando es necesario.

Cuando Utilizar los Diagramas

Utilizar los diagramas cuando varias personas necesiten entender la estructura de una parte particular del diseño, porque todos ellos lo estarán trabajando simultáneamente. Deténgase cuando todos ellos estén de acuerdo que lo han entendido

Cuando dos o mas personas estén en desacuerdo con un elemento particular que debería ser diseñado, y quieres un consenso del equipo. Detente cuando la decisión haya sido tomada.

Capítulo 5 PRUEBAS DE REQUERIMIENTOS:

El objetivo de las pruebas de verificación es buscar discrepancias entre los requerimientos y la ejecución del software.

Planeación: tiempo y recursos del proyecto.

Diseños y casos de pruebas: para la verificación del requerimiento

Ejecución: evaluación del requisitos, reportes (errores y sugerencias)

Cierre: visto buena para la aprobación.

Capítulo 6 GESTIÓN DE CAMBIOS

La gestión de cambio en los proyectos debe ser una coordinación planificada de las actividades que conlleve el logro de los objetivos o propósitos comunes a través de una comunicación clara y eficiente.

Identificación Control de cambios:

Análisis de la Solicitud:

La solicitud es recibida por parte del cliente interno o externo, esta debe ser recibida por parte del líder de implementación para ser analizada. Uno de los puntos importantes para analizar son el Alcance y el Tiempo, esto con el fin de identificar si la solicitud es viable realizarla sobre el mismo requerimiento.

Valorar el cambio

Otro punto importante es valorar la factibilidad de la solicitud realizada ya sea por un cliente interno o uno externo. Para ello se deberá ir recorriendo todo el árbol de requisitos viendo como les afecta el cambio, y aquí es donde entra la trazabilidad de los requisitos.

Analizar Modificación

El líder de implementación debe realizar el análisis de la solicitud para saber que tanto impacta la modificación e identificar puntualmente las modificaciones solicitadas que afectan el requerimiento completo y así identificar si el cambio afecta más de un requerimiento.

Documentar Cambio

Para tener un mejor control sobre los cambios solicitados es recomendable realizar una documentación clara para evitar ambigüedades en las modificaciones que se van a realizar a los requerimientos.

Aprobación Control de Cambios

Aprobar Cambios

Una vez se ha analizado el impacto del cambio, se debe tomar una decisión. Si se acepta el cambio, tras negociarlo con el cliente, se continuará con la actividad de implementar el cambio. En caso contrario, se deberá negociar con el cliente el siguiente paso a realizar.

Planear Cambio

Después de tener una aprobación formal del cambio aceptado se planea el tiempo necesario y los recursos necesarios para llevar a cabo el cambio aprobado.

Realizar Cambio

Una vez se planea el cambio aprobado se debe realizar las modificaciones necesarias a todos los productos que resulten afectados por dicho cambio.

Revisar Cambio

Una vez se realice el cambio es recomendable hacer una verificación por parte del líder para identificar que el requerimiento incluye todos los cambios solicitados y que fueron aprobados.

Actualizar Línea Base

Es recomendable utilizar el nuevo requerimiento como línea base, esto con el fin de trabajar siempre sobre la última versión del requerimiento.

Informar

Una vez se realice la modificación de la solicitud se debe informar a los interesados que el cambio ya está realizado para que sea verificado por el cliente.

Capítulo 7 GESTIÓN DE REQUERIMIENTO:

Matriz de relación de documentos:

Matriz de valoración y aprobación de los requisitos

La siguiente matriz de trazabilidad es la que nos permite valorar si el requisito cumple con todas las etapas llevadas a cabo en la metodología, en caso que todos los criterios se cumplan se dará por cerrado y aprobado el requisito.

Cumple=C, esto nos indica que el requisito cumple con el criterio correctamente, se encuentra en color verde.

No Cumple= N, El color rojo es para dar una señal de alerta informando que el requisito no está cumpliendo correctamente con el criterio de aceptación y que se debe revisar porque razón esto pasando esto y tomar las medidas de control necesarias.

No aplica= En caso que el criterio no aplique en ese caso para el requisito se mostrar en amarillo informando que no hay problema.

Matriz de Control de cambios

La matriz de control de cambios nos permite registrar los controles de cambios que se van presentando, en esta matriz podremos registrar el número de control de cambio que se tiene asignado, la referencia a la documentación de dicho control, quien aprobó el control, su porcentaje de ejecución hasta llegar al 100%, el o los requisitos afectados y una descripción breve del control de cambios.