Normas sobre Tecnologías de la Información y Comunicación - NORTIC

Normas sobre Tecnologías de la Información y Comunicación - NORTIC

Administración y desarrollo

En este capítulo se presentan las directrices que deben aplicar los organismos gubernamentales para lograr una mejor administración y uso del software, así como el desarrollo del software gubernamental, estableciendo una vía de control y estandarización en cada uno de sus procesos.

  • Administración del software Abrir o Cerrar

    En la siguiente sección de establecen las pautas y lineamientos que los organismos gubernamentales deben implementar al momento de instalar, reinstalar o actualizar un software, así como también las políticas de uso.

     

    Instalación y reinstalación del software

    1. Todo requerimiento o solicitud de instalación, reinstalación o reparación del software por parte de un usuario, debe ser realizado mediante correo electrónico o algún otro medio de comunicación usado por el organismo, detallando como mínimo:

      • Nombre de usuario.

      • Cargo de usuario.

      • Razones de la instalación/reinstalación.

      • Programas, aplicaciones o utilitarios a instalar o reinstalar.

    2. Todo requerimiento o solicitud de instalación, reinstalación o reparación de software perteneciente a la plataforma de TIC, debe ser aprobado por el personal autorizado del área de Operaciones TIC.

    3. Para la instalación del software adquirido debe cumplirse con los requerimientos mínimos de hardware especificados por el fabricante como:

      • Tipo de procesador.

      • Cantidad de memoria.

      • Cantidad de espacio en disco.

      • Sistema operativo o plataforma compatible.

      • Cualquier otro requerimiento especificado por el fabricante.

    4. La unidad de administración del servicio TIC debe contar con un personal que asuma la función de las instalaciones, reinstalaciones o reparaciones del software en los equipos de los usuarios. Para las instalaciones, reinstalaciones o reparaciones en equipos, tales como servidores, base de datos, equipos de redes y comunicaciones entre otros, la unidad de operaciones TIC debe contar con el personal necesario para realizar estas funciones.

    5. El personal designado debe tener conocimientos técnicos de los sistemas operativos y aplicaciones utilizadas en las áreas de operación y administración TIC antes mencionadas.

    6. Antes de realizarse la desinstalación del software adquirido en la infraestructura TIC, debe hacerse un respaldo de los archivos o informaciones como se establece en el punto sobre el Respaldo de la información.

    7. Toda instalación, reinstalación o reparación del software adquirido en la plataforma TIC o en los equipos de usuario debe ser documentada.

    8. La documentación debe contener como mínimo:

      • Nombre del software adquirido y tipo de software adquirido.

      • Justificación de la instalación, reinstalación o reparación.

      • Equipo donde se realizó la instalación, reinstalación o
        reparación.

      • Responsable de la instalación, reinstalación o reparación.

     

    Actualización del software adquirido

    Para la actualización del software adquirido con carácter crítico, debe cumplirse con las siguientes directrices:

    1. Autorización del personal responsable dentro del área de operaciones TIC.

      1. Tener una copia de seguridad del sistema en caso de fallas.
      2. Realizar las actualizaciones del software adquirido luego de la jornada laboral o en horas donde se experimente menos uso del ancho de banda de la red.

      3. Descargar las actualizaciones directamente desde el proveedor.
    2. Los departamentos de TIC deben elaborar políticas para la implementación de aquellas actualizaciones que no sean consideradas como críticas.

    3. Las políticas de actualizaciones automáticas realizadas mediante un servidor de aplicaciones, repositorio o algún otro medio, deben ser elaboradas por el departamento de TIC, tomando las siguientes medidas:

      1. Las actualizaciones del software adquirido deben ser programadas en horas no laborales o en horas donde se experimente menos uso del ancho de banda de la red.

      2. El proceso de actualización no debe interrumpir los servicios del organismo gubernamental.

      3. El proceso de actualización entre el servidor o repositorio de aplicaciones o y el proveedor, no debe afectar el ancho de banda de la red.

     

    Políticas de uso del software adquirido

    1. Debe elaborarse políticas para el uso del software adquirido, en donde se establezcan los derechos y restricciones que tienen los usuarios respecto al software adquirido instalado en el equipo.
    2. Las políticas de uso del software adquirido deben ser dadas a los usuarios, mediante correo electrónico, Intranet o cualquier medio de comunicación que el organismo considere.

    3. Los departamentos de TIC deben implementar controles que eviten la instalación y desinstalación del software adquirido.
    4. El software utilizado por el organismo debe estar provisto con el soporte necesario por parte del proveedor.

     

  • Desarrollo del software gubernamental Abrir o Cerrar

    Todo software gubernamental desarrollado por los organismos debe mantener un marco de usabilidad y accesibilidad para seguir una metodología quepermita la buena gestión de los requerimientos, diseño, codificación y prueba del software gubernamental, cumpliendo así con la calidad y el tiempo a la hora de la entrega del producto final.

     

    Usabilidad del software gubernamental

    1. El software gubernamental debe estar diseñado para ofrecer la mejor experiencia al usuario tomando como referencia los siguientes criterios:
      1. Evitar el uso de ventanas emergentes cuando estas no sean solicitadas por el usuario.

      2. Mantener la homogeneidad del software gubernamental permitiendo que los usuarios realicen las tareas en el mismo orden lógico y en las mismas condiciones en todas las pantallas.

      3. Si la pantalla en la que se encuentra el usuario tiene un límite de tiempo, informar al usuario antes de que este expire.

      4. Retroalimentar al usuario mientras este espera por la finalización de un proceso o tarea:

        1. Si el proceso o la tarea dura más de 10 segundos, debe hacerse uso de un reloj de arena, barra de progreso o algún otro indicativo.

      5. Tener una opción de ayuda, en caso de que el usuario lo necesite.
      6. Tener una resolución de pantalla mínima para visualización de las pantallas de 1024 x 768 pixeles.

    2. Poseer una pantalla de inicio:
      1. El usuario debe poder acceder a la pantalla de inicio en todo momento.

      2. Todos los elementos y opciones principales deben estar presentes en la pantalla de inicio.

    3. Utilizar un diseño adecuado cuando se necesite visualizar una información en pantalla, evitando que los usuarios tengan que desplazarse horizontalmente.

    4. Informar al usuario en qué pantalla se encuentra:
      1. Debe destacarse el menú en donde se encuentra el usuario.

      2. Cuando el usuario hace clic sobre un botón dentro de la pantalla este debe cambiar de color o forma.
      3. Cuando se utilicen formularios, los campos requeridos deben diferenciarse de los campos opcionales.

      4. El formulario debe validar los datos antes hacer el envío.
      5. No debe existir faltas ortográficas.

     

    Accesibilidad del software gubernamental

    1. El software gubernamental debe permitir la navegación, a través del menú principal, y seleccionar todos los elementos del menú, incluyendo el menú del sistema por medio del teclado.

    2. Cada función de la barra de herramientas debe ser seleccionable desde el teclado.

    3. Todas las funciones básicas del teclado y atajos deben estar disponibles.
    4. El usuario debe navegar por el área de texto o contenido por medio del teclado.

    5. El usuario debe acceder a cualquier interfaz de la aplicación utilizando el teclado.

    6. Cuando se utilice elementos de multimedia en la aplicación, estos deben incorporar:

      • Una indicación de la señal del sonido y audio.

      • Gráficos descriptivos para la señalización del audio.

      • Textos descriptivos para la señalización del video.

      • Una opción donde el usuario pueda habilitar o deshabilitar el sonido o ajustar el volumen.

    7. No debe utilizarse objetos que provoquen parpadeos o movimientos continuos en el contenido.

    8. La información o contenido no debe depender de los colores.

    9. No debe haber elementos escondidos u ocultos.
    10. Todos los controles deben estar con una etiqueta que describa su utilidad.

    11. Debe evitarse que los controles no disponibles puedan ser marcados con el cursor.

    12. Todos los elementos de una ventana deben tener una tabulación y orden lógico.

    13. Todo tipo de fuente debe ser legible y entendible por el usuario.

    14. Las imágenes e íconos deben ser descriptivos y objetivos a su función.

     

    Metodología para el desarrollo del software gubernamental

    La metodología para el desarrollo del software gubernamental, debe seguir un conjunto de procesos, los cuales se describen en la figura no.1.

    Metodología de desarrollo del software gubernamental

    Proceso de gestión de los requerimientos

    1. Debe elaborarse una lista ordenada con todos los requerimientos del software gubernamental suministrados por los interesados, especificando como mínimo:
      • Prioridad de cada requerimiento.

      • Validación y aceptación de cada requerimiento por los interesados.
      • Características, funcionalidades, requisitos, mejoras y correcciones que se vayan realizando sobre cada entrega del prototipo del software gubernamental.

    2. La lista de requerimientos del software gubernamental debe contar con los siguientes atributos:

      • Descripción del requerimiento.

      • Número de orden del requerimiento.

      • Tiempo estimado para desarrollo del requerimiento.

      • Valor del requerimiento dado por la parte interesada.

    3. La prioridad y los detalles de cada requerimiento solo deben ser actualizados o modificados a solicitud del departamento de TIC con aprobación de las partes interesadas.

    4. El software gubernamental debe dividirse en prototipos, los cuales serán mostrados y entregados a los interesados.

    Proceso de planificación del desarrollo

    1. Debe realizarse un plan de desarrollo en base a un periodo de tiempo no mayor de un mes.
    2. El plan de desarrollo debe contener como mínimo los siguientes elementos:

      • Lista de requerimientos seleccionados para la entrega del prototipo.

      • Objetivo que se alcanzará en la entrega de cada prototipo.

      • Detalles que contendrá la entrega de cada prototipo.

      • Capacidad de desarrollo para la ejecución del desarrollo.

    3. Debe decidirse y evaluarse cuáles son los requerimientos que se tomarán en cuenta de la lista para la entrega de cada prototipo.

    4. Una vez seleccionados los requerimientos para la entrega del prototipo y estos sean aprobados por las partes interesadas, debe elaborarse:

      1. Un diseño general de la arquitectura del software gubernamental, utilizando uno de los siguientes patrones arquitectónicos:

        • Arquitectura en base a modelos y vistas, y cualquier otro que se adapte a este patrón, con el objetivo de separar los datos, las funcionalidades del software gubernamental y la interfaz del usuario.
        • Arquitectura por n-capas, donde el software gubernamental sea segregado en el número de capas necesarias.

      2. Un diseño preliminar de las interfaces de usuario, pantallas y cualquier otro elemento o componente del software gubernamental.

      3. Un diseño inicial de la base datos, tomando en cuenta los siguientes criterios:

        1. Las base de datos, tanto relacional como orientadas a objetos, debe soportar los siguientes formatos para el intercambio de información:

          • Notación de Objetos de JavaScript (JSON, por sus siglasen inglés) y sus variantes.

          • Lenguaje de Marcas Extensible (XML, por sus siglas en inglés) y sus variantes.

          • Valores Separados por Coma (CSV, por sus siglas en inglés).

          • Valores Separados por Delimitadores (TSV, por sus siglas en inglés).

      4. Los diseños elaborados deben ser incluidos dentro del plan de desarrollo y actualizados cada vez que se genere algún cambio.

      5. Debe especificarse el tiempo que se tomará para entregar cada prototipo.
      6. Debe informarse a las partes interesadas mediante una documentación o comunicación cómo será ejecutado el desarrollo para cumplir con la entrega del prototipo.

    Proceso de organización del desarrollo

    1. Una vez seleccionados los requerimientos para la entrega del prototipo debe listarse, dividir y seleccionar los requerimientos con los cuales se trabajará diariamente.
    2. La lista de requerimientos diarios debe ser actualizada constantemente durante la realización del desarrollo, mostrando lo siguiente:

      • Requerimiento completado.

      • Requerimiento pendiente.

      • Requerimiento actualizado.

      • Requerimiento eliminado.

    3. Cuando uno de los requerimientos de la lista de desarrollo diario pasa a ser innecesario este debe ser eliminado.

    Proceso de desarrollo diario

    1. Durante el desarrollo diario cada participante en el desarrollo debe informar:
      • Desarrollo realizado el día anterior.

      • Desarrollo que realizará.

      • Impedimentos que puedan atrasar la ejecución del desarrollo diario.

    2. El prototipo debe desarrollarse cumpliendo con los requerimientos obtenidos en la lista de requerimientos del software gubernamental y con el diseño general de la arquitectura del software gubernamental.

    3. El código fuente debe estar comentado.
    4. Las variables deben ser nombradas de acuerdo a su función en el código fuente.

    5. Todo el código fuente debe estar claramente tabulado.
    6. Debe implementarse herramientas para el control de versiones del código fuente.

    7. Debe realizarse pruebas de unidad en cada uno de los módulos, verificando que estos cumplan con los requerimientos del software gubernamental, como lo especifica el Proceso de gestión de los requerimientos descrito anteriormente.

    8. Debe realizarse pruebas de integración, verificando que los módulos sean interoperables entre sí.

    Proceso de revisión del desarrollo

    1. Para la revisión del desarrollo debe realizarse una prueba general del prototipo del software gubernamental, donde se compruebe su funcionamiento y estabilidad.

    2. Debe verificarse cuáles funcionalidades de la lista de requerimientos del software gubernamental se han completados y cuáles están pendientes.

    3. Si la parte interesada añade nuevos requerimientos después de presentar el prototipo, la lista de requerimientos del software gubernamental debe ser actualizada.

    4. Los resultados de la prueba general del prototipo del software gubernamental deben incluirse dentro del plan de desarrollo.

    Proceso de recapitulación del desarrollo

    1. Debe identificarse y ordenarse las actividades más importantes que salieron de forma efectiva y las posibles mejoras a realizarse.

    2. Estas informaciones deben estar contenidas dentro del plan de desarrollo.

  • Software libre en la administración pública Abrir o Cerrar
    1. Los organismos gubernamentales deben desarrollar sus aplicaciones en base a código fuente y licencias abiertas.
    2. Los organismos que contraten servicios de desarrollo de aplicaciones, deben exigir a los desarrolladores propiedad exclusiva de las aplicaciones y códigos fuentes, y estos deben colocarse en el Repositorio del Software Gubernamental del Estado; cumpliendo con todo lo especificado en la NORTIC A3, sobre publicación de datos abiertos en el gobierno dominicano.