SlideShare ist ein Scribd-Unternehmen logo
1 von 4
PASO 1: Descripción del problema. URD.
Se genera automáticamente:
1. ID
2. Quien carga la URD (De acuerdo al nombre de usuario en una Base de Datos Regional)
3. Planta
4. Fecha del pedido
5. Deberá definir si se trata de una:
•    Modificación (es un cambio propuesto en una aplicación existente)
•    Nuevo desarrollo (es una nueva aplicación que debería cubrir alguna necesidad)

Modificación:                                                Desarrollo
•   Nombre del sistema                                       •   Nombre propuesto del sistema.
•   Prioridad: Urgente, Normal o baja. (En cada caso se      •   Prioridad: Urgente, Normal o baja. (En cada caso se
    deberá definir a través de intervalos la cantidad de         deberá definir a través de intervalos la cantidad de
    tiempo en cada nivel de prioridad).                          tiempo en cada nivel de prioridad).
•   Descripción de la modificación a través de texto         •   Descripciones y funciones globales del sistema.
    descriptivo y fotos de las ventanas de la aplicación a   •   Detallar paso a paso:
    modificar.                                                    –    Origen de los datos que va a utilizar el sistema.
                                                                  –    Describir cual es el proceso que se debe realizar con las datos del
•   Las razones de la modificación. Debe describir el                  paso anterior
    problema que se solucionaría.                                 –    El objetivo final que se debería reflejar del proceso anterior.
                                                                       (reportes, gráficos, envío de email, generación de impresiones,
•   Determinar los beneficios económicos que generará                  etc.)
    la modificación. Ya sean monetarios o en eficiencia      •   Nivel de permisos:
    a la hora de utilizar los recursos de la compañía.            –    Si va a tener 1 o mas usuarios administradores. (Estos tendrían la
                                                                       posibilidad de cambiar datos, dar permisos a otros usuarios, etc.)
                                                                  –    Nivel de usuarios normales (Por ej: cargar y ver datos)
                                                                  –    Solo visitantes
                                                             •   Las razones de la modificación. Debe describir el
                                                                 problema que se solucionaría.
                                                             •   Determinar los beneficios económicos que generará
                                                                 la modificación. Ya sean monetarios o en eficiencia
                                                                 a la hora de utilizar los recursos de la compañía.
PASO 1: Descripción del problema. URD.

Luego de que se completo el formulario correctamente:

•   Se confirmaría la creación de la URD a través de un mail al usuario que la cargo.
•   Se generaría un nuevo registro en la Base de datos del LA Team donde figuren todo lo
    cargado por el usuario pero con el status del mismo en “Evaluación”
•   Se elevaría la URD a los lideres de la región para ser evaluada.
PASO 2: Evaluación de la URD.

•   El grupo evaluador encargado, definirá si la URD será aprobada, de acuerdo a:
     •   Las políticas de la compañía.
     •   La existencia de una nueva versión regional del sistema.
     •   Otras.
•   En caso de NO ser aprobada, se le envía un mail al usuario detallándole las razones del
    rechazo. Al mismo tiempo el status en el sistema del LA Team pasa a “Rechazado”.
•   En caso de SI ser aprobada, se envía la URD al LA Team para ser tratada y el status cambia a
    “Aprobada”.
PASO 3: Descripción del problema. URD.

En el LA Team, se debe:

1.   Definir a grandes rasgos lo que se debe hacer y como. De esta forma, el objetivo seria generar un
     checklist, que puede ser dinámico (para agregar y quitar elementos de la lista), que definan los pasos a
     realizar para llevar a cabo el requerimiento.
2.   Luego, se deberá definir quien/quienes pueden llevar a cabo la tarea dependiendo de:
      •    La carga horaria laboral ocupada.
      •    Matriz de habilidades en programación.
      •    Experiencia relacionada a la actividad del sistema.
      •    Etc.
           El responsable definido y su grupo de apoyo también deben ser cargados en el registro del sistema
           del LA Team.
3.   Definir el tiempo estimado en que será entregada la tarea. También debe ser reflejado en el sistema.
4.   Una vez terminada la tarea, se deberá informar al usuario a través de un mail que la tarea ya fue termina.
     Al mismo tiempo el status cambia a “Terminado”. Por otro lado se pueden hacer cálculos de eficiencia
     dependiendo de los valores cargados en la base de dato del sistema LA Team.

Weitere ähnliche Inhalte

Ähnlich wie Formulario urd

Arnold Gutierrez | Requerimientos & Trazabilidad
Arnold Gutierrez | Requerimientos & TrazabilidadArnold Gutierrez | Requerimientos & Trazabilidad
Arnold Gutierrez | Requerimientos & TrazabilidadArnold Gutierrez
 
Opciones en la adquisición de sistemas de información
Opciones en la adquisición de sistemas de información Opciones en la adquisición de sistemas de información
Opciones en la adquisición de sistemas de información VALENTINAESPINOSAUPE
 
Qué es un proyecto
Qué es un proyectoQué es un proyecto
Qué es un proyectoleomar02
 
Requerimientosdfsdsvsvsvfsfvfvfsfvsfvsvfv
RequerimientosdfsdsvsvsvfsfvfvfsfvsfvsvfvRequerimientosdfsdsvsvsvfsfvfvfsfvsfvsvfv
RequerimientosdfsdsvsvsvfsfvfvfsfvsfvsvfvLuis Caballero
 
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfTema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfNinoskaChuraLlojlla1
 
Ciclo de vida de un Software.pptx
Ciclo de vida de un Software.pptxCiclo de vida de un Software.pptx
Ciclo de vida de un Software.pptxPabloRiquelme42
 
10 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].610 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].6Julio Pari
 
10 Clase Captura De Los Requisitos Cap.6
10 Clase Captura De Los Requisitos  Cap.610 Clase Captura De Los Requisitos  Cap.6
10 Clase Captura De Los Requisitos Cap.6Julio Pari
 
ACTIVIDAD FINAL INTRODUCCION SISTEMAS DE INFORMACION (1) (2).pdf
ACTIVIDAD FINAL INTRODUCCION SISTEMAS DE INFORMACION (1) (2).pdfACTIVIDAD FINAL INTRODUCCION SISTEMAS DE INFORMACION (1) (2).pdf
ACTIVIDAD FINAL INTRODUCCION SISTEMAS DE INFORMACION (1) (2).pdfJordan Turizo oñoro
 
Revisión de conceptos básicos clase IR
Revisión de conceptos básicos clase IRRevisión de conceptos básicos clase IR
Revisión de conceptos básicos clase IRYAMILA GASCON
 

Ähnlich wie Formulario urd (20)

Arnold Gutierrez | Requerimientos & Trazabilidad
Arnold Gutierrez | Requerimientos & TrazabilidadArnold Gutierrez | Requerimientos & Trazabilidad
Arnold Gutierrez | Requerimientos & Trazabilidad
 
Ejemplo FDD
Ejemplo FDDEjemplo FDD
Ejemplo FDD
 
Tipos de requerimeintos
Tipos de requerimeintosTipos de requerimeintos
Tipos de requerimeintos
 
Expo escenarios requerimientos sw
Expo escenarios requerimientos swExpo escenarios requerimientos sw
Expo escenarios requerimientos sw
 
Opciones en la adquisición de sistemas de información
Opciones en la adquisición de sistemas de información Opciones en la adquisición de sistemas de información
Opciones en la adquisición de sistemas de información
 
Ejemplo de fdd
Ejemplo de fddEjemplo de fdd
Ejemplo de fdd
 
Qué es un proyecto
Qué es un proyectoQué es un proyecto
Qué es un proyecto
 
APLICACIONES N-CAPAS EN VISUAL NET
APLICACIONES N-CAPAS EN VISUAL NETAPLICACIONES N-CAPAS EN VISUAL NET
APLICACIONES N-CAPAS EN VISUAL NET
 
Requerimientosdfsdsvsvsvfsfvfvfsfvsfvsvfv
RequerimientosdfsdsvsvsvfsfvfvfsfvsfvsvfvRequerimientosdfsdsvsvsvfsfvfvfsfvsfvsvfv
Requerimientosdfsdsvsvsvfsfvfvfsfvsfvsvfv
 
01.introduccion
01.introduccion01.introduccion
01.introduccion
 
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfTema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
 
Ciclo de vida de un Software.pptx
Ciclo de vida de un Software.pptxCiclo de vida de un Software.pptx
Ciclo de vida de un Software.pptx
 
10 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].610 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].6
 
10 Clase Captura De Los Requisitos Cap.6
10 Clase Captura De Los Requisitos  Cap.610 Clase Captura De Los Requisitos  Cap.6
10 Clase Captura De Los Requisitos Cap.6
 
Taller en clases
Taller en clases Taller en clases
Taller en clases
 
Taller en clases
Taller en clases Taller en clases
Taller en clases
 
ACTIVIDAD FINAL INTRODUCCION SISTEMAS DE INFORMACION (1) (2).pdf
ACTIVIDAD FINAL INTRODUCCION SISTEMAS DE INFORMACION (1) (2).pdfACTIVIDAD FINAL INTRODUCCION SISTEMAS DE INFORMACION (1) (2).pdf
ACTIVIDAD FINAL INTRODUCCION SISTEMAS DE INFORMACION (1) (2).pdf
 
02 captura de requisitos
02 captura de requisitos02 captura de requisitos
02 captura de requisitos
 
Revisión de conceptos básicos clase IR
Revisión de conceptos básicos clase IRRevisión de conceptos básicos clase IR
Revisión de conceptos básicos clase IR
 
Sitode
SitodeSitode
Sitode
 

Formulario urd

  • 1. PASO 1: Descripción del problema. URD. Se genera automáticamente: 1. ID 2. Quien carga la URD (De acuerdo al nombre de usuario en una Base de Datos Regional) 3. Planta 4. Fecha del pedido 5. Deberá definir si se trata de una: • Modificación (es un cambio propuesto en una aplicación existente) • Nuevo desarrollo (es una nueva aplicación que debería cubrir alguna necesidad) Modificación: Desarrollo • Nombre del sistema • Nombre propuesto del sistema. • Prioridad: Urgente, Normal o baja. (En cada caso se • Prioridad: Urgente, Normal o baja. (En cada caso se deberá definir a través de intervalos la cantidad de deberá definir a través de intervalos la cantidad de tiempo en cada nivel de prioridad). tiempo en cada nivel de prioridad). • Descripción de la modificación a través de texto • Descripciones y funciones globales del sistema. descriptivo y fotos de las ventanas de la aplicación a • Detallar paso a paso: modificar. – Origen de los datos que va a utilizar el sistema. – Describir cual es el proceso que se debe realizar con las datos del • Las razones de la modificación. Debe describir el paso anterior problema que se solucionaría. – El objetivo final que se debería reflejar del proceso anterior. (reportes, gráficos, envío de email, generación de impresiones, • Determinar los beneficios económicos que generará etc.) la modificación. Ya sean monetarios o en eficiencia • Nivel de permisos: a la hora de utilizar los recursos de la compañía. – Si va a tener 1 o mas usuarios administradores. (Estos tendrían la posibilidad de cambiar datos, dar permisos a otros usuarios, etc.) – Nivel de usuarios normales (Por ej: cargar y ver datos) – Solo visitantes • Las razones de la modificación. Debe describir el problema que se solucionaría. • Determinar los beneficios económicos que generará la modificación. Ya sean monetarios o en eficiencia a la hora de utilizar los recursos de la compañía.
  • 2. PASO 1: Descripción del problema. URD. Luego de que se completo el formulario correctamente: • Se confirmaría la creación de la URD a través de un mail al usuario que la cargo. • Se generaría un nuevo registro en la Base de datos del LA Team donde figuren todo lo cargado por el usuario pero con el status del mismo en “Evaluación” • Se elevaría la URD a los lideres de la región para ser evaluada.
  • 3. PASO 2: Evaluación de la URD. • El grupo evaluador encargado, definirá si la URD será aprobada, de acuerdo a: • Las políticas de la compañía. • La existencia de una nueva versión regional del sistema. • Otras. • En caso de NO ser aprobada, se le envía un mail al usuario detallándole las razones del rechazo. Al mismo tiempo el status en el sistema del LA Team pasa a “Rechazado”. • En caso de SI ser aprobada, se envía la URD al LA Team para ser tratada y el status cambia a “Aprobada”.
  • 4. PASO 3: Descripción del problema. URD. En el LA Team, se debe: 1. Definir a grandes rasgos lo que se debe hacer y como. De esta forma, el objetivo seria generar un checklist, que puede ser dinámico (para agregar y quitar elementos de la lista), que definan los pasos a realizar para llevar a cabo el requerimiento. 2. Luego, se deberá definir quien/quienes pueden llevar a cabo la tarea dependiendo de: • La carga horaria laboral ocupada. • Matriz de habilidades en programación. • Experiencia relacionada a la actividad del sistema. • Etc. El responsable definido y su grupo de apoyo también deben ser cargados en el registro del sistema del LA Team. 3. Definir el tiempo estimado en que será entregada la tarea. También debe ser reflejado en el sistema. 4. Una vez terminada la tarea, se deberá informar al usuario a través de un mail que la tarea ya fue termina. Al mismo tiempo el status cambia a “Terminado”. Por otro lado se pueden hacer cálculos de eficiencia dependiendo de los valores cargados en la base de dato del sistema LA Team.