metodojarri

177 visualizaciones

Publicado el

tabajo

Publicado en: Educación
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
177
En SlideShare
0
De insertados
0
Número de insertados
4
Acciones
Compartido
0
Descargas
1
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

metodojarri

  1. 1. METODOLOGIA GESTION DE REQUERIMIENTOS ENSAYO CAP. 1 -7 Jhon jarrinson cuellar lozada JUAN CAMILO GOMEZ JOVEL TECNOLOGO ANALISIS Y SISTEMAS DE DESARROLLO DE INFORMACION CENTRO AGROEMPRESARIAL Y DESARROLLO PECUARIO DEL HUILA SENA GARZON-HUILA
  2. 2. Objetivos Analizar los requerimientos que se necesitan para conocer las necesidades y objetivos que el cliente o usuario necesita para poder desarrollar un sistema que cumpla con aquellas necesidades. Aprender a realizar una correcta documentación para que todo lo que se vaya a ir actualizando se tenga en modo de carpeta escrito.
  3. 3. METODOLGIA GESTION DE REQUERIMIENTOS Los requerimientos se enfocan a describir las necesidades del cliente, es decir que para recabarlos hay que tener una información que se obtiene mediante entrevistas, para que los costos del cliente no incrementen estos van evolucionando con el tiempo es bueno y necesario tener una copia de la documentación original del cliente. Para que este método que se utiliza sea efectivo es necesario seguir una secuencia que se desarrollan para la identificación de las necesidades del cliente: Obtener información del cliente 1. Definir el alcance 2. Identificar requerimientos funcionales y no funcionales 3. Realizar entregable de identificación de necesidades 4. Realizar entregable de identificación de necesidades La definición del alcance tiene como propósito definir las necesidades del cliente para esto es necesario tener en cuenta unos pasos: 1. Los entregables que hacen parte del alcance: para este se recomienda describir listar los entregables finales estos tiene que ser aprobados por el cliente, es bueno no mencionar documentos propios del proyecto por ejemplo un cronograma 2. Los tipos de datos que están en el alcance y fuera de el: estos se refieren al negocio de los entregables como datos financieros, de venta y de los empleados
  4. 4. 3. Las fuentes de datos (bases de datos) que están en el alcance y fuera de el: es parecido a los tipos de datos este lleva datos agregados (base de datos de cliente, contabilidad general, sistema de facturación y cobranza 4.Áreas involucradas en el alcance y fuera de él: a veces estas ayudan a las áreas involucradas en el proyecto delimitan el alcance 5. Condiciones fuera del alcance: es recomendable como un punto de claridad y contraste al describir entregables que no se han creados Las fuentes de información claves es bueno que cualquier información que se haya creado esta debe ser usada como una base para definir el alcance de una manera más detallada, cuando se obtienen objetivos del proyecto es recomendable tener esto en cuenta para definir el alcance, para cumplir cada uno de los objetivos es necesario crear uno o más entregables.
  5. 5. TECNICAS PARA IDENTIFICAR REQUERIMIENTOS En la actualidad existen aplicaciones de software, estas utilizan diferentes herramientas que ayudan a la identificación de los requerimientos. Las organizaciones actuales utilizan múltiples herramientas para la identificación de requerimientos sin saber si son los más convenientes Técnicas para la identificación de requerimientos estas técnicas nos permiten investigar aspectos generales para que luego sean específicos para tener un dialogo mucho más abierto es importante estas técnicas. La entrevista es muy utilizada para la recolección de información esta se hace a cabo mediante conversaciones estructuradas para esto es importante que el lugar sea tranquilo para que el cliente este en confianza. Antes de iniciar una entrevista hay que saber unos tips: Estudiar el tipo de personas a las cuales se les realizar la entrevista, estudiar el entorno donde se llevara a cabo la entrevista esto sirve para identificar los confortables que son los clientes, conocer la manera de hablar de la persona verificar que la persona tenga la disponibilidad de dar las necesidades para luego saber si se convierten en requerimientos, analizar como es la relación del cliente con la organización que posterior analizara los requerimientos, saber que es importante obtener la mayor información. La lluvia de ideas es abierta esta se utiliza para investigar nuevos servicios o necesidades que no son claramente identificadas es decir es necesario que todas las personas que hacen parte del equipo de apoyo hagan parte de la investigación. Los cuestionarios se puede dirigir al público en específico o en general con esto se puede tener una mayor información porque se pueden involucrar más personas para el desarrollo del cuestionario Técnicas específicas para la identificación de requerimientos están nos permiten completar las técnicas generales para obtener mayor información Observación esta técnica permite revisar que no existen omisiones o una interpretación errónea sobre el proceso esto se hace si el cliente lo permite.
  6. 6. Escenarios con esta técnica permite analizar el producto ante determinados eventos considerando los datos, acciones y excepciones que se pueden presentar. Los requerimientos de software se clasifican en funcionales y no funcionales. Los funcionales son declaraciones de los servicios que proveerá el sistema este hace cosas que el sistema no debe realizar Identificación de los requerimientos no funcionales es la declaración de uno o de los servicios que muestra el sistema de la manera en que este reaccionara a una entrada en particular, algunos de los problemas de software vienen desde la impresión en la especificación de requerimientos se habla con el cliente, se plantean nuevos requerimientos debido a este cambio obliga hacer unos cambios en los requerimientos tiene que cambiar el sistema este retrasa la entrega debido a esto se incrementa el costo. Una especificación de requerimientos funcionales no puede faltar por ningún motivo todo el proceso tiene que ser completo esto por supuesto tiene una consistencia y una compleción significa que los servicios que se hayan solicitado tienen que estar definidos y la consistencia es que los requerimientos no tiene definiciones contradictoria La identificación de los requerimientos no funcionales se refiere a las restricciones en el tiempo la capacidad de almacenamiento y las fiabilidades, estas surgen de las necesidades del usuario también es por el presupuesto, los requerimientos del producto estos dicen el comportamiento del producto como un requerimiento de desempeño en la ejecución del sistema y la memoria que necesita y los requerimientos organizables estos tienen un lenguaje de programación o un método de diseño a utilizar y los requerimientos de entrega especifican cuando es la entrega del producto y su documentación. La definición de requisitos para que esto sea un éxito los requerimientos deben ser claros y definidos es bueno realizar requerimientos revisando
  7. 7. proyectos qu8e se hayan finalizado porque en estos puede haber información que nos va a hacer muy útil pero debe estar clara y sin ningún error. Los requerimientos se clasifican en funcionales y no funcionales estos son de una gran importancia para poder desarrollar una aplicación de software por eso siempre tienen que estar escritos con claridad es bueno obtener la mayor información posible de las necesidades del cliente. Para una verificación de requisitos se deben añadir criterios de aceptación por cada requisito para lograr una tarea de la calidad es bueno asegurarse de que cada requisito cumple los criterios, la revisión de requisitos de especificación esto es cuando ya se han identificado los requerimientos documentados y verificados, luego se procede a hacer la revisión de los mismos con la información que se halla recolectado con los usuarios del sistema en la revisión participan los analistas y por supuesto los usuario que sean necesarios para hacer un proceso de preparación es necesario tener unos pasos hacer un plan de revisión en esta reunión se debe panear los que deben hablar de que se va hablar y el tiempo que se va a utilizar la documentación se debe especificar los documentos a revisar, prepara la reunión se debe prepara el lugar de encuentro los materiales, luego de esto se hace la reunión se revisa la especificación por parte de los interesados y obviamente se valida que lo especificado si se cumple identificar los defectos de la especificación se identifican los errores que tenga la especificación realización de correcciones a los documentos si en el paso anterior hay errores el analista del sistema debe hacer la correcciones respectivas al documento. técnicas para definir requisitos Para poder desarrollar un software se debe conocer los requisitos del cliente que se hace efectivo con ayuda de una entrevista que son métodos antiguos, los métodos que se usan ahora son los prototipos y los casos de uso.
  8. 8. En el mercado hay muchas herramientas que sirven para la especificación y descripción para facilitar el inicio del desarrollo del sistema lo más recomendable utilizar son los diagramas UML que no se utilizan cuando no se necesite o porque los va a codificar otra persona y se utilizan cuando se necesita que otras personas lo quieran entender porque lo van a estar trabajando a la misma vez, cuando dos personas tengan un conflicto por elementos que crean necesarios, cuando quieras hacerlo por diversión. Los diagramas más utilizados son: Los de estado que cosiste en mostrar los estados que pasa en la vida. De secuencia: estos muestran los intercambios de mensajes en un momento dado. De caso de uso: describen las relaciones que existen entre dos casos de uso. Para poder definir correctamente los casos de usos identificar y categorizar los diferentes grupos de actores se debe tener en cuenta que dichos actores pueden llegar a ser usuarios los intereses de los actores que nos permite desarrollo de los casos de usos y la identificación de los escenarios para poder saber cuál va a ser la interacción que va a tener con los actores. Los casos de uso deben ser una secuencia de relatos que especifique su funcionalidad los intercambios entre los casos de uso y los actores y se debe evitar describir detalles de la interfaz evitar el uso de términos como por ejemplo entre otras y el uso de ambigüedades o preguntas que ya deberían estar resueltas y debe contra con unas características como el caso de uso debe cumplir con todos los requerimientos se puede definir en dos niveles uno de sistema y otro de negocio. Los prototipos son funcionales pero no llega a equivaler al producto final ya que no lleva a cabo todas las funciones necesarios es importante definir un objetivo ya que puede ser muy útiles las fases del proyecto, esta puede que funcione como no puede funcionar, son más rápidos de hacer, tienen bajos costos.
  9. 9. Los criterios nos permiten saber si se cumplieron con los requisitos necesarios y si el sistema es de alto nivel puede tener gran aceptación por los clientes y las empresas. PRUEBAS DE REQUERIMIENTOS Se parte desde lo anterior para que los productos desarrollados su metodología sea correcta se debe estimar el tiempo que se requiera y el alcance que va tener este como tal verificación del requerimiento evaluación de los requisitos visto bueno para la aprobación. La planeación define el alcance y las limitaciones que tiene, la estrategia que tiene para la ejecución de esta pruébalos requerimientos para poder realizar las pruebas. Los casos de prueba debe tener un diseño para que funcionen, deben ser completo todos los ítems deben estar no debe faltar ninguno, correcto no debe tener errores, preciso no ambiguo y claro, consistente ningún ítem debe entrar en conflicto con otro, manejable que se pueda cambiar sin afectar los otros ítems. En la ejecución de los casos de prueba se debe evaluar cada uno de los requerimientos y se deben reportarlos errores y sugerencias y se deben realizar reuniones para hacer aclaraciones y definir si las conclusiones planteadas deben estar solucionadas. En el cierre se dará el visto bueno una vez que se haya completado la ejecución con resultados satisfactorios. GESTIÓN DE CAMBIOS Para que haya una comunicación clara y efectiva se debe hacer una planificación para desarrollarse los objetivos y propósitos para poderse llevar a cabo la gestión de cambios se necesita el siguiente proceso:
  10. 10. Para poder realizar una correcta identificación de los controles de cambios se requieren los siguientes pasos: Análisis de la solicitud se hace cuando se recibe la solicitud por el cliente ya sea externo o interno y debe ser recibida por el líder para que este la analice y es importante analizar el alcance y el tiempo para saber si la solicitud es viable o de lo contrario manejarlo con un requerimiento ya que con este análisis se puede identificar el impacto que va a tener.
  11. 11. Además se debe valorar la factibilidad de la solicitud del cliente ya sea interno o externo donde se define si le afecta el cambio y la trazabilidad y el líder debe analizar si los cambios afectan a los requerimientos y que tantos requerimientos afecta este. Para que no haya complicaciones en las modificaciones de los requerimientos es recomendable que tenga una documentación clara para que no haya ambigüedades y ayuda a tener control y para informar sobre las modificaciones que se hagan. Una vez analizado el cambio se puede negociar con el cliente si es aceptable la continuación de lo contrario los pasos a seguir después de tener aprobación s `planea el tiempo y los recursos necesarios para este, y una vez aprobado el cambio se terminan de hacer las modificaciones y después verificar por parte del líder si se cumple con los cambios en los requerimientos y trabajar con el ultimo línea de base para siempre trabajar con la última versión y una vez realizado el cambio se debe informar a los interesados. Una vez terminado el documento este no debe ser ambiguo y debe ser validada por los clientes y empresas. GESTIÓN DE REQUERIMIENTO Para que el sistema sea factible por el cliente que cumpla con sus necesidades debe cumplir con las siguientes acciones: Matriz de relación de documento es que el que nos muestra la relación de la documentación y la clasificación si es un negocio, usuario o sistema si sirve o
  12. 12. no y las peticiones quejas o sugerencias. Matriz de valoración es la que nos muestra si los criterios exigidos se cumplieron si en este caso si se cierra y se aprueba el requisito, y el encargado de revisar deberá dar un chequeo si la documentación es correcta y deberá dar un dictamen correcto si esta en verde es porque se cumplió el requisito correctamente y si esta en rojo es porque el criterio no cumple correctamente con la aceptación y si se muestra en amarrillo es porque no
  13. 13. tiene ningún problema. Matriz de control de cambios nos permite registrar los cambios que se van realizando se puede registrar el número de control de cambio que se le hizo y quien lo reviso en caso de que ya lo haya revisado su porcentaje de ejecución
  14. 14. hasta llegar al 100%, los requisitos afectados entre otras.
  15. 15. Conclusiones Que más tipos de diagramas existen con este mismo proceso? Si los prototipos son más rápidos y con menos costos porque no son tan funcionales? Si el sistema no está concreto falla a quien le va a ocasionar costos al creador del sistema o al usuario? Si no se hace una planeación adecuada puede fallar el sistema?
  16. 16. Bibliografía https://sites.google.com/site/metodologiareq/capit ulo-i

×