1 · web view: la arquitectura de software es un conjunto de patrones que proporcionan un marco de...

PROTOCOLO DE LINEAMIENTOS TÉCNICOS PARA EL MANEJO DE CICLO DE VIDA DE

PROYECTOS DE SOFTWARE

Código: TC.GT.T1

Versión: 01

Vigente desde:09/12/2016

1. OBJETIVO

Establecer los lineamientos técnicos mediante el cual se contempla el ciclo de vida de las aplicaciones, sistemas de información o procedimientos automatizados y el ciclo de vida de la información, basados en el Marco de Referencia de Gobierno en Línea, para garantizar la optimización del servicio en el Ministerio del Interior

2. ALCANCE

Inicia con las fases del ciclo de vida de los proyectos o los productos de software independientemente de la tecnología en la que sean desarrollados y finaliza con los mecanismos que se requieren para lograr el cumplimiento de los lineamientos de la Estrategia de Gobierno en Línea a través de la Arquitectura Empresarial y con ello ser parte de “El camino hacia un gobierno integrado”.

3. TERMINOS Y DEFINICIONES

ANS: (Service Level Agreement o SLA), acuerdo de nivel de servicio, es un contrato escrito entre un proveedor de servicio y su cliente con objeto de fijar el nivel acordado para la calidad de dicho servicio.

Arquitectura e Software: La arquitectura de software es un conjunto de patrones que proporcionan un marco de referencia necesario para guiar la construcción de un software, permitiendo a los programadores, analistas y todo el conjunto de desarrolladores del software compartir una misma línea de trabajo y cubrir todos los objetivos.

Auraportal: Es un sistema para la descripción, ejecución, análisis y mejora de los procesos de una organización.

Automatizar: Mejorar y simplificar los procesos, integrar procesos internos, ahorrar tiempo y dinero a través de los sistemas de información.

BPM: (Business Process Management) es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales. BPM es un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con metodologías de proceso y gobierno.

BPMS: (Business Process Management Suite) Es la suite de tecnologías BPM, lo que incluye todos los módulos funcionales, las capacidades técnicas y la infraestructura de apoyo, integradas en un único entorno que realiza todas las funciones de la tecnología BPM de manera perfecta, sin fisuras.

Caso De Uso: Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema.

Desarrollo: Por extensión, se utiliza la palabra «desarrollo» para indicar el trabajo de elaboración de un programa o aplicación.

Diagrama De Flujo: Representación gráfica, mediante la utilización de signos convencionales, del proceso que sigue la información en un programa determinado.



Código: TC.GT.T1Versión: 01

Vigente desde:

Diseño: Proceso de esquematización de un proyecto de software. Es la primera fase en el desarrollo de aplicaciones.

Diseño Gráfico: Proceso de programar, proyectar, coordinar, seleccionar y organizar una serie de elementos para producir objetos visuales destinados a comunicar mensajes específicos a grupos determinados.

Gestión De La Integración: Incluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los diversos procesos y actividades de dirección del proyecto.

NET: Conjunto de herramientas que se usa para diseñar plataformas de acuerdo a la necesidad del cliente, con el nombre de dominio .net es un dominio utilizado en el Sistema de Nombres de Dominio de Internet.

Proceso: Operación o conjunto combinado de operaciones con datos, o bien una secuencia de acontecimientos definida única y delimitada, que obedece a una intención operacional en condiciones predeterminadas.

Prueba Funcional: Etapa final de la automatización en la cual se comprueba el funcionamiento del proceso de acuerdo a las configuraciones realizadas.

Prueba Técnica: Son las actividades que permiten verificar y revelar la calidad de un proceso automatizado. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad del proceso.

Puesta En Marcha / Producción Del Proceso Automatizado: Cambio de modo en el sistema en el cual los usuarios pueden iniciar la ejecución del proceso automatizado.

Repositorio: Un repositorio, depósito o archivo es un sitio web centralizado donde se almacena y mantiene información digital, habitualmente bases de datos o archivos informáticos. Pueden contener los archivos en su servidor o referenciar desde su web al alojamiento originario.

Requerimientos Funcionales: Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.

Requerimientos No Funcionales: Un requisito no funcional o atributo de calidad es un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales.

TIC: (Tecnología de la Información y las comunicaciones) Las Tecnologías de la Información y la Comunicación, también conocidas como TIC, son el conjunto de tecnologías desarrolladas para gestionar información y enviarla de un lugar a otro. Abarcan un abanico de soluciones muy amplio. Incluyen las tecnologías para almacenar información y recuperarla después, enviar y recibir información de un sitio a otro, o procesar información para poder calcular resultados y elaborar informes

Viabilidad: Probabilidad que existe de llevar aquello que se pretende o planea a cabo, de concretarlo efectivamente.

Página 2 de 26

https://es.wikipedia.org/wiki/Dominio_de_nivel_superior_gen%C3%A9rico




Vigente desde:

4. RESPONSABILIDAD

El responsable del procedimiento, de la realización, actualización y socialización del mismo, corresponde al Jefe de la Oficina de Información Pública y al Coordinador del Grupo de Sistema.

Roles que Intervienen:

Líder de Gestión: Dirigir y gestionar el trabajo del proyecto (de acuerdo a WBS y sus criterios de calidad y aceptación), elabora el cronograma de actividades, los informes de seguimiento, revisa los casos de uso, los documentos de pruebas, manuales, actas de aceptación de entregable recibida a satisfacción, lecciones aprendidas comunicadas y documento informe final aprobado.

Líder Técnico: Genera concepto de viabilidad, concepto de control de cambios, revisa y acompaña los documentos de requerimientos, diseño, arquitectura, desarrollo y pruebas. Elabora la Ficha Técnica del Sistema, acompaña la puesta en producción y atiende el segundo Nivel de Soporte.

Analista De Procesos: Se encarga de elaborar el formato de viabilidad, el formato de entendimiento del proceso, los casos de uso, entrega final y actualización del proceso SIGI automatizado.

Diseñador: Es el encargado de elaborar la guía de estilos que requiere la solución tecnológica, configura botones, formatos y logos de acuerdo a las necesidades de cada proyecto.

Arquitecto Ti: Define la estructura y el comportamiento de los componentes de los Sistemas de Información, así como sus interacciones. Define y documenta la arquitectura de la solución, a partir de las especificaciones establecidas, elabora Documentos de Arquitectura y diseño de Software.

Desarrollador: Construye los componentes de software siguiendo las directrices establecidas en la arquitectura de la solución y cumpliendo con el diseño definido, asegura que se ejecuten las pruebas unitarias y de integración de los componentes desarrollados y elabora el formato de prueba técnica.

Analista De Calidad (QA): Es el que elabora los documentos de pruebas, manuales, actas de aceptación de entregable recibida a satisfacción, lecciones aprendidas comunicadas, documento informe final aprobado

5. DESARROLLO

Para la ejecución del proyecto se plantean unas fases claramente definidas en donde cada una deberá tener como entregable intermedio el resumen de la ejecución de la fase, debe entenderse que la aprobación de dichos entregables son requisito para el inicio de la siguiente, esto no quiere decir que la totalidad del alcance del proyecto se deba ejecutar al mismo tiempo por cada fase, dependiendo de la complejidad del proyecto, es factible que las fases se ejecuten por módulo o paquete de acuerdo al modelo de desarrollo iterativo e incremental. La definición de este tipo de decisiones deberá estar enmarcada en los planes de gerencia del proyecto.

Página 3 de 26




Vigente desde:

Figura 1. Modelo de desarrollo iterativo e incremental.

El modelo de ciclo de vida se plantea para todos los tipos de proyecto o producto de software independiente de la tecnología en la que finalmente sea construida la solución.

a. Levantamiento y análisis de información

i. Requerimientos funcionales

Son todas las declaraciones de las características que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer.

En términos generales el sistema de información deberá satisfacer las siguientes necesidades:

● Solución informática integrada con sistemas misionales del Ministerio del Interior a través de la propuesta de integración BPM + SOA del ministerio del Interior.

● Solución informática integrada con otros sistemas de información institucionales.● Solución informática que permita apoyar la actividad institucional en cualquier lugar del país.● Solución informática de apoyo a la gestión interna.● Solución informática con implementación de la totalidad de procesos de la función preventiva de

la Dirección/Subdirección/Oficina/Grupo.● Solución informática con herramientas de análisis de datos.● Solución informática con integración a herramientas de análisis georreferenciado.● Solución informática integrada con la gestión de correspondencia y gestión documental.● Solución informática administrada a través de un portal de información.● Solución informática a disposición de los ciudadanos toda la información definida como de

carácter público.● Dentro de los procesos automatizados, se hace necesario el levantamiento de información con la

coordinación del grupo de sistemas de la OIPI así como de las dependencias de control interno y

Página 4 de 26




Vigente desde:

de gestión del cambio a las que haya lugar, en el sentido de determinar los informes y reportes que respondan a las preguntas de nivel de utilización de los procesos automatizados.

Durante la fase de inicio en gestión de proyecto, el proceso de levantamiento de información debe ser realizado no solo con la información digital o física entregada por los stakeholders sino que debe estar acompañado por sesiones de entrevistas a las personas pertinentes en la operación futura del sistema.

Para las sesiones de levantamiento, adicional a las respectivas actas de reunión que se levanten se plantea el formato “Formato entendimiento de proceso y definición de casos de uso.docx”, para su correcto diligenciamiento se deben tener en cuenta los siguientes aspectos.

1. Diagrama de flujo de proceso

De no existir o encontrarse desactualizado, se debe elaborar por parte del analista de información el diagrama donde se plasme el entendimiento del proceso objeto de automatización o sistematización, en él deben quedar claros los roles que interactúan, los documentos que se generan y tienen como insumo, las decisiones que se toman, las interrelaciones con otros procesos y las relaciones con sistemas de información presentes.

2. Reglas de negocio

Deben describir las políticas, normas, operaciones, definiciones y restricciones presentes en la entidad o dependencia y que son de vital importancia para alcanzar los objetivos misionales, en ningún caso se deben confundir las reglas de proceso (restricciones) y las reglas de negocio ya que las segundas expresan una generalidad que en ningún caso deben depender del resultado de la automatización o sistematización, las primeras están ligadas explícitamente al sistema que se está modelando.

3. Escenarios o flujos

Describen un ejemplo del uso del sistema en términos de una serie de interacciones entre el usuario y el sistema, en lo posible deben determinarse los escenarios de flujo normal, alternos y de excepción.

4. Casos de uso

Los casos de uso deben estar determinados mediante la obtención de un logro de negocio por parte del usuario que está realizando la interacción y debe comprender los posibles escenarios presentes en su ejecución. Como normal general, deberán estar codificados y expresados en forma infinitiva.Se deberá tener en cuenta la atomicidad del caso de uso, el cual como recomendación deberá hacer referencia a una única función del sistema y se deberá centrar exclusivamente en la interacción relacionada al objeto del negocio.

Para todos los casos no deben presentarse sobre el documento palabras técnicas de desarrollo de software dado que la población objetivo del documento es el de usuarios funcionales del ministerio del interior.

Al finalizar se debe presentar el diagrama de integración entre casos de uso de modo que denote las dependencias de implementación de los mismos, esta información es vital para la elaboración de los planes de pruebas y operación del sistema entregado.

Página 5 de 26




Vigente desde:

5. Pantalla prototipo

Se deberá plasmar en pantalla el orden, agrupamiento y tipos de controles (cajas de texto, botones, etc) de la información levantada y relacionada al caso de uso. En ella se debe evidenciar claramente la información que sirve de entrada y de salida, la que es obligatoria de la que es opcional, la que es modificable y la que no lo es. Se puede acompañar de notas para cuando se requiera especificar comportamientos no obvios en los diferentes campos de datos.

6. Actores

Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo. Se sugiere que los actores definidos en los casos de uso estén alineados a los roles de los mismos dentro del proceso que se levanta, de este modo se adelanta la matriz de roles y accesos de cara a los procesos de pruebas y salida a producción.

ii. Requerimientos no funcionales

Todas las soluciones informáticas que se implementen en el Ministerio del Interior deben cumplir con los siguientes requerimientos definidos por el grupo de sistemas dependiente de la Oficina de Información Pública.

Los requerimientos no funcionales se refieren a las características del sistema que aplican de manera general como un todo, más que a rasgos particulares del mismo. Estos requerimientos son adicionales a los requerimientos funcionales que debe cumplir el sistema, y corresponden a aspectos tales como la disponibilidad, mantenibilidad, flexibilidad, seguridad, facilidad de uso, etc., los cuales se describen a continuación.

La solución debe cumplir como mínimo las siguientes características basadas en las especificaciones funcionales y los requerimientos no funcionales:

1. Desempeño

● Garantizar la confiabilidad, la seguridad y el desempeño del sistema informático a los diferentes usuarios a nivel nacional. En este sentido la información almacenada podrá ser consultada y actualizada permanente y simultáneamente, sin que se afecte el tiempo de respuesta.

● El sistema debe estar en capacidad de dar respuesta al acceso de todos los usuarios con tiempo de respuesta aceptable y uniforme, en la medida de las posibilidades tecnológicas del Ministerio del Interior, en períodos de alta, media y baja demanda de uso del sistema.

2. Disponibilidad

● Estar disponible 99% o superior, durante el horario 7x24x365, es especial en horario laboral del Ministerio del Interior a nivel nacional (de lunes a viernes de 8:00 a.m. a 5:00 p.m., con excepción de los días festivos)

● Operar de la misma manera para todos los niveles de la estructura jerárquica del Ministerio del Interior.

● Para todas las aplicaciones del Ministerio del Interior, se debe tener en cuenta que tanto las aplicaciones como la data van sobre una infraestructura en nube, por lo que todo sistema de información debe cumplir con los estándares necesarios para trabajar sobre nube pública (Microsoft Azure) como

Página 6 de 26




Vigente desde:

plataforma como servicio (Pass). Y solo en casos especiales, bajo estudio del Grupo de Sistemas, se permitirá el uso de Infraestructura como servicio (Laas). (No aplica para desarrollos sobre la plataforma BPM que utilicen la plataforma ya existente).

3. Escalabilidad

● El sistema debe ser construido sobre la base de un desarrollo evolutivo e incremental, de manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados afectando el código existente de la menor manera posible; para ello deben incorporarse aspectos de reutilización de componentes.

● El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades después de su construcción y puesta en marcha inicial.

● La estrategia de crecimiento de plataforma de hardware de las aplicaciones debe ser, en lo posible, horizontal apalancadas en soluciones de Grid Computing.

● El sistema debe ser compatible con el servicio de auto escalamiento de Microsoft Azure (horizontalmente (Scale Out): Agregar más instancias de un mismo rol).

4. Facilidad de Uso e Ingreso de Información

● El sistema debe mantener un estándar de trabajo definido, de modo que sea de fácil uso y entrenamiento por parte de los usuarios del Ministerio del Interior, así como de fácil adaptación de la entidad con el mismo. ● El sistema no debe permitir el cierre de una operación hasta que todos sus procesos, subprocesos y tareas relacionados, hayan sido terminados y cerrados satisfactoriamente.

● El ingreso de información al sistema debe diseñarse con transacciones que permitan el ingreso de los datos de forma parcial; es decir, que el tamaño de las páginas de registro (o formularios) de información sean adecuadas de acuerdo con la estabilidad de la red o canales de comunicación utilizados.

● El sistema debe presentar mensajes de error que permitan al usuario identificar el tipo de error y comunicarse con el administrador del sistema.

● El sistema construido en plataformas web debe cumplir con tecnología de Diseño Web Adaptable o en inglés Responsive Design para que pueda ser usado desde diferentes tamaños en pantalla y dispositivos

● Los sistemas de información deben utilizar interfaz web, de forma que se universalice el acceso a los mismos, en su defecto la aplicación debe ser compatible con los estándares de Porlets vigentes. Los navegadores compatibles deben por lo menos IE 9 o superior, Firefox , Google Crome

5. Facilidad para las Pruebas

● El sistema debe contar con facilidades para la identificación de la localización de los errores durante la etapa de pruebas y de operación posterior, para ello los logs de trazabilidad deben indicar la fecha, el componente de software, la excepción interceptada, el método en ejecución y la línea de código que produjo el error. En la medida de lo posible se debe indicar el usuario que se encontraba ejecutando la acción.

Página 7 de 26




Vigente desde:

6. Flexibilidad

● El sistema debe ser diseñado y construido con los mayores niveles de flexibilidad en cuanto a la parametrización de la información, de tal manera que la administración del sistema pueda ser realizada por un administrador funcional del sistema, en ningún caso el dentro del código fuente deben quedar valores fijos que dado el negocio requieran ser cambiados posteriormente. Igualmente, si el sistema incluye la generación de documentos, estos deben partir de plantillas que puedan llegar a ser modificadas sin tener que realizar una nueva compilación del sistema.

7. Instalación

● El sistema debe contar con la documentación suficiente para la realización de los procesos de instalación en todas las plataformas de hardware y software de base definida por el grupo de sistemas dependiente de la Oficina de Información Pública

● Desde el punto de vista de servidor de aplicaciones el estándar definido para los sistemas es Windows Server 2012 R2 o superior y IIS 7.5 o superior como servidor de aplicaciones y el motor de base de datos, reportes BI debe ser MSSQL 2012 o superior

● Se debe aplicar el criterio del menor privilegio, el cual consiste en la instalación solamente de los recursos que requieren para la ejecución de los programas.

8. Mantenibilidad

● Todo el sistema deberá estar complemente documentado, cada uno de los componentes de software que forman parte de la solución propuesta deberán estar debidamente documentados tanto en el código fuente como en los manuales de administración y de usuario

● Todo proceso de modificación de la plataforma por motivos de liberación de nuevas funcionalidades debe contar con sus respectivas actividades de instalación, configuración y reversión total de las acciones para los casos de imposibilidad de instalación de alguno de los componentes.

● El sistema debe contar con una interfaz de administración que incluya: Administración de usuarios, Administración de módulos y Administración de parámetros. En cada una de éstas secciones deberá ofrecer todas las opciones de administración disponibles para cada uno

● El sistema debe estar en capacidad de permitir en el futuro su fácil mantenimiento con respecto a los posibles errores que se puedan presentar durante la operación del sistema.

● El sistema deberá funcionar de manera adecuada frente a una falla de seguridad.

● El sistema debe estar construido de forma que permita la consulta de eventos de modificación de la información paramétrica, tanto si se realiza desde la aplicación como directamente sobre las fuentes de datos.

● Se debe tener en cuenta los costos asociados a plataforma como servicio (Nube) y deben estar disponibles para garantizar la operación continua del sistema de información. Por lo que es parte integral los costos mensuales y anuales y se deberán aprovisionar según se requiera con la suficiente antelación para mantener el sistema funcional.

Página 8 de 26




Vigente desde:

● El sistema debe contemplar un plan de soporte durante el tiempo estimado de vida del Sistema de Información

9. Operatividad

● El sistema debe ser de fácil operación por el grupo de sistemas dependiente de la Oficina de Información Pública del Ministerio del Interior, y que demande un bajo nivel de soporte de los usuarios del sistema.

● El sistema deberá poder ser administrado remotamente por las personas encargadas o designadas por el grupo de sistemas dependiente de la Oficina de Información Pública del Ministerio del Interior.

10. Seguridad

● La seguridad del sistema debe estar regida por las Políticas de Seguridad de la Información definidas por el Ministerio del Interior y alineadas con la Estrategia de Gobierno en Línea.

● El acceso al Sistema debe estar restringido a los usuarios de directorio activo que se habiliten para acceder al sistema. Sólo podrán ingresar al Sistema las personas que estén habilitadas, estos usuarios serán clasificados en varios tipos de usuarios (o roles) con acceso a las opciones de trabajo definidas para cada rol.

● Para los usuarios externos o invitados el sistema deberá integrarse con la autenticación única del ministerio del interior.

● El control de acceso implementado debe permitir asignar los perfiles para cada uno de los roles identificados, los cuales serán definidos por los dueños del proceso.

● Respecto a la confidencialidad, el sistema debe estar en capacidad de rechazar accesos o modificaciones indebidos (no autorizados) a la información y proveer los servicios requeridos por los usuarios del sistema.

● El sistema deberá contar con mecanismos que permitan el registro de actividades (Logs de auditoria) con identificación de los usuarios que los realizaron, incluyendo los procesos y actividades realizadas en las bases de datos por parte del usuario.

● El sistema debe contar con pistas de auditoría de las actividades que se realizan sobre el sistema con niveles razonables para su reconstrucción e identificación de los hechos.

● El grupo de sistemas realizará pruebas previas a la entrada de producción y entregará un informe con los riesgos encontrados para su correspondiente mitigación por parte del desarrollador. Una vez sean cerradas las brechas en seguridad, se realizará una segunda prueba, si el sistema no presenta riesgos o si estos no son de importancia alta el oficial de seguridad dará el visto bueno para la el despliegue en producción del sistema. El Ministerio se reservará la recepción en producción del sistema de información hasta no mitigar todos los riesgos 1

11.Validación de Información

1 Tenga en cuenta TOP 10 de los riesgos de seguridad de Aplicaciones

Página 9 de 26




Vigente desde:

El sistema debe validar automáticamente la información contenida en los formularios de ingreso. En el proceso de validación de la información, se deben tener en cuenta aspectos tales como obligatoriedad de campos, longitud de caracteres permitida por campo, manejo de tipos de datos, velocidad de respuesta, tráfico de datos, etc.

iii. Otros Requerimientos No Funcionales

1. Arquitectura

● La Arquitectura siempre será avalada por parte del grupo de sistemas de la oficina de información pública del ministerio del interior.

● La solución debe ser 100% “Basada en Web y Nube (Microsoft Azure)”” y toda la parametrización y administración debe realizarse desde al menos los navegadores definidos.

● La solución debe operar de manera independiente del navegador que se utilice.

● La solución debe tener interfaces gráficas de administración y de operación en idioma español y en ambiente 100% Web, para permitir su utilización a través de exploradores o navegadores de Internet.

● La información de los formularios que corresponda a listas de selección deberá ser parametrizada y administrable.

2. Integración

● La solución deberá integrarse a la página Web que defina el Ministerio del Interior. mediante estándares propuestos por Gobierno en Línea.

● Si la solución requiere la generación de un código de radicación, se debe disponer el servicio GDC_Consecutivo Radicación, de acuerdo a lo indicado al Grupo de Sistemas de la Oficina de Información Pública.

3. Interoperabilidad

● El sistema debe estar en capacidad de interactuar con los otros sistemas del Ministerio del Interior y con sistemas de entidades externas a través de la estrategia de SOA seleccionada por el Ministerio del Interior como la solución de integración de aplicaciones empresariales. La Interoperabilidad debe estar alineada por las definiciones del apartado de interoperabilidad de GEL

● De ser necesario interactuar con entidades externas al Ministerio del Interior, por requerimientos del sistema, estas interacciones debe realizarse con la solución de integración de aplicaciones empresariales y debe estar alineado lo definido en el “Marco para Interoperabilidad de Gobierno en Línea” lo cual supone que para cualquier implementación de este tipo, se deben consultar y/o solicitar actualización del “Diccionario del estándar de lenguaje común” según el caso.

4. Otros Requerimientos

● Facilidades y controles para permitir el acceso a la información al personal autorizado de otras

Página 10 de 26




Vigente desde:

entidades del estado a través de Internet, con el propósito de consultar la información pertinente para cada una de ellas.

● Facilidades para poder adelantar discusiones electrónicas a través de foros o salas de conversación sobre casos en particular que se adelanten en el Ministerio del Interior y registrar la participación de los asistentes.

● Contar con herramientas de software para la administración automática de archivos

● Contar con herramientas y características necesarias para su administración, la realización de búsquedas y la posibilidad de realizar consultas de índole general.

● El diseño gráfico de los sistemas debe responder al diseño oficial del Ministerio del Interior

● El sistema debe propender por el desarrollo de la cultura que minimice el uso del papel. Para ello, hasta donde sea posible, deberá hacer uso de las diferentes características de la tecnología, tales como documentos electrónicos, imágenes digitales, buscando minimizar la sobrecarga de las redes de transporte de datos y en concordancia con la estrategia de gobierno del Línea con la Política de Cero Papel.

● Garantizar que el diseño de las consultas no afecte el desempeño de la base de datos, ni considerablemente el tráfico de la red.

Las consideraciones anteriormente descritas aplican tanto para las aplicaciones transaccionales desarrolladas a la medida como para las que están enmarcadas como automatización de procesos BPM en la herramienta designada por el ministerio.

5. Arquitectura, Diseño y Desarrollo

Para las soluciones de software que no se planteen como automatización BPM, se deberá elaborar la propuesta arquitectónica con la que se estructuraran y determinaran el comportamiento de los componentes que harán parte de la plataforma teniendo en cuenta la compatibilidad con plataforma como servicio en nube de Microsoft azure. Para las soluciones que se enmarquen en la plataforma BPM del Ministerio del Interior no se requiere propuesta arquitectónica toda vez que aplica la presente en la propia herramienta. Debe tenerse en cuenta los documentos en la versión vigente del Marco de Referencia de Arquitectura Empresarial2

iv. Base de datos

El sistema de información debe estar basado en el motor de base de datos MSSQL cumpliendo con el modelo relacional. El Ministerio cuenta con Microsoft SQL Enterprise Edition 2012 R2 en arquitectura de alta disponibilidad.

El sistema de información debe proveer el licenciamiento necesario para el motor de base de datos en caso que las capacidades actuales del Ministerio no provean los requerimientos solicitados por el Sistema de Información, siempre basado en el modelo de licenciamiento por núcleo, integrándose con el motor actual del Ministerio y con cumplimiento de las políticas de respaldo y con capacidad de coexistir con las bases de datos e instancias presentes en el Ministerio del Interior sin modificar el motor de base de datos.

Para los servicios de reportes e inteligencia de negocios se debe utilizar MSSQL 2012 R2 y cumplir con

2 http://www.mintic.gov.co/arquitecturati/630/w3-propertyvalue-8114.html

Página 11 de 26




Vigente desde:

las mismas especificaciones que el motor de datos.

El método de autenticación a la base de datos debe ser integrada de Windows, preferiblemente mediante un usuario de dominio con políticas de seguridad de no vencimiento de clave para evitar bajas en el servicio, se debe propender que las actividades de interacción entre los componentes y la base de datos solamente sean de escritura y lectura.

Para los servicios de bases de datos como plataforma (Paas) se utilizará la última versión del motor de base de datos MSSQL disponible por parte de proveedor (Microsoft Azure)

v. Georreferenciación

El Ministerio del Interior cuenta con licenciamiento para los productos ARCGIS, los cuales constituyen una familia de productos de software para construir un Sistema de Información Geográfica (SIG) completo.

El sistema ARCGIS es un sistema de información geográfica integrado que provee la arquitectura para implementar SIG para uno o muchos usuarios, emplea modelos de datos inteligentes para la representación geográfica, incluye las herramientas necesarias para crear y trabajar con datos geográficos e incluye herramientas para todas las tareas de un SIG, tales como la edición y automatización de datos, mapeo, manejo de datos, análisis geográfico, despliegue de datos y aplicaciones sobre Internet.

Por tanto los sistemas que requieran un componente geográfico en su implementación deberán acogerse a la arquitectura de Sistema de Información Geográfica establecida en el Ministerio y la forma de integración entre la solución transaccional y el componente de georreferenciación deberá ser evaluado en conjunto entre el grupo de sistemas de la OIPI y el diseñador de software.

vi. Integración

A continuación se describen las características a tener en cuenta para realizar integraciones entre sistemas de información de la entidad o hacia otras entidades. En donde la integración a nivel de procesos de negocio se debe realizar mediante la herramienta BPMs y aquellas integraciones de exposición de datos como servicio, se realizaran a través de la tubería de servicios de la entidad.

El listado de integraciones contiene tanto las de consulta interna/externa como las de exposición de información interna/externa y se encuentra documentado bajo el nombre de “Inventario Integraciones.xlsx” y deberá quedar actualizado posterior a la ejecución del proyecto.

● Tubería de serviciosLa tubería de servicios es un componente de software desarrollado bajo tecnología .Net, que permite la exposición y consumo de servicios de datos con tecnologías XML, WSDL, SOAP, Rest y ODATA, A continuación se describen las consideraciones técnicas más relevantes:o Microsoft .Net 4.5o WCF (Windows Comunication Foundation)o Entity Framiework 5.0o ODATA Versión 3

● Arquitectura de Alto Nivel.A continuación se describe el marco arquitectónico de alto nivel asociado a la solución de la tubería de servicios.

Página 12 de 26




Vigente desde:

Figura 2. Marco Arquitectónico de Alto Nivel, tubería de servicios.

o Capa de Servicios Distribuidos Externos: En esta capa se alojaran los servicios Web tanto en formatos asmx como svc, que se expondrán hacia fuera de la entidad, dichos servicios están asegurados contra los servicios de directorio activo.

o Las entidades externas que desean acceder a estos servicios se les deberán crear un usuario en el directorio activo, y asociar al grupo correspondiente al servicio.

o Capa de Servicios Distribuidos Internos: En esta capa se alojaran los servicios Web tanto en formatos asmx como svc, que se expondrán hacia dentro de la entidad, estos no se encuentran asegurados a menos que la información que viaje sea de carácter confidencial, y si es el caso manejara el mismo esquema que la capa asociada a los externos.

o Capa de Aplicación: En esta capa se alojaran tanto los contratos como las implementaciones asociadas a los servicios expuestos en las capas superiores (Servicios Distribuidos Externos e Internos), además servirá como la capa de orquestación entre otros servicios de esta capa, la capa de datos y el modulo común.

o Capa de Datos: En esta capa contendrá los repositorios y fachadas de datos que tienen como fin de ser el enlace con las bases de datos relacionales, no relacionales y/o servicios externos.

o Modulo Común: En esta capa se encuentran todos los componentes de software transversales al software, como son: adaptadores, Entidades, archivos de recursos, objetos valor y utilitarios asociados.

o Código Fuente.El código fuente se encuentra en el archivo digital de los sistemas de información de la oficina de información pública, en la carpeta “27. TUBERIA DE SERVICIOS”.

vii. CMS

Página 13 de 26




Vigente desde:

Si se requiere un micro sitio, el proveedor de la solución debe implementar sobre el gestor de contenidos que le indique el Grupo de Sistemas, desde este CMS podemos administrar todos los contenidos, subdominios, artículos y noticias a los que tiene acceso el usuario final, debe estar montado sobre la plataforma del Ministerio del Interior, en servidor web es IIS (Internet Information Services) y anclado a la base de datos SQLl Server del Ministerio o en su defecto el ministerio del interior evaluará la posibilidad del uso de MySQL. El diseño y desarrollo deben cumplir todos los lineamientos Gobierno en Línea GEL 3.1 o superior.

viii. BPM

A continuación se describen una serie de lineamientos para el diseño e implementación de procesos sobre la plataforma Auraportal del Ministerio del Interior, que estarán agrupados en los siguientes ítems y documentados en el formato “Formato Diseño BPM.docx”:

1. Definición de claves.

La clave deberá ser definida en relación a los grupos de proceso enfocados a cumplir una necesidad de negocio en particular y será de ayuda para la identificación y trazabilidad de los componentes de los mismos. Es altamente recomendable que la longitud de la designación de la clave sea de tres caracteres. Las claves serán utilizadas como prefijo para los componentes propios de los procesos, por ello, la clave a utilizar debe ser lo más particular posible.

2. Definición de términos.

Los términos son una serie de campos creados por el diseñador del proceso, con el fin de ser mostrados y utilizados en los formularios durante la ejecución de una clase de proceso, en la ficha de familia o en la ficha de un rol en particular. Para la plataforma BPM del ministerio del interior, dichos términos deben ser estructurados de la siguiente forma en el árbol por capítulos:

Tipo de Proceso: En este nodo del árbol se ubican los tipos de procesos que puede tener la entidad (Apoyo, Estratégicos, Misionales), Adicionalmente existe una quinta categoría como es transversal, en la cual se agrupan todos aquellos términos que son genéricos y pueden ser utilizados en las otras categorías de forma canónica o como plantilla guía para formularios.

Proceso: En esta rama se describe el proceso o sub proceso macro que apalanca el procedimiento a automatizar.

Procedimiento: En esta rama se describe el procedimiento el cual se debe implementar

En general, el lineamiento al respecto es que el árbol de términos se encuentre fuertemente relacionado a la definición de la estructura SIGI y que los nombres de los elementos tengan como prefijo la clave de las clases de proceso donde van a ser utilizados.

A continuación, se muestra el ejemplo del procedimiento de “Recepción y Tramite de Cuentas” de cómo se debe estructurar el árbol de términos para la implementación de un proceso.

Página 14 de 26




Vigente desde:

Figura 3. Ejemplo de Estructura de Terminos de un Proceso.

3. Definición de familias propias

A continuación se describen una serie de características que se deben tener en cuenta para la definición de familias propias:

Las familias propias se deben definir de la forma <Clave>.<Nombre_Familia>, todo esto con el fin de generar una estandarización en la nomenclatura, y la fácil identificación de familias por dominio de negocio. Ejemplo: RTC. Contratistas.

Toda familia propia deberá tener un campo de uso exclusivo, esto con el fin de tener una mayor flexibilidad en las búsquedas y cierta integridad en la información.

En la configuración del Grid de las familias propia, los encabezados deberán tener nombres concretos, esto con el fin de su fácil identificación en su consulta.

En lo posible validar que las relaciones entre familias se realice mediante mapas de relación entre familias, el uso de grupos dentro de familias debe validarse para cada caso.

Velar por el mantenimiento unificado de las familias que representan objetos de negocio y que representan entidades que presentan un alto nivel de importancia dentro más de un procedimiento, esto con el fin de no tener pérdidas de integridad de la información.

4. Definición de clases de proceso

Las clases de proceso son los patrones establecidos de un proceso, en donde se definen las características de identidad del proceso, el funcionamiento y los tiempos de afectación de este. A continuación se definen una serie de lineamientos básicos para el diseño e implementación de estas:

La clase de proceso deberá estar ubicada dentro de la estructura de Árbol según el siguiente esquema: Tipo de Proceso, Proceso Macro, clase de proceso. En la siguiente figura se muestra un ejemplo de la estructura para la definición de una clase de proceso:

Página 15 de 26




Vigente desde:

Figura 4. Ejemplo de Definción de una clase de proceso.

En general deben seguir la estructura SIGI de modo que los términos y las clases de proceso donde son utilizados se encuentren en ramas con iguales características de numeración y nombre.

Cada clase de proceso se le deberá asociar un responsable del proceso, en la mayoría de los casos deberá ser el líder técnico asociado. En el diagrama del proceso, los objetos de una clase de proceso como son tareas personales deberán siempre tener en su nomenclatura la descripción básica de la tarea acompañada de la persona y/o el grupo responsable de su ejecución. Ejemplo: Verificación Área Contable - Grupo Contable.

En el diagrama del proceso, los objetos de una clase de proceso como son tareas de sistema deberán siempre tener en su nomenclatura la descripción básica de la tarea, iniciando por el tipo de tarea de sistema. Ejemplo: NOTIFICADOR - Enviar notificación de retraso.

6.1.8.5 Acceso Usuarios

Los procesos y o procedimientos modelados en la plataforma que requieran el acceso deben distinguir la naturaleza del usuario “Usuario Externo - portal Externo Usuario interno – acceso a la plataforma, Usuario Invitado -WIP.” Teniendo en cuenta las WIP debe estar enlazada y definida desde el micrositio empleado para dicho proceso y/o procedimiento, los enlaces y las acciones principales de acceso (url WIP) y registro deben estar allí definidas mediante botones que visualicen claramente el tipo de usuario y acción a realizar.

ix. Transaccional

Para la definición del diseño y arquitectura de las soluciones propuestas sobre .NET se requiere por parte del proveedor del servicio, la elaboración del documento según el formato “Formato Diseño y Arquitectura Transaccional”.

Se entiende que para el diseño de un sistema de información, en primera medida se debe definir el diseño de la arquitectura asociada al sistema, la cual consiste en la definición de los requisitos técnicos y operacionales del mismo. En donde este proceso tiene la finalidad de definir qué componentes forman el sistema, como es su relación entre si y como mediante su interacción llevan a cabo la funcionalidad especificada, cumpliendo con una serie de requerimientos de calidad (requerimientos no funcionales y/o calidades sistémicas).

Por otra parte y teniendo en cuenta el marco que define la arquitectura de software y el ciclo de vida de las aplicaciones, el proceso de diseño de la arquitectura juega un papel muy importante. La diferencia

Página 16 de 26




Vigente desde:

entre un buen proceso de diseño arquitectural y uno malo puede suponer la diferencia entre el fracaso o el éxito de un proyecto.

Por lo anterior para un buen diseño arquitectónico de las aplicaciones basadas en tecnología .Net, se propondrán una serie de lineamientos que estarán agrupados en los siguientes ítems:

Tipos de aplicaciones que se pueden construir. Arquitectura física de la aplicación. Arquitectura lógica de la aplicación. Arquitectura marco de referencia. Estándares de diseño detallado. Tecnologías de la aplicación.

1. Tipos de aplicaciones que se pueden construir

Una vez que están claros los objetivos de la iteración y la funcionalidad que desarrollaremos, podemos pasar a su diseño. Llegados a este punto, el primer paso es decidir qué tipo de aplicación vamos a desarrollar.

Aplicaciones web: Son aplicaciones que se consumen mediante un navegador y que ofrecen una interfaz de usuario estándar y completamente interoperable, estas aplicaciones deben tener la posibilidad de poder ser visualizado en la mayoría de veces, en dispositivos móviles como celulares y tabletas.

Aplicaciones orientadas a Servicios: Se trata de aplicaciones que exponen una funcionalidad determinada en forma de servicios web para que otras aplicaciones los consuman. Este tipo de aplicaciones deberán tender a centralizarse por medio de la tubería de servicios preestablecida en la entidad cuando amerite.

Para otros tipos de aplicaciones, como son: clientes ricos, aplicaciones de escritorio o de dispositivos móviles, serán evaluados por parte del grupo de sistemas las bondades y las desventajas de poder implementar este tipo de aplicaciones.3

2. Arquitectura física de la aplicación

Posteriormente a la definición del tipo de aplicación que se va construir, el paso a seguir es el de diseñar la arquitectura de la infraestructura o la topología de despliegue que tendrá la aplicación. Esta topología, para el caso particular del ministerio del interior se debe realizar mediante un despliegue distribuido.

Este lineamiento se debe a que un despliegue distribuido permite separar las capas lógicas en distintos niveles físicos. De esta forma el sistema puede aumentar su capacidad añadiendo servidores donde se necesiten y se puede balancear la carga para maximizar la eficiencia. Al mismo tiempo, al separar las capas en distintos niveles aprovechamos mejor los recursos, balanceando el número de equipos por nivel en función del consumo de las capas que se encuentran en él.

3 En una arquitectura de servidor cliente el término “cliente rico” es usado para clientes donde el procesamiento de datos ocurre principalmente del

lado del cliente. El cliente también provee la interfaz gráfica de usuario. A menudo los clientes ricos son aplicaciones que son extensibles mediante

conexiones (plug gins) y módulos. De esta forma los clientes ricos son capaces de solucionar más de un problema. Los clientes ricos también pueden

solucionar problemas relacionados potencialmente, al igual que aquellos que sean completamente diferentes a su propósito general. Los clientes ricos

son desarrollados típicamente al principio de un framework. Un framework ofrece un punto de inicio básico al principio por el cual el usuario puede unir

lógicamente las partes relacionadas de la aplicación, las cuales son llamadas módulos.

Página 17 de 26




Vigente desde:

Por lo anterior, los únicos tipos de despliegue soportados para la entidad son: 3 – Niveles, N – Niveles, para los casos en que se requiera otro tipo de despliegue en una aplicación, esta deberá ser previamente evaluada por el grupo de sistemas de la OIPI.

3. Arquitectura lógica de la aplicación

Posterior definición del tipo de aplicación y la estructura física de esta, se debe diseñar la arquitectura lógica de la aplicación. Por lo cual y para un buen diseño, este debe ser guiada mediante un conjunto de estilos arquitecturales o patrones de arquitectura, los cuales definirán aspectos macro del sistema que se diseña y representan una forma estándar de definir o implementar dichos aspectos.

En la siguiente tabla se agrupan los diferentes estilos arquitectónicos soportados por la entidad, agrupados por los aspectos que definen:

Aspecto Estilos arquitecturalesComunicaciones SOA (Service Oriented Architecture), Bus de mensajesDominio Diseño orientado al dominioInteracción Page Template, SPA (Single Page Application)Estructura Componentes, Orientado a objetos, Arquitectura en capas

Para otro tipo de estilos arquitectónicos, que se deseen implementar, estos deberán ser previamente evaluados por el grupo de sistemas de información pública del interior, para su posterior implementación.

4. Arquitectura marco de referencia

A continuación se describe la arquitectura marco de referencia definida por el ministerio del interior, para la construcción de aplicaciones basadas en plataforma .Net.

Figura 5. Arquitectura Marco de Alto Nivel.

Página 18 de 26




Vigente desde:

Capa de Presentación: esta capa tiene como responsabilidad la de mostrar información al usuario e interpretar las acciones que realicen las capas inferiores. Esta capa tiene la responsabilidad de implementar la funcionalidad requerida para que los usuarios puedan interactuar con la aplicación, mediante patrones MVP y MVC.

o Subcapa de Componentes Visuales. Son una serie de componentes que tienen como finalidad ser un mecanismo base para que el usuario utilice el aplicación. Son componentes que formatean datos, tipos de letras, controles visuales y adicionalmente reciben datos proporcionados por el usuario.

o Subcapa de Controladores. Son una serie de componentes que permiten la sincronización y orquestación de las interacciones del usuario con la lógica de la aplicación y viceversa. Lo anterior tiene como fin lograr que el flujo de proceso y la lógica de negocio y de gestión se encuentre programada dentro de los formularios visuales.

Capa de Servicios Distribuidos: esta capa actúa como un proveedor de servicios para otras aplicaciones o para la capa de presentación cuando esta implementa en enfoque SPA (Single Page Application), en donde se publica la lógica de negocio mediante una capa de servicios.

o Subcapa de Contratos. En esta capa se definen todos aquellas contratos de las firmas (funcionalidades) que se van a exponer como servicio, así como las complejidades técnicas como son el comportamiento y el tipo de enlace.

o Subcapa de Implementaciones. Es esta capa se realizan las implementaciones concretas de los servicios y de cómo estos acceden a capas inferiores como son las de datos y/o aplicación.

Capa de Aplicación: esta capa tiene como tarea el poder realizar tareas de coordinación de aspectos tecnológicos de la aplicación, en esta capa se implementa la coordinación de la fontanería de la aplicación. Como la coordinación de transacciones, ejecución de unidades de trabajo y en definitiva llamadas a tareas necesarias para la aplicación. Esta capa es usada por la capa de presentación y/o la capa de servicios distribuidos, y orquesta operaciones entre la capa de datos el modulo común y/o la capa transversal de calidad de servicio.

o Subcapa de Servicios de Aplicación. En esta capa se albergan todas aquellas clase que permiten la coordinación de tareas de negocio entre diferentes componentes como son repositorios, componentes transversales (envió de correos, generación de auditoria y registro. etc…).

o Subcapa de WorkFlow de Negocio. En esta capa se albergan todas aquellas clases que permiten la interacción con la plataforma BPMs AuraPortal de la entidad.

Capa de Acceso a Datos: esta capa tiene las capacidades de poder persistir datos así como lógicamente acceder a ellos. En donde los datos pueden ser propios del sistema o datos expuestos por sistemas externos, esta capa es utilizada por capas superiores como la de aplicación, servicios distribuidos y/o presentación directamente cuando no se requiere ningún tipo de orquestación de tareas de negocio y solo se requiere el paso de los datos.

o Subcapa de Repositorios. Los repositorios son todas aquellas clases encargadas de realizar operaciones de persistencia y acceso a datos, sobre una tecnología concreta. Lo anterior tiene como principal ventaja la centralización de la funcionalidad de acceso a datos.

o Subcapa de Modelos de Datos. En esta capa se albergaran los modelos de datos definidos bajo el enfoque de sistema ORM Entitiy Framework, estos proporciona técnicas de definición del modelo de datos a nivel de diagramas “entidad-relación”.

Página 19 de 26




Vigente desde:

o Subcapa de Agentes de Servicios Externos. Esta capa nace de las necesidades de tener componentes de negocio que puedan utilizar funcionalidades expuestas a través de servicios externos (Normalmente servicios Web) y reutilizarlos internamente en la aplicación.

Módulo Común: Este módulo transversal, tiene como fin proporcionar componentes de software comunes a todas las capas, como son:

o Entidades de Dominio. Son una serie de entidades desconectadas, que se utilizan para alojar y transferir datos de entidades entre las diferentes capas, y adicionalmente contienen también lógica de dominio relativa a cada entidad.

o Objetos Valor. Son una serie de objetos que describen cosas. Y siendo más precisos, un objeto sin ninguna entidad conceptual, que describe aspectos del dominio.

o Objetos Utilitarios. Son todas aquellas clases que tienen como funcionalidad proporcionar utilidades comunes de cálculos, asignaciones y transformaciones a lo largo de toda la aplicación. Generalmente estas clases son definidas como estáticas.

o Adaptadores. Los adaptadores tienen como finalidad poder transformar un tipo de objeto a otro, para que estas puedan ser utilizada das por clases que no puedan utilizar el objeto sin transformar.

Capa transversal de calidad de Servicio (QOS): esta capa tiene la finalidad de proporcionar capacidades técnicas genéricas que dan soporte a capas superiores. En esta capa también existe el concepto de servicios. Se encargan de agrupar acciones de infraestructura, como el envió de correos, controlar aspectos de seguridad, gestión de operaciones, auditoria y registro, etc. En la actualidad la arquitectura marco del ministerio del interior para aplicaciones .Net, solo soporta los bloques de auditoria y registro, manejo de excepciones y criptografía.

NOTA: Esta arquitectura de referencia anteriormente descrita se encuentra implementada, y reposito en el archivo digital de los sistemas de información del grupo de sistemas de la oficina de información pública.

5. Estándares de diseño detallado

A continuación se describen una serie de principios básicos a la hora de diseñar un sistema de información, los cuales ayudaran a crear una arquitectura que se ajuste a prácticas demostradas, que minimicen los costes de mantenimiento y maximicen la usabilidad y extensibilidad.

Principios SOLID. A continuación se describen los principios de diseño relacionados con la sigla SOLID:

o Principio de Única Responsabilidad (Single Responsability Principle): Una clase debe tener una única responsabilidad o característica. Dicho de otra manera, una clase debe de tener una única razón por la que está justificado realizar cambios sobre su código fuente. Una consecuencia de este principio es que, de forma general, las clases deberían tener pocas dependencias con otras clases/tipos.

o Principio Abierto Cerrado (Open Closed Principle): Una clase debe estar abierta para la extensión y cerrada para la modificación. Es decir, el comportamiento de una clase debe poder ser extendido sin necesidad de realizar modificaciones sobre el código de la misma.

o Principio de Sustitución de Liskov (Liskov Subtitution Principle): Los subtipos deben poder ser sustituibles por sus tipos base (interfaz o clase base). Este hecho se deriva de que el comportamiento de un programa que trabaja con abstracciones (interfaces o clases base) no debe cambiar porque se sustituya una implementación concreta por otra.

Página 20 de 26




Vigente desde:

Los programas deben hacer referencia a las abstracciones, y no a las implementaciones. Veremos posteriormente que este principio va a estar muy relacionado con la Inyección de Dependencias y la sustitución de unas clases por otras siempre que cumplan el mismo interfaz.

o Principio de Segregación de Interfaces (Interface Segregation Principle): Los implementadores de Interfaces de clases no deben estar obligados a implementar métodos que no se usan. Es decir, los interfaces de clases deben ser específicos dependiendo de quién los consume y por lo tanto, tienen que estar granularizados/segregados en diferentes interfaces no debiendo crear nunca grandes interfaces. Las clases deben exponer interfaces separados para diferentes clientes/consumidores que difieren en los requerimientos de interfaces.

o Principio de Inversión de Dependencias (Dependency Inversion Principle): Las abstracciones no deben depender de los detalles – Los detalles deben depender de las abstracciones. Las dependencias directas entre clases deben ser reemplazadas por abstracciones (interfaces) para permitir diseños top-down sin requerir primero el diseño de los niveles inferiores.

Mantener el código transversal abstraído de la lógica específica de la aplicación: el código transversal se refiere a código de aspectos horizontales, cosas como la seguridad, gestión de operaciones, logging, instrumentalización, etc. La mezcla de este tipo de código con la implementación específica de la aplicación puede dar lugar a diseños que sean en el futuro muy difíciles de extender y mantener. Relacionado con este principio está AOP (Aspect Oriented Programming).

Separación de Preocupaciones/Responsabilidades (Separation of Concerns): dividir la aplicación en distintas partes minimizando las funcionalidades superpuestas ente dichas partes. El factor fundamental es minimizar los puntos de interacción para conseguir una alta cohesión y un bajo acoplamiento. Sin embargo, separar la funcionalidad en las fronteras equivocadas, puede resultar en un alto grado de acoplamiento y complejidad entre las características del sistema.

No repetirse (DRY): se debe especificar la intención en un único sitio en el sistema. Por ejemplo, en términos del diseño de una aplicación, una funcionalidad específica se debe implementar en un único componente; esta misma funcionalidad no debe estar implementada en otros componentes.

Minimizar el diseño de arriba abajo (Upfront design): diseñar solamente lo que es necesario, no realizar sobre ingenierías y evitar el efecto YAGNI (En inglés-slang: You Aint Gonna Need It).

6. Tecnologías de la aplicación

A continuación se describe la arquitectura marco de referencia definida por el ministerio del interior, para la construcción de aplicaciones basadas en plataforma .Net, detallada en las diferentes tecnologías que implementa.

Página 21 de 26




Vigente desde:

Figura 6. Arquitectura Marco de Alto Nivel con Tecnologías Asociadas.

o Microsoft .Net. NET Framework es un entorno de ejecución runtime que administra aplicaciones cuyo destino es .NET Framework. Incorpora Common Language Runtime, que proporciona administración de la memoria y otros servicios del sistema, y una biblioteca de clases completa, que permite a los programadores aprovechar el código sólido y confiable de todas las áreas principales del desarrollo de aplicaciones.

o Microsoft Asp.Net. ASP.NET es un modelo de desarrollo Web unificado que incluye los servicios necesarios para crear aplicaciones Web empresariales con el código mínimo. ASP.NET forma parte de .NET Framework y al codificar las aplicaciones ASP.NET tiene acceso a las clases en .NET Framework. El código de las aplicaciones puede escribirse en cualquier lenguaje compatible con el Common Language Runtime (CLR), entre ellos Microsoft Visual Basic y C#. Estos lenguajes permiten desarrollar aplicaciones ASP.NET que se benefician del Common Language Runtime, seguridad de tipos, herencia, etc.

o KnockOut.js. Es una biblioteca javascript, que nos ayuda a implementar aplicaciones mediante un modelo MVVM. Dentro de las características especiales, tal cual indica en su página, nos permite:

Realizar Binding Declarativos Refresco automático de los elementos del UI, como decía, cuando se actualiza el

modelo vista, nuestra UI se actualiza automáticamente Tracking de Dependencias, detecta los cambios realizados en la vista o en el

modelo y es capaz de propagarlos. Plantillas, permite generar rápidamente plantillas en función de los datos del

modelo vista.o JQuery. Es un framework de JavaScript para facilitar, entre otros, el acceso a los

elementos del DOM, los efectos, interactuar con los documentos HTML, desarrollar animaciones y agregar interacción con la tecnología AJAX a páginas web.

o OData. Es una estandarización, a través de la carta de compromiso de Microsoft (Microsoft Open Specification Promise), de la generación y consumo de datos vía Web. Esta construido sobre un conjunto de estándares de internet, especialmente sobre el AtomPub especificado en el RFC 5023, quien a su vez está construido sobre Atom. Odata permite la creación de servicios de datos basados en HTTP mediante un modelo de datos abstracto mediante un identificador uniforme de recursos (Uri) definidos en el RFC 2396.

Página 22 de 26

http://es.wikipedia.org/wiki/AJAX




Vigente desde:

o Windows Comunication Foundation (WCF). Es el modelo de programación unificado de Microsoft para generar aplicaciones orientadas a servicios. Permite a los programadores generar soluciones con transacción seguras y de confianza, que se integren en diferentes plataformas y que interoperen con las inversiones existentes.

o Entity Framework (EF). Entity Framework es una tecnología que permite a los desarrolladores trabajar con datos en forma de objetos y propiedades específicos del dominio, como clientes y direcciones de cliente, sin tener que preocuparse por las tablas y columnas de la base de datos subyacente donde se almacenan estos datos. Con Entity Framework, los desarrolladores pueden trabajar en un nivel mayor de abstracción cuando tratan con datos, y pueden crear y mantener aplicaciones orientadas a datos con menos código que en las aplicaciones tradicionales. Dado que Entity Framework es un componente de .NET Framework, las aplicaciones de Entity Framework se pueden ejecutar en cualquier equipo en el que esté instalado.

o Lucene. Apache Lucene es una biblioteca del motor de búsqueda de alto rendimiento de texto, con todas las funciones. Se trata de una tecnología adecuada para casi cualquier aplicación que requiera la búsqueda de texto completo, especialmente multiplataforma.

o Enterprise Libraries. Microsoft Enterprise Library es un conjunto de librerías que facilitan el desarrollo de aplicaciones empresariales en .NET. Implementan funcionalidad que típicamente debe incorporarse a las aplicaciones empresariales. Esta funcionalidad se presenta subdividida en 9 bloques, cada uno apuntando a resolver un tipo de problema particular:

b. Implementación

i. General

Es responsabilidad del ejecutor del proyecto la identificación de las necesidades en relación a ambientes de pruebas y acceso a información del Ministerio del Interior, conjuntamente con el grupo de sistemas de la OIPI se establecerán los mecanismos de acceso y/o transferencia de información posterior a la evaluación de confidencialidad de la misma.

ii. BPM

Todos los elementos de una clase de proceso deben documentarse de acuerdo a su finalidad dentro del mismo, para ello se debe diligenciar el campo Descripción para todos los elementos de tipo Evento, Compuerta y Tarea (Personal y Sistema).

1. Construcción de formularios

A continuación se describen una serie de lineamientos técnicos a tener en cuenta para la construcción de formularios sobre la plataforma.

Los Nombres de los formularios deberán ser de la forma <Clave>.<Objeto>, Ejemplo: RTC.IM_Proceso X, el anterior ejemplo identifica al formulario asociado al inicio del proceso. Las divisiones de los formularios deberán ser de la forma <Clave>.<Objeto>.<NombreDiv>, Ejemplo: RCT.IM_Proceso X.HEADER_FORMULARIO, el anterior ejemplo identifica a la división asociada a la cabecera del formulario.

Los estilos aplicados a los objetos del formulario deberán en todos los casos estar enlazados a los estilos previamente aprobados para el proyecto y configurados en la herramienta en la sección de galería de

Página 23 de 26




Vigente desde:

estilos.

Se debe evaluar la necesidad de que los eventos IM y EM se publiquen como servicios web, de este modo se posibilita que los procesos puedan ser iniciados o continuados por programas externos.

2. Seguridad

En relación a este punto se debe partir del enfoque de la herramienta hacia los recintos seguros, en ese orden de ideas se deberán en lo posible determinar tres tipos diferentes de estos para aplicar a los elementos configurados a saber:

Recintos de Monitorización: Aplicables a la monitorización de los procesos automatizados los cuales deberán cumplir con la sintaxis Clave.RCM.X donde X representa el nombre particular al o los procesos que se blindan con el recinto. Es preferible que para la aplicación del recinto en su sección de Lectura se defina un solo Rol Personal.

Recintos de Procesos: Aplicables a los inicios y eventos intermedios de los procesos automatizados, deberán cumplir con la sintaxis Clave.RCP.X donde X representa el nombre particular relacionado al o los eventos de los procesos que se blindan con el recinto. Es preferible que para la aplicación del recinto en su sección de Lectura se defina un solo Rol Personal.

Recintos de Familias: Aplicables a los accesos de tipo CRUD de las familias utilizadas, deberán cumplir con la sintaxis Clave.RCF.X donde X representa el nombre particular al o las familias que se blindan con el recinto. Es preferible que para la aplicación del recinto en sus secciones de Lectura / Edición / Adición / Cancelación se defina un solo Rol Personal.

En lo relacionado a los roles a aplicar sobre los recintos seguros y siguiendo las recomendaciones de casa matriz, se deben nombrar de acuerdo a su utilización en los recintos en el modo en que apliquen de la forma, por ejemplo, si el rol aplica para un recinto de familia, el rol deberá determinarse como Clave.RCF.X_Y, donde X es el nombre particular dado al recinto y Y la abreviatura del modo (L, E, A, C) – (Lectura, Edición, Actualización, Cancelación).

iii. Transaccional

Se requiere que el código fuente entregado como definitivo se encuentre debidamente documentado en cuanto a las clases y los métodos que la componen. Solo para los casos en que la lógica descrita sea demasiado compleja se sugiere documentar las porciones de código relacionadas.Es altamente recomendable que se realicen inspecciones de codificación sobre la los artefactos en construcción con el fin de disminuir la utilización de malas prácticas de software, al respecto, en cualquier momento el grupo de sistemas de la OIPI podrá solicitar al proveedor de la solución, el código fuente para la realización de inspecciones sobre la construcción.

c. Pruebas

i. General

El ejecutor del proyecto se encuentra en libertad de aplicar su metodología en lo relacionado a las pruebas unitarias y pruebas de certificación de los desarrollos, sin embargo debe contemplar dentro de sus planes, la elaboración y ejecución de un plan de certificación por parte del usuario final. Estas pruebas deberán contemplar los escenarios de negocio junto con los datos de entrada y resultados esperados de modo que a manera de lista de chequeo, una vez finalizados los desarrollos, el usuario final defina el nivel de cumplimiento que presenta la herramienta en relación a los procesos de negocio incluidos en el alcance del proyecto.

Página 24 de 26




Vigente desde:

Para dar como verificado un caso de uso, se debe diligenciar el documento según formato “Formato de Pruebas Funcionales TC-GT-P2-F5” en el que deberá quedar consignada la conformidad por parte del usuario con el producto entregado.

d. Entrega

i. General

Para la recepción del proyecto por parte del grupo de sistemas de la OIPI, el ejecutor del proyecto deberá hacer la entrega total de la siguiente información:

Formatos de Gestión de inicio, seguimiento y cierre del proyecto, bajo acta de aceptación. Casos de prueba certificados por los respectivos usuarios finales, bajo actas de aceptación. Código fuente de todos los componentes (proyectos transaccionales). Ficha técnica del sistema de información (proyectos transaccionales), se deben incluir los datos

de contacto para las eventuales solicitudes de soporte. Manual de usuario. Manual de instalación y configuración (proyectos transaccionales). Manual técnico de operación en el cual se debe incluir el listado de errores comunes y sus

formas de solucionarlo. Documento de entrega de procesos (BPM).

Se entiende que los entregables intermedios del proyecto pueden tener modificaciones durante la ejecución de las fases posteriores, por ello se hace necesario que como parte de la entrega final se presenten los documentos definitivos relacionados a todos los entregables.

ii. BPM

El manual de usuario de los procesos BPM debe en gran medida enfocarse al detalle de la ejecución de pasos y acciones dentro de las pantallas que acompañan la definición del mismo. Para resaltar algunos de los puntos que se entienden como clave y obligatorios al momento de evaluar y recibir el manual de usuario se listan a continuación las consideraciones mínimas a tener en cuenta:

- Debe contener una sección general al inicio del manual donde se describan las operaciones comunes a todas las pantallas y que expliquen la forma de funcionamiento de los controles como botones, cuadros de selección, tablas y demás controles que permiten la interacción de los usuarios con el sistema.

- Definición de los grupos de empleados con su respectiva descripción que aplican sobre la ejecución de las tareas en los procesos.

- Matriz de trazabilidad que indique la relación entre grupos de procesos y pantallas, esto es útil para generar un contexto visual de las tareas en que un grupo de empleados en particular debe intervenir directamente.

Página 25 de 26




Vigente desde:

6. DOCUMENTO/ REGISTRO

REGISTROS RESPONSABLE FRECUENCIA UBICACIÓNActa de Aceptación Líder de Gestión Permanente 1301.48Documento Técnico Líder Técnico Permanente 1301.48

Ficha Técnica Desarrolladores Permanente 1301.48Formato de Pruebas Analista de Calidad Permanente 1301.48

*Tabla de retención documental

7. CONTROL DE CAMBIOS

FECHA CAMBIO VERSIÓN

8. CONTROL DE FIRMAS

Elaboró Revisó y Aprobó Firma

_______________________

Firma

______________________NombreFirma

NombreFirma

9. ANEXOS

Para apoyo, comprensión y aplicación de las actividades descritas en este documento es necesario consultar e implementar los lineamientos de gobierno en línea en marcados en el link: http://www.mintic.gov.co/arquitecturati/630/w3-propertyvalue-8114.html

Página 26 de 26

1 · web view: la arquitectura de software es un conjunto de patrones que proporcionan un marco de...

Documents