Lineamientos de desarrollo y

gestión de software en las entidades

públicas del Estado Plurinacional de
Bolivia

Agosto de 2017

1
Tabla de contenido
1INTRODUCCIÓN...................................................................................................................................6
2MARCO NORMATIVO REFERENCIAL..............................................................................................9
3OBJETIVO...............................................................................................................................................9
4ALCANCE...............................................................................................................................................9
5TÉRMINOS Y DEFINICIONES...........................................................................................................10
6LICENCIA SOFTWARE LIBRE LPG BOLIVIA.................................................................................11
7DESARROLLO DE SOFTWARE PARA EL ESTADO........................................................................12
7.1Proyecto de desarrollo de software................................................................................................12
7.2Estructura básica de un proyecto....................................................................................................12
7.2.1Inicio.......................................................................................................................................12
7.2.1.1Objetivos de la fase de inicio..........................................................................................12
7.2.1.2Actividades.....................................................................................................................12
7.2.2Planificación...........................................................................................................................12
7.2.3Objetivos de la fase de planificación......................................................................................13
7.2.3.1Actividades que tienen lugar durante la etapa de planificación......................................13
7.2.4Ejecución................................................................................................................................13
7.2.4.1Objetivos de la fase de ejecución....................................................................................13
7.2.4.2Actividades durante la etapa de ejecución......................................................................14
7.2.5Seguimiento y control.............................................................................................................14
7.2.5.1Objetivo de la fase de seguimiento y control..................................................................14
7.2.5.2Actividades durante la etapa de seguimiento y control..................................................14
7.2.6Cierre......................................................................................................................................15
7.2.6.1Objetivos de la fase de cierre..........................................................................................15
7.3Desarrollo de software....................................................................................................................16
7.3.1Accesibilidad y Usabilidad.....................................................................................................16
7.3.2Disponibilidad........................................................................................................................18
7.3.3Obsolescencia del software.....................................................................................................18

2
 7.3.4Interoperabilidad.....................................................................................................................18
7.3.5Arquitecturas de software.......................................................................................................18
7.4Metodologías para el desarrollo del software.................................................................................18
7.5Código Fuente................................................................................................................................19
7.5.1Manejo de código fuente........................................................................................................19
7.5.1.1Control de Versiones.......................................................................................................19
7.5.2Documentación del software..................................................................................................19
7.5.2.1Documentación mínima de un proyecto.........................................................................19
7.5.2.2Documentos técnicos del sistema...................................................................................20
7.6Pruebas...........................................................................................................................................21
7.6.1Pruebas unitarias.....................................................................................................................21
7.6.1.1Ventajas...........................................................................................................................22
Detección temprana de problemas........................................................................................22
Refactorización de código.....................................................................................................22
Corrección de errores............................................................................................................22
7.6.2 Pruebas de integración...........................................................................................................22
7.6.3 Pruebas de estrés....................................................................................................................22
7.7Auditoría de sistemas.....................................................................................................................23
7.7.1Almacenamiento de actividad en base de datos.....................................................................23
7.7.2Almacenamiento de actividad en servidores remotos............................................................23
7.7.3Manejo de errores y reporte de incidencias............................................................................24
7.8Calidad y aseguramiento del Software...........................................................................................24
7.9Seguridad........................................................................................................................................25
7.9.1Confidencialidad.....................................................................................................................25
7.9.2Integridad................................................................................................................................25
7.9.3Disponibilidad........................................................................................................................26
7.10Mantenimiento del software.........................................................................................................26
7.10.1Refactorización de código....................................................................................................26
8IMPLEMENTACIÓN Y GESTIÓN DE BASE DE DATOS.................................................................27

3
 8.1 Implementación de base de datos..................................................................................................27
8.1.1 Gestor de base de datos..........................................................................................................27
8.1.2 Políticas de Seguridad de la base de datos.............................................................................27
8.1.3Documentos generados:..........................................................................................................27
8.2Gestión de base de datos................................................................................................................28
8.2.1Respaldos................................................................................................................................28
8.2.2Usuarios administradores........................................................................................................28
8.2.3Versionamiento de la base de datos........................................................................................29
8.3Ciclo de vida de la Base de Datos..................................................................................................29
8.3.1Diseño.....................................................................................................................................29
8.3.1.1Integridad del modelo.....................................................................................................30
8.3.1.2Nombrado de tablas y campos........................................................................................30
8.3.1.3Codificación de las tablas...............................................................................................30
8.3.1.4Idioma de campos...........................................................................................................30
8.3.1.5Procedimientos y funciones............................................................................................31
8.3.1.6Documentos generados...................................................................................................31
8.3.2Desarrollo...............................................................................................................................31
8.3.3Evaluación y mantenimiento..................................................................................................31
9CATÁLOGO DE SOFTWARE..............................................................................................................31
9.1Información mínima.......................................................................................................................32
10 CONTRATACIÓN DE DESARROLLO DE SOFTWARE DE TERCEROS....................................32
10.1Proyecto de desarrollo de software..............................................................................................32
10.2Desarrollo de software..................................................................................................................32
10.3Sobre la base de datos..................................................................................................................33
10.4Aceptación del Producto..............................................................................................................33
10.4.1Aceptación del área de sistemas...........................................................................................33
10.4.2Aceptación del área solicitante.............................................................................................33
10.5Transferencia de tecnología..........................................................................................................33
10.5.1Capacitación.........................................................................................................................33

4
 10.5.1.1Capacitación técnica.....................................................................................................33
10.5.1.2Capacitación de uso del sistema...................................................................................34
11ABREVIATURAS Y ACRÓNIMOS...................................................................................................34
12ANEXO................................................................................................................................................35

5
 LINEAMIENTOS PARA LA GESTIÓN Y DESARROLLO DE SOFTWARE EN LAS
ENTIDADES PÚBLICAS DEL ESTADO PLURINACIONAL DE BOLIVIA

1 INTRODUCCIÓN
El Consejo para las Tecnologías de Información y Comunicación del Estado Plurinacional de
Bolivia (CTIC-EPB) se constituye en una instancia de coordinación técnica para la
implementación de Gobierno Electrónico y para el uso y desarrollo de Tecnologías de
Información y Comunicación en el país.
Entre las principales tareas asignadas al CTIC-EPB se encuentran:
• Formular propuestas de políticas y normativa relacionada con Gobierno
Electrónico, a ser presentadas a la AGETIC;
• Presentar proyectos y programas de Gobierno Electrónico y Tecnologías de
Información y Comunicación en el ámbito gubernamental a la AGETIC para su
gestión;
• Generar mecanismos de participación de instituciones y organizaciones de la
sociedad civil en la proposición y formulación de políticas y acciones
relacionadas con Gobierno Electrónico y Tecnologías de Información y
Comunicación en el ámbito gubernamental;
• Establecer espacios de coordinación entre las entidades del sector público para
el desarrollo conjunto de programas, proyectos o acciones de Gobierno
Electrónico y Tecnologías de Información y Comunicación en el ámbito
gubernamental;
• Desarrollar y proponer estándares abiertos oficiales del Estado Plurinacional de
Bolivia en materia de Gobierno Electrónico y Tecnologías de Información y
Comunicación aplicables a las entidades del sector público;
• Establecer espacios de coordinación de comunidades de desarrollo informático,
dentro del Estado, con la ciudadanía y a nivel internacional.
El 5 de mayo de 2016 se llevó a cabo la inauguración y la primera reunión del Pleno del
CTIC-EPB, en la que se conformaron seis grupos temáticos de trabajo: Interoperabilidad,
Software Libre, Seguridad, Infraestructura, Desarrollo de Software y Datos Abiertos.
Cada Grupo de Trabajo estuvo integrado por servidores públicos de las entidades del nivel
central del Estado: Órgano Ejecutivo, Legislativo, Judicial y Electoral, incluyendo sus
instituciones descentralizadas, autárquicas, empresas públicas y autoridades de regulación
sectorial; Ministerio Público y Procuraduría General del Estado.
Adicionalmente, se invitó a participar, en calidad de miembros adjuntos, a representantes de
entidades territoriales autónomas, universidades públicas e indígenas y sociedad civil, a fin

6
de trabajar y elaborar propuestas a ser presentadas al Consejo para su posible
implementación a nivel estatal.
Cabe mencionar que el desarrollo de los Grupos de Trabajo y del Consejo se enmarca en el
Reglamento de Funcionamiento del CTIC-EPB, aprobado mediante la Resolución
Administrativa N° 024/2016 de la AGETIC, de fecha 31 de mayo de 2016.
El Grupo de Trabajo de Desarrollo de Software se planteó como objetivo elaborar un
documento que defina los estándares técnicos para el desarrollo de software, aplicable en las
entidades del sector público del Estado Plurinacional de Bolivia.
El Grupo estuvo conformado por los representantes de las siguientes entidades y sociedad
civil:
• Aduana Nacional de Bolivia (ANB).
• Agencia de Gobierno Electrónico y Tecnologías de Información y Comunicación
(AGETIC).
• Agencia para el Desarrollo de la Sociedad de la Información en Bolivia (ADSIB).
• Autoridad de Fiscalización y Control Social de Electricidad (AE).
• Autoridad de Fiscalización del Juego (AJ).
• Autoridad de Supervisión del Sistema Financiero (ASFI).
• Autoridad General Jurisdiccional Administrativa Minera (AJAM).
• Banco Unión S.A. (BUSA).
• Dirección General de Migraciones (DIGEMIG).
• Empresa Boliviana de Industrialización de Hidrocarburos (EBIH).
• Empresa de Apoyo a la Producción de los Alimentos (EMAPA).
• Empresa Estatal de Transporte Por Cable - “Mi Teleférico”.
• Empresa Pública “QUIPUS”.
• Fondo de Desarrollo del Sistema Financiero y de Apoyo al Sector Productivo
(FONDESIF).
• Gobierno Autónomo Departamental de Cochabamba.
• Gobierno Autónomo Departamental de Tarija.
• Instituto Boliviano de Metrología (IBMETRO).
• Instituto Nacional de Estadística (INE).
• Insumos Bolivia.

7
 • Ministerio de Defensa.
• Ministerio de Desarrollo Productivo y Economía Plural (MDPyEP).
• Ministerio de Economía y Finanzas Públicas (MEyFP).
• Ministerio de Minería y Metalurgia.
• Ministerio de Obras Públicas Servicios y Vivienda (MOPSV).
• Ministerio de Relaciones Exteriores.
• Ministerio de Salud.
• Ministerio de Trabajo, Empleo y Previsión Social (MTEyPS).
• Observatorio Agroamiental y Productivo (OAP).
• Servicio General de Identificación Personal (SEGIP).
• Servicio de Impuestos Nacionales (SIN).
• Servicio Nacional de Propiedad Intelectual (SENAPI).
• Servicio Nacional e Sanidad Agropecuaria e Inocuidad Alimentaria (SENASAG).
• Servicio Nacional de Registro y Control de la Comercialización de Minerales y Metales
(SENARECOM).
• Sistema Nacional de Información en Salud y Vigilancia Epidemiológica del Ministerio
de Salud (SNIS-VE).
• Universidad Técnica de Oruro (UTO).
• Yacimientos Petrolíferos Fiscales Bolivianos (YPFB).
• Guery Salcedo (Sociedad civil).
• Rodrigo Chumacero (Sociedad civil).
• Amilkar Conterras Castro (Sociedad civil).
• Daniel Revilla Alba (Sociedad civil).
• Alicia Estrada Cava (Comunidad de Software Libre Bolivia).

Como resultado de las reuniones de trabajo del Grupo de Software Libre, sus respectivas
discusiones y exposiciones, se elaboró el documento “Lineamientos de desarrollo y gestión
de software en las entidades públicas del Estado Plurinacional de Bolivia”.

8
2 MARCO NORMATIVO REFERENCIAL
La elaboración del presente documento se enmarca en el mandato institucional respaldado
por:
• Decreto Supremo N° 2514 que en su Disposición Final Primera incorpora el inciso t)
en el Artículo 22 del Decreto Supremo Nº 29894, de 7 de febrero de 2009, de
Organización del Órgano Ejecutivo, que establece que: “el Ministerio de la Presidencia
es el ente rector de Gobierno Electrónico y de Tecnologías de Información y
Comunicación para el sector público del Estado Plurinacional de Bolivia, siendo el
encargado de establecer las políticas, lineamientos y normativa específica para su
implementación, seguimiento y control”.
• El Artículo 2 del Decreto Supremo N° 2514 sobre la creación de la Agencia de
Gobierno Electrónico y Tecnologías de Información y Comunicación - AGETIC, como
“una institución pública descentralizada de derecho público, con personalidad jurídica,
autonomía de gestión administrativa, financiera, legal y técnica y patrimonio propio,
bajo tuición del Ministerio de la Presidencia”.
• Lo señalado en los artículos 9, 10 y 11 del Decreto Supremo N° 2514 sobre la
creación del Consejo para las Tecnologías de Información y Comunicación para
formular y presentar propuestas de políticas, normativa, programas y proyectos de
Gobierno Electrónico y Tecnologías de Información y Comunicación por parte de
entidades del ámbito gubernamental.
El marco normativo concerniente a la temática incluye:
• Decreto Supremo Nº 3251 de 12 de julio del 2017, que aprueba el Plan de
Implementación de Software Libre y Estándares Abiertos.

3 OBJETIVO
El presente documento tiene como objetivo establecer lineamientos para la gestión y
desarrollo de software en las entidades públicas del Estado Plurinacional de Bolivia.

4 ALCANCE
El presente documento formula lineamientos y buenas prácticas para el ciclo de vida de
desarrollo de software, incluyendo análisis, diseño, codificación, pruebas, mantenimiento,
contratación y publicación en el Repositorio Estatal de Software Libre. De la misma manera,
para el desarrollo de software por terceros.
Los lineamientos contenidos en este documento deberán ser asumidos por todas las
entidades del sector público, sin perjuicio del trabajo desarrollado por aquellas que hayan
asumido como parámetros rectores, normas y estándares nacionales e internacionales
vigentes o de otra naturaleza en materia de desarrollo de software.

9
5 TÉRMINOS Y DEFINICIONES
Software libre.
Según el Decreto Supremo N.º 1793, se define el software libre como el software licenciado
por su autor, bajo una licencia de código fuente abierta, de manera tal que permita al usuario
el ejercicio de las siguientes libertades:
• Ejecutar el software, para cualquier propósito, sin restricción alguna;
• Estudiar cómo funciona el software y modificarlo para que cumpla un determinado
propósito, a través del acceso al código fuente del mismo y todos los componentes
que hacen posible su funcionamiento. El acceso al código fuente es una condición
necesaria e imprescindible;
• Redistribuir copias del software;
• Distribuir copias de las versiones modificadas a terceros. El acceso al código fuente es
una condición necesaria e imprescindible.
Usabilidad.
“La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido,
usado y ser atractivo para el usuario, en condiciones específicas de uso” (ISO/IEC 9126).
“Usabilidad es la eficiencia y satisfacción con la que un producto permite alcanzar objetivos
específicos a usuarios específicos en un contexto de uso específico” (ISO/IEC 9241).
Accesibilidad.
“Capacidad de los sistemas de ajustar la interfaz de usuario, el entorno de aprendizaje, y de
localizar los recursos y las propiedades de los mismos, con la finalidad de adaptarse a las
necesidades y preferencias del usuario de modo que los contenidos sean proporcionados del
modo más cómodo posible para éste” (ISO/IEC 24751).
Desviación de un proyecto.
Se utiliza para expresar la separación con respecto a la línea base del plan de un proyecto.
Autenticación.
De acuerdo al IBM Knowledge Center, la autenticación es la capacidad de demostrar que un
usuario o una aplicación es realmente quién dicha persona o aplicación asegura ser.
Rdbms.
Según el GlosarioIT, un RDBMS (Relational Database Management System), es un Sistema
de Gestión de Bases de Datos Relacionales o, lo que es lo mismo, distintas fuentes de datos
relacionadas entre sí para obtener un mayor rendimiento.
Microservicios.

10
De acuerdo a OpenWebinars, si bien no existe un estándar o definición formal para los
microservicios, hay ciertas características que ayudan a identificarlos. Básicamente el
desarrollo de un proyecto que se base en este método conforma una aplicación o
herramienta mediante la conjunción de diversos servicios independientes que se despliegan
según se vayan necesitando. Por tanto, tendremos una aplicación modular a base de
“pequeñas piezas”, que podremos ir ampliando o reduciendo a medida que se requiera.
Timestamp.
“El timestamp es una secuencia de caracteres que representa una fecha y/u hora
específicas. El timestamp es el tiempo en que un evento es guardado por una computadora,
no el tiempo del evento en sí mismo” ( http://www.alegsa.com.ar/Dic/timestamp.php )
Encapsulamiento.
“En programación Modular, y más específicamente en programación orientada a objetos, se
denomina Encapsulamiento al ocultamiento del estado, es decir, de los datos miembro de un
objeto de manera que sólo se pueda cambiar mediante las operaciones definidas para ese
objeto.
El aislamiento protege a los datos asociados de un objeto contra su modificación por quien
no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.”
(https://es.wikipedia.org/wiki/Encapsulamiento_(informática) )

6 LICENCIA SOFTWARE LIBRE LPG BOLIVIA

Cualquier software que se publique en el Repositorio Estatal de Software Libre, tiene que
estar bajo la Licencia Pública General publicada por la Agencia para el Desarrollo de la
Sociedad de la Información en Bolivia (ADSIB) publicada en el enlace
https://softwarelibre.gob.bo/

7 DESARROLLO DE SOFTWARE PARA EL ESTADO

7.1 Proyecto de desarrollo de software

Un proyecto de desarrollo de software es un esfuerzo temporal con principio y final que se
lleva a cabo para crear un producto, servicio y/o resultado. El resultado de un proyecto es un
sistema complejo, integrado por: hardware, software, personal entrenado, normas, entre
otros.

11
7.2 Estructura básica de un proyecto
Según la guía PMBOK 1 los proyectos varían en tamaño y complejidad y pueden configurarse
dentro de la siguiente estructura del ciclo de vida de un proyecto de software: inicio,
organización y preparación, ejecución del trabajo y cierre.
7.2.1 Inicio
La fase de inicio es crucial en el ciclo de vida del proyecto, ya que es el momento de definir el
alcance y proceder a la selección del equipo. Sólo con un ámbito claramente definido y un
equipo especializado, se puede garantizar el éxito. Es además, el momento de compartir la
visión con las partes interesadas y buscar su compromiso y apoyo.
7.2.1.1 Objetivos de la fase de inicio
• Definir los límites y el alcance.
• Alinear las expectativas de las partes interesadas con el propósito del proyecto.
7.2.1.2 Actividades
Como actividades de esta fase se sugiere las siguientes:
1. Elaboración del caso de negocio/plan de proyecto.
2. Estudio de viabilidad.
3. Definición de proyecto.
4. Designación del equipo de proyecto.
5. Revisión de la fase.
7.2.2 Planificación
Ésta es a menudo la fase más difícil para una organización, ya que tiene que hacer un
importante esfuerzo de abstracción para calcular las necesidades de personal, recursos y
equipo que habrán de precaverse para lograr la consecución a tiempo y dentro de los
parámetros previstos. Asimismo, también es necesario planificar comunicaciones, contratos y
actividades de adquisición.
Como producto de esta etapa, se tendrán uno o más documentos, en los cuales de exprese
el resultado de cada una de las actividades realizadas. Ver en anexo el contenido mínimo del
documento para el proyecto de software.
7.2.3 Objetivos de la fase de planificación
Los objetivos de esta fase es establecer el alcance total del esfuerzo, definir y refinar los
objetivos, planear el curso de acción necesario para alcanzar dichos objetivos, prever qué
documentación se utilizará para llevar a cabo el proyecto y a la vez planificar
comunicaciones, contratos y actividades de adquisición.

1 PMBOK – Project Management Body of Knowledge / Project Management Institute (PMI) 6ta versión.

12
7.2.3.1 Actividades que tienen lugar durante la etapa de planificación
Como actividades de esta fase se sugiere las siguientes:
1. Elaborar el plan de proyecto inicial.
2. Plan de comunicación.
3. Plan de gestión de recursos.
4. Plan de gestión financiera.
5. Plan de gestión de calidad.
6. Proyecto de Análisis de Riesgos.
7. Plan de aceptación.
8. Plan de compras y gestión de proveedores.
9. Revisión de la fase.
O todo lo que la institución considere pertinente para cumplir con esta fase.
7.2.4 Ejecución
En base a la planificación, habrá que completar las actividades programadas, con sus tareas,
y proceder a la entrega o valoración de los productos intermedios. Es importante velar por
una buena comunicación en esta fase para garantizar un mayor control sobre el progreso y
los plazos. Asimismo, es indispensable monitorear la evolución del consumo de recursos,
presupuesto y tiempo, para lo que suele resultar necesario apoyarse en alguna herramienta
de gestión de proyectos. En esta etapa se deben gestionar: el riesgo, el cambio, los eventos,
los gastos, los recursos y el tiempo.
7.2.4.1 Objetivos de la fase de ejecución
Los objetivos son reforzar la comprensión de la meta de proyecto y los objetivos específicos
por parte de todos los participantes, fomentar la buena comunicación entre las distintas
partes interesadas, asegurar la aceptación del proyecto y cumplir con los plazos fijados en
las condiciones estimadas de uso de recursos y presupuesto, entregando productos de
calidad.
7.2.4.2 Actividades durante la etapa de ejecución
a) Asignar paquetes de trabajo asociados a cada actividad a todos los miembros del
equipo: es importante que las explicaciones sean claras y suficientes pero sin entrar
en excesivo detalle.
b) Coordinar actividades y recursos: en función de las prioridades establecidas y
observando las dependencias marcadas en el programa.

13
 c) Acatar los hitos y plazos para cada evento o entrega de productos intermedios:
evitando retrasos que puedan afectar negativamente a otras actividades o al curso
global del proyecto.
d) Monitorear el consumo de presupuesto: tratando de economizar y sin superar las
previsiones planeadas, llevando a cabo un control de gastos adecuado.
e) Hacer un seguimiento del uso de los recursos.
f) Controlar la relación entre tiempo consumido y proporción de proyecto completado
g) Detectar desviaciones en la planificación
h) Informar sobre las desviaciones detectadas.
i) Implementar acciones correctoras o modificaciones.
j) Controlar y gestionar los cambios.
7.2.5 Seguimiento y control
Esta fase comprende los procesos necesarios para realizar el seguimiento, revisión y
monitoreo del progreso de proyecto. Se concibe como el medio para detectar desviaciones
con la máxima premura posible, para poder identificar las áreas en las que puede ser
requerido un cambio en la planificación. La etapa de seguimiento y control se encuentra
naturalmente asociada a la de ejecución, de la que no puede concebirse de forma separada,
aunque por su importancia y valor crítico para el proyecto, en este lineamiento se trata de
manera independiente.
7.2.5.1 Objetivo de la fase de seguimiento y control
Los objetivos son detectar desviaciones, actualizar el plan de gestión del riesgo, prever las
medidas correctoras a tomar en cada caso y preparar un plan de contingencias.
7.2.5.2 Actividades durante la etapa de seguimiento y control
a) Actualización y seguimiento de los instrumentos de gestión de proyecto.
b) Definición y establecimiento de los indicadores clave de gestión que aportarán
métricas sobre las variables más relevantes a controlar.
c) Monitorear los indicadores clave de gestión.
d) Comunicación de desviaciones.
e) Planificación y puesta en marcha de acciones correctoras.
f) Creación de un plan de contingencias.
g) Lista de comprobación (Checklist) de revisiones de cada fase.

14
7.2.6 Cierre
Esta fase comprende todos los procesos orientados a completar formalmente el proyecto y
las obligaciones contractuales inherentes. Una vez terminado este estado, se establece
formalmente que el proyecto ha concluido.
7.2.6.1 Objetivos de la fase de cierre
Los objetivos de esta fase son lograr la aceptación de los entregables y obtener la firma de
los documentos de cierre.
Las actividades que tienen lugar durante la etapa de cierre:
a) Evaluar cada actividad y fase del proyecto.
b) Hacer una valoración del proyecto en su conjunto.
c) Llegar a acuerdos con el cliente sobre todos los puntos a tratar.
d) Formalizar la aceptación del proyecto.
e) Transmitir la información, transferencia tecnológica y formación complementaria
acordada.
f) Organizar la salida de los equipos de trabajo.
g) Entregar la documentación del proyecto al cliente.
h) Fase de transferencia tecnológica.
Los documentos esenciales durante esta etapa son:
• Informe de cierre de proyecto.
• Revisión post implementaciones.
• Aceptación y entrega de proyecto.
• Documentación entregable al cliente y materiales de carácter formativo e informativo.
Las fases presentadas anteriormente pueden ser evaluadas por cada institución, y aplicarlas
a los proyectos dependiendo del tamaño y alcances del mismo. De tal manera que se
garantice que el proyecto cuente con lo mínimo de planificación y control.

7.3 Desarrollo de software

Es necesario que se pueda establecer directrices y políticas que establezcan un marco de
desarrollo y gestión de software en el Estado Plurinacional de Bolivia, por tal razón, en este
punto se detallan recomendaciones para un desarrollo de software orientado a la calidad bajo
las mejores metodologías y buenas prácticas.
Para poder realizar el desarrollo de software, se tiene que tomar en cuenta los siguientes
lineamientos:

15
7.3.1 Accesibilidad y Usabilidad
La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado
y ser atractivo para el usuario, en condiciones específicas de uso. 2 3
La usabilidad no puede ser definida como una característica intrínseca del software.
Contempla la relación entre el programa y el usuario. Por la misma razón, se puede indicar
que poder obtener la implementación de un software accesible y usable se tienen que
considerar las siguientes recomendaciones:
• Sencillez. Debe ser de fácil utilización e intuitivo para el usuario.
• Portabilidad. Debe poder funcionar bajo distintas plataformas según corresponda.
• Balance. Los controles de la interfaz deben estar distribuidos de manera que se
aproveche al máximo el espacio visual disponible, manteniendo una navegación
clara y sencilla.
• Regularidad. Todos los controles deben mantener el mismo estilo visual en toda la
aplicación.
• Proporcionalidad. Se deben ajustar los controles de la interfaz para que tengan el
mismo tamaño.
• Secuencialidad. Los controles deben estar ordenados de manera secuencial, tanto
de manera visual como de identificación para el manejo mediante teclado, cuando
corresponda.
La información que el software presente al usuario tiene que estar basada en los siguientes
puntos:
• El software en todo momento, debe mostrar al usuario en qué lugar se encuentra
(mapa de navegación).
• Las opciones del sistema tienen que reflejarse en un menú claro, simple y accesible
en todo momento
• Presentar ayudas contextuales para cada acción y tiempo de espera en caso de
procesos cuando corresponda.
• En caso de utilizar medios multimedia se tienen que mostrar controles de audio y
reproducción para que el usuario pueda modificar su comportamiento.
• El tipo de fuente debe ser uniforme a lo largo del sistema.
• Las imágenes e íconos deben ser descriptivos y coherentes para su objetivo y
función.

2 Ver ISOIEC 25010:2011.

3 Ver Speicher et al., 2015 – arXiv:1502.06792.

16
Sobre la redacción del texto en las interfaces:
• El texto debe utilizar un lenguaje formal.
• Se deben considerar los criterios de redacción: precisión, brevedad y claridad.
• El texto debe aplicar correctamente las reglas gramaticales y semánticas del idioma
utilizado.
• El empleo de siglas deberá mostrar ayudas contextuales presentando el significado
completo de las mismas, cuando corresponda.
• El software debe tener la posibilidad de mostrar traducciones en los lenguajes
necesarios, cuando corresponda.
• Los textos de ayuda dirigidos al usuario deben ser redactados de forma impersonal.
• Utilizar términos técnicos cuando sean estrictamente necesarios y mostrar ayudas
contextuales mostrando una breve explicación de los mismos, cuando corresponda.
• Se debe diferenciar visiblemente los títulos de las secciones y contenidos.
• El contraste de colores tiene que permitir la visualización y lectura adecuada del
contenido.
Sobre los reportes:
• Brindar herramientas de filtrado de resultados, cuando corresponda.
• Permitir la posibilidad de imprimir el contenido.
• Permitir la posibilidad de exportar el contenido a formatos abiertos conforme a la
guía de datos abiertos de la CTIC.
7.3.2 Disponibilidad
La disponibilidad se considera al porcentaje de tiempo que un sistema es capaz de realizar
las funciones para las que está diseñado, para poder medir la misma se utiliza la siguiente
formula:
Porcentaje de disponibilidad = (tiempo transcurrido – tiempo de baja del sistema) / tiempo
transcurrido.
Debe tomarse en cuenta que el nivel de disponibilidad depende del contexto del sistema y de
la entidad, en este referido no es lo mismo que el sistema de registro de ingresos tenga una
disponibilidad de 99,9% que el sistema de gestión documental.
Cuando corresponda, la disponibilidad del software debe ser 24/7/365.

17
7.3.3 Obsolescencia del software
El software debe desarrollarse tomando en cuenta los estándares abiertos para mantener la
compatibilidad con los estándares y así evitar la discontinuidad de la tecnología.
Al elegirse la tecnología a ser empleada, se tiene que tomar en cuenta la comunidad que
mantiene las revisiones de tecnología como de seguridad.
7.3.4 Interoperabilidad
Todo software desarrollado debe contar con mecanismos que permitan el intercambio de
datos con otros sistemas en el marco de Gobierno Electrónico a ser establecidos por el
documento de interoperabilidad de CTIC.
7.3.5 Arquitecturas de software
Dependiendo del tamaño y alcance del sistema cada Entidad del estado puede decidir el tipo
de arquitectura que requiera. A continuación se sugiere las siguientes arquitecturas:
• Arquitecturas orientadas a microservicios.
• Arquitecturas en capas.
• Monolíticas.

7.4 Metodologías para el desarrollo del software.

Se recomienda que todo desarrollo de software sea llevado adelante aplicando una
metodología que oriente el trabajo, debiendo ser elegida en función a las características del
proyecto y la entidad que llevará adelante el proceso.
A continuación se listan los tipos de metodologías de desarrollo de software recomendadas:
• Metodologías Estructuradas
• Metodologías Ágiles

7.5 Código Fuente

7.5.1 Manejo de código fuente
El código fuente de un proyecto de software desarrollado en cualquier Entidad Pública debe
estar presente en el Repositorio de Software Estatal, el cual debe contener la última versión
del sistema, su documentación y respaldos en medios físicos cuando sea pertinente.
7.5.1.1 Control de Versiones
Es un componente dentro de la Gestión de Configuración de Software (SCM), este se refiere
al manejo de cambios sobre los elementos del software. Estos cambios se identifican por un
código usualmente denominado “número de revisión” o “versión” simplemente. Cada versión
esta asociada a una fecha de modificación y al usuario que realizó el cambio. Las versiones
pueden ser comparadas, restauradas y en algunos casos unidas.

18
Para tener un adecuado control de versiones es recomendable utilizar un Sistema de Control
de Versiones , que permita gestionar ramas de código, el mezclado de versiones y una
gestión distribuida de versiones.
Se recomienda manejar al menos dos ramas principales, una que contenga todas las
versiones puestas en producción y otra que permita integrar todas las nuevas
funcionalidades para su posterior puesta en producción.
7.5.2 Documentación del software
Para los participantes de un proyecto, contar con documentación es algo necesario. La
documentación ayuda a mantener el seguimiento de todos los detalles de una aplicación y
está directamente relacionada con la calidad del mismo. Su principal objetivo es el desarrollo,
mantenimiento y transferencia de conocimiento a otros desarrolladores o actores del
proyecto. Una documentación exitosa permitirá que la información sea fácilmente accesible,
permitiendo que los nuevos actores del proyecto puedan aprender rápido.
7.5.2.1 Documentación mínima de un proyecto
1. Modelo de datos, se basará en lo establecido en el punto de Base de Datos, como
se especifica en el punto 3 del presente documeto.
2. Documentación del código. Todo el código desarrollado deberá ser debidamente
comentado y permitir la generación automática de la documentación con alguna
herramienta. Dando prioridad a los segmentos de código críticos del proyecto.
3. Manual técnico. Deberá contener:
a) Instrucciones paso a paso de la instalación del producto software.
b) Instrucciones paso a paso de la configuración de la solución.
c) Requerimientos técnicos de acuerdo al ambiente donde se instale.
d) Tecnologías utilizadas y cómo instalarlas, así como las versiones estables para el
funcionamiento de las mismas.
e) Mención a casos especiales, como complementos, librerías, servicios de terceros
u otros.
f) Se deberán tomar en cuenta la documentación referente a al menos dos
ambientes, el de desarrollo y producción
4. Manuales de Usuario. Deberá contener de forma explicativa la funcionalidad del
sistema por cada perfil/rol establecido para el proyecto.
5. Diccionario de datos. Se deberá elaborar el diccionario de la estructura completa
de la base datos (campos, tablas, relaciones, esquemas) dependiendo de la
naturaleza de la base de datos usada en el proyecto.

19
7.5.2.2 Documentos técnicos del sistema
Arquitectura de software. Se tiene que realizar una breve descripción de la Arquitectura de
software que se utilizará en el proyecto. De esta manera los actores del proyecto podrán
conocer los detalles de dicha arquitectura y tenerla en mente en el momento del desarrollo.
Requisitos del software. Según la ISO/IEC 1233, cada requisito debe contener
explícitamente los criterios de un requerimiento bien formado. Un requerimiento bien formado
es una declaración de la funcionalidad del sistema que puede ser validada, y que debe ser
poseído por el sistema para resolver el problema de un cliente o lograr el objetivo del cliente,
y que está calificado por condiciones medibles y delimitado mediante restricciones. El cual
debe contener:
• Capacidades. Requerimientos fundamentales del sistema y representan las
características o funciones del sistema requerido por el cliente. Una capacidad debe
usualmente ser enunciada de tal manera que describa lo que el sistema debe hacer.
• Condiciones. Atributos y características medibles, cualitativa o cuantitativamente, que
son estipulados para una capacidad. Permiten calificar una capacidad necesaria, y
proporciona atributos que permiten que una capacidad sea formulada y enunciada de
tal manera que pueda ser validada y verificada.
• Restricciones. Requerimientos que son impuestos sobre la solución por
circunstancias, por la fuerza o por compulsión. Limita absolutamente las opciones
abiertas al diseñador de la solución imponiendo límites inamovibles.
Flujos de procesos. Mediante la utilización de diagramas UML se necesita que representen
los flujos de proceso y se complete un diagrama por cada flujo de proceso. De esta manera
se podrá tomar decisiones de simplificación de procesos antes de comenzar la codificación
del sistema.
Código fuente. El código desarrollado debe estar debidamente comentado, ser descriptivo y
permitir la generación de la documentación con alguna herramienta.
Se recomienda que todos los archivos cuenten con:
• Nombre del Proyecto.
• Sistema.
• Componente.
• Módulo.
• Fecha de creación.
• Autor o autores.
• Descripción de la funcionalidad.

20
 • Cronología de modificación(Número, Fecha, Autor y la descripción de la
modificación).
Cada método tendrá comentarios paramétricos.
• Descripción del método.
• Descripción de los parámetros de entrada.
• Descripción de las salidas.
Esto se aplica tanto a código de lenguaje y código de programación de base de datos.
Base de datos. Sobre la documentación necesaria para la base de datos se detalla en el
punto 3.3.1.6 del presente documento.

7.6 Pruebas
La Generación de pruebas debe realizarse desde la creación del código con pruebas
unitarias. Adicionalmente se deben realizar pruebas de funcionalidad, pruebas de integridad y
pruebas de estrés.
Estas pruebas generalmente son escritas y ejecutadas por los desarrolladores para asegurar
que el código cumple las condiciones y se comporta de la manera esperada.
7.6.1 Pruebas unitarias
Es el método por el cual piezas individuales del código son probadas, en programación
funcional es común realizar estas pruebas a las funciones y procedimientos, en tanto que en
programación orientada a objetos, es común realizar las pruebas a las clases.
Estas pruebas generalmente son escritas y ejecutadas por los desarrolladores, para asegurar
que el código cumple las condiciones y se comporta de la manera esperada.
7.6.1.1 Ventajas
Detección temprana de problemas
El proceso de escribir las pruebas obliga al desarrollador a pensar detalladamente en las
entradas y en las salidas que desea obtener, esto permite definir de una mejor manera el
comportamiento de la unidad puesta a prueba
Refactorización de código
Al tener pruebas unitarias se pueden realizar actualizaciones y correcciones al código, en el
caso de algún cambio indeseado en la funcionalidad las pruebas unitarias muestran los
errores.
Sin pruebas unitarias no se podría realizar la refactorización de código porque sería un nuevo
desarrollo sin algo que medir si funciona como el anterior o no.

21
Corrección de errores
Al encontrar un error en el sistema, el mismo después de ser corregido, es agregado como
una prueba unitaria, esto evita volver a incurrir en el error al realizar modificaciones
posteriores en el sistema.
7.6.2 Pruebas de integración
Son aquellas que comprueban el funcionamiento del sistema, mediante la verificación de la
correcta interacción entre 2 o más módulos de un sistema. Estas pruebas se realizan
posteriormente a las pruebas unitarias.
Si una prueba de integración falla la causa puede estar atribuida al entorno y no
necesariamente al código.
7.6.3 Pruebas de estrés
Están orientadas a probar el rendimiento bajo situaciones extremas como ser: alta
concurrencia de peticiones y tiempo reducido entre peticiones, el objetivo de este tipo de
pruebas es evaluar el comportamiento del proyecto de software bajo las circunstancias antes
mencionadas.
Para que estas pruebas sean efectivas se debe considerar:
• Utilizar la misma configuración de hardware, sistema operativo y versión de sistema
operativo.
• Utilizar la misma configuración de Red.
• Realizar las pruebas en cada reinicio del servidor o cambio de configuración.

7.7 Auditoría de sistemas

Todos los sistemas deben tener mecanismos que permitan su auditoría correspondiente:
7.7.1 Almacenamiento de actividad en base de datos
Para efectos de auditoría, todas las tablas del sistema tienen que contar mínimamente con
campos de control que permita la trazabilidad de cambios.
En este sentido se sugiere que cada tabla de una Base de datos cuente con los siguientes
campos adicionales:
1. Usuario aplicación
2. Fecha y hora de creación del registro
3. Fecha y hora de modificación del registro
4. Usuario base de datos (deseable)
5. Puntero de trazabilidad (deseable)

22
Esto se completa con una tabla centralizada que permite guardar el historial de cambios de
cada uno de los registros. Esta tabla contendría los siguientes campos:
1. Puntero de trazabilidad
2. Objeto de base de datos modificado
3. Operación
4. Valor anterior
5. Valor nuevo o actual
6. IP servidor aplicaciones
7. IP cliente
8. Usuario de base de datos
9. Usuario de aplicación
10. Fecha de modificación (timestamp)
Esta tabla sólo deberá tener permisos de inserción. Lo cual permitirá tener una trazabilidad
sobre las tablas, modificaciones y accesos que se hubieran realizado.
7.7.2 Almacenamiento de actividad en servidores remotos
Es recomendable que la información utilizada en el punto anterior debe ser enviada a un
servicio externo a la aplicación, que pueda centralizar y proveer informes sobre cualquier
cambio de información en registros, permitiendo su validación y trazabilidad.
7.7.3 Manejo de errores y reporte de incidencias
La entidad debe contar con un procedimiento para el registro, control y seguimiento de las
incidencias o errores reportados.
Toda aplicación debe realizar el encapsulamiento de las excepciones, para poder desplegar
al usuario un mensaje claro y no exponer información critica, internamente debe proceder
con el registro centralizado (Base de datos o archivos de registro de eventos) y
almacenamiento de información suficiente para poder identificar las causas.
Debe registrar:
• Nombre o código de la Aplicación.
• Módulo que generó la excepción.
• Pila de seguimiento de error.
• Fecha y hora.
• Usuario de la aplicación.
• IP del servidor de aplicaciones.

23
Se debe contar con un módulo de visualización de las excepciones generadas por los
diferentes aplicativos para poder realizar la atención y corrección de los mismos.

7.8 Calidad y aseguramiento del Software

De acuerdo a la ISO 9001, la calidad es la capacidad de un producto de software de cumplir
con los requerimientos establecidos en la lista de requerimientos del software.
El proceso de Aseguramiento de la Calidad del Software, SQA (por sus siglas en ingles,
Software Quality Assurance), tiene por objetivo garantizar la calidad en los procesos de
ingeniería de software, para que el producto de software satisfaga los requisitos de sus
clientes y/o usuarios.
El proceso de SQA es el responsable de la aprobación de los productos y de establecer
acciones correctivas y preventivas; aunque es posible considerar que todo esto está incluido
dentro del plan de calidad del cual será responsable SQA de llevar a cabo. De esta manera
se logrará tener un producto técnicamente bueno pero que al mismo tiempo satisfaga al
cliente. El objetivo principal es la satisfacción del cliente, nunca y bajo ningún concepto debe
perderse de vista esta premisa.
La tarea fundamental del aseguramiento de calidad del software es exigir que se cumplan
todas las normas y estándares establecidos para asegurar el buen fin del proyecto.
Las pruebas de aseguramiento de calidad de software revisa:
• Ejecución de Pruebas.
• Documentación del proyecto.
◦ Flujos vs realidad.
• Estándares de desarrollo y buenas prácticas.

7.9 Seguridad
Para el aseguramiento de la seguridad en aplicaciones software se deben cumplir y aplicar
los criterios establecidos por el documento de seguridad de CTIC. Además de considerar los
criterios de la seguridad de la información como la confidencialidad, integridad y
disponibilidad:
7.9.1 Confidencialidad.
La confidencialidad es la propiedad que impide la divulgación de información a individuos,
entidades o procesos no autorizados. A grandes rasgos, asegura el acceso a la información
únicamente a aquellas personas que cuenten con la debida autorización. Las
consideraciones que se deben tomar en una aplicación software son:
• Clasificación de la información en los tipos Pública, Privada y Confidencial
• Control de acceso por interfaz

24
 • Gestión de sesiones
• Roles de permisos a interfaces y datos
• Transacciones por canales seguros SSL
7.9.2 Integridad
Es la propiedad que busca mantener los datos libres de modificaciones no autorizadas. Es
mantener con exactitud la información tal cual fue generada, sin ser manipulada ni alterada
por personas o procesos no autorizados. Las consideraciones que se deben tomar en una
aplicación software son:
• Control de Permisos de usuario a modificación o eliminación de datos.
• Trazabilidad, registro de transacciones considerando mínimamente usuario, fecha y
hora, descripción de la tarea realizada.
• Acceso a base de datos distinguiendo el IP y usuario específico.
• Separar datos históricos de datos activos o transaccionales, donde los históricos no
se debieran modificar.
7.9.3 Disponibilidad
La disponibilidad es la característica, cualidad o condición de la información de encontrarse a
disposición de quienes deben acceder a ella, ya sean personas, procesos o aplicaciones. Es
el acceso a la información y a los sistemas por personas autorizadas en el momento que así
lo requieran. Las consideraciones que se deben tomar en una aplicación software son:
• Respaldos periódicos de bases de datos y aplicativos de acuerdo a su criticidad.
• Procedimientos de restauración de respaldos y pruebas del mismo.

7.10 Mantenimiento del software.

Se entiende por Mantenimiento de Software a la modificación de un producto de software
posterior a la entrega del mismo, puede ser por:
Corrección de errores.
• Mejoramiento de funcionalidad.
• Adición de funcionalidad.
• Otros.
El mantenimiento se puede clasificar como:
• Adaptación.- Modificar el sistema por cambios en la lógica de negocio o ambiente del
software.

25
 • Perfección.- Implementar nuevos o modificar requerimientos de usuario referidos a
mejoras funcionales.
• Correctivo.- Diagnóstico y corrección de errores.
• Preventivo.- Modificar el sistema para aumentar la disponibilidad, usabilidad,
integridad y así evitar errores futuros.
7.10.1 Refactorización de código
Dentro de la etapa de mantenimiento de código se puede ver conveniente refactorizar el
código para mejorar rendimiento en tiempo y utilización de recursos. Es importante contar
con pruebas unitarias para tener un base de comparación del trabajo antes y después de la
modificación, de la misma manera nos permitirá saber si el nuevo código cumple con los
requerimientos que el anterior cumplía.

8 IMPLEMENTACIÓN Y GESTIÓN DE BASE DE DATOS

La base de datos es un activo intangible muy importante dentro de la Entidad, por lo que es
importante que se definan lineamientos para garantizar su manejo.

8.1 Implementación de base de datos

Para la implementación de una base de datos se debe seguir los siguientes puntos:
8.1.1 Gestor de base de datos
La elección del gestor de base de datos, es deseable que pueda cumplir con las siguientes
características, dependiendo del requerimiento del software.
• Manejo de roles de usuario
• Permisos por tablas
• Manejo de esquemas
• Funciones y/o procedimientos almacenados
• Manejo de Logs a nivel de base de datos
• Soporte de mb-UTF-8
• Alta disponibilidad
• Portabilidad
8.1.2 Políticas de Seguridad de la base de datos
• Definir políticas de seguridad que permitan resguardar los datos a nivel de usuarios
y accesos.
• Accesos a la base de datos, puertos e interfaces.

26
 • Accesos diferenciados por usuarios
8.1.3 Documentos generados:
Al finalizar la etapa de diseño tenemos que contar con los siguientes documentos:
• Detalle de Usuarios y Roles.
• Lenguaje de manipulación de datos (DML).
• Lenguaje de definición de datos (DDL).

8.2 Gestión de base de datos

8.2.1 Respaldos
Es importante realizar un plan de respaldos de la base de datos, estos respaldos pueden ser
copias de la base de datos que se guardan separadas una de otras, o pueden ser
incrementales.
En ambos casos, es necesario realizar pruebas de restauración de la base de datos en
ambientes de prueba para garantizar que el respaldo es válidos y se realizó sin errores.
De acuerdo a la magnitud e importancia de la información contenida en cada base de datos
se debe establecer :
• El tiempo del respaldo.
• Lugar de almacenamiento.
• Tiempo de almacenamiento.
• Pruebas de recuperación.
Otros aspectos que se tienen que tomar en cuenta:
Identificar los eventos (amenazas) que puedan ocasionar interrupciones en los procesos de
las actividades, por ejemplo, fallas en el equipamiento, comisión de ilícitos, interrupción del
suministro de energía eléctrica, inundación e incendio, desastres naturales, atentados, etc.
Evaluar los riesgos para determinar el impacto de dichas interrupciones, tanto en términos de
magnitud de daño como del período de recuperación.
Dicha evaluación debe identificar los recursos críticos, los impactos producidos por una
interrupción, los tiempos de interrupción aceptables o permitidos, y debe especificar las
prioridades de recuperación.
Identificar los controles preventivos, como por ejemplo sistemas de supresión de fuego,
detectores de humo y fuego, contenedores resistentes al calor y a prueba de agua.
8.2.2 Usuarios administradores
Al gestionar la base de datos, es importante tomar en cuenta:

27
 • Evitar usuarios administradores, por defecto, root, sys, admin.
• Definir usuarios con los mismos perfiles de un usuario administrador, para evitar el
acceso de personal no autorizado.
• Implementación de roles por usuario del software.
• Definir los eventos y actividades de usuarios a ser registrados en los sistemas de
procesamiento de su incumbencia y la periodicidad de revisión de los mismos.
• Aprobar y solicitar la asignación de privilegios a usuarios.
• Llevar a cabo un proceso formal y periódico de revisión de los derechos de acceso a
la información.
• Implementar procedimientos para la activación y desactivación de derechos de acceso
a las redes.
• Analizar e implementar los métodos de autenticación y control de acceso definidos en
los sistemas, bases de datos y servicios.
• Determinar los controles de accesos, autenticación y utilización a ser implementados
en cada caso.
• Implementar el control de puertos, de conexión a la red y de ruteo de red.
• Implementar el registro de eventos o actividades de usuarios de acuerdo a lo definido
por los propietarios de la información, así como la depuración de los mismos.
• Definir e implementar los registros de eventos y actividades correspondientes a
sistemas operativos y otras plataformas de procesamiento.
• Definir e implementar la configuración que debe efectuarse para cada servicio de red,
de manera de garantizar la seguridad en su operatoria.
• Analizar las medidas a ser implementadas para efectivizar el control de acceso a
Internet de los usuarios.
• Otorgar acceso a los servicios y recursos de red, únicamente de acuerdo al pedido
formal correspondiente.
• Efectuar un control de los registros de auditoría generados por los sistemas operativos
y de comunicaciones.
8.2.3 Versionamiento de la base de datos.
Se debe de hacer un versionamiento de la estructura de la base de datos ya sea esta por
herramientas externas para el llevar un mejor control de los cambios que sufre o mediante
respaldos automáticos.

28
Estos archivos tienen que tener un proceso de validación posterior al respaldo para poder
garantizar que es funcional.

8.3 Ciclo de vida de la Base de Datos

8.3.1 Diseño
Determinado por el modelo, existen estándares de diseño con nomenclaturas, en el caso de
los más comunes como relaciones se realizan los diseños con modelos Conceptuales =>
Lógicos => Físicos que permiten el entendimiento completo del negocio a partir de un Modelo
de Datos.
A continuación detallamos lineamientos importantes para el diseño de la base de datos:
8.3.1.1 Integridad del modelo
Dentro de la base de datos se almacenarán datos, que si no tenemos cuidado pueden ser
inservibles al momento de realizar las consultas requeridas y alejarse del uso requerido. En
ese sentido detallamos reglas de integridad del modelo.
8.3.1.2 Nombrado de tablas y campos
Se recomienda que el nombramiento de las tablas se considere el nombre en plural y los
campos en singular.
También se encuentra dentro los estándares (Obviamente esta aplicado a RDBMS [BD
relacionales]), hay que añadir la compatibilidad con el número de caracteres soportado por el
sistema de gestión de la base de datos.
1. Siempre usar nombres semánticos (con significado) y específicos.
2. Utilizar caracteres alfanuméricos exceptuando caracteres especiales al nombrar los
objetos de base de datos.
3. No usar espacios en los nombres de objetos de base de datos.
4. Las variables y parámetros deben describir el significado de una entidad no su tipo ni
tamaño.
5. Usar abreviaciones claras únicamente cuando la longitud del nombre sea grande.
6. Los campos restantes no deberían incorporar el nombre de la tabla en su definición.
7. Se debe contar con un diccionario de datos.
8.3.1.3 Codificación de las tablas
Dependiendo del tipo de modelo de base de datos y del gestor de base de datos, se tiene
que establecer un esquema de codificación de tablas para que el proyecto y las tablas dentro
del sistema puedan ser leídos y disciplinadamente seguido por todos los desarrolladores.
1. Utilizar UTF-8 en los nombres.

29
 2. No utilizar caracteres especiales.
3. No utilizar espacios en los nombres.
8.3.1.4 Idioma de campos
De la misma manera que en la codificación de las tablas, se tiene que definir el idioma con el
que se nombran las tablas.
1. Para los campos utilizados por el sistema, se tiene que priorizar la utilización del
idioma Español Bolivia.
2. Para los campos utilizados automáticamente por el sistema o marcos de trabajo
utilizados, se puede mantener el idioma inglés por convención.
3. Utilizar UTF-8 en los nombres.
4. No utilizar caracteres especiales.
5. No utilizar espacios en los nombres.
8.3.1.5 Procedimientos y funciones
Todo procedimiento, función o bloque anónimo debe contar con la identificación
correspondiente la misma que contendrá el Autor, Fecha de Creación y la Descripción, cada
cambio realizado al mismo debe tener la identificación del cambio.
8.3.1.6 Documentos generados
Al finalizar la etapa de diseño tenemos que contar con los siguientes documentos:
1. Modelo de datos, (Relacional o no relacional).
2. Diccionario de datos.
3. Diccionario de procedimientos y funciones.
4. Esquema de Usuarios y Roles.
8.3.2 Desarrollo
En base a los documentos de estándares y convenciones para las estructuras de base de
datos, se debe realizar la implementación física del modelo de datos (los esquemas, tablas,
índices, validación de datos, relación de tablas, parámetros a usar entre ellas, etc.), también
se realizan correcciones y validaciones de la utilidad del mismo.
Según la arquitectura para el desarrollo de software que se utilice, trabajar con convenciones
de desarrollo en base de datos, las que explicaremos más adelante.
De la misma manera es necesario definir las medidas de seguridad.
8.3.3 Evaluación y mantenimiento
Se debe realizar las pruebas correspondientes a los casos, de esta manera se asegura que
las necesidades del cliente hayan sido satisfechas.

30
9 CATÁLOGO DE SOFTWARE
El catálogo de software se constituye en un registro que describa la información mínima
necesaria de cada sistema para una correcta gestión de software.
Con este catálogo se previene la doble adquisición o desarrollo de software que contenga las
mismas características y permitirá aunar esfuerzos y proyectos.

9.1 Información mínima

La información mínima a ser registrada:
1. Nombre del sistema.
2. Descripción del sistema.
3. Plataformas de funcionamiento (Web, escritorio, móvil, otros).
4. Tipo de sistema (Desarrollo propio, adquisición, donación, comunitario).
5. Tipo de licencia (Software Libre, propietario, freeware).
6. Estado (Producción, desarrollo, pruebas, inactivo, desuso).
7. Área solicitante/responsable.
8. Versión.
9. Fecha de último Backup.
10. Número de registro SENAPI. Para desarrollo propio.
De acuerdo a la entidad, este catálogo tendrá que estar administrado y actualizado ante
cualquier nuevo proyecto.

10 CONTRATACIÓN DE DESARROLLO DE SOFTWARE DE TERCEROS

Para la contratación de desarrollo de software de terceros, previa coordinación con las áreas
de tecnología y las interesadas, se debe cumplir los siguientes puntos:

10.1 Proyecto de desarrollo de software

Es importante tomar en cuenta que cualquier desarrollo de software tiene que ser formulado
dentro de un ciclo de vida de proyecto. Tomando en cuenta las etapas de Inicio, Planificación,
Ejecución, Seguimiento, Control y Cierre, como se indica en el punto 2.2, los TDRs del
consultor están incluidos en el SRS.

10.2 Desarrollo de software

En la etapa de ejecución, el software tiene que estar desarrollado utilizando una metodología,
como se definen en el punto 2.4. De igual manera tiene que cumplir con los lineamientos de

31
Accesibilidad y Usabilidad, Disponibilidad e Interoperabilidad, contar con una Arquitectura de
software definida, como se indica en el punto 2.3.
En la etapa de ejecución del proyecto, el desarrollo de software tiene que contar con un
manejo de versiones para el código generado, como se indica en el punto 2.5.
El código generado tiene que cumplir con los requerimientos de documentación, como se
indica en el punto 2.6.
Tiene que contar con pruebas para asegurar la calidad de software como se indica en el
punto 2.7.
Sobre la seguridad, se debe cumplir los criterios de Confidencialidad, Integridad y
Disponibilidad como se indica en el punto 2.8.

10.3 Sobre la base de datos

Debe tomar en cuenta los puntos sobre Diseño, Nombrado de Tablas y campos, Campos de
Auditoría y Documentación como se menciona en le punto 3 del presente documento.

10.4 Aceptación del Producto

La aceptación del producto es una tarea que se realiza a lo largo del proyecto cada vez que
se recepciona un entregable. Esta aceptación es de dos tipos:
10.4.1 Aceptación del área de sistemas
El área de sistemas realizará una evaluación sobre el entregable, en el que verificará el
cumplimiento de las normas y estándares técnicos exigidos en el punto 5.2.
Se realizará la validación de las pruebas unitarias y de Integración para asegurar la calidad
de software como se indica en el punto 2.7.
10.4.2 Aceptación del área solicitante
El área solicitante realizará una evaluación sobre el entregable, en el que verifica que se
cumplan con los lineamientos definidos en los TDR’s como requerimientos de funcionalidad.
Tiene que cumplir y validar el documento de especificación de requisitos del Software.

10.5 Transferencia de tecnología

Para la finalización del proyecto y tener la conformidad del producto, se requiere completar
con la transferencia de tecnología que comprende:
10.5.1 Capacitación.
10.5.1.1 Capacitación técnica
El objetivo de la capacitación técnica es de poder tomar el control del proyecto una vez este
se termina, para poder realizar modificaciones o correcciones al sistema posterior a la
entrega, donde se debe realizar:

32
 1. Validación de manuales de Instalación y configuración de componentes.
2. Revisión de la estructura de base de datos.
3. Explicación de las reglas de negocio del sistema.

10.5.1.2 Capacitación de uso del sistema

El objetivo es capacitar al equipo de sistemas, encargados del sistema y personal del área
solicitante, para posteriormente poder realizar capacitaciones a los usuarios finales, donde se
realizará:
1. Validación de manuales de Usuario.
2. Detalle de funcionalidad.
3. Ejercicios de uso del sistema.

11 ABREVIATURAS Y ACRÓNIMOS
ADSIB. Agencia para el Desarrollo de la Sociedad de la Información en Bolivia
RDBMS. Sistema de Gestión de Bases de Datos Relacionales
UML. Lenguaje Unificado de Modelado
IP. Protocolo de Internet
SSL. Capa de Puertos Seguros
UTF. Formato de Transformación Unicode
DML. Lenguaje de Manipulación de Datos
DDL. Lenguaje de Definición de Datos
BD. Base de Datos
SENAPI. Servicio Nacional de Propiedad Intelectual
SRS. Especificación de Requerimientos de Software
TDRs. Términos de Referencia
ISO/IEC. Estándar para la seguridad de la información publicado por la Organización
Internacional de Normalización y la ComADSIB. Agencia para el Desarrollo de la Sociedad
de la Información en Bolivia
RDBMS. Sistema de Gestión de Bases de Datos Relacionales
UML. Lenguaje Unificado de Modelado
IP. Protocolo de Internet
SSL. Capa de Puertos Seguros

33
UTF. Formato de Transformación Unicode
DML. Lenguaje de Manipisión Electrónica Internacional.
LPG. Licencia Pública General GNU
PMBOK. Guía de los Fundamentos para la Dirección de Proyectos
CTIC-EPB. Consejo para las Tecnologías de Información y Comunicación del Estado
Plurinacional de Bolivia
SCM. Gestión de Configuración de Software
SQA. Aseguramiento de la Calidad de Software

12 ANEXO
Contenido Mínimo del documento para el proyecto de software
1. Introducción
2. Antecedentes
3. Problemática
4. Justificación
5. Objetivos
5.1 Objetivo General
5.2 Objetivos Específicos
6. Propuesta Técnica
7. Resultados esperados
8. Marco Lógico
9. Planes de actividades, cornogramas, etc.
Este punto podrá ser disgregado en otros documentos o anexos de acuerdo a su
conveniencia y naturaleza del proyecto.
10. Seguimiento, reportes de control, etc.
Este punto podrá ser disgregado en otros documentos o anexos de acuerdo a su
conveniencia y naturaleza del proyecto.
11. Resultados
11.1 Indicadores de resultado
12. Conclusiones y recomendaciones

34
 13. Anexos
Dado que es una lista del contenido mínimo, y podrían agregarse más puntos o tal vez
disgregar otros ya existentes, la numeración podría variar, sin que esta situación pudiera
afectar la naturaleza del documento.

35