Apoyo ingenieril al componente de desarrollo, área de documentación de Codaltec para el convenio 005 DGSM 2018 de la solución vertical en salud SALUD SIS

Texto completo

(1)APOYO INGENIERIL AL COMPONENTE DE DESARROLLO, ÁREA DE DOCUMENTACIÓN DE CODALTEC PARA EL CONVENIO 005 DGSM 2018 DE LA SOLUCIÓN VERTICAL EN SALUD SALUD.SIS. Programa de Ingeniería de Sistemas. Estudiante Pasante Oscar Ricardo Rosas Cruz ID 394.286. Universidad Cooperativa de Colombia Villavicencio Meta Informe Práctica Social, Empresarial y Solidaria Copyright 2018 © Por Oscar Ricardo Rosas Cruz | Todos los Derechos Reservados.

(2) APOYO INGENIERIL AL COMPONENTE DE DESARROLLO, ÁREA DE DOCUMENTACIÓN DE CODALTEC PARA EL CONVENIO 005 DGSM 2018 DE LA SOLUCIÓN VERTICAL EN SALUD SALUD.SIS. Programa de Ingeniería de Sistemas. Estudiante Pasante Oscar Ricardo Rosas Cruz 394.286 Docente Asignado Ing. Francy Yaneth Patiño Martínez. Universidad Cooperativa de Colombia Villavicencio Meta Informe Práctica Social, Empresarial y Solidaria Copyright 2018 © Por Oscar Ricardo Rosas Cruz | Todos los Derechos Reservados 2.

(3) Dedicatoria El presente informe es dedicado a todos los ingenieros del programa de ingeniería de sistemas de la Universidad Cooperativa de Colombia sede Villavicencio quienes, en su vocación como docentes me brindaron todos los conocimientos necesarios para formarme como un excelente profesional capaz de afrontar retos en mi vida diaria. También dedico este documento a mis padres, quienes, en todo el transcurso de estos 5 años de formación, me apoyaron para cumplir uno de mis más grandes sueños “ser un ingeniero de sistemas”.. 3.

(4) Agradecimientos Gracias a todos los jurados, docentes e ingenieros aquí presentes, quienes en el transcurrir de todos estos años me formaron como un profesional de bien, un emprendedor capaz de afrontar cualquier tipo de problema que se presente en mi vida. También doy gracias a mis padres por apoyarme en estos 5 años académicos y permitirme cumplir un logro más en mi vida.. 4.

(5) Abstract Live an experience working in the development of the vertical solution in health SALUD.SIS project with the high tech corporation for defense CODALTEC is a great opportunity to strengthen our engineering knowledge in the labor field. Work in the documentation area in CODALTEC, is an experience at another level, due to the high complexity that required for make manuals and documents, for example users manuals, system manual, software design description and specification of software requirements. Why do I say it is difficult? Because make each manual or document, require to do several steps and also the documenter need to have information about the system. "Its necessary that the documenter can interactive with the system". 5.

(6) Tabla de Contenidos Capítulo 1 Descripción y naturaleza de la organización ................................................................. 3 1.1 Descripción de CODALTEC ................................................................................................ 3 1.1.1 Misión ............................................................................................................................ 3 1.1.2 Visión ............................................................................................................................. 4 1.1.3 Aliados para la creación ................................................................................................. 4 1.1.4 Organigrama .................................................................................................................. 5 1.1.5 Valores ........................................................................................................................... 7 Capítulo 2 Requerimiento de la organización ................................................................................. 9 2.1 ¿Cuál es la necesidad de CODALTEC? ............................................................................... 9 2.2 Requerimientos metodológicos implementados en el desarrollo de proyectos .................. 10 2.2.1 Metodología aplicada para el desarrollo de proyectos ................................................. 10 2.3 Normas de documentación .................................................................................................. 11 2.3.1 Metodología aplicada para la construcción del documento especificación de requisitos de software (E.R.S) ............................................................................................................... 12 2.3.2 Metodología aplicada para la construcción del documento descripción del diseño de software (S.D.D) ................................................................................................................... 25 Capítulo 3 Plan de acción ............................................................................................................. 32 3.1 Cronograma de actividades ................................................................................................. 32 Capítulo 4 Actividades realizadas ................................................................................................. 35 4.1 Actividades realizadas en la corporación de alta tecnología para la defensa CODALTEC 35 4.1.1 Inicio en CODALTEC ................................................................................................. 35 4.1.2 Curva de aprendizaje.................................................................................................... 35 4.1.3 Apoyo actualización documento E.R.S al módulo DAM ............................................ 37 4.1.4 Apoyo y actualización manual de usuario módulos odontología general ODO y programa salud oral PSO ...................................................................................................... 39 4.1.5 Apoyo actualización en los módulos (ADJ, CYD, FFA, DAM, CGP) ....................... 46 4.1.6 Ventanas de mantenimiento ......................................................................................... 47 4.1.7 Versionamiento manuales de usuario .......................................................................... 53 4.1.8 Diseño de tabla costos y estados de cuenta en HTML puro ........................................ 55 4.1.9 Actualización manual de sistema ................................................................................. 56 4.1.10 Actualización módulo características generales de los programas de promoción y prevención (CGP) y administración (ADMIN) fase V ......................................................... 60 Capítulo 5 Logros y lecciones aprendidas .................................................................................... 62 5.1 Logros y lecciones .............................................................................................................. 62 Capítulo 6 Limitaciones, conclusiones y recomendaciones ......................................................... 63 6.1 Limitaciones, conclusiones y recomendaciones ................................................................. 63 Capítulo 7 Anexos......................................................................................................................... 64 7.1 Certificación culminación de pasantías en CODALTEC ................................................... 64. 6.

(7) Lista de tablas Tabla 1 Formato para evaluar los proveedores de requerimientos ............................................... 15 Tabla 2 Listar procesos actuales y responsables ........................................................................... 17 Tabla 3 Identificar los objetivos del sistema................................................................................. 17 Tabla 4 Elaborar los procesos del sistema .................................................................................... 18 Tabla 5 Descripción de los actores ............................................................................................... 18 Tabla 6 Identificar y revisar los requerimientos funcionales ........................................................ 19 Tabla 7 Identificar y revisar los requerimientos no funcionales ................................................... 20 Tabla 8 Ejemplo de tabla convenciones........................................................................................ 26 Tabla 9 Formato casos de uso SDD .............................................................................................. 28 Tabla 10 Ventana de mantenimiento 1 ......................................................................................... 51 Tabla 11 Ventana de mantenimiento 2 ......................................................................................... 52 Tabla 12 Ventana de mantenimiento 3 ......................................................................................... 52 Tabla 13 Ventana de mantenimiento 4 ......................................................................................... 52 Tabla 14 Ventana de mantenimiento 5 ......................................................................................... 53 Tabla 15 Versionamiento de manuales de usuario ....................................................................... 53 Tabla 16 Tabla original control de cambios ................................................................................. 54. 7.

(8) Lista de figuras Figura 1 Logo corporación de alta tecnología para la defensa CODALTEC. ................................ 3 Figura 2 Aliados de la corporación de alta tecnología para la defensa CODALTEC .................... 4 Figura 3 Organigrama CODALTEC ............................................................................................... 6 Figura 4 Valores corporativos......................................................................................................... 8 Figura 5 Entorno laboral ................................................................................................................. 8 Figura 6 Productividad .................................................................................................................... 9 Figura 7 Marco de trabajo ágil SCRUM ....................................................................................... 10 Figura 8 Estructura documento especificación de requisitos de software E.R.S .......................... 12 Figura 9 Ejemplo de entrevista como método para levantamiento de información ..................... 13 Figura 10 Diagrama elaboración de documento de especificación de requisitos de software E.R.S ............................................................................................................................................... 14 Figura 11 Actividades check list ................................................................................................... 15 Figura 12 Estructura diagrama del proceso .................................................................................. 18 Figura 13 Estructura ISO 9126 ..................................................................................................... 19 Figura 14 Estructura prototipo de baja fidelidad .......................................................................... 21 Figura 15 Plantilla historias de usuario ......................................................................................... 22 Figura 16 Matriz de rastreabilidad requisitos/objetivos................................................................ 23 Figura 17 Matriz de rastreabilidad historias de usuario/requisitos ............................................... 24 Figura 18 Ejemplo de diagrama de componentes ......................................................................... 27 Figura 19 Ejemplo mockup reporte de temperatura del refrigerador ........................................... 29 Figura 20 Ejemplo modelo entidad relación ................................................................................. 30 Figura 21 Ejemplo diagrama de procedimiento ............................................................................ 30 Figura 22 Interfaz gráfica SALUD.SIS ........................................................................................ 31 Figura 23 Panel de control SALUD.SIS ....................................................................................... 31 Figura 24 Cronograma de actividades .......................................................................................... 32 Figura 25 Cronograma de actividades 2 parte .............................................................................. 33 Figura 26 Cronograma de actividades 3 parte .............................................................................. 34 Figura 27 Logo oficial de SALUD.SIS......................................................................................... 35 Figura 28 Imagen ilustrativa a SALUD.SIS ................................................................................. 36 Figura 29 Historia de usuario modificada en E.R.S módulo DAM .............................................. 38 Figura 30 Logo oficial de GitHub ................................................................................................. 39 Figura 31 Logo GitExtension........................................................................................................ 40 Figura 32 Logo de inicio software MadCap Flare ........................................................................ 40 Figura 33 Ejemplo de ajustes aplicados en odontología general (ODO) y programa salud oral (PSO)..................................................................................................................................... 41 Figura 34 Interfaz gráfica MadCap Flare...................................................................................... 42 Figura 35 Ítems interfaz gráfica MadCap Flare ............................................................................ 43 Figura 36 Ejemplo commit Git Extension .................................................................................... 44 Figura 37 Push Git Extension ....................................................................................................... 45 Figura 38 Periodontograma SALUD.SIS ..................................................................................... 45 Figura 39 Ajustes propiedades TOC ............................................................................................. 48 Figura 40 Ajustes propiedades Toc............................................................................................... 49 Figura 41 Tabla Desarrollada en HTML puro costos y estados de cuentas.................................. 55 8.

(9) Figura 42 código tabla costos y estados de cuentas ...................................................................... 56 Figura 43 Funcionalidad detectada en módulo ADMIN............................................................... 60 Figura 44 Funcionalidad implementada en los programas de promoción y prevención .............. 61. 9.

(10) Acrónimos E.R.S: Especificación de requisitos de software. S.D.D: Descripción del diseño de software. M.U: Manual de usuario. M.S: Manual del sistema. ADJ: Adolescencia y juventud. CYD: Crecimiento y desarrollo. FFA: Módulo ficha familiar. DAM: Detección de alteraciones adulto mayor. CGP: Módulo características generales de los programas de promoción y prevención. ODO: Módulo odontología general. PSO: Programa de salud oral. PMP: Programa materno perinatal. SAM: Salud mental. SSR: Salud sexual y reproductiva. CEX: Consulta externa. ADMIN: Administración. AGE: Agendamiento. AMB: Salud ambiental. APS: Administración personal de salud. PERSONADMIN: Personal administrativo. POR: Portafolio de servicios. 1.

(11) REI: Reportes e indicadores. VAC: Vacunación. RYC: Referencia y contrareferencia. Commit: Conjunto de cambios efectuados en el repositorio. GitHub: Forja para alojar proyectos utilizando el control de versiones. Fork: Copia de un cambio. Pull Request: Permite contarles a otros sobre los cambios que ha introducido en el repositorio GitHub. Push: Acción ejecutada en Git Extension para subir cambios al repositorio. Origin: Servidor padre. Upstream: Servidor hijo. Toc: Tipo de salida para impresos y manuales de ayuda en línea. Target: Tipo de salida para impresos y manuales de ayuda en línea. Tópico: Archivos HTML que describen un conjunto de funcionalidades. Mockup: Modelo de diseño de interfaz implementado para la vista de usuario. Front-end: Es la parte que interactúa con los usuarios, hace referencia a la interfaz. Back-end: Es la parte que procesa la entrada desde el front-end es decir procesos internos. M.E.R: Modelo entidad relación.. 2.

(12) Capítulo 1 Descripción y naturaleza de la organización 1.1 Descripción de CODALTEC La corporación de alta tecnología para la defensa nace de la necesidad del sector defensa de promover el desarrollo de capacidades en el área tecnológica; a fin de crear sus propias soluciones, apoyando no solo el ambiente operacional de la fuerza pública sino el avance de la industria nacional. (CODALTEC, 2015) A continuación, se presenta logo como imagen corporativa de CODALTEC.. Figura 1 Logo corporación de alta tecnología para la defensa CODALTEC. Imagen tomada de: https://ormigga.com/web/images/ormigga/logosMinTic/Logo%20Codaltec.png. 1.1.1 Misión “Disminuir la brecha tecnológica del país en la industria del sector defensa a través de la apropiación y generación de conocimiento, el desarrollo tecnológico y mediante la integración del sector productivo público y privado, las universidades y el estado. Todo lo anterior con proyección social para el desarrollo de tecnologías duales, que potencien la producción tecnológica nacional y territorial”.. 3.

(13) 1.1.2 Visión “Ser reconocida como gestora de la disminución de la brecha tecnológica de la industria del sector defensa, convirtiéndose en la principal proveedora de soluciones en tecnología para este, buscando ocupar una posición de importancia en el mercado latinoamericano”. 1.1.3 Aliados para la creación La corporación de alta tecnología para la defensa CODALTEC en sus inicios contó con el apoyo de tres aliados principales que fueron: 1. Ministerio de defensa (aportó económicamente) 2. Gobernación del Meta (aportó económicamente) 3. Alcaldía de Villavicencio. (aportó económicamente). Figura 2 Aliados de la corporación de alta tecnología para la defensa CODALTEC Imagen diseñada por Oscar Ricardo Rosas Cruz, implementando logotipos tomados de https://meta.gov.co/static/img/logo.d32bfda.png , http://villavicencio.gov.co/ , https://upload.wikimedia.org/wikipedia/commons/thumb/8/89/MinDefensa_%28Colombia%29_logo.png/8 00px-MinDefensa_%28Colombia%29_logo.png. Gracias al apoyo del ministerio de defensa, en conjunto de la gobernación del Meta y la alcaldía de Villavicencio, CODALTEC dio sus inicios el día 2 de enero del 2013 como una entidad pública, derecho privado sin ánimo de lucro con un objeto social para el desarrollo, promoción y realización de ACTI. (CODALTEC, 2015) 4.

(14) 1.1.4 Organigrama La Corporación de alta tecnología para la defensa CODALTEC posee 3 divisiones del mismo nivel distribuidas de la siguiente manera: . División de modelado y simulación: Considerado como la división más amplia debido a los múltiples desarrollos y trabajos que comprende el desarrollo de tecnología de punta y de simuladores.. . División de gestión tecnológica: Encargada de la propiedad intelectual en los desarrollos e implementaciones para futuras empresas.. . División de sensores y radares: División encargada de diseñar y construir tecnología de punta enfocada en el diseño de radares y sensores para favorecer las infraestructuras y espacios específicos. Dentro de la estructura organizacional, CODALTEC está conformada por. dependencias que representan la columna vertebral de la corporación. Los representantes para cada una de ellas, se encuentran establecidas de la siguiente forma: . Asamblea general: Ministerio de defensa, Indumil, gobernación del Meta, alcaldía de Villavicencio, SIAC.. . Consejo directivo: Representantes de cada una de las entidades anteriormente nombradas.. . Gerencia: Gral. Julio Alberto González Ruiz. . Control interno: Greis Alejandra Mosquera Cerquera. . Revisoría fiscal: CEAC S.A.S. . Subgerencia: Cnel. Darío Fernando Rey Baquero 5.

(15) . División gestión tecnológica: Cnel. José Antonio Siabato Patiño. . Planeación y finanzas: Juan Carlos Gómez Dávila. . Dirección administrativa: Gabriel Andrés Ruiz Morales. . Gerencia sede Meta: Cnel. Darío Fernando Rey Baquero. . División de sensores: Cap. Gustavo Andrés González Castañeda. . División modelado y simulación: T.C Diego Andrés Hernández Mosquera. Figura 3 Organigrama CODALTEC Imagen tomada de: http://www.codaltec.com/sites/default/files/organigrama_codaltec.jpg. 6.

(16) 1.1.5 Valores Dentro del ambiente laboral de la corporación de alta tecnología para la defensa se tiene que implementar los siguientes valores: . Transparencia: El trabajador debe mostrar transparencia tanto en la adquisición y manejo de información confidencial, como en cualquier procedimiento en donde involucre la relación directa con el y/o los clientes.. . Eficiencia: El trabajador debe ser eficiente y dar cumplimiento con las tareas y/o labores asignadas por el jefe inmediato en cada uno de los componentes y/o células.. . Eficacia: El trabajador debe ser eficaz para trazar una meta y dar cumplimiento a ella en tiempos estipulados.. . Responsabilidad: La responsabilidad es un valor con un peso muy grande en la corporación de alta tecnología para la defensa, ya que cada uno de los más de 300 empleados tienen un compromiso y es dar cumplimiento a cada una de las tareas que se interpongan propuestas por los líderes de los componentes, ya que los proyectos desarrollados poseen tiempos de entrega y es obligatorio su respectivo cumplimiento.. . Veracidad: El trabajador de CODALTEC debe demostrar veracidad en sus acciones y demostrar dominio del tema frente a cualquier cliente.. 7.

(17) Figura 4 Valores corporativos Imagen tomada de: http://fondoramo.com/documentos/valores%20corporativos.jpg. Figura 5 Entorno laboral Imagen tomada de: https://blogazulambientalistas.files.wordpress.com/2013/07/azul-ambientalistas-laimportancia-de-la-responsabilidad-ambiental-en-las-empresas.jpg?w=640&h=420. 8.

(18) Capítulo 2 Requerimiento de la organización 2.1 ¿Cuál es la necesidad de CODALTEC? La corporación de alta tecnología para la defensa CODALTEC dentro del componente de desarrollo – área de documentación, requirió de apoyo para la construcción del documento especificación de requisitos de software E.R.S, descripción de diseño de software S.D.D, actualización de manuales de usuario, generación de ayuda en línea, generación de impresos y actualización del manual de sistema. Además, CODALTEC requirió generar los manuales de usuario de los módulos involucrados en ventanas de mantenimiento.. Figura 6 Productividad Imagen tomada de: https://mdc.org.co/wp-content/uploads/2017/11/fo-1200x675.jpg. 9.

(19) 2.2 Requerimientos metodológicos implementados en el desarrollo de proyectos La corporación de alta tecnología para la defensa CODALTEC implementa diferentes metodologías para el desarrollo de sus proyectos. Como marco de desarrollo ágil se implementa SCRUM en todas las áreas del componente de desarrollo, sin embargo, cada una de ellas según sus actividades y funciones específicas, aplican diversos tipos de metodologías para efectuar de manera correcta el cumplimiento de sus labores.. En el área de documentación, se implementan normas de documentación,. formatos y parámetros para la construcción de los diferentes documentos y manuales, los cuales serán descritos en la continuidad del presente informe. 2.2.1 Metodología aplicada para el desarrollo de proyectos. Figura 7 Marco de trabajo ágil SCRUM Imagen tomada de: https://development.grupogaratu.com/wp-content/uploads/sites/3/2017/07/SRUM-1.png. 10.

(20) SCRUM como proceso de gestión ágil, permite que cada uno de los miembros de CODALTEC pueda dividirse las tareas a realizar y a su vez generar un compromiso por cada uno de ellos, para el cumplimiento de estas en unos límites de tiempo que fueron estipulados según corresponde las fechas de entrega. Por lo general cada 2 a 3 semanas se realiza un daily meeting donde se efectúa un feedback (retroalimentación) para que los equipos de trabajo tengan conocimiento acerca de las labores que está haciendo cada uno y de esta manera determinar si requiere o no apoyo para dar cumplimiento a los objetivos propuestos.. 2.3 Normas de documentación La corporación de alta tecnología para la defensa CODALTEC implementa unas normas, las cuales se deben aplicar para la elaboración de cualquier tipo de documento dentro del componente de desarrollo área de documentación. . IEEE 830: Práctica recomendada para especificaciones de requisitos de software (ERS). . IEEE 1063: Estándar para documentar manuales de usuario de software. . NTC 1486: Presentación de documentación. . NTC 4490: Referencias de información electrónicas. . NTC 5613: Referencias bibliográficas.. . IEEE 1016-2009 (SDD). 11.

(21) 2.3.1 Metodología aplicada para la construcción del documento especificación de requisitos de software (E.R.S) El documento de especificación de requisitos de software (ERS) incluye comportamiento del sistema en función de los requerimientos pactados para el desarrollo, la elaboración de este documento está enmarcada por la norma IEEE 830, la cual establece las recomendaciones para la construcción del mismo. (CODALTEC, 2018).. Figura 8 Estructura documento especificación de requisitos de software E.R.S Imagen tomada de presentación capacitación elicitación de requerimientos V2.0. 12.

(22) Antes de empezar con la construcción del documento de especificación de requisitos de software (E.R.S) se requiere de la aplicación de unos requerimientos para obtener la información y poder modelar el documento. Para la recolección de información se aplican: . Entrevistas. . Cuestionarios. . Etnografías. . Glosarios La corporación de alta tecnología para la defensa CODALTEC aplica cada una de. estas técnicas para recolectar la información suministrada por los clientes, esta información debe ser vital para la construcción y el levantamiento de los requerimientos junto con sus historias de usuario. Figura 9 Ejemplo de entrevista como método para levantamiento de información. Imagen tomada de: https://profesionistas.org.mx/wp-content/uploads/2016/04/Captura-de-pantalla2016-04-29-a-las-8.13.59-640x450.png. Una vez se realiza el levantamiento de requerimientos con el cliente, se procede con la estructura de construcción del documento de especificación de requisitos de software, el cual consta de 3 fases (descubrimiento, diseño e implementación). 13.

(23) A continuación, se puede observar los diferentes ítems que se requieren para el cumplimento de cada una de estas 3 fases.. Figura 10 Diagrama elaboración de documento de especificación de requisitos de software E.R.S Imagen tomada de presentación capacitación elicitación de requerimientos V2.0. Actividades Principales Implementadas en el E.R.S 1. Evaluar los proveedores de requerimientos 2. Describir el sistema actual 3. Describir la problemática actual 4. Listar procesos actuales y responsables 5. Identificar los objetivos del sistema 6. Elaborar los procesos del sistema 7. Identificar y revisar los requerimientos funcionales 8. Identificar y revistar los requerimientos no funcionales 9. Identificar restricciones 10. Identificar supuestos y dependencias 11. Elaborar prototipo de baja fidelidad 12. Elaborar historias de usuario 13. Elaborar matrices de rastreabilidad. 14.

(24) Figura 11 Actividades check list Imagen tomada de: https://www.como-limpiar.com/wp-content/uploads/2017/11/checklist-640x480.jpg. Evaluar los proveedores de requerimientos Esta actividad tiene como objetivo identificar los usuarios líderes y finales a los cuales está dirigido el desarrollo dentro de la organización. (CODALTEC, 2018). Tabla 1 Formato para evaluar los proveedores de requerimientos Tabla tomada de capacitación elicitación de requerimientos V2.0. NOMBRE Usuario líder. DESCRIPCIÓN Son las personas que comprenden el dominio del problema en donde será empleado el software desarrollado.. Usuario final. Son las personas que usarán el sistema desarrollado. Serán quienes utilicen las vistas y los manuales de usuario.. 15.

(25) Describir el sistema actual Esta actividad tiene como objetivo describir el funcionamiento del sistema actual de la organización. . Software y/o herramientas utilizadas. . Descripción general (¿cómo lo hacen?, ¿quiénes?, ¿para que?, ¿qué información necesita?, ¿con que frecuencia? y ¿qué pasa sí?. . Procesos, actores y unas actividades. Ejemplo: Actualmente no se cuenta con una herramienta sistematizada que permita a los establecimientos de sanidad militar registrar la información correspondiente a los residuos hospitalarios. No existe un completo control ni trazabilidad de la gestión de los establecimientos de sanidad militar con los residuos peligrosos. No se tiene información precisa sobre el estado y cumplimiento de las actividades de cada establecimiento de sanidad militar en la referente a la salud ambiental. (CODALTEC, 2018). Describir la problemática actual De acuerdo a la descripción del sistema actual y basado en los requerimientos, presentar las preguntas para que el cliente exponga la respectiva problemática. (CODALTEC, 2018) ¿Cuáles son las necesidades insatisfechas relacionadas con el requerimiento x? El [usuario] necesita [problema/necesidad] para [justificación]. 16.

(26) Listar procesos actuales y responsables El cliente debe identificar, listar los procesos actuales y los responsables del levantamiento de información de cada uno de los procesos. (CODALTEC, 2018) Tabla 2 Listar procesos actuales y responsables Tabla tomada de capacitación elicitación de requerimientos V2.0. NOMBRE PROCESO. RESPONSABLE. Proceso 1 …  . Subproceso 1. …. . …. ... Proceso 2 …  . . Subproceso 1 ... Identificar los objetivos del sistema Esta sección debe contener una lista con los nuevos objetivos que se esperan alcanzar cuando el sistema software a desarrollar esté en uso, especificarlos mediante la plantilla descrita en la tabla. (CODALTEC, 2018) Tabla 3 Identificar los objetivos del sistema Tabla tomada de capacitación elicitación de requerimientos V2.0. ID. OBJ - N. Descripción. <objetivo a cumplir por el sistema>. Subobjetivos. . OBJ–. 17.

(27) Elaborar los procesos del sistema Esta actividad tiene por objetivo:    . Identificar entradas y salidas de los procesos Identificar las actividades que se realizan en cada proceso del sistema Identificar el personal que interviene en los procesos del sistema Realizar diagramas de los procesos del sistema Tabla 4 Elaborar los procesos del sistema Tabla tomada de capacitación elicitación de requerimientos V2.0. Proceso: Nombre del proceso Actores Entradas. Actividades. Salidas. Tabla 5 Descripción de los actores Tabla tomada de capacitación elicitación de requerimientos V2.0. ID. ACT- N - <Nombre de actor>. Funciones. <Funciones del actor>. Comentarios. <comentarios adicionales sobre el actor>. Figura 12 Estructura diagrama del proceso Imagen tomada de capacitación elicitación de requerimientos V2.0 diseñado en software bizagi. 18.

(28) Identificar y revisar los requerimientos funcionales Esta actividad tiene por objetivos identificar y revisar los requerimientos funcionales que el software deberá cumplir. (CODALTEC, 2018) Tabla 6 Identificar y revisar los requerimientos funcionales Tabla tomada de capacitación elicitación de requerimientos V2.0. ID. RF - <N>. Categoría. <nombre categoría excel>. Descripción. <descripción del requerimiento de información>. Objetivos asociados. . OBJ-x <nombre del objetivo>. Procesos asociados. . Proceso... Identificar y revisar los requerimientos no funcionales Esta actividad tiene por objetivo identificar los requerimientos no funcionales del software a desarrollar y clasificarlos en los atributos de calidad establecidos por la ISO 9126. Algunos tipos de requisitos que se suelen incluir en esta sección son los siguientes: (CODALTEC, 2018) ISO 9126. Funcionalidad. Fiabilidad. Facilidad de uso. Facilidad de mantenimiento. Eficiencia. Portabilidad. Figura 13 Estructura ISO 9126. Imagen tomada de capacitación elicitación de requerimientos V2.0. 19.

(29) Tabla 7 Identificar y revisar los requerimientos no funcionales Tabla tomada de capacitación elicitación de requerimientos V2.0. ID. RNF - <id>. Categoría. <nombre categoría>. Descripción. <descripción del requerimiento no funcional>. Objetivos asociados. . OBJ-x <nombre del objetivo>. Procesos asociados. . N/A. Identificar restricciones Esta actividad tiene como objetivo indicar cualquier tipo de limitaciones sobre los desarrolladores del producto como pueden ser: (CODALTEC, 2018)      . Políticas de la empresa Limitaciones hardware Consideraciones de seguridad Protocolos de comunicación Interfaces con otras aplicaciones Lenguajes de programación. Identificar supuestos y dependencias En este apartado aparecerá cualquier factor que si cambia, puede afectar a los requisitos. No son restricciones de diseño, por ejemplo, asumir que un determinado sistema operativo estará disponible, presuponer una cierta organización de las unidades de la empresa. Si cambian ciertos detalles puede ser necesario revisar los requisitos. (CODALTEC, 2018). 20.

(30) Elaborar prototipos de baja fidelidad 1. Dibujar una caja vacía y suponer que es la pantalla principal del módulo. 2. Identificar las secciones o submódulos que deberá tener el módulo. 3. Solicitar a las personas reunidas que comenten según cada rol del sistema que pueden hacer desde ahí. 4. Para cada acción trazar una línea a una caja nueva y etiquetar con el nombre de la sección. 5. Incluir dentro de cada una de las secciones las funcionalidades identificadas a partir de los requerimientos. 6. Analizar si los requerimientos del módulo en cuestión interactúa de forma directa con otro módulo desarrollado en la aplicación, de ser así, se debe indicar en el prototipo.. Figura 14 Estructura prototipo de baja fidelidad Imagen tomada de capacitación elicitación de requerimientos V2.0. 21.

(31) Elaborar historias de usuario Las historias de usuario es una manera simple de describir una funcionalidad o tarea a realizar por un usuario del sistema, estas se desarrollan de manera conjunta entre el cliente (usuario funcional) y el equipo de desarrollo mediante conversaciones, toma de apuntes, etc. y está compuesta de las siguientes actividades: (CODALTEC, 2018) 1. 2. 3. 4. 5. 6.. Identificar el título. Identificar el funcionario. Identificar la dependencia. Registrar los requerimientos a los que da cumplimiento. Realizar la descripción de la funcionalidad. Definir los criterios de aceptación.. Figura 15 Plantilla historias de usuario Imagen editada por Oscar Rosas y tomada de capacitación elicitación de requerimientos V2.0. 22.

(32) Matrices de rastreabilidad Las matrices de rastreabilidad permiten al equipo hacer un seguimiento al cumplimiento de las actividades programadas, estas incluyen la comparación de requisitos/objetivos, e historias de usuario/requisitos, esto permite garantizar el cumplimiento a las necesidades. (CODALTEC, 2018). Figura 16 Matriz de rastreabilidad requisitos/objetivos Imagen editada por Oscar Rosas y tomada de capacitación elicitación de requerimientos V2.0. 23.

(33) Figura 17 Matriz de rastreabilidad historias de usuario/requisitos Imagen tomada de capacitación elicitación de requerimientos V2.0. 24.

(34) 2.3.2 Metodología aplicada para la construcción del documento descripción del diseño de software (S.D.D) El documento de descripción de diseño de software (SDD), es un documento elaborado por el área de documentación en donde se detallan las vistas de usuario (mockups), los casos de uso, el modelo de datos y la codificación de los diagramas de procesos para los desarrollos propuestos. (Corporación de alta tecnología para la defensa CODALTEC, 2016). Este documento consta de seis secciones descritas a continuación: 1. Introducción: Proporciona una visión global de los contenidos y organización del diseño del software. 2. Modelo conceptual del sistema: Describe el funcionamiento general de la aplicación, así mismo incluye una descripción y diagrama de componentes para cada uno de los módulos. 3. Descripción del diseño de software: Presenta los casos de uso de todas las funcionalidades incluidas en los módulos derivados de los requerimientos incluidos. 4. Diseño de vistas: Esta sección incluye las vistas de usuarios elaboradas para cada una de las funcionalidades, estas cuentan con un identificador del módulo y su consecutivo. 5. Diseño de datos: Detalla a nivel conceptual los datos que soportan el funcionamiento del sistema e identifica las entidades importantes, sus interacciones y los atributos que componen cada una de ellas, para todos los módulos incluidos en la fase de desarrollo. 25.

(35) 6. Anexos: Se relacionan los diagramas de procesos codificados para cada uno de los módulos, programas y sus respectivas actividades. A continuación, se procederá a dar una breve explicación de cada una de las secciones.. Introducción: En la sección de introducción se contemplan componentes que enfocan al desarrollador, proporcionando la estructura del documento y a su vez involucrando secciones tales como (propósito, alcance, visión general del documento, definiciones, acrónimos y abreviaturas, y convenciones, donde esta última presenta la estructura del documento así: Tabla 8 Ejemplo de tabla convenciones Descripción Fuente Calibri: Inicial en mayúscula y Negrita. Tabla tomada de documento SDD V1.0.3 Representa Ejemplo Una vista de usuario Un modal Una pestaña. Todo en mayúsculas. Acrónimos Abreviaturas. La vista Usuarios… El modal Usuarios… Seleccione la pestaña Antecedentes… La tabla Personas… Haga clic en el botón Aceptar… Ingrese el nombre de la tabla en el campo Tipo de afiliado... Seleccione la opción Atención en planificación familiar. El sistema presenta el documento Criterios médicos… GAVD, CSS, HTTPS MB (Megabyte). Cursiva con corchete angular derecho. Ruta de un menú. Archivo > Guardar. Tabla de datos con filtros Un botón Un campo de una ventana Una opción Un documento. 26.

(36) Inicial en mayúscula y Cursiva. Conceptos de importancia Capítulos o secciones del documento Referencia a libros. Un panel y una rejilla. Títulos y secciones. Mensaje de notificación. Un formulario Inicial en mayúscula, cursiva y en “”. Los administradores de la solución serán… Refiérase al capítulo 1, Introducción para… Como se presentó en el Critical Design Review Seleccione el panel Datos… El usuario selecciona la rejilla Peso para la edad… En el capítulo 1. Introducción. En la sección Registrar datos básicos… Se presenta el formulario AIEPI. El sistema presenta el siguiente mensaje: “Transacción realizada satisfactoriamente”. Modelo conceptual del sistema: En esta sección, se describe el funcionamiento de la aplicación y es acompañado por un diagrama de componentes, el cual debe estar debidamente diseñado acorde a cada uno de los módulos de la aplicación.. Figura 18 Ejemplo de diagrama de componentes Imagen tomada de SDD V1.0.3. Descripción del diseño de software: En la sección de descripción del diseño de software se contemplan los casos de uso elaborados para cada una de las funcionalidades.. 27.

(37) Tabla 9 Formato casos de uso SDD Tabla editada por Oscar Rosas y tomada de SDD V1.0.3. CU-MOD-001 Descripción Requerimientos Historias de usuario Vistas Procesos Funcionalidades. Nombre Registrar al paciente en el programa x Este caso de uso describe la secuencia para registrar la información del paciente cuando es un bebe prematuro o presenta bajo peso al nacer, en el programa x de la valoración del programa de primera infancia - infancia, por primera vez. - RF-xxx, RFxxx, RFxxx, RFxxx - HU-Modulo-x.x.x -. VI-MOD-06, VI-MOD-07a, VI-MOD-07b. PR-MOD-1.1 FN-MOD-03 El usuario debe haber diligenciado la información de la pestaña: Antecedentes (VI-MOD-05). - El paciente debe ser menor a 11 meses y 29 días de edad. Precondiciones - El paciente debe ser un bebe prematuro y/o tener bajo peso al nacer. Curso normal de los eventos Paso Acción del usuario Respuesta del sistema Hace clic sobre la etiqueta de la pestaña “Programa Canguro” de la valoración Presenta la vista Programa X (VI1. del programa de primera infancia MOD-06). Infancia. Paso Excepciones Si el usuario selecciona la rejilla Peso para la talla, y dependiendo el rango en que 5a. se encuentre, el sistema presenta el siguiente mensaje: “Peso anormal para la talla estatura del paciente”. El sistema realiza un autoguardado temporalmente hasta que la Post-condiciones valoración finalice. Alto Complejidad Estimación(horas) 30 N/A Comentarios. 28.

(38) Diseño de vistas: En esta sección, se contemplan las vistas de usuarios diseñados en mockups para cada una de las diferentes funcionalidades. (Imagen diseñada en el software Balsamiq). Figura 19 Ejemplo mockup reporte de temperatura del refrigerador Imagen tomada de SDD V1.0.3. 29.

(39) Diseño de datos: En el diseño de datos se incluyen los modelos entidad relación (M.E.R) de cada uno de los diferentes módulos. (El diseño del modelo entidad relación es elaborado mediante el software DbSchema). Figura 20 Ejemplo modelo entidad relación Imagen tomada de SDD V1.0.3. Anexos: En esta sección se integran los diagramas de procesos para cada uno de los módulos.. Figura 21 Ejemplo diagrama de procedimiento Imagen tomada de SDD V1.0.3. 30.

(40) Interfaz del sistema SALUD.SIS. Figura 22 Interfaz gráfica SALUD.SIS Imagen tomada de SALUD.SIS. Figura 23 Panel de control SALUD.SIS Imagen tomada de SALUD.SIS. 31.

(41) Capítulo 3 Plan de acción 3.1 Cronograma de actividades. Figura 24 Cronograma de actividades Imagen diseñada por Oscar Ricardo Rosas Cruz. 32.

(42) Figura 25 Cronograma de actividades 2 parte Imagen diseñada por Oscar Ricardo Rosas Cruz. 33.

(43) Figura 26 Cronograma de actividades 3 parte Imagen diseñada por Oscar Ricardo Rosas Cruz. 34.

(44) Capítulo 4 Actividades realizadas 4.1 Actividades realizadas en la corporación de alta tecnología para la defensa CODALTEC 4.1.1 Inicio en CODALTEC El día viernes 18 de mayo empiezo mis prácticas en la corporación de alta tecnología para la defensa CODALTEC, gracias al apoyo de la Universidad Cooperativa de Colombia sede Villavicencio, el líder de desarrollo Ing. Fredy Parra Guevara, líder área documentación Ing. Pablo Andrés Padilla Flechas y la Psicóloga Adonaí Rodríguez García.. 4.1.2 Curva de aprendizaje Dentro de la curva de aprendizaje el Ing. Pablo Andrés Padilla Flechas proporcionó información frente a las actividades que se realiza dentro del componente de desarrollo área de documentación, obteniendo como primera tarea entender y comprender los diversos documentos realizados, entre estos S.D.D y E.R.S, los cuales contenían bastante información frente a diversas funcionalidades y los diversos módulos existentes en el sistema.. Figura 27 Logo oficial de SALUD.SIS Imagen tomada de: https://p5.zdassets.com/hc/theme_assets/805668/200153398/SALUDSIS.png. 35.

(45) Después de haber entendido como era la estructura de los documentos anteriormente mencionados, conozco los ambientes donde actualmente se encuentra alojado la solución de la vertical de salud SALUD.SIS. Decido indagar e investigar más a fondo acerca de este macro sistema y comprendo que actualmente se encuentra en “productivo” es decir el sistema se encuentra en funcionamiento brindando sus servicios a través de la página web https://saludsis.mil.co/. La corporación de alta tecnología para la defensa CODALTEC cuenta con ambientes espejo denominados DEV, DEV-PRO, QA, QA-PRO, estos son una copia idéntica del sistema actualmente en productivo, pero ninguno de ellos usa información real, por el contrario, gracias a estos ambientes se pueden realizar diversas pruebas y visualizar nuevas funcionalidades para que seguidamente sean implementadas en el ambiente en productivo.. Figura 28 Imagen ilustrativa a SALUD.SIS Imagen tomada de: https://upload.wikimedia.org/wikipedia/commons/c/c4/SALUD.SIS.jpg. 36.

(46) Cuando entiendo que existen unos ambientes donde se aplican los diversos cambios, es allí donde mi supervisor me proporciona diversos tipos de ejercicios para que practicara y entendiera el funcionamiento del sistema a nivel de usuario final, por lo cual aprendo a interactuar con el sistema y a realizar diversos ejercicios como por ejemplo crear un usuario, crear un nuevo personal de salud, asignar permisos, asignar turnos, crear un paciente para luego este ser atendido por consulta externa o urgencias, teniendo en cuenta que el manejo según el tipo de usuario y permisos asignados son diferentes.. 4.1.3 Apoyo actualización documento E.R.S al módulo DAM. El día 3 de julio del presente año apoyé en la actualización del documento E.R.S específicamente en el módulo adultez y vejez DAM fase V en donde el ingeniero John Carlos Rincón Villamizar, me explicó y me oriento durante la actualización del mismo, acerca de los diferentes parámetros y estructura que se debe tener en cuenta para realizar una actualización al documento de especificación de requisitos de software, entre los más comunes se encuentran los tipos de estilos, fuentes, tamaños de letra, tipos de letra, estructuras de tablas que se debe tener en cuenta al momento de realizar un cambio, permitiendo apoyar en la actualización de la sección descripción del problema, objetivo general y objetivos específicos junto con las historias de usuario.. Efectuar cualquier tipo de ajuste, ya sea en un documento de especificación de requisitos de software E.R.S o un manual, se debe tener en cuenta que para cada uno de ellos se aplican unos estilos predefinidos los cuales deben ser verificados antes, durante y 37.

(47) después de su aplicación, esto con el fin de minimizar los errores al momento de ser entregado a otro ingeniero para que este también pueda verificar y validar el manual o documento.. Figura 29 Historia de usuario modificada en E.R.S módulo DAM Imagen editada por Oscar Ricardo Rosas y tomada de E.R.S DAM fase V. 38.

(48) 4.1.4 Apoyo y actualización manual de usuario módulos odontología general ODO y programa salud oral PSO El proceso de actualización de un manual de usuario se da gracias al uso de 3 herramientas fundamentales las cuales son: . GitHub. . GitExtension. . MadCap Flare A continuación, se dará una breve explicación acerca de las herramientas. nombradas anteriormente. GiThub: Es una forja (plataforma de desarrollo colaborativo) para alojar proyectos utilizando el sistema de control de versiones GIT. El código de los proyectos alojados en GitHub se almacena típicamente de forma pública, aunque utilizando una cuenta de pago, también permite hospedar repositorios privados. (Wikipedia, 2018). Figura 30 Logo oficial de GitHub Imagen tomada de https://cdn-images-1.medium.com/max/1125/1*wotzQboYWAfaj-7bvGNIkQ.png. 39.

(49) GitExtension: Es un kit de herramientas que permite trabajar con GIT en windows de una forma intuitiva. Además, permite descargar repositorios, realizar Commits, realizar pull, y muchas otras interacciones que facilitarán llevar un control adecuado sobre los cambios efectuados en un proyecto. (Git Extension, 2018). Figura 31 Logo GitExtension Imagen tomada de: https://henkwesthuis.gallerycdn.vsassets.io/extensions/henkwesthuis/gitextensions/2.50.2/1510324206914/3 9546/1/screenshot.png. MadCap Flare: Es un software potente para la documentación técnica que le permite crear, administrar y publicar contenido en una gran variedad de formatos, incluidos impresos, ayudas en línea de escritorio y móviles.. Figura 32 Logo de inicio software MadCap Flare Imagen tomada de: http://uaeurope.com/assets/img/201806_Flare2018Review/Flare-splash-screen.png. 40.

(50) Entrando una vez más en contexto frente a la actualización realizada en el módulo de odontología general (ODO) y programa de salud oral (PSO), se contribuyó en la modificación y ajustes en múltiples imágenes que contenía información desactualizada frente al sistema actual.. Figura 33 Ejemplo de ajustes aplicados en odontología general (ODO) y programa salud oral (PSO) Imagen tomada de GitHub cuenta pasante. Las actualizaciones efectuadas en los módulos programa de salud oral (PSO) y odontología general (ODO) se realizaron de la siguiente manera: 1. Se identificó la documentación actual que se encontraba alojada en el MadCap Flare (Información desactualizada).. 41.

(51) 2. Se procede a validar paso a paso la información del MadCap Flare, comparándola con el aplicativo en un ambiente específico, en mi caso se realizó en ambiente QA-PRO. 3. Una vez detectados los cambios, se procede a realizar los debidos ajustes en el MadCap Flare. Si los cambios fueron en interfaces gráficas, se localiza la imagen y esta se abre en un editor de imágenes, para que posteriormente sea implementado el ajuste visual. (Se debe aclarar que, si el cambio fue en interfaz gráfica, se debe validar comentarios, notas y descripción del procedimiento paso a paso).. Figura 34 Interfaz gráfica MadCap Flare Imagen tomada de: https://assets.madcapsoftware.com/websiteImages/illustrations/ill-flareUI-2x.jpg. 42.

(52) Figura 35 Ítems interfaz gráfica MadCap Flare Imagen tomada de: https://www.madcapsoftware.com/products/flare/. 4.. Al efectuar cualquier tipo de cambio mediante entrada de textos y/o ajustes a la información, se recomienda realizar los cambios a nivel de editor de código, teniendo en cuenta que de esta manera se puede fácilmente comprender la estructura de la funcionalidad documentada, respetando a la vez grillas, tablas, notas y demás.. 43.

(53) 5. Por último, una vez se ha realizado los respectivos cambios, se procede a efectuar la actualización en el repositorio haciendo clic en el botón commit de Git Extension seguido de actualizar y hacer push. Cuando ya se ha realizado el push se deberá ir a GitHub para crear el pull request y solicitar integración. Los comandos a utilizar para actualizar el repositorio en el Git Extension son los siguientes: . Git checkout + nombre de rama (cambio de rama de local a remota). . Git pull upstream + nombre de rama (captura todos los cambios nuevos existentes). . Git checkout + nombre rama local (cambio de rama remota a local). . Git rebase + nombre rama (compara los cambios de la rama remota a la rama local y aplica los cambios). Figura 36 Ejemplo commit Git Extension Imagen tomada de: https://www.danrigby.com/images/gitex-commit.png. 44.

(54) Figura 37 Push Git Extension Imagen tomada de: https://s16458.pcdn.co/wp-content/uploads/2016/03/Push-code.jpg. En total se ajustaron 14 imágenes y se añadió corrección en el odontograma y el periodontograma de los módulos odontología general ODO y programa de salud oral PSO.. Figura 38 Periodontograma SALUD.SIS Imagen tomada de SALUD.SIS. 45.

(55) 4.1.5 Apoyo actualización en los módulos (ADJ, CYD, FFA, DAM, CGP) Dentro del proceso de actualización del documento descripción del diseño de software S.D.D se llevó a cabo la actualización de diferentes modelos conceptuales como por ejemplo el del módulo primera infancia-infancia, programa materno perinatal, módulo características generales, módulo ficha familiar, programa adultez y vejez, programa adolescencia y juventud, así como la actualización de más de 40 casos de uso en las que se aplicaron los siguientes cambios: . Se dejó como parámetros el nombre de caso de uso junto con su respectivo programa, descripción, requerimientos, historias de usuario, vistas, procesos, funcionalidades, precondiciones, curso normal de los eventos, excepciones, post condiciones, complejidad, estimación (horas) y comentarios.. . Se aplico la homogeneidad de estilos.. . Se elimino redundancia “el usuario hace clic”.. . Se aplican negritas y cursivas a vistas, cuadros dialogo, paneles y demás. Por último se implementaron las vistas en cada uno de los módulos mencionados. anteriormente, teniendo en cuenta los ajustes de imagen, ya que estos deben ser visibles en un ajuste predeterminado de enfoque y visualización al 100% teniendo en cuenta también que dependiendo si es una vista o cuadro de dialogo, sus tamaños cambian.. 46.

(56) 4.1.6 Ventanas de mantenimiento Las ventanas de mantenimiento fue una de las tareas que más tiempo llevo, debido a que se requiere de varios procesos para realizar una sola ventana de mantenimiento, los cuales explicaré a continuación: 1. En primer lugar, se obtiene un documento interno (ventana de mantenimiento) cuyo contenido indica todos los cambios solicitados por el cliente en el sistema para diferentes módulos. “Se debe realizar una profunda investigación acerca de los cambios específicos solicitados en ese documento interno”. 2. Se deben localizar los cambios específicos por módulo y compararlos con la documentación actual en MadCap Flare, por lo general esta va a ser diferente, por lo que se requiere de actualizar el módulo en el software, teniendo en cuenta las propiedades fundamentales y respetando la estructura que se encuentra establecida. Además de esto hay que tener en cuenta dos cosas, en la mayoría de veces, los cambios van a ser un poco complejos de encontrar en el aplicativo ejecutado en cualquier ambiente, por lo que es recomendado que, si el cambio no es perceptible, se requiere de ayuda con los programadores quienes fueron los encargados de realizar esos cambios, para ubicarlos y posteriormente actualizarlos. Además de esto se debe identificar si el cambio fue visual es decir front-end o si este fue de manera interna y lógica osea back-end, ya que, si no es un cambio visual, esta no se incluirá en la ventana de mantenimiento.. 47.

(57) 3. Se debe tener un control acerca de los cambios efectuados, ya que en ocasiones puede suceder que ese cambio requiera de ser implementado en otras funcionalidades y/o módulos, ejemplo un filtro de contenido de tablas. 4. Una vez realizado los cambios correspondientes del documento interno (ventana de mantenimiento), se procede a ajustar la TOC y la TARGET dentro del MadCap Flare para generar las ayudas en línea e impresos.. Figura 39 Ajustes propiedades TOC Imagen tomada de: MadCap Flare. 48.

(58) 5. Los ajustes que se dan en la TOC son una serie de propiedades los cuales están distribuidos en unos parámetros ya establecidos, a nivel de documentos impresos, se ajustan las propiedades de las portadas, control de cambios, contenido, índice de tablas, introducción, información de uso del manual y procedimientos, además se debe validar que en los procedimientos contengan todos los tópicos existentes en el módulo, ya que existen ocasiones en donde estos no están y por ende se debe incluir las funcionalidades en la sección de procedimientos dentro de la TOC, de lo contrario al generar el documento, este no contendrá la funcionalidad faltante. A nivel de ayudas en línea se ajustan las propiedades de la sección General, Printed Outpus y Auto-numbers. A continuación, se mostrará un ejemplo de una de las secciones a modificar dentro de la TOC.. Figura 40 Ajustes propiedades Toc Imagen tomada de MadCap Flare Software. 49.

(59) 6. Cuando se ha culminado con el proceso de ajustes dentro de las propiedades de la TOC, se procede a aplicar la misma dinámica de actualización, pero esta vez en la sección TARGET. 7. Una vez realizado los respectivos cambios se procede a hacer push en Git Extension para subir nuestros cambios al repositorio y seguido de este dentro de la plataforma GitHub se realiza un pull request para que un ingeniero que se encuentre integrando, pueda aplicar los cambios realizados. 8. Después de que se realizó el pull request y los cambios fueron integrados en el repositorio, se procede a informar a un ingeniero para que el/ella se actualice y pueda generar los documentos. “Si se trabaja bajo un software free trial (licencia gratuita) no se podrá generar documentos ni ayudas en línea por lo que se recomienda que lo genere un compañero que cuente con el software MadCap Flare licenciado” 9. Cuando el ingeniero haya generado el impreso, se obtendrá un documento en formato .doc el cual corresponde al manual de usuario. Seguidamente el ingeniero reenviará el respectivo manual para que posteriormente se ajusten todos los respectivos cambios frente a los estilos predefinidos, lo que recomienda el área de documentación de la corporación de alta tecnología para la defensa es que las imágenes si son muy grandes, se pueden recortar, siempre y cuando se añada una referencia indicando el nombre de la figura para no perder la estructura del documento, además teniendo en cuenta que lo importante es que se pueda. 50.

(60) visualizar fácilmente la imagen, de lo contrario el cliente no podrá entender el contenido de las interfaces. Cabe resaltar que el procedimiento es repetitivo según la cantidad de módulos que fueron actualizados en la ventana de mantenimiento, es decir que si se actualizaron ocho módulos, se deberá obtener como resultado ocho manuales de usuario generados y actualizados con todos los cambios mencionados anteriormente.. Ahora que ya se dio una vista previa del procedimiento que se debe realizar para generar un manual de usuario, teniendo en cuenta los cambios aplicados en los módulos involucrados dentro de una ventana de mantenimiento, se procederá a mencionar los módulos y ventanas en las cuales se realizaron los respectivos ajustes. Tabla 10 Ventana de mantenimiento 1 Tabla diseñada acorde a cambios efectuados en la ventana de mantenimiento. Nombre de la Ventana. Ventana de mantenimiento No. OFI18066/MI.DIMOD - DDI 22 de Febrero 2018. Módulos Actualizados – Manuales de Usuario generados  ADJ (Módulo adolescencia y juventud)  CYD (Módulo crecimiento y desarrollo)  DAM (Módulo adulto mayor y vejez)  PMP (Programa materno perinatal)  SAM (Módulo salud mental)  SSR (Módulo salud sexual y reproductiva). 51.

(61) Tabla 11 Ventana de mantenimiento 2 Tabla diseñada acorde a cambios efectuados en la ventana de mantenimiento. Nombre de la Ventana. Ventana de mantenimiento No. OFI18117/MI.DIMOD - DDI 22 de Marzo. Módulos Actualizados – Manuales de Usuario generados  ADMIN (Módulo de administración)  CEX (Módulo de consulta externa)  CYD (Módulo crecimiento y desarrollo)  DAM (Módulo adulto mayor y vejez)  PMP (Programa materno perinatal). Tabla 12 Ventana de mantenimiento 3 Tabla diseñada acorde a cambios efectuados en la ventana de mantenimiento. Nombre de la Ventana. Ventana de Mantenimiento No. OFI18235/ MI.DIMOD - DDI 9 de Junio. Módulos Actualizados – Manuales de Usuario generados  ADJ (Módulo adolescencia y juventud)  AGE (Módulo de agendamiento)  AMB (Módulo de salud ambiental)  APS (Módulo administración del personal de salud)  PERSONADMIN (módulo personal administrativo)  POR (Módulo portafolio)  REP (Módulo reportes)  VAC (Módulo vacunación). Tabla 13 Ventana de mantenimiento 4 Tabla diseñada acorde a cambios efectuados en la ventana de mantenimiento. Nombre de la Ventana Ventana de Mantenimiento No. OFI18-. Módulos Actualizados – Manuales de Usuario generados  APS (Módulo adolescencia y juventud) 52.

(62) XXX/MI.DIMOD - DDI 14 de Julio Tabla 13. (Continuación) Módulos Actualizados – Manuales de Usuario generados. Nombre de la Ventana Ventana de Mantenimiento No. OFI18-. . XXX/MI.DIMOD - DDI 14 de Julio. PERSONADMIN (Módulo personal administrativo). Tabla 14 Ventana de mantenimiento 5 Tabla diseñada acorde a cambios efectuados en la ventana de mantenimiento. Módulos Actualizados – Manuales de Usuario generados. Nombre de la Ventana Ventana de Mantenimiento No. OFI18XXX/MI.DIMOD - DDI 16 de Agosto. . RYC (Módulo referencia y contrareferenica). 4.1.7 Versionamiento manuales de usuario El versionamiento es un procedimiento, cuyo fin es organizar y distribuir los diferentes cambios obtenidos, aplicando un control de versiones en los manuales de usuario ya generados. A continuación, se muestra el versionamiento efectuado en los manuales de usuario según los módulos involucrados en las ventanas de mantenimiento. Tabla 15 Versionamiento de manuales de usuario Tabla diseñada acorde a procedimiento de versionamiento. Ventana de Mantenimiento Ventana 1. Módulo   . ADJ CYD DAM. Versión   . 1.1 1.1 1.1 53.

(63) Tabla 15. (Continuación) Ventana de Mantenimiento Ventana 1. Ventana 2. Ventana 3. Ventana 4 Ventana 5. Módulo                   . PMP SAM SSR ADMIN CEX CYD DAM PMP ADJ AGE AMB APS PERSONADMIN POR REP VAC APS PERSONADMIN RYC. Versión                   . 1.1 1.1 1.1 1.2 1.1 1.2 1.2 1.2 1.2 1.1 1.2 1.1 1.1 1.2 1.2 1.1 1.2 1.2 1.1. A continuación, se presenta la tabla original que se utiliza para el control de cambios. Tabla 16 Tabla original control de cambios Imagen tomada y editada de manual de usuario vacunación (MU-VAC). 54.

(64) 4.1.8 Diseño de tabla costos y estados de cuenta en HTML puro El día 5 de octubre del presente año apoye al ingeniero Carlos Tous Mosquera en el diseño de una tabla de costos y estados de cuenta, la cual fue realizada durante la jornada laboral completa y desarrollada en HTML. Desafortunadamente la tabla, aunque cumplía de manera visual con el requerimiento del ingeniero, esta no pudo ser implementada ya que el código debía ser aplicado en el software MadCap Flare pero teniendo en cuenta que este no interpreta HTML sino XML, el software no detecto el estilo de la tabla. A continuación, se proporciona una vista previa de la tabla desarrollada en HTML puro y su respectivo código como muestra de desarrollo aplicado.. Figura 41 Tabla Desarrollada en HTML puro costos y estados de cuentas Imagen desarrollada por Oscar Ricardo Rosas Cruz. 55.

(65) Figura 42 código tabla costos y estados de cuentas Imagen desarrollada por Oscar Ricardo Rosas Cruz. 4.1.9 Actualización manual de sistema El proceso de actualización del manual de sistema en la corporación de alta tecnología para la defensa CODALTEC consiste en 8 pasos que se deben tener en cuenta. 1. Definiciones, acrónimos y abreviaturas: En esta sección se debe realizar una lista con todas aquellas definiciones existentes en el documento, ejemplo: . Repositorio: Sitio centralizado donde se almacena, mantiene, comparte y modifica información digital relacionada con el desarrollo de software.. . Acrónimos como: SQL (structured query language).. . Por último, abreviaturas como: etc. Etcétera.. 56.

(66) Cabe resaltar que es importante verificar todo el manual del sistema para validar si existen palabras desconocidas, las cuales, en caso de encontrarlas, se deben adjuntar en esta sección, buscar el significado y organizarla según corresponda. 2. Resumen del Sistema - descripción del servicio: En esta sección se debe realizar una descripción, acerca del módulo sobre el cual se está documentando el manual de sistema, y se debe especificar con viñetas las funcionalidades con las que cuenta el módulo. Estas funcionalidades se pueden encontrar fácilmente en el MadCap Flare. 3. Modelo de datos: En la sección de modelo de datos se encuentra el modelo entidad relación (M.E.R) correspondiente al módulo sobre el cual se está realizando la actualización del manual de sistema, este modelo lo genera el área de base de datos. Se debe tener cuenta que en algunos casos puede que el modelo aún no se encuentre generado, por lo que es necesario validar la información y de ser así solicitar su generación. 4. Acceso roles y permisos: En esta sección se realiza una tabla en la que se estipula los diferentes roles involucrados en el módulo sobre el cual se está desarrollando el manual de sistema, junto con sus respectivos permisos. Esta sección se puede realizar interactuando directamente con el sistema, aunque hay que tener en cuenta que a veces los roles son un poco difíciles de encontrar, por lo que en ocasiones es recomendable solicitar soporte a los desarrolladores. 5. Diagramas de estructura: En esta sección se tiene que diseñar un diagrama general en el que se especifique las diferentes relaciones que posee el módulo 57.

(67) sobre el cual se esta documentando el manual del sistema, con los demás módulos, validando también las relaciones, es decir, si es unidireccional o bidireccional. Cabe añadir que es recomendable diseñar este diagrama con el área de pruebas, ya que ellos tienen conocimiento por que interactúan con el sistema de manera constante, por lo que se les facilita localizar las diferentes interacciones para cada uno de los módulos. 6. Estructura de datos - diccionario de datos: En esta sección se debe crear una serie de tablas que contienen los atributos de las tablas del M.E.R sobre la cual se va a realizar el diccionario de datos, teniendo en cuenta que se puede estructurar dando un nombre de la columna, especificando el tipo de dato, longitud, si es nulo o no, y dando una descripción del atributo. El procedimiento es repetitivo ya que tiene que abarcar las tablas del modelo entidad relación que interactúa con el módulo. También es importante tener en cuenta los estilos predefinidos. 7. Capas del sistema: En esta sección se debe tener en cuenta, los controladores, modelo(s) de vista(s), vista(s) y los BL, estos archivos solo son proporcionados por personal autorizado y el manejo de este requiere de organizar la información en unas tablas de una forma similar al diccionario de datos, pero con la diferencia que aquí se debe tener cuidado con las relaciones frente a los modelos de vista y vistas por que pueden ser muchos a muchos, uno a muchos o uno a uno. Es importante tener en cuenta los estilos predefinidos, además, se debe realizar una descripción de la misma y se tiene que proporcionar las funcionalidades que interactúan con el sistema. Realizar este último procedimiento puede conllevar 58.

(68) tiempo debido a que se debe hacer una búsqueda de todas las funcionalidades que interactúen con esos modelos de vista y esas vistas. 8. Interfaces de usuario: Para finalizar se deben añadir todas las interfaces correspondientes a cada una de las funcionalidades del módulo, teniendo en cuenta que estas no se pueden repetir, y que en muchas ocasiones una imagen estará más actualizada que otra. De igual manera se debe tener presente la estandarización frente a los tamaños de las imágenes, si son vistas, cuadros de dialogo entre otros se deberá respetar como en todos los manuales los tamaños, referencias cruzadas entre otros. Teniendo en cuenta el procedimiento implementado por la corporación de alta tecnología para la defensa CODALTEC para la actualización del manual de sistema, apoyé con la actualización de 3 módulos los cuales son: . MOD-VAC (módulo vacunación).. . MOD-ADMIN (módulo administración).. . MOD-PQX (módulo procedimientos quirúrgicos).. 59.

(69) 4.1.10 Actualización módulo características generales de los programas de promoción y prevención (CGP) y administración (ADMIN) fase V El proceso de actualización del módulo características generales de los programas de promoción y prevención fue la última tarea desarrollada en la corporación de alta tecnología para la defensa CODALTEC. Consistió en realizar una serie de procedimientos descritos a continuación: 1. Se identificó tres cambios generados para la fase v en el módulo características generales de los programas de promoción y prevención (CGP), los cuales fueron validados por el desarrollador Ingeniero Miguel Moreno. Cabe aclarar que los cambios encontrados fueron aplicados en módulos diferentes a CGP, los cuales fueron, módulo de administración (ADMIN) y los programas de promoción y prevención.. Figura 43 Funcionalidad detectada en módulo ADMIN. Imagen tomada de SALUD.SIS. 60.

(70) 2. Se realizaron las actualizaciones para los módulos (ADMIN, ADJ, CYD, DAM, ODO, PSO, SSR) creando nuevos tópicos y describiendo las nuevas funcionalidades añadidas para cada uno de los módulos en el software MadCap Flare.. Figura 44 Funcionalidad implementada en los programas de promoción y prevención. Imagen tomada de SALUD.SIS 3. Una vez realizadas las actualizaciones en los módulos definidos anteriormente, se realizó la integración gracias a la herramienta git extension, la cual permitió efectuar la actualización en el repositorio. 4. Finalmente, se ajustó en el software MadCap Flare la estructura de los manuales de usuario para la fase V.. 61.