guÍa metodolÓgica para el desarrollo de sistemas de

GUÍA METODOLÓGICA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN Y SOFTWARE EN GENERAL

CÓDIGO: 2310200-GS-014 VERSIÓN: 01 PÁGINA: 1 de 25

CLASIFICACIÓN DE LA INFORMACIÓN: PÚBLICA

2310100-FT-120. Versión 02

SECRETARÍA JURÍDICA DISTRITAL ALCALDÍA MAYOR

DE BOGOTÁ, D.C.

GUÍA METODOLÓGICA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN Y SOFTWARE EN

GENERAL




2310100-FT-120. Versión 02

Tabla de contenido 1. INTRODUCCIÓN ................................................................................................ 4 2. ALCANCE ........................................................................................................... 5 3. OBJETIVO .......................................................................................................... 5 3.1. Objetivos específicos ........................................................................................ 5 4. DESCRIPCIÓN DE LA METODOLOGÍA ............................................................ 6 5. DEFINICIÓN DE FUNCIONES Y RESPONSABILIDADES ................................. 6 6. FASES PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN ............. 8 6.1. Solicitud para el desarrollo de un Sistema de Información ........................... 8 6.2. Estudio Preliminar ............................................................................................. 9 6.3. Identificación de soluciones y su factibilidad ................................................. 9 6.4. Análisis integral de requerimientos ............................................................... 10 6.4.1. Requerimientos funcionales ........................................................................... 10 6.4.2. Requerimientos no funcionales ..................................................................... 11 6.4.3. Priorización de Requerimientos ..................................................................... 12 6.4.4. Definición de infraestructura tecnológica ..................................................... 12 6.4.5. Cronograma de las fases posteriores del proyecto ...................................... 12 6.5. Diseño conceptual del Proyecto .................................................................... 12 6.5.1. Identificación de los módulos ........................................................................ 13 6.5.2. Descripción de módulos y sub-módulos y su interacción ........................... 13 6.5.3. Identificación de interrelaciones con otros sistemas o módulos ................ 13 6.5.4. Identificar tipos de usuarios ........................................................................... 13 6.6. Diseño de pruebas: ......................................................................................... 13 6.6.1. Requerimientos para las pruebas .................................................................. 14 6.6.2. Casos y datos de prueba ................................................................................ 14 6.6.3. Usuarios para las pruebas .............................................................................. 14 6.7. Construcción y desarrollo del Proyecto ........................................................ 15 6.7.1. Implementación del modelo físico de datos .................................................. 15 6.7.2. Creación de roles y usuarios .......................................................................... 15 6.7.3. Programación .................................................................................................. 16 6.7.4. Conversión y levantamiento de datos ........................................................... 16 6.7.5. Documentación del proyecto ......................................................................... 16 6.7.5.1. Manual de usuario ..................................................................................... 18 6.7.5.2. Manual técnico .......................................................................................... 18 6.8. Capacitación .................................................................................................... 18 6.9. Puesta en producción ..................................................................................... 18 6.10. Instalación del sistema ................................................................................... 19 6.11. Conversión y carga inicial automatizada de datos ....................................... 19 6.12. Ejecución del paralelo ..................................................................................... 20 6.13. Aprobación formal del sistema para el inicio de su operación. ................... 21 6.14. Hacer la entrega del sistema al Responsable del Proyecto. ........................ 21 6.15. Hacer la entrega de programas fuente........................................................... 21




2310100-FT-120. Versión 02

6.16. Evaluación post-implementación ................................................................... 21 7. MANTENIMIENTO DE SISTEMAS ................................................................... 22 7.1 Planificación de la fase de mantenimiento .................................................... 22 7.2 Especificación de los nuevos requerimientos .............................................. 22 7.3 Ajustes en programación y pruebas .............................................................. 22 7.4 Actualización de la documentación y los programas fuente ....................... 23 7.5 Implementación de los cambios..................................................................... 23 7.6 Evaluación post-implementacion ................................................................... 23 7.7 Seguimiento y mejoramiento a los sistemas de información ...................... 23 8 RECEPCIÒN DOCUMENTACIÓN SOFTWARE ............................................... 24




2310100-FT-120. Versión 02

1. INTRODUCCIÓN

Un sistema de información es considerado, como la adquisición de una solución para la automatización de procesos, con interrelación compleja de procesos, procedimientos, presupuesto, políticas, equipo computacional, entre otros. Se fundamentan en la integración de dos aspectos principalmente los datos y los procesos, en este sentido un sistema se concibe como un conjunto de objetos que se comunican entre sí mediante mensajes, este enfoque permite un modelado más natural del mundo real y facilita enormemente la reutilización del software Es por ello que es necesaria elaborar una guía metodológica para desarrollo de Sistemas de Información y Software en General que le permita a la secretaria Jurídica Distrital construir soluciones flexibles y responder a un ambiente tecnológico controlado. Hasta hace poco el proceso de desarrollo llevaba asociado un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige un alto grado control y exigencias en el seguimiento de los procesos. Sin embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo, pero manteniendo una alta calidad, en este escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío metodológico. Esta guía metodológica provee un conjunto estructurado de actividades para implementar y dar mantenimiento a un sistema de información (o software específico), de manera que la especificación, el diseño, la validación y el desarrollo del sistema converjan en una solución eficiente en un tiempo prudencial, acorde con las necesidades de esta entidad y con la documentación suficiente para facilitar su actualización o cambios. Por consiguiente, la aplicación de las actividades señaladas en la presente Guía Metodológica es de cumplimiento obligatorio para todos los funcionarios de este la secretaria Jurídica Distrital que participen en el desarrollo de sistemas de información de acuerdo a las funciones y responsabilidades que estén desempeñando, o empresas con las cuales se contrate la tercerización de estos servicios.




2310100-FT-120. Versión 02

2. ALCANCE

El desarrollo del presente documento está orientado a describir de manera general las actividades a realizar para el desarrollo de sistemas de información y software en general, sin entrar en detalles específicos de forma en cuanto a los documentos de cada una de las etapas, por esto, no se profundiza en aspectos técnicos específicos de la construcción de “software” como reglas para el diseño de bases de datos, técnicas de afinamiento de sistemas y mecanismos para el desarrollo y reutilización de componentes, entre otros. Se omite hacer referencia a herramientas para el desarrollo de aplicaciones, modelado de bases de datos, confección y actualización de cronogramas así como motores de bases de datos, plataformas operativas, protocolos de comunicación, arquitectura de sistemas y especificaciones de equipos, entre otros, para que lo establecido en esta Guía Metodológica no pierda vigencia como consecuencia del constante avance que presenta el mercado en estos aspectos.

3. OBJETIVO

Disponer de un documento guía para la ejecución de las actividades relacionadas con el desarrollo y mantenimiento de Sistemas de Información y Software en General, y manejo de los requerimientos, lo cual asegurara los mejores niveles de servicio, calidad, seguridad de la información, disponibilidad, y aplicación eficaz de planes de mejoramiento.

3.1. Objetivos específicos

Los objetivos específicos de la presente Guía Metodológica son los siguientes:




2310100-FT-120. Versión 02

• Definir claramente las fases y actividades a realizar en los proyectos de

desarrollo de sistemas de información y software en general.

• Señalar las funciones de los roles y responsabilidades de los involucrados en el

proceso de construcción e implementación de desarrollo de proyectos de

sistemas de información.

• Definir un marco de referencia común entre todos los proyectos de desarrollo de

sistemas para estandarizar técnicas y métodos de trabajo.

4. DESCRIPCIÓN DE LA METODOLOGÍA

La presente metodología está estructurada en tres secciones principales:

A. Funciones y responsabilidades

B. Las fases para el desarrollo de sistemas de información

C. El seguimiento y mejoramiento a los sistemas de información

En la primera de estas secciones se hace referencia a las funciones y responsabilidades de cada uno de los involucrados en el desarrollo del proyecto. En la segunda sección de la presente metodología se presenta la guía para la realización de las distintas fases que conlleva el desarrollo de un sistema de información nuevo. En la tercera sección se especifican los aspectos principales para el seguimiento y mejoramiento de las aplicaciones en producción considerando para esto el manejo de los nuevos requerimientos.

5. DEFINICIÓN DE FUNCIONES Y RESPONSABILIDADES

En el desarrollo del presente documento se hace referencia a varias funciones y responsabilidades que se describen a continuación:

• Jefe De Oficina TIC: Es el máximo ente en lo referente a la aprobación de las

directrices y lineamientos a seguir en la planificación y dirección de los procesos

de desarrollo tecnológico.




2310100-FT-120. Versión 02

• Responsable de proyecto: Es el interlocutor válido del área de la secretaria

jurídica para la cual se va a desarrollar el sistema de información o software en

general.

• Líder Funcional: es un funcionario del área que requiere el software, y que cuenta

con gran conocimiento de su área funcional, aspecto por el cual se le ha

conferido la capacidad de tomar decisiones y la responsabilidad del participar

activamente.

• Coordinador de Equipo Técnico del proyecto: Éste es un funcionario del área de

TIC, al cual, por su formación en el área de informática, experiencia y capacidad,

se le da la responsabilidad de administrar los aspectos tecnológicos de un

proyecto de desarrollo de sistemas. De igual manera será el responsable de

aconsejar al jefe de oficina TIC, en la evaluación, gestiona el establecimiento de

prioridades y programación de los cambios. Estarán al tanto de las solicitudes de

paso a producción de los nuevos desarrollos y mantenimientos de software,

siendo quien de la aprobación formal del paso a producción. Ver formato

2310200-PR-096 Gestión de Control de Cambios de Servicios de TI

• Equipo Técnico del proyecto: Trabajan bajo la coordinación y dirección del

Coordinador de Equipo Técnico del proyecto para la realización del sistema cuyas

actividades principales son análisis y diseño del sistema, construcción de los

programas, pruebas y documentación, capacitación de usuarios, y apoyo de los

usuarios en la puesta en operación del sistema.

• Usuario del sistema: funcionario de la oficina usuaria, que tiene acceso autorizado al

Sistema de Información. Existen dos tipos de usuarios: usuario generador de

información y usuario de consulta.

• Arquitecto de Software (Fábrica de Desarrollo o tercerización): Persona asignada para

realizar el diseño de arquitectura de los diferentes requerimientos de software,

alineadas al modelo general de los componentes de los Sistemas de Información de

la secretaria jurídica distrital. Asegura la aplicación de estándares y buenas prácticas




2310100-FT-120. Versión 02

de codificación y que se cumpla con los estándares de desarrollo seguro con el fin de

eliminar cualquier vulnerabilidad.

• Analista de Calidad de Software (Fábrica de Desarrollo o tercerización): Persona

asignada que realiza el aseguramiento del proceso y del producto, mediante

verificaciones del debido proceso del proyecto, ejecuciones de pruebas estáticas de

documentación y pruebas de calidad sobre el software y la documentación, este rol

garantiza el aseguramiento de calidad de productos de software mediante la

aplicación de set de pruebas y estándares en los diferentes proyectos.

• Oficial de Seguridad de la Información: Líder asignado por Jefe De Oficina TIC para

verificar la correcta alineación del proyecto cumpliendo con la Política de Seguridad

de la Información y los requerimientos de seguridad establecidos.

6. FASES PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN

6.1. Solicitud para el desarrollo de un Sistema de Información

Esta es la primera fase para la formulación de un proyecto que conlleve al desarrollo de un nuevo Sistema de Información o a la construcción de un nuevo módulo en un sistema ya existente. Esta etapa se enfoca en la comprensión y análisis de la iniciativa en los que aún no se tiene claridad de su alcance o necesidad por parte de la secretaría jurídica distrital, con el apoyo del Jefe De Oficina TIC. Por consiguiente, la solicitud para el desarrollo de un sistema de información debe ser elaborada por el responsable del proyecto, en dicha solicitud se deben establecer los requerimientos de operación y definir los recursos necesarios (Humanos, tecnológicos y Económico), para asegurar que el sistema desarrollado contará con el entorno adecuado de funcionamiento. Para ello es necesario hacer uso del formato 2310200-FT-289 Project Charter. El Jefe De Oficina TIC analizará la solicitud, la cual debe contar con un estudio debidamente justificado (objetivos y alcances de la misma) si es aceptada, se asigna personal para que, junto con el Coordinador de Equipo Técnico del proyecto, complete el estudio preliminar, que le permita detallar el proyecto de desarrollo de un sistema de información, posterior a ello si el Jefe De Oficina TIC determina que la solicitud no es aceptada, se le remite un memorando al

https://smart.bogotajuridica.gov.co/SJD/index.php?la=2&li=1&op=2&sop=2.4.2&id_doc=927&version=1&back=1





2310100-FT-120. Versión 02

Responsable del Proyecto en el cual se indican los factores por los cuales la solicitud no es aceptada, en caso de tener viabilidad técnica, se envía a comité MIPG para su aprobación y esta determinará su prioridad, de acuerdo al Plan Estratégico de Tecnologías de la Información -PETI- y el presupuesto Dado el caso puntual que se necesite acompañamiento técnico por parte de terceros, debe ser solicitado a la Gerencia del Proyecto con su respectiva justificación y este tiempo será incluido dentro la etapa de Planificación.

6.2. Estudio Preliminar

El estudio preliminar específica los resultados de la valoración efectuada sobre la solicitud de desarrollo de un sistema de información. Este documento es diseñado en conjunto por el responsable de proyecto y el líder funcional donde se describa la forma como el proceso se está realizando ya sea por un sistema anterior o de forma manual. Para este fin se deberá utilizar el formato Smart Canvas determinado para este fin. En este estudio se debe hacer énfasis en la búsqueda de oportunidades de mejorar los procesos actuales en procura de que el nuevo sistema permita la realización de actividades de forma más eficiente y efectiva.

6.3. Identificación de soluciones y su factibilidad

Establecer las diferentes alternativas (al menos dos) para la construcción del nuevo sistema de acuerdo a los alcances definidos. Para ello es requerido, realizar un análisis de costo/beneficio de las soluciones propuestas para hacer una evaluación de su pre-factibilidad económica definida en términos de costos y ahorros. No sólo tomando en cuenta los costos de implementación del sistema o solución sino también los costos asociados a la actualización permanente de la información. Se debe calcular el costo en cantidad de funcionarios y el tiempo laboral requerido, el equipo y las herramientas a utilizar. En el caso del ahorro se deben considerar los beneficios tangibles e intangibles que se obtienen con el sistema, por ejemplo: tiempo requerido para la actualización o conclusión del proceso, desplazamiento de personas, aprovechamiento de equipo y las herramientas existentes. El nivel de detalle de esta evaluación dependerá directamente de la complejidad del sistema y del tamaño de los recursos disponibles para la elaboración del estudio. En cualquier caso,




2310100-FT-120. Versión 02

deberá contemplar las variables básicas que determinen la viabilidad del sistema y su permanencia en el tiempo. El equipo de desarrollo y contratistas procederán hacer uso del formato Smart Canvas para este fin.

6.4. Análisis integral de requerimientos

La especificación de requerimientos es la descripción precisa y detallada que hace el usuario de las necesidades a ser resueltas con el sistema solicitado y sus restricciones. Para ello, el Líder Técnico debe trabajar en conjunto con el Equipo de trabajo y el líder funcional, de manera que generen experiencia en traducir en requerimientos (descripción precisa y detallada de la funcionalidad del sistema), las necesidades que poseen y le sean muy comprensibles. Para lograr este propósito el responsable de Proyecto puede aportar la documentación que considere pertinente, como formularios y tipos de reportes.

Para que los requerimientos cumplan a cabalidad con la necesidad de los usuarios finales, se debe identificar, analizar y documentar los requerimientos funcionales y no funcionales que debe soportar el sistema o solución propuesta. Los requerimientos funcionales se refieren a las cosas que el sistema debe realizar, por ejemplo, que información se debe registrar y qué manera se debe procesar; los requerimientos no funcionales se refieren a los aspectos operativos del sistema como tiempos de respuesta, respaldos de información. Par este fin se deberá hacer uso del formato REQUERIMIENTOS DETALLADOS DE SOFTWARE donde se consignará la información requerida para el cambio.

6.4.1. Requerimientos funcionales

El Usuario final en compañía con el equipo técnico del proyecto analizan, validan, evalúan el alcance que tendrá el requerimiento para delimitar el ámbito de la solicitud. Bajo la gestión Coordinador de Equipo Técnico del proyecto se convocan a las reuniones de entendimiento necesarias, resultados que serán recopilados en actas de reunión que serán diligenciadas por los responsables de proyecto. Se llevarán a cabo las reuniones de entendimiento necesarias antes de dar inicio a la fase de planificación. Son las indicaciones de servicio que el sistema debe proveer en cuanto a actualización de datos, opciones de consulta, reportes a generar, interacción con otros sistemas, bitácoras de seguimiento y pistas de Auditoria. Entre las características que se espera que posean los requerimientos son:




2310100-FT-120. Versión 02

• Correcto: Cada requerimiento debe describir con exactitud la funcionalidad que se

obtendrá del sistema, de manera que no exista conflicto entre ellos. Debe tener una

referencia a la fuente del requerimiento, sea este el cliente o bien un requerimiento

propio de la implementación del sistema.

• Factible: Se refiere a la posibilidad técnica, operativa y presupuestaria de implementar

cada uno de los requerimientos dentro de la capacidad y limitaciones del sistema y su

ambiente de desarrollo. El desarrollador debe chequear cada uno de los

requerimientos y determinar qué se puede desarrollar y qué no, qué puede

desarrollarse, pero tiene un costo excesivo.

• Necesario: Cada uno de los requerimientos debe documentar una necesidad del

usuario o bien un requisito del sistema, interface o estándar. Debe poder indicarse el

rastro del requerimiento desde su origen, de tal forma que sea válido y por ende

necesario.

• Claro: El lector del documento de requerimientos debe ser capaz de interpretarlo de

una única forma. Para esto cada requerimiento debe describirse en forma sucinta,

simple, en un lenguaje comprensible por el usuario. Para verificar la claridad de los

requerimientos se pueden crear escenarios que ilustren la funcionalidad de porciones

específicas del sistema.

• Verificable: Un requerimiento es verificable si se puede utilizar algún tipo de pruebas

tales como inspección o demostración para determinar si el requerimiento soporta las

necesidades de los usuarios a través del producto. Si el requerimiento no es verificable

determinar si se implementó correctamente o no es un asunto de opinión.

6.4.2. Requerimientos no funcionales

Son las propiedades y restricciones del sistema, pueden ser de índole organizacional, como consecuencia de alguna política organizacional o de procedimiento, o pueden ser de operatividad como los son: confiabilidad, tiempo de respuesta, almacenamiento, capacidades de dispositivos de E/S, migración de herramienta, y conversión de archivos.




2310100-FT-120. Versión 02

6.4.3. Priorización de Requerimientos

Implica asignar una prioridad a cada requerimiento o característica para indicar que tan esencial es incluirlo. Los usuarios tienen una gran cuota de responsabilidad en definir las prioridades. Si todos los requerimientos tienen igual prioridad, se limita la capacidad de reacción del Líder de Proyecto ante nuevos requerimientos determinados durante el desarrollo, recortes en el presupuesto, la salida de un miembro del equipo u otras situaciones inesperadas. La prioridad se debe calcular como una función del valor que agrega el requerimiento a la función del cliente, el costo relativo de implementación y el riesgo técnico asociado a esta implementación. Se recomiendan tres niveles de prioridad:

• Alto: El requerimiento debe incluirse en la próxima entrega del producto.

• Medio: El requerimiento es necesario, pero puede ser incluido en otra versión.

• Bajo: Sería bueno contar con el requerimiento sin embargo no es imprescindible.

6.4.4. Definición de infraestructura tecnológica

Se debe detallar la infraestructura computacional que soportará el sistema cuando esté en operación, a nivel de equipo principal y de usuarios, lenguaje de programación y especificación de la base de datos; y cualquier otro aspecto requerido para el funcionamiento del sistema. En términos generales, el tipo de tecnología a utilizar dependiendo del tipo de sistema.

6.4.5. Cronograma de las fases posteriores del proyecto

Confección del cronograma detallado del proyecto para las siguientes etapas indicando las fechas de inicio y finalización para cada una de ellas, así como los responsables de las actividades. Para ello es necesario hacer uso del formato 2310200-FT-293 PLAN DE GESTIÓN DE CRONOGRAMA

6.5. Diseño conceptual del Proyecto Esta fase tiene el propósito de identificar los primeros elementos de diseño del nuevo sistema. Los insumos principales de esta fase son: el documento de especificación de requerimientos y el documento de análisis.






2310100-FT-120. Versión 02

6.5.1. Identificación de los módulos

Un módulo es una parte o división del sistema. Consiste en agrupar funcionalidad que está relacionada y que soporta un eje o situación específica del negocio sobre la cual se está desarrollando el proyecto.

6.5.2. Descripción de módulos y sub-módulos y su interacción

Con base en el diseño conceptual de la solución, se detalla la estructura modular del sistema en cuanto a la jerarquía de los módulos y la forma en la que interactúan. Además de la descripción de los módulos se debe confeccionar el diagrama de contexto y el diagrama de flujo de datos. El diagrama de contexto establece las relaciones que el módulo tiene con otros sistemas, otros módulos o entidades externas. El diagrama de flujo de datos es la representación gráfica de las entradas, procesos y salidas de un módulo mostrando la interrelación de los procesos.

6.5.3. Identificación de interrelaciones con otros sistemas o módulos

Se refiere a la identificación de sistemas o módulos que estarán relacionados con el sistema en construcción y la descripción de estas relaciones en lo referente al tipo y método de comunicación. Además, se debe indicar si es requerida la modificación de algún sistema existente para ajustarlo a la solución que se está diseñando. En esta actividad es importante que se analice la estructura de datos existente en los sistemas que estarán relacionados para la creación de un modelo lógico de datos en la siguiente fase.

6.5.4. Identificar tipos de usuarios

Identificar los tipos de usuarios y el rol a cumplir por ellos dentro del sistema, especificándose quiénes pueden ingresar, modificar, borrar o consultar información y cuál información. Qué tipos de usuarios utilizan cada uno de los módulos y qué funciones lleva a cabo.

6.6. Diseño de pruebas: Se requiere identificar los tipos de pruebas a realizar: pruebas unitarias, pruebas de módulos, pruebas de integración, pruebas de esfuerzo, tiempos de respuesta y tráfico en la infraestructura de comunicaciones.




2310100-FT-120. Versión 02

• Pruebas unitarias: son las pruebas que se realizan a cada programa del sistema

• Pruebas de módulos: pruebas que se aplicarán a los módulos o partes funcionales del

sistema

• Pruebas de integración: pruebas totales del sistema y de su integración con otros

sistemas

• Pruebas de esfuerzo: comprobación de recursos computacionales para soportar la

aplicación (servidor de bases de datos, servidor web, recursos de las máquinas de

usuario)

• Tiempo de respuesta: verificación de que el tiempo de respuesta es aceptable de

acuerdo con los estándares de la industria

• Tráfico en la infraestructura de comunicaciones: comprobación de capacidad de

transmisión de datos (ancho de banda) para la operación del sistema.

6.6.1. Requerimientos para las pruebas La plataforma de “Hardware”, “Software”, conectividad y base de datos requerida. Si el sistema tendrá integración con otros sistemas o módulos deberá disponerse de un ambiente de pruebas de dichos sistemas.

6.6.2. Casos y datos de prueba Identificar todos los escenarios posibles con diversidad de datos de entrada y acciones realizadas por el usuario, con el propósito de identificar posibles puntos de error en el sistema. Si se requiere la existencia de datos para las pruebas, se deberá señalar el método de captura de éstos en las estructuras de la base de datos.

6.6.3. Usuarios para las pruebas Determinar las características y cantidad de los usuarios que serán requeridos en el proceso de pruebas y el tiempo a invertir en dicho proceso. Esto es importante para que las Unidades puedan efectuar la coordinación correspondiente con la debida anticipación.




2310100-FT-120. Versión 02

Con el fin de entrega resultados de las pruebas de software se validará un grupo finito de casos de prueba, debidamente seleccionados del ámbito de ejecuciones en relación al comportamiento esperado. Contrario a lo que se pueda pensar una prueba exitosa es aquella en la que se consigue que el sistema falle y por tanto, se encuentran errores, aunque estos no sean todos los que posee el producto.

De igual forma se puede considerar una prueba exitosa cuando es posible asegurar que no existen más errores en el sistema, cuestión que es mucho más difícil de garantizar.

Específicamente las pruebas de software permiten evaluar las soluciones y determinar el nivel de calidad que poseen, por lo que se debe definir un proceso que se pueda emplear en el entorno de desarrollo de aplicaciones informáticas en la secretaria jurídica distrital.

Con el fin de documentar las pruebas se requerirá hacer uso del formato 2310200-FT-290 PLAN DE PRUEBAS DE LA SOLUCIÓN

6.7. Construcción y desarrollo del Proyecto El objetivo de la presente fase es plasmar en un producto Software las especificaciones técnicas y funcionales derivadas del Diseño. El Arquitecto dirige el desarrollo de la arquitectura, difunde ante el líder Técnico y el Equipo de Desarrollo los patrones a implementar, rigiéndose por el estándar de Arquitectura. En esta fase se desarrolla y documenta el código fuente, es muy importante el acompañamiento del responsable de proyecto, líder Funcional y el Coordinador de Equipo Técnico del proyecto

6.7.1. Implementación del modelo físico de datos Se recomienda escribir las rutinas (scripts) para la creación de objetos en la base de datos de acuerdo con el modelo entidad relación, especificando llaves primarias y llaves foráneas de acuerdo con el tamaño de los registros y de las tablas en los estándares establecidos.

6.7.2. Creación de roles y usuarios




2310100-FT-120. Versión 02

Se crean los roles y se asocian a los usuarios según las acciones que les correspondan. Se debe generar una rutina para la creación de los roles y la implementación de la seguridad en la base de datos.

6.7.3. Programación Durante el desarrollo de esta etapa se generan los programas que componen el Sistema de Información. Conforme se avanza en la programación se debe documentar cada uno de los componentes generados de acuerdo con el estándar definido. Adicionalmente el desarrollador deberá adoptar los estándares establecidos en nomenclatura, manejo de versiones, y documentación de los programas que establece el manual de estándares.

6.7.4. Conversión y levantamiento de datos En caso de requerirse una migración de datos desde una aplicación anterior o bien desde un ingreso masivo de información, se deberá tomar en cuenta la depuración que requiera esta información. El Coordinador de Proyecto deberá considerar este traspaso como un sub-proyecto adicional, donde incluirá los requerimientos de recurso humano y tecnológico para su ejecución, asimismo deberá negociar estos recursos. Esta conversión o ingreso masivo de información se ejecutará durante la etapa de implantación. Cada uno de los módulos generados deberá estar sujeto a una revisión de su funcionalidad por parte del Coordinador de Proyecto o quien él designe y a una revisión de tipo técnico para garantizar su calidad.

6.7.5. Documentación del proyecto Son todos los documentos generados por su organización y ejecución. El archivo del proyecto debe contener los documentos a entregar en cada una de las fases: 1. Documentos de organización del proyecto

• Cronograma original

• Cronograma ajustado

• Correspondencia generada




2310100-FT-120. Versión 02

2. Solicitud para el desarrollo de un sistema de información

• Oficio de solicitud

• Informe de diagnóstico

• Oficio de resultado del estudio

• Solicitud de aprobación

3. Análisis integral de requerimientos

• Especificación de requerimientos

• Priorización de requerimientos

• Documento de análisis

4. Diseño conceptual de la solución

• Documento conceptual del proyecto

5. Diseño detallado de la aplicación

• Documento de diseño detallado

• Diseño de pruebas

6. Programación y pruebas

• Scripts de creación de objetos

• Inventario de componentes de programación

• Constancia de pruebas

• Aceptación del sistema

7. Capacitación

• Constancia de la capacitación

8. Implementación

• Plan de implementación

• Aprobación del inicio de operación

• Entrega del sistema

9. Manual de usuario

10. Manual técnico




2310100-FT-120. Versión 02

6.7.5.1. Manual de usuario El manual del usuario debe ser conciso y práctico, sin dejar de ser exhaustivo, de manera que los usuarios encuentren en él toda la información necesaria para interactuar con el sistema. Se debe combinar la descripción textual, con la gráfica, de manera que al usuario se le facilite su uso. El manual debe contener lo siguiente: 1. Introducción 2. Estándares del Sistema 3. Cómo se ingresa al Sistema 4. Descripción del Menú Principal del Sistema 5. Descripción textual y gráfica de cada pantalla (sea de registro o consulta) 6. Descripción del uso e impresión de reportes

6.7.5.2. Manual técnico En este manual se deben describir, de manera detallada, todos los componentes del sistema desde el punto de vista técnico. En dicha documentación deben explicarse todos los aspectos necesarios para el posterior mantenimiento de la aplicación.

6.8. Capacitación De acuerdo con la complejidad en el uso del sistema desarrollado y de la cantidad de usuarios del sistema, se debe coordinar el lugar, hora y cantidad de sesiones que va a comprender la capacitación de usuarios. En caso de ser necesario se coordinará con la dirección corporativa de manera que la capacitación se lleve por medio de una interacción total sistema-usuario.

6.9. Puesta en producción El Coordinador de Proyecto, siguiendo criterios de impacto, materialidad, riesgo asociado, sensibilidad y criticidad de la información involucrada, deberá considerar el tipo de pruebas adicionales que requiera el proyecto, logrando un adecuado balance costo/beneficio. Entre otras podrá considerar pruebas en paralelo cuyo objetivo será el verificar que el sistema nuevo arroja resultados similares al sistema que estuviera en ese momento en funcionamiento – manual o automatizado), pruebas de tensión cuyo objetivo es poner a prueba al sistema y la




2310100-FT-120. Versión 02

plataforma frente a una fuerte demanda de los servicios. Estas pruebas pueden ser reales o simuladas, dependiendo de la disponibilidad de recursos humanos y tecnológicos.

6.10. Instalación del sistema Las actividades incluirán preparar los aspectos restantes del ambiente físico y computacional para dar inicio con la operación del sistema Para lo anterior y de acuerdo a las características del sistema, se recomienda lo siguiente:

• Iniciar las estructuras de seguridad de acceso al sistema: identificación de usuarios,

palabras de paso y atributos de usuario (roles), con la finalidad de garantizar que el

ingreso al sistema en operación se realizará de forma segura.

• Verificar que los requerimientos de “hardware”, “software” y comunicaciones se

encuentran disponibles.

• Verificar que en los sitios de instalación del sistema, se encuentre disponible el

mobiliario, la instalación eléctrica (toma corrientes, conexión a tierra, protectores de

picos) y el espacio físico acondicionado.

• Verificar que los materiales que use el sistema se encuentren disponibles. Por ejemplo

formularios especiales, papelería, cintas para impresora, disquetes, CD´s, cajas de

seguridad para disquetes, cobertores para el equipo, así como todos los otros

materiales requeridos.

• Realizar la instalación del sistema en el ambiente de producción en coordinación con

el DBA.

6.11. Conversión y carga inicial automatizada de datos En caso de requerirse una migración de datos sea de una aplicación anterior o bien un ingreso masivo de información, el Líder de Proyecto deberá considerar este traspaso como un sub-proyecto, donde incluirá los requerimientos de recurso humano y tecnológico para su ejecución y sus respectivos controles de calidad y completitud. Las actividades a realizar son las siguientes:




2310100-FT-120. Versión 02

• Confirmar que el ambiente computacional ("software", "hardware") y personal,

requerido para la carga de los datos al sistema, se encuentre disponible, según lo

indicado en el plan. De lo contrario, realizar los ajustes necesarios para asegurar que

la carga de los datos iníciales se haga en una forma satisfactoria.

• Ejecutar las aplicaciones construidas para la conversión y carga inicial de los datos al

sistema.

• Es recomendable realizar una depuración de los datos por convertir, para asegurar

que no se incluyan datos erróneos al sistema.

• Verificar que los datos introducidos se encuentren correctos y completos,

considerando los resultados obtenidos

• Comprobación por parte del Líder del Proyecto y del analista responsable, que la

conversión y carga de datos se realizó en una forma satisfactoria.

6.12. Ejecución del paralelo Las actividades incluirán determinar la necesidad de ejecución de un procesamiento en paralelo, realizando una justificación. Esta decisión la tomará el Líder Técnico en conjunto con el usuario responsable, considerando las características del sistema en cuanto a la necesidad de un paralelo.

• Determinar la duración y forma del paralelo, de acuerdo con la naturaleza y

complejidad del sistema.

• Determinar las funciones y responsabilidades del personal técnico y del usuario que

participa en el paralelo.

• Establecer los criterios de aceptación esperados, para evaluar los resultados que se

tengan al final de la ejecución del paralelo.

• Iniciar el paralelo brindando asistencia al usuario en forma continua, para asegurar

que los procedimientos se realizan en la forma correcta. Asimismo, identificar y

corregir los problemas que se presenten.

• Documentar los resultados de la ejecución del paralelo, considerando los criterios de

evaluación establecidos. Indicar el criterio de aceptación considerado y el nombre de

la persona que aprueba.

• Dar un visto bueno, por parte del Líder del Proyecto y del analista responsable,

haciendo constar que el paralelo se concluyó en forma satisfactoria.




2310100-FT-120. Versión 02

6.13. Aprobación formal del sistema para el inicio de su operación. Esta aprobación la hace el Solicitante, mediante un acta de aceptación y puesta en operación del sistema. Aquí se confirma que el sistema terminado cumple con los requisitos acordados al final de la Etapa de Construcción.

6.14. Hacer la entrega del sistema al Responsable del Proyecto. El Responsable del Proyecto y el Jefe de la oficina TIC notificarán, formalmente, a los usuarios, y a la dirección corporativa, si es del caso, acerca de la puesta en operación del sistema desarrollado

6.15. Hacer la entrega de programas fuente Cuando el sistema cuenta con la aceptación del Responsable del Proyecto y el coordinador de Proyecto, y está instalado en los equipo de producción se deberá entregar, para sus custodia, todos los programas, fuente en su versión final, generados en el desarrollo del sistema. Estos programas deben ir acompañados de la documentación especificada en el procedimiento. Además, se debe depurar el inventario de programas de manera tal que solo se haga entrega de los que realmente se requieren para la operación del sistema (borrar los programas temporales o transitorios, versiones de prueba y cualquier otro programa que no es definitivo)

6.16. Evaluación post-implementación Es necesario que, realizada la implantación del sistema, se dé el tiempo necesario (de una semana a 3 meses según el tamaño del sistema), para que se realice una evaluación de éste y se hagan los ajustes necesarios, de manera que los usuarios finales satisfagan los requerimientos previamente establecidos a implementarse en esta versión. Esta etapa supone la realización de una sesión con el equipo de proyecto para discutir las lecciones aprendidas en el proceso de desarrollo e implantación, de donde incluso pueden derivarse mejoras a ser incorporadas a esta Guía Metodológica de acuerdo al proceso




2310100-FT-120. Versión 02

establecido para su actualización. Adicionalmente se generará una rendición de cuentas final y la relación costo/beneficio efectiva del proyecto.

7. MANTENIMIENTO DE SISTEMAS

Para el mantenimiento del sistema se tiene que elaborar la solicitud de modificación por escrito por parte del Responsable del Proyecto. Una vez aprobado el ajuste, se conforma el equipo de trabajo para el desarrollo correspondiente.

7.1 Planificación de la fase de mantenimiento

Para llevar a cabo el mantenimiento se debe hacer una lista con las actividades por medio de las cuales éste se realizará. Con esta lista de actividades, se determinará si es necesario formular un cronograma para esta etapa, o simplemente efectuar un acuerdo entre el Líder de Proyecto y el Líder Técnico sobre cómo se realizará, y cuál será el alcance que tendrá. Es necesario que se asignen los recursos necesarios (humanos, técnicos, y materiales), así como establecer un calendario de seguimiento: fechas de reunión con el Comité de Usuarios y fechas de validación con el Usuario Solicitante.

7.2 Especificación de los nuevos requerimientos

En la misma forma en que fueron especificados en la fase de análisis de requerimientos, deben ser especificadas las nuevas necesidades. Podría ser que obedezcan a solicitudes que anteriormente tuvieran muy baja prioridad, por lo que no se les tomó en cuenta en esa oportunidad. De ser así debe quedar claro en el nuevo listado. Para especificarlos debe existir una sesión de trabajo, en la cual el Líder Técnico deje claro qué se puede atender y qué no, de manera que todos los requerimientos que sean viables se implementen en el mantenimiento, con el visto bueno del Líder de proyecto.

7.3 Ajustes en programación y pruebas




2310100-FT-120. Versión 02

Realizar los ajustes correspondientes a la programación y la base de datos, si esto fuera necesario, para dar cumplimiento a lo solicitado. Además, se debe valorar el tipo de pruebas a realizar (pruebas funcionales y pruebas de integración) según el impacto de los nuevos requerimientos en el sistema. Es importante que se asegure que las pruebas aplicadas cubren todos los aspectos afectados por las recientes modificaciones en el sistema para asegurar la estabilidad de la aplicación.

7.4 Actualización de la documentación y los programas fuente Realizar los ajustes que correspondan en la documentación del sistema, tanto a nivel de manual de usuario, manual de operación y manual técnico, con la finalidad de que dichos documentos se mantengan vigentes en todo momento. Los cambios realizados en la programación y la base de datos deben manejarse como versiones de acuerdo con lo establecido en el estándar respectivo.

7.5 Implementación de los cambios Con todos los ajustes aprobados y efectuada la capacitación, se realizarán los ajustes en el equipo de producción (tanto en equipo principal como en equipo periférico, según corresponda), implementando el sistema actualizado.

7.6 Evaluación post-implementacion Dependiendo del tipo de ajuste realizado, se deberá realizar una etapa de post-implantación. Los motivos por los que un sistema informático puede desajustarse son muchos: el deterioro provocado por el uso, su obsolescencia, uso inadecuado, etc por consiguiente anteponerse a estos problemas suele ser mucho más rentable a la larga que optar por un mantenimiento correctivo. Para ello hacer uso del formato 2310200-FT-300 INFORME DE REVISIÓN POST IMPLEMENTACIÓN 7.7 Seguimiento y mejoramiento a los sistemas de información El modelo que se presenta a lo largo de este documento se enfoca en “La implementación de requerimientos de software”, aplicado a la recepción y atención de tres (3) tipos de solicitudes:




2310100-FT-120. Versión 02

• Mantenimiento preventivo: Es el orientado a modificar el software o aplicativo para

mejorar sus propiedades en términos de calidad, mantenibilidad, seguridad u otra

característica del sistema de información. Corresponden a proyectos que se

constituyen como un avance o desarrollo de una funcionalidad ya existente, busca la

reducción de tiempos de transacción y el mejor manejo de recursos (almacenamiento,

procesamiento).

• Mantenimiento evolutivo o adaptativo: Es el que permite adecuar o ajustar el software

a un cambio normativo o de procedimiento. Surgen como consecuencia de la

necesidad de ajustar el sistema a requerimientos de carácter legal tanto de

normatividad externa de la entidad (leyes, normas técnicas, regulaciones), como de

normatividad interna (políticas, normas e instrucciones técnicas internas).

• Mantenimiento correctivo: Es el orientado a corregir defectos de funcionamiento y

seguridad del software. Este tipo de mantenimiento se reporta a través de la

herramienta de “Gestión de Incidentes” para lo cual el líder del proceso asigna al

equipo de soporte. Este tipo de mantenimiento se atenderá bajo el proceso de Gestión

de Incidentes ITIL.

Con el fin de controlar todo el proceso de cambios, la gestión de cambios permite a la entidad mantenerse al tanto de todas las solicitudes de cambios. También facilita la identificación y reducción de los cambios no autorizados. Al permitir que los usuarios envíen una solicitud de cambio (RFC) solo a través de la herramienta de la mesa de servicio, la secretaria jurídica puede recopilar toda la información necesaria sobre el cambio desde el principio y luego decidir si realmente es necesario implementar el cambio. Un mecanismo de aprobación robusto garantiza que los cambios reciban todos los permisos necesarios antes de su implementación, para ello es necesario hacer uso del formato 2310200-FT-278 REGISTRO DE CAMBIOS RFC 8 RECEPCIÒN DOCUMENTACIÓN SOFTWARE





2310100-FT-120. Versión 02

Con el fin de hacer entrega al almacén y llevar el control de los aplicativos que sean adquiridos por la entidad se requerirá hacer uso del formato 2310200-FT-065 RECEPCIÒN DOCUMENTACIÓN SOFTWARE, que se encuentra disponible en el SMART.

CONTROL DE CAMBIOS.

ACTIVIDADES O NUMERALES

QUE CAMBIARON CAMBIOS EFECTUADOS

FECHA DEL

CAMBIO VERSIÓN

Creación del Documento N.A. 15/10/2021

01

guÍa metodolÓgica para el desarrollo de sistemas de

Documents