Merge branch 'qa-v1.0' into 'master'

Qa v1.0



See merge request !1

doc/Est_IngenieriaRequerimientos.md

+# Políticas para la documentación de Ingeniería de Requerimientos
+
+### 1. ¿Qué son los Requerimientos?
+
+A continuación se presenta la definición que aparece en el glosario de la IEEE:
+
+(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2).
+
+Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.
+
+Los requerimientos **funcionales** definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.
+
+Los requerimientos **no funcionales** tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
+
+### 2. Características de los requerimientos
+
+Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.
+
+* **Necesario:** Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.
+
+* **Conciso:** Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
+
+* **Completo:** Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
+
+* **Consistente:** Un requerimiento es consistente si no es contradictorio con otro requerimiento.
+
+* **No ambiguo:** Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.
+
+* **Verificable:** Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.
+
+
+### 3. Documentación mínima requerida
+
+El uso de los diferentes tipos de diagramas depende mucho de la complejidad de cada proyecto, puesto que muchas veces es necesaria más información detallada para poder comprender mejor los requerimientos. Sin embargo, se define la siguiente documentación como mínima requerida para cada proyecto:
+
+> #### a. Historias de usuario
+
+> #### b. Diagrama de flujo de datos
+
+En todos los casos ess necesario que se coordine con un miembro del equipo de desarrollo designado para estas tareas.
+
+Como se explicó anteriormente, dependiendo de los requerimientos del grupo de desarrollo, podrían adicionarse los siguientes documentos:
+
+* Diagrama de Casos de uso
+* Diagrama de secuencia
+* Modelo de procesos del Negocio
+* Diagrama de Componentes
+* Diagrama de Despliegue
+* Diagrama de Estados
+* Diagrama de Actividad
+* Diagrama de Colaboración
+
+
+### 4. Estándares a seguir en la documentación
+
+Toda la documentación correspondiente a UML, deberá cumplir con los estándares vigentes de la ISO al respecto, la [ISO/IEC 19505-1] y [ISO/IEC 19505-2].
+
+
+
+[ISO/IEC 19505-1]: <http://www.omg.org/spec/UML/ISO/19505-1/PDF>
+[ISO/IEC 19505-2]: <http://www.omg.org/spec/UML/ISO/19505-2/PDF>

doc/estandares-codificacion-nodejs.md

+# Estándares de Codificación - NodeJs
+
+## Objetivo
+
+El presente documento tiene por finalidad establecer estándares de codificación para el lenguaje de programación NodeJs con la finalidad de mejorar la calidad del código desarrollado.
+
+## Alcance
+Aplicable a los sistemas desarrollados por las siguientes unidades:
+1. [nombre de las unidades que desarrollan proyectos de software]
+
+## Extensión de responsabilidad
+Si bien la finalidad del documentos es definir lineamientos para el desarrollo de productos de software la aplicación de los mismos esta sujeto al criterio de los administradores de proyectos y desarrolladores.
+
+## Referencias
+
+Los siguientes documentos son complementarios a los estándares del presente documento.
+[Código y nombre del documento Estándares de codificación]
+
+## Desarrollo
+
+Los siguientes estándares pretenden alcanzar código mantenible, se considera mantenible cuando el código es: legible, consistente, predictivo y documentado.
+La corrección de errores y modificación del código desarrollado de un producto de software toma tiempo considerable, este factor puede incrementarse si el personal que realizar esta actividad no es la misma que realizó el desarrollo o si el espacio temporal entre estas actividades es amplia.
+Otra actividad que se ve afectada por el poco cuidado en la codificación es el mantenimiento, esta actividad generalmente se realiza en la post entrega del producto de software y considerando los cambios en el equipo de desarrollo y el tiempo transcurrido puede superar el 50% del tiempo empleado en el desarrollo del producto inicial.
+
+1. Código en general
+  * Aunque JavaScript considera como final de instrucción el salto de linea “ \n ” y el carácter punto y coma “ ; ” utilizar siempre el “ ; ” como final de instrucción, esto mejora la lectura y evita conflictos con las herramientas de verificación de código.
+  * Para delimitar cadenas de texto se recomienda utilizar comillas simples con excepción de JSON y otras estructuras de datos que así lo requieran.
+
+    ```javascript
+    // Para cadenas de texto
+    var siteName = 'a great site';
+
+    // Para datos en formato JSON
+    var jsonData = {
+      "h1": "a great site",
+      "header": "you get the awesome",
+      "content":
+          {
+           "table":
+              [
+                  { "id":"1", "type":"regular1" },
+                  { "id":"2", "type":"regular2" },
+                  { "id":"3", "type":"regular3" }
+              ]
+          }
+    };
+    ```
+  * Se recomienda utilizar el operador ternario “ ? : ” siempre y cuando mejore la legibilidad de una estructura de control de comparación “if then else”.
+
+    ```javascript
+    // Sentencia tipo if then else
+    var a = 124;
+        
+    if( a > 100 ) {
+        return a * 100 - 124;
+    } else {
+        return a * 51;
+    }
+    ```
+    ```javascript
+    // Uso del operador ternario
+    var a = 124;
+        
+    return ( a > 100 ) 
+        ? a * 100 - 124 
+        : a * 51;
+
+    ```
+  * Utilizar el modo estricto “use strict” en las funciones para escribir código JavaScript seguro.
+  * Utilizar espacios en blanco entre los siguientes operadores: ( ) { } [ ] , = + - / : < > == !=%  para mejorar la legibilidad del código. 
+
+    ```javascript
+    // Codificación estándar
+    var a=124;
+        
+    if(a>100){
+        return a*100-(124/14);
+    }else{
+        return a*51;
+    }
+    ```
+    ```javascript
+    // Codificación con espacios
+    var a = 124;
+        
+    if( a > 100 ) {
+        return a * 100 – (124 / 14);
+    } else {
+        return a * 51;
+    }
+    ```
+2. Funciones / procedimientos
+  * Cuando se desarrolla funciones estas deben tener la siguiente estructura:
+    * En una función de retorno “Callback”, la variable de error debería ser el primer parámetro.
+    * La función de retorno o “Callback” debería ser el último parámetro de una función.
+    * Siempre deben tener la sentencia “return”.
+
+      ```javascript
+      var fs = new FileSystem;
+    
+      fs.readFile( '/foo.txt', readOptions, function( err, data ) {
+        // Verificar la variable de error
+        if( err ) {
+          console.log( 'Unknown Error' );
+          return;
+        }
+  
+        return data.status;
+      });
+      ``` 
+  * Cuando se invoca a una función / procedimiento que retorna una variable (callback) de error, se debe verificar este valor antes de cualquier instrucción.
+
+      ```javascript
+      var fs = new FileSystem;
+    
+      fs.readFile( '/foo.txt', readOptions, function( err, data ) {
+        // Verificar la variable de error
+        if( err ) {
+          console.log( 'Unknown Error' );
+          return;
+        }
+  
+        return data.status;
+      });
+      ```
+3. Variables
+  * Siempre se debe declarar variables con “var”.
+  * Evitar el uso del conversión de datos “type casting” implícito, cuando se realiza la comparación de variables o valores es importante utilizar el operador “===” en lugar de “==”.
+  * Se debe evitar el uso de variables globales.
+  * Guardar el estado de la variable “this” cuando cambie el contexto del código y evitar confusiones.
+
+      ```javascript
+      this.enviroment = 'title one';
+
+      // Guarda el valor de this
+      var _this = this;
+      var one = function( callback ){
+        this.enviroment = 'title two';
+        console.log( 'local env' + this.enviroment );
+        console.log( 'global env' + _this.enviroment );
+      };
+      var uno = new one();
+      ```
+4. Comentarios
+   * Utilizar el generador de documentación JSDoc.
+   * El conjunto de instrucciones que cumplen un propósito deben ser agrupadas y comentadas de ser necesario.
+5. Pruebas unitarias
+   * Se debe utilizar el framework Mocha para generar las pruebas unitarias del proyecto.
+   * Se recomienda utilizar el framework Zombie.js para generar pruebas de Comportamiento (BDD), en algunos casos también esta permitido el uso de SeleniumHQ.
+   * Los archivos de pruebas unitarias deben ubicarse en el directorio test/ del proyecto.
+   * Se recomienda tener archivos separados por cada test funcional o test unitario del proyecto.
+   * Las pruebas del documento deben estar orientados a describir el comportamiento del proyecto conforme las historias de usuarios, en 2 niveles descriptivos.
+     * 1º nivel, debe indicar el nombre de la historia de usuarios.
+     * 2º nivel, debe indicar una característica de la historia de usuario que valide su aceptación.
+
+     ```javascript
+     describe( 'Como usuario deseo ingresar al sitio con mis datos', function() {
+        before( function() {
+           this.browser = new Browser({ site: 'http://www.agetic.gob.bo/login' });
+        } );
+           
+        it( 'Ingreso con credenciales válidas', function( done ) {
+           var that = this;
+           this.browser.visit( 'http://www.agetic.gob.bo', 
+            function(err, browser) {
+                assert.ok( that.browser.success );
+            ....
+                    done();
+                } 
+           );
+        } );
+
+        it( 'Ingreso con credenciales NO válidas', function( done ) {
+           var that = this;
+           this.browser.visit( 'http://www.agetic.gob.bo', 
+            function(err, browser) {
+                assert.ok( that.browser.success );
+            ....
+                    done();
+                } 
+           );
+        } );
+
+      } );
+     ```    
+6. Refactorización y Limpieza
+   * Una vez finalizado el desarrollo se debe evaluar las funciones / procedimientos y refactorizar los que sean necesarios, posteriormente deben ejecutarse las pruebas unitarias para asegurar el funcionamiento del proyecto.
+   * Los puntos de ruptura deben estar deshabitados pero no deben ser eliminados si no mas bien comentados indicando su propósito.
+   * Las instrucciones de registro de acciones “Logging” deben ser deshabilitadas cuando el proyecto es puesto en producción.
+   * Los comentarios innecesarios deben ser eliminados.
\ No newline at end of file

doc/estandares-codificacion.md

+# Estándares de Codificación
+
+## Objetivo
+
+El presente documento tiene por finalidad establecer estándares de codificación con la finalidad de mejorar la calidad del código desarrollado.
+
+## Alcance
+Aplicable a los sistemas desarrollados por las siguientes unidades:
+1. [nombre de las unidades que desarrollan proyectos de software]
+
+## Extensión de responsabilidad
+Si bien la finalidad del documentos es definir lineamientos para el desarrollo de productos de software la aplicación de los mismos esta sujeto al criterio de los administradores de proyectos y desarrolladores.
+
+## Desarrollo
+
+Los siguientes estándares pretenden alcanzar código mantenible, se considera mantenible cuando el código es: legible, consistente, predictivo y documentado.
+La corrección de errores y modificación del código desarrollado de un producto de software toma tiempo considerable, este factor puede incrementarse si el personal que realizar esta actividad no es la misma que realizó el desarrollo o si el espacio temporal entre estas actividades es amplia.
+Otra actividad que se ve afectada por el poco cuidado en la codificación es el mantenimiento, esta actividad generalmente se realiza en la post entrega del producto de software y considerando los cambios en el equipo de desarrollo y el tiempo transcurrido puede superar el 50% del tiempo empleado en el desarrollo del producto inicial.
+
+1. **Convenciones de nombres**
+  * Los nombres de las variables / procedimientos deben representar el contenido o propósito de la misma, evitando nombres con una sola letra.
+
+    ```javascript
+    // Incorrecto
+    var l, k, q    
+    private a
+    public d
+    ```
+    ```javascript
+    // Correcto
+    var companyId
+    private emailStatus
+    public lastDocument
+    ```
+  * Los nombres de las constantes deben estar en mayúsculas y las palabras separadas por guiones bajos '_'.
+
+    ```javascript
+    // Ejemplos constantes
+    const MAX_ACCOUNT_LIMIT = 12
+    const DEFAULT_NAME = "untitled"
+    ```
+  * Los nombres de variables, clases, interfaces y procedimientos deben ser claros y concisos evitando ambigüedades.
+  * Se debe evitar nombres de variables, clases, interfaces y procedimientos extensos.
+
+    ```javascript
+    // Incorrecto
+    var the_current_user_name_of_app
+    private last_status_of_this_class
+    class CustomClassForHandlerDatabaseErrors
+    ```
+    ```javascript
+    // Correcto
+    var userName
+    private classStatus
+    class CustoDatabaseHandleErrors
+    ```
+  * El estilo para los nombres de variables / procedimientos es lowerCamelCase la cual establece que la letra inicial debe ser minúscula y las palabras siguientes deben tener la inicial en mayúsculas y el resto en minúsculas.
+
+    ```javascript
+    // Ejemplos lowerCamelCase
+    var enviroment               delete()
+    private size                 public clear()
+    var logFileName              setBodyParser()
+    private pathRootFolder       public getProductInfo()
+    ```
+  * El estilo para los nombres de clases e interfaces es UpperCamelCase la cual establece que la letra inicial debe ser mayúscula y las palabras siguientes deben tener la inicial en mayúsculas y el resto en minúsculas. 
+
+    ```javascript
+    // Ejemplos UpperCamelCase
+    class Customer
+    interface Enviroment
+    class IOErrorHandler
+    interface ErrorHandler
+    ```
+  * Evitar adicionar prefijos que indiquen el tipo de dato que contiene.
+
+    ```javascript
+    // Incorrecto                                           
+    var intCounter                                      
+    private strName                                     
+    public boolstatus   
+    ```
+    ```javascript
+    // Correcto
+    var counter
+    private name
+    public status
+    ```
+  * Los nombres de variables, clases e interfaces deben ser sustantivos y en algunos casos representar estados.
+
+    ```javascript
+    // Incorrecto                                           
+    var getItem                                         
+    private jumpValidation                              
+    class DeliverEmail
+    ```
+    ```javascript
+    // Correcto
+    var item
+    private validationStatus
+    class Email
+    ```
+  * Los nombres de los procedimientos deben tener un verbo o acción que indique su propósito o determine estados. 
+
+    ```javascript                                          
+    // Incorrecto                                           
+    userData()                                          
+    private color()                                     
+    public userSatus() 
+    ```
+    ```javascript
+    // Correcto
+    getUserData()
+    private setCustomColor()
+    public isUserEnabled()
+    ```
+  * Con la finalidad de mejorar la claridad de una variable se podrán indicar prefijos de ámbito en las variables. 
+
+    ```javascript
+    // Ejemplos ámbitos de variables
+    var localDocument         public globalEnviroment
+    ```    
+  * Con la finalidad de mejorar la claridad de una variable o procedimiento se podrán usar nombres en plural y singular.
+    
+    ```javascript
+    // Ejemplos nombres en singular y plural
+    var enviroments           private sheet
+    insertItem()              public getResults()
+    ```    
+2. **Bloques de código**
+  * Las líneas de código que están relacionadas deben estar agrupadas sin espacio entre sus líneas.
+  * La cantidad máxima de caracteres en una línea de código debería ser de 120 caracteres.
+  * Los bloques de código que pertenecen a clases, procedimientos y estructuras de control deben estar identados con 4 espacios / 1 tabulación.
+  * Los  bloques de código que pertenecen a clases, procedimientos y estructuras de control deben estar entre llaves '{' y '}'.
+3. **Procedimientos**
+  * La cantidad de líneas recomendadas para un procedimiento es de 20 salvo casos excepcionales.
+  * Cuando un procedimiento supera las 20 líneas se debe considerar la división del proceso en procesos mas pequeños siguiendo la premisa: Un procedimiento debería realizar Una tarea.
+4. **Complejidad ciclomática**
+   La complejidad ciclomática es la anidación de estructuras de control esta debe estar limitada a 4 anidaciones salvo casos excepcionales.
+5. **Parámetros**
+   Se recomienda como cantidad máxima de parámetros de un procedimiento 4, en caso de requerir enviar una mayor cantidad de parámetros, se debe analizar la posibilidad de pasar objetos como parámetros.
+
+     ```javascript
+     // Incorrecto                                           
+     public drawCube(
+        float height,
+        float width,
+        float depth,
+        int color,
+        int xPosition,
+        int yPosition
+     ){
+      ...
+     }
+     ```    
+     ```javascript
+     // Correcto
+     public drawCube(
+        cube myCube
+        int color,
+        position drawPosition
+     ){
+       ...
+     }
+     ```   
+6. **Manejo de errores/ excepciones**
+   Se debe tener las siguientes consideraciones:
+   * Todos los errores y/o excepciones posibles deben ser capturados (catch) y se debe lanzar (throw) un mensaje definido con la finalidad de evitar la finalización abrupta del programa.
+   * En caso de que el error requiera de acciones del usuario como ser: continuar, cancelar u otras opciones debe informarse al usuario las consecuencias de cada una de las opciones.
+   * Los mensajes para los usuarios deben ser claros, concisos y ser redactados en Español-Castellano, evitar en lo posible términos técnicos.
+   * La información mínima de un mensaje de error es: Título, mensaje, código de error y opciones.
+
+     ![alt tag](/doc/imagen/error-mesaje.png)
+7. **Comentarios**
+
+   Los comentarios forman parte de la documentación de un proyecto siendo esta la base del manual técnico de un proyecto de software.
+
+   Los comentarios reducen el costo de transferencia de conocimientos entre equipos de desarrollo.
+
+   Si bien el uso de comentarios es altamente recomendado es importante no extralimitarse en su uso.
+
+   Mientras mejor elaborado este un procedimiento / clase o interfase menor cantidad de comentarios requiere.
+
+   La información imprescindible que debe tener un comentario es:
+     * Propósito o descripción.
+     * Autor original.
+     * Fecha de creación.
+     * Modificaciones con sus autores.
+
+   Los comentarios deben estar en idioma Español – Castellano, deben seguir los lineamientos que la librería / framework de documentación requiere.
+
+  ```javascript
+  /**
+   * [proposito-descripcion]
+   *
+   * [autor]
+   * [fecha-creacion]
+   *
+   * [modificacion1][autor][fecha]
+   * [modificacion2][autor][fecha]
+   */
+  ```
\ No newline at end of file

doc/herramientas/selenium-ide/INSTALL.md

+# Selenium IDE - Instalación
+
+## Descripción del Documento
+
+El presente documento contiene procedimientos básicos para la instalación de Selenium IDE, este tiene la licencia Apache 2.0.
+
+## Versión y tipo de aplicación
+
+Selenium se divide en 2 partes:Selenium WebDriver y Selenium IDE, recomendado para realizar pruebas rápidas mediante un IDE integrado al navegador Mozilla Firefox.
+
+Selenium IDE será la herramienta descrita en el presente documento.
+
+Si bien el sitio oficial [Selenium IDE](http://www.seleniumhq.org), provee de un complemento (addon) para el navegador Firefox, es recomendable utilizar el complemento que se encuentra en 
+el sitio [Firefox Addons](https://addons.mozilla.org/es/firefox/search/?q=selenium&appver=46.0&platform=linux), debido a las variaciones entre versiones del navegador y el complemento.
+
+## Instalación 
+
+* Para instalar el complemento se debe insgresar a la página de complementos de [Mozilla Firefox](https://addons.mozilla.org/es/firefox/).
+* En el listado de complementos de firefox, se debe ubicar el complemento con el nombre "Selenium IDE", puede usar este [enlace](https://addons.mozilla.org/en-US/firefox/addon/selenium-ide/?src=userprofile).
+* Posterior a la instalación el navegador debe mostrar el icono ![alt tag](/doc/herramientas/selenium-ide/archivos/selection_002.png)
+* Al presionar el boton se abrirá el IDE se Selenium
+
+## Elementos del IDE
+A continuación se detallan las caracteristicas más importantes e la herramienta.
+
+![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-ide-numbered.png)
+
+1. URL base (Base URL), indica cual es la dirección incial donde empieza la ejecución de los comandos
+2. Ejecuta todas pruebas cargadas en el panel de Casos de Prueba.
+3. Ejecuta la prueba seleccionada en el panel de Casos de prueba.
+4. Pausar / Continuar, pausa o reanuda la ejecución de pruebas, mediante esta opción se puede hacer inspección a detalle de las pruebas en ejecución.
+5. Ejecución por pasos, permite ejecutar uno por uno los comando que componen un Caso de Prueba.
+6. Programador de ejecución de Casos de prueba y Grabador de acciones. 
+   * Programador de Ejecución, permite especificar que caso o casos de pruebas serán ejecutados, tambien permite indicar las horas y los dias que se ejecutarán los casos de pruebas.
+   * Grabador de acciones, permite grabar las acciones realizadas en el navegador, en algunos casos estas pruebas requieren ser modificadas.
+7. Panel de Casos de Prueba (Test Case), en este Panel se muestran los Casos de pruebas disponibles, pueden cargarse tantos casos de pruebas se requieran.
+8. Listado de Comandos, El listado de comandos indica el orden (de arriba abajo) de los comandos que se ejecutan a partir de la URL base.
+9. Listado de Comandos disponibles, esta lista de selección contiene los comandos disponibles y que pueden ser agregados al listado de comandos.
+10. Objetivo (Target), Herramientas para la selección del elemento que evaluará el Comando.
+    * Ingreso de elementos a ser evaluado y listado de elementos utilizados, indica el elemento del DOM sobre el cual se ejecutara el Comando previamente seleccionado. Para la selección de un elemento se pueden utilizar los siguientes selectores:
+      * Selector de Id, se obtiene a través del atributo id de un elemento del DOM, Ej. *id=my_id*
+      * Selector de Nombre, se obtiene a través del atributo name de un elemento del DOM. Ej. *name=my_name*. Adicionalmente se puede especificar el índice de los elementos que comparten el mismo nombre mediante el parámetro index, Ej. *name=my_name index=2*
+      * Selector de enlace (link), se obtiene un elemento del DOM en base al texto del enlace. Ej. *link=Enlace a mi sitio*
+      * DOM, se puede seleccionar un elemento del documento mediante la notación de JavaScript *document*. Ej. document.div['elements'].button[0].
+      * XPath, es una herramienta diseñada para navegar a través de documentos XML, mediante esta herramienta se puede navegar entre elementos individuales, atributos o algún otro elemento de un documento XML. Ej. //div[@id="my_item"]/button[0].
+    * Seleccionar (Select), sirve para seleccionar un elemento de la página, una vez presionado y con la ayuda del ratón se puede seleccionar un elemento simplemente haciendo clic.
+    * Buscar (Find), sirve para comprobar que el Objetivo (Target) ha sido definido correctamente, al presionar este boton, el elemento de la página que coincide con el valor del Objetivo se resalta momentaneamente.
+12. Indicador de comandos ejecutados satisfactoriamente.
+13. Indicador de comandos ejecutados con errores.
+14. Panel de Registro de acciones (Log), este panel brinda información detallada de la ejecución de comandos de prueba de un Caso de Prueba.
+
+## Grabado de acciones
+
+Por defecto Selenium IDE tiene la opción de grabado de acciones activada, mientras esta opción este activada las acciones realizadas sobre el navegador serán registradas en el panel de comandos, conjuntamente con los Objetivos y los valores.
+
+La opción de grabado agiliza el registro de pruebas sin embargo se debe revisar los comandos generados para adecuarlos al caso de prueba.
+
+A continuación la captura de Selenium IDE con el grabador de acciones habilitado.
+
+![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-sample.png),
\ No newline at end of file

doc/herramientas/selenium-ide/ejemplo.md

+# Selenium IDE - Ejemplo
+
+## Descripción del Documento
+
+El presente documento contiene un ejemplo de uso de Selenium IDE para automatización de Casos de pruebas.
+
+## Versión
+
+La versión utilizada para el ejemplo es 2.9.1.
+
+## Caso de Prueba
+En el presente ejemplo se generá un caso de prueba sobre el sitio Web [http://www.agetic.gob.bo](http://www.agetic.gob.bo), las pruebas consisten en verificar el acceso a todas las opciones de menú del sitio.
+
+A continuación se detallan los pasos a seguir para el caso de prueba.
+
+1. Abrir el navegador Mozilla Firefox.
+2. Iniciar Selenium IDE presionando el boton ![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-button.png). ubicado en la parte derecha de la barra de direcciones del Navegador.
+2. Verificar o iniciar que la opción Grabado de opciones este activo ![alt tag](/doc/herramientas/selenium-ide/archivos/record-button.png).
+3. Ingresar al sitio [http://www.agetic.gob.bo](http://www.agetic.gob.bo).
+   ![alt tag](/doc/herramientas/selenium-ide/archivos/agetic-browser.png)
+4. Verificar que esta misma dirección este en la URL base de Selenium IDE.
+   ![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-browser.png).
+5. Ingresar a cada una de las opciones de menú, 
+6. Verificar que en panel de comandos se crean las pruebas de verificación.
+   ![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-command.png).
+7. En este punto se puede ejecutar el caso de prueba presioando el boton.
+   ![alt tag](/doc/herramientas/selenium-ide/archivos/test-case-button.png).
+8. Cuando se ejecuta el caso de prueba, el valor del indicador de comandos ejecutados satisfactoriamente es 1 y el indicador de comandos ejecutados con errores es 0.
+9. Detener el Grabador de acciones ![alt tag](/doc/herramientas/selenium-ide/archivos/grabador-acciones-off.png).
+10. Se añadirá una verificación manual en la opción de menú 'Transparencia' donde se verificará el título del documento para la cual se registrará un comando, un objetivo y un valor.
+    * El comanda utilizar es *assertText*.
+    * El objetivo será el título del documento, para este ejemplo se obtendrá el objetivo mediante la opción CSS, para este caso se hace clic izquierdo en el título del documento y selecciona la opción 'Inspeccionar Elemento / Inspect Element', se muestra el panel de Inspección de código, con el elemnto HTML seleccionado, en el presente caso es "<h1>Transparencia</h1>". Con este identificador se puede indicar el objetivo con la siguiente regla **css=h1**.
+    * El valor corresponde al valor esperado del objetivo, en este caso como el comando es **assertText** se compara el texto que contiene el objetivo, en este caso el valor es 'Transparencia'.
+    A continuación se presenta el listado de Comandos generados.
+    
+    | Comando       | Objetivo      | Valor  | Descripción |
+    | ------------- |:-------------:| ------:| ----------- |
+    | open           | / |  | Realiza la navegación hasta la raíz del sitio. |
+    | clickAndWait  | link=exact:¿Quiénes Somos? | | Busca un elemento del documento que tenga el título '¿Quiénes Somos?', posteriormente navega hasta la dirección indicada en el elemento encontrado y espera a que termina la carga. |
+    | clickAndWait  | link=Gobierno Electrónico | | Busca un elemento del documento que tenga el título 'Gobierno Electrónico', posteriormente navega hasta la dirección indicada en el elemento encontrado, accede a la dirección y espera a que termina la carga. |
+    | clickAndWait  | link=Simplificación de Trámites | | Busca un elemento del documento que tenga el título 'Simplificación de Trámites', posteriormente navega hasta la dirección indicada en el elemento encontrado, accede a la dirección y espera a que termina la carga. |
+    | clickAndWait  | link=TIC | | Busca un elemento del documento que tenga el título 'TIC', posteriormente navega hasta la dirección indicada en el elemento encontrado, accede a la dirección y espera a que termina la carga. |
+    | clickAndWait  | link=Transparencia | | Busca un elemento del documento que tenga el título 'Transparencia', posteriormente navega hasta la dirección indicada en el elemento encontrado, accede a la dirección y espera a que termina la carga. |
+    | assertText  | css=h1 | Transparencia | Verifica que en el documento actual existe un elemento que cumple con la regla de CSS "css=h1" tenga el valor Transparencia |
+12. Una vez probado y revisado se puede guardar el caso de prueba, para esto se utiliza la opción de menú File > Save Test Case As..., posteriormente seleccionar una hubicación dentro del equipo local y nombrar el caso de prueba para ser utilizado cuando sea necesario. Considerar que el archivo generado con Selenium IDE no tiene extensión.
\ No newline at end of file

doc/politicas-bases-datos.md

+# Políticas para el diseño y creación de bases de datos para los proyectos de desarrollo
+
+## I. Objetivo
+
+El presente documento tiene por objetivo, el establecer las políticas a seguir durante el proceso de diseño del **modelo de datos** a utilizarse en el proyecto correspondiente.
+
+## II. Desarrollo
+
+### A. Reglas de consistencia e integridad
+
+#### Integridad
+>**1. Regla de la llave primaria:** todos los tipos de entidades tiene una llave primaria (propia, compuesta o heredada)
+
+>**2. Regla de la denominación:** todos los tipos de entidad, relaciones y atributos tienen nombre.
+
+>**3. Regla de la cardinalidad:** está dada para los dos grados que pueden existir en una relación.
+
+>**4. Regla de la participación de la entidad:** todos los tipos de entidad participan en al menos una relación, excepto los de una jerarquía de generalización.
+
+>**5. Regla de participación en una jerarquía de generalización:** cada jerarquía de generalización participa en al menos una relación con un tipo de entidad que no está en la jerarquía de generalización.
+
+#### Consistencia
+>**1. Regla de nombres de entidad:** los nombres de una entidad son únicos.
+
+>**2. Regla de nombre de atributo:** los nombres de atributos son únicos dentro de las de entidades.
+
+>**3. Regla de nombre de atributos heredados:** los nombres de los atributos de un subtipo no coinciden con los nombres de los atributos heredados (directos o indirectos)
+
+>**4. Regla de tipo de conexión relación/entidad:** todas las relaciones conectan dos tipos de entidad (no necesariamente distintos).
+
+>**5. Regla de conexión relación/relación:** las relaciones no se conectan con otras relaciones.
+
+>**6. Regla de entidad débil:** las entidades débiles tienen al menos una relación identificable.
+
+>**7. Regla de la relación identificable:** para cada relación identificable al menos uno de los tipos de entidad participante debe ser débil.
+
+>**8. Regla de la Cardinalidad de identificación de dependencia:** para cada relación identificable, la cardinalidad mínima y máxima debe ser 1 en el sentido del tipo de entidad hijo (entidad débil) al tipo de entidad padre.
+
+>**9. Regla de la llave foránea redundante:** las llaves foráneas redundantes no se usan.
+
+### B. NOMENCLATURA DE OBJETOS DE BASE DE DATOS
+
+**Guías genéricas y buenas prácticas**
+1. Se debe utilizar nombres en español para todos los elementos de la base de datos, tablas, vistas, campos, etc. Excepto cuando el acrónimo usado sea un estándar predifinido y esté en inglés.
+
+2. Se recomienda utilizar nombres descriptivos para los campos. Utilizar nombres que resulten intuitivos  y permitan entender el significado de los campos (mnemotécnicos). Evitar las abreviaciones, y si esto no es posible documentarlas bien.
+
+3. Se debe utilizar solo minúsculas para nombrar los elementos de la base de datos, schemas, tablas y campos. No debe contener caracteres especiales excepto el guión bajo \( _ ).
+
+4. Se recomienda evitar tener demasiadas columnas NULLABLES en una tabla. Esto es indicio de un esquema poco o nada normalizado. Falta de normalización puede conllevar problemas de consistencia en los datos en la medida que un mismo campo se puede terminar almacenando en varias tablas. Excesiva normalización puede tener asociada una pérdida de performance en ciertas operaciones sobre la base de datos. Es necesario encontrar el equilibrio correspondiente a los requerimientos de cada proyecto en este punto. Como regla general la tercera forma normal es un buen punto intermedio.
+
+5. Se recomienda evitar tener tablas sin definición de llaves primarias.
+
+6. Se recomienda evitar tener tablas innecesarias en el sistema. Un buen diseño es uno simple.
+
+
+#### 1. Tabla
+
+>a) Definir nombres claros, que describan el contenido de la entidad o tabla. La longitud máxima será de 30 caracteres.
+
+>b) La denominación debe ser un sustantivo en singular; sólo en aquellos casos en donde el singular no represente correctamente el contenido de la misma, se podrán utilizar nombres en plural.
+
+>c) Las tablas temporales deberán tener como prefijo "tmp_"
+
+>d) Las tablas que hagan referencia a versión deberán tener como prefijo "ver_"
+
+#### 2. Atributo.
+> a) El nombre del atributo debe ser claro y representativo al dato que contiene, con un tamaño máximo de 25 caracteres.
+
+> c) El orden de los atributos al interior de la entidad, deben ser de acuerdo al orden de captación de la información correspondiente.
+
+> d) Únicamente a los atributos que formen parte de la llave primaria se les agregará el prefijo "id_" seguido del nombre de la entidad.
+
+>e) La llave foránea seguirá el patrón: "fid_nombreTabla"
+
+>Los siguientes 4 atributos deberán estar de manera obligatoria en todas las tablas:
+* _usuario_creacion
+* _fecha_creacion
+* _usuario_modificacion
+* _fecha_modificacion

doc/politicas-gestion-ramas.md

+# Políticas gestión de ramas en GIT
+
+## Descripción del Documento
+El presente documento contiene políticas para la gestión de ramas en GIT aplicado al desarrollo de proyectos de Software.
+
+## Flujo de ramas 
+
+Con la finalidad de homogenizar la gestión de las ramas (branches) en los proyectos se recomienda seguir el siguiente Flujo:
+
+![alt tag](/doc/imagen/git-workflowv2.png)
+
+### Ramas
+El flujo contempla las ramas Master, Develop, Versión Entregable y HotFix, tambien contempla la creación de Tags Release (etiquetas de lanzamiento) de Git, a continuación se describen los elementos del diagrama:
+1. **Master**, es la rama principal del proyecto y contiene las versiones candidatas para puesta en Producción. Cuenta con 2 acciones:
+   * Actualización de archivos, la unión (merge) de cambios hacia esta rama debe ser autorizado por el Administrador del Proyecto y sujeta a pruebas ejecutadas por el equipo de desarrollo del proyecto.
+   * Generación de Tag releases (Etiqueta de Lanzamiento), con respecto al paso a producción de los archivos de esta rama, tiene que cumplir los siguientes requisitos:
+      * Haber concluido las pruebas unitarias, de integración y funcionales elaboradas por el equipo SQA de manera satisfactoria.
+      * Generar un Tag release (etiqueta de lanzamiento), a cargo del equipo de SQA.
+2. **Develop**, es la rama de la versión estable en desarrollo, contiene la última versión del proyecto de software, cuenta con 2 acciones:
+   * Unión (merge) con rama Master, el paso de cambios a la rama Master debe ser autorizado por el Administrador del Proyecto, ademas debe terminar satisfactoriamente las pruebas del equipo de desarrollo.
+   * Actualización de archivos, todas las versiones entregables que se unen (merge) con esta rama deben terminar satisfactoriamente las pruebas de los encargados del desarrollo de la versión entregable.
+3. **Versión Entregable**, son ramas creadas con la finalidad de desarrollar una caracteristica o funcionalidad del proyecto, pueden estar asociadas a requisitos del proyecto o historias de usuarios, para diferenciarlas de las ramas Master y Develop se recomienda indicar el código utilizado en el Open Proyect. 
+
+    Ejemplos:
+
+        feature/servicio-web-v1
+        feature/registro-usuarios
+        feature/busqueda-paginacion
+    Estas ramas cuentan con 2 acciones:
+      * Creación de la rama, las ramas creadas para versiones entregables, deben obtenerse de la última versión de la rama Develop.
+      * Unión (merge) con la rama Develop, para el paso de cambios hacia la rama Develop debe ejecutarse pruebas unitarias y terminarlas satisfactoriamente.
+    
+    Es importante que estas ramas no sean extensas en tiempo, con la finalidad de evitar conflictos durante la unión (merge) con la rama Develop.
+4. **HotFix**, esta rama es de uso excepcional, su finalidad es corregir posibles errores en producción los cuales requieren soluciones inmediatas. Esta rama debe ser obtenida de la rama Master y una vez solucionado el error debe unirse  a la rama Master y a la rama Develop.
+5. **Tag release (Etiqueta de lanzamiento)**, para la generación de Tag releases, se coordina con el administrador del proyecto y posteriormente se ejecutan pruebas sobre la versión de archivos de la rama master, esta versión de archivos es sometida a pruebas unitarias, de integración, de funcionalidades ademas de revisión de calidad del código, si todas las pruebas concluyen satisfactoriamente, se procede con la creación de un Tag release, este tag es candidato de paso a producción. 
+    Cuando se genera una rama de tipo HotFix y esta se une (merge) con la rama master, se ejecuta ejecuta el procedimiento de creación de Tag release.
\ No newline at end of file

doc/politicas-gestion-versiones.md

+# Políticas para la gestión de versiones de los proyectos
+
+Para indicar el nivel de desarrollo de un sistema es necesaria la asignación de un nombre, código o número único.
+
+En nuestro caso de usará una combinación de la sigla o nombre del proyecto y la numeración X.Y.Z:
+