4
Gestión de requerimientos: Generalidades Sistema Va a tener un módulo habilitado de consulta (tipo mapa) de las aplicaciones y sus conexiones con el resto (Interfaces). Después se pueden poder in cargando a nivel datos. Esto lo pueden consultar Testeo y Desarrollo. Después normas desde su perfil va a poder acceder también. Los encargados de completar esto van a ser los de sistemas. Va a ser progresivo. A medida que se vayan ingresando requerimientos ellos van cargando las distintas interfaces que van desarrollando. Los sistemas etc… Ellos tiene la responsabilidad de mantener esté mapa de sistemas y solo ellos lo pueden modificar. Generalidades Requerimientos En todos los casos los usuarios deben tener la posibilidad de delegar sus tareas a otro usuario, de acuerdo a la estructura de testeo área. Forma en que se puede agregar la reunión. Cuando el estado cambia a “Demorado o Consenso Interno”. Se pregunta si hay una reunión Pactada y un campo de Lugar, Fecha, hora. Cuando se registra una modificación del requerimiento las autorizaciones se reinicializan, comenzando desde cero. Asegurándose que todas las área están de acuerdo (límite de tiempo para la respuesta.) Los requerimientos se pueden linkear unos con otro y se debe aclara si el desarrollo se debe hacer antes del ya cargado, en paralelo o después. De acuerdo a la dependencia se modifican las fechas. Además se pueden agrupar en proyectos. - Requirentes Usuarios: o Tienen acceso a ingresar un req.

Gestión de Requerimientos

Embed Size (px)

DESCRIPTION

Gestión de Requerimientos

Citation preview

Gestin de requerimientos:Generalidades SistemaVa a tener un mdulo habilitado de consulta (tipo mapa) de las aplicaciones y sus conexiones con el resto (Interfaces). Despus se pueden poder in cargando a nivel datos. Esto lo pueden consultar Testeo y Desarrollo. Despus normas desde su perfil va a poder acceder tambin.Los encargados de completar esto van a ser los de sistemas. Va a ser progresivo. A medida que se vayan ingresando requerimientos ellos van cargando las distintas interfaces que van desarrollando. Los sistemas etc Ellos tiene la responsabilidad de mantener est mapa de sistemas y solo ellos lo pueden modificar.Generalidades RequerimientosEn todos los casos los usuarios deben tener la posibilidad de delegar sus tareas a otro usuario, de acuerdo a la estructura de testeo rea.Forma en que se puede agregar la reunin. Cuando el estado cambia a Demorado o Consenso Interno. Se pregunta si hay una reunin Pactada y un campo de Lugar, Fecha, hora.Cuando se registra una modificacin del requerimiento las autorizaciones se reinicializan, comenzando desde cero. Asegurndose que todas las rea estn de acuerdo (lmite de tiempo para la respuesta.)Los requerimientos se pueden linkear unos con otro y se debe aclara si el desarrollo se debe hacer antes del ya cargado, en paralelo o despus. De acuerdo a la dependencia se modifican las fechas.Adems se pueden agrupar en proyectos. Requirentes Usuarios: Tienen acceso a ingresar un req. El formulario de ingreso a requerimiento tiene que ser tipo cuestionario. Muy fcil de acuerdo a las opciones que se van tildando En la pantalla de ingreso tienen grfico Torta o barra, que les muestra el estado general de sus requerimientos. Debajo de esta e recuadro de novedades que dividido en, Finalizados, rechazados y derivaciones (se aprob el consenso y pasa a test) Tiene solapa con requerimientos pendientes: tabla con todos los req. que no se hayan finalizado (Rechazados o Aprobados) Tiene solapa con requerimientos rechazados: tabla con todos los req. Rechazados en los ltimos dos meses. Los requerimientos pueden ser modificados slo cuando se encuentran en borrador o cuando le es devuelto para su modificacin. Los Gerentes o Autorizantes pueden modificar las reas a las que se le consulta previo a testeo? Aprobado con modificaciones y le notifica al que ingreso el req q su formulario fue aprobado y las modificaciones q se le hicieron. Solapa de observados. Pueden poner alerta de seguimiento! Para que se le envi un mail por cada cambio en especial del req. Tiene que estar la posibilidad de que ingresen una a alerta general antes cualquier modificacin importante envar correo. Las alertas son definidas por Testeo. Se pueden activar esas.

Analistas de Testeo para el anlisis del req. Usuarios: Buzn de entrada Estados del req. Para informar correctamente el estado, si se pacta una reunin, cualquier involucrado del mismo podr acceder y ver que el estado es en consenso, reunin pactada para el dd/mm/yyyy Pueden insertar fechas lmites para que se realice el consenso, de acuerdo a la magnitud del proyecto. Ver si dentro de este plazo es la primer vuelta de correo, en cuento se registre una devolucin, el sistema detiene la alerta. Actualiza estado del req. Devuelto con observaciones (y se ingresa a la observacin y del rea de donde se ingreso.) Las respuestas del consenso por parte del analista del req. Del testeo, le llegan al analista, el usuario inicial solo puede el estado en q se encuentra En consenso. Los tipos de estados se son distintos de acuerdo al perfil. El supervisor de testeo pueden reasignar las tareas de todos los analistas. Y puede gestionar los reqs. Envindolos a consenso y devolvindolos, lo mismo q el analista. Los analistas y los testeadores, van a tener dos perfiles Analista y Tester. De acuerdo al puesto se le dan los dos pero slo se puede acceder uno a la vez. Como Prima!!! El lder de Testeo le debe asignar la tarea a un desarrollador y de acuerdo a los temas que tenga asignados les debe poner una prioridad del tema, para que el mismo sepa si lo tiene q empezar a gestionar ya o no. Si el requeriemitno es Urgente, debe advertirlo al desarrollador o l lder y el motivo. Ver si se le pueden asignar pre prioridades, por ej: si el sistema no puede funcionar o hay un error en una poliza es mas urgente que una mejora.

Desarrollo Deben cargar si o si los sistemas en los que impacta el requerimiento. Especificar a que nivel se ve afectado: Interface (Tablas) Base de datos Aplicacin En todos los cosas, si no se encuentra cargado el sistema o la interface o la BD, etc lo puede agregar. YA se la conexin o el mdulo propiamente dicho.A partir de esta se le puede advertir al desarrollador que hay req activos que impactan en los mismos sistemas, interface, bd, etc. Registrar el anlisis del impacto de acuerdo a los sistemas en que impacta. (se puede poner un nivel de relevancia a cada sistema!) Tiempo, no costos para no herir susceptibilidades. Puede pedir aclaraciones respecto del requerimiento. En caso en que en el desarrollo del req. Intervenga una consultora lo debe poner. Como as tambin debe poder cargar las demoras y los motivos de las demoras. (Estadstica de resoluciones con intervencin de consultoras.) El lder de Desarrollo le debe asignar la tarea a un desarrollador y de acuerdo a los temas que tenga asignados les debe poner una prioridad del tema, para que el mismo sepa si lo tiene q empezar a gestionar ya o no. Preguntar a Gabriel si quiere poner ms!

Tester Buzon de tareas asigandas. Generacin de casos de prueba. Estimacin de tiempo. Derivacin al usuarios final para aprobacin Reporte de bugs al desarrollador. Tipo, bloqueante o no, etc. Los bugs estn asociados a los requerimientos. Derivacin al carrito de implementacin o mail de acuerdo al proceso que se haga. Oracle no tiene carrito.