Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop #206

Merged
merged 8 commits into from
Apr 19, 2024
Merged
Show file tree
Hide file tree
Changes from 7 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion docs/cr/Desarrollo/estandar-codificacion.md
Original file line number Diff line number Diff line change
Expand Up @@ -95,7 +95,8 @@ Otros directorios opcionales son:

**1. Formato**

- El atributo _“id”_ se escribe antes que _“model”_.
- El atributo _“model”_ se escribe antes que _“id”_.
- Los valores de los atributos deben usar doble comillas.
- Para la declaración de un `<field>`, el atributo del nombre se escribe primero. El valor del atributo se ingresa dentro de los tags de `<field>`.

**Ejemplo:**
Expand Down
42 changes: 31 additions & 11 deletions docs/cr/Desarrollo/manual-arquitectura.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ El propósito de este documento es describir la arquitectura del proyecto de Tal

Además de ser una guía para los miembros del equipo de desarrollo, este documento servirá como referencia para futuros desarrollos y como material de consulta para la resolución de problemas.

## Arquitetura
## Arquitectura

La arquitectura propuesta para el proyecto se basa en el uso de Odoo como plataforma principal para el desarrollo de la solución. La arquitectura se compone de los siguientes elementos:

Expand Down Expand Up @@ -52,20 +52,19 @@ Para asegurar la calidad del código y la funcionalidad de los módulos desarrol

## Tutoriales

### Índice de tutoriales

- [Crear nuevo tutorial](#crear-nuevo-tutorial)
- [Precargar información con XML](#precargar-información-con-xml)

Esta sección contiene tutoriales para el desarrollo de módulos en Odoo, si tienes algún tutorial que quieras compartir, por favor agrega una entrada usando el siguiente formato:

### Crear nuevo tutorial

- **Título del tutorial:** Descripción general del tutorial.
- **Descripción:** Descripción detallada del tutorial.
- **Pasos o procedimiento:** Pasos a seguir para completar el tutorial, puede ser en texto o en video.
- **Enlace de interés:** Enlaces externos relacionados con el tutorial.

### Índice de tutoriales

- [Precargar información con XML](#precargar-información-con-xml)
- [Permisos y seguridad](#permisos-y-seguridad)
- [Pruebas unitarias](#pruebas-unitarias)

### Precargar información con XML

- **Título:** Precargar información con XML.
Expand Down Expand Up @@ -114,8 +113,29 @@ Esta sección contiene tutoriales para el desarrollo de módulos en Odoo, si tie

3. Actualizar el archivo `__manifest__.py` del módulo para incluir el archivo XML en la lista de archivos de datos.

### Permisos y seguridad

- **Título:** Permisos y seguridad.
- **Descripción:** Tutorial para definir permisos y seguridad en los módulos de Odoo.
- **Pasos:**

Para definir permisos y seguridad en los módulos de Odoo, referirse al siguiente video tutorial:

[Permisos y seguridad](https://drive.google.com/file/d/1LKMrv46QPTXJ85t6acbocOvNTQEeiL0B/view?usp=sharing)

### Pruebas unitarias

- **Título:** Pruebas unitarias.
- **Descripción:** Tutorial para realizar pruebas unitarias en los módulos de Odoo.
- **Pasos:**

Para realizar pruebas unitarias en los módulos de Odoo, referirse al siguiente video tutorial:

[Pruebas unitarias](https://drive.google.com/file/d/15rHCKMoWrjC_uCuPkCANQOZIQQwCt2q_/view?usp=sharing)

## Control de cambios

| Versión | Cambio | Autor del cambio | Aprobado por | Fecha de cambio |
| ------- | ---------------------- | ---------------- | ------------ | --------------- |
| v 1.0 | Creación del documento | Diego Sandoval | Daniel Cajas | 17/03/2024 |
| Versión | Cambio | Autor del cambio | Aprobado por | Fecha de cambio |
| ------- | ------------------------------------------ | ---------------- | ------------ | --------------- |
| v 1.0 | Creación del documento | Diego Sandoval | Daniel Cajas | 17/03/2024 |
| v 1.1 | tutoriales de permisos y pruebas unitarias | Diego Sandoval | | 19/03/2024 |
66 changes: 41 additions & 25 deletions docs/guias/gui-bdt-012.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,57 +10,73 @@ v 1.0
Explicar qué es un elemento de configuración e identificar qué productos de trabajo se pondrán bajo gestión de configuración para tener un mayor control de los elementos de trabajo que conforman una línea base

## Notas introductorias
Línea base: Las líneas base representan la última versión estable de un elemento de configuración, asegurándonos un punto de referencia “seguro” para el desarrollo continuo.
Para más información leer "[Resumen de CM](https://docs.google.com/document/d/1nU3UvQYrKnQ0tWVQS8KdK-ErITvPMbaa1Qce34szmwY/edit?usp=sharing)".

## Entradas

## Salidas
- Línea base: Las líneas base representan la última versión estable de un conjunto de elementos de configuración, asegurándonos un punto de referencia “seguro” para el desarrollo continuo.
- Nivel dinámico: No hay ninguna gestión de la configuración ni control de cambios
- Nivel controlado: Se debe someter a un proceso o mecanismo para aprobar los cambios a un elemento de configuración por al menos una parte interesada
- Nivel estático: Todas las partes interesadas aprobaron el elemento de la configuración y ahora forma parte de una línea base
- Para más información leer "[Resumen de CM](https://docs.google.com/document/d/1nU3UvQYrKnQ0tWVQS8KdK-ErITvPMbaa1Qce34szmwY/edit?usp=sharing)".

## Procedimiento

### Criterio
Para que un elemento de trabajo pueda considerarse bajo gestión de configuración, debe cumplir mínimo con uno de los siguientes criterios:
### 1. Criterio
- Para que un elemento de trabajo pueda considerarse bajo gestión de configuración, debe cumplir mínimo con uno de los siguientes criterios:
- Productos de trabajo que se pueden utilizar por Talent Dot y Linked Bridge
- Productos de trabajo que se espera que cambien a lo largo del tiempo debido a errores o a cambio en los requisitos. Los cambios en estos productos de trabajo no deben ser continuos (ej. si un producto de trabajo se actualiza cada 1-3 días), ya que sería insostenible mantenerlos bajo configuración.
- Productos de trabajo que se espera que cambien a lo largo del tiempo debido a errores o a cambios en los requisitos y que pertenezcan al nivel controlado o estático de configuración (Revisar notas introductorias)
- Prodcutos de trabajo que son dependientes entre sí (es decir, un cambio en uno implica un cambio en los otros)
- Productos de trabajo críticos para el éxito del proyecto

### Elementos de configuración identificados
### 2. Elementos de configuración identificados
Productos de trabajo identificados bajo gestión de configuración en Black Dot:
1. Proyectos (repositorios de Github: CR, ZG y Wiki)
2. Procesos
3. Políticas
4. Documentación de análisis (ERS, MER, etc)
5. Guías
6. Checklists
4. Manuales
5. Plantillas
6. Guías
7. Checklists
8. Definiciones

### IDs
### 3. IDs
Para acceder y distinguir de mejor manera los elementos de configuración, se han asignado los siguientes identificadores únicos:
1. CR-BDT, ZG-BDT, WIKI-BDT
2. PRO-BDT-###
3. POL-BDT-###
4. ANA-BDT-###
5. GUI-BDT-###
6. CHK-BDT-###
4. MAN-BDT-###
5. PLT-BDT-###
6. GUI-BDT-###
7. CHK-BDT-###
8. DEF-BDT-###

### Características
Estas son las características importantes que cada elemento de configuración debe tener para ponerla bajo configuración:
### 4. Características
Éstas son las características importantes que cada elemento de configuración debe tener para ponerla bajo gestión de configuración:
- ID
- Nombre
- Ubicacion
- Ubicación
- Bitácora de cambios
- Versión actual
- Fecha de creación original
- Fecha de última versión
- Autor original
- Autor responsable de última versión

### ¿Cuándo se pone un elemento de configuración bajo gestión de configuración?
### 5. Criterio para que un elemento de configuración sea considerado en los niveles

#### Estático:
- El elemento fue aprobado por todas las partes interesadas
- El elemento fue auditado satisfactoriamente

#### Controlado:
- El elemento fue aprobado solamente por una parte interesada
- El elemento sigue los estándares y políticas que correspondan al elemento
- El elemento está listo para ser auditado

### Especificar las relaciones entre los elementos de configuración
#### Dinámico:
- El elemento recibe cambios constantes
- El elemento no ha sido aprobado por ninguna de las partes interesadas
- El elemento tiene retroalimentación de mejora, en caso de tener

## Control de cambios

| Versión | Cambio | Autor del cambio | Aprobado por | Fecha de cambio |
| ------- | ---------------------- | ---------------- | -------------- | --------------- |
| v 1.0 | Creación de la guia | Carlos Velasco | | 17/04/2024 |
| Versión | Cambio | Autor del cambio | Aprobado por | Fecha de cambio |
| ------- | ---------------------- | ------------------------------------------------ | -------------- | --------------- |
| v 1.0 | Creación de la guia | Carlos Velasco, Diego Perdomo, Sergio Garnica | | 19/04/2024 |
58 changes: 58 additions & 0 deletions docs/procesos/pro-bdt-016.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
---
#Este número indica la posición de este documento en su respectiva carpeta de la sidebar. Favor de actualizarlo de acuerdo al número del identificador que pondrás en el nombre del archivo/título del mismo.
sidebar_position: 16
---

# PRO-BDT-016 Pruebas de inspección de componentes críticos de software

v 1.0 / VER, VAL, PPQA

## Propósito

Revisar un componente desarrollado para asegurar la calidad y el buen funcionamiento del mismo.

## Notas introductorias

Este proceso tiene como objetivo reconocer los defectos de los componentes más críticos del sistema durante la fase de pruebas. Es importante considerar que este proceso tiene un alto costo, por lo que debe ejecutarse exclusivamente en los componentes más importantes del sistema.

## Involucrados

Integrantes del departamento bajo los siguientes roles:

- 1 Expositor del componente
- 4 - 6 Inspectores dentro del equipo de trabajo
- 1 - 2 Inspectores fuera del equipo de trabajo

## Entradas

- Código fuente del componente a inspeccionar
- Hoja de cálculo de inspección
- Checklist de Revisión de Código del Equipo

## Salidas

- Listado de defectos encontrados en el Defect Log del equipo
- Resumen de detalles de la inspección
- Total de defectos
- Número de defectos restantes
- Densidad estimada de defectos por KLOC

## Descripción

| Fase | Actividades | Responsables | Prácticas Asociadas al CMMI |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------- |
| Planeación | Seleccionar el componente a evaluar | Equipo de trabajo | VER SP 1.1 <br/> VER SP 1.2 <br /> VAL 1.1 <br /> PPQA SP 1.2 |
| Planeación | Dividir los roles de inspección | Equipo de trabajo | VER SP 1.1 <br/> VER SP 2.1 <br /> VAL 1.2 <br /> PPQA SP 1.1 |
| Planeación | Explicar la Checklist de Revisión de Código del Equipo a los inspectores que desconocen de ella | Integrante del equipo, Equipo de inspección | VER SP 1.3 <br /> VAL SP 1.3 <br /> PPQA SP 1.2 |
| Ejecución | Mostrar el componente funcionando, los inspectores hacen notas de los defectos que se van encontrando durante la demostración | Expositor del componente, Inspectores | VER SP 2.2 <br /> VER SP 2.3 |
| Ejecución | Mostrar y explicar los archivos de código creados para el funcionamiento del componente | Expositor del componente | VER SP 2.2 <br /> VER SP 2.3 |
| Ejecución | Cada inspector estudia los archivos presentados por el expositor y reportan los defectos encontrados en su hoja, enfocándose en cada sección de la Checklist de Revisión de Código del Equipo. **Este paso se repite por cada sección de la Checklist** | Equipo de inspección | VER SP 2.3 <br /> VER SP 3.1 <br /> VAL SP 2.1 |
| Análisis | Llenar la hoja "Log" con base en los defectos encontrados por cada inspector y verificar que sean válidos con base en los estándares del equipo | Integrantes del equipo, Equipo de inspección | VER 3.2 <br /> VAL SP 2.2 |
| Resumen | Llenar la hoja de detalles de la hoja de cálculo para obtener datos cuantificables de la inspección | Integrantes del equipo, Equipo de inspección | |
| Reporte | Pasar los defectos encontrados al Defect Log del equipo | Integrantes del equipo, Equipo de inspección | PPQA SP 2.2 |

## Control de cambios

| Versión | Cambio | Autor del cambio | Aprobado por | Fecha de cambio |
| ------- | -------------------- | ---------------- | ------------ | --------------- |
| v 1.0 | Creación del proceso | David Langarica | | 18/04/2024 |
Loading