guÍa para el ciclo de vida de una sistema de informaciÓn

GUÍA PARA EL CICLO DE VIDA DE UNA SISTEMA DE INFORMACIÓN

MINISTERIO DE SALUD Y PROTECCIÓN SOCIAL BOGOTÁ, JULIO DE 2018

PROCESO

CICLO DE VIDA Y REINGENIERÍA DE SISTEMAS DE INFORMACIÓN

Código CVSG01

GUÍA Guía para el Ciclo de Vida de un

Sistema de Información Versión 01

Página 2 de 25 Una vez impreso o descargado este documento se considera copia no controlada ASIF04- Versión 1

TABLA DE CONTENIDO

1. OBJETIVO .................................................................................................................................................... 3

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

3. ÁMBITO DE APLICACIÓN ........................................................................................................................... 3

4. DOCUMENTOS ASOCIADOS A LA GUÍA................................................................................................... 3

5. NORMATIVA Y OTROS DOCUMENTOS EXTERNOS ................................................................................ 3

6. DEFINICIONES ............................................................................................................................................. 4

7. CONSIDERACIONES ................................................................................................................................... 4

8. DESCRIPCION PROCESO DEL CICLO DE VIDA DE UN SISTEMA DE INFORMACIÓN ......................... 5

8.1 Diagrama de Flujo procedimiento “Gestión del desarrollo y/o mantenimiento de software misional” .... 6

8.2 Solicitar el desarrollo y/o mantenimiento de software misional ............................................................. 7 8.3 Analizar la solicitud de servicio o requerimiento. ................................................................................... 7

8.4 Definir el alcance, la estructura, los requerimientos y el cronograma de actividades. ........................... 8 8.5 Realizar el levantamiento de información. ............................................................................................. 9 8.6 Efectuar el análisis de la información recolectada ............................................................................... 10 8.7 Solicitar la Infraestructura para Disponer los Ambientes de Desarrollo y Prueba ............................... 12 8.8 Realizar el Diseño del Software .......................................................................................................... 13 8.9 Realizar el desarrollo de Software ....................................................................................................... 14

8.10 Verificar el cumplimiento de las especificaciones del sistema............................................................. 15 8.11 Verificar Software Seguro ................................................................................................................... 17 8.12 Realizar la publicación del Software en ambiente de pre-producción y gestionar aprobación del área funcional ......................................................................................................................................................... 18

8.13 Sensibilizar el uso del sistema de información .................................................................................... 19 8.14 Realizar la puesta en producción del Sistema de Información o Mantenimiento de Software............. 20

8.15 Analizar el mantenimiento de software o atención a incidencias del sistema de información ............. 21 8.16 Realizar seguimiento a proyectos del proceso CVS ............................................................................ 22

ANEXO 1. TABLA DE CONTENIDO DE LOS MANUALES .............................................................................. 24

PROCESO


Código CVSG01




1. OBJETIVO

Orientar el desarrollo de las actividades descritas en el Proceso del Ciclo de Vida y Reingeniería de Sistemas de Información CVSC01, usado por la Oficina TIC en los proyectos del Ministerio de Salud y Protección Social – MSPS.

2. ALCANCE

Se escribe el conjunto de actividades que se deben llevar a cabo para el:

- Desarrollo de nuevos sistemas de información seguros. - Mantenimiento de sistemas de información ya existentes. - Reingeniería sobre sistemas de información.

3. ÁMBITO DE APLICACIÓN

Aplica a los procesos misionales en sus sistemas de información.

4. DOCUMENTOS ASOCIADOS A LA GUÍA

- Proceso CVSC01 Ciclo de Vida y Reingeniería de Sistemas de Información. - Procedimiento CVSP01 Gestión del Desarrollo y/o mantenimiento de Software Misional. - Procedimiento CVSP03 Gestión de la Mesa de Ayuda Tecnológica Misional. - Formato ASIF06 Listado de Asistencia a Reuniones. - Formato CVSF01 Alcance del Proyecto. - Formato CVSF02 Estructura del Proyecto. - Formato CVSF03 Actores. - Formato CVSF04 Especificación de Requerimientos. - Formato CVSF05 Anexo Técnico para Reporte de Información. - Formato CVSF06 Solicitud de Transporte de Anexo Técnico a través de PISIS. - Formato CVSF07 Caso de Uso. - Formato CVSF08 Diccionario de datos. - Formato CVSF10 Mantenimientos Software Especificación. - Formato CVSF11 Solución Incidencia de Software. - Formato CVSF19 Prueba Funcional. - CVSG02 Guía para la Migración de Bases de Datos.

5. NORMATIVA Y OTROS DOCUMENTOS EXTERNOS

- Decreto 4107 de 2011: Artículo 10. Funciones de la Oficina de Tecnología de la información y la comunicación – OTIC.

PROCESO


Código CVSG01




6. DEFINICIONES

Artefacto: producto tangible resultante del proceso de desarrollo de software. Son artefactos los casos de uso, diagrama de clases u otros modelos UML que ayudan a la descripción de la función, la arquitectura o el diseño del software. Otros se enfocan en el proceso de desarrollo en sí mismo, como planes de proyecto, casos de negocios o enfoque de riesgos. El código fuente compilado para las pruebas se suele considerar un artefacto.

Diagrama de Casos de uso: representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos: i) Actor, ii) Casos de Uso, iii) Relaciones de Uso, Herencia y Comunicación.

Revisión: actividad emprendida para asegurar la conveniencia, adecuación, eficacia eficiencia y efectividad del tema objeto de la revisión, para alcanzar unos objetivos establecidos.

Stackeholder: son llamados interesados o involucrados en un problema determinado, y que necesitan una solución. Desde el punto de vista del desarrollo de sistemas, un "stakeholder" es aquella persona o entidad que está interesada en la realización de un proyecto o tarea, auspiciando el mismo ya sea mediante su poder de decisión y/o de financiamiento o a través de su propio esfuerzo. En la gestión de proyectos, los involucrados o interesados son todas aquellas personas u organizaciones que afectan o son afectadas por el proyecto, ya sea de forma positiva o negativa. El SRI (Stanford Research Institute), los define como: “Cualquier grupo o individuo identificable que pueda afectar el logro de los objetivos de una organización o que es afectado por el logro de los objetivos de una organización (grupos de interés público, grupos de protesta, agencias gubernamentales, asociaciones de comercio, competidores, sindicatos, así como segmentos de clientes, accionistas, empleados, ciertos proveedores, ciertas instituciones financieras y otros.

Seguridad de la Información: Preservación de la confidencialidad, integridad y disponibilidad de la información.

7. CONSIDERACIONES

De acuerdo al alcance que se dé al proyecto y a la disponibilidad de medios humanos, técnicos y recursos financieros, puede

optarse por llevar a cabo la contratación de un tercero o proveedor de desarrollo de software para que realice el desarrollo del sistema que se requiere y la implementación del mismo en el Ministerio de Salud y Protección Social; en cuyo caso se deberá iniciar el proceso pre-contractual. Un profesional de la Oficina TIC, asignado por la Jefatura de la misma será el responsable por ejercer la supervisión del contrato que se suscriba entre la Oficina TIC y el proveedor.

Para orientar las actividades de la Oficina TIC relacionadas con los requerimientos funcionales, análisis, diseño y desarrollo de soluciones de software, se debe consultar el documento GVTS01 Lineamientos generales de operación para la OTIC, en el cual se encontrarán entre otros aspectos relacionados con las herramientas de software que usa la Oficina TIC.

Durante el tiempo en que se ejecute el desarrollo del sistema de información y su puesta en producción, se hará seguimiento a la ejecución del plan del proyecto y se realizarán los ajustes respectivos en caso de ser necesario.

El desarrollo de software puede ser realizado bajo diferentes aproximaciones de desarrollo, incluyendo métodos ágiles. Con el fin de hacer convivir estos tipos de aproximaciones, la guía a continuación descrita hace referencia a diferentes tipos de artefactos, los cuales podrán ser seleccionados y/o ajustados por cada proyecto según su complejidad. Sin embargo, hay algunos parámetros que son obligatorios para todos los proyectos, por lo que se hará la diferenciación con los artefactos opcionales.

PROCESO


Código CVSG01




8. DESCRIPCION PROCESO DEL CICLO DE VIDA DE UN SISTEMA DE INFORMACIÓN

En la Figura se presenta el Diagrama de Flujo del Ciclo de Vida de un sistema de Información, donde se presentan las diferentes etapas que contiene en general el Ciclo de Vida de un Sistema de Información.

Estas etapas son:

Alcance del proyecto

Especificación y Análisis y de requerimientos

Análisis y diseño

Desarrollo de Software

Pruebas de Software

Sensibilización

Puesta en producción

Mantenimiento y estabilización Teniendo como base estas etapas a continuación se presenta el Diagrama de Flujo correspondiente al procedimiento “Gestión del desarrollo y/o mantenimiento de software misional” del proceso Ciclo de Vida y Reingeniería de Sistemas de Información.

Alcance del proyecto

Especificación y análisis de

requerimientos Análisis y diseño

Desarrollo de software

Pruebas de software

Sensibilización Puesta en

producción Mantenimiento y Estabilización

8.1 Diagrama de Flujo procedimiento “Gestión del desarrollo y/o mantenimiento de software misional”

PROCESO


Código CVSG01




A continuación, se describe cada etapa del procedimiento “Gestión del desarrollo y/o mantenimiento de software misional”- CVSP01.

8.2 Solicitar el desarrollo y/o mantenimiento de software misional

Objetivo: En esta etapa las dependencias del Ministerio de Salud y Protección Social, manifiestan sus necesidades para el cumplimiento de sus funciones misionales que requieren apoyo de los Sistemas de Información, a través del diligenciamiento de un formato de solicitud de servicio. Entrada:

Documento de Normatividad bien sea ley, resolución o decreto, un documento técnico de política o un correo que genera la necesidad del sistema o mantenimiento.

Metodología: El Jefe de la dependencia del Ministerio o su delegado manifiesta una necesidad que requiere para el cumplimiento de sus funciones, la cual posteriormente se evidencia con el diligenciamiento de un formato estándar establecido para ser formalizado su requerimiento a la Oficina de TIC. Salida:

Formato GVTF01 Solicitud Servicio de requerimiento diligenciado

8.3 Analizar la solicitud de servicio o requerimiento.

Objetivo: En esta etapa, una vez recibida la solicitud, se direcciona al profesional competente de la Oficina de TIC para su análisis y verificación de la aceptación o rechazo de la misma. Entrada:

Formato GVTF01 Solicitud Servicio de requerimiento diligenciado Metodología: Recibida la solicitud, el Jefe de la Oficina de TIC asigna al Profesional de la Temática correspondiente según la solicitud. Posteriormente, cuando el profesional de la Temática recibe la asignación verifica si es procedente el desarrollo de este requerimiento, en caso de no serlo, se envía comunicado (oficio o correo electrónico) informando a la dependencia misional el estado de su solicitud. Una vez aprobada la solicitud, se determina la prioridad de la misma, teniendo en cuenta los siguientes criterios: A. Prioridad Alta:

Solicitudes originadas por normas aprobadas, con fecha de operación menor a tres meses.

Solicitudes generadas por afectación crítica de la operación de los aplicativos misionales del MSPS.

B. Prioridad Media:

Solicitudes originadas por normas aprobadas, con fecha de operación mayor a tres meses.

Solicitudes generadas por afectación NO crítica de la operación de los aplicativos misionales del MSPS.

C. Prioridad Baja:

Todas las Solicitudes que no afecten en forma crítica la operación de los aplicativos misionales del MSPS, las cuales serán atendidas de acuerdo a la fecha de la solicitud.

PROCESO


Código CVSG01




Si la solicitud aprobada corresponde a un desarrollo nuevo, continúa a la etapa “Definir el alcance, la estructura, los requerimientos y el cronograma de actividades”, y si corresponde a un mantenimiento, debe ejecutar la etapa “Realizar el mantenimiento o atención a incidencias del sistema de Información”. Salida:

Comunicación (oficio o correo electrónico) al área funcional informando el tratamiento que se va a dar a esta solicitud.

8.4 Definir el alcance, la estructura, los requerimientos y el cronograma de actividades.

Objetivo: Establecer lo que está dentro de las fronteras del proyecto: lo qué ha de resolverse durante la realización del proyecto y cuáles aspectos se dejarán fuera. Si es necesario, se puede especificar todo aquello que se posponga hasta una versión posterior del sistema. Entrada:

Formato GVTF01 Solicitud Servicio de requerimiento diligenciado

Documento técnico de política o normatividad que genera la necesidad del sistema, si aplica

Comunicación (oficio o correo electrónico) al área funcional informando el tratamiento que se va a dar a esta solicitud.

Documentos de referencia:

Lineamientos del Manual de la política de Gobierno Digital en el marco de referencia de Arquitectura TI.

Políticas en materia de información expedidas por el DNP- Departamento Nacional de Planeación y el DANE- Departamento Administrativo Nacional de Estadística.

Metodología: En esta etapa, el profesional de la Oficina TIC asignado para atender el requerimiento, convocará una o más sesiones de trabajo con el o los usuarios funcionales responsables, llevando registro de las mismas en el formato ASIF06 Listado de Asistencia a Reuniones. Estas reuniones tienen como objetivo definir y formalizar los siguientes temas:

Alcance del proyecto, diligenciando el formato CVSF01 Alcance del Proyecto (project chárter), en el cual se delimita el ámbito del proyecto describiendo en forma breve los factores críticos de éxito, sus riesgos y oportunidades, alcance general, objetivo general, los objetivos específicos y criterios de aceptación. Es decir recopilar la descripción de la funcionalidad que tendrá el sistema de información, sus características principales y sus objetivos claves. En caso que se requiera mayor información para dimensionar los alcances del sistema o implicaciones en la programación del mismo, se deberá acordar con los responsables de la dependencia del Ministerio (área usuaria).

Estructura del proyecto, a través del formato CVSF02 Estructura del Proyecto, donde se registra el equipo de trabajo conformado que estará apoyando el desarrollo del proyecto, identificando los roles (Líder de proyecto por parte de OTIC, Líder de proyecto por parte de área funcional, desarrolladores, analistas de pruebas del área funcional, capacitadores y usuarios), sus relaciones y responsabilidades dentro del proyecto.

Se recomienda que en el equipo de trabajo se cuente con personas de la siguiente formación: i) Ingeniero(s) de Sistemas de la Oficina TIC para apoyar la identificación de requerimientos, análisis, desarrollo del software y pruebas de seguridad ii) Ingeniero de procesos o industrial, para apoyar a la dependencia del ministerio en la definición y/o actualización de los procesos y procedimientos operativos que se vean impactados por el nuevo sistema de Información iii) funcionarios de la dependencia del ministerio, que van a recibir el software y que conozcan de la necesidad presentada.

PROCESO


Código CVSG01




Documento que contenga el cronograma de actividades, donde se establezca como mínimo los tiempos, responsables y actividades pertinentes del proyecto. Es importante que el líder por parte de la dependencia usuaria que generó la necesidad, participe en su construcción. Como parte de la Gestión del proyecto, la primera sesión de trabajo será identificada como la reunión de inicio, por cada reunión de trabajo se debe diligenciar el formato de control de asistencia ASIF06 Listado de Asistencia a Reuniones. Teniendo en cuenta lo anterior, en caso que el desarrollo requiera contratación externa, se notificará al área funcional para gestionar la contratación necesaria para ser atendida la solicitud –ver Proceso GCOC01 Gestión Contractual-, y una vez realizada la contratación, se ajustan el alcance, la estructura del proyecto, los requerimientos y el cronograma de actividades. Salida:

Formato CVSF01 Alcance del Proyecto diligenciado.

Formato CVSF02 Estructura del Proyecto

Formato ASIF06 Listado de Asistencia a Reuniones diligenciado.

Documento que contenga cronograma definido entre las partes.

8.5 Realizar el levantamiento de información.

Objetivo: Obtener la información necesaria, los insumos requeridos que permitan establecer los requerimientos funcionales y no funcionales, así como los intervinientes o actores del sistema con su respectivo rol. Entrada:

Formato CVSF01 Alcance del Proyecto diligenciado.

Formato CVSF02 Estructura del Proyecto

Documento que contenga cronograma definido entre las partes. Descripción: Las necesidades de las partes interesadas en el proyecto son la base para determinar los requisitos del sistema, así como las expectativas, limitaciones, interfaces, conceptos operativos y conceptos de producto de las partes interesadas, las cuales se analizan, armonizan, refinan y elaboran para su traducción a un conjunto de requerimientos de los usuarios. Ocasionalmente, y en procesos específicos que así se determine en el alcance del proyecto, los requerimientos se especificaran de manera iterativa durante toda la vida del proyecto para lograr el objetivo del sistema; no obstante, los requerimientos aprobados por el usuario quedaran en firme como base para la siguiente etapa y sus modificaciones se realizarán con control de cambio. Los requerimientos se identifican y refinan a lo largo de las fases del ciclo de vida del producto. Decisiones de diseño, acciones correctivas posteriores y la retroalimentación durante cada fase del ciclo de vida del producto se analiza para determinar el impacto en los requerimientos derivados. En la especificación de los requerimientos se sugiere tener en cuenta las siguientes actividades:

Identificación de los actores relacionados con el sistema directa o indirectamente.

Recopilación y coordinación de las necesidades de las partes interesadas

Identificación de los requerimientos del producto

Identificar requerimientos de seguridad de la Información

Establecimiento del cliente funcional y los atributos de calidad requeridos

Establecimiento de los requisitos iniciales del producto y del componente del producto de acuerdo con las necesidades del cliente

Aprobación de especificación de requerimientos por el usuario funcional.

PROCESO


Código CVSG01




Metodología: En esta etapa, el profesional de la Oficina TIC asignado para atender el requerimiento, convocará una o más sesiones de trabajo con el o los usuarios funcionales responsables, en donde se formularán preguntas como: ¿Qué se está haciendo actualmente?, ¿De qué manera se está haciendo?, ¿Qué se quiere mejorar?, ¿Cómo se puede mejorar?, ¿Qué esperan los involucrados en el proyecto?, ¿Quiénes son los intervinientes (actores) del proceso y su interacción (Rol) en el mismo?, las cuales tienen como objeto establecer los requisitos del solicitante. Aunado a lo anterior, se llevará el registro de estas reuniones en el formato ASIF06 Listado de Asistencia a Reuniones. Con respecto a proyectos que impliquen el reporte de información a través de la plataforma PISIS, inicialmente se comenzará a elaborar el acto administrativo por parte de la Dependencia Misional, en el cual se indica los intervinientes del proceso, la obligatoriedad del reporte de información y la estructuración de la información a reportar a partir del Formato(s) CVSF05 Anexo Técnico para Reporte de Información. Posteriormente, se diligenciará el Formato CVSF06 Solicitud de Transporte de Anexo Técnico a través de PISIS donde se debe relacionar toda la información de que trata el Anexo Técnico, el objetivo, la gestión que requiere recibir la información, los responsables, el servicio de mesa de ayuda. Todo lo anterior con el fin de que se garantice la disponibilidad de la plataforma. Salida:

Formato CVSF03 Actores

Formato(s) CVSF04 Especificación de Requerimientos diligenciado(s)

Formatos CVSF05 Anexo Técnico para Reporte de Información diligenciado.

Formato ASIF06 Listado de Asistencia a Reuniones diligenciado.

8.6 Efectuar el análisis de la información recolectada

Objetivo: Analizar los requisitos aprobados y establecidos en la etapa anterior, es decir definir el producto o componente del producto y componente de seguridad, con el fin de modelar una solución que satisfaga las necesidades de los usuarios internos y externos. Así mismo, documentar los requerimientos de manera más detallada con sus requisitos aprobados y establecidos mediante casos de uso. Entrada:



Formatos CVSF05 Anexo Técnico para Reporte de Información diligenciado. Descripción: Se analizan, validan, las necesidades, expectativas y restricciones comunicadas por el usuario para obtener los requisitos priorizados que constituyen una comprensión de lo que va a satisfacer a las partes interesadas. Estos requerimientos del cliente se analizan junto con el desarrollo del concepto operacional para obtener conjuntos de requerimientos más detallados y precisos llamados "Requerimientos de componentes de productos y productos". Los requerimientos de los componentes del producto y del producto responden a las necesidades asociadas con cada fase del ciclo de vida del producto, estos surgen de las limitaciones; Consideración de las cuestiones implícitas, pero no expresamente establecidas en la línea de base de los requerimientos del cliente; Factores introducidos por la arquitectura seleccionada, el ciclo de vida del producto y el diseño; y las consideraciones organizacionales. Se deberán validar los requerimientos para asegurar que el producto resultante se comportará como se pretende en el entorno del usuario final, la validación de estos requerimientos se realizan temprano en el esfuerzo de desarrollo con los usuarios finales para ganar confianza de que los requerimientos son capaces de guiar un desarrollo que da lugar a una validación final exitosa.

PROCESO


Código CVSG01




Como resultado de la validación, se deben tener los requerimientos con las reglas de negocio, formatos que deben ser aprobados por el usuario funcional o usuario técnico que corresponda. Se debe diferenciar el responsable de aprobación según el enfoque del requerimiento. En esta etapa para los proyectos nuevos se debe realizar el Diagrama de Contexto1, teniendo en cuenta que este “diagrama debe de ser comprensible, no es posible representar todos los flujos de datos del sistema en él, sino más bien debe representarse en él una visión general del sistema desde la perspectiva de los propietarios de sistemas siguiendo dos lineamientos básicos:

Representar únicamente los flujos de datos que tengan algo que ver con el objetivo principal del sistema.

Utilizar flujos de datos compuestos que representen a aquellos que sean similares.

Dentro de éste diagrama se enfatizan varias características importantes del sistema:

Las personas, organizaciones y sistemas con los que se comunica el sistema. Son conocidos como terminadores.

Los datos que el sistema recibe del mundo exterior y que deben procesarse de alguna forma.

Los datos producidos por el sistema y que se enviarán al exterior.

Los almacenes de datos que el sistema comparte con los terminadores.

La frontera entre el sistema y el resto del mundo El diagrama de contexto consiste de terminadores, flujos de datos y flujos de control, almacenes de datos y un solo proceso, que consiste en una sola burbuja. El nombre dentro del proceso suele ser el nombre del sistema completo o un acrónimo convenido. Los terminadores se representan por medio de rectángulos y se comunican con el sistema utilizando flujos de datos o de control, los cuales son representados por flechas, o a través de almacenes externos. Hay que recalcar que los terminadores no se comunican entre sí, al menos no en el diagrama de contexto, ya que denotarían interacciones externas al sistema.”

1 YOURDON, Edward, "Análisis Estructurado Moderno", México, Editorial Prentice Hall Hispanoamericana. 1989 “Diagrama de Contexto”, http://clases3gingsof.wikifoundry.com/page/Diagrama+de+Contexto

PROCESO


Código CVSG01




Metodología En esta etapa se analiza lo documentado en el(los) Formato(s) CVSF04 Especificación de requerimientos determinados en la etapa anterior, es un proceso de conceptualización y formulación de los criterios donde de forma concreta se establecen los requerimientos de una manera detallada y estructurada, direccionándolos específicamente hacia los desarrolladores, distinguiendo entre los requisitos del solicitante y los requisitos detallados, obteniendo como resultado la creación del (los) Formato(s) CVSF07 Caso de Uso, en los cuales se formula de forma clara y sistemática los requisitos Planteados. Dentro de estos casos de uso, se debe crear uno general donde se relacionen todos los requerimientos del proyecto con su(s) respectivo(s) caso(s) de uso, con el fin de garantizar que se modele una solución para cada requerimiento solicitado. En caso de existir dudas en los requerimientos propuestos en el(los) Formato(s) CVSF04 Especificación de requerimientos, el analista puede solicitar reuniones con la dependencia funcional con el fin de que estas sean resueltas. Estas reuniones deben ser registradas en el Formato ASIF06 Listado de Asistencia a Reuniones. Una vez elaborados los Casos de Uso, se construye el Diagrama de Contexto con el fin de representar una visión general del Sistema de Información desde el punto de vista de la Dependencia Misional que realiza el requerimiento. Salida:

Formato(s) CVSF07 Caso de Uso, diligenciado. (Documento de relación entre requerimientos y casos de uso).

Formato ASIF06 Listado de Asistencia a Reuniones

Documento Diagrama de Contexto.

NOTAS:

Si se especifica un requerimiento que implique realizar una migración de datos, se debe proceder según lo descrito en la CVSG02 Guía para la migración de bases de datos. Durante esta fase, se define si la migración es parte de este proyecto o es otro proyecto con otros responsables; con lo cual se debe dar inicio al nuevo proyecto.

8.7 Solicitar la Infraestructura para Disponer los Ambientes de Desarrollo y Prueba

Objetivo: Definir los requerimientos mínimos de hardware y software, con el fin de que se dispongan los ambientes de desarrollo y pruebas del sistema de información. Entrada:



Documento Diagrama de Contexto.

Metodología: En esta etapa el profesional asignado de la Temática de Desarrollo, con base en todas las especificaciones planteadas en las fases anteriores, defina en un documento los requerimientos mínimos de hardware, software y comunicaciones con los que debe contar para disponer de los ambientes de desarrollo y pruebas del sistema de información para el nuevo aplicativo a desarrollar, y este se gestiona por medio del diligenciamiento del Formato SIMF02 Solicitud de Servicio de Infraestructura Tecnológica (ver Procedimiento SIMP03 Gestión de Solicitudes de Infraestructura y Seguridad para los Sistemas de Información Misionales), el cual es direccionado a la Temática de Infraestructura y Seguridad. Una vez la Temática de Infraestructura y Seguridad apruebe ese requerimiento, informa a la Temática de Desarrollo que cuenta los ambientes de Desarrollo y Pruebas solicitados.

PROCESO


Código CVSG01




Salida:

Documento de requerimientos mínimos de hardware y software para los ambientes de desarrollo y pruebas del sistema.

Formato SIMF02 Solicitud de Servicio de Infraestructura Tecnológica (ver Procedimiento SIMP03 Gestión de Solicitudes de Infraestructura y Seguridad para los Sistemas de Información Misionales)

Disposición de los Ambientes de desarrollo y pruebas por parte de la Temática de Infraestructura y Seguridad.

8.8 Realizar el Diseño del Software

Objetivo: Realizar el diseño del Sistema de Información con base en todas las especificaciones planteadas en las fases anteriores. Entrada:





Documento Diagrama de Contexto. Descripción: Los diseños de componentes de productos o productos deben proporcionar el contenido adecuado no sólo para la implementación, sino también para otras fases del ciclo de vida del producto, como modificaciones, reprocesos, mantenimiento e instalación. La documentación de diseño proporciona una referencia para apoyar la comprensión mutua del diseño por las partes interesadas pertinentes y apoya los cambios futuros en el diseño durante el desarrollo como en las fases posteriores del ciclo de vida del producto. El diseño del producto consta de dos amplias fases que pueden superponerse en la ejecución, y ejecutarse según la complejidad del producto: diseño preliminar y detallado. El diseño preliminar establece las capacidades del producto y la arquitectura del producto, incluyendo estilos y patrones arquitectónicos, particiones del producto, identificaciones de componentes del producto, estados y modos del sistema, interfaces intercomponentes principales e interfaces de productos externos. El diseño detallado define completamente la estructura y las capacidades de los componentes del producto. La definición de la arquitectura se basa en un conjunto de requisitos arquitectónicos desarrollados durante los procesos de levantamiento de requerimientos. Estos requerimientos identifican los atributos de calidad que son críticos para el éxito del producto. La arquitectura define elementos estructurales y mecanismos de coordinación que satisfacen directamente los requerimientos o apoyan el cumplimiento de los requerimientos a medida que se establecen los detalles del diseño del producto. Las arquitecturas pueden incluir normas y reglas de diseño que rigen el desarrollo de los componentes del producto y sus interfaces, así como orientación para ayudar a los desarrolladores de productos Los arquitectos postulan y desarrollan un modelo del producto, haciendo juicios sobre la asignación de atributos funcionales y de calidad de los atributos a los componentes del producto incluyendo hardware y software. Se pueden desarrollar y analizar múltiples arquitecturas, soportando soluciones alternativas, para determinar las ventajas y desventajas en el contexto de los requisitos arquitectónicos. Los conceptos operativos y los escenarios operacionales, de mantenimiento y de desarrollo se utilizan para generar casos de uso y escenarios relacionados con los atributos de calidad que se utilizan para refinar la arquitectura. También se utilizan como un medio para evaluar la idoneidad de la arquitectura para el propósito que se persigue durante las evaluaciones de la arquitectura, que se realizan periódicamente durante todo el diseño del producto. Ejemplos de tareas de definición de arquitectura incluyen:

Establecer las relaciones estructurales de las particiones y las reglas relativas a las interfaces entre elementos dentro de particiones y entre particiones

PROCESO


Código CVSG01




Selección de patrones arquitectónicos que soportan los requisitos de atributos funcionales y de calidad e instancia o composición de dichos patrones para crear la arquitectura del producto

Identificación de las principales interfaces internas y de todas las interfaces externas

Identificación de los componentes del producto y las interfaces entre ellos

Definición de mecanismos de coordinación (por ejemplo, para software, hardware)

Establecimiento de capacidades y servicios de infraestructura y seguridad

Desarrollo de plantillas de componentes de producto o clases y marcos

Establecimiento de reglas de diseño y autoridad para tomar decisiones

Definición de un modelo de proceso / hilo

Definición de implementación física de software en hardware

Identificación de enfoques y fuentes de reutilización mayores

Lista de chequeo para la revisión de código El diseño detallado se centra en los componentes de productos de software. Se define la estructura interna de los componentes del producto, se generan esquemas de datos, se desarrollan algoritmos y se establecen heurísticas para proporcionar capacidades de componente de producto que satisfacen los requerimientos asignados. Metodología: En esta etapa el profesional asignado de la Temática de Desarrollo de la OTIC, teniendo en cuenta todas las especificaciones establecidas en las fases anteriores, plantea y realiza el diseño del Sistema de Información estructurando los datos necesarios (tablas, relaciones, llaves e índices), su relación entre cada uno de ellos con los elementos estructurales del aplicativo y describe la operación de sus componentes así como la interacción entre ellos y con los sistemas externos si aplica. Salida:

Documento de diseño incluyendo la arquitectura de la solución

Formato CVSF08 Diccionario de datos

8.9 Realizar el desarrollo de Software

Objetivo: Implementar los componentes del producto a partir de los diseños realizados en la fase anterior para aplicativos nuevos o a partir de la especificación de mantenimiento para actualización de aplicativos en producción. Entrada: Para los aplicativos nuevos:

Documento de diseño incluyendo la arquitectura de la solución (Manual Técnico)




Formato(s) CVSF07 Caso de Uso, diligenciado. (Documento de relación entre requerimientos y casos de uso). Descripción:

Una vez que el diseño se ha completado, se implementa como un componente del producto. Las características de esa implementación

dependen del tipo de componente del producto.

La implementación del diseño en el nivel superior de la jerarquía del producto incluye la especificación de cada uno de los componentes

del producto en el siguiente nivel de la jerarquía del producto. Esta actividad incluye la asignación, refinamiento y verificación de cada

componente del producto. También implica la coordinación entre los diversos esfuerzos de desarrollo de componentes de producto.

PROCESO


Código CVSG01




En esta etapa es importante elaborar y mantener la documentación que se requiera para la instalación, operación y mantenimiento del producto. Metodología En esta etapa el profesional asignado de la Temática de Desarrollo de la OTIC, procede a realizar el desarrollo del aplicativo teniendo en cuenta lo establecido en los documentos GVTS01 Lineamientos Generales de Operación para la OTIC, “Lineamiento de Desarrollo Seguro de Software” y documento de trabajo “Guía Técnica para desarrollo de aplicaciones web en el SISPRO”.

Para la gestión del código, debe hacerse uso de la herramienta TFS por parte de los desarrolladores.

Con el fin de facilitar la trazabilidad del código, es importante que cada actualización de código en TFS quede asociada a su respectivo

caso de uso (CVSF07 para proyectos nuevos) o mantenimiento (CVSF10 para cambios de sistemas en producción). El código en el

TFS se puede organizar para utilizar un esquema de promoción de código, uno por funcionalidad o uno mixto.

En paralelo al desarrollo se debe elaborar la actualización del documento de diseño si se trata de un proyecto nuevo o la documentación

de la solución (CVSF11) dada al mantenimiento de software si se trata de un cambio a un sistema en producción.

Salida:

Código fuente de la solución en el TFS

Publicación de la versión de software en ambiente de desarrollo y pruebas

Documento de diseño actualizado si aplica.

Casos de uso desarrollados o actualizados en la versión de software si aplica. Para los aplicativos en producción que requieren mantenimientos o manejo de incidencias:

Formato CVSF10 Mantenimientos Software Especificación.

Formato CVSF11 Solución Mantenimiento de Software si aplica

8.10 Verificar el cumplimiento de las especificaciones del sistema

Objetivo: Llevar a cabo la verificación del software frente a los requerimientos especificados por el usuario para comprobar que el sistema opere según lo solicitado. Entrada:





Formato CVSF11 Solución Mantenimiento de Software


Publicación de la versión de software en ambiente de desarrollo y pruebas

Casos de uso desarrollados o actualizados en la versión de software si aplica.

Mantenimientos e Incidencias atendidas en la versión de software si aplica.

Descripción Los métodos, procedimientos y criterios de verificación se utilizan para comprobar que los productos de trabajo seleccionados y los servicios asociados de mantenimiento, así como la capacitación y apoyo utilicen el entorno de verificación apropiado. Las actividades de verificación deben realizarse durante todo el ciclo de vida del producto y estas deben estar enfocadas entre el producto y el trabajo intermedio de los productos contra todos los requisitos seleccionados, incluyendo requerimientos de clientes,

PROCESO


Código CVSG01




productos y de los componentes del producto. Dicha verificación es inherente en un proceso incremental, dado que esta se realiza durante el desarrollo de los productos, comenzando con la revisión de los requisitos, progresando a través de la verificación de la evolución de los productos de trabajo y culminando en la exploración del producto terminado. La preparación inicial es necesaria para asegurar que las provisiones de verificación estén incorporadas en los requisitos de los productos y componentes del producto, diseños, planes de desarrollo y horarios, en esta etapa se debe incluir también la selección, inspección, pruebas, análisis y demostración de productos de trabajo, así como la definición de herramientas de soporte, equipos de prueba y software, simulaciones, prototipos e instalaciones. Hay que mencionar además que es importante establecer los criterios de verificación de los productos a probar, entre los cuales se encuentran los datos de prueba y estándares. Así mismo, se debe seleccionar el método de verificación que se va a emplear, algunos ejemplos de estos métodos son:

Evaluación de la arquitectura de software

Integración continua

Casos de prueba

Pruebas de seguridad

Pruebas de carga, estrés y rendimiento

Pruebas de aceptación

Pruebas de regresión Las pruebas de regresión, son pruebas de una funcionalidad previamente probada que ha sufrido modificaciones, para asegurarse que no se han introducido o descubierto defectos en áreas del software que no han sido modificadas como resultado de los cambios realizados. Se realiza cuando el software o su entorno han sido modificados. Los casos de prueba se utilizan para examinar que el sistema cumple con los requerimientos funcionales y no funcionales, dichas pruebas se realizan en forma iterativa, con lo cual si se presenta una falla (incidencia) se debe reportar a través de la herramienta definida para su posterior corrección y realización nuevamente de pruebas de módulo y del sistema. Así como, las pruebas de Usabilidad y Accesibilidad deben ser orientadas a verificar que se cumplan los requisitos de gobierno en línea. Las evaluaciones entre pares envuelven un examen metódico de los productos de trabajo por parte de los desarrolladores y probadores, para identificar los defectos de la eliminación y recomendar otros cambios que sean necesarios. La revisión por pares es un método de verificación importante y efectivo implementado a través de inspecciones, tutorías estructuradas o una serie de otros métodos de revisión colegiada. Los exámenes por pares se aplican principalmente a los productos de trabajo desarrollados por los proyectos, pero también pueden aplicarse a otros productos de trabajo, como documentación y productos de trabajo de capacitación. Metodología Realizado el desarrollo de software, se debe verificar el cumplimiento de las especificaciones del sistema frente al producto desarrollado, por lo que el profesional asignado de la Temática de Desarrollo de la OTIC efectúa sus pruebas iniciales en el ambiente de desarrollo y pruebas hasta obtener la funcionalidad operando adecuadamente de acuerdo a las especificaciones. Una vez se tenga el software estable en el ambiente de desarrollo y pruebas, se asigna otra persona de OTIC (diferente al desarrollador) para la realización de las pruebas. Este a su vez recibe una presentación por parte del desarrollador, donde se realiza la demostración del funcionamiento del aplicativo en la versión publicada en el ambiente de desarrollo y pruebas para realizar las pruebas y documentarlas. Para documentar las pruebas se puede utilizar una de las siguientes alternativas:

Test Manager de Microsoft -TFS, para elaborar los planes de prueba y ejecución de dichos planes.

Formato CVSF19 Prueba Funcional, el cual una vez diligenciado con las pruebas se registra en TFS.

PROCESO


Código CVSG01




Los resultados de la verificación deben compararse con los criterios ya previamente establecidos con el fin de determinar la aceptación de la solución, posteriormente los resultados tanto exitosos como los no exitosos deben ser registrados en la herramienta seleccionada. En caso de que el resultado de la prueba no sea exitoso, si este no se subsana en la misma sesión de pruebas se procede a crear el (los) bug(s) correspondientes en TFS, los cuales deben ser asignados al desarrollador encargado, para su subsanación. Una vez desarrollada la solución a la incidencia, esta debe ser registrada con el fin de actualizar el estado de la prueba, así como los documentos relacionados. En caso de utilizar el Formato CVSF19 Prueba Funcional, se debe registrar el aplicativo objeto de la prueba, la fecha de realización, el ambiente en el cual se desarrolló la prueba, los resultados, las observaciones y los participantes. Una vez diligenciado este formato y realizada la prueba se registra en TFS y envía correo electrónico con el enlace de TFS respectivo al líder técnico del sistema de la OTIC. Ya implementadas las soluciones a incidencias presentadas, se envía comunicado a la Temática de Infraestructura y Seguridad autorizando la publicación en Preproducción, teniendo en cuenta lo establecido en la Gestión de solicitudes de Infraestructura y seguridad para los Sistemas de Información Misionales Por otra parte, en esta etapa se realiza el Manual del Usuario. NOTAS:

Si el proyecto incluye migración, se ejecuta la misma en esta fase sobre el ambiente de pruebas.

Si el Sistema de Información involucra Solicitud de Transporte de Anexo Técnico a través de PISIS con su respectivo anexo técnico, se debe realizar las pruebas respectivas, durante esta fase.

Salida:

Registro en TFS de los planes de prueba o pruebas realizadas en formato CVSF19 Prueba Funcional, si aplica

Reporte de los Bugs en TFS, si aplica

Manual del Usuario

Software funcionando adecuadamente en ambiente de desarrollo y pruebas.

8.11 Verificar Software Seguro

Objetivo: Llevar a cabo la verificación de los nuevos desarrollos frente a los lineamientos de software seguro. Entrada:


Publicación de la versión de software en ambiente de preproducción Descripción Los requisitos de seguridad de la información, se deben identificar usando varios métodos, tales como la obtención de requisitos de cumplimiento a partir de políticas y reglamentación, análisis de amenazas o vulnerabilidades, por ejemplo: haciendo uso del Top 10 de vulnerabilidades de OWASP. Algunos de los requerimientos que se deben considerar en desarrollo seguro de aplicaciones son:

Validación de datos de entrada.

Administración de autenticación y contraseñas

Administración de sesiones

Control de Acceso

PROCESO


Código CVSG01




Prácticas Criptográficas

Manejo de errores y Logs

Protección de datos

Seguridad en las comunicaciones

Configuración de los sistemas

Seguridad de Base de Datos

Manejo de Archivos

Practicas Generales para la Codificación

Para lo anterior, se recomienda consultar la guía de prácticas seguras de codificación de OWASP, en la cual se presenta un listado de requisitos de seguridad de alto nivel que hacen frente a muchos de los escenarios de abuso comunes, donde se deben seleccionar los requisitos de seguridad que se consideren pertinentes de acuerdo con la criticidad de la información involucrada en el proyecto y el impacto negativo potencial que podría resultar de la falta de seguridad adecuada. En esta etapa se deben aplicar las pruebas de Seguridad que están orientadas a:

Pruebas de seguridad sobre la Infraestructura

Revisión de Código fuente en búsqueda de vulnerabilidades

Pruebas de seguridad sobre la aplicación Metodología: Una vez el desarrollo de software del nuevo sistema de información satisfaga las especificaciones requeridas, la Temática de Desarrollo procede a evaluar los requerimientos no funcionales en cuanto a seguridad, para lo cual diligencia las listas de Chequeo de Desarrollo Seguro. Este proceso de verificación se realiza de acuerdo los lineamientos establecidos en el documento: “Lineamientos de Desarrollo Seguro de Software”. En caso de que el Ministerio tenga contratado un servicio de análisis de código, se enviará al proveedor la solicitud para realizar dicha revisión y con la retroalimentación se hará al plan de trabajo correspondiente acorde a la actividad “Realizar el mantenimiento o la atención de incidencias del Sistema de Información”. Salida:

Listas de Chequeo de Software Seguro, si aplica.

Comunicación (oficio o correo electrónico) de la Temática de Desarrollo al responsable de realizar la revisión de código, dependiendo del servicio contratado por el Ministerio para la OTIC.

8.12 Realizar la publicación del Software en ambiente de pre-producción y gestionar aprobación del área funcional

Objetivo: Publicar el Software desarrollado en ambiente de pre-producción y obtener la aprobación del área funcional para realizar la puesta en producción. Entrada:

Código fuente y compilado disponible en TFS

Casos de uso desarrollados o actualizados en la versión de software, si aplica.

Mantenimientos e Incidencias atendidas en la versión de software, si aplica.

Listas de Chequeo de Software Seguro, si aplica.

PROCESO


Código CVSG01




Descripción El ambiente de preproducción debe ser lo más similar posible a los ambientes de pruebas y producción, a efectos de prevenir situaciones en las cuales el software desarrollado presente comportamientos distintos y errores en esos ambientes, es decir, debe ser un ambiente distinto a los de pruebas y producción.

Aunado a lo anterior este ambiente debe contener sólo datos de prueba que no sean críticos para el negocio, por lo que conviene disponerse de procedimientos para eliminar datos sensibles (blanquear datos), cuando se traen de ambiente de pruebas o producción, también se deben incluir réplicas de todos los componentes con los cuales el software tendrá interoperación en producción incluyendo: otras aplicaciones cliente servidor, bases de datos relacionales, componentes middleware, interfaces, demonios (daemons), procesos personalizados, utilidades FTP y otros. Además este ambiente debe utilizar nombres de dominio diferentes para los ambientes de producción, pruebas y desarrollo, a efectos de evitar confusión durante la ejecución de las pruebas, así como, tener instalado el mismo manejador de base de datos, versión y calidad de los ambientes de prueba y producción. Si esto no es posible, usar herramientas automatizadas de propagación de una base de datos a otros. 2

Así mismo en esta etapa se deben realizar las pruebas de aceptación que corresponden a pruebas totales del sistema, que si se realizan con éxito, marcará oficialmente el final del proceso de desarrollo y el comienzo de la etapa de mantenimiento. Cabe aclarar que los desarrolladores deben realizar su trabajo exclusivamente en ambiente de desarrollo, nunca en otros ambientes directamente.

Metodología En esta etapa se realiza la publicación del software en ambiente de preproducción, teniendo en cuenta lo solicitado y realizado en las etapas anteriores, posteriormente se informa mediante correo electrónico al área funcional la implementación del nuevo software o incorporación de las nuevas funcionalidades y se solicita la participación del usuario funcional con el fin de verificar el funcionamiento del sistema para su aprobación.

Una vez realizada la verificación por parte del área funcional y si no se presentan incidencias, se procede a realizar el acta de aprobación o se envía comunicado por parte del área funcional aprobando la puesta en producción del desarrollo evaluado. En caso de que en la verificación se presenten incidencias, se debe regresar y realizar lo referido en la actividad “Verificar el cumplimiento de las especificaciones del sistema” (Numeral 7.10) Salida:

Comunicado a la Temática de Infraestructura y Seguridad solicitando la publicación en Preproducción.

Software disponible en ambiente de preproducción.

Solicitud mediante correo electrónico al Área Funcional informando las actualizaciones al sistema e invitando a participar en su verificación.

Formato CVSF19 Prueba Funcional de pruebas realizadas por los usuarios funcionales.

y verificado por el área funcional responsable

Comunicado del Área Funcional aprobando o rechazando la publicación del software en ambiente de producción.

8.13 Sensibilizar el uso del sistema de información

Objetivo: Llevar a cabo la transferencia de conocimiento sobre el nuevo sistema de información a las personas que van a usar el mismo y/o a los agentes de la mesa de ayuda tecnológica que dan soporte (en caso que se requiera).

2 Basado en lo publicado en “PMOinformatica.com”, “lunes, 3 de septiembre de 2012”, http://www.pmoinformatica.com/2012/09/ambientes-de-desarrollo-de-software.html

PROCESO


Código CVSG01




Entrada:

Correo electrónico solicitando el alistamiento e implementación del servicio de Mesa de Ayuda Tecnológica Misional.

Manual del Usuario Descripción: En esta etapa se debe programar las capacitaciones al personal encargado de realizar la asistencia técnica y/o la sensibilización a las personas que interactúan con el Aplicativo Misional desarrollado. Metodología Para el cumplimiento de esta actividad, se deben realizar las siguientes acciones:

Programar la asistencia técnica y/o la sensibilización a reportadores de información sobre el sistema de Información desarrollado.

Coordinar a través de la Temática de Servicios de la Oficina TIC, la sensibilización al personal de la mesa de ayuda tecnológica para aquellos sistemas que van a ingresar a producción, teniendo en cuenta el procedimiento CVSP03 Gestión de la Mesa de Ayuda Tecnológica Misional.

Se debe dejar el registro correspondiente a la sensibilización, a través del diligenciamiento del formato: ASIF06 Listado de Asistencia a Reuniones

Salida:

Correo electrónico solicitando el alistamiento e implementación del servicio de mesa de ayuda tecnológica misional.

Formato ASIF06 Listado de Asistencia a Reuniones diligenciado

8.14 Realizar la puesta en producción del Sistema de Información o Mantenimiento de Software

Objetivo: Publicar el Software desarrollado y aprobado por el área misional en ambiente de producción. Entrada:

Comunicado del Área Misional aprobando la publicación del software en ambiente de producción.

Código fuente y compilado disponible en TFS

Descripción: De cara a su instalación, se ha de planificar el entorno en el que el sistema debe funcionar, tanto hardware como software: equipos necesarios y su configuración física, redes de interconexión entre los equipos y de acceso a sistemas externos, sistemas operativos (actualizados para evitar problemas de seguridad), bibliotecas y componentes suministrados por terceras partes, entre otros.

Configurar el ambiente de producción.

Instalación y despliegue de aplicaciones según guía de instalación.

Migración de las bases de datos actuales si aplica.

Configuración del sistema.

Parametrización (carga de tablas de referencia) del sistema.

Puesta a disposición del sistema de Información a los actores.

PROCESO


Código CVSG01




Metodología: En esta etapa, la Temática de Desarrollo realiza la solicitud a la Temática de Infraestructura y Seguridad, en la cual si se trata de un sistema nuevo se gestiona con el Centro de Datos Externo el ingreso, la instalación y la configuración del software según los requerimientos de hardware definidos, a través del Formato del CDE para la entrega de Software a producción, y el Formato SIMF01 Definición de Línea Base Infraestructura para Recepción Aplicativos OTIC -ver Procedimiento SIMP01 Ingreso de Aplicaciones Misionales al Centro de Datos Externo. En caso de que se trate de una actualización de software a un sistema que se encuentra en producción, su publicación se tramita mediante el formato SIMF02 Solicitud de Servicio de Infraestructura Tecnológica o el formato que defina el CDE contratado por el Ministerio. Una vez puesto en producción en caso de presentarse incidencias, se deben realizar las actividades definidas en la etapa: “Analizar el mantenimiento de software o atención a incidencias del sistema de Información.” (Numeral 7.15) NOTA:

Para el ingreso de aplicaciones nuevas usar el procedimiento SIMP01 Ingreso de aplicaciones misionales al centro de datos externo.

Para llevar a cabo la entrega del software al ambiente productivo, la dependencia del Ministerio (área funcional), debe contar con la actualización de los procesos y/o procedimientos inherentes al nuevo sistema de información. En cuyo caso, deberá quedar documentado y aprobado en el acta de finalización de pruebas.

Salida:

Formato SIMF01 Definición de Línea Base Infraestructura para Recepción Aplicativos OTIC, diligenciado o el formato que defina el Centro de Datos contratado por el Ministerio.

Formato SIMF02 Solicitud de Servicio de Infraestructura Tecnológica, diligenciado o el formato que defina el Centro de Datos contratado por el Ministerio.

Aplicativo en operación en ambiente de producción con información disponible para los actores.

8.15 Analizar el mantenimiento de software o atención a incidencias del sistema de información

Objetivo: Llevar a cabo los ajustes al software que se encuentra en producción y que sean producto de una incidencia de software o mantenimiento solicitados por la dependencia usuaria del sistema en el Ministerio o identificados por la temática de desarrollo de la Oficina TIC. Entrada:

Formato GVTF01 Solicitud Servicio Requerimiento, diligenciado Incidente reportado en la herramienta dispuesta (TFS) Descripción: Los mantenimientos operan bajo tres alcances:

Eliminar los defectos que se detecten durante su vida útil (mantenimiento correctivo, incidencias reportadas)

Adaptar el software a nuevas necesidades (mantenimiento adaptativo), cuando el sistema ha de funcionar sobre una nueva versión del sistema operativo o en un entorno hardware diferente, por ejemplo.

PROCESO


Código CVSG01




Añadir nueva funcionalidad (mantenimiento perfectivo), cuando se proponen características deseables que supondrían una mejora del sistema ya existente, nuevas consultas o reportes, nuevos módulos que solicita el usuario.

Metodología Para eliminar defectos (mantenimiento correctivo, incidencias reportadas): Se revisa el reporte del incidente o solicitud de mantenimiento correctivo que se requiere realizar. Si es necesario se hace

obtención de más información para validar la incidencia presentada: obtener logs del sistema, pantallazos del error, entre otros.

Se registra el incidente en TFS y se asigna al desarrollador.

Se informa el tratamiento dado a la incidencia, al usuario funcional del Ministerio y/o a la mesa de ayuda que remitió el incidente. Para adaptación o adición de una nueva funcionalidad (mantenimiento adaptativo o perfectivo):

Esta fase se inicia con la recepción del formato GVTF01 Solicitud de Servicio Requerimiento, las cuales se registran en las actas correspondientes; en el que se solicita una nueva necesidad del usuario para el software que se encuentra en producción (mantenimiento adaptativo o perfectivo).

Se revisa la solicitud y se le asigna un consecutivo de acuerdo al sistema de información al cual está asociado. Si se requiere, es priorizado dentro de los desarrollos que se estén efectuando.

Se elaboran las especificaciones en el formato CVSF10 y se registra en la herramienta dispuesta para tal fin –TFS. En caso de que el mantenimiento involucra transporte de archivos, se debe anexar diligenciado el formato CVSF06 Solicitud de Transporte de Anexo Técnico a Través de PISIS con el respectivo acto administrativo que contiene el formato CVSF05 Anexo Técnico para Reporte de Información. Se debe llevar a cabo la actualización de los procesos y/o procedimientos inherentes al sistema por parte de la dependencia del Ministerio (área funcional: Dirección, oficina, grupo, etc.), para permitir el ingreso a producción de los nuevos requerimientos. Salida:

Registro de Incidente (Bugs) en TFS y asignado a un desarrollador para su implementación

Formato GVTF01 de solicitud de requerimiento diligenciado

Formato CVSF10 Mantenimientos software Especificación, diligenciado

Correo de respuesta a incidencia al usuario funcional o a la mesa de ayuda Nota:

Los incidentes presentados durante la operación del sistema son reportados por los usuarios a la mesa de ayuda tecnológica. Ver procedimiento CVSP03 Gestión de la Mesa de Ayuda Tecnológica Misional.

8.16 Realizar seguimiento a proyectos del proceso CVS

Objetivo: Realizar seguimiento a proyectos de desarrollo de software y actualizaciones de los aplicativos misionales o sus componentes en sus diferentes etapas del Proceso “Ciclo De Vida y Reingeniería de Sistemas de Información”, para análisis y retroalimentación de mejoras en cada proyecto. Entrada:

Solicitudes recibidas mediante Formato GVTF01 Solicitud Servicio Requerimiento

Mantenimientos especificados Formato CVSF10 Mantenimientos software especificación y asignados a desarrolladores.

Casos de uso desarrollados y probados.

Mantenimientos desarrollados y probados, publicados o producción

Incidencias registradas en TFS y asignadas a desarrolladores

PROCESO


Código CVSG01




Incidencias superadas, probadas y publicadas en producción Metodología Los líderes técnicos de los proyectos de sistemas de información en construcción o en mantenimiento, que usan la metodología de desarrollo de “Ciclo De Vida y Reingeniería de Sistemas de Información”, realizan la planeación periódica de los proyectos tomando en cuenta los recursos asignados y las necesidades identificadas en cada proyecto y realizan el seguimiento a su ejecución para controlar la oportunidad de los resultados y tomar acciones correspondientes para lograr los objetivos propuestos en los tiempos deseados. Para lo anterior se apoya en los insumos de entrada y define las nuevas tareas a reasignar a su equipo de trabajo. Se genera un resumen consolidado de los avances para la Jefe de la Oficina TIC, en el subcomité integrado de Gestión realizado programados bimensualmente, alimentando el indicador del Proceso Ciclo de Vida y Reingeniería de Sistemas de Información. Salida:

Casos de uso, pendientes de desarrollar

Mantenimientos pendientes de desarrollar

Mantenimientos e incidencias superadas pendientes de publicar en producción

Incidencias pendientes de resolver

Consolidado de avances para OTIC

Formato ASIF08 Acta de Reunión, diligenciado del Subcomité Integrado de Gestión

http://intranet.minsalud.gov.co/Sistema-integrado/Mapa-de-procesos/Paginas/CVS.aspx

PROCESO


Código CVSG01




ANEXO 1. TABLA DE CONTENIDO DE LOS MANUALES

Manual Técnico

Introducción ................................................................................................................................................................

1. Objeto ...............................................................................................................................................................

2. Alcance

3 ESPECIFICACION MODELO FUNCIONAL

3.1 Modelo de Procesos

3.2 Definición de Actores 3.3 Especificación de requerimientos funcionales 3.4 Especificación de requerimientos no funcionales 3.5 Casos de uso 4 ESPECIFICACION MODELO ESTRUCTURAL 4.1 Modelo de Clases 4.2 Modelo físico de datos (Diccionario de datos) 4.3 Modelo Entidad – Relación

5. INCORPORACIÓN DEL SISTEMA AL ENTORNO DE OPERACIÓN

5.1. Preparación de la instalación 5.2. Preparación – configuración parametros del Sistema 5.3 Migración y carga inicial de datos

6 ESTABLECIMIENTO DE NIVELES DE SERVICIO.................................................................................................................................

6.1. Características del Servicio 6.2. Niveles de escalamiento 6.3. Prioridad de atención de problemas

7 OTROS .................................................................................................................................................................................................

7.1 Lista de chequeo de verificación de requisitos de instalación .............................................................................................................

7.2 Responsables de la implantación

PROCESO


Código CVSG01




Manual de Usuarios

Introducción ................................................................................................................................................................

1. Objeto ...............................................................................................................................................................

2. Alcance

3. Glosario .............................................................................................................................................................

4. Presentación Modulos del Sistema 4.1. Descripción Módulo de Seguridad del sistema 4.2. Descripción Módulo de Ingreso al sistema 4.3 Descripción Módulo de Registro de información 4.4 Descripción Módulo de Generación de reportes 4.5 Descripción Módulo de Actualización de datos 5. Roles y responsabilidades

ELABORADO POR: REVISADO POR: APROBADO POR:

Nombre y Cargo: Jacqueline Becerra Silva, Contratista Oficina de TIC Fecha: 30 de agosto de 2016

Nombre y Cargo: Dolly Esperanza Ovalle Carranza, Jefe de la Oficina de TIC Fecha: 02 de diciembre de 2016

Nombre y Cargo: Dolly Esperanza Ovalle Carranza, Jefe de la Oficina de TIC Fecha: 02 de diciembre de 2016

guÍa para el ciclo de vida de una sistema de informaciÓn

Documents