Diferencia entre revisiones de «Desarrollo»

De Telstock Wiki
Saltar a: navegación, buscar
(Referencia.)
(Descripción de Actividades)
 
(No se muestran 18 ediciones intermedias del mismo usuario)
Línea 12: Línea 12:
  
 
==Referencia.==
 
==Referencia.==
[[Políticas Generales de Desarrollo]]
+
* [[Políticas Generales de Desarrollo]]
[[Estándar de Proceso de Uso Aplicativo JIRA]]
+
* [[Estructura de Repositorio SVN|Estructura de Repositorio y Estatus de Nombre SVN]]
[[SesionPruebas|Liberación a QA]]
+
* [[Estándar de Proceso de Uso Aplicativo JIRA]]
 +
* [[SesionPruebas|Liberación a QA]]
 +
* [[Peer Review]]
  
 
==Responsabilidades.==
 
==Responsabilidades.==
Línea 20: Línea 22:
 
*'''Tramitador:''' Project Manager (PM), Product Owner (PO).
 
*'''Tramitador:''' Project Manager (PM), Product Owner (PO).
  
*'''Encargado:''' Team Leader (TL)
+
*'''Encargado:''' Team Leader (TL/LT)
  
*'''Ejecutor:''' Developer Team (DT)
+
*'''Ejecutor:''' Developer Team (DT), Team Leader (TL/LT)QA Team (QA), Coord TI
 
 
*'''Validador:''' QA Manager (QAM) y QA Team (QAT), Cliente (CTE).
 
  
 +
*'''Validador:''' QA Manager (QAM) y QA Team (QA), Cliente (CTE).
  
 
==Definiciones.==
 
==Definiciones.==
Línea 41: Línea 42:
 
'''1.''' Antes de iniciar con la fase de Codificación, los siguientes formatos deben contener la información necesaria hasta este punto:  
 
'''1.''' Antes de iniciar con la fase de Codificación, los siguientes formatos deben contener la información necesaria hasta este punto:  
  
'''TSK-FOR-012:''' Especificación de Diseño del Sistema
+
'''TSK-''' Especificación de Diseño del Sistema
 
 
'''TSK-FOR-013:''' Diagramas
 
  
'''TSK-PRO-014:''' Matriz de Trazabilidad
+
'''TSK-''' Diagramas
  
'''TSK-FOR-015:''' Plan de Pruebas de Sistema
+
'''TSK-''' Plan de Pruebas de Sistema
  
'''TSK-FOR-016:''' Matriz de Pruebas del Sistema  
+
'''TSK-''' Matriz de Pruebas del Sistema  
  
'''TSK-FOR-017:''' Plan de Integración y Despliegue
+
'''TSK-''' Plan de Integración y Despliegue
  
  
Línea 60: Línea 59:
 
'''3.''' Todas las actividades programadas para cada desarrollador, deberán ser actualizadas diariamente en el JIRA.
 
'''3.''' Todas las actividades programadas para cada desarrollador, deberán ser actualizadas diariamente en el JIRA.
  
'''4.''' Es obligatorio estructurar las pruebas unitarias por parte del equipo de desarrolladores antes de notificar al QAM que puede dar inicio a las pruebas.
+
'''4.''' Es obligatorio estructurar las pruebas unitarias y de integración por parte del equipo de desarrolladores antes de notificar al QAM que puede dar inicio a las pruebas.
 +
 
 +
'''5.''' En caso de presentarse dudas o temas omitidos por parte del equipo de desarrollo, deberán informarse de forma inmediata a PM y PO, para resolverlas sin afectar tiempos de desarrollo. En caso de que existan, estas serán consideradas deuda técnica, ya que debieron desplegarse en la fase de análisis y diseño.
  
'''5.''' EL DT debe realizar la Verificación de Código antes de las pruebas por parte de QA.
+
'''6.'''Cualquier falla Crítica que impida el desempeño del sistema se considera deuda técnica.
  
==Descripción de Actividades==
+
'''7.'''Cualquier falla técnica o de mejores prácticas será considerada deuda técnica, así como cualquier regla de negocio que NO cumpla con lo estipulado en la fase de análisis y diseño.
[[Archivo:Ejecucion de Proyecto8.png|centro]]
 
  
==Diagrama de Flujo==
+
'''8.'''Fallas superficiales, faltas de ortografía, o error de UI/UX que SI permita trabajar y usar el sistema, serán enviadas a Back Log, así como cualquier regla de negocio o cambio de flujo que NO este estipulado en la fase de análisis y desarrollo. IMPORTANTE: el tiempo que se ocupe para adicionar estos nuevos flujos deberá ser cotizado de nuestra parte y ser cubierto por el cliente.
  
 +
==Descripción de Actividades==
  
'''Diagrama 1'''
 
[[Archivo:2.2.2.2.jpg|centro]]
 
  
 +
[[Archivo:Ejecucion de ProyectoBD2w.png|centro]]
  
'''Diagrama 2'''
+
==Diagrama de Flujo==
[[Archivo:2.2.2.2.2.jpg|centro]]
 
  
 
==Formato==
 
==Formato==
  
[[Archivo:2.2.2.2.2.2.jpg|centro]]
+
[[Archivo:Documentos Ejecucion.png|centro]]

Revisión actual del 02:01 15 ago 2020

1. Propósito del procedimiento.

Elaborar el producto fundamental a través de la codificación de los módulos de programa definidos en la etapa de Análisis y Diseño.


Alcance.

Abarca el proceso de implementación (codificación) del aplicativo.


Referencia.

Responsabilidades.

  • Tramitador: Project Manager (PM), Product Owner (PO).
  • Encargado: Team Leader (TL/LT)
  • Ejecutor: Developer Team (DT), Team Leader (TL/LT), QA Team (QA), Coord TI
  • Validador: QA Manager (QAM) y QA Team (QA), Cliente (CTE).

Definiciones.

  • Scrum: Es un proceso de la Metodología Ágil que se usa para minimizar los riesgos durante la realización de un proyecto, pero de manera colaborativa.
  • Codificación: Es el proceso por el cual la información de una fuente es convertida en símbolos para ser comunicada. Al codificar convertimos información de un formato o código a otro, con el propósito de estandarización, velocidad o de compresión
  • Trazabilidad: Serie de procedimientos que permiten seguir el proceso de evolución de un producto en cada una de sus etapas.


Políticas y Lineamientos

1. Antes de iniciar con la fase de Codificación, los siguientes formatos deben contener la información necesaria hasta este punto:

TSK- Especificación de Diseño del Sistema

TSK- Diagramas

TSK- Plan de Pruebas de Sistema

TSK- Matriz de Pruebas del Sistema

TSK- Plan de Integración y Despliegue


2. Es estrictamente necesario, durante el proceso de desarrollo, realizar reuniones diarias de seguimiento (Daily).

Cada miembro del equipo de desarrollo es responsable de acudir puntualmente a los dailys. En caso que el PM se encuentre ausente, es responsabilidad del TL llevar a cabo el daily. Cualquier duda que se tenga respecto a la programación de un daily en específico debe ser aclarado directamente con el PM, ya sea en persona o por el canal de Slack destinado al proyecto.

3. Todas las actividades programadas para cada desarrollador, deberán ser actualizadas diariamente en el JIRA.

4. Es obligatorio estructurar las pruebas unitarias y de integración por parte del equipo de desarrolladores antes de notificar al QAM que puede dar inicio a las pruebas.

5. En caso de presentarse dudas o temas omitidos por parte del equipo de desarrollo, deberán informarse de forma inmediata a PM y PO, para resolverlas sin afectar tiempos de desarrollo. En caso de que existan, estas serán consideradas deuda técnica, ya que debieron desplegarse en la fase de análisis y diseño.

6.Cualquier falla Crítica que impida el desempeño del sistema se considera deuda técnica.

7.Cualquier falla técnica o de mejores prácticas será considerada deuda técnica, así como cualquier regla de negocio que NO cumpla con lo estipulado en la fase de análisis y diseño.

8.Fallas superficiales, faltas de ortografía, o error de UI/UX que SI permita trabajar y usar el sistema, serán enviadas a Back Log, así como cualquier regla de negocio o cambio de flujo que NO este estipulado en la fase de análisis y desarrollo. IMPORTANTE: el tiempo que se ocupe para adicionar estos nuevos flujos deberá ser cotizado de nuestra parte y ser cubierto por el cliente.

Descripción de Actividades

Ejecucion de ProyectoBD2w.png

Diagrama de Flujo

Formato

Documentos Ejecucion.png