metodologia desarrollo de sistemas de información version firmada digitalmente

MINISTERIO DE CULTURA Y JUVENTUD

DIRECCION GENERAL DE ARCHIVO NACIONAL

DEPARTAMENTO DE TECNOLOGÍA DE LA INFORMACIÓN

SISTEMAS DE INFORMACION INSTITUCIONAL

METODOLOGÍA

DESARROLLO DE SISTEMAS DE INFORMACIÓN

“Ocuparse de lo fácil

cuando se tienen bríos para hacer lo difícil,

es como despojar de la

dignidad al talento”

José Martí

ELABORADO POR:

ING. PETRONILA MAIRENA TRAÑA, MCI

MINISTERIO DE CULTURA Y JUVENTUD DIRECCIÓN GENERAL DEL ARCHIVO NACIONAL

PÁGINA 2 DE 80

VERSIÓN 1.1

METODOLOGIA DE DESARROLLO DE SISTEMAS DE INFORMACION OCTUBRE 2014

_______________________________________________________________________________________Metodología de Desarrollo de Sistemas de Información Por: Petronila Mairena Traña Página 2 de 80

Tabla de Contenidos

1. Introducción ............................................................................................................................. 5

2. Objetivo ................................................................................................................................... 6

3. Procedimientos relacionados ................................................................................................... 6

4. Responsables .......................................................................................................................... 6

5. Metodología para el Desarrollo de Sistemas de Información ................................................... 8

Etapas o Fases de la Metodología ............................................................................................ 10

1) LEVANTAMIENTO DE NECESIDADES Y/O SOLICITUD DEL SISTEMA BASADO EN EL

MAI-DGAN ............................................................................................................................. 11

2) ESPECIFICACIÓN DE REQUERIMIENTOS .................................................................. 17

3) DESCRIPCION DETALLADA DEL SISTEMA (PROTOTIPO DE INTERFAZ DE

USUARIO) ............................................................................................................................. 21

4) CODIFICACIÓN, DISEÑO Y PROGRAMACIÓN DEL SISTEMA .................................... 22

5) PRUEBAS Y ENTRENAMIENTO .................................................................................... 23

6) AJUSTES Y MODIFICACIONES .................................................................................... 23

7) IMPLANTACION Y LANZAMIENTO ............................................................................... 24

8) ENTREGABLES Y CIERRE DEL PROYECTO ............................................................... 25


PÁGINA 3 DE 80

VERSIÓN 1.1



6. Anexos o Instrumentos de la Metodología ............................................................................ 27

ANEXO #1: LEVANTAMIENTO DE NECESIDADES DE AUTOMATIZACION DE PROCESOS

.............................................................................................................................................. 28

ANEXO #2: MODELO DE ARQUITECTURA DE INFORMACIÓN MAI-DGAN ....................... 30

ANEXO #3: SOLICITUD DE SISTEMA DE INFORMACION .................................................. 32

ANEXO #4: BITACORA DE REUNION .................................................................................. 34

ANEXO #5: ANALISIS Y EVALUACION PRELIMINAR .......................................................... 36

ANEXO #6: ESPECIFICACION DE REQUERIMIENTOS ...................................................... 39

ANEXO #7: CRONOGRAMA DEL PROYECTO .................................................................... 58

ANEXO #9: PRUEBA DE ACEPTACION ............................................................................... 62

ANEXO #10: PLAN DE PRUEBAS TÉCNICAS ..................................................................... 64

ANEXO #11: PLAN DE SESION DE ENTRENAMIENTO ...................................................... 67

ANEXO #12: CONTROL DE CAMBIOS, VERSIONES Y BUGS ............................................ 70

ANEXO #13: MANUAL TÉCNICO DE INSTALACIÓN Y CONFIGURACIÓN ......................... 71

ANEXO #14: MANUAL DE USUARIO .................................................................................... 74

ANEXO #15: ACTA DE CIERRE Y ENTREGA DEL PROYECTO .......................................... 76

ANEXO #16: CONTROL DE CAMBIOS DEL PROYECTO .................................................... 78


PÁGINA 4 DE 80

VERSIÓN 1.1



ANEXO #17: MATRIZ DE RIESGOS DEL PROYECTO......................................................... 79

ANEXO #18: SOLICITUD DE CAMBIO EN EL SISTEMA DE INFORMACION ...................... 80


PÁGINA 5 DE 80

VERSIÓN 1.1



1. Introducción

El desarrollo de sistemas de información tanto interno, con funcionarios internos y externo, por

medio de contrataciones y servicios profesionales contratados; es un proceso que debe ser

regulado dentro de cualquier institución u organización; durante todo su ciclo de vida, para lograr

obtener un software de acuerdo a las necesidades reales de los usuarios y con la calidad esperada

tanto técnica como funcional.

Esta metodología pretende establecer una guía práctica basada en el ciclo de vida de desarrollo de

sistemas de información conjugados con algunos principios de la administración profesional de

Proyectos, necesaria para el adecuado control de todas las etapas del proceso de desarrollo de

sistemas de información y su mantenimiento, que ayuden a garantizar la integridad, confiabilidad,

oportunidad y seguridad de éstos.

Con la utilización de esta metodología, puede acortarse la brecha para garantizar un buen diseño

de los sistemas de información, su mantenimiento y un adecuado control del proceso de

desarrollo.

Una metodología estructurada, oficializada y divulgada en la institución, facilita en gran medida el

proceso de solicitud, análisis y diseño así como la programación, implantación y mantenimiento

del sistema durante su vida útil; además fortalece y posiciona el proceso de desarrollo de sistemas

de información institucional, garantizándole a los usuarios internos y externos de la Dirección

General del Archivo Nacional disponer de sistemas de información de alta calidad.


PÁGINA 6 DE 80

VERSIÓN 1.1



Las fases señaladas en esta metodología, así como los estándares de documentación que se

presentan se consideran estrictamente requeridos para el desarrollo de un sistema, bien sea con

personal interno o en aquellos casos en que se contrate a terceros para tales efectos.

2. Objetivo

Establecer una metodología de desarrollo de sistemas institucionales que sea estándar y permita

la solicitud, análisis, elaboración y diseño de sistemas de calidad y el control de todas las etapas

del desarrollo, pruebas, implementación y su posterior mantenimiento.

3. Procedimientos relacionados

Administración de Bases de Datos

Diseño Estándar de Bases de Datos del Archivo Nacional

Respaldos Institucionales

Plan de Contingencias

Desarrollo de Sistemas

Contraparte técnica de Proyectos Informáticos

4. Responsables

Usuario o Departamento Solicitante: Departamento, proceso o Usuario que solicita el desarrollo

de un Sistema.


PÁGINA 7 DE 80

VERSIÓN 1.1



Equipo del Proyecto: Grupo de funcionarios conformado por el Jefe del Departamento Solicitante

o quien éste designe, el grupo de usuarios involucrados en el proceso y el o los analistas de

sistemas designados para el proyecto.

Patrocinador del Proyecto: Es la máxima autoridad institucional quien provee, gestiona y

administra los recursos financieros necesarios para la ejecución del proyecto.

Líder del Proyecto: Es el Jefe del Departamento Solicitante o quien éste designe. Le corresponde la

toma de decisiones del planeamiento de las tareas a desarrollar durante el proyecto, convoca a

reuniones de seguimiento y sesiones de trabajo al Equipo. Trabaja en estrecha coordinación con

los analistas de sistemas y sus superiores.

Responsables del desarrollo: Departamento de Tecnología de la Información, Sistemas de

información, desarrolladores internos y terceros contratados responsables del desarrollo de

sistemas de información para la Dirección General del Archivo Nacional.

Responsables de administración y mantenimiento: Departamento de Tecnología de la

Información, Sistemas de información, desarrolladores internos y terceros contratados.

MAI-DGAN: Modelo de Arquitectura de la Información de la Dirección General del Archivo

Nacional. Este modelo es una representación gráfica que permita resumir y visualizar con suma

claridad los flujos de información y la forma en que interactúan los procesos institucionales a nivel

de datos.


PÁGINA 8 DE 80

VERSIÓN 1.1



5. Metodología para el Desarrollo de Sistemas de Información

La evolución de los Sistemas de Información, desde pequeñas aplicaciones que resolvían pequeños

problemas específicos y de cálculos que se instalaban en una computadora de escritorio, hasta los

sistemas transaccionales que incorporan las bases de datos integradas y distribuidas, los sistemas

web y los aplicativos para dispositivos móviles, ha ido en aumento según la demanda de servicios

que exigen los ciudadanos cada día. De ahí que tratando de conjugar el ciclo de vida de un sistema

de información y algunos de los principios básicos d

e la administración profesional de proyectos, a partir de una gestión institucional por procesos,

pueden considerarse ocho etapas.

Cada una de estas etapas, están diseñadas para un mejor control y seguimiento del desarrollo de

sistemas como un Proyecto, no pretende ser en ninguna medida un manual para el desarrollo sino

más bien una metodología para homologar el diseño y desarrollo de software como la ejecución

de un proyecto administrable partiendo del objetivo que es obtener un producto final.

De ahí que durante las fases descritas no se profundiza en el cómo y con qué herramientas o

programas de software se llevaran a cabo las mismas, esto es porque se parte del hecho que un

analista programador en su carrera base ha adquirido las destrezas y habilidades en el uso de

herramientas para construcción de las mismas, esta es la labor intelectual del analista

programador en la construcción de un software específico basado en una gestión institucional por

procesos.

A continuación las etapas o fases de la metodología:


PÁGINA 9 DE 80

VERSIÓN 1.1



INICIO PLANEACION EJECUCION CONTROL CIERRE

Especificación de Requerimientos

Descripción Detallada del Sistema (Prototipo)

Codificación / Diseño/ Programación

Pruebas y Entrenamiento

Ajustes y Modificaciones

Levantamiento de necesidades / solicitud

basado en el MAI-DGAN

Implantación y lanzamiento

Entregables y cierre

Ciclo de Vida de Sistemas

Administración Profesional de Proyectos


PÁGINA 10 DE 80

VERSIÓN 1.1



Etapas o Fases de la Metodología

1) Levantamiento de necesidades / Solicitud basado en el MAI-DGAN

2) Especificación de Requerimientos

3) Descripción Detallada del Sistema (Prototipo de Interfaz de Usuario)

4) Diseño y Programación

5) Pruebas y Entrenamiento

6) Ajustes y modificaciones

7) Implantación y Lanzamiento

8) Entregables y cierre del Proyecto


PÁGINA 11 DE 80

VERSIÓN 1.1



1) LEVANTAMIENTO DE NECESIDADES Y/O SOLICITUD DEL SISTEMA BASADO

EN EL MAI-DGAN

a. Levantamiento de Necesidades: El Departamento de Tecnología de la Información en

conjunto con las Autoridades del Archivo Nacional debe realizar un levantamiento de las

necesidades de información de los usuarios internos y externos basados en los procesos

institucionales; con el fin de priorizar la planificación y organización de los mismos de

acuerdo a los recursos materiales y de potencial humano disponibles.

Esto significa que los procesos institucionales deben estar mapeados de tal forma que

puedan establecerse todas las relaciones o integraciones de datos de los mismos; lo cual

servirá de soporte para el establecimiento de un modelo de arquitectura de información

institucional.

Para el caso de contrataciones externas, convenios de cooperación o apoyo de otras

instituciones u otros países, regirá el mismo principio, es decir, lo primero que debe

realizarse es el levantamiento de necesidades de automatización de uno o varios procesos

objeto del proyecto.

Ver Anexo 1: FORM1-Levantamiento de necesidades de automatización basada en

procesos.

b. Crear el Modelo de Arquitectura de Información del Archivo Nacional: El Modelo de

Arquitectura de la Información deberá establecer el diseño general de los sistemas de

información (no necesariamente ya automatizados), los datos y sus interrelaciones,

documentar un diccionario de datos del negocio (institucional) con su esquema de

clasificación, estableciendo criticidad, sensibilidad y propiedad de los datos. Finalmente

deberá establecer los controles de seguridad apropiados para cada una de las

clasificaciones.

Este modelo deberá estar debidamente documentado, tanto en forma narrativa como

mediante una representación gráfica que permita resumir y visualizar con suma claridad los


PÁGINA 12 DE 80

VERSIÓN 1.1



flujos de información y la forma en que interactúan los procesos institucionales a nivel de

datos. Deberá clasificar los datos a nivel institucional permitiendo identificar los

propietarios y responsables de los datos, catalogar los datos con base en su criticidad,

sensibilidad, multimedios y ubicación física. Deberá facilitar la determinación de los

privilegios de acceso de los usuarios, así como los requerimientos de respaldo y

disponibilidad, retención (tiempo de almacenamiento), desecho, y necesidad relativa de

cifrado (encripción). El modelo debe promover la seguridad informática en todos los

alcances pertinentes.

A partir del MAI actualizado será posible plantear los macro sistemas sustantivos y de

apoyo, así como los sistemas o soluciones adicionales que requiere la institución para

operar.

Este modelo será el insumo indispensable para que el Departamento de Tecnología de la

Información a través del Proceso de Sistemas de Información desarrolle una intensa

actividad tendiente a inventariar las necesidades de información, documentarlas y

confrontarlas contra los sistemas actuales, para luego identificar sistemas que requieren

modificaciones, así como nuevos sistemas a incluir dentro de un plan de sistemas o

portafolio de proyectos.

Es responsabilidad de los analistas de sistemas el crear el Modelo de Arquitectura de

Información a partir del levantamiento de necesidades basado en los procesos

institucionales que deben estar elaborados y mapeados de previo.

Cabe mencionar que como cada Departamento es responsable del levantamiento de sus

procesos y procedimientos, es necesario coordinar el traslado de los procesos diagramados

o mapeados al Departamento de Tecnología de la Información.

Ver Anexo 2: FORM2-Modelo de Arquitectura de Información DGAN.

c. Solicitud: Todo Departamento o Usuario que considera necesario automatizar algún

proceso, debe enviar una solicitud aprobada por las Autoridades del Archivo Nacional al

Departamento de Tecnología de la Información, a efectos de anticipar los recursos


PÁGINA 13 DE 80

VERSIÓN 1.1



humanos y económicos necesarios. Se debe adjuntar a esta solicitud el mapa del proceso y

su detalle así como el o los procedimientos involucrados y que se requieren automatizar.

Ver Anexo 3: FORM3- Solicitud de Sistema de Información.

El formulario debe ser completado minuciosamente y traer la aprobación del Jefe del

Departamento Solicitante y de la Dirección General del Archivo Nacional.

El formulario “Solicitud de Sistema de Información” debe considerar los siguientes

apartados:

Problema a resolver: Es muy importante tener bien claro y definido el problema; así que,

se debe preparar un enunciado del mismo, breve pero entendible, indicando además las

posibles restricciones que se podrían enfrentar durante el desarrollo de la solución.

Posteriormente, junto con el usuario se llegará a un enunciado definitivo del problema el

cual debe de incluir una descripción de la situación actual y de las metas que debe lograr el

nuevo sistema. La definición del problema requiere de un total entendimiento del

problema y de su entorno.

Justificación: Todo proyecto deberá contener una justificación donde se exprese por qué

se desea o necesita desarrollar el proyecto; así mismo, si la justificación se fundamenta en

el cumplimiento de legislación vigente, debe enumerarse y describirse toda la legislación.

Alcance: Aquí deben enumerarse los objetivos, los usuarios, servicios y procesos

involucrados y cuales ventajas se obtendrían en razón de tiempo, eficiencia y calidad del

servicio; cuales otros departamentos interactúan con el proceso involucrado; así como el

tiempo estimado de ejecución del proyecto.

Responsables del proyecto: Deben designarse cada una de las personas que estarán en

cada una de las fases del desarrollo del proyecto. Identificándose con su nombre completo,

cargo, correo electrónico, teléfono, disponibilidad de tiempo y rol a cumplir. El número de

personas involucradas debe estar en función con la magnitud o alcance del proyecto. Una

de ellas será el líder o coordinador del Proyecto, el cual debe ser el jefe del Departamento


PÁGINA 14 DE 80

VERSIÓN 1.1



Solicitante o quien este designe en sustitución, y será quien en conjunto con el personal de

Sistemas de Información que se designe, conformarán el equipo de trabajo.

Financiamiento: Un aspecto relevante en la toma de decisiones sobre la ejecución o no del

proyecto lo constituye la disponibilidad del presupuesto, por tal motivo deberá indicarse

claramente si se cuenta y en qué cantidad y el origen de los mismos en el caso de ser

contratado a terceros y si fue considerado en el presupuesto del plan operativo

institucional, su desarrollo e implementación.

Aclaración de la solicitud: La aclaración de la solicitud pretende proveer al Departamento

de Tecnología de la Información una clara definición del problema a resolver y de todos los

aspectos indicados en la solicitud del sistema; deberá ser llevada a cabo por un analista de

sistemas en extrema colaboración con el usuario solicitante u otro designado por el mismo,

una vez conformado el equipo de trabajo. Lo que se pretende es aclarar y ampliar si es

necesario, todos aquellos aspectos que así lo requieran, desde el punto de vista

informático y situacional. Para esta esta labor es necesaria una o varias sesiones de trabajo,

las cuales deben quedar documentadas y firmadas mediante una bitácora de reunión.

Ver Anexo 4: FORM4- Bitácora de reunión

Análisis Preliminar de la Solicitud: Como resultado de la solicitud y su posterior aclaración

se deberá presentar un documento, que contenga lo expuesto anteriormente, a la Jefatura

del Departamento de Tecnología de la Información, éste a su vez lo entregará a la

Coordinación de Sistemas de Información. Dicho documento contendrá los mismos

apartados de la solicitud misma, pero con las aclaraciones y ampliaciones necesarias para

su adecuada valoración por la Jefatura de la Departamento de Tecnología de la

Información, y deberá estar firmado tanto por el analista designado, como por el líder del

Proyecto o usuario del Departamento solicitante.

Este análisis preliminar deberá considerar:

1. Diagnóstico de la situación actual o problema a resolver: En este apartado se deberá

presentar el problema por resolver y las razones que lo justifican, se requiere una


PÁGINA 15 DE 80

VERSIÓN 1.1



definición clara del problema a resolver. Para abarcar este aspecto deberá basarse en

el resultado del Análisis y evaluación preliminar de la Solicitud.

2. Objetivos generales y específicos del sistema a desarrollar: Para todo proyecto de

sistemas deberá exponerse los propósitos deseados con la implementación del sistema,

estos se redactarán a modo de objetivos generales y específicos y estarán siempre

orientados a la solución del problema planteado en el apartado anterior, es decir,

deberán obedecer a las razones por las que se requiere del sistema. Evidentemente,

tales objetivos deberán estar en concordancia con los objetivos expresados en la

solicitud y el resultado del análisis preliminar de la solicitud.

3. Alcance del sistema: A fin de determinar el alcance del sistema se considerará la

información recopilada de la solicitud y su aclaración. Se deberán establecer los límites

entre el sistema y su ambiente externo, mediante el Diagrama de secuencia del sistema

(interoperabilidad con otros sistemas) y se indicarán los servicios (departamentos,

procesos de trabajo, servicios, otras instituciones) y documentos (fuentes de

información, otros sistemas) relacionados con el sistema.

4. Supuestos y restricciones del sistema: En este apartado se especificarán los supuestos

(condiciones, situaciones o estados del proyecto o de su entorno, que se asumen como

verdaderas para efectos de la planificación) y las restricciones (aquellas situaciones que

pueden limitar la solución que le podemos dar al problema que origina el proyecto).

El analista deberá asegurarse que los supuestos y restricciones del proyecto sean acordados con

los usuarios solicitantes, y que la documentación que de ellos se realiza en este apartado sea

suficientemente clara; pues los mismos serán determinantes en las etapas subsiguientes del

proyecto.


PÁGINA 16 DE 80

VERSIÓN 1.1



Este documento proporcionará la información necesaria para la primera toma de decisión

respecto a la realización del sistema y el momento oportuno para continuar con la siguiente fase,

en consideración de las prioridades institucionales y demás proyectos y recursos disponibles.

Ver Anexo 5: FORM5- Análisis y Evaluación Preliminar de la Solicitud

Punto de Control 1: Finalizada la fase de Solicitud de Sistema, el Jefe del Departamento de

Tecnología de la Información determinará la viabilidad del proyecto y el momento oportuno para iniciar,

en consideración de los recursos humanos disponibles para elaborar la etapa siguiente, otros proyectos

en desarrollo, la solicitud y el informe mismo de aclaración de la solicitud.

Deberá existir un expediente del Proyecto tanto físico como digital que contenga toda la documentación

generada del mismo en todas sus fases.

Para el caso del expediente digital, existirá una carpeta compartida con acceso a los analistas

correspondiente a la Cartera de Proyectos.

Para este punto deben existir los siguientes documentos en el expediente físico y digital:

1. FORM1-Levantamiento de necesidades de automatización basada en procesos

2. FORM2-Modelo de Arquitectura de Información DGAN.

3. FORM3- Solicitud de Sistema de Información

4. FORM4- Bitácora de reunión

5. FORM5- Análisis y Evaluación Preliminar de la Solicitud


PÁGINA 17 DE 80

VERSIÓN 1.1



2) ESPECIFICACIÓN DE REQUERIMIENTOS

Considerando los aspectos relevantes identificados en el Análisis Preliminar de la Solicitud y sobre

todo si la Jefatura del Departamento de Tecnología de la Información, aprueba o autoriza la

viabilidad y el momento oportuno para iniciar el proyecto; se procede con el levantamiento y

especificación de los requerimientos del sistema.

Se realizará mediante sesiones de trabajo o reuniones programadas con el equipo de trabajo en

pleno o bien identificándose el usuario o grupo de usuarios involucrados en el proceso objeto del

proyecto.

Estas reuniones o sesiones serán convocadas por el líder del proyecto a solicitud de los analistas

de sistemas y deberán ser documentadas utilizando el formulario de bitácora de reunión.

Al concluir esta especificación de requerimientos, el analista de sistemas generará un documento

técnico llamado Especificación de Requerimientos, confeccionado y firmado por él y firmado y

aprobado por los miembros del equipo de trabajo. Este documento incluirá los siguientes

apartados: Ver Anexo 6: FORM6- Especificación de Requerimientos

a. Carátula con el nombre del Proyecto, miembros del equipo de trabajo con su rol

respectivo: Es la primera página del documento.

b. Identificación de los módulos del Proyecto: Aquí se describirán de forma detallada, breve

y concisa cada uno de los módulos que tendrá el proyecto según el proceso que se

automatizará. Es importante mencionar que nunca deberán quedar por fuera los módulos

de Administración de la aplicación, Mantenimiento de Catálogos y Seguridad de la misma.

En el módulo de administración de la aplicación deberán quedar parametrizables todos

aquellos datos que así se requieran. El módulo de Mantenimiento de Catálogos deberá

considerar las opciones de agregar, modificar y eliminar registros de cada uno de los


PÁGINA 18 DE 80

VERSIÓN 1.1



catálogos del sistema. El módulo de Seguridad deberá permitir el cambio de contraseña y

el establecimiento de roles y permisos de usuarios para el caso del usuario Administrador

del Sistema.

c. Descripción de requerimientos funcionales y no funcionales del sistema: En este

apartado, se pretende identificar claramente los requisitos del sistema. Al desarrollar un

sistema, es de primordial importancia la definición de lo que se va a desarrollar, pues de la

claridad de la determinación de los requisitos depende la calidad del nuevo sistema. Se

entenderá por requerimiento funcional aquel que describe las funciones que los usuarios

serán capaces de realizar usando el nuevo sistema. Se entenderá por requerimiento no

funcional aquellos relacionados con las características del sistema que aplican de manera

general como un todo, más que a rasgos particulares del mismo, tales como desempeño,

disponibilidad, escalabilidad, flexibilidad, instalación, seguridad (control de acceso,

confidencialidad, bitácoras, pistas de auditoría, validación de información, respaldos, etc.),

arquitectura (interfaces, capas, integración, interoperabilidad, etc.), entre otros que se

considere necesarios.

d. Descripción y numeración de todos los casos de uso del Sistema: de entrada, salida y

procesamiento: Se debe describir en orden lógico e identificados en orden consecutivo,

todos y cada uno de los casos de uso del sistema por roles o perfiles de usuarios. Los casos

de uso deberán ser realizados en el siguiente formato:

e. Diagramas de los casos de Uso: Los diagramas de casos de uso documentan el

comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto los casos

de uso determinan los requisitos funcionales del sistema, es decir, representan las

funciones que un sistema puede ejecutar. Su ventaja principal es la facilidad para

interpretarlos, lo que hace que sean especialmente útiles en la comunicación con los


PÁGINA 19 DE 80

VERSIÓN 1.1



usuarios. Se deberán diagramar todos los casos de uso del sistema utilizando las

herramientas disponibles para hacerlos.

f. Diagrama de secuencia del sistema (interoperabilidad con otros sistemas): En un

diagrama de secuencia se indicarán los módulos o clases que forman parte del programa y

las llamadas que se hacen en cada uno de ellos para realizar una tarea determinada. Se

realizan diagramas de secuencia para definir acciones que se pueden realizar en la

aplicación en cuestión o bien sus interacciones con otras aplicaciones.

g. Diagrama Entidad-Relación: Es la representación grafica de las entidades y sus relaciones

en el Modelo de Bases de Datos del Sistema. Este diagrama mostrará todas las tablas del

sistema, sus campos, tipos de datos y las relaciones existentes entre ellas.

h. Diccionario de Datos: Es la descripción de cada uno de los campos con sus tipos de datos

de todas las tablas del diagrama Entidad-Relación.

Una vez finalizada esta fase, el analista responsable podrá generar una descripción

conceptual del sistema a desarrollar, siguiendo los apartados del Documento Especificación

de Requerimientos e integrando la matriz de riesgos del Proyecto.

Ver Anexo 7: FORM7 – Matriz de Riesgos del Proyecto

Antes de iniciar la siguiente fase es necesario elaborar y/o actualizar el cronograma de

actividades del proyecto.

La especificación de los requerimientos constituye el insumo fundamental para establecer

el cronograma de trabajo.


PÁGINA 20 DE 80

VERSIÓN 1.1



Ver Anexo 8: FORM8- Cronograma de Actividades del Proyecto

Cuando ya se ha establecido el cronograma del proyecto con las especificaciones

aprobadas y surge algún cambio o ajuste que implique un requerimiento adicional a

solicitud del Departamento o Jefe donde se desarrolla el proyecto, este deberá quedar

debidamente documentado mediante el uso de la Solicitud del Cambio y actualizarse en el

formulario de Control de Cambios del Proyecto.

Ambos documentos podrán ser actualizados y ajustados cada vez que se requiera una vez

finalizada la fase 2.

Ver Anexo 9: FORM9 - Control de Cambios del Proyecto

Ver Anexo 10: FORM10 – Solicitud de Cambio del Proyecto

Esto implica que debe ajustarse o actualizarse nuevamente el Cronograma del Proyecto,

para los casos que se requiera postergar la finalización del mismo.

Punto de Control 2: Al finalizar esta fase se deberá contar con el Cronograma del Proyecto así

como con el documento completo de Especificación de Requerimientos y la matriz de Riesgos del

Proyecto en el expediente físico y digital, firmado por el equipo de trabajo en original.

Si existiera alguna solicitud de cambio, deberá incorporarse la solicitud firmada en original y formulario

de Control de cambios actualizado y el cronograma ajustado según el control.


PÁGINA 21 DE 80

VERSIÓN 1.1



3) DESCRIPCION DETALLADA DEL SISTEMA (PROTOTIPO DE INTERFAZ DE

USUARIO)

Un prototipo es un modelo a escala de lo real, pero no tan funcional para que equivalga a un

producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final y

proporciona una retroalimentación temprana por parte de los usuarios acerca del Sistema.

El objetivo de esta fase es desarrollar las interfaces de usuarios del sistema, utilizando la

especificación de los requerimientos obtenidos. Este prototipo engloba dos componentes: los

módulos y los datos, los cuales serán analizados y diseñados desde una perspectiva conceptual a

una física, mediante pantallas o interfaces de usuarios que hagan posible la modularización del

sistema y su posible funcionamiento.

El prototipo del sistema es responsabilidad del analista del sistema y deberá ser presentado al

equipo de trabajo para su aprobación, incluyendo cada uno de los módulos descritos para el

sistema en una fase anterior.

Cabe mencionar que una vez presentado el prototipo, la reacción de los usuarios es importante a

considerar para realizar ajustes o modificaciones al mismo.

El desarrollo del prototipo deberá ser elaborado utilizando el IDE de programación más

conveniente disponible, a criterio de los analistas y deberá ser una vista rápida de todas las

pantallas y datos del sistema

Ver Anexo 11: FORM11- Aprobación del Prototipo de Interfaz de Usuario del Sistema

Punto de Control 3: En esta fase es necesario tener elaborado el Prototipo del Sistema en el IDE

seleccionado y aprobado por los usuarios del Equipo de Trabajo en el expediente físico y digital.

http://www.monografias.com/trabajos/adolmodin/adolmodin.shtml

http://www.monografias.com/trabajos6/dige/dige.shtml#evo

http://www.monografias.com/trabajos12/elproduc/elproduc.shtml

http://www.monografias.com/trabajos7/mafu/mafu.shtml

http://www.monografias.com/trabajos5/teorsist/teorsist.shtml#retrp

http://www.monografias.com/trabajos16/objetivos-educacion/objetivos-educacion.shtml

http://www.monografias.com/Fisica/index.shtml


PÁGINA 22 DE 80

VERSIÓN 1.1



4) CODIFICACIÓN, DISEÑO Y PROGRAMACIÓN DEL SISTEMA

Una vez aprobado el prototipo del sistema, dará inicio la fase de codificación, diseño y

programación del sistema en un ambiente de pruebas previamente establecido.

El ambiente de pruebas es responsabilidad del analista de sistemas en coordinación estrecha con

el administrador de servidores y administrador de bases de datos.

En esta etapa es importante describir en el cronograma de actividades del proyecto, en

concordancia con el tiempo estimado para finalizar el proyecto, las actividades por puntos de

función del sistema, es decir, cada funcionabilidad que tendrá el sistema deberá considerarse

como una actividad.

La codificación y programación del sistema es responsabilidad del analista de sistemas utilizando

las herramientas de desarrollo, creación de interfaces, servicios web y motor de bases de datos

disponibles en la institución para este fin.

El Proyecto y su código fuente deberá ser documentado en todos sus extremos de

versionamiento, procesamiento, entradas, salidas, conexión con bases de datos, librerías, manejo

de objetos y capas; de tal manera que permita identificarse en todo momento el objeto, método,

clase, entidad, acción o procesamiento que se ejecuta, utilizando una nomenclatura de nombres

intuitiva y de fácil comprensión. Por ejemplo si el Proyecto se llama: Sistema Integrado de

Consultas, con sus siglas SIC; todos los objetos tendrán como sufijo SIC. Si existiera una clase para

establecer una conexión, se llamaría SIC_conect por ejemplo. El modelo de datos también se

llamaría como el sistema SIC.

Deberá realizarse un respaldo semanal del código fuente, en una carpeta de acceso compartido

para los analistas de sistemas, especificando siempre como nombre de la carpeta, la fecha del

respaldo.

Punto de Control 4: Código fuente documentado y compilado sin errores, respaldos semanales de

código fuente


PÁGINA 23 DE 80

VERSIÓN 1.1



5) PRUEBAS Y ENTRENAMIENTO

Deberá elaborarse un plan de pruebas con los usuarios de los distintos roles y un plan de

pruebas a nivel técnico, en el ambiente de pruebas y/o producción.

El plan de pruebas con los usuarios consistirá en la ejecución de todos los casos de uso por

usuario o rol, siguiendo el instrumento de “Prueba de Aceptación”.

El plan de pruebas técnico, consiste en elaborar una serie de pruebas técnicas de velocidad

en la red, transmisión de datos, usabilidad, amigabilidad, guardado y modificación de datos

en la Base de Datos.

Ver Anexo 12: FORM12- Prueba de aceptación

Ver Anexo 13: FORM13- Plan de Pruebas Técnicas

Una vez que los planes de pruebas tanto de usuarios y técnicas sean satisfactorios y los

usuarios lo requieran; se procederá a elaborar un Plan de Entrenamiento, indicando la

fecha, hora y lugar donde se llevarán a cabo.

Ver Anexo 14: FORM14- Plan de sesión de Entrenamiento

6) AJUSTES Y MODIFICACIONES

En caso que las pruebas con los usuarios y las pruebas técnicas no alcancen un nivel

satisfactorio y se encuentren observaciones realizadas por los usuarios o analistas de

sistemas, deberán realizarse los ajustes y modificaciones que se requieran para lograr el

nivel de satisfacción deseado considerando las observaciones de los usuarios y/o analistas.

Esta etapa es iterativa durante la vida útil del sistema y se documentará haciendo uso del

formulario Control de Cambios, Versiones y Bugs, el cual deberá listar todas las

Punto de Control 5: Plan de pruebas de aceptación con los usuarios debidamente firmados, Plan

de Pruebas técnicas firmado por los analistas, Plan de Entrenamiento y planes de sesión.


PÁGINA 24 DE 80

VERSIÓN 1.1



observaciones e inconsistencias registradas en las pruebas técnicas y de aceptación; con su

respectivo ajuste o modificación.

Es importante mencionar que este mismo formulario será empleado durante la vida útil del

sistema en producción para documentar las actualizaciones, mejoras y cambios solicitados

por los usuarios una vez finalizado el sistema y durante toda su vida en producción.

Es responsabilidad del analista de sistemas mantener actualizado el control de cambios,

versiones y bugs de cada aplicación que se encuentra en producción.

Ver Anexo 15: FORM15- Control de Cambios, Versiones y Bugs del Sistema

7) IMPLANTACION Y LANZAMIENTO

En esta etapa se debe confeccionar el manual técnico de configuración e instalación de la

aplicación y ejecutarse para liberar el sistema en producción.

Es responsabilidad del analista de sistemas confeccionar minuciosamente este manual; el

cual será un insumo importante para que en eventualidades fortuitas o situaciones de

emergencia se pueda restablecer el sistema en el menor tiempo posible.

Ver Anexo 16: FORM16- Manual Técnico de Instalación y Configuración del Sistema

Cuando el sistema es liberado en producción deberá realizarse una presentación formal del

mismo a los usuarios; en caso de ser usuarios externos deberá coordinarse con Proyección

Institucional para confeccionar los avisos o anuncios correspondientes para la puesta en

marcha del nuevo sistema, su dirección de acceso y su respectivo manual de usuario.

Ver Anexo 17: FORM17- Manual de Usuario en Línea

Punto de Control 7: Al finalizar esta etapa deberá contar en el expediente físico y digital el

manual de usuario y el manual de instalación y configuración. También toda la logística de aviso y

comunicación a los usuarios implementada.


PÁGINA 25 DE 80

VERSIÓN 1.1



8) ENTREGABLES Y CIERRE DEL PROYECTO

Los entregables corresponden a toda la documentación generada del proyecto, en sus diferentes

etapas o fases, grabadas en un CD o DVD dirigido al departamento solicitante y una copia del

mismo en el expediente físico del proyecto desarrollado que permanecerá en el Archivo de

Gestión del Departamento de Tecnología de la Información.

Deberá constar en dicho expediente un Acta de Cierre del Proyecto.

Ver Anexo 18: FORM18- Acta de Cierre del Proyecto


PÁGINA 26 DE 80

VERSIÓN 1.1



Punto de Control último: Para cerrar el proyecto, es necesario que exista en el expediente físico

y digital del mismo, la siguiente documentación:

1. FORM1 - Formulario de levantamiento de necesidades

2. FORM2 - Modelo de Arquitectura de Información DGAN.

3. FORM3 - Formulario de Solicitud de Sistema de Información

4. FORM4 - Bitácoras de reuniones efectuadas firmadas en original

5. FORM5 - Análisis y Evaluación Preliminar de la Solicitud firmada en original

6. FORM6 - Especificación de Requerimientos

7. FORM7 - Matriz de Riesgos del Proyecto

8. FORM8 - Cronograma de Actividades del Proyecto

9. FORM9 - Control de Cambios del Proyecto

10. FORM10 - Solicitud de Cambio del Proyecto

11. FORM11 - Aprobación del Prototipo de Interfaz de Usuario del Sistema

12. FORM12- Prueba de aceptación

13. FORM13 – Plan de Pruebas Técnicas

14. FORM14 - Plan de sesión de Entrenamiento

15. FORM15 - Control de Cambios, Versiones y Bugs

16. FORM16 – Manual Técnico de Instalación y configuración del sistema

17. FORM17 – Manual de Usuario (en línea)

18. FORM18 – Acta de Cierre del Proyecto

Adicionalmente, si existiera, cualquier otra documentación utilizada durante la ejecución

del proyecto con formato de correo electrónico, imágenes, diagramas, uml, código fuente,

clases, objetos, forms, javascripts, html, etc, deberá ser incorporada al expediente.


PÁGINA 27 DE 80

VERSIÓN 1.1



6. Anexos o Instrumentos de la Metodología


PÁGINA 28 DE 80

VERSIÓN 1.1



ANEXO #1: LEVANTAMIENTO DE NECESIDADES DE AUTOMATIZACION DE

PROCESOS


DIRECCIÓN GENERAL DEL ARCHIVO NACIONAL

PÁGINA 28 DE 80

VERSIÓN 1.1

LEVANTAMIENTO DE NECESIDADES DE AUTOMATIZACION DE PROCESOS FORM1

Utilice este formulario para el levantamiento de necesidades de automatización basada en los procesos

institucionales. Debe llenar una tabla por cada proceso.

(NOMBRE DEL PROCESO)

Describa brevemente en qué consiste este proceso. Para qué se hace, como se hace y para quien se hace

Nombre del Departamento Escriba aquí el nombre del Departamento responsable de ejecutar el

proceso

Nombre del funcionario o

funcionarios responsables de

ejecutar el proceso

Escriba aquí el nombre de las personas o funcionarios responsables de

ejecutar el proceso.

Identificación del proceso AN_SIGLA DEL DEPARTAMENTO_NOM PROCESO_01

Funcionario

Interno

Usuario

Interno

Usuario

Externo

Autoridades/JAAN/otro

Tipo de Usuario del proceso

Salida/Producto final del proceso Indique las salidas y el producto final del proceso

Procedimientos relacionados Indique el nombre de los procedimientos relacionados con este proceso

Entradas Describa todas las entradas de información que se requieren para ejecutar este


PÁGINA 29 DE 80

VERSIÓN 1.1



proceso.

Salidas Describa todas las salidas de información como resultado de ejecutar este proceso

Actividades y tareas Describa en orden secuencial las actividades y tareas del proceso

Insumos Describa todos los insumos requeridos para ejecutar este proceso

Se conecta con proceso Describa en detalle con cuales otros procesos se conecta


PÁGINA 30 DE 80

VERSIÓN 1.1



ANEXO #2: MODELO DE ARQUITECTURA DE INFORMACIÓN MAI-DGAN


PÁGINA 31 DE 80

VERSIÓN 1.1




PÁGINA 32 DE 80

VERSIÓN 1.1



ANEXO #3: SOLICITUD DE SISTEMA DE INFORMACION



PÁGINA 32 DE 80

VERSIÓN 1.1

SOLICITUD DE SISTEMA DE INFORMACIÓN FORM3

Datos de la Solicitud

Describa brevemente cual proceso o grupo de procesos requiere automatizar.

Departamento Solicitante: Nombre del Departamento, Proceso o Subproceso que solicita

Firma del Jefe del Departamento: Firma del Jefe del Departamento Solicitante

Fecha de la Solicitud: Fecha de Solicitud [dd/mm/aaaa]

Problema a Resolver: Enunciado del problema con las posibles restricciones que se podrían

enfrentar durante el desarrollo de la solución. Posteriormente, junto

con el usuario se llegará a un enunciado definitivo del problema el cual

debe de incluir una descripción de la situación actual y de las metas

que debe lograr el nuevo sistema. La definición del problema requiere

de un total entendimiento del problema y de su entorno.

Justificación: Aquí debe expresarse por qué se desea o necesita desarrollar el

proyecto; así mismo, si la justificación se fundamenta en el

cumplimiento de legislación vigente, debe enumerarse y describirse

toda la legislación.

Legislación: Enumere toda la legislación relacionada y vinculada con el proyecto.

Alcance: Debe indicarse los objetivos, los usuarios, servicios y procesos

involucrados y cuales ventajas se obtendrían en razón de tiempo,

eficiencia y calidad del servicio; cuales otros departamentos

interactúan con el proceso involucrado; así como el tiempo estimado


PÁGINA 33 DE 80

VERSIÓN 1.1



de ejecución del proyecto.

Responsables del Proyecto:

Nombre Completo

Departamento Puesto Correo

Electrónico

Teléfono

Financiamiento Proyecto ADAI Pre Inversión

MIDEPLAN

Banco

Mundial

Otro:

Especifique:__

Cantidad en colones:

Analista Asignado: Para uso del Departamento de Tecnología de la Información

Aclaración de la Solicitud:

(para uso del analista)

La aclaración de la solicitud pretende proveer al Departamento de

Tecnología de la Información una clara definición del problema a

resolver y de todos los aspectos indicados en la solicitud del sistema,

esta aclaración es responsabilidad del analista de sistemas.

Fecha de Aclaración: Fecha en que se realiza la aclaración de la solicitud [dd/mm/aaaa]


PÁGINA 34 DE 80

VERSIÓN 1.1



ANEXO #4: BITACORA DE REUNION



PÁGINA 34 DE 80

VERSIÓN 1.1

BITACORA DE REUNIÓN FORM4

Fecha: dd/mm/aaaa [NUMERO DE REUNION 001]

Asunto o Proyecto: [SISTEMAS DE INFORMACION INSTITUCIONAL]

Objetivo:

[Revisión y definición de acciones: FORMULARIO DE INSCRIPCIÓN CONGRESO

Revisión y Ajuste de Cronogramas de trabajo.

Revisión y avance metas POI.]

Convoca: [Ing. Petronila Mairena Traña]

Lugar [DEPARTAMENTO DE COMPUTO]

Hora de Inicio 2:30 pm Hora de Finalización 4:00 pm

I. Agenda

Actividad Responsable

II. Asistencia

Nombre Firmar Asistencia


PÁGINA 35 DE 80

VERSIÓN 1.1



III. Asuntos discutidos y acuerdos

Observaciones

Bitácora elaborada por: [nombre quien elabora minuta y la comunica]


PÁGINA 36 DE 80

VERSIÓN 1.1



ANEXO #5: ANALISIS Y EVALUACION PRELIMINAR



PÁGINA 36 DE 80

VERSIÓN 1.1

ANALISIS Y EVALUACIÓN PRELIMINAR FORM5

ANALISIS Y EVALUACIÓN PRELIMINAR

Describa brevemente cual proceso o grupo de procesos requiere automatizar.


Fecha de recibo de la Solicitud: Fecha de recibido de la Solicitud [dd/mm/aaaa]

Problema a Resolver: Enunciado del problema con las posibles restricciones que se podrían

enfrentar durante el desarrollo de la solución. Posteriormente, junto

con el usuario se llegará a un enunciado definitivo del problema el

cual debe de incluir una descripción de la situación actual y de las

metas que debe lograr el nuevo sistema. La definición del problema

requiere de un total entendimiento del problema y de su entorno.

Justificación: Aquí debe expresarse por qué se desea o necesita desarrollar el

proyecto; así mismo, si la justificación se fundamenta en el

cumplimiento de legislación vigente, debe enumerarse y describirse

toda la legislación.

Legislación: Enumere toda la legislación relacionada y vinculada con el proyecto.




interactúan con el proceso involucrado; así como el tiempo estimado

de ejecución del proyecto.


PÁGINA 37 DE 80

VERSIÓN 1.1



Equipo Responsable:

Nombre Completo

Departamento Puesto Correo

Electrónico

Teléfono

Financiamiento Proyecto ADAI Pre Inversión

MIDEPLAN

Banco

Mundial

Otro:

Especifique:__

Cantidad en colones:

Firma Analista Asignado:

Firma Líder del Proyecto:

Aclaración de la Solicitud:

(para uso del analista)

La aclaración de la solicitud pretende proveer al Departamento de

Tecnología de la Información una clara definición del problema a

resolver y de todos los aspectos indicados en la solicitud del sistema,


PÁGINA 38 DE 80

VERSIÓN 1.1



esta aclaración es responsabilidad del analista de sistemas.

Diagnóstico de la Situación Actual:

Objetivo General

Objetivos Específicos

Supuestos y restricciones

Fecha de Aclaración: Fecha en que se realiza la aclaración de la solicitud [dd/mm/aaaa]

Aprobación de la Jefatura TI FIRMA DEL JEFE

Fecha de Aprobación: Fecha de aprobación [dd/mm/aaaa]


PÁGINA 39 DE 80

VERSIÓN 1.1



ANEXO #6: ESPECIFICACION DE REQUERIMIENTOS



PÁGINA 39 DE 80

VERSIÓN 1.1

ESPECIFICACION DE REQUERIMIENTOS FORM6

NOMBRE DEL PROYECTO

EQUIPO DEL PROYECTO

NOMBRE COMPLETO ROL FIRMA

líder

analista

Elabora y

comunica

bitácora

Usuario experto

Fecha de especificación:


PÁGINA 40 DE 80

VERSIÓN 1.1



Elaborado por: [nombre del analista]


PÁGINA 41 DE 80

VERSIÓN 1.1



TABLA DE CONTENIDOS

NOMBRE DEL PROYECTO 39

Tabla de Contenidos 41

MODULOS DEL PROYECTO 42

REQUERIMIENTOS FUNCIONALES 44

REQUERIMIENTOS NO FUNCIONALES 46

CASOS DE USO 47

DIAGRAMA DE CASOS DE USO 52

DIAGRAMA DE SECUENCIA 54

DIAGRAMA ENTIDAD-RELACION 56

DICCIONARIO DE DATOS 57


PÁGINA 42 DE 80

VERSIÓN 1.1



MODULOS DEL PROYECTO

Enumere los módulos

MODULO 1 Nombre del Módulo

Descripción detallada del módulo

Describa a detalle los procesos y tareas que se desarrollaran en este módulo





PÁGINA 43 DE 80

VERSIÓN 1.1










PÁGINA 44 DE 80

VERSIÓN 1.1



REQUERIMIENTOS FUNCIONALES

RF-1 Nombre del Requerimiento

Descripción detallada del requerimiento

Describa a detalle del requerimiento funcional





PÁGINA 45 DE 80

VERSIÓN 1.1






RF- 4 Nombre del Requerimiento




PÁGINA 46 DE 80

VERSIÓN 1.1



REQUERIMIENTOS NO FUNCIONALES

RNF-1 Nombre del requerimiento no funcional


Describa a detalle el requerimiento no funcional





PÁGINA 47 DE 80

VERSIÓN 1.1









CASOS DE USO

CU-1 Nombre del Caso de Uso

Descripción detallada del caso de uso


PÁGINA 48 DE 80

VERSIÓN 1.1



Describa a detalle del caso de uso

Actores

Enumere los actores del caso de uso

Flujo normal de eventos

Describa el flujo normal de eventos del caso de uso

Subflujo

Describa el subflujo si existe

Relación

Describa o mencione con qué se relaciona este caso de uso





PÁGINA 49 DE 80

VERSIÓN 1.1



Actores




Subflujo


Relación






PÁGINA 50 DE 80

VERSIÓN 1.1



Actores




Subflujo


Relación






PÁGINA 51 DE 80

VERSIÓN 1.1



Actores




Subflujo


Relación



PÁGINA 52 DE 80

VERSIÓN 1.1



DIAGRAMA DE CASOS DE USO


PÁGINA 53 DE 80

VERSIÓN 1.1




PÁGINA 54 DE 80

VERSIÓN 1.1



DIAGRAMA DE SECUENCIA


PÁGINA 55 DE 80

VERSIÓN 1.1




PÁGINA 56 DE 80

VERSIÓN 1.1



DIAGRAMA ENTIDAD-RELACION


PÁGINA 57 DE 80

VERSIÓN 1.1



DICCIONARIO DE DATOS

Desarrolle aquí el diccionario de datos del sistema


PÁGINA 58 DE 80

VERSIÓN 1.1



ANEXO #7: CRONOGRAMA DEL PROYECTO

I II III IV I II III IV I II III IV I II III IV I II III IV I II III IV I II III IV I II III IV

ACTIVIDADUNIDAD o FUNCIONARIO

RESPONSABLE

agosto

[NOMBRE DEL PROYECTO]

DEPARTAMENTO DE TECNOLOGIA DE LA INFORMACION

CRONOGRAMA DEL PROYECTO

DEPARTAMENTO SOLICITANTE: (DSAE) DIRECCION

SERVICIOS ARCHIVISTICOS EXTERNOS

2015

enero febrero marzo abril mayo junio julio


PÁGINA 59 DE 80

VERSIÓN 1.1



ANEXO #8: APROBACION DEL PROTOTIPO



PÁGINA 59 DE 80

VERSIÓN 1.1

APROBACION DEL PROTOTIPO FORM8

NOMBRE DEL PROYECTO

EQUIPO DEL PROYECTO

NOMBRE COMPLETO ROL FIRMA

líder

analista

Elabora y

comunica

bitácora

Usuario experto

Fecha de Aprobación:


PÁGINA 60 DE 80

VERSIÓN 1.1



Elaborado por: [nombre del analista]


PÁGINA 61 DE 80

VERSIÓN 1.1



TABLA DE CONTENIDOS

NOMBRE DEL PROYECTO 59

TABLA DE CONTENIDOS 61

PANTALLAS DEL SISTEMA 61

Pantalla 1 61

Pantalla 2 61

PANTALLAS DEL SISTEMA

Pantalla 1

Pantalla 2


PÁGINA 62 DE 80

VERSIÓN 1.1



ANEXO #9: PRUEBA DE ACEPTACION


PÁGINA 62 DE 80

VERSIÓN 1.1

PRUEBA DE ACEPTACION FORM9

Código Caso de

Prueba: 1 Nombre de Caso de Uso: Usuario rol:

Descripción de la Prueba:

Condiciones de Ejecución:

Entrada / Pasos de Ejecución:

1. A 2. B 3. C

Resultado Esperado:

Evaluación de la Prueba:

Satisfactoria No Satisfactoria

Observaciones:


PÁGINA 63 DE 80

VERSIÓN 1.1



Firma del Usuario:

Firma del Analista:


PÁGINA 64 DE 80

VERSIÓN 1.1



ANEXO #10: PLAN DE PRUEBAS TÉCNICAS


PÁGINA 64 DE 80

VERSIÓN 1.1

PLAN DE PRUEBAS TECNICAS FORM10

PRUEBAS TÉCNICAS DEL SISTEMA

Con este plan se aseguran las funcionalidades y características del sistema para:

1. Identificar que la información existente del proyecto y los componentes de software sean probados.

2. Listar los requerimientos recomendados de prueba (de alto nivel).

3. Recomendar y describir las estrategias a ser empleadas.

4. Identificar los recursos requeridos y estimar los esfuerzos de las pruebas.

5. Listar los elementos a entregar de las actividades de pruebas.

Analista:

Firma:

Pruebas de integridad de

datos y BD:

Verificar el acceso a la BD.

Verificar el acceso simultáneo en la lectura de registro de las distintas tablas.

Verificar el bloqueo realizado durante actualizaciones de registros de las

tablas transaccionales

Verificar la correcta obtención de data actualizada.

Criterio de

Cumplimiento:

Satisfactorio No Satisfactorio Observaciones


PÁGINA 65 DE 80

VERSIÓN 1.1



Pruebas del Sistema: Resultado de las pruebas de aceptación de los usuarios en porcentaje

Criterio de

Cumplimiento:


Prueba de la Interfaz de

Usuario:

Verificar la facilidad de navegación mediante un ejemplo de pantallazos de

las funcionalidades.

Verificar que los pantallazos de ejemplo cumplan estándares de GUI.

Criterio de

Cumplimiento:


Pruebas de Desempeño: Verificar el tiempo de respuesta para acceder remotamente a la aplicación

Verificar el tiempo de respuesta para guardar un registro

Verificar el tiempo de respuesta para consultar un dato o conjunto de ellos

Verificar el tiempo de respuesta para generar un reporte en pantalla o

impresora

Criterio de

Cumplimiento:


Pruebas de Carga: Verificar la respuesta del sistema cuando tiene un determinado número de usuarios (50)

usuarios accediendo a la tabla principal del sistema.

Criterio de

Cumplimiento:


Pruebas de Stress: Verificar la respuesta del sistema cuando tiene más de 100 sesiones de usuario

Criterio de

Cumplimiento:



PÁGINA 66 DE 80

VERSIÓN 1.1



Pruebas de Volumen: Verificar el tiempo de respuesta cuando la tabla principal está en el 90% de su capacidad.

Criterio de

Cumplimiento:



PÁGINA 67 DE 80

VERSIÓN 1.1



ANEXO #11: PLAN DE SESION DE ENTRENAMIENTO


PÁGINA 67 DE 80

VERSIÓN 1.1

PLAN DE SESION DE ENTRENAMIENTO FORM11

Título de la Sesión FUNCIONABILIDADES DEL SISTEMA X

Tiempo estimado de la sesión: 60 minutos

Público Objetivo: Personal Profesional y Técnico que ejecuta funciones o tareas en el sistema.

Facilitador o Analista:

Perfil de entrada Perfil de Salida

Personal apenas que conoce el proceso manual sin automatización

Personal con conocimientos avanzados en el uso del sistema.

Objetivo General:

Objetivos Específicos:

1. A

2. b

Contenidos didácticos: Liste los temas o módulos a desarrollar

Metodología: Refuerzo participativo mediante presentación con diapositivas proyectadas en una pantalla y/o uso del VideoBeam. Se utiliza una dinámica de aprendizaje para aplicar lo aprendido.

Programación de la Sesión Horario Actividad Descripción de la Actividad Recursos y Materiales

8:00am – 8:05am Apertura y Motivación

Se sensibiliza a los participantes sobre la importancia del uso de la tecnología sin perder la naturaleza humana.

Reflexión

8:05am - 8:10am Dinámica de Integración

Reconocimiento de conceptos a través de figuras.

Mural y/o Diapositiva

8:10am - 8:30am Refuerzo Participativo: Presentación teórica de los conceptos.

Mediante la técnica de presentación con diapositivas y/o uso del Rotafolio se desarrolla el objetivo general y los objetivos específicos de la sesión.

Video Beam y/o Rotafolio, presentación impresa


PÁGINA 68 DE 80

VERSIÓN 1.1



8:30am - 8:55am Dinámica de Aprendizaje:

Se solicita a los participantes completar un formulario de recolección de información.

Se solicita completar un formulario con levantamiento de necesidades en gestión integral de información.

Formulario con datos a recolectar del participante.

8:55am – 9:00am

Cierre de Sesión

Diagnóstico – Evaluación

Se solicita a cada participante completar un formulario de Falso y Verdadero

Formulario con ítems de Falso y Verdadero para cada participante.

Lista de Participantes

NOMBRE DE LA CAPACITACION

LUGAR

FECHA

HORA INICIO HORA FINAL

NOMBRE COMPLETO FIRMA


PÁGINA 69 DE 80

VERSIÓN 1.1




PÁGINA 70 DE 80

VERSIÓN 1.1



ANEXO #12: CONTROL DE CAMBIOS, VERSIONES Y BUGS

Por: [NOMBRE DEL ANALISTA RESPONSABLE]

ID C-R-E Prioridad EstadoFecha de

RegistroDescripción Solución/Observaciones

Fecha

ResueltoQA Versión Inicial Fecha Nueva Versión Manual de usuario Manual Técnico Documentación

1 R 2-dic-2005

Proyecto: [NOMBRE DEL PROYECTO O SISTEMA]

Cambios en el



DEPARTAMENTO DE TECNOLOGIA DE LA INFORMACIÓN


CONTROL DE CAMBIOS, VERSIONES Y BUGS

FORM12


PÁGINA 71 DE 80

VERSIÓN 1.1



ANEXO #13: MANUAL TÉCNICO DE INSTALACIÓN Y CONFIGURACIÓN

“NOMBRE DEL PROYECTO O SISTEMA”

Manual Técnico de

Instalación y Configuración

FORM13


PÁGINA 72 DE 80

VERSIÓN 1.1



Tabla de Contenidos

Introducción

Descripción del proceso que automatiza el sistema y sus módulos

Objetivo

Desarrollar una guía rápida de referencia para la instalación y configuración de las tecnologías utilizadas para el sistema.


1. Mostrar los pasos para la instalación y configuración de Apache Web Server en ambiente Windows y Linux

2. Desarrollar la guía de instalación de MySQL en ambiente Windows y Linux. 3. Mostrar la instalación y configuración de PHP en Apache en ambiente Windows y Linux,

y PHP en IIS (Internet Information Server) para Windows. 4. Instalación del Sistema sobre Windows y Linux. 5. Instalación de la Base de Datos

Instalación y Configuración

Aquí debe referenciarse el medio físico o CD o DVD donde están los archivos del Sistema y deberán aparecer las pantallas con su respectiva descripción de cada uno de los pasos para realizar la correcta instalación y configuración de la aplicación en el ambiente de producción, incluyendo todas las restricciones, limitaciones y supuestos.


PÁGINA 73 DE 80

VERSIÓN 1.1



Este manual es la referencia técnica para que cualquier persona con conocimientos de informática y computación pueda instalar el sistema en un servidor y en las computadoras clientes.

1

Metodología de Desarrollo Sistemas de Información Página 74 de 80

ANEXO #14: MANUAL DE USUARIO

“NOMBRE DEL PROYECTO O SISTEMA”

Manual de

Usuario FORM14


Tabla de Contenidos

Introducción

Descripción del proceso que automatiza el sistema y sus módulos

Objetivo


1. Mostrar los pasos para ingresar al sistema 2. Describir cada uno de los módulos del sistema con sus respectivas pantallas 3. Crear usuario 4. Mantenimiento de parámetros 5. Mantenimiento de Catálogos 6. Procesos…

Módulos

Describir el uso de cada uno de los módulos de la aplicación y el acceso, modificación y guardado de

datos.

Utilice las pantallas y descríbales los pasos.


ANEXO #15: ACTA DE CIERRE Y ENTREGA DEL PROYECTO

ACTA DE CIERRE Y ENTREGA DEL PROYECTO

Una vez concluido el proyecto, el analista responsable deberá cerrar el proyecto mediante la presente acta:

Título del Proyecto

Objetivos Finales del Proyecto Con el paso del tiempo los objetivos iniciales del proyecto pudieron cambiar, por lo que se requiere presentarlos en forma actualizada.

Fecha de entrega del Proyecto:

Fecha de inicio del Proyecto:

Costo Final del Proyecto en US$ Costo del proyecto de acuerdo con los datos registrados por el responsable del proyecto.

Aporte final del Patrocinador: Valor total entregado por el patrocinador del proyecto, de acuerdo con los datos registrados por el responsable del proyecto.

Entregables generados por el proyecto: Enunciar los productos tangibles o intangibles que el

responsable del proyecto presenta como resultado de

la ejecución del proyecto.

Bienes a favor de la ESPE: Indicar los bienes adquiridos que quedan a favor de la Institución (SI EL CASO LO AMERITA – CASO CONTRARIO NO LLENAR)

Logros el proyecto: Enunciar los principales logros alcanzados con la

ejecución del proyecto.

Posibles Aplicaciones de los Resultados: Indicar las posibles aplicaciones que se pueden dar a los resultados alcanzados obtenidos.


Beneficiarios del Proyecto: Indicar y describir las personas naturales o jurídicas que se beneficiaron con la ejecución del proyecto

Comentarios Generales: En este campo se pueden dejar claro cualquier tipo de comentario importante para la ejecución del producto resultado del proyecto o para la réplica misma del proyecto o las buenas prácticas empleadas en su ejecución.

Firmas de Responsabilidad

------------------------------------------------ ---------------------------------------------

Líder del Proyecto Analista Programador

(Llenar nombre, cargo y firma) (Llenar nombre, cargo y firma)

------------------------------------------------

Jefe Departamento de Tecnología de la Información

(Llenar nombre, cargo y firma)


ANEXO #16: CONTROL DE CAMBIOS DEL PROYECTO


ICFECHA DE SOLICITUD DEL

CAMBIODESCRIPCIÓN DEL CAMBIO PERSONA QUE AUTORIZA EL CAMBIO

TIEMPO ESTIMADO PARA REALIZAR EN

CAMBIO ( en días)

FECHA DE FINALIZACIÓN DEL

CAMBIORESPONSABLE DE EJECUTAR EL CAMBIO

1 1 1

2

3

4

5

6

7

8






CONTROL DE CAMBIOS DEL PROYECTOFORM16


ANEXO #17: MATRIZ DE RIESGOS DEL PROYECTO


IR DESCRIPCIÓN DEL RIESGO CLASIFICACION DEL RIESGO PROBABILIDAD DE OCURRENCIA PLAN DE ACCION PARA MITIGARLO RESPONSABLE DE ADMINISTRARLO

1 1 1

2

3

4

5

6

7

8






MATRIZ DE RIESGOS DEL PROYECTOFORM17


ANEXO #18: SOLICITUD DE CAMBIO EN EL SISTEMA DE INFORMACION



PÁGINA 80 DE 80

VERSIÓN 1.1

SOLICITUD DE CAMBIO EN EL SISTEMA DE INFORMACIÓN FORM18

Solicitud de Cambio # 1

Describa brevemente en qué consiste el cambio solicitado. Debe ser un nuevo requerimiento no incluido en el

análisis preliminar.


Firma del Jefe del Departamento: Firma del Jefe del Departamento Solicitante

Firma Directora General: Firma de la Directora General del Archivo Nacional

Fecha de la Solicitud: Fecha de Solicitud [dd/mm/aaaa]

Justificación del cambio: Aquí debe expresarse por qué se desea o necesita desarrollar o

implementar dicho cambio en el proyecto; así mismo, si la

justificación se fundamenta en el cambio de cumplimiento de

legislación vigente, debe enumerarse y describirse toda la legislación.

Legislación: Enumere toda la legislación relacionada y vinculada con el cambio




interactúan con el cambio involucrado; así como el tiempo estimado

de incorporación del cambio.

Analista Asignado: Para uso del Departamento de Tecnología de la Información

Fecha de incorporación del cambio

en el Proyecto Para uso del Departamento de Tecnología de la Información

Fecha ajuste Cronograma: Para uso del Departamento de Tecnología de la Información

Fecha finalización del Proyecto: Para uso del Departamento de Tecnología de la Información

metodologia desarrollo de sistemas de información version firmada digitalmente

Engineering