MINISTERIO DE TRABAJO Y PROMOCIÓN DEL EMPLEO ...

MINISTERIO DE TRABAJO Y PROMOCIÓN DEL EMPLEO

PROGRAMA TRABAJA PERÚ

Documento de Estándares para el Proceso de Desarrollo de Software


Página 2 de 6

TABLA DE CONTENIDOS

1 INTRODUCCIÓN ............................................................................................................................ 3

2 ALCANCE ...................................................................................................................................... 3

3 EL PROCESO UNIFICADO RATIONAL ....................................................................................... 3

4 FLUJO DE PROCESOS ................................................................................................................. 3

4.1 Fase 1: Inicio .......................................................................................................................... 3 4.2 Fase 2: Elaboración ............................................................................................................... 4 4.3 Fase 3: Construcción ............................................................................................................. 4 4.4 Fase 4: Transición .................................................................................................................. 5

5 AMBITO DE APLICACIÓN ............................................................................................................ 5

5.1 Nuevos desarrollos de sistemas informáticos ........................................................................ 5 5.2 Mantenimientos y excepciones .............................................................................................. 6

6 HERRAMIENTAS RECOMENDADAS........................................................................................... 6


Página 3 de 6

11 IINNTTRROODDUUCCCCIIÓÓNN El desarrollo orientado a objetos y su propuesta de abstracción teniendo al marco de trabajo (framwork) .NET, como estándar del Programa Trabaja Perú, necesita un soporte metodológico que ordene de manera lógica todos los artefactos o documentos propuestos por la metodología RUP, la cual sirve de base para la presente metodología de desarrollo de software. Es por ello que mediante la metodología propuesta, se busca estandarizar la documentación a utilizar en el proceso de desarrollo del software para los productos de la Unidad de Sistemas del Programa Trabaja Perú. Ello permitirá garantizar la documentación formal y posterior mantenimiento de los productos de software y su correcto proceso de desarrollo basado en la metodología RUP.

22 AALLCCAANNCCEE El presente documento, de estándares de artefactos basados en la metodología RUP para el proceso de desarrollo de software, abarca las disciplinas de Modelado del Negocio, Requerimientos, Análisis y Diseño, Implementación, Pruebas y Despliegue.

33 EELL PPRROOCCEESSOO UUNNIIFFIICCAADDOO RRAATTIIOONNAALL El Proceso Unificado de Rational (RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos. RUP permite adaptar el proceso, balancear prioridades, colaboración entre equipos y demostrar valor iterativamente. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto. Permite también elevar el nivel de abstracción, actualmente este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Esto previene a los ingenieros de software ir directamente de los requisitos a la codificación de software a la medida del cliente. Un nivel alto de abstracción también permite discusiones sobre diversos niveles arquitectónicos, los cuales se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo mediante diagramas UML.

44 FFLLUUJJOO DDEE PPRROOCCEESSOOSS La organización de RUP en flujos de trabajo y actividades, junto a los ‘artefactos’ que produce, se acopla a la estructura en Fases, Actividades y Entregables que suele proponerse como plan secuenciado del desarrollo, por ejemplo en las especificaciones de un concurso de una Administración Pública (secuenciación que facilita la comprensión por el cliente).

4.1 Fase 1: Inicio

Fase Objetivos Hito

Inicio Establecer el alcance y fronteras del software en el proyecto, incluyendo la visión operacional, criterio de aceptación, qué se espera que esté en el producto y qué no.

Discriminar los casos de uso críticos del sistema, los escenarios primarios de operación que dirigirán las principales decisiones de diseño.

Estimar los riesgos potenciales.

Preparar el ambiente de soporte al proyecto

Establecer el ámbito del producto, la identificación de los principales riesgos y la viabilidad del proyecto.


Página 4 de 6

4.2 Fase 2: Elaboración

Fase Objetivos Hito

Elaboración Asegurar que la arquitectura, requisitos y planes son lo suficientemente estables y los riesgos han sido mitigados para poder determinar los costes y planificación para completar el desarrollo.

Solucionar todos los riesgos significativos para la arquitectura del proyecto.

Establecer la línea base de la arquitectura obtenida después de tratar los escenarios más significativos para la arquitectura, que por lo general muestra los mayores riesgos técnicos del proyecto.

Producir un prototipo progresivo de componentes con calidad para la producción, así como también los prototipos desechables exploratorios donde se mitigan riesgos específicos, como por ejemplo: Soluciones de compromiso en el diseño, reutilización de componentes, factibilidad del producto, o demostraciones a inversores, clientes y usuarios finales

Demostrar que la arquitectura incluida en la línea base respaldará los requisitos del sistema a un coste y tiempo razonables.

Establecer el ambiente de soporte para el proyecto. Esto incluye crear los planes de desarrollo, preparar las plantillas de los documentos, instrucciones, y herramientas.

Obtener una línea base de la arquitectura del sistema, capturar los requisitos y reducir los riesgos principales así como permitir la escalabilidad del equipo del proyecto durante la fase de construcción.

4.3 Fase 3: Construcción

Fase Objetivos Hito

Construcción Minimizar los costos de desarrollo, optimizando los recursos y evitando cambios innecesarios que resulten de desechar o modificar trabajo ya realizado.

Obtener una calidad apropiada tan rápido como sea posible.

Obtener versiones útiles (alfa, beta, y otras entregas de prueba) tan rápido como sea posible.

Completar el análisis, diseño, desarrollo y prueba de toda la funcionalidad requerida.

Desarrollar de forma iterativa e incremental un producto completo que esté listo para su transición hacia la comunidad de usuarios. Esto implica detallar otros casos de uso y otros requisitos que surgieran así como completar el diseño, implementación y prueba del software.

Decidir si el software, lugar y usuarios están listos para la instalación de la aplicación.

Alcanzar algún grado de paralelismo en el trabajo de los equipos. Incluso en proyectos pequeños existen componentes que pueden ser desarrollados de forma independiente entre ellos, permitiendo un paralelismo natural entre los equipos. Este paralelismo puede acelerar significativamente el desarrollo de actividades.

Desarrollo del sistema con calidad de producción y prepararse para la entrega al equipo de transición. Toda la funcionalidad debe haber sido implementada y las pruebas para el estado beta de la aplicación completadas. Si el proyecto no logra alcanzar este hito, entonces la transición deberá posponerse una iteración.


Página 5 de 6

4.4 Fase 4: Transición

Fase Objetivos Hito

Transición Realizar pruebas de estadio beta para validar el nuevo sistema con las expectativas de los usuarios.

Entrenamiento de usuarios y encargados del mantenimiento.

Actividades de corrección de errores, mejoras en el funcionamiento, rendimiento y usabilidad.

Evaluación de la línea base de la instalación con la visión completa y criterios de la aceptación del producto.

Lograr el consenso de los involucrados en que la línea base se encuentre completa.

Revisión y aceptación del producto software.

55 AAMMBBIITTOO DDEE AAPPLLIICCAACCIIÓÓNN

5.1 Nuevos desarrollos de sistemas informáticos Para efectos de la aplicación de la siguiente metodología, se considerará que el requerimiento corresponde a un nuevo desarrollo de sistema informático (software) y que cumple con una o más de las siguientes premisas:

Demande igual o más de 120 horas de trabajo (estimado al momento de la planificación).

Involucre desarrollar uno o más nuevos módulos o subsistemas.

Afecte a más de un sistema informático en producción

Involucre cambios en la arquitectura del sistema En los casos en que para una aplicación se hayan acumulado varios requerimientos que se atenderán conjuntamente y éstos, en conjunto, cumplan con las premisas señaladas en el acápite anterior (así no lo hicieran en forma individual), deberán seguir la metodología establecida para los mantenimientos. Para los nuevos desarrollos, el equipo de la Unidad de Sistemas o proveedores que desarrollan software, deben generar los siguientes documentos:

N° Entregables Formatos (Word)

1 Modelo de Negocio TP-MODELO DE NEGOCIO.docx

2 Documento de Requerimientos TP-REQUERIMIENTOS.docx

3 Glosario de Términos TP-GLOSARIO.docx

4 Análisis y Diseño TP-ANALISIS Y DISEÑO.docx

5 Documento de Especificación de Casos de Uso de Sistema TP-ESPECIFICACION CU.docx

6 Documento de Arquitectura TP-ARQUITECTURA DE SOFTWARE.docx

7 Plan de Pruebas TP-PLAN DE PRUEBAS.docx

8 Informe de Pruebas TP-INFORME DE PRUEBAS.docx

9 Manual de Usuario * Documento propio de la Unidad de Sistemas

10 Manual de Instalación * Documento propio de la Unidad de Sistemas

(*) Son documentos propios de la Unidad de Sistemas y que se recomienda seguir utilizándolos, por ello no se han generado formatos adicionales.


Página 6 de 6

5.2 Mantenimientos y excepciones Para aquellos casos no contemplados de acuerdo a las premisas indicadas en el punto anterior, es decir:

Demande menos de 120 horas de trabajo (estimado al momento de la planificación)

Modifique o elimine una o más tablas de la aplicación

Modifique o elimine una o más clases de la aplicación

Modifique o elimine uno o más casos de uso de la aplicación

Modifique o elimine las características de uno o más actores

Modifique o elimine alguna otra característica tales como: procedimientos almacenados, funciones, trigers, reportes, etc.

Para los mantenimientos de software en producción, el equipo de la Unidad de Sistemas o proveedores que desarrollan software, deben generar los siguientes documentos:

N° Entregables Formatos (Word)

1 Informe de Detalles del Cambio Informe que indique los cambios realizados

2 Documento de Requerimientos TP-REQUERIMIENTOS.docx

3 Análisis y Diseño TP-ANALISIS Y DISEÑO.docx

4 Documento de Especificación de Casos de Uso de Sistema TP-ESPECIFICACION CU.docx

El informe de detalles del cambio debe tener los datos de tablas, clases, casos de uso, actores, etc., que indique los cambios realizados.

66 HHEERRRRAAMMIIEENNTTAASS RREECCOOMMEENNDDAADDAASS La adopción de la metodología de desarrollo de software, puede ser más rápida si es que se utiliza una aplicación informática como soporte a las actividades que deben ser realizadas por el equipo de desarrollo de software de la Unidad de Sistemas del Programa Trabaja Perú. Por ello se recomienda utilizar alguna de las siguientes herramientas para la gestión de la configuración:

a) Team Foundation Server.- En su versión 2010 automatiza y optimiza el proceso de entrega del software para todos los miembros del equipo. (http://msdn.microsoft.com/es-es/vstudio/ff637362).

b) Subversion.- Es un Sistema de Control de Versiones de software libre, sirve principalmente para el versionado de código fuente. (http://subversion.tigris.org/)

c) Rational Clear Quest.- Proporciona el seguimiento de cambios y defectos, la automatización de procesos, la generación de informes y la rastreabilidad del ciclo de vida para obtener una mayor visibilidad y control del ciclo de vida de desarrollo de software. (http://www-142.ibm.com/software/products/es/es/clearquest/)

http://msdn.microsoft.com/es-es/vstudio/ff637362

http://msdn.microsoft.com/es-es/vstudio/ff637362

http://subversion.tigris.org/

http://www-142.ibm.com/software/products/es/es/clearquest/

http://www-142.ibm.com/software/products/es/es/clearquest/



PLANTILLA A UTILIZAR COMO

MODELO DE NEGOCIO {NOMBRE SISTEMA}

{Versión n.n.n}

Actualizado a {Nombre mes} {Año}

Modelo de Negocio { NOMBRE SISTEMA }

Página 2 de 11

Historial de Revisiones

Ítem Fecha Versión Equipo Autor Descripción Responsable de

revisión y/o aprobación

{01} {dd/mm/aaaa} {n.n.n} {Nombre del

equipo} {Nombre del autor}

{Descripción de los cambios en el documento}

{Nombre de responsable de

revisión y/o aprobación}


Página 3 de 11

TABLA DE CONTENIDOS

1 INTRODUCCIÓN ............................................................................................................................ 4

1.1 Objetivo .................................................................................................................................. 4 1.2 Alcance ................................................................................................................................... 4 1.3 Definiciones y abreviaciones ................................................................................................. 4

2 POSICIONAMIENTO ...................................................................................................................... 4

2.1 Oportunidad de Negocio ........................................................................................................ 4 2.2 Definición del Problema ......................................................................................................... 4

3 DESCRIPCIÓN DE STAKEHOLDERS Y USUARIOS .................................................................. 4

3.1 Resumen de los Stakeholders ............................................................................................... 4 3.2 Resumen de los Usuarios ...................................................................................................... 5 3.3 Entorno del Usuario ............................................................................................................... 5

4 CONTEXTO DEL SISTEMA ........................................................................................................... 5

4.1 Identificación de los procesos de Negocio ............................................................................. 5 4.1.1 Diagrama de procesos de nivel 0 ...................................................................................... 5 4.1.2 Diagrama de nivel 1 ........................................................................................................... 6 4.1.3 Descripción de los Procesos ............................................................................................. 7

4.2 Reglas de Negocio ................................................................................................................. 7 4.3 Diagrama de procesos de la Situación actual........................................................................ 8 4.4 Diagrama de procesos optimizado ........................................................................................ 8

5 CASOS DE USO DEL NEGOCIO .................................................................................................. 9

5.1 Identificación de actores principales del negocio .................................................................. 9 5.2 Diagrama de Actores del Negocio ......................................................................................... 9 5.3 Identificación de Casos de Uso del Negocio ......................................................................... 9 5.4 Diagrama de Casos de Uso del Negocio ............................................................................. 10

6 CLASES DEL NEGOCIO ............................................................................................................. 10

6.1 Diagrama de Clases de Negocio ......................................................................................... 10 6.2 Descripción de las Clases de Negocio ................................................................................ 11

7 ANEXOS ....................................................................................................................................... 11

7.1 Resultado de análisis de procesos ...................................................................................... 11


Página 4 de 11

11 IINNTTRROODDUUCCCCIIÓÓNN [La introducción brinda una vista rápida de todo el documento respecto al sistema en desarrollo. Da una idea general del contenido del documento así como algunos alcances generales. ]

1.1 Objetivo [Indicar el objetivo del documento Modelo de Negocio respecto al sistema en desarrollo.]

1.2 Alcance [Una breve descripción del alcance de este documento y qué otros documentos se ven afectados por éste. Además debe mencionarse qué otro(s) sistema(s) están asociados o se ven afectados por el sistema en desarrollo.]

1.3 Definiciones y abreviaciones [Esta sección brinda la definición de aquellos términos y abreviaciones requeridas para interpretar adecuadamente el contenido de este documento. Esta información debería ser provista en un glosario del documento y aquí únicamente hacer referencia a dicho documento.]

22 PPOOSSIICCIIOONNAAMMIIEENNTTOO

2.1 Oportunidad de Negocio [Se debe indicar la oportunidad de negocio y los niveles de calidad a los que se quiere llegar, y la relación y/o el aporte del sistema en su consecución.]

2.2 Definición del Problema [Se debe explicar en forma clara cuál es el problema que se pretende solucionar, así como cuáles son los beneficios que se tendrían con la solución propuesta. Colocar sólo el principal problema que en forma general incluya a problemas menores.]

El problema es [Describa el problema concisamente]

Afecta a [Listar a quienes se ven afectados por el problema (persona, cargos, áreas, etc.)]

El impacto es [Describir el impacto del problema. Puede ser más de uno]

Una solución exitosa es [Listar los beneficios de una solución exitosa]

33 DDEESSCCRRIIPPCCIIÓÓNN DDEE SSTTAAKKEEHHOOLLDDEERRSS YY UUSSUUAARRIIOOSS

3.1 Resumen de los Stakeholders [Se detalla a todos los involucrados, es decir aquellos que serán afectados por el proyecto y que pueden ejercer cierta influencia sobre él, pero que no están directamente involucrados con la ejecución del trabajo. Ejemplos de este tipo de interesados son: gerentes afectados por el proyecto, personas que trabajan en los procesos de negocio involucrados, departamentos internos que soportan el proceso (como el departamento de finanzas), proveedores, la oficina de gestión de proyectos, clientes y el patrocinador]

Nombre Rol Responsabilidades

[Nombre del tipo [Descripción del rol del [Principales responsabilidades del stakeholder

http://es.wikipedia.org/wiki/Oficina_de_Gesti%C3%B3n_de_Proyectos

http://es.wikipedia.org/wiki/Oficina_de_Gesti%C3%B3n_de_Proyectos


Página 5 de 11

de Stakeholder] stakeholder dentro del

proyecto.]

dentro del proyecto. Por ejemplo: Definir el

proceso de negocio, Aprobar alguna tarea,

etc.]

3.2 Resumen de los Usuarios

Nombre Rol Responsabilidades Stakeholder

[Tipo de

usuario]

[Descripción

del rol del

usuario

respecto al

sistema]

[Principales

responsabilidades del

usuario respecto al

sistema. Por ejemplo:

generar reportes, etc.]

[Si el usuario no está

directamente representado, se

deberá especificar que

stakeholder será responsable de

representar sus intereses, dentro

de la fase de concepción]

3.3 Entorno del Usuario

Lista de personas involucradas en completar el proceso

[Se debe listar a todos los usuarios involucrados]

Tiempo que se necesita (promedio) para completar el proceso

[Se debe poner el valor y la unidad de medida, En el caso

de ser más de un proceso y estar diferenciados especificar

el nombre del proceso valor y unidad de medida.]

Actual plataforma utilizada [Se debe describir la actual plataforma utilizada, puede ser más de una.]

Aplicaciones actuales utilizadas en el proceso

[Listar los Sistemas utilizados en el proceso]

44 CCOONNTTEEXXTTOO DDEELL SSIISSTTEEMMAA [Se debe definir el contexto del sistema, el dominio donde funcionará, quiénes son los usuarios principales, las entidades que intervienen, si se trata de la continuación de un sistema existente, la migración de tecnología de un mismo sistema, la automatización de un proceso manual, etc.]

4.1 Identificación de los procesos de Negocio Aunque la metodología de trabajo está fundamentalmente orientada a objetos, para la identificación de los principales procesos de negocio del sistema se hará uso del diagrama de contexto de negocio.

4.1.1 Diagrama de procesos de nivel 0

En el diagrama de contexto o de nivel 0 solo modela, o dibuja, el proceso principal del problema en cuestión con sus respectivas entidades. Además se deben identificar las fronteras del proceso, para que todo lo que no se encuentre dentro de las referidas fronteras no forme parte del estudio de sistemas Cada proceso debe tener al menos una entrada y una salida de datos.

[Los diagramas deben ser generados con un modelador de procesos o en su defecto Visio]


Página 6 de 11

Diagrama de procesos de nivel 0

Del flujo de datos que se percibe entre el sistema y cada una de las entidades anteriormente mencionadas se tiene:

ENTIDAD DESCRIPCIÓN

{Coloque aquí el nombre de la entidad 1}

{Coloque aquí la descripción de la entidad y cómo interviene en el diagrama}

{Coloque aquí el nombre de la entidad 2}


{ … } {Coloque aquí la descripción de la entidad y cómo interviene en el diagrama}

{Coloque aquí el nombre de la entidad n}


De la explotación del Diagrama de Contexto se han podido resaltar los procesos más relevantes, los cuales se representan en el siguiente Diagrama de Nivel 1.

4.1.2 Diagrama de nivel 1

En el diagrama de nivel 1, de mayor detalle, se plasman todos los sub-procesos que describen al proceso principal, o sea, éste se descompone en varios procesos. En este nivel aparecen los archivos, los cuales tienen la capacidad de almacenar o enviar datos para ser usados en los distintos procesos.


Página 7 de 11


4.1.3 Descripción de los Procesos

[Repita el siguiente cuadro por cada uno de los procesos identificados en el nivel 1]

Proceso de Negocio

{Nombre del proceso}

Objetivo {Colocar cual es el objetivo del negocio que se persigue en este proceso del Negocio}

Descripción {Descripción del proceso del negocio}

Prioridad {Básico, Medio, Alto}

Riesgos {Identificación del riesgo que se presenta en este proceso. También se puede indicar si se trata de un proceso crítico o no}

Posibilidades {Determinación del éxito de la posible automatización del proceso del negocio}

Flujos de entrada {Indicar los flujos de entrada al proceso}

Flujos de salida {Indicar los flujos de salida del proceso}

4.2 Reglas de Negocio [Listado de las reglas de negocio aplicadas en los procesos según las normativas, documentación y formas de trabajo de la entidad.] [Repita por cada regla.]

Regla de Negocio {Colocar el nombre de la regla de negocio}

Normativas y Dispositivos legales

{Escriba una descripción acerca de la normativa}

Tipo de regla {Regla especifica, Regla de Codificación, Reglas de Cálculo, Reglas de Acceso a la Información, Otras reglas}


Página 8 de 11

Descripción de la regla {Descripción detallada de la regla de negocio, si la norma es muy larga se puede hacer un resumen que contenga lo principal}

4.3 Diagrama de procesos de la Situación actual [Debe incluirse los diagramas de procesos de la situación actual correspondientes a los procesos de negocio identificados. Incluir un diagrama de actividades por cada proceso de negocio identificado.]

Diagrama de actividades del Proceso 1 actual [Coloque aquí cualquier comentario adicional que se considere necesario para la mejor comprensión del diagrama.]

4.4 Diagrama de procesos optimizado [De ser necesario incluir un diagrama de procesos de negocio.]

Diagrama de actividades de Proceso 1 optimizado propuesto


Página 9 de 11

[De ser necesario coloque aquí cualquier comentario adicional que se considere necesario para la mejor comprensión del diagrama.]

55 CCAASSOOSS DDEE UUSSOO DDEELL NNEEGGOOCCIIOO

5.1 Identificación de actores principales del negocio

NOMBRE DEL ACTOR DESCRIPCIÓN

{Nombre del actor 1} { Descripción del actor }

{Nombre del actor 2} { Descripción del actor }

{ … } { Descripción del actor }

{Nombre del actor n} { Descripción del actor }

5.2 Diagrama de Actores del Negocio

Diagrama de actores del negocio

[De ser necesario coloque aquí cualquier comentario adicional que se considere necesario para una mejor comprensión del diagrama, indicando la relación entre los actores del negocio.]

5.3 Identificación de Casos de Uso del Negocio

NOMBRE DEL CASO DE USO DESCRIPCIÓN

{Nombre del caso de uso 1} { Descripción del caso de uso }

{Nombre del caso de uso 2} { Descripción del caso de uso }

{…} { Descripción del caso de uso }

<<Actor Negocio>>

Usuario PPSS

<<Trabajador Negocio>>

Usuario SINAMEIS

<<Actor Negocio>>

Usuario del Sector

<<Actor Negocio>>

Ciudadano

<<Actor Negocio>>

Usuario MEF

<<Actor Negocio>>

Usuario CGR


Página 10 de 11

{Nombre del caso de uso m} { Descripción del caso de uso }

5.4 Diagrama de Casos de Uso del Negocio

Diagrama de Casos de Uso del Negocio

[De ser necesario coloque aquí cualquier comentario adicional que se considere necesario para una mejor comprensión del diagrama.]

66 CCLLAASSEESS DDEELL NNEEGGOOCCIIOO [Representar las clases de negocio y sus relaciones.]

6.1 Diagrama de Clases de Negocio

<<Caso de Uso de Negocio>>

Gestión de Seguridad

<<Actor Negocio>>

Ciudadano

<<Actor Negocio>>

Usuario del Sector

<<Actor Negocio>>

Usuario PPSS

<<Trabajador Negocio>>

Usuario SINAMEIS<<Caso de Uso de Negocio>>

Gestión de Información


Gestión del Monitoreo


Gestión de Evaluación

<<Actor Negocio>>

MEF


Página 11 de 11

Diagrama de clases del negocio

[De ser necesario coloque aquí cualquier comentario adicional que se considere necesario para una mejor comprensión del diagrama.]

6.2 Descripción de las Clases de Negocio En el diagrama anterior se han plasmado las clases que participan como parte de los procesos de negocio. A continuación se detalla cada una de ellas:

[Elabore la tabla siguiente para cada una de las clases identificadas.]

Nombre de la Clase { Colocar el nombre de la clase }

Descripción { Escriba una descripción acerca de la clase}

Atributos { Escriba la lista de atributos identificados inicialmente}

Responsabilidad { Escriba las responsabilidades asignadas a esta clase}

77 AANNEEXXOOSS [Incluir los anexos que se estimen necesarios, documentación proporcionada por los usuarios que clarifiquen mejor el modelo de negocio.]

7.1 Resultado de análisis de procesos

[En caso sea aplicable, incluir recursos, perfiles de simulación, resultados de simulación y análisis estadístico producto del análisis de los procesos.]

1..1

1..*

1..*

1..*

0..1

1..1

0..1

1..1

0..1

0..*

0..1

0..*

Beneficiario

-

-

-

-

-

-

dni

apellidoPaterno

apellidoMaterno

nombres

sexo

fechaNacimiento

: String

: String

: String

: String

: Character

: Date

Ubigeo

-

-

-

-

codigoUbigeo

nombreDepartamento

nombreProvincia

nombreDistrito

: String

: String

: String

: String

ProgramaSocial

-

-

-

-

-

-

codigoPPSS

nombrePPSS

direccionPPSS

emailPPSS

telefono

estadoPPSS

: String

: String

: String

: String

: String

: Integer

Indicador

-

-

-

-

codigoIndicador

nombreIndicador

formulaIndicador

estadoIndicador

: String

: String

: String

: Integer

EstablecimientoSalud

-

-

-

codigoEESS

nombreEESS

estadoEESS

: String

: String

: Integer

InstitucionEducativa

-

-

-

codigoIIEE

nombreIIEE

estadoIIEE

: String

: String

: Integer

CentroPoblado

-

-

-

codigoCCPP

nombreCCPP

estadoCCPP

: String

: String

: Integer




REQUERIMIENTOS {NOMBRE SISTEMA}

{Versión n.n.n}


REQUERIMIENTOS { NOMBRE SISTEMA }

Página 2 de 8







{Nombre del responsable de



Página 3 de 8

TABLA DE CONTENIDOS

1 INTRODUCCIÓN ............................................................................................................................ 4

1.1 Objetivo .................................................................................................................................. 4 1.2 Alcance ................................................................................................................................... 4 1.3 Definiciones y Abreviaciones ................................................................................................. 4

2 DETERMINACIÓN DEL ALCANCE FUNCIONAL DEL SISTEMA ............................................... 4

2.1 Contexto del Sistema ............................................................................................................. 4 2.2 Necesidades y Características .............................................................................................. 5 2.3 Definición del Sistema ............................................................................................................ 5 2.4 Alcance funcional del Sistema ............................................................................................... 5 2.5 Restricciones y Límites del Sistema ...................................................................................... 5

2.5.1 Interfaces con otros sistemas ............................................................................................ 5

3 LISTA DE REQUERIMIENTOS ...................................................................................................... 6

3.1 Requerimientos Funcionales ................................................................................................. 6 3.2 Requerimientos no Funcionales ............................................................................................ 6 3.3 Requerimientos Transversales a todos los procesos ............................................................ 7

4 CASOS DE USOS DEL SISTEMA ................................................................................................. 7

4.1 Listado de Actores ................................................................................................................. 7 4.2 Listado de Casos de Uso del Sistema ................................................................................... 8

4.2.1 {Nombre del módulo o subsistema} ................................................................................... 8

5 ANEXOS ......................................................................................................................................... 8


Página 4 de 8

11 IINNTTRROODDUUCCCCIIÓÓNN [La introducción brinda una vista rápida de todo el documento. Incluye el objetivo, alcances, definiciones, abreviaturas utilizadas en el documento.]

1.1 Objetivo [Indicar la naturaleza y objetivo del documento respecto al sistema desarrollado.]

1.2 Alcance [Una breve descripción del alcance de este documento. Incluir que otro(s) documento(s) o sistema(s) están asociados o se ven afectados por este documento.]

1.3 Definiciones y Abreviaciones [Esta sección brinda la definición de aquellos términos y abreviaciones requeridas para interpretar adecuadamente el contenido de este documento. Esta información debería ser provista en un glosario del documento y aquí únicamente hacer referencia a dicho documento.]

22 DDEETTEERRMMIINNAACCIIÓÓNN DDEELL AALLCCAANNCCEE FFUUNNCCIIOONNAALL DDEELL SSIISSTTEEMMAA [En este apartado se presentan las características específicas del sistema requerido por el cliente, en lo referente a su alcance funcional y especificaciones a cumplir.]

2.1 Contexto del Sistema [Aquí se identifican los procesos o actividades que serán soportadas por el sistema dentro del contexto del negocio.] [Incluir un gráfico de los procesos del negocio a nivel macro indicando qué procesos serán soportados por el sistema.] [Incluir el diagrama de procesos de nivel 1.]



Página 5 de 8

2.2 Necesidades y Características [La siguiente tabla resume las principales necesidades de los usuarios, los prioriza y luego propone las características que tendrá el producto y en que versión será implementado.]

Necesidad del Negocio Prioridad Característica del Sistema Versión Sistema

{Colocar la versión 1,

2, etc.}

{Sistematizar los procedimientos asociados con la formulación del Marco Lógico – ML}

{Alta}

{El sistema permitirá gestionar la información registrada del Marco Lógico de cada programa social.}

{1}

2.3 Definición del Sistema [Describir el sistema a desarrollar indicando las actividades que automatiza y las facilidades que ofrece.]

2.4 Alcance funcional del Sistema [Identificar los aspectos funcionales generales que serán implementados en el sistema.] [Identificar los Módulos y Paquetes (o Sub Módulos) que soportarán a dichas funcionalidades.] [Incluir en este punto el Diagrama de Paquetes. El siguiente gráfico es un ejemplo de este diagrama.]

Diagrama de paquetes del sistema

2.5 Restricciones y Límites del Sistema [Definir lo puntos que no serán implementados en el sistema. En este punto se debe indicar las interfaces con otros sistemas.]

2.5.1 Interfaces con otros sistemas

ITEM INTERFAZ DESCRIPCION

1 RENIEC {El sistema hará uso de Web Service de RENIEC para validar el DNI}


Página 6 de 8

33 LLIISSTTAA DDEE RREEQQUUEERRIIMMIIEENNTTOOSS [Listado de los Requerimientos funcionales y técnicos obtenidos durante las reuniones de levantamiento de información con el Área Usuaria. Incluir la priorización.]

3.1 Requerimientos Funcionales [Propio de la Operativa del Negocio]

Código Descripción Tipo Prioridad

RQXXXX001 ACU Crítico

RQXXXX002 AAG Necesario

RQXXXX003 AAG Deseable

[Donde: Código: RQXXXXNNN XXXX: Es el código del Área Usuaria NNN: Es un secuencial Prioridad: Crítico (C),

Necesario (N), Deseable (D)

TIPO AUC: Asociados a los casos de uso. AAG: Asociados a aspectos generales]

3.2 Requerimientos no Funcionales [Característica o restricción del sistema]









[Donde: Código: RQXXXXNNN XXXX: Es el código del Área Usuaria NNN: Es un secuencial Prioridad: Crítico (C),

Necesario (N), Deseable (D)

TIPO: USA: Usabilidad. CON: Confiabilidad REN: Rendimiento


Página 7 de 8

SOP: Soporte. RED: Restricciones de Diseño INU: Interfaces de Usuarios. INH: Interfaces de Hardware INS: Interfaces de Software INC: Interfaces de Comunicaciones RUP: Estándares Aplicables.]

[Incluir las especificaciones de requerimientos suplementarios si existiera.]

3.3 Requerimientos Transversales a todos los procesos


RQ-T001 Validación de los DNI ingresados (numérico de 8 dígitos)

AAG C

RQ-T002 Validación de los UBIGEOS de acuerdo al INEI AAG C

RQ-T003 Validación de la información complementaria a Ubicación Geográfica (número)

AAG C

RQ-T004 Validación de los apellidos paternos, apellidos maternos y nombres a texto

AAG C

RQ-T005 Validación de las fechas a formato fecha AAG C

RQ-T006 Validación del código SIS a número AAG C

RQ-T007 Validación de tipo de Sexo AAG C

RQ-T008 Validación de la edad a tipo numérico AAG C

RQ-T009 Validación del código de EESS a tipo numérico AAG C

RQ-T010 Captura de los datos que son seleccionados de preguntas con respuestas dicotómicas o de listados

AAG C

44 CCAASSOOSS DDEE UUSSOOSS DDEELL SSIISSTTEEMMAA [Incluir la definición de caso de uso, diagrama de casos de usos, actores, tipos de asociaciones y sus respectivas representaciones.]

4.1 Listado de Actores [Listar la relación de actores identificados en el sistema, según el siguiente formato]

Ítem Actor Descripción

1 [Nombre del actor] [Describir al actor indicando sus funciones y responsabilidades con el sistema]

[Incluir un Diagrama de Actores. El siguiente gráfico es un ejemplo de este diagrama.]


Página 8 de 8

Diagrama de actores del sistema

4.2 Listado de Casos de Uso del Sistema [Mostrar la relación de Casos de Usos identificados para cada uno de los Módulos y Paquetes o Sub Módulos que integrarán el Sistema. Utilizar el siguiente formato.] 4.2.1 {Nombre del módulo o subsistema}

Código Caso de Uso

Caso de uso

[Indicar el código de caso de uso CUSXXX001 Donde XXX es el prefijo del modulo]

[Buscar Información de Formato FOC.01]





ESPECIFICACIÓN DE CASOS DE USO {NOMBRE SISTEMA}

{Versión n.n.n}


ESPECIFICACIÓN DE CASOS DE USO { NOMBRE SISTEMA }

Página 2 de 6










Página 3 de 6

TABLA DE CONTENIDOS

1 INTRODUCCIÓN ............................................................................................................................ 4


2 ESPECIFICACIÓN DE CASOS DE USO ...................................................................................... 4

2.1 {Nombre del módulo o subsistema} ....................................................................................... 4

3 ANEXOS ......................................................................................................................................... 6


Página 4 de 6

11 IINNTTRROODDUUCCCCIIÓÓNN [El presente documento contiene la especificación de los Casos de Uso para un sistema informático, en cada uno de ellos se brinda información detallada de la secuencia de pasos o interacción entre un actor y el sistema. Es uno de los documentos técnicos necesarios y obligatorios que deben ser validados con los usuarios funcionales. Una vez identificados los usuarios del sistema (actores primarios) se validan los flujos completos que proporcionan suficiente valor tanto a ellos como a la institución.]

1.1 Objetivo [El documento tiene como objetivo servir de herramienta que permita conocer la interacción funcional del sistema con los usuarios o actores identificados.]

1.2 Alcance [El documento será de utilidad en la comunicación y validación de la funcionalidad del sistema informático, entre desarrollador y usuario final. Podrá ser mejorado durante las iteraciones previstas en la etapa de construcción.]

1.3 Definiciones y abreviaciones [Ver documento Glosario de Términos.]

22 EESSPPEECCIIFFIICCAACCIIÓÓNN DDEE CCAASSOOSS DDEE UUSSOO [A continuación se muestra el diagrama de caso de uso y especificación de caso de uso por cada módulo identificado.]

2.1 {Nombre del módulo o subsistema} [Incluir el Diagrama de Casos de Uso del módulo. El siguiente gráfico es un ejemplo de este diagrama]


Página 5 de 6

Diagrama de casos de uso del sistema del módulo 1

[Incluir la tabla siguiente por cada caso de uso del diagrama]

TERMINOS DEFINICION

Caso de Uso {Código del caso de uso}-{Nombre del caso de uso}

Descripción General {Descripción del caso uso}

Pre-condición [Se mencionarán las condiciones de entrada para activar el Caso de Uso]

Post-condición [Se mencionarán las condiciones de salida para el Caso de Uso]

Actores [Se mencionarán los actores para el Caso de Uso]

Flujo Principal

Flujo Alternativo 1

Flujo Alternativo 2

Puntos de Extensión

Reglas Identificadas


Página 6 de 6

Diseño de Prototipo

[Colocar aquí la captura de la(s) ventanas correspondientes al caso de uso]





ANÁLISIS Y DISEÑO {NOMBRE SISTEMA}

{Versión n.n.n}


ANÁLISIS Y DISEÑO { NOMBRE SISTEMA }

Página 2 de 11




1 {dd/mm/aaaa} {1.0} {Nombre del equipo}

{Nombre del autor}

{Describir los cambios realizados en el documento}

{Nombre del responsable de revisión y/o aprobación}


Página 3 de 11

TABLA DE CONTENIDOS

1 INTRODUCCIÓN ............................................................................................................................ 4


2 MODELO DE CLASES DE ANÁLISIS........................................................................................... 4

2.1 Diagrama de Clases {Modulo 1} ............................................................................................ 4 2.2 Especificación de clases {Modulo 1} ...................................................................................... 5

3 DIAGRAMAS DE ACTIVIDADES .................................................................................................. 5

4 DIAGRAMAS DE ESTADOS ......................................................................................................... 6

4.1 Diagrama de estados de {Nombre de entidad} ...................................................................... 6

5 REALIZACIÓN DE CASOS DE USO ............................................................................................. 7

5.1 Diagramas de Secuencia ....................................................................................................... 7 5.1.1 {Nombre del diagrama de secuencia} ............................................................................... 8

6 MODELO DE DATOS .................................................................................................................... 8

6.1 Modelo Entidad-Relación Lógico ........................................................................................... 8 6.2 Modelo Entidad-Relación Físico ............................................................................................ 9 6.3 Diccionario de Datos .............................................................................................................. 9

6.3.1 Listado de Tablas .............................................................................................................. 9 6.3.2 Descripción de tablas y campos ...................................................................................... 10 6.3.3 Listado de Objetos Complementarios de Base de Datos ................................................ 10

7 ANEXOS ....................................................................................................................................... 11


Página 4 de 11

11 IINNTTRROODDUUCCCCIIÓÓNN [La introducción brinda una vista rápida de todo el documento. Da una idea general del contenido del documento así como algunos alcances generales. Incluye el objetivo, alcance, definiciones, abreviaturas utilizadas en el documento.]

1.1 Objetivo [Indicar el objetivo del documento.]

1.2 Alcance [Una breve descripción del alcance de este documento, qué otro(s) sistema(s) están asociados o se ven afectados por este documento.]


22 MMOODDEELLOO DDEE CCLLAASSEESS DDEE AANNÁÁLLIISSIISS

[Identificar las clases de análisis. Los diagramas de clases de análisis pueden agruparse por subsistemas. Las clases deben mostrar su nombre y las relaciones entre ellas, debe especificar el estereotipo de la clase (Boundary, Control, Entity). Mostrar los atributos más importantes o relevantes para la comprensión del diagrama.] {Agregar un diagrama para cada módulo}

2.1 Diagrama de Clases [Es un diagrama opcional para la metodología del Programa Trabaja Perú]

Diagrama de clases de {Módulo 1}


Página 5 de 11

2.2 Especificación de clases [Es un punto opcional para la metodología del Programa Trabaja Perú] Mediante la siguiente tabla se describe las clases identificadas, atributos iniciales y métodos principales: [Debe registrarse una clase por cada tabla y ordenadas alfabéticamente. Las tablas siguientes pueden reemplazarse con la opción a generar según lenguaje de programación utilizado que genera documentación en formato HTML. Por ejemplo en el caso de Java, utilizar Javadoc y en el caso de .net usar Ndoc.]

Nombre {NOMBRE DE LA CLASE}

Descripción

Atributos

Item Nombre Descripción Tipo de Dato

1

2

3

Métodos

Item Nombre Descripción Parámetros

Entrada Retorno

1

2

3

33 DDIIAAGGRRAAMMAASS DDEE AACCTTIIVVIIDDAADDEESS

[Diagrama Obligatorio. El diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general. El propósito del diagrama de actividad es modelar un proceso de flujo de trabajo (workflow) y/o modelar operaciones. Una Operación es un servicio proporcionado por un objeto, que está disponible a través de una interfaz. Una Interfaz es un grupo de operaciones relacionadas con la semántica.]


Página 6 de 11

Diagrama de actividades

44 DDIIAAGGRRAAMMAASS DDEE EESSTTAADDOOSS

[Diagrama opcional. Luego de analizar las clases de entidad del diagrama de clases, deben identificarse aquellas entidades que cambian de estado. Para cada una de las entidades que cambian de estado deberá mostrarse un diagrama de estados. Se entiende por entidad al conjunto de datos que conforman un registro coherente y son almacenados por lo general en una tabla. Cuando no se contemple diagramas de estado, se debe justificar en este ítem. Si hay varias entidades que cumplen con un cambio de estados igual, se puede graficar un sólo diagrama de estados y se deberá indicar las clases que cumplen con ese cambio de estados.]

4.1 Diagrama de estados de {Nombre de entidad}


Página 7 de 11

Diagrama de estados de {Nombre de entidad}

[Luego del diagrama de estados incluir una descripción de los estados por los que pasa la entidad, así como describir qué tiene que pasar para el cambio de estado.]

Entidad {Nombre de la clase de entidad}

Item ESTADO DESCRIPCIÓN

1

2

3

[Insertar diagrama de estados y descripción de estados por cada entidad a la que se haya identificado estados, repetir la sección 3.1 para cada caso asignándole un número correlativo (3.2, 3.3,…, etc.)]

55 RREEAALLIIZZAACCIIÓÓNN DDEE CCAASSOOSS DDEE UUSSOO [La realización de casos de uso se realizará mediante diagramas de interacción. Deberán identificarse los casos de uso que sigan un comportamiento común como las búsquedas y operaciones CRUD (Create, Read, Update, Delete) sobre una sola entidad, de tal manera que se grafique una sola vez cómo se manejarán estas situaciones.]

5.1 Diagramas de Secuencia [Se deberán agrupar los diagramas de secuencia por módulo o subsistema Todos los casos de uso deberán tener un diagrama de secuencia asociado.]

Módulo o subsistema Caso de uso Diagrama de Secuencia

Módulo 1 Caso de uso 1 Diagrama 1

Caso de uso 2 Caso de uso 3

Diagrama 2

Módulo 2 Caso de uso 4 Diagrama 3


Página 8 de 11

5.1.1 {Nombre del diagrama de secuencia}

Diagrama de secuencia {Nombre de diagrama}

[Incluir una breve descripción del diagrama. Si el diagrama es complejo incluir una descripción detallada.]

TÍTULO: {Nombre del diagrama de secuencia nro 1}

DESCRIPCIÓN: {Descripción concisa del diagrama de secuencia nro }

ACTORES: [Listar los actores que intervienen en el diagrama]

OBJETOS: [Listar los objetos que intervienen en el diagrama]

MENSAJES: [Listar los mensajes del diagrama]

[Repetir por cada diagrama de secuencia.]

66 MMOODDEELLOO DDEE DDAATTOOSS

6.1 Modelo Entidad-Relación Lógico {Descripción del Modelo Lógico} [Incluir el modelo de datos lógico. Considerar la separación en vistas de tal manera que el modelo pueda verse. El modelo de datos debe estar graficado en la notación Information Engineering]

Modelo de datos lógico

CODINFORME

NCIN_CODENT: String

NCIN_ID: Number

CCIN_CODINA: String

INFORME

NINF_ID: Number

CINF_CODENT: String

CINF_COD: String

CINF_TIP: String

CINF_PER: String

DINF_INIINF: Datetime

DINF_FININF: Datetime

CINF_EST: String

CINF_INDVIG: String

CINF_USUCRE2: String

DINF_FECCRE: Datetime

CINF_USUMOD: String

CINF_USUCRE: String

DINF_FECMOD: Datetime

FORMATO

NINF_ID: Number (FK)

NFOR_ID: Number

CFOR_TIP: String

CFOR_EST: String

CFOR_INDVIG: String

CFOR_USUCRE: String

DFOR_FECCRE: Datetime

CFOR_USUMOD: String

DFOR_FECMOD: Datetime

TABLATIPO

NTTI_ID: Number

CTTI_CODTAB: String

CTTI_CODTIP: String

CTTI_DESTIP: String

CTTI_DSCTIP: String

CTTI_INDVIG: String


Página 9 de 11

6.2 Modelo Entidad-Relación Físico {Descripción del Modelo Físico} [Incluir el modelo de datos físico. Considerar la separación en vistas de tal manera que el modelo pueda verse. El modelo de datos debe estar graficado en la notación Information Engineering]

Modelo de datos físico

6.3 Diccionario de Datos

6.3.1 Listado de Tablas

[En la siguiente tabla colocar las tablas y el módulo al que pertenecen dentro del sistema (esto si se dividió en módulos). Ordenar las tablas por módulo.]

Item Nombre tabla Módulo Sistema

1

2

3

4

5

6

7

FK_SRC_AGRUP_OBLIG

FK_SRC_INFORME

FK_SRC_AGRUP_OBLIG

SRC_COD_INFORME

CCIN_CODENT: CHAR(4) NOT NULL

NCIN_ID: INTEGER NOT NULL

NCIN_CODIRC: INTEGER NOT NULL

SRC_INFORME

NINF_ID: NUMBER NOT NULL

CINF_CODENT: CHAR(4) NOT NULL

CINF_COD: VARCHAR2(30) NOT NULL

CINF_TIP: VARCHAR2(3) NOT NULL

CINF_INDPER: VARCHAR2(3) NOT NULL

DINF_INIINF: DATE NOT NULL

DINF_FININF: DATE NOT NULL

CINF_EST: VARCHAR2(3) NOT NULL

CINF_INDVIG: VARCHAR2(1) NOT NULL

CINF_USUCRE: VARCHAR2(30) NOT NULL

DINF_FECCRE: DATE NOT NULL

CINF_USUMOD: VARCHAR2(30) NULL

DINF_FECMOD: DATE NULL

SRC_FORMATO

NINF_ID: NUMBER NOT NULL (FK)

NFOR_ID: NUMBER NOT NULL

CFOR_TIP: VARCHAR2(3) NOT NULL

CFOR_EST: VARCHAR2(3) NOT NULL

CFOR_INDVIG: VARCHAR2(1) NOT NULL

CFOR_USUCRE: VARCHAR2(30) NOT NULL

DFOR_FECCRE: DATE NOT NULL

CFOR_USUMOD: VARCHAR2(30) NULL

DFOR_FECMOD: DATE NULL

SRC_TAB_TIP

NTTI_ID: INTEGER NOT NULL

CTTI_CODTAB: VARCHAR2(3) NOT NULL

CTTI_CODTIP: VARCHAR2(3) NOT NULL

CTTI_DESTIP: VARCHAR2(100) NOT NULL

CTTI_DSCTIP: VARCHAR2(20) NULL

CTTI_INDVIG: VARCHAR2(1) NOT NULL

SRC_ENT_OBLIG

NENO_ID: NUMBER NOT NULL

NENO_IDAGRU: INTEGER NOT NULL (FK)

CENO_CODENT: CHAR(4) NOT NULL

CENO_INDVIG: VARCHAR2(1) NOT NULL

SRC_AGRUP_OBLIG

NAGO_ID: INTEGER NOT NULL

CAGO_NOMAGP: VARCHAR2(50) NOT NULL

CAGO_DESAGP: VARCHAR2(100) NULL

CAGO_INDVIG: VARCHAR2(1) NOT NULL

SRC_FOR_OBLIG

CFOO_TIPFOR: VARCHAR2(3) NOT NULL

NAGO_ID: INTEGER NOT NULL (FK)

CFOO_INDVIG: VARCHAR2(1) NOT NULL


Página 10 de 11

8

9

10

6.3.2 Descripción de tablas y campos

[Repetir el siguiente cuadro por cada tabla. Las tablas deberán presentarse en el orden en el que aparecen en el listado de la sección anterior.]

Tabla

Descripción

Definición de Campos

Ítem Campo Tipo de Dato Descripción Nulo PK FK

1 {Sí/ No}

{Sí/No}

{Sí/ No}

2

3

4

5

Definición de Índices

Ítem Índice Campos

1 {Ingresar los campos que conforman el índice en orden:

Campo1, campo2, campo3}

2

3

4

6.3.3 Listado de Objetos Complementarios de Base de Datos

[Indicar la relación de objetos de base de datos que complementan a las tablas a utilizar, tales como Store Procedures, Funciones, Secuencias.]

Ítem Objeto Tipo Módulo

1 {Nombre del objeto}

{Store Procedure, Function, Sequence}

{Módulo del sistema}

2

3

4

5


Página 11 de 11

77 AANNEEXXOOSS [Sólo si el documento lo requiera, se adjuntarán los anexos.]




ARQUITECTURA DEL SOFTWARE {NOMBRE SISTEMA}

{Versión n.n.n}


ARQUITECTURA DE SOFTWARE { NOMBRE SISTEMA }

Página 2 de 12




1 {dd/mm/aaaa} {n.n.n} {Nombre del equipo}

{Nombre del autor}

{Describir los cambios realizados en el documento}

{Responsable del responsable de revisión y/o aprobación}


Página 3 de 12

TABLA DE CONTENIDOS

1 INTRODUCCIÓN ............................................................................................................................ 4


2 REPRESENTACIÓN DE LA ARQUITECTURA ............................................................................ 4

3 VISTAS DE CASOS DE USO ........................................................................................................ 5

3.1 Listado de Casos de Uso más significativos del Sistema ...................................................... 6

4 VISTA LÓGICA .............................................................................................................................. 6

5 VISTA DE IMPLEMENTACIÓN ..................................................................................................... 6

6 VISTA DE PROCESOS .................................................................................................................. 7

7 VISTA DE DESPLIEGUE ............................................................................................................... 8

8 VISTA DE DATOS ........................................................................................................................ 10

8.1 Paquetes .............................................................................................................................. 10 8.2 Funciones ............................................................................................................................. 10 8.3 Procedimientos .................................................................................................................... 11 8.4 Triggers ................................................................................................................................ 11 8.5 Tablas ................................................................................................................................... 11

8.5.1 Volumen Estimado de Tablas .......................................................................................... 11 8.6 Vistas .................................................................................................................................... 11 8.7 Secuenciadores ................................................................................................................... 11 8.8 Jobs ...................................................................................................................................... 12


Página 4 de 12

11 IINNTTRROODDUUCCCCIIÓÓNN [La introducción brinda una vista rápida de todo el documento. Da una idea general del contenido del documento así como algunos alcances generales. Incluye el objetivo, alcance, definiciones, abreviaturas utilizadas en el documento.]

1.1 Objetivo [Indicar el objetivo del documento respecto al sistema en desarrollo.]



22 RREEPPRREESSEENNTTAACCIIÓÓNN DDEE LLAA AARRQQUUIITTEECCTTUURRAA [Para los desarrollos orientados a objetos, la representación de la arquitectura será representada de acuerdo a la arquitectura 4+“1”, puede tomarse como base el siguiente texto. De lo contrario explicar la manera en que se representará la arquitectura, y los diagramas que se incluirán.] El documento se ha estructurado empleando la representación de la arquitectura de acuerdo con la arquitectura de 4 + “1” vistas propuestas por IBM Rational.

Arquitectura 4 + "1"

La representación se realizará a fin de mostrar diferentes perspectivas del producto software, empleando las vistas siguientes:


Página 5 de 12

Perspectiva Funcional – Vista de Casos de Usos. Presenta la arquitectura desde la perspectiva del usuario final. Esta vista se desarrolla a través del Modelo de Casos de Usos (usando Diagramas de Casos de Uso de UML). Perspectiva Estructural – Vista Lógica. Presenta la arquitectura desde la perspectiva del analista/diseñador. Permite mostrar la organización de las piezas fundamentales de la arquitectura, organizando los elementos de diseño mediante módulos, paquetes, clases y niveles lógicos dentro de la solución. Perspectiva de Construcción – Vista de Implementación. Presenta la arquitectura desde la perspectiva del programador, definiendo los componentes software a ser desarrollados. Perspectiva Dinámica – Vista de los Procesos / Tareas. Presenta la arquitectura desde la perspectiva del integrador de sistemas a fin de definir aspectos de concurrencia, comunicación ínter procesos, sincronizaciones, etc. Perspectiva del Despliegue – Vista de Despliegue. Presenta la arquitectura desde la perspectiva del implantador de la solución. Define como los componentes de la arquitectura serán desplegados sobre la infraestructura de TI definida. Perspectiva de los Datos – Vista de Datos. Presenta la arquitectura de datos que soportará los requerimientos de información del sistema software. Se emplea el Modelo Entidad Relación.

33 VVIISSTTAASS DDEE CCAASSOOSS DDEE UUSSOO La presente vista, está orientada a mostrar el modelo de casos de uso del sistema, basados en los requerimientos funcionales. Se incluyen los casos de uso más significativos para la arquitectura.

Diagrama de casos de uso más significativos del sistema


Página 6 de 12

3.1 Listado de Casos de Uso más significativos del Sistema

Nombre del Caso de Uso Descripción

CUSXXX {Nombre del caso de uso} {Descripción breve del caso de uso}

…. …

44 VVIISSTTAA LLÓÓGGIICCAA Se describe a continuación la organización del sistema en paquetes o módulos así como la organización de cada módulo por capas. La organización por capas es la siguiente:

La capa de persistencia es representada por el paquete dao y domain.

La capa de negocio es representada por el paquete service.

La capa de presentación es representada por el paquete view. A continuación se muestra la distribución lógica del sistema por paquetes: [Reemplazar el siguiente gráfico por el que corresponda a la organización del sistema.]

Diagrama de paquetes del sistema

Por cada paquete se mostrará cómo está dividido cada paquete en sub paquetes y clases. [Por cada paquete incluir diagrama donde se muestre la estructura interna de sub paquetes y clases de diseño más representativas del sistema. Para que los diagramas no crezcan demasiado evitar mostrar los atributos y operaciones.]

55 VVIISSTTAA DDEE IIMMPPLLEEMMEENNTTAACCIIÓÓNN La vista de implementación muestra el empaquetado físico del sistema en unidades reutilizables denominadas componentes. Un componente es una unidad física de implementación con interfaces definidas pensadas como unidades reutilizables del sistema. Cada componente implementa una o más clases del diseño. A continuación se presenta el diagrama de componentes del sistema. [Se deberá incluir un diagrama de componentes UML que contenga los componentes del sistema, además deberá incluirse componentes externos con los que se interactúe.] [Reemplazar el siguiente gráfico por el que corresponda a la organización del sistema.]


Página 7 de 12

Diagrama de componentes del sistema

Ítem Nombre del componente Descripción del componente

1 {Incluir los nombres de los componentes mostrados en el gráfico superior}

{Breve descripción de los componentes del gráfico}

2

3

66 VVIISSTTAA DDEE PPRROOCCEESSOOSS Esta sección describe la descomposición del sistema en procesos que se comunican e interactúan. A continuación se listan los procesos que se contemplan dentro del sistema, cada uno representado por una clase de control. [Incluir el diagrama correspondiente donde se indiquen los procesos en los que se divide el sistema, dar una breve explicación de los procesos involucrados.] [Reemplazar el siguiente gráfico por el que corresponda a la organización del sistema.]


Página 8 de 12

Diagrama de procesos del sistema

77 VVIISSTTAA DDEE DDEESSPPLLIIEEGGUUEE La vista de despliegue modela la distribución física de los procesos a través de un conjunto de nodos en el sistema, incluyendo la distribución física de los procesos e hilos. Un nodo es un objeto físico de ejecución que representa un recurso computacional. Puede tener estereotipos (UCP, memorias, discos, etc.). Las asociaciones entre nodos se grafican mediante líneas de asociación. [Insertar el diagrama correspondiente, mostrando los nodos y sus relaciones. Colocar una breve descripción del diagrama.] [Reemplazar el siguiente gráfico por el que corresponda a la organización del sistema.]


Página 9 de 12

RED PRIVADAINTERNET

Sede Central

Usuarios en

General

Red De la Institución

Gobiernos

Locales

Direcciones Zonales

Servidor Internet

Servidor de

Dominio

Otra Institución

Gubernamental

Otra Institución

Gubernamental

Topología del Sistema

Servidor de

Base de Datos

Servidor de

Correo ElectrónicoServidor de Archivos

Servidor Proxy Servidor de Aplicaciones

Diagrama de despliegue del sistema


Página 10 de 12

88 VVIISSTTAA DDEE DDAATTOOSS

La vista de datos proporciona información de los objetos de base de datos utilizados en el sistema y que son significativamente más importantes, entre ellos tablas, procedimientos almacenados y funciones. A continuación se muestra el modelo físico de datos del sistema. [Reemplazar el siguiente gráfico por el que corresponda a la organización del sistema.]

Modelo físico de datos

A continuación se muestra una lista con los objetos de base de datos necesarios para este sistema. [Deberá indicarse el esquema de base de datos donde se encuentran estos objetos. Sólo incluir las secciones que correspondan.]

8.1 Paquetes

Ítem Nombre del paquete Descripción

1

2

3

8.2 Funciones

Ítem Nombre de la función Paquete Descripción

1

2

3

FK_SRC_AGRUP_OBLIG

FK_SRC_INFORME

FK_SRC_AGRUP_OBLIG

SRC_COD_INFORME

CCIN_CODENT: CHAR(4) NOT NULL

NCIN_ID: INTEGER NOT NULL

NCIN_CODIRC: INTEGER NOT NULL

SRC_INFORME

NINF_ID: NUMBER NOT NULL

CINF_CODENT: CHAR(4) NOT NULL

CINF_COD: VARCHAR2(30) NOT NULL

CINF_TIP: VARCHAR2(3) NOT NULL

CINF_INDPER: VARCHAR2(3) NOT NULL

DINF_INIINF: DATE NOT NULL

DINF_FININF: DATE NOT NULL

CINF_EST: VARCHAR2(3) NOT NULL

CINF_INDVIG: VARCHAR2(1) NOT NULL

CINF_USUCRE: VARCHAR2(30) NOT NULL

DINF_FECCRE: DATE NOT NULL

CINF_USUMOD: VARCHAR2(30) NULL

DINF_FECMOD: DATE NULL

SRC_FORMATO

NINF_ID: NUMBER NOT NULL (FK)

NFOR_ID: NUMBER NOT NULL

CFOR_TIP: VARCHAR2(3) NOT NULL

CFOR_EST: VARCHAR2(3) NOT NULL

CFOR_INDVIG: VARCHAR2(1) NOT NULL

CFOR_USUCRE: VARCHAR2(30) NOT NULL

DFOR_FECCRE: DATE NOT NULL

CFOR_USUMOD: VARCHAR2(30) NULL

DFOR_FECMOD: DATE NULL

SRC_TAB_TIP

NTTI_ID: INTEGER NOT NULL

CTTI_CODTAB: VARCHAR2(3) NOT NULL

CTTI_CODTIP: VARCHAR2(3) NOT NULL

CTTI_DESTIP: VARCHAR2(100) NOT NULL

CTTI_DSCTIP: VARCHAR2(20) NULL

CTTI_INDVIG: VARCHAR2(1) NOT NULL

SRC_ENT_OBLIG

NENO_ID: NUMBER NOT NULL

NENO_IDAGRU: INTEGER NOT NULL (FK)

CENO_CODENT: CHAR(4) NOT NULL

CENO_INDVIG: VARCHAR2(1) NOT NULL

SRC_AGRUP_OBLIG

NAGO_ID: INTEGER NOT NULL

CAGO_NOMAGP: VARCHAR2(50) NOT NULL

CAGO_DESAGP: VARCHAR2(100) NULL

CAGO_INDVIG: VARCHAR2(1) NOT NULL

SRC_FOR_OBLIG

CFOO_TIPFOR: VARCHAR2(3) NOT NULL

NAGO_ID: INTEGER NOT NULL (FK)

CFOO_INDVIG: VARCHAR2(1) NOT NULL


Página 11 de 12

8.3 Procedimientos

Ítem Nombre del procedimiento Paquete Descripción

1

2

3

8.4 Triggers

Ítem Nombre del Trigger Tabla Descripción

1

2

3

8.5 Tablas

Ítem Nombre de tabla Descripción

1

2

3

8.5.1 Volumen Estimado de Tablas

Ítem Tabla

Tamaño por

Registro (bytes)

Cantidad inicial de registros

Tamaño inicial (bytes)

Cantidad estimada de registros en

{tiempo}

Tamaño proyectado en {tiempo}

(bytes)

1

2

3

8.6 Vistas

Ítem Nombre de vista Descripción

1

2

3

8.7 Secuenciadores

Ítem Nombre del secuenciador Tabla Campo

1

2

3


Página 12 de 12

8.8 Jobs

Ítem Nombre del Job Descripción

1

2

3

[Si hubiera otros objetos de base de datos involucrados, señalarlos.]




GLOSARIO {NOMBRE SISTEMA}

{Versión n.n.n}


GLOSARIO DE TÉRMINOS { NOMBRE SISTEMA }

Página 2 de 4


Ítem Fecha Versión Equipo Autor Descripción Responsable

de revisión y/o aprobación







Página 3 de 4

TABLA DE CONTENIDOS

1 INTRODUCCIÓN ............................................................................................................................ 4

1.1 Objetivo .................................................................................................................................. 4 1.2 Alcance ................................................................................................................................... 4

2 GLOSARIO ..................................................................................................................................... 4


Página 4 de 4

11 IINNTTRROODDUUCCCCIIÓÓNN [La introducción brinda una vista rápida de todo el documento. Incluye el objetivo, alcance, definiciones, abreviaturas utilizadas en el documento.]

1.1 Objetivo [Indicar el objetivo del documento en relación con el sistema desarrollado.]


22 GGLLOOSSAARRIIOO [Esta sección brinda la definición de aquellos términos y abreviaciones requeridas para interpretar adecuadamente el contenido de los documentos de sistemas.] [Incluir la lista de términos en orden alfabético. Resaltar el término que se va a definir en negrita.]

Término Definición




PLAN DE PRUEBAS {NOMBRE SISTEMA}

{Versión n.n.n}


PLAN DE PRUEBAS { NOMBRE SISTEMA }

Página 2 de 9






{Descripción de los

cambios en el documento}




Página 3 de 9

TABLA DE CONTENIDOS

1 INTRODUCCIÓN ............................................................................................................................ 4


2 PARTICIPANTES Y ROLES .......................................................................................................... 4

2.1 Personal necesario ................................................................................................................ 4 2.2 Equipo y necesidades de entrenamiento ............................................................................... 4

3 ACTIVIDADES PRINCIPALES ...................................................................................................... 4

3.1 Revisión del ambiente de pruebas ......................................................................................... 4 3.2 Solicitud de Recursos ............................................................................................................ 5 3.3 Documentación de las pruebas ............................................................................................. 5 3.4 Preparación de los casos de prueba ..................................................................................... 5 3.5 Elaboración del cronograma de ejecución de pruebas .......................................................... 6 3.6 Solicitar accesos y permisos para la prueba ......................................................................... 6 3.7 Inicio de las pruebas .............................................................................................................. 6

4 ENTREGABLES ............................................................................................................................. 6

4.1 Relación de entregables ........................................................................................................ 6 4.2 Evaluación de entregables ..................................................................................................... 7 4.3 Especificación de Casos de Prueba ...................................................................................... 8

5 APROBACIÓN DE LAS PRUEBAS .............................................................................................. 9


Página 4 de 9


1.1 Objetivo [Indicar el objetivo del documento respecto al sistema en desarrollo.]

1.2 Alcance [Una breve descripción del alcance de este documento y qué otros documentos se ven afectados por éste. Este plan debe ser elaborado por el Analista de Pruebas en colaboración con el Jefe del Proyecto para considerar todos los niveles de pruebas necesarios para asegurar el buen funcionamiento de los sistemas en producción, listar simplemente los tipos de pruebas o áreas de riesgos de calidad que serán cubiertas por este plan. Producto de esta planificación, se debe elaborar un cronograma de la disciplina de pruebas que formará parte del plan general de administración del proyecto. El Jefe del Proyecto y el Analista de Pruebas, encargado de la prueba, son los responsables de que todas las actividades programadas, se lleven a cabo según lo especificado.]

1.3 Definiciones y abreviaciones [Esta sección brinda la definición de aquellos términos y abreviaciones requeridos para interpretar adecuadamente el contenido de este documento. Esta información debería ser provista en un glosario del documento y aquí únicamente hacer referencia a dicho documento.]

22 PPAARRTTIICCIIPPAANNTTEESS YY RROOLLEESS

2.1 Personal necesario

Nro.

Usuario asignado

Rol Responsabilidades específicas

1. [Nombres y Apellidos de Usuario 1.] [• Rol 1. • Rol 2]

2. [Nombres y Apellidos de Usuario 2.] [• Rol 2.]

2.2 Equipo y necesidades de entrenamiento [En esta sección definir cómo enfocar la conformación del equipo y el entrenamiento de los roles de prueba del proyecto, indicar tiempo necesario de entrenamiento por cada rol identificado.]

33 AACCTTIIVVIIDDAADDEESS PPRRIINNCCIIPPAALLEESS

3.1 Revisión del ambiente de pruebas [Este tipo de revisiones deben ser previas a las coordinaciones con los usuarios antes que se inicien las pruebas en el ambiente de pruebas.


Página 5 de 9

En esta actividad el Jefe del Proyecto y/ó encargado de la prueba apoyado por el Equipo de Desarrollo del Programa o Equipo de Desarrollo del Proveedor, deben identificar los caso de uso, módulos y componentes del software que se desea probar y las características de Hardware y Software de base que se necesita. Debe coordinar con el Equipo de Desarrollo, para conseguir los elementos del ambiente requeridos para el buen desarrollo de la prueba (Espacios en disco, horarios adecuados, servidores de respaldo, líneas dedicadas, equipos móviles etc.) y comportamiento del software en el entorno de la red (Procesos diarios, eventuales, en línea o Bach, tiempos de respuesta etc.)]

3.2 Solicitud de Recursos [En esta actividad el Jefe del Proyecto y/ó encargado de las pruebas, basándose en los puntos anteriormente definidos, debe efectuar las gestiones necesarias ante la Unidad de Sistemas y áreas usuarias correspondientes, a fin de asegurar la participación de los recursos humanos y materiales requeridos:

Para el equipo funcional, con el Líder Funcional (Usuario) o la jefatura usuaria correspondiente.

Para el equipo de desarrollo con el jefe del proyecto.

Para los recursos de equipamiento, con la Unidad de Sistemas.]

3.3 Documentación de las pruebas [En esta actividad se debe documentar todas las condiciones y características que presenta la prueba:

Condiciones especiales del Hardware y Software utilizado.

Principales módulos a probar.

Características especiales de cada módulo.

Responsable de cada caso de uso ó módulo a probar y nivel de la pruebas.

Resultados previstos por cada caso de uso ó módulo.

Consideraciones de seguridad y performance.]

3.4 Preparación de los casos de prueba [En esta actividad, se debe preparar un set completo de pruebas para cada caso de uso identificado, considerando los ciclos de prueba definidos anteriormente y el nivel de la prueba que se desea realizar. Esta actividad es de responsabilidad del equipo usuario, quienes estarán permanentemente apoyados por el equipo de desarrollo Todos los casos de pruebas y los datos de estas, deben estar escritos en el entregable: Especificación de Caso de Prueba. Asimismo, en esta actividad se debe definir los ciclos de prueba que se prevé realizar y sus requerimientos de control y acceso. Se recomienda que el ciclo de pruebas tenga un máximo de 3 iteraciones; si la prueba arroja un resultado negativo a la tercera iteración y se encuentra dentro del alcance definido, se debe devolver al equipo de desarrollo para su revisión respectiva.]


Página 6 de 9

3.5 Elaboración del cronograma de ejecución de pruebas [En esta actividad, el Jefe del Proyecto y/ó encargado de la prueba, debe elaborar un programa detallado de trabajo donde se refleje cada una de las actividades identificadas, relacionando la persona asignada para realizar esta labor, la fecha de inicio y la duración de cada una de las actividades. Asimismo, se debe definir la secuencia de actividades, cuáles son predecesoras, cuáles son sucesoras y cuáles se pueden ejecutar en paralelo. Esta actividad debe terminar con la generación de un cronograma del proceso de pruebas y hacerlo del conocimiento a todos los involucrados en el proyecto.]

3.6 Solicitar accesos y permisos para la prueba [Días antes de la fecha designada para las pruebas, el Jefe del Proyecto apoyado por el Líder usuario, debe gestionar con las áreas usuarias las facilidades y permisos para cada uno de los participantes. El responsable debe asegurarse de contar con estas facilidades antes de iniciar sus pruebas, de lo contrario deberá reportarlo a las instancias necesarias para asegurar el éxito de la prueba:

Accesos a las oficinas donde se efectuara la prueba para cada uno de los participantes.

Accesos y claves de usuario para los sistemas involucrados o relacionados.

Permiso para el ingreso de equipos adicionales no pertenecientes a la oficina donde se realizará la prueba (si fuera el caso).]

3.7 Inicio de las pruebas [El día designado para la prueba, una hora antes del inicio, el Analista de Pruebas debe reunir a todos los participantes al evento y proporcionarles los elementos e información necesarios para el cumplimiento de la función para la que han sido convocados:

Claves de acceso a los equipos

Acceso a los sistemas de acuerdo al nivel requerido

Set de casos de pruebas

Relación de módulos a probar

Otros]

44 EENNTTRREEGGAABBLLEESS

4.1 Relación de entregables [Durante las Pruebas, se deben presentar los siguientes entregables: Ver el siguiente ejemplo]

Entregables Descripción Responsables

Plan de Pruebas Actividades y recursos requeridos para realizar las pruebas formales.

Unidad de Sistemas

CheckList de los casos de pruebas que pasaran a las pruebas de usuario firmados por el desarrollador.

Lista de casos de pruebas probados por los Analistas Programadores.

Equipo implementador.

Versión Congelada de las fuentes. Fuentes del Sistema informático. Equipo implementador

Acta de conformidad de la usabilidad de la totalidad

Documento en el que se acepta la usabilidad del sistema.

Equipo implementador y Usuario Líder


Página 7 de 9

interfaces, con el VºBº del usuario.

Acta de Capacitación. Documento empleado para realizar la capacitación.

Equipo implementador

Manual de Instalación Documento empleado para realizar la instalación del sistema.

Equipo implementador

Informe de Pruebas Técnicas Documento que informa el resultado de las pruebas técnicas que incluyen la revisión del código fuente (aplicativo y script de BD) y el resultado obtenido.

Unidad de Sistemas

Informe de Pruebas Funcionales Documento que resume las actividades de las pruebas funcionales por parte de los usuarios seleccionados y el resultado obtenido.

Equipo implementador y Usuario Líder

4.2 Evaluación de entregables [Proporcionar una definición tanto de la forma como el contenido de los reportes usados para medir la calidad percibida del producto e imprimir tantos como sean necesarios para su revisión. Se debe de incluir un análisis de las Incidencias y Peticiones de Cambios sobre la Cobertura de las Pruebas.]


Página 8 de 9

4.3 Especificación de Casos de Prueba [A continuación se muestra un ejemplo de caso de prueba, agregar según el número de casos de prueba definidos, por lo general un caso de prueba por caso de uso de sistema. Ejemplo de caso de prueba:]

Proyecto [Nombre del Proyecto] Caso de prueba [Nombre del Caso de Uso del Sistema]

Sistema / Módulo

[Nombre del Sistema / Módulo] Fecha de ejecución: dd/mm/aaaa CP Nro: 01

Paso Descripción del Paso Resultados Esperados

1 [Consultar “Listado de Proyectos en General”] El sistema realiza la búsqueda en la base de datos y retorna los registros que coinciden con el criterio de búsqueda, agrupados en listas de 100 registros, con un link en número de expediente

2 [Consultar “Listado de Proyectos – Avance Físico”] El sistema realiza la búsqueda en la base de datos y retorna los registros que coinciden con el criterio de búsqueda, agrupados en listas de 20 registros

3 [Opción “Listado de Proyectos Avance Financiero”] El sistema realiza la búsqueda en la base de datos y retorna los registros que coinciden con el criterio de búsqueda, agrupados en listas de 20 registros.

4 [Consultar “Listado de Proyectos – Avance Estado del Proyecto”]

El sistema realiza la búsqueda en la base de datos y retorna los registros que coinciden con el criterio de búsqueda, agrupados en listas de 20 registros.

5 [Consultar “Listado de Proyectos – Alertas”] El sistema realiza la búsqueda en la base de datos y retorna los registros que coinciden con el criterio de búsqueda, agrupados en listas de 20 registros.

6 [Consulta “Listado de Proyectos – Consolidados”] El sistema realiza la búsqueda en la base de datos y retorna los registros que coinciden con el criterio de búsqueda, agrupados, mostrara información consolidada de la información, con sus respectivos detalles.


Página 9 de 9

55 AAPPRROOBBAACCIIÓÓNN DDEE LLAASS PPRRUUEEBBAASS El Jefe del Proyecto, Analista de Pruebas, Líder Funcional (usuario) y el Responsable Usuario deben registrar su nombre y firma en los siguientes documentos de aprobación en señal de conformidad:

Acta de Pruebas del Software (Unitarias y/ó Integrales).

Especificación de Casos de Prueba.

Informe de Pruebas.




INFORME DE PRUEBAS {NOMBRE SISTEMA}

{Versión n.n.n}


INFORME DE PRUEBAS { NOMBRE SISTEMA }

Página 2 de 5










Página 3 de 5

TABLA DE CONTENIDOS

1 INTRODUCCIÓN ............................................................................................................................ 4


2 PRUEBAS EJECUTADAS ............................................................................................................. 4

2.1 Personal asignado ................................................................................................................. 4 2.2 Acta de pruebas de software ................................................................................................. 5


Página 4 de 5


1.1 Objetivo [Indicar el objetivo del documento.]

1.2 Alcance [Una breve descripción del alcance de este documento y qué otros documentos se ven afectados por éste.]


22 PPRRUUEEBBAASS EEJJEECCUUTTAADDAASS

2.1 Personal asignado

Nro.

Caso de Prueba

Rol Usuario asignado

1. [Caso de Prueba 1: CUS Login] [• Rol 1.] [• Usuario 1. • Usuario 2.]

2. [Caso de Prueba 2: CUS Registro de formato A] [• Rol 2.] [• Usuario 3.]


Página 5 de 5

2.2 Acta de pruebas de software

Nombre del Caso de Prueba

[Nombre del Caso de Uso del Sistema] Nro. De Caso de Prueba CP Nro: 1

Nro./Descripción del Paso

Errores encontrados Mejoras Funcionalidad

Ampliada

Fecha de Cumplimiento/Corrección Prioridad Estado

[CP-01 / Paso 2] [Describir los errores de funcionalidad]

[Describir si es funcionalidad mejorada]

[Describir si es funcionalidad ampliada]

dd/mm/aaaa Alta AP

Media PP

Baja CA

Estado de las Pruebas: 1. (AP) Aprobado. 2. (PP) Pendiente de prueba. 3. (CA) Cancelado. 4. (PC) Pendiente de corrección Prioridad: Alta, Media, Baja. Firmantes: _______________________________ __________________________________ [Nombres y apellidos de/los usuario(s) que intervienen en la prueba] [Nombres y apellidos de Unidad de Sistemas o Proveedor]

MINISTERIO DE TRABAJO Y PROMOCIÓN DEL EMPLEO ...

Documents

Transcript of MINISTERIO DE TRABAJO Y PROMOCIÓN DEL EMPLEO ...