Documento Técnico de Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos PDF

 Contenido Etapa de análisis y diseño del sistema................................................................................................. 3 Análisis del Sistema...............................

 Contenido Etapa de análisis y diseño del sistema................................................................................................. 3 Análisis del Sistema........................................................................................................................... 4 Consideraciones para seleccionar un gestor de base de datos........................................................... 4 Elementos de la etapa de análisis................................................................................................ 6 Productos generados en la etapa de análisis................................................................................. 7 Herramientas propuestas para diagramación.............................................................................. 12 Diseño del Sistema....................................................................................................................... 13 Elementos de la etapa de diseño................................................................................................ 14 Productos generados en la etapa de diseño................................................................................ 16 Herramientas propuestas para Diagramas ER y UML................................................................ 18 Anexos......................................................................................................................................... 27 Anexo 1. Guía de diagramación para procesos BMPN.............................................................. 27 Anexo 2. Plantilla de Plan de Trabajo para el Desarrollo de Aplicaciones.................................. 33 Anexo 3. Formato propuesto de Cronograma............................................................................ 35 Anexo 4. Manual para el nombramiento de objetos de base de datos......................................... 35 Anexo 5. Manual de Integración de Sistemas............................................................................ 40 Modificaciones............................................................................................................................. 44 ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 2  Etapa de análisis y diseño del sistema Metodología Scrum Equipos que Componen los Procesos Scrum Para el caso del Ministerio de Hacienda en la etapa de Análisis y Diseño no se cuenta con amplia experiencia de la implementación de SCRUM sin embargo en términos de investigación y tomando en cuenta la experiencia en la aplicación en otras etapas, para los casos que se considere su implementación en dicha etapa se establece a continuación, cuáles son los actores que conforman la metodología Scrum y con los cuales se trabajará, cada quien con sus respectivas responsabilidades. 1. Product Owner Forma parte del usuario funcional o la parte interesada y actúa como intermediario entre este y el equipo de análisis y diseño. Por ello debe ser capaz de hablar el lenguaje del negocio o de los requisitos del usuario y estar familiarizado con los métodos y conceptos empleados por el equipo. Es la primera línea de comunicación entre usuarios finales y el equipo técnico analista y diseñador de software. Liderar el proceso de identificación, recopilación y documentación de procesos y coordinación de todos los responsables de las diferentes direcciones de la institución. Debe expresar claramente los elementos de la lista de requerimientos a ser analizada. Debe asegurar que la lista de requerimientos a analizar sea visible, transparente y clara para todos. Debe asegurar que el Equipo de Análisis y Diseño entiende los elementos de la lista de requerimientos. 2. Scrum Master (Coordinador de la realización de las actividades de Análisis y Diseño) Scrum Master no es un Jefe de Proyecto sino más bien se le considera un facilitador, su principal objetivo es mejorar la productividad de los participantes del proyecto, facilita el trabajo y elimina interferencias, fomenta también las prácticas ágiles. Es el responsable de asegurar que Scrum se entienda y se adopte. Es quien forma parte de las mesas de trabajo con las áreas involucradas con el fin de optimizar las actividades de análisis y diseño para lograr los objetivos establecidos. Es un líder que está al servicio del equipo Scrum. Ayuda a las personas externas al equipo Scrum a entender qué interacciones con el equipo. Identifica y promueve oportunidades de mejora de los procesos para las áreas de la institución. Elimina inconvenientes para el progreso del Equipo de Análisis y Diseño. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 3  3. Scrum Team Los componentes del equipo de trabajo no tienen un rol especifico asignado, pero sin ellos es imposible llevar a fin claro el trabajo con la ayuda del Scrum Master, el equipo deberá ser capaz de realizar el seguimiento de la evolución de su productividad y presentar los productos finales de la etapa de análisis y diseño. 4. Stakeholders Compuesto por todas las personas e instituciones que tienen algún interés en el trabajo generalmente los usuarios finales. Análisis del Sistema Los actores en esta etapa son Arquitecto o Analista de Sistemas de la unidad informática. Actividades: Análisis del Documento Técnico Funcional. Evaluar el impacto de cambio en aplicaciones existentes y en la organización. Elaborar un listado de requerimientos verificados que serán insumo para el plan de trabajo. Elaboración de diagramas para la representación del modelo. Elaboración de diagramas para representar los procesos. Selección de lenguaje de programación (Revisar sección de lenguaje de programación propuestos en etapa de construcción) Selección de gestor de base de datos. Paralelo al análisis de requerimientos del sistema, los analistas deben realizar la selección del gestor de la base de datos, para lo cual se recomienda tomar en cuenta las consideraciones siguientes: Nota: La selección aplica para nuevos proyectos debido a que en el Ministerio de Hacienda en la mayoría de direcciones ya se cuenta con un gestor de base de datos. Consideraciones para seleccionar un gestor de base de datos 1. Que sea fácil de usar La primera cosa a tener en cuenta al elegir un sistema de gestión de los elementos de una base de datos para la institución es la facilidad de uso. Asegurarse que el sistema sea fácil de usar para todos los miembros del personal que van a necesitar utilizarlo. Por ejemplo, tendrán que utilizarlo programadores, resto del personal de IT. Si estos grupos de personas van a tener que acceder al GBD deberías comprobar que se trata de un GBD conveniente y fácil de utilizar según sus habilidades. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 4  2. Seguridad de los Datos La seguridad de datos es un aspecto integral en la implementación de una base de datos. Toda la información, tanto personal como de negocios, debe tener carácter confidencial y debe estar almacenada de forma segura, protegida de robo o pérdida. Por lo tanto, tener en cuenta tanto los riesgos físicos como puede ser un robo, como los riesgos derivados de errores humanos, como el facilitar la piratería o la corrupción de datos no intencional, antes de elegir un sistema de gestión de base de datos para mantener los datos seguros y protegidos. 3. Funcionalidad Asegurarse de que todos los módulos que están disponibles en el GBD cumplen con los requisitos del negocio. Al menos debería de tener los siguientes módulos o funcionalidades: Consultas y análisis de resultados de operación Estrategia de predicción Automatización de datos Capacidad de modelado y segmentación de datos Filtrar y extraer datos Copia y restauración de datos 4. Capacidad de integración Puede que en un futuro se quiera integrar el sistema de gestión de base de datos con otros sistemas que se esté utilizando. Asegurarse que el sistema tiene la capacidad de integrarse con ellos. 5. Soporte y Desarrollo Pensar en el servicio de soporte ofrece para el sistema de gestión de base de datos. ¿Se trata de un servicio que está disponible durante las horas en las que es probable se necesite ayuda? ¿Proporcionan apoyo a través de correo electrónico, teléfono u otros medios? Asegurarse que existe un plan de desarrollo para el software seleccionado de modo que se pueda estar seguro que a medida que aparecen nuevas tecnologías éste crecerá con ellas. Confirmar que se va a recibir las actualizaciones mientras se utiliza el software. 6. Escalabilidad Asegurarse que el GBD seleccionado tiene capacidad para crecer con los datos y la empresa. Debido a que se seguirá añadiendo datos todo el tiempo, por lo que a pesar de que el requisito ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 5  actual puede no ser enorme, esto puede cambiar muy rápidamente. Pensar que se puede gestionar millones de registros de datos para estar seguro. 7. Costo e Idoneidad El costo es un factor importante, asegurarse que la decisión está basada sobre todo en que el GBD que se selecciona sea el adecuado para la institución. Si se selecciona uno barato pensando solo en el precio se podría cometer un error todavía mayor ya que se podría obligar a invertir pronto en uno nuevo asumiendo otra vez los costos del software y su implementación. Tampoco se elige el más caro si no se van a utilizar la mayor parte de su funcionalidad. 8. Recomendación Se recomienda seleccionar para el proyecto un gestor de base de datos con el que se posea soporte institucional o del fabricante, además de experiencia institucional y licenciamiento disponible. Al momento de la elaboración de este documento el gestor de base de datos utilizado en la mayoría de Direcciones del Ministerio de Hacienda es Oracle, cumpliendo con todos los puntos mencionados anteriormente. De existir razones relevantes por las cuales no sea posible utilizar Oracle, tales como incompatibilidad con aplicativos, establecimiento de un gestor de base de datos específico por parte de Instituciones Cooperantes, u otros motivos de peso, podrá reconsiderarse la presente recomendación. A continuación, se presenta el esquema para el análisis de requerimientos. Elementos de la etapa de análisis ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 6  INSUMOS PRODUCTOS PROCESO PROCESO PARA LA GESTION DE CAMBIOS 1. Documento 1. Modelo: 4. Verificar 8. Aprobación funcional Técnico Diagrama de requerimientos de modificación del Funcional y componentes 5. Elaborar listado de requerimiento otros Diagrama de requerimientos 9. Modificación de documentos de Contexto. verificados y documento de apoyo. 2. Diagrama de elementos del requerimientos flujo de procesos. modelo. 10. Envío de documento 2. Herramientas 3. Plan de trabajo. 6. Elaborar plan de de requerimientos de diagramación de trabajo. modificado a Analista flujos de procesos 7. Validar plan de 11. Evaluación de cambios trabajo con los en los documentos de interesados. análisis 12. Aprobación o rechazo de la modificación solicitada 13. Modificación de Plan de Trabajo. Productos generados en la etapa de análisis 1. Diagramas para representar el modelo A continuación, se listan diagramas con sus características además de estos se puede incluir otros diagramas que muestren los límites, alcances y aspectos generales, a consideración de los responsables de esta etapa. Diagrama de Componentes Diagrama de Contexto Representan relaciones entre componentes Define los límites entre el sistema o parte de el con individuales mediante una vista de diseño su ambiente mostrando una vista de alto nivel. estática. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 7  Diagrama de Componentes Diagrama de Contexto CARACTERISTICAS Los componentes son partes modulares e Muestra las entidades que interactúan con él. independientes entre sí. Comprende sistemas, ambientes y Son auto contenidos. actividades con las que interactúa. Su comunicación es por medio de Comprende factores externos y eventos que interfaces. generan restricciones al sistema Las interfaces documentan relaciones y Muestra el alcance del sistema. dependencias. Debe desarrollarse en lenguaje sencillo y de fácil comprensión. BUENAS PRACTICAS PARA SU ELABORACION 1. Determinar el propósito del diagrama e 6. Determinar el propósito del diagrama e identificar los artefactos como los identifique las actividades principales que archivos, documentos, etc., del sistema o resolverá el sistema. aplicación que se necesita representar en el 7. Elija el formato de objetos para representar diagrama. las actividades principales o módulos del 2. A medida que se determinen las relaciones sistema. entre los elementos que identificó 8. Cree una estructura mental de su diagrama anteriormente, cree una estructura mental de contexto. de su diagrama de componentes. 9. Determine con base en lo anterior, los 3. A medida que se dibuja el diagrama, módulos que serán necesarios para resolver agrega componentes primero, la problemática planteada. agrupándolos dentro de otros componentes 10. Ponga en el centro de su diagrama el como te parezca conveniente. nombre del sistema dentro del tipo de 4. El siguiente paso es añadir otros elementos objeto seleccionado y a continuación como interfaces, clases, objetos, ponga los módulos alrededor, uniendo con dependencias, etc. a su diagrama de flechas o líneas. componentes y completarlo. 11. El siguiente paso es añadir notas sobre diferentes partes de su diagrama o actores principales, si es necesario para un mejor entendimiento del diagrama. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 8  Diagrama de Componentes Diagrama de Contexto 5. Puede adjuntar notas sobre diferentes partes de su diagrama de componentes para aclarar ciertos detalles. OBJETIVO DE CONSTRUIR LOS PRESENTES DIAGRAMAS Puede ayudar a comprender la Se utilizan como modelo inicial para estructura final del sistema. establecer el alcance del problema a solucionar. Ayuda a que el trabajo de desarrollo Aclarar los límites de la solución, las tenga un objetivo claro. entidades con las que tiene relación y ayuda a la comprensión de los interesados o stakeholders. Es útil para que el grupo de trabajo comprenda el sistema. Facilita la reutilización de componentes de sistemas de software y la utilización de sus servicios. 2. Diagramas para representar procesos A continuación, se listan tipos de diagramas con sus características para representar procesos de negocio, que sirvan de insumo para la definición detallada de los productos de la etapa de diseño, a consideración de los responsables de esta etapa. Diagramas de Flujo Diagramas BPMN Los diagramas de flujo son una manera de BPMN es un lenguaje de diagrama de proceso. Describe representar visualmente el flujo de datos través en una imagen los pasos en un proceso de negocio, de sistemas de tratamiento de información. desde su comienzo hasta la conclusión. CARACTERISTICAS Facilitan la comprensión de cómo están Es el estándar internacional más difundido y aceptado, desarrollando sus procesos y actividades. para definir, modelar y compartir procesos de negocios en el marco de la Disciplina BPM. BPMN significa «Notación para la Gestión de Procesos de Negocios». ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 9  Diagramas de Flujo Diagramas BPMN Facilitan comprensión de problemas Existen varios lenguajes de diagramación de procesos complicados y sobre todo muy largos. desde la década de 1980, que han desarrollado este estándar. Ayuda a mejorar las practicas organizacionales. Crea un puente estandarizado para disminuir la brecha entre los procesos de negocio y la implementación de estos. Es independiente de cualquier metodología de modelado de procesos. Permite modelar los procesos de una manera unificada y estandarizada permitiendo un entendimiento a todas las personas de una organización. Buenas prácticas para la elaboración de diagramas BPMN Los diagramas deben ser desarrollados hasta mostrar el detalle de las actividades, al momento de construir su diagrama tenga en cuenta estos principios básicos. Mantenga una secuencia lógica y clara Nombre claramente los elementos Simplifique los diagramas A continuación, encontrara una serie de puntos útiles para seguir estos principios. 1. Mantenga una secuencia lógica y clara Defina un inicio y un fin Siga una dirección consistente en el flujo: evite el cruce de conectores, mantenga una secuencia y dirección clara. Mantenga claro el escenario primario: el camino principal debe ser fácilmente identificable al leer el diagrama. Se sugiere diagramar primero el escenario principal y luego agregar los caminos alternativos. Distinga escenarios finales de exitosos y no exitosos: utilice eventos de finalización separados para identificar cuando un proceso ha finalizado exitosamente y cuando no. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 10  Mantenga un formato: enfóquese en una apariencia limpia y amigable, evite utilizar diferentes tamaños de fuente, dimensiones de caja o sobreponer etiquetas ya que esto puede dificultar la lectura del diagrama. 2. Nombre claramente los elementos: un correcto nombramiento es fundamental para un fácil y correcto entendimiento de los procesos. Algunas recomendaciones se listan a continuación: Los nombres deberían describir claramente su propósito, no se recomienda utilizar nombres cortos o abreviaturas. Nombre las actividades con un verbo y un objeto, esto ayudara a identificar claramente el objetivo de la tarea. No etiquete los eventos de inicio y fin cuando son únicos, es común nombrarlo como inicio o fin del proceso, pero esto es redundante o innecesario. Nombre los eventos cuando se utilizan múltiples eventos de inicio o fin, nómbrelos de acuerdo a lo que representan y evite repetir nombres. Las compuertas deberán tener un nombre adecuado que indique la decisión o condición evaluada, puede incluso utilizar preguntar para clarificar la decisión involucrada. Si no aplica nombres para una compuerta, utilice abreviaciones o números para diferenciarlas. Nombre las transiciones indicando la condición relacionada. 3. Simplifique los diagramas: se debe tener una definición correcta del alcance de las tareas y el nivel de detalle de los procesos para reducir el exceso de información, los siguientes puntos ayudaran a simplificar los diagramas: Reduzca el número de tareas redundantes. Tener claro el nivel de detalle Utilice sub procesos para agrupar actividades que tienen el mismo propósito, quedando la posibilidad de ampliar luego los sub procesos para exponer los detalles. Para la creación de diagramas y la correcta utilización de cada uno de los componentes verificar el siguiente Anexo 1. Guía de diagramación para procesos BPMN. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 11  3.Plan de Trabajo o cronograma Un plan de trabajo muestra la información necesaria para llevar a cabo un proyecto y define los objetivos, los procesos y los tiempos de entrega. Es una herramienta que sirve de guía y establece estrategias que permiten alcanzar objetivos mediante la colaboración y el trabajo en equipo. A continuación, se proponen los datos mínimos que debe contener: a. Objetivos b. Alcance c. Lista de actividades y responsables d. Tiempos de ejecución de tareas e. Recursos necesarios f. Premisas para alcanzar los resultados g. Cronograma En este sentido se propone un formato estándar definido en el documento “Anexo 2. Plantilla de Plan de Trabajo para el Desarrollo de Aplicaciones”, para su elaboración. Nota: El plan de trabajo podría resumirse en un cronograma en donde claramente muestre la lista de actividades para representar los objetivos y alcance del proyecto, definiendo tiempos, responsables y recursos necesarios para cada una de las tareas descritas. Anexo 3. Formato propuesto de cronograma Herramientas propuestas para diagramación Algunas de estas alternativas ofrecen la posibilidad de dibujar y compartir los diagramas online para trabajo colaborativo inclusive. La misión de estos softwares es coordinar a las personas, máquinas y objetos para colaborar en la mejora y transformación de los procesos de negocio. A continuación, se presentan alternativas para el modelado de diagramas de flujo de datos de igual manera si se tiene otra herramienta que genere lo requerido se puede optar por ella. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 12  Herramienta Licencia Flokzu Gratuita BPMN.IO Pago Bizagi Pago y versión gratuita. BonitaSoft Pago y versión gratuita. Lucidchart Pago y versión gratuita limitada. Edraw Gratuita y pago Wireflow Gratuita Creately Pago Google Drawings Gratuita Diseño del Sistema Los actores en esta etapa son los Arquitectos o Analistas de Sistemas. Actividades Elaborar modelo de datos y/o clases. De ser necesario modificar las interfaces definidas en el documento técnico funcional tomando en cuenta definiciones y validaciones definidas en la etapa de requerimientos. Definir interrelaciones entre componentes o integraciones con otros sistemas, entradas, salidas y procesamiento de la información que se integra. Diagrama entidad-relación Definición del diseño de la arquitectura de la solución ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 13 Elementos de la etapa de diseño INSUMOS PRODUCTOS PROCESO PROCESO PARA LA GESTION DE CAMBIOS Documento 1. Modelo de datos: 1. Elaboración de modelo 1. Aprobación técnico Expresado en modelo de de datos (Diagrama ER funcional de funcional o clases o en diagrama o Diagrama de Clases) modificación del requerimiento. entidad-relación (De 2. Realizar la verificación requerimiento acuerdo a estándar de las interfaces de 2. Modificación de Modelo y definido en el documento usuario y su documento de procesos “Anexo 4. modificación de ser requerimiento o elaborados en Manual para el necesario. documentos del la etapa de Nombramiento de análisis de análisis. Objetos de Bases de ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 14  INSUMOS PRODUCTOS PROCESO PROCESO PARA LA GESTION DE CAMBIOS Datos”). 3. Describir las relaciones 3. Envío entre componentes o documentos integraciones con Herramientas 2. Diccionario de datos (De componentes externos modificados a de acuerdo a estándar en un documento. encargado del diagramación. definido en el documento 4. Validar documentos de diseño de “Anexo 4. diseño con usuarios. 4. Evaluación los Manual para el 5. Gestión de cambios de cambios en de Nombramiento de requerimientos. documentos Objetos de Bases de diseño o Datos”). 5. Aprobación la 3. Verificación y rechazo de modificación de ser modificación necesario de interfaces de solicitada del documento funcional. 6. Modificación 4. Documento de definición Plan de Trabajo de relaciones o integraciones. 5. Metodología de desarrollo (elementos a considerar para la definición) 6. Diseño arquitectónico ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 15  Productos generados en la etapa de diseño Modelo de datos Modelo de Clases Modelo Entidad-Relación Diccionario de Datos Es de Es la representación Contiene características de los estructura estática. abstracta del modelo de datos que se utilizan en el Describe la datos. sistema. estructura del Muestra de manera Debe contener al menos los sistema. simplificada los siguientes datos por cada uno de Muestra clases, componentes de un sus elementos descritos. atributos, proceso y sus relaciones ✓ Identificación del sistema: métodos y entre sí, se dibujan hasta nombre del sistema que relaciones entre con tres niveles de soporta la base de datos. objetos. detalle que son, modelos ✓ Nombre de la base de datos Tiene conceptuales, modelos y fabricante: nombre físico relaciones lógicos y modelos de de la base de datos, estáticas datos físicos. descripción y nombre del (Herencia, Comprende los fabricante o marca del composición, siguientes elementos motor. agregación, principales: ✓ Nombre de Entidad asociación y Entidades, conjunto de o Tabla: nombre de entidad dependencia) entidades, categorías o tabla que contiene el Existen varios de entidades, Atributos campo o columna descrita. tipos de clases: (describe las ✓ Nombre de Campo o Entidad, de propiedades de cada Columna: para distinguir un Interfaz, entidad) y relaciones dato de otro. Abstractas y de (establecen vínculos ✓ Descripción: indica lo que Control. entre parejas de el campo o columna entidades), representa en el sistema. cardinalidad. ✓ Tipo de dato: para determinar el tratamiento que debe dársele. ✓ Longitud: porque es de importancia de saber la ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 16  Modelo de Clases Modelo Entidad-Relación Diccionario de Datos cantidad de espacio necesario para cada dato. ✓ Restricción: porque en algunos procesos solo son permitidos valores muy específicos para los datos. Si los valores de los datos están restringidos a un intervalo específico, esto debe estar en la entrada del diccionario. Tabla #1. Formato para diccionario de datos de un sistema informático. Nombre del sistema de información Nombre de la base de datos Descripción de la base de datos Nombre y fabricante del DBMS Oracle ENTIDAD NOMBRE TIPO LONGITUD NULO RESTRICCION DESCRIPCION DE CAMPO Nombre de Nombre Tipo de dato Tamaño del En esta Indicar las la asociado al del campo, campo columna relaciones con Breve tabla en la campo de la por ejemplo indicar si el otras tablas de la descripción base de tabla de base (Integer,varc campo base de datos. asociada al datos de datos har,etc.) acepta campo y su valores contenido. NULL (SI: acepta valores ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 17  NULL, NO: no acepta valores NULL) Modelo Físico de Datos Un modelo físico de datos, representa como se construirá el modelo en la base de datos. Muestra todas las estructuras de tabla, incluidos el nombre de columna, el tipo de dato, las restricciones, la llave principal, llaves externas y las relaciones entre las tablas. La consideración especial es que el modelo de datos físico es diferente según en gestor de base de datos y generalmente se utiliza un programa utilitario de diseño de bases de datos para generarlo, al cual se le debe especificar el driver respectivo del gestor de base de datos a utilizar. Herramientas propuestas para Diagramas ER y UML Herramienta Licencia Edraw UML Diagram Pago UMLet Versión gratuita Visio Pago StarUML Versión de evolución sin límite de tiempo, sin soporte. ConceptDraw Diagram Versión gratuita de uso no comercial Creately Pago Power Designer Pago Rational Pago BOUML Versión gratuita ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 18  Herramienta Licencia ArgoUML Versión gratuita Elementos a considerar para la verificación y modificación de diseño de interfaces de usuario Comprende un conjunto de principios de diseño identificando objetos y acciones de esta para luego crear una pantalla que constituye la base del prototipo de la interfaz de usuario. Que comprende una interfaz: Ventanas Menús Botones Opciones Imágenes Características básicas para construir una buena interfaz: 1. Las acciones deben ser rápidas y reversibles, con efectos inmediatos. 2. Diseño ergonómico mediante menús, barras de acciones e íconos de fácil acceso. 3. Representación fija del contexto de acción (fondo). 4. Las interacciones se deben basar en acciones físicas sobre elementos visuales. 5. El objeto de interés ha de ser de fácil identificación. 6. Existencia de herramientas de ayuda y consulta. 7. Facilidad de compresión, aprendizaje y uso. Reglas de diseño de la interfaz de usuario: 1. Dejar el control al usuario. 2. Reducir la necesidad de que el usuario memorice 3. Hacer consistente la interfaz A continuación, se muestra una tabla general de elementos que se deben tener en cuenta para el desarrollo de aplicaciones web: ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 19  Nombre del dominio El nombre de dominio es la puerta de entrada a un sitio web. Su composición de nombre y dominio genérico deben informar de manera clara y directa el tipo de sitio al que el usuario va a ingresar. El sitio web dispone de un nombre de dominio claro y único para la institución. Interacción con Los enlaces se distinguen del texto normal e indicar si fueron visitados, estos enlaces deben estar representados por palabras subrayadas de color diferente al color primario del texto normal. Estructura de La aplicación debe contar con una estructura de navegación consistente, la barra navegación de navegación debe ser la misma para todas las paginas además siempre se debe tener un botón que permita regresar al inicio. Diseño Mantener un diseño limpio y ordenado en el que se distingan cada uno de los elementos, hacer un uso adecuado de los colores y tener un manejo controlado de tipos de letras, los cuales se sugiere no excedan de dos tipos diferentes. En el Ministerio de Hacienda todas las aplicaciones para el público desarrolladas con tecnología web deberán cumplir con lo establecido por las autoridades actuales en los lineamientos para el desarrollo de aplicaciones web, estos lineamientos excluyen todos aquellos portales ya existentes y los de uso interno del Ministerio de Hacienda” o aquellos que tengan otros estándares por políticas de los cooperantes. Documento de definición de relaciones o integraciones La integración del sistema es un proceso de administración de datos que utiliza software para compartir información entre varios subsistemas automáticamente. Como cada sistema está programado con diferentes codificaciones, un integrador actúa como un intermediario que traduce los datos de cada software detrás de las escenas. Sin esta solución, la información tendría que ser introducida manualmente por una persona designada para dicho fin, aumentando el riesgo de error humano y costando al negocio los gastos adicionales de tiempo y mano de obra. Otro factor de gestión a tener en cuenta son los diferentes tipos de procesos de integración de sistemas disponibles, ya que cada uno de estos métodos tiene un propósito diferente. Para la creación del documento de Integraciones se utilizará el Anexo 5. Manual de Integración de Sistemas. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 20  Un elemento fundamental a definir dentro del diseño son los elementos de arquitectura del sistema, a través de los cuales se especifica el funcionamiento de la aplicación en sus distintas capas por lo que se que se detallan a continuación los patrones de software sugeridos a tomar en cuenta. Patrones de Software El uso de patrones de software nos provee soluciones a problemas comunes en él, ya que la estructura de las clases que conforma la solución de un problema puede estar ya inventada, si la forma de solucionar ese problema se puede extraer, explicar y reutilizar en múltiples ámbitos, entonces nos encontramos ante un patrón de diseño de software. El uso de patrones dentro de las dependencias del Ministerio de Hacienda es de vital importancia para aprovechar las ventajas que cada uno ofrece ahorrando tiempo de desarrollo, generando un lenguaje común y estandarizado. Patrones arquitectónicos Los patrones arquitectónicos, o patrones de arquitectura, también llamados arquetipos ofrecen soluciones a problemas de arquitectura de software en ingeniería de software. A través de los años se han usado diversos patrones dentro del Ministerio de Hacienda. Un patrón arquitectónico expresa un esquema de organización estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones. Para el diseño de la arquitectura se recomienda usar los siguientes patrones dependiendo del caso de uso de la aplicación a desarrollar. 1. Programación por capas. Puede utilizarse para estructurar programas que pueden descomponerse en subtareas. Cada una de ellas proporciona servicios a la capa siguiente y podemos encontrar los 4 comunes: capa de presentación, de aplicación, de lógica de negocios y de acceso a datos. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 21  2. Arquitectura de microservicios. Basa la construcción de las aplicaciones en un conjunto de pequeños servicios que se ejecutan en su propio proceso y se comunican con mecanismos ligeros. Por ejemplo: una API con recursos HTTP. Cada uno de estos servicios independientes se encargará de implementar una funcionalidad. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 22  3. Patrón cliente-servidor. El primero, se encarga de proporcionar servicios a múltiples componentes del cliente, mientras que este solicita servicios del servidor. Se trata de una especie de ‘escucha’ constante de las solicitudes del cliente. Patrones de Diseño Describen soluciones en un nivel medio de estructuras de software. Normalmente soportan requerimientos funcionales (especificaciones técnicas del sistema). Patrón de modelo-vista-controlador Divide una aplicación interactiva en 3 partes, como se detallan a continuación: Modelo: contiene la funcionalidad y los datos básicos Vista: muestra la información al usuario (se puede definir más de una vista) Controlador: maneja la entrada del usuario Esto se hace para separar las representaciones internas de información de las formas en que se presenta y acepta la información del usuario. Desacopla los componentes y permite la reutilización eficiente del código. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 23  A continuación, se muestra un cuadro resumen de los resultados finales de la implementación de la etapa en cada una de las direcciones o unidades del Ministerio de Hacienda teniendo en cuenta que los requerimientos analizados pueden estar relacionados a sistemas nuevos o sistemas existentes. ANALISIS Sistemas Nuevos ✓ Selección del lenguaje de programación. ✓ Selección del gestor de base de datos. ✓ Análisis del documento técnico funcional ✓ Elaboración del listado de requerimientos verificados. ✓ Diagrama de componentes o diagrama de contexto. ✓ Diagrama de flujos o BPMN. ✓ Elaboración de plan de trabajo o cronograma de actividades. Sistemas existentes ✓ Análisis del documento técnico funcional. ✓ Elaboración del listado de requerimientos verificados. ✓ Diagrama de flujos o BPMN, para todos aquellos cambios en los que implica cambios en el proceso. ✓ Elaboración del plan de trabajo o cronograma de actividades para todos aquellos cambios mayores. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 24  DISEÑO Sistemas Nuevos ✓ Revisión y modificación de las interfaces definidas en el documento funcional. ✓ Definir documento de definición de interrelaciones o integraciones. ✓ Definición de la arquitectura de la solución. ✓ Definición de patrones de diseño a implementar. ✓ Modelo de datos: Modelo entidad-relación, modelo de clases y diccionario de datos. ✓ Modelo físico ✓ Diagrama entidad-relación. Sistemas existentes ✓ Revisión y modificación de las interfaces definidas en el documento funcional. ✓ Definir documento de definición de interrelaciones o integraciones, para los cambios que se comunican con otros componentes o sistemas. Para los cambios que implican la creación o modificación de elementos de la base de datos. ✓ Modelo de datos: Modelo entidad-relación, modelo de clases y diccionario de datos. ✓ Modelo físico. Apoyo con la herramienta Tuleap Al ejecutar la etapa de Análisis y Diseño podemos apoyarnos en la herramienta Tuleap para almacenar la documentación relacionada a diagramas, planes de trabajo, informes y otros, en la sección de Documentos. En lo que respecta a la aplicación del marco de trabajo Scrum, Tuleap ofrece diferentes trackers como el de Épicas e Historias de usuario, de modo que es posible crear los artefactos que conformarán el backlog del proyecto y que serán trabajados en los diferentes Sprints, teniendo como insumo los requerimientos definidos en la etapa anterior. Planificación de Releases Se recomienda planificar en esta etapa los diferentes entregables del proyecto mediante la creación de Releases, tracker con el cual cuenta la herramienta Tuleap. Los entregables deben ser tomados en cuenta ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 25  en el plan de trabajo. Desde el tracker de Releases, podremos consultar o ingresar dichos artefactos completando el formulario respectivo. El número de versión de un Release, por convención, es el siguiente: Nombre de la aplicación+Correlativo Ejemplo: APP CONSTANCIAS 1 En resumen, los productos de software a entregar son asociados a los Releases, los cuales deben ser planificados en la etapa de Análisis y Diseño, luego proceder a su desarrollo en la etapa de Construcción, ejecutándose posteriormente la etapa de Pruebas, y en caso de ser exitosas se finaliza en la etapa de Puesta en Producción. La transición de los estados transcurre a lo largo de dicho ciclo de vida. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 26  Anexos Anexo 1. Guía de diagramación para procesos BMPN La presente es una guía de los elementos utilizados para la diagramación y su correcto uso. Elementos que debe cumplir un diagrama BMPN La función del BPMN es crear un mecanismo simple para realizar modelos de procesos de negocio, con todos sus elementos gráficos, y que al mismo tiempo sea posible gestionar la complejidad. El método elegido para manejar estos dos conflictivos requisitos es organizar los aspectos gráficos de la notación en categorías específicas. Un diagrama de procesos de negocio está compuesto por diferentes elementos necesarios para construir los flujos de negocio los cuales se presentan a continuación: Simbología BPMN 1. Eventos Los eventos son estados que nos indican que en el proceso de negocio algo importante ha ocurrido. En BPMN los eventos pueden iniciar un proceso, ser provocados durante el proceso o terminar un proceso. Los eventos que han ocurrido son condiciones generadas por una causa externa. Estos pueden ser eventos de inicio o intermedios. Los eventos desencadenados son condiciones generadas por el propio proceso y pueden ser eventos intermedios o finales. TIPO DE EVENTO SIMBOLOGIA DESCRIPCION Evento de inicio El evento de inicio desencadena el flujo de secuencia de un proceso. Evento intermedio Un evento intermedio interrumpe temporalmente el flujo de secuencia del proceso. Evento final El evento final finaliza el flujo de secuencia del proceso. 1.1 Tipos de Eventos de Inicio SIMBOLOGIA DESCRIPCION No tiene establecida una condición o requisito de inicio al proceso o subproceso. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 27  SIMBOLOGIA DESCRIPCION Un proceso o aplicativo envía un mensaje para dar inicio a un proceso. Se puede fijar una hora o fecha específica en la que se activara el inicio del proceso. 1.2 Tipos de Eventos Intermedios SIMBOLOGIA DESCRIPCION Es usado para enviar o recibir un mensaje de otros procesos o aplicativos y debe tener el mismo nombre en el mensaje. Es un mecanismo de retraso dentro del proceso. Este tiempo puede ser definido en una expresión fecha o unidad de tiempo. Permite conectar dos secciones de un proceso para crear situaciones de bucle o para evitar líneas de secuencia de flujo largas o cruzadas y están limitados a un nivel de proceso. 1.3 Tipos de Eventos de Fin SIMBOLOGIA DESCRIPCION No tiene establecida ninguna condición o requisito para finalizar el proceso o subproceso. Un proceso o aplicativo envía un mensaje específico para dar fin a un proceso. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 28  2. Actividades Las actividades se utilizan para representar los pasos individuales del proceso en los diagramas de BPMN. TIPO SIMBOLOGIA DESCRIPCION Actividad Una actividad representa un paso de trabajo y se formula en presente. Subproceso Si no se quiere mostrar la compleja secuencia de una actividad directamente en un diagrama, se puede evitar utilizando un subproceso. Un subproceso simboliza un diagrama de flujo que contiene una descripción de las actividades complejas en el siguiente nivel. 3. Tarea Están incluidas dentro de un proceso, estas no pueden desglosarse en un nivel de mayor detalle. Los siguientes son los tipos de tareas. TIPO SIMBOLOGIA DESCRIPCION Tarea Manual Es una tarea donde interviene un humano para su ejecución y presenta información para la ejecución de la tarea. Tarea Automática Es toda aquella tarea que realiza el sistema sin intervención humana, como lo puede ser enviar un email o invocar un web service. Subproceso Los detalles del subproceso no pueden ser visualizados. El signo mas (+) indica que la actividad es un subproceso y que tiene un nivel más bajo de detalle. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 29  4. Compuertas Por regla general, los procesos no siempre son lineales, sino que consisten en divisiones y fusiones. Estos se representan en el flujo de secuencia de un modelo por medio de compuertas de enlace o gateways. Se representa con un diamante, y se emplea para controlar la divergencia o convergencia de la secuencia de flujo. Éstas determinan ramificaciones, bifurcaciones, combinaciones y fusiones del proceso. Existen diferentes tipos de compuertas los cuales se muestran a continuación: TIPO DE SIMBOLOGIA DESCRIPCION COMPUERTA Compuertas exclusivas Las compuertas exclusivas se utilizan cuando puede darse exactamente una condición ("una cosa o la otra"). Al fusionarse de nuevo, sólo puede darse una ruta de proceso entrante. Compuertas paralelas Indica un punto del proceso donde pueden ser llevadas a cabo actividades en forma concurrente y sincroniza los caminos que parten de una compuerta paralela. Compuertas inclusivas Las compuertas inclusivas se utilizan cuando se pueden seguir una o más rutas de proceso ("y/o"; combinaciones de rutas). Al fusionarse, debe esperarse a cumplirse todas las rutas previamente activadas. Compuertas basadas en En las compuertas basadas en eventos, se sigue el eventos flujo de un proceso cuyo evento ocurre primero. Compuerta Compleja Se da en un punto del proceso donde aparecen varios caminos y solo uno de ellos es válido. Esta decisión está basada en la información registrada en Metadata. 5. Conectores ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 30  Todos los elementos de flujo utilizados en un proceso BPMN están conectados a través de los llamados flujos de secuencia. TIPO DE CONECTOR SIMBOLOGIA DESCRIPCION Flujos de secuencia Muestra el orden de los eventos, actividades y decisiones que se realizan dentro del proceso. Flujos de mensajes Los flujos de mensajes representan el intercambio de información con los participantes externos del proceso. Se desencadenan por actividades y pueden unirse a otras actividades, pools o eventos de noticias. Flujos de asociación Asociar diferentes artefactos con objetos de flujo. 6. Piscinas y Carriles Los pasos individuales de un proceso son llevados a cabo por los participantes en el mismo. En BPMN se utilizan piscinas y carriles para representar a los diferentes participantes del proceso. TIPO SIMBOLOGIA DESCRIPCION Piscinas Representa los actores externos con los cuales interactúa un proceso, estos actores pueden ser un proceso o aplicativo. Carriles Los carriles representan a los participantes en el proceso, pueden ser unidades organizativas o funciones, el cual contiene un conjunto de actividades asociadas a este rol. 7. Artefactos Para que el diseño de sus procesos de negocio en BPMN sea aún más claro, se ha incluido en el estándar BIC para modeladores otros artefactos. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 31  TIPO DE SIMBOLOGIA DESCRIPCION ARTEFACTO Objetos de Muchos procesos incluyen pasos de proceso que contienen el Datos uso o la creación de documentos o datos. Estos están representados por los objetos de datos. Anotaciones Son un mecanismo para que el modelador pueda dar información textual adicional. Grupos Se utiliza para agrupar un conjunto de actividades ya sea para efectos de documentación o análisis. Roles Un rol es una representación de puestos o una combinación de las mismas áreas de operaciones. Los participantes en los procesos, adicionalmente a los ya modelados en los carriles, pueden ser representados como roles. Aplicaciones Las aplicaciones representan sistemas informáticos que son relevantes para la ejecución de los pasos del proceso. Muestran explícitamente qué sistemas de TI se utilizan para apoyar el trabajo manual. Normas Las normas representan los requisitos para la ejecución del proceso. Pueden ser directrices específicas de la empresa o normas oficiales internacionales. Riesgos Los riesgos son peligros que pueden ocurrir en el curso de la ejecución del proceso. Se utilizan en el modelado de BPMN para apoyar la gestión de riesgos orientada a los procesos. Controles Los controles son actividades de reglamentación que tienen por objeto reducir al mínimo los riesgos. Se utilizan en el modelado de BPMN para apoyar los sistemas de control interno. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 32  Anexo 2. Plantilla de Plan de Trabajo para el Desarrollo de Aplicaciones PLANTILLA PLAN DE TRABAJO Introducción > Objetivos > Alcance > Lista de actividades y responsables > Recursos necesarios > ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 33  Premisas o supuestos > Cronograma Modelo propuesto: PLAN DE DESARROLLO DEL “>” No FECHA FECHA ACTIVIDAD DURACION DEPENDENCIA RESPONSABLE RECURSOS INICIO FINALIZACION Unidad: ________________________ Responsable: ________________________ Dirección: ________________________ Fecha: ________________________ Aprobado por: ________________________ ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 34  Anexo 3. Formato propuesto de Cronograma DESARROLLO DEL "SISTEMA" No. ACTIVIDAD DURACION FECHA FECHA ACTIVIDAD RESPONSABLE RECURSOS INICIO FINALIZACION PREDECESORA Unidad Responsable: Dirección: Fecha: Aprobado por: Anexo 4. Manual para el nombramiento de objetos de base de datos 1. Introducción A finales del 2020, se conforma el Comité de Desarrollo de Sistemas del Ministerio de Hacienda, con representantes de las diferentes Unidades de Informática de este Ministerio, con el propósito de coordinar el desarrollo la adopción de estándares para el desarrollo y mantenimiento de sistemas, por lo cual el nombramiento de los objetos definidos en las bases de datos y en el código fuente de los mismos. Este documento describe el primero de estos puntos, con el propósito general de facilitar el mantenimiento del código de los sistemas informáticos elaborados en el Ministerio de Hacienda de la República de El Salvador. 2. Glosario a) Base de Datos: el conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. b) Código fuente: el conjunto de líneas de texto escritas en algún lenguaje de programación que contiene las instrucciones dadas a la computadora para realizar la funcionalidad deseada de un programa. c) Entidad: la representación de un objeto o concepto del mundo real que se describe en una base de datos. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 35  d) Estándar: el conjunto de especificaciones técnicas u otros criterios precisos para ser usados consistentemente como reglas, guías, o definiciones de características para asegurar la interoperabilidad o compatibilidad de los productos, procesos y servicios e) Identificador: la descripción de un objeto mediante el uso de abreviaturas, separadas por un guión bajo, si la descripción consta de más de dos palabras significativas, o bien, cuando el lenguaje lo reconozca, iniciando con mayúscula cada palabra significativa. f) Metadatos: los datos estructurados que describen las características de contenido, calidad, condición, acceso y distribución de la información estadística o geográfica. g) Modelo de datos: conjunto de conceptos que nos permiten describir los datos, las relaciones que existen entre ellos, la semántica y las restricciones de consistencia. h) Sistema informático: el conjunto de componentes físicos (hardware), lógicos (software) y humanos que se organizan para realizar una tarea o un proceso específico. 3. Objetivo general Establecer el marco de referencia para el nombramiento de los objetos de las bases de datos, de los nuevos sistemas informáticos desarrollados en y para el Ministerio de Hacienda, de manera tal que se facilite el desarrollo y mantenimiento de los mismos. 4. Ámbito de aplicación Los estándares contenidos en el presente Manual son de observancia obligatoria para todo el personal que labora en el Ministerio de Hacienda o que es contratado con terceros para que realice actividades inherentes al desarrollo y documentación de sistemas informáticos para el Ministerio de Hacienda. 5. Nomenclatura de objetos de base de datos 5.1 Tablas 5.1.1 Generales a) Definir nombres claros, que describan el contenido de la entidad o tabla. La longitud máxima será de 30 caracteres, es permitido el carácter guion bajo, no debe contener espacios, ni caracteres especiales, no iniciar con números. b) La denominación debe ser un sustantivo en singular; sólo en aquellos casos en donde el singular no represente correctamente el contenido de la misma, se podrán utilizar nombres en plural. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 36  5.1.2 Tipos de tablas (Nomenclatura de tablas) a) Modelo relacional “TR_” = Entidades que representan los registros con datos detallados “TC_” = Entidades que representan catálogos que describen los valores de una variable de una entidad tipo TR_ “TI_” = Entidades que representan la relación muchos a muchos entre dos tablas. En este caso el nombre de la tabla debe incluir los nombres de las tablas que relaciona separadas por guion bajo (“_”). b) Modelo estrella “TH_” = Entidades que representan los hechos. “TD_” = Entidades que representan dimensiones que describen y jerarquizan los valores de una variable de una entidad tipo TH_. c) Metadatos “TM_” = Entidades que representan metadatos. d) Temporales “TT_” = Entidades utilizadas temporalmente por uno o varios procesos. 5.2 Atributos a) El nombre del atributo debe ser claro y representativo al dato que contiene, con un tamaño máximo de 25 caracteres. b) No debe contener caracteres especiales excepto el guión bajo (_), no se permite iniciar con números los nombres. c) El orden de los atributos al interior de la entidad, deben ser de acuerdo al orden de captación de la información correspondiente. d) Los atributos que correspondan a la llave primaria se sugiere sean nombrados bajo el nombre ID. e) En tablas de catálogos debe utilizar el nombre “DESCRIPCION” para aquellos atributos que representan su descripción. 5.3 Procedimientos a) El nombre del procedimiento iniciará con el prefijo “PR_” y será de la siguiente manera: PR_NO MBRE Donde: ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 37  “PR_”: indica que es un procedimiento almacenado NOMBRE: es el nombre del procedimiento 5.4 Funciones a) El nombre de la función iniciará con el prefijo “FN_” y será de la siguiente manera: FN_NO MBRE Donde: “FN_”: indica que es una función. NOMBRE: es el nombre de la función. 5.5 Paquetes a. El nombre del paquete iniciará con el prefijo “PQ_” y será de la siguiente manera: PQ_NOMBRE Donde: “PQ_”: indica que es un paquete. NOMBRE: es el nombre del paquete. b. Los nombres de procedimientos, funciones o paquetes deben ser claros y descriptivos a las tareas que realizarán. Dentro del script de creación del procedimiento o función se debe agregar como comentario lo siguiente: b.1 Descripción: Texto que detalla la acción o finalidad del procedimiento o función, incluir en la descripción fecha de creación y autor b.2 Parámetros: Valores que recibe el procedimiento o función. Para cada parámetro debe considerarse: b.2.1 Nombre. b.2.2 Tipo de dato. b.2.3 Longitud (considerando el número de decimales). b.2.4 Si es de entrada y/o salida. b.3 Resultado: En el caso de las funciones, el dato que se genera al ejecutarla. 5.6 Vistas a) El nombre de la vista seguirá los estándares de nomenclatura de una tabla (numeral 5.2), con la variante de que en lugar de comenzar con “T” se comenzará con “V”. Ejemplo, en lugar de usar “TR_” se usará “VR_”. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 38  5.7 Índices a) En índices de campos que no son llave primaria o foránea, el nombre de un índice debe constituirse por el prefijo “I_”, seguido por las primeras letras de los nombres de cada una de las columnas que involucra, omitiendo cualquier prefijo, la longitud máxima del nombre debe ser de 30 caracteres y debe estar construido de la siguiente manera: I_XXX_YYY Donde: I = Índice XXX = campo 1 YYY = campo n 5.8 Llave primaria y llave foránea a. La llave primaria seguirá el patrón: PK_ XXX Donde: “PK_”: indica que es una llave primaria. XXX: indica el nombre de la tabla para la cual se crea la clave primaria. b. La llave foránea seguirá el patrón: FK_XX X_YYY Donde: FK: indica que es una llave foránea. XXX: indica el nombre de la tabla de origen. YYY: indica el nombre de la tabla referenciada. 5.9 Secuencias a. Para aquellas entidades donde no exista un atributo de llave primaria, se deberá agregar un atributo de secuencia que servirá como identificador único, nombrándolo “SEQ_”, seguido del nombre de la entidad, el nombre no debe exceder los 35 caracteres y debe construirse de la manera siguiente: SEQ_NO MBRE Donde: “SEQ_”: indica que es una secuencia. NOMBRE: es el nombre de la secuencia. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 39  5.10 Sinónimos a. El nombre de un sinónimo debe constituirse con el mismo nombre del objeto (tabla, procedimiento, vista, etc.) al cual hace referencia dicho sinónimo. 5.11 Database Link (DBLink) a. Se debe considerar el alias definido por el DBA, el nombre no debe exceder los 30 caracteres, no debe contener caracteres especiales, espacios en blanco y números. La estructura para construir el nombre debe ser la siguiente. ESQUEMA_BASEDATOS Donde: ESQUEMA: Es el nombre del esquema al que accede el DBLink (eliminando guiones intermedios que se encuentren en el nombre). BASEDATOS: Nombre de la base de datos donde se encuentra el esquema. 5.12 Triggers a. El nombre del trigger o disparador debe conformarse por un máximo de 30 caracteres, no debe contener caracteres especiales, espacios en blanco y números. El nombre debe iniciar con el prefijo “TRG_” de la manera siguiente: TRG_NOMBRE Donde: “TRG_”: indica que es un trigger. NOMBRE: es el nombre del trigger. Dentro del script de definición del trigger se debe hacer mención del tipo de tareas o acciones que ejecuta y listar claramente los objetos que lo disparan y los objetos a los que afecta. Anexo 5. Manual de Integración de Sistemas ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 40  DIRECCIÓN [NOMBRE DE DIRECCIÓN] [Unidad Organizativa] Documento de Integración entre [nombres de sistemas involucrados] Mes - Año Antecedentes En este apartado se describe brevemente la integración entre sistemas, describiendo los procesos involucrados en el mismo. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 41  A continuación, se muestra una tabla con los principales cambios al proceso: Diagrama de la nueva integración (ej.) Funcionamiento del nuevo proceso En este apartado se describen los pasos del nuevo proceso si es posible también incluir de manera gráfica como se integran o comunican lo sistemas o componentes. Ej: ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 42  Nuevo esquema a. Estructura de nuevas tablas Mostrar de manera gráfica las tablas o APIS involucradas en la integración. b. Descripción de las tablas Tabla: [nombre tabla] Se describen los nombres de los campos, tipo, longitud, si es mandatorio, valor por defecto y descripción. Nombre Tipo de Dato Longitud Mandatorio Valor por Defecto Descripción Parámetros enviados por sistema [nombre de sistema] Se describen de manera detallada los parámetros enviados hacia otro sistema o componente. Respuestas recibidas de acuerdo a los parámetros enviados. Se describen las respuestas, mensajes o códigos recibidos de acuerdo a los parámetros enviados. Recomendación En este apartado se dan indicaciones o recomendaciones sobre cómo deben efectuarse algunas acciones de la integración para poder obtener los resultados esperados. Anexos Se agregarán todos aquellos formatos o documentos que sean necesarios para llevar a cabo la integración. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 43  Modificaciones REGISTRO DE MODIFICACIONES N° MODIFICACIONES 1 Se adicionan las secciones Apoyo con la herramienta Tuleap y Planificación de Releases. ©Edición 2 -2024 Estándares de Desarrollo y Mantenimiento de Sistemas Informáticos-Etapa de Análisis y Diseño 44