Requerimientos Documentales. Sistemas de Información

Requerimientos Documentales Sistemas de Información

Índice de contenido Objetivo... 3 Alcance... 3 Recepción de Aplicaciones... 3 Tipos de documentación... 3 Documentación de soporte (DS)... 3 Documentación de Administración (DA)... 3 Documentación de Desarrollo (DD)... 4 Prioridad de la documentación... 4 Documentación Necesaria (N):... 4 Documentación Requerida (R):... 4 Documentación Deseable (D):... 4 Estado de la documentación... 4 Documentación Aceptada (A)... 4 Documentación Recibida (R)... 4 Documentación Pendiente (P)... 5 Documentación No Entregada (NE)... 5 Recomendaciones para Documentación Requerida... 5 Observaciones... 7 Observaciones de los documentos entregados.... 8 Sobre el Documento de instalación.... 8 Anexos... 9 Recomendaciones mínimas de contenido del Documento de Instalación... 9 Formatos de Diagramas UML de Referencia... 10 Diagrama de Despliegue de Referencia SINEB.... 10 Diagrama de Despliegue de Referencia - RRHH:... 11 Políticas de Gestión de Almacenamiento... 11 Políticas de Gestión de Espacio y Backup (sobre el punto 5.2.1.)... 12 Política Backup de base de datos (sobre el punto 5.2.2.)... 13 Política de Backup de repositorio de archivos (sobre el punto 5.2.3.)... 13

Política de rotado de logs (sobre el punto 5.2.4) y Política de retención de Backup y logs (sobre el punto 5.2.5.)... 13 Política de Backup de aplicación (sobre el punto 5.2.6.)... 14 Objetivo Determinar la documentación mínima y de referencia que se debe tener en cuenta para el proceso de entrega aplicaciones con el objeto de llevar crear y poner en práctica procedimientos de administración exitosa. Alcance Este documento se debe utilizar como una herramienta de referencia con respecto a los documentos requeridos para la recepción de aplicaciones. Se puede utilizar tanto para aplicaciones creadas a la medida (donde el código fuente le pertenece a Ministerio de Educación Nacional (MEN)) como para aplicaciones que son soluciones genéricas a requerimientos particulares del MEN. La documentación se clasifica acorde a su función en producción, como documentación de Soporte, documentación de Administración y documentación de Desarrollo. Recepción de Aplicaciones Para la documentación de recepción de aplicaciones se ha creado una primera clasificación que permite tipificar, priorizar y evaluar el estado de los documentos con el objeto de facilitar el proceso de entrega, dando importancia a los documentos que son necesarios para el levantamiento de información correspondiente. A continuación de se define una clasificación por tipo de documentos y prioridad de los mismos. Tipos de documentación A continuación se definen los tipos de documentación que se contemplan en este formato. Documentación de soporte (DS) La documentación de soporte permite mantener una referencia a todos los módulos o componentes de la aplicación, que se etiquetan como funcionales ya que cumplen con procesos misionales del Sistema de Información (SI) y que tienen que ver con la operación del mismo desde la vista del usuario final. La documentación de Soporte debe incluir los procesos de capacitación que permitirán a mesa de Ayuda, nivel 1 y 2 soportar el día a día de la operación de la aplicación. Documentación de Administración (DA) La documentación de administración permite desarrollar actividades base de instalación,

configuración, puesta en marcha de la aplicación. Incluye información que soporta la toma de decisiones con respecto a la capacidad de los sistemas, la gestión de seguridad y el día a día de la administración desde el punto de vista de Operadores, Ingenieros y especialistas de Datacenter. Documentación de Desarrollo (DD) La documentación de Desarrollo es un referente que permite entender el funcionamiento del sistema de información y su integración con el entorno. La información base de diseño y arquitectura es vital en procesos de administración pues permite hacer gestión y optimización de los recursos dispuestos por la solución propuesta. Finalmente, la documentación de desarrollo le permite al MEN continuar el proceso de mantenimiento, evolución y ciclo de de vida de un desarrollo de software, robusteciendo funcionalidades o simplemente corrigiendo las existentes. Prioridad de la documentación A continuación se clasifica la información acorde a su prioridad para la gestión de los sistemas de información. No se prioriza la información acorde a procesos debidos al ciclo de vida del software ya que esta actividad no se realizan desde Datacenter. Documentación Necesaria (N): Estos documentos son esenciales para procesos base de administración (instalación, configuración, parametrización, puesta en marcha, puesta a punto, soporte base). Documentación Requerida (R): Estos documentos permiten soportar de manera adecuada la operación del sistema de información Documentación Deseable (D): Esta documentación permite optimizar procesos de gestión de la información y soportan la toma de decisiones en cuanto a la arquitectura y las aplicaciones desplegadas. Estado de la documentación A continuación se clasifica la información acorde a su estado de la misma, entendiendo por estado si esta es suficiente para realizar procesos de administración y soporte de aplicaciones. Documentación Aceptada (A) La documentación Aceptada es la documentación Entregada a Datacenter, con respecto a una aplicación, que posterior al análisis y a la respectiva capacitación del grupo de aplicaciones y mesa de ayuda, se avala como suficiente para suplir las necesidades de administración y soporte de una aplicación específica. Documentación Recibida (R) La documentación Recibida es la que se recibe en datacenter como documentación de aplicación, tanto a nivel funcional como técnico, con el objeto de suministrar las

herramientas mínimas que permitan soportar la operación, administración y soporte de los aplicativos que se alojan en Datacenter. Recibido para estudio no significa aceptación. Documentación Pendiente (P) La documentación Pendiente es información que no se encuentra disponible pero que se puede conseguir con el desarrollador del software y/o se puede desarrollar por Administradores expertos del MEN en los diferentes Sistemas de Información. Documentación No Entregada (NE) La documentación no entregada es la documentación que no existe y sobre la cual no se tendrá referencia en el sistema de información. Recomendaciones para Documentación Requerida A continuación se presenta un cuadro de resumen que debe servir para el proceso de recepción de aplicaciones. Documento TIPO PRIO FECHA ESTADO 1.- Capacitación Funcional de Soporte. 1.1.- Documentación de Módulos. 1.1.1.-Desarrollo conceptual de cada módulo de la aplicación DS N 1.1.2.- Definición de formularios y campos. DS N 1.1.3.- Definición de restricciones de cada Formulario. DS N 1.1.4.- Errores conocidos, validaciones necesarias DS N 1.2.- Navegación Interacción con el modulo. (Sesión capacitación). DS N 2.- Capacitación Técnica Administrativa. 2.1.- Documentación Base (Diseño, Arquitectura e Instalación) 2.1.1.- Diagrama de Arquitectura Software de la solución. DA R 2.1.2.- Diagrama s de Actividad de requerimientos (core del sistema). DA D 2.1.3.- Diagrama de Deployment de la solución. DA D 2.1.4.- Documento de Instalación. (Aplicación y BD). DA N 2.1.5.- Documento de Administración de la Aplicación. DA N 2.2.- Ejercicio Practico seguimiento de administración (seguimiento a logdata configuración ) - capacitación, 3.- Documentación de desarrollo 3.1.- Documentación funcional DA N 3.1.1- Glosario del Proyecto DS/DD N 3.1.2.- Normatividad del Proyecto DS/DD N 3.1.3.- Diagrama de casos de Uso DD D

3.1.4.- Requerimientos Aprobados para Desarrollo DD D 3.1.5.- Manual de Usuario Funcional de la Aplicación DD/D N 3.2.- Documentación Técnica 3.2.1.- Casos de uso Desarrollados DD D 3.2.2.- Plan de Pruebas Aceptado por Caso de Uso DS/DD D 3.2.3.- Diccionario de Datos DS/DD N 3.2.4.- Diagrama ER (Entidad Relación)* DS/DD N 3.2.5.- Diagrama de Clases* DD D 3.2.6.- Diagrama de Componentes* DD D 3.2.7.- Diagrama de Estado* DD D 3.2.8.- Diagrama de Actividades* DD R 3.2.9.- Diagramas Adicionales de Soporte. * DD D 3.2.10.- Manual Técnico de aplicación. DD N 3.2.11.- Documento de Instalación. DD N 3.2.12.- Binarios de la aplicación (y fuentes de ser acordado). DD N 3.2.13.- Scripts Inicial de base de datos (Estructura, tablas paramétricas, demás objetos) 3.2.14.- Documentación de Desarrollo (Doxygen, javadoc, gendoc, etc) DD D 3.2.15.- Repositorio CSV y/o SVN de Desarrollo. DD D 4.- Capacidad de la Aplicación 4.1.- Documento de capacidad por aplicación 4.1.1.- Consumo por instancia de Aplicación (cpu,men,disco). DA R 4.1.2.- Arquitectura de Aplicación recomendada por el desarrollador. DA R 4.1.3.- Máximo número de transacciones por modulo por unidad de tiempo. DA R 4.1.4.- Tasa de crecimiento de repositorios y base de datos. DA R 4.1.5.- Tiempo Promedio de respuesta del componente Web. DA R 5.- Administración de Aplicaciones 5.1.- Temas base de Seguridad (Disponibilidad, Confiabilidad, Integridad, Auditoria, No repudio - Documento de definición). 5.1.1.- Puertos y Flujos (Acorde a la arquitectura inicial) (monitoreo e instancias) Tipologías de despliegue arquitecturas sugeridas. 5.1.2.- Interoperabilidad (Interfaz disponibles) DA N 5.1.3.- Administración de contraseñas. DA R 5.1.4.- Administración de sesiones. DA R DD DA N N

5.1.5.- Administración de flujos de la aplicación. DA D 5.1.6.- Administración de logs de (auditoria, aplicación, base de datos). DA D 5.2.- Políticas de almacenamiento 5.2.1.- Políticas de Gestión de Espacio y Backup. DA N 5.2.2.- Política Backup de base de datos. DA N 5.2.3.- Política de Backup de repositorio de archivos. DA N 5.2.4.- Política de rotado de logs. DA N 5.2.5.- Política de retención de backups y logs. DA N 5.2.6.- Política de Backup de aplicación. DA N 5.3.- Mantenimiento Preventivo 5.3.1.- Labores administrativas de BD (limpieza, particionamiento, cambio de configuración de tablas, indexación, recomendaciones). 5.3.2.- Labores de limpieza del filesystem (temporales). DA D 5.3.3.- Análisis de Riesgos. DA D 5.3.4.- Manejo de históricos. DA D 5.4.- Mantenimiento Correctivo 5.4.1.- Plan de continuidad de Negocios DA D 5.4.2.- Administración de errores conocidos. DA D DA D Observaciones La tabla presentada es una referencia a la documentación entregable para un desarrollador o proveedor de software con respecto a un producto puntual. Desarrollos específicos pueden requerir mayor información o estos ser más detallados con respecto a su funcionalidad y características especiales. Todos los diagramas deben ir acompañados por la documentación que soporte las decisiones de diseño, la nomenclatura utilizada y la definición de la iconografía, si no se trabaja con el estándar UML. La documentación de Desarrollo es contemplada en proyectos de software medida donde el dueño de las fuentes es Ministerio de Educación Nacional.

Observaciones de los documentos entregados. A continuación se presentan comentarios sobre algunas características esperadas en la recepción de la documentación. Sobre el Documento de instalación. Característica Observaciones al contenido Versión Tipo de versión Requerimientos de Hardware Requerimientos de Plataforma Requerimientos de Base de Datos Requerimientos Adicionales Medios - Estructura de Directorios - Estructura de Base de datos Archivos de configuración Procesos de Instalación Capacidad del sistema Observaciones Adicionales Responsables y contactos

Anexos Recomendaciones mínimas de contenido del Documento de Instalación El documento de instalación debe contener los siguientes apartes para garantizar el correcto paso a ambiente de pruebas y posterior paso a producción por los especialistas de Datacenter. Característica Contenido Versión Tipo de versión Requerimientos de Hardware Requerimientos de Plataforma Requerimientos de Base de Datos Requerimientos Adicionales Versión-Release-Numero y Fecha de lanzamiento del aplicativo. Final Desarrollo Prueba alfa Beta. Dimensionamiento inicial de Hardware (CPU,RAM,DISCO) Requerimientos de SO y Capa Media (Ver. SO, Paquetes base y librerías) Requerimientos de Base de Datos (Tecnología y ver.) Requerimientos de conectividad, seguridad, backup, entre otros. Medios Ese documento debe incluir los medios fisicos y hacerlos dispnibles en Datacenter. - Estructura de Directorios Definición de la estructura de directorios de la aplicación. - Estructura de Base de datos Script de BD y procedimientos almacenados (archivo.sql base). Archivos de configuración Procesos de Instalación Capacidad del sistema Observaciones Adicionales Responsables y contactos Identificación y ubicación de los mismos. - Definición de variables de parametrización - Conjunto de variables iniciales (recomendación del proveedor) Definir un procedimiento claro de instalación que incluya:: - Proceso requerido a nivel de aplicación - Proceso requerido a nivel de base de datos - Procesos adicionales requeridos (conectividad, seguridad, arquitectura de aplicación, etc). Tipo de usuarios que accederían, cantidad de usuarios que accederían, tipo de proceso que se requiere, cronograma anual de consumo del aplicativo o página de administración de gestión. Caminos de excepción, errores conocidos, recomendaciones y observaciones adicionales., políticas de seguridad, análisis de riesgos, plan de continuidad de negocios. Responsables de la elaboración del documento en el MEN y el proveedor.

Formatos de Diagramas UML de Referencia. A continuación se muestran diagramas de despliegue de referencia (de ejemplo), los cuales son utilizados por datacenter para la puesta en producción de las aplicaciones. Estos diagramas sirven para soportar la arquitectura de la aplicación y son recomendaciones del proveedor con respecto al montaje sobre la infraestructura que permitirá la puesta a punto de una aplicación. Se utiliza convenciones estándar UML para la definición de los mismos. Se recomienda modelar los sistemas de información en función de estos diagramas para facilitar la entrega del modelo conceptual a Datacenter. Diagrama de Despliegue de Referencia SINEB. A continuación se presenta un diagrama de despliegue de ejemplo para el caso del sistema de información SINEB, en el caso hipotético de dos servidores que soporten el servicio balanceados por 2 Webcache. En las máquinas se pueden observar descripciones de los paquetes y las aplicaciones desplegadas y la interacción entre los bloques (http, jdbc, etc.)

Diagrama de Despliegue de Referencia - RRHH: A continuación se presenta un diagrama de despliegue de ejemplo sistema de información Humano, para su ambiente de Certificación y Producción. Utilizando los componentes de UML para su representación. Políticas de Gestión de Almacenamiento. Un componente importante en las definiciones del lanzamiento (delivery) de la aplicación es acotar como se realizaría la gestión de almacenamiento, pues se pueden encontrar limitaciones a nivel contractual o a nivel de políticas de proyecto que limitan la operación y administración de esta información. En este sentido las limitantes contractuales no permiten mantener por más de 3 meses cualquier data o Backup generado de la infraestructura de Ministerio. También, por política de Datacenter no se disponen de

medios magnéticos (CD, DVD, unidades de medios, entre otros), mediante los cuales se pueda generar procedimientos de almacenamiento y movimiento de data, por lo cual es importante que cada aplicación desde su definición en la operación se valide contra las disposiciones de datacenter y se realicen el estudio de riesgos, que permita definir los procedimientos necesarios para garantizar la continuidad del negocio en caso de un incidente donde se vea afectada la datos (binarios, repositorios, temporales, logs, bases de datos, Backup entre otros), o en caso de auditoría donde se requiere tener una la correcta gestión de la cadena de custodia de la data, tanto así, como los repositorios específicos donde se puedan validar los estado y las acción en particular que se haya llevado a cabo sobre el sistema de información y sobre la cual se tenga registro. En este documento se han listado un mínimo de temas para hacer gestión de almacenamiento, y con respecto a estos ítems se recomienda lo siguiente: Políticas de Gestión de Espacio y Backup (sobre el punto 5.2.1.) Se debe poder contar con una policita en función del comportamiento y la utilización del espacio y los requerimientos de Backup de la aplicación. Las políticas debe ser sencillas desde su definición y permitir su ejecución acorde a la tecnología disponible (esto también puede hacer que algunas políticas que se definen de manera general, se puedan plasmar en políticas de sistemas tan específicas como la tecnología que utilizan o la parametrización puntual que requieran). e.g. El sistema de información XXXX aloja datos en las siguientes rutas o volúmenes lógicos. Estos datos crecen con la siguiente rata de XXMB por día y requieren que se realice labores de mantenimiento preventivo cada XX tiempo ejecutando Backup de los archivos que tienen XX característica para su posterior eliminación definitiva del sistema de archivos. Este Backup se requiere como histórico de comportamiento de aplicación, por lo tanto se debe etiquetar y copiar en medio XXX para su entrega posterior a líderes de aplicación del MEN. Lo cual se puede resumir en la siguiente tabla, donde se presentan algunos ejemplos de cómo plasmar la política en Modulo de Aplicación Directorio Recurrencia Filtro Manejo de Históricos Simat batch /oracle/product/oas Antes de RFC La carpeta de binarios y los reportes. SI (EtiquetaX) Humano Reportes /var/lib/rrhh-report/ Diaria Archivos que terminen en.tmp NO

Política Backup de base de datos (sobre el punto 5.2.2.) Se aplica de la misma manera que la anterior tomando como referencia que las tecnologías necesarias para su ejecución son diferentes. Una definición para este tipo de política se puede asociar a la siguiente tabla: Modulo de Aplicación Esquema Recurrencia Tipo de Backup Descripción Manejo de Históricos Simat batch PRODUCCION Diaria Físico FULL SI (Etiqueta X) Humano MENRH Semanal Lógico DATA (TABLAS, NO CONSTR.) NO Procesos Política de Backup de repositorio de archivos (sobre el punto 5.2.3.) Se aplica de la misma manera que la primera pero el enfoque de esta política es sobre la operación (el día a día de aplicación) en el crecimiento de repositorios de data para la aplicación, donde se incluyen temporales de ejecución, reportes, repositorio de temporales, data estacionaria de aplicación, etc. Modulo de Aplicación Directorio Rata (MB/dia) Recurrencia Filtro Manejo de Históricos Simat batch /oracle/product/oas/ 10MB/d Mensual Todo SI (EtiquetaX) Humano /archivos/de/datos/ 5MB/d Anual Archivos > a 1 año. NO Procesos Política de rotado de logs (sobre el punto 5.2.4) y Política de retención de Backup y logs (sobre el punto 5.2.5.) Estas políticas se definen a nivel de servidor para tratar el mecanismo de almacenamiento de la logs previo a su salida de estos archivos del servidor. Características como tamaño, fecha, compresión, estado son definidas como descripción del proceso, así como número el de copias de respaldo del estado de servicio previo a su eliminación. Un ejemplo de cómo se puede describir esta política es la siguiente: Modulo de Aplicació n Simat Batch Humano Procesos Logs de Aplicac. Logs capa Media Logs de SO Nivel de Logging Recurrenci a Descripción SI(RUTA) SI (app) NO FINEST Diaria Mayor a XXMB o Más antiguos a 30 días. SI NO SI (app) DEBUG Semanal Menor a 1M y menos de una semana de antigüedad. Num. Backup Manejo de Históricos 90 SI (EtiquetaX) 15 SI (Etiqueta) y envío mail.

Política de Backup de aplicación (sobre el punto 5.2.6.) Políticas específicas sobre los binarios pueden ser establecidas para validar estados de compilación y funcionamiento general en la creación de librerías y el enlace de sus funcionalidades. Para este tipo de archivos se puede utilizar la definición de rotado y Backup para la administración de copias, su verificación en el tiempo y su mantenimiento histórico de ser necesario. Las políticas de sistemas deben representar el comportamiento de la aplicación y sus requerimientos puntuales. Estas pueden ser tan generales como las acciones que representan y tan especificas como la parametrización que su ejecución requiera. La especificidad de una política esta relegada a Datacenter, ya que es de su competencia la configuración, ejecución y seguimiento a la misma. Desde este punto de vista, este anexo debe servir de referencia para representar como se pueden definir los requerimientos de gestión de espacio de una aplicación para su puesta en producción en Datacenter.