111111

METODOLOGIA DE GESTION DE REQUERIMIENTOS

CENTRO AGROEMPRESARIAL Y DESARROLLO PECUARIO DEL HUILA TEGNOLOGO EN ANALISIS Y DESARROLLO DE SISTEMAS DE

INFORMACION (ADSI) 866036

MAICKOLL STIVENS RAMIREZ GUTIERREZ CRISTIAN DAVID PAREDES FERNANDEZ

ContenidoDEFINICION DE ALCANCE................................................................................................4

FUENTES DE INFORMACION.....................................................................................................5

RECOMENDACIONES PARA DEFINIR EL ALCANCE..................................................................7

BENEFICION DE UNA DEFINICION..........................................................................................7

1. Técnicas generales para la identificación de requerimientos...............................................9

Entrevista.............................................................................................................................9

Lluvia de ideas....................................................................................................................10

Cuestionarios......................................................................................................................10

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

OBSERVACIÓN....................................................................................................................11

ESCENARIOS.......................................................................................................................11

3.Técnicas para identificar requisitos funcionales y no funcionales.......................................12

IDENTIFICACION DE REQUERIMIENTOS FUNCIONALES......................................................12

IDENTIFICACION DE LOS REQUERIMIENTOS NO FUNCIONALES.........................................12

ASPECTOS A TENER EN CUENTA EN LA IDENTIFICACION DE REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES....................................................................................13

IDENTIFICACION DE ELEMENTOS.......................................................................................13

4.TEGNICAS DE INVESTIGACION DE LOS ATRIBUTOS DE LAS NESESIDADES DE LOS CLIENTES...............................................................................................................................................14

GRUPOS FOCALES...................................................................................................................14

ENTREVISTA INDIVIDUAL........................................................................................................14

ANALISIS CONTEXTUAL...........................................................................................................14

CLIENTE PILOTO.....................................................................................................................14

DEFINICIÓN DE REQUISITOS...................................................................................................15

CLASIFICACIÓN DE REQUERIMIENTOS....................................................................................16

REQUERIMIENTOS FUNCIONALES:.....................................................................................16

REQUERIMIENTOS NO FUNCIONALES................................................................................16

PREPARAR PLAN DE REVISIÓN:...............................................................................................16

PREPARAR REUNIÓN:.............................................................................................................16

REALIZAR REUNIÓN:...............................................................................................................16

IDENTIFICAR DE DEFECTOS DE LA ESPECIFICACIÓN:..............................................................17

REALIZACIÓN DE CORRECCIONES A LOS DOCUMENTOS:.......................................................17

INFORMAR MODIFICACIONES A LOS INTERESADOS:..............................................................17

CIERRE DE LOS REQUERIMIENTOS:.........................................................................................17

DEFINICIÓN DE DIAGRAMAS..................................................................................................18

Cuando no Utilizar Diagramas............................................................................................18

Cuando Utilizar los Diagramas............................................................................................18

De estados:.........................................................................................................................19

De secuencia:.....................................................................................................................19

De caso de uso:..................................................................................................................19

DEFINICIÓN DE CASOS DE USO...............................................................................................19

La identificación de actores:...............................................................................................19

Intereses de los actores:.....................................................................................................19

La identificación de eventos y escenarios que este podría llegar a tener:.........................20

Especificación de Casos de uso...............................................................................................20

Prototipos...............................................................................................................................21

Características de un prototipo..........................................................................................21

Definición de criterios de aceptación.....................................................................................21

Planeaciones..........................................................................................................................22

Diseño de casos de prueba.....................................................................................................23

EJECUCIÓN DE CASOS DE UNA PRUEBA.................................................................................23

Cierre......................................................................................................................................23

Identificación control de cambios..........................................................................................25

Valorar el cambio..............................................................................................................25

Analizar modificación.........................................................................................................25

Documentar cambio...........................................................................................................26

Aprobación control de cambio...............................................................................................26

Aprobar cambios................................................................................................................26

Planear cambio...................................................................................................................26

Realizar cambio..................................................................................................................26

Revisar cambio...................................................................................................................26

Actualizar line base.............................................................................................................26

Informar.............................................................................................................................26

Entregable control de cambios...............................................................................................26

Matriz de relación de documentos....................................................................................27

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

Matriz de Control de cambios............................................................................................28

Capítulo 1 “IDENTIFICACION DE NESESIDADES CON EL CLIENTEsi los requerimientos se enfocan a describir las necesidades del cliente, entonces para recabarlos haya que obtener la información de primera mano. Esto es mediante la entrevista u obteniendo la documentación del cliente que describa la manera de como el cliente desee que funcione el software.

DEFINICION DE ALCANCELa definición del alcance tiene como propósito describir y delimitar claramente las necesidades del cliente, las cuales pretenden ser cumplidas con el proyecto.Es importante para la definición del alcance la identificación de los siguientes aspectos:   

     Los entregables que hacen parte del alcance. se recomienda describir y listar los entregables finales principalmente los que deben ser aprobados por el cliente.Los tipos de datos que están en el alcance y fuera de él. Los “tipo de datos” se refieren a la categoría del negocio de los entregables tales como datos financieros, datos de ventas, datos de los empleados, etc.

           Las fuentes de datos (bases de datos) que están en el alcance y fuera de él. Esto es similar a los tipos de datos, excepto que ahora se está refiriendo a los datos agregados tales como base de datos de clientes, Contabilidad general, sistema de facturación y cobranza, etc.

    Áreas involucradas en el alcance y fuera de él. En algunos casos, las áreas involucradas en el proyecto ayudan a delimitar el alcance.

      Condiciones fuera del alcance. Se recomienda como punto de claridad y contraste al describir entregables que no serán creados, qué organizaciones no serán impactadas, qué facilidades y funciones no serán incluidas, entre otros aspectos.

FUENTES DE INFORMACION

Cualquier información creada debe ser usada como base para definir el alcance de manera más detallada. Si no se cuenta con suficiente información para la definición del alcance, se debe buscar apoyo con el patrocinador para reunir información adicional.

RECOMENDACIONES PARA DEFINIR EL ALCANCEAlgunas recomendaciones son:

Desarrollar un escrito o un documento frontal Detallar claramente que actividades y procesos que son parte del

proyecto Definir los criterios que se utilizarán para determinar si el proyecto ha

finalizado exitosamente, es decir, los criterios de aceptación. Al definir el alcance, tener en mente que lo que no esté en el alcance

está fuera del  proyecto. Al definir el alcance, tener en mente que lo que no esté en el alcance

está fuera del  proyecto. Al definir el alcance, tener en mente que lo que no esté en el alcance está fuera del  proyecto.

Formalizar la aceptación del alcance con el cliente. 

BENEFICION DE UNA DEFINICIONEl alcance marca la pauta para la toma de decisiones futuras y realización de actividades a nivel Operativo y nos ayuda a:

Mejorar la precisión en las estimaciones de tiempo, costo y recursos.  Facilitar la asignación clara de recursos y responsabilidades. Definir la línea base para la medición del desempeño y control Identificar, tanto el equipo de proyecto como el cliente, el objetivo final

del proyecto y sus entregables. Desarrollar y confirmar un entendimiento común del  proyecto entre

ambas partes, cliente y equipo de proyecto.  Asegurar que el proyecto incluye todo el trabajo requerido y solamente el

trabajo requerido para terminar exitosamente. "Asegurar que el proyecto incluye todo el trabajo requerido para terminar exitosamente."

CAPITULO 2 TEGNICAS PARA IDENTIFICAR REQUERIMIENTOS

En la actualidad las organizaciones enfocadas al desarrollo de aplicaciones de software utilizan diferentes herramientas que permiten facilitar la fase de identificación de requerimientos, puesto que se presta mayor atención a las necesidades que se identifican en todas las fases del ciclo de vida del sistema; para así obtener un mejor aprovechamiento, entendimiento, y rendimiento al momento que entre en ejecución el sistema que se esté desarrollando.

  

Las organizaciones actuales utilizan múltiples herramientas para el apoyo de la identificación de los requerimientos.

A continuación se especifican cada una de las técnicas utilizadas: 

o Técnicas generales para la identificación de requerimientoso Técnicas específicas para la identificación de requerimientoso Técnicas para Identificar Requisitos Funcionales y No Funcionaleso Técnicas de investigación de los atributos de las necesidades de los

clienteso

A continuación se presenta documento de uso opcional como apoyo para identificación y definición de requerimiento:

Formato ObjetivoMR_002_Entrevista (Ver formato) Sugerir las preguntas  que permitan detallar el

requerimiento.

 1. Técnicas generales para la identificación de requerimientos

Las técnicas generales son las que permiten investigar aspectos generales para posteriormente ser especificado con mayor detalle con el apoyo de técnicas más específicas. Estas técnicas son más abiertas y requieren ser adecuadamente orientadas para cubrir a información que se quiere capturar.

 

Entrevista

Esta técnica es muy utilizada para recolección de opiniones, criterios o descripciones.

 Se lleva a cabo mediante conversaciones estructuradas

Es fundamental que la relación con el cliente este basada en confianza para dar a conocer la información más detallada

Antes de iniciar una entrevista es importante tener en cuenta los siguientes Tips.

1.    estudiar al tipo de persona a las cuales se les realizara la entrevista.

2.    Estudiar cómo será el entorno donde se llevara a cabo la entrevista para identificar que tan confortables estarán las personas y así obtener la información de la manera más eficiente.

3.    Estudiar como es la manera de hablar de las personas individualmente o en un equipo de trabajo.

4.    Verificar que las personas tengan la disponibilidad para dar a conocer las necesidades que posterior a esto se puedan convertir en requerimientos.

5.    Revisar como es la relación del cliente con la organización que realizará la identificación de los requerimientos, esto con el fin de facilitar el trabajo y la disposición de ambas partes.

6.    Entender que es importante obtener la mayor información para la definición de los requerimientos, teniendo en cuenta que nada es obvio para las organizaciones de desarrollo de software. 

Lluvia de ideas

Esta técnica es abierta y se utiliza para explorar necesidades iniciales con la ayuda de la identificación de ideas de todas las personas que hacen parte del equipo de apoyo para la identificación de los requerimientos.

Es utilizada para investigar nuevos servicios o necesidades que no son claramente identificadas.

Algunos Tips para tener en cuenta cuando se realice una lluvia de ideas:

1. Escoger un sitio tranquilo que permita que las personas involucradas se sientan cómodas y dispuestas para dar a conocer sus ideas.

2. Tomar la iniciativa para iniciar una reunión enfocada en la confianza.

3. Tomar nota de las ideas que las personas expresan en los equipos de trabajo.

Cuestionarios

Esta técnica puede ir dirigida a un público específico o general, lo que permite obtener una información  mayor, ya que se tiene la posibilidad de

involucrar más personas para el desarrollo de los cuestionarios y que estos tengan diferentes puntos de vista. Lo importante es tener en cuenta  que se debe tener un mayor cuidado en la selección de los encuestados y de la forma en que se pregunta para obtener respuestas concretas y confiables

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

Las técnicas como las especificas permiten complementar las técnicas generales para tener mayor detalle.

OBSERVACIÓN

Esta técnica permite obtener información directa sobre la manera en que se realizan las actividades. Esta técnica sirve para revisar que no existen emisiones o interpretaciones erróneas sobre el proceso realizado.

ESCENARIOS

Esta técnica permite conocer el comportamiento del producto ante determinados eventos considerando los datos, acciones y acepciones que se pueden presentar.

 

3.Técnicas para identificar requisitos funcionales y no funcionales

Ya que los requerimientos del sistema de software se clasifican en funcionales y no funcionales deben tener en cuenta las siguientes técnicas para para la identificación correcta.

IDENTIFICACION DE REQUERIMIENTOS FUNCIONALES

Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de manera en que este reaccionara a entradas particulares.

Muchos de los problemas de la ingeniería de software viene de la impresión de la especificación de requerimientos.

Para un desarrollador es natural dar interpretaciones de un requerimiento ambiguo.

En la práctica para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y compleción. Esto se debe a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes.

IDENTIFICACION DE LOS REQUERIMIENTOS NO FUNCIONALES

1. No se refiere directamente a las funcionales específicas que entrega el sistema, sino las propiedades emergentes de este.

2. Define la restricciones del sistema como la capacidad de los dispositivo de entrada y salida.

3. Surgen de la necesidades del usuario como: Las restricciones en el presupuesto Las políticas de la organización La necesidad de lainteroperabilidad

Estos diferentes requerimientos se clasifican en:

1) Requerimientos de producto. Especifican el comportamiento del producto.2) Requerimientos organizacionales. Se derivan de las políticas y

procedimientos existen en la organización del cliente y en la del desarrollador.

3) Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo.

ASPECTOS A TENER EN CUENTA EN LA IDENTIFICACION DE REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

Requerimiento básico: se estructura su identificación al buscar respuestas a preguntas como:

¿Cuál es el proceso básico de la empresa? Que datos utiliza o produce este proceso? Cuáles son los límites impuestos por el tiempo y la carga de trabajo? Que controles de desempeño utiliza?

Las siguientes preguntas sin de utilidad para recibir la comprensión necesaria:

¿Cuál es la finalidad de la actividad dentro de la empresa? Que pasoso se siguen para realizarla? ¿Dónde se realizan estos pasos? ¿Quiénes los realizan? Cuanto tiempo tardan en efectuarlos? Con cuanta frecuencia lo hacen? Quienes emplean la información resulrante?

IDENTIFICACION DE ELEMENTOS

Durante esta, se debe identificar muy claramente los siguientes elementos:

Proceso Flujo de datos entre procesos Datos de cada flujo de datos Bases de datos Datos de base de datos

4.TEGNICAS DE INVESTIGACION DE LOS ATRIBUTOS DE LAS NESESIDADES DE LOS CLIENTES

Lo que se hace es preguntarle al cliente sobre cada una de sus necesidades, con el objetivo de clasificar y ponderar su importancia.

Este proceso de investigación debe ser suficientemente inteligente para conseguir respuestas que permitan elevar realmente el nivel de competitividad de la solución buscada.

GRUPOS FOCALES se conforman 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 la que se focaliza la discusión.

En el debate se establece una relación de afinidad por lo que todas las respuestas giran en torno a la situación a analizar.

ENTREVISTA INDIVIDUAL

Esta técnica en más eficaz que la anterior, es entre un experto del cliente y el entrevistador cualificado del equipo de análisis. Tiene unas ventajas sobre el grupo focal y es que se puede matizar en un espacio de mayor privacidad.

Si el moderado, en el caso de los grupos focales, el entrevistador juega el papel de crítico, no solo tiene que dominar las técnicas de la entrevista, sino que además debe reunir la experiencia y dominio suficiente sobre el tema discutir para generar al cliente una motivación positiva.

ANALISIS CONTEXTUALCon esta técnica lo que se hace no solo es pedir al cliente que cuente su experiencia de uso y responda las preguntas de los metodosanteriores, sino que le solisite además ver como utiliza el producto para comprender el por que de su necesidad y discutir sobre el terreno cada uno de los detalles y particularidades de uso.

CLIENTE PILOTOUn método de investigación mas sofisticado es utilizar clientes piloto. clientes con alto prestigio y conocimiento que pueden ofrecer un formidable campo de pruebas para el nuevo producto.

Capítulo 3 DEFINICIÓN REQUERIMIENTOS

Para tener una buena definición de requerimientos es necesario realizar una buena identificación de los mismos, posterior a esto es importante definirlos de manera detallada, donde se involucre la información aportada por los usuarios

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

DEFINICIÓN DE REQUISITOS

Para realizar con éxito la definición de los requerimientos es importante conseguir que los requerimientos sean claramente definidos para minimizar la ambigüedad de los requerimientos, para esto es importante tener en cuenta lo siguiente:

Definir los requerimientos teniendo en cuenta la información identificada con la perspectiva del usuario

 

Reutilizar requerimientos, revisando proyectos ya finalizados para ver si contienen material potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que un requisito ha sido especificado satisfactoriamente para un producto y que el producto ha tenido éxito, el requerimiento no tendrá que volverse a inventar, podrá ser utilizado las veces que se desee teniendo en cuenta los derechos de autor.

Se debe documentar los requerimientos de una forma clara y correcta. En la mayoría de los proyectos se observa que la documentación de los requerimientos puede parecer una tarea tediosa, pero es la única manera de asegurar que la esencia de los requisitos ha sido capturada correctamente, y que esto pueda ser probado.

CLASIFICACIÓN DE REQUERIMIENTOS

REQUERIMIENTOS FUNCIONALES: 

Estos requerimientos se utilizan para determinar que hara el software definirndo la relación de su operación y su implementación.

a) Los requerimientos se dividen en dos puntos de vista: el primero tiene relación con el usuario y el segundo tiene relación con el sistema dando respuesta al usuario.

 REQUERIMIENTOS NO FUNCIONALES

a) Estos requerimientos se basan en las restricciones de los servicios o funciones ofrecidos por el sistema.

b) Los Requerimientos funcionales son los requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.

c) Los dos tipos de requerimientos especificados son de gran importancia para el desarrollo de una aplicación en software, por lo tanto siempre deben ser escritos con claridad, contener la mayor especificación de las necesidades expuestas por el cliente, esto con el fin de tener un soporte base desde el cual se trabajaran y no presentar ambigüedades en la definición y el resultado del producto.

PREPARAR PLAN DE REVISIÓN:En la preparación del plan de reunión se deben planear quienes deben asistir, que se va a hablar y cuánto tiempo se va a demorar.

 PREPARAR REUNIÓN:

Se debe confirmar el lugar en el cual realizará la reunión y se deben prepara       los materiales necesarios para la reunión (lápices, hojas, elementos visuales… etc).

REALIZAR REUNIÓN:

Se revisa el entendimiento de la especificación por parte de los interesados y se valida que lo especificado si cumple con la necesidad del cliente y con lo solicitado.

  IDENTIFICAR DE DEFECTOS DE LA ESPECIFICACIÓN:

Si revisa si se encuentran defectos con respecto a lo solicitado o si hace falta alguna especificación requerida.

REALIZACIÓN DE CORRECCIONES A LOS DOCUMENTOS:

Si en la etapa anterior se encuentran defectos en la especificación el analista del sistema debe realizan las debidas correcciones al documento.

 INFORMAR MODIFICACIONES A LOS INTERESADOS:

Una vez los defectos en la especificación han sido subsanados, se debe enviar un breve resumen informando las tareas realizadas para la corrección de los documentos especificados junto con los documentos corregidos a los participantes en la reunión para dar su aprobación

CIERRE DE LOS REQUERIMIENTOS:

Por último se da por cerrado y entendido la el requerimiento se firma la aprobación por parte de los interesados y se procede a enviarse un correo con la aprobación del requerimiento.

Capítulo 4 TÉCNICAS PARA DEFINIR REQUISITOS

Para obtener los requisitos del cliente se pueden emplear varias técnicas. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos.

DEFINICIÓN DE DIAGRAMAS

De manera general se recomienda el uso de los diagramas UML, pero cuándo utilizar diagramas UML? y cuándo no hacerlo?.

Veamos de manera didáctica cuándo utilizar y  no utilizar los diagramas UML

Cuando no Utilizar Diagramas

o No dibujar diagramas porque el proceso te lo diceo 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.

o Dibujar diagramas para que otra persona codifique

Cuando Utilizar los Diagramas

o 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

o 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

o Cuando quieras jugar con una idea de diseño, y los diagramas pueden ayudarte a entenderlo. Detente cuando hayas conseguido finalizar el punto que querías codificar

o Cuando necesites exponer una estructura de alguna parte del código a alguien más o a ti mismo.

Los diagramas que se utilizan son los siguientes:

 De estados: 

Estos diagramas nos muestra los diferentes estados de un objeto durante su vida.   

   De secuencia:

Estos nos muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado.Los diagramas de secuencia ponen especial énfasis en el    orden y el momento en que se envían los mensajes a los objetos.

   De caso de uso:

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso. Los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.

DEFINICIÓN DE CASOS DE USO

La identificación de actores: 

Esto nos permite categorizar los diferentes grupos de actores, es decir identificar características comunes de los actores que intervienen en el sistema, en esta identificación de actores debemos tener en cuenta que dichos actores pueden llegar a ser un usuario, un humano u otro sistema o dispositivo de hardware, también debemos hacernos las siguientes preguntas:

o  Quién o qué inicia eventos con el sistema?o Quién proveerá, usará o quitará información?o Quién usará esta funcionalidad?o Quién está interesado en cierto requerimiento?o En que parte de la organización será usado el sistema?o Quién dará soporte y mantendrá el sistema?o Cuales son los recursos externos del sistema?o Qué otros sistemas necesitarán interactuar con este sistema?

Intereses de los actores:

       

La identificación de estos intereses nos permite priorizar desarrollo de los casos de uso, planificar mejor las interacciones y reconocer cuales son los usuarios con los que debemos levantar los casos de uso.

La identificación de eventos y escenarios que este podría llegar a tener:

La identificación de eventos y escenarios es necesaria para poder determinar cuál es la interacción entre el sistema y los actores, que puede ser descrito mediante una secuencia de mensajes, es una descripción narrativa de lo que la gente hace al intentar utilizar la aplicación.

Especificación de Casos de uso

Los casos de uso deben ser relatos secuenciales que especifiquen una funcionalidad determinada del sistema que se desea desarrollar, así que debe describir como inicia y termina el caso de uso, que datos se intercambian entre el actor y el caso de uso, el flujo de eventos, no solo la funcionalidad, para reforzar esto debe comenzar cada acción con la frase “El actor...”, describir solo los eventos que pertenecen a ese caso de uso, y no lo que pasa en otros casos de uso o fuera del sistema.

De la misma manera se debe tener especial cuidado de no utilizar los siguientes detalles:

o No describir detalles de la interfaz del usuario, a menos que sea necesario para entender el comportamiento del sistema.

o  Evitar terminología vaga tal como “por ejemplo” “etc” “información”.o Evite dejar en el texto del caso de uso ambigüedades o preguntas que

se debieron resolver en el levantamiento de información.

Los casos de uso deben contar con los siguientes elementos

o El conjunto de todos los casos de uso, debe cubrir los requerimientos del sistema en su totalidad.

o Se pueden definir casos de uso en diferentes niveles.o A nivel de sistema de Negocioo A nivel de sistema de Software 

o Las descripciones de los casos de uso son cruciales para la comprensión del sistema.

o Debe  contar con Pre y Post Condiciones, una  Pre-Condición es una restricción sobre cuando un caso de uso puede empezar. que necesita

para poder ser ejecutado, la Post-Condición para un caso de uso debe ser verdadera, independientemente de cual flujo sea ejecutado. Si algo puede fallar, debería cubrirse en la post condición diciendo: “La acción se ha completado o si algo ha fallado, la acción no se ha realizado”, en lugar de decir “La  acción se ha completado”.

PrototiposLos prototipos son modelos a escala o facsímil de lo real, pero no tan funcional para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final.

Características de un prototipo

o El prototipo es una aplicación que puede no funcionar(conjunto de dibujos por ejemplo, una presentación de escenarios) o que puede funcionar (conjunto de pantallas que proporcionan un modelo dinámico).

o Los prototipos se crean con rapidezo Los prototipos evolucionan a través de un proceso iterativo.o Los prototipos tiene un costo bajo desarrollo.

Definición de criterios de aceptación

Estos criterios nos permiten asegurar que los requisitos satisfacen la funcionalidad requerida y al mismo tiempo que el producto es de calidad, nos ayuda a obtener un nivel de aceptación realista tanto para el cliente como la empresa que los desarrolla.

para la definición de criterios de aceptación se presenta el siguiente modelo:

o Se debe encontrar el documento de requisito terminado, revisado y aprobado por las diferentes partes, implicadas.

o El requisito no debe tener escenarios ambiguoso El requisito debe hacer que dice el documento de especificación ni mas,

ni menos y cumplir con todos los escenarios.o El requisito debe ser medible, es fácil identificar si cumple o no cumple.o No existe contraindicaciones con otros requisitos

o El requisito debe haber sido probado y aceptado por este proceso.o Se debe entregar el requisito dentro de las fechas establecidas.o El requisito aparte de cumplir con los anteriores pasos, puede haber

otros criterios que el cliente solicite.

Capítulo 5 PRUEBAS DE REQUERIMIENTOS

En este capítulo quiere decir que su objetivo de las pruebas es verificar y buscar los requerimientos y el desarrollo de un software.

Planeaciones Esta se basa en en los alcances y limitaciones que hay de la prueba, estrategia para luego utilizarla en la ejecución de la prueba.

Los siguientes pasos para realizar la prueba es:

-Documentación.-Recurso humano.-Recurso tecnológico.

 Diseño de casos de pruebaen este diseño se define el checkilts con las características a evaluar de los requerimientos.

EJECUCIÓN DE CASOS DE UNA PRUEBAEn esta fase se evalúa cada uno de los de requerimientos de acuerdo con el checklist definidos como casos de prueba:

-Conciso-Contraposición-Ambigüedad-Completitud, etc…

En estas se reportaran las condiciones sugerencias

Para hacer aclaraciones y definir si las consideraciones planteadas van a ser solucionadas o si el requerimiento es correcto.

CierreAquí en el cierre donde ya se haya completado la ejecución con los resultados satisfactorios y los ajustes correspondientes se realiza el cierre de la prueba donde se dará el visto bueno sobre los requisitos que serán evaluados.

Formato Objetivo

MR_005.1_Planeación Prueba de

requerimiento

Presentar la estrategia, alcance,

estimación de tiempos, de la prueba de

requerimiento.

MR_005.2_Diseño de Casos de Prueba Identificar los posibles casos de prueba

del requerimiento

MR_005.3_Ejecucion de Casos de Prueba Presentar resultado de ejecución de los

casos

MR_005.4_Informe final prueba Presentar informe de cierre con los

aspectos más relevantes de la ejecución

 

Capítulo 6 GESTIÓN DE CAMBIOS en este capitulo quiere decir que la planificación coordinada debe ser un proyecto de las actividades que conlleve el logro los objetivos o propósitos claras y eficientes.

Identificación control de cambios.

Las organizaciones de desarrollo de software, se identifican las siguientes actividades.

Análisis de la solicitud: 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

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

La solicitud para saber que tanto impacta la modificación e identificar puntualmente las modificaciones solicitadas que afectan el requerimiento.

Documentar cambio

 Este punto apoya también a tener un control de las modificaciones que se realizan sobre un documento de requerimiento esto con el fin de mantener informado al grupo de trabajo y al cliente que actualizaciones se han realizado sobre los documentos.

Aprobación control de cambio

Aprobar cambios

Se debe tomar una decisión. Si se acepta el cambio, tras negociarlo con el cliente se continuará con la actividad de implementar cambio sino se deberá negociar con el cliente el siguiente paso a realizar.

Planear cambio

Una aprobación formal del cambio aceptado planea al tiempo necesario.

Realizar cambio

El cambio aceptado se debe realizar las modificaciones necesarias a todos los productos que resulten afectados.

Revisar cambio

Hacer una verificación por parte del líder para identificar que el requerimiento incluye todos los cambios solicitados.

Actualizar line base

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

Informar

La modificación de la solicitud se debe a los interesados que el cambio y se está realizando para que el cliente lo verifique.

Entregable control de cambios

Los puntos anteriores es importante utilizar el documento que apoye a la identificación de la solicitud realizada por los clientes internos o externos.

Formato Objetivo

MR_006_Control de cambios Describir la situación de cambio solicitada por

el cliente.

Capítulo 7 GESTIÓN DE REQUERIMIENTO

Para que la gestión de los requerimientos sea realmente aplicable al cliente en pro de la satisfacción de las necesidades y control del proyecto general, se debe cumplir con las siguientes acciones.

Matriz de relación de documentosLa siguiente matriz nos muestra cuales son las relaciones de documentación de cada requisito.

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

la siguiente matriz es a que nos permite valorar si el requisito cumple con todas las etapas llevadas a cabo en la metodología.

Matriz de Control de cambios

La matriz de control de cambios nos permite registrar los controles de cambio que se van presentando, en esta matriz podemos registrar el número de control de cambio que se tiene asignado.