Guía para el desarrollo de aplicaciones WEB, basada en MoProSoft. - Proceso sugerido para el desarrollo de sistemas WEB -

Secciones:

1.- Introducción
2.- Estructura
3.- Características de los sistemas WEB
4.- Dificultades en los desarrollos de sistemas WEB
5.- Involucrados en el desarrollo de un sistema WEB
6.- Proceso sugerido para el desarrollo de sistemas WEB
6.1 Notas sobre los procesos
6.2 Actividades del Proceso de Administración de Proyectos Específicos
6.3 Actividades del Proceso de Desarrollo y Mantenimiento de software

7.- Técnicas útiles en el desarrollo WEB
8.- Productos
Referencias bibliográficas
Referencias a aplicaciones
Sitios de interés



6.- Proceso sugerido para el desarrollo de sistemas WEB



6.1 Notas sobre los procesos

Los últimos modelos de procesos de desarrollo de software no nos indican una secuencia de pasos sino una serie de temas o áreas a cubrir. Aunque, por ejemplo, es claro que es indispensable elaborar los requerimientos antes de iniciar el desarrollo, no se abandonan los primeros al iniciar lo segundo. Se trabaja simultáneamente en diversas áreas aunque con distinta intensidad, lo que mejor ilustra esta situación es el siguiente cuadro del RUP (Rational Unified Process) en el que las áreas coloreadas en cada renglón señalan el esfuerzo dedicado a cada disciplina en las diferentes fases. Por ejemplo se puede ver que al inicio se trabaja mucho en los requerimientos pero aun durante la construcción se sigue trabajando en estos.

MoProSoft es más concreto y nos señala diversas actividades y productos a desarrollar. A pesar de estas diferencias de forma, la filosofía de trabajo simultáneo en diversas disciplinas se mantiene, en este caso aplicada a las actividades y productos. Esto implica que los productos evolucionan y se refinan a lo largo del proyecto. Dos de los productos, solicitudes de cambios y el control de la configuración, sirven para administrar y documentar las modificaciones.

Los productos son instancias de información de diversa naturaleza. Existen documentos como el plan de proyecto, plan de comunicación, descripción del proyecto, etc… que aportan información concerniente al proyecto, otros documentos contienen conocimientos sobre el sistema en sí, como son los requerimientos, la configuración del sistema, los reportes de verificación, etc. Finalmente hay productos como la solicitud de cambios y las lecciones aprendidas que contienen información que ayuda a controlar el proceso de desarrollo o a las organizaciones y equipos involucrados.

En particular en los sistemas WEB los propios requerimientos cambian mucho conforme los clientes aprenden sobre la WEB y organizan la información para el sistema y los desarrolladores conocen y entienden la actividad de los clientes. Por eso las primeras fases del desarrollo pueden enfocarse en el levantamiento de los requerimientos y en la elaboración de prototipos descartables para acelerar dicho aprendizaje y desencadenar los cambios en etapas más tempranas.

El desarrollo de un sistema WEB incluye información que solo los clientes pueden determinar y generar. Por lo tanto los clientes deben trabajar para el desarrollo del sistema independientemente de cuantos desarrolladores se involucren. El trabajo de los clientes es indispensable e insustituible y además es adicional a las actividades que ya desempeñan. Esto suele causar retrasos y dificultades a los desarrolladores. Una forma sencilla de disminuir estos problemas es documentar claramente todo lo que se requiere del cliente y establecer claramente las formas de comunicación y en particular de solicitar y aprobar cambios.

A continuación se presenta una lista de actividades basadas en los procesos de Administración de Proyectos Específicos y Desarrollo y Mantenimiento de Software de MoProSoft. Hay que recordar que el orden señala una secuencia deseable de para el inicio de las actividades pero como se explicó anteriormente se debe trabajar simultáneamente en diversas áreas o productos a lo largo del proyecto. Cada tarea debe tener un responsable cuyo rol se especifica junto a ésta. A las tareas sugeridas para web se le numero con el prefijo W y en las tareas en que así aplica se puede leer entre paréntesis el número correspondiente a la tarea en MoProSoft. Adicionalmente en cada tarea se subrayaron los productos que se generan o modifican y se destacaron con negritas aquellos que se deben consultar para poder realizarla.




6.2 Actividades del Proceso de Administración de Proyectos Específicos

Rol

Descripción

Observaciones

A1. Aprobación


CP
CAE
RAPE

W1.1 (A1.1) Generar con el Cliente Patrocinador y el Cliente Administrador Encargado la P1 Descripción del Proyecto.

  • Generar P2 Bocetos, listas de sitios de similares y prototipos.

  • Generar P3 Glosario.

  • Analizar, discutir y establecer el alcance y la magnitud del proyecto

  • Generar P1 Descripción del Proyecto.

Los proyectos WEB se caracterizan por sus D2 Requisitos altamente cambiantes definir claramente todos los elementos de la descripción del proyecto: Descripción del Producto, Objetivos, Entregables y Alcance. Ayuda a disminuir el número y el impacto de los cambios. Además es indispensable para poder negociar clara y abiertamente cuando estos ocurran.



Hacer P2 Bocetos, listas de sitios de similares y prototipos disminuye las D3 Dificultades de comunicación. El P3 Glosario ayuda al mismo fin y se debe iniciar en este momento.

RAPE
(otros)*

W1.2 A partir de la P1 Descripción del Proyecto identificar a todos involucrados, y sus expectativas, influencia, y responsabilidades generando el P4 Mapa de Involucrados.

  • Generar el P23 Directorio.

* El CAE y/o el RDM pueden ayudar a elaborar un primer listado, que debe ser complementado con entrevistas con todos involucrados con quienes esto sea factible.

Los sistemas Web tienen C9 Múltiples involucrados con múltiples aéreas de especialización que tienen diversos grados de interés e influencia sobre el sistema. Identificar y considerar estas personas y factores durante la elaboración de los diversos planes disminuye los D2 Requisitos altamente cambiantes así como diversos riesgos.

CP
CAE
RAPE

W1.3 Revisar y ajustar la P1 Descripción del Proyecto considerando lo plasmado en el P4 Mapa de Involucrados.


Es común que entre los involucrados con mucha influencia existan discrepancias entre sus expectativas sobre el sistema. Es necesario tratar estos temas con el CAE y/o el CP para apoyarse en su influencia y autoridad para modificar la P1 Descripción del Proyecto y/o las expectativas e influencia de algunos involucrados.

RAPE
CAE

W1.4 (A1.3) Definir conjuntamente con el Cliente el P5 Protocolo de Entrega de cada uno de los entregables especificados en la P1 Descripción del Proyecto.


CAE
RAPE
RDM

W1.5 (A1.11) Generar el P6 Plan de Manejo de Riesgos.

  • Identificar, describir y evaluar los riesgos que pueden afectar el proyecto, contemplar riesgos relacionados con:

    • Los involucrados

    • La tecnología y metodología

    • La organización del proyecto

    • Agentes externos al proyecto.



  • Identificar la probabilidad e impacto de cada riesgo estimando sus implicaciones en los objetivos del proyecto (análisis cuantitativo).

  • Priorizar los efectos de los riesgos sobre los objetivos del proyecto (análisis cualitativo).

  • Desarrollar procedimientos para reducir la posibilidad de ocurrencia de los riesgos.

  • Desarrollar procedimientos para reducir el impacto de los riesgos.

Los riesgos pueden afectar notoriamente el tiempo y costo de un desarrollo WEB. El control y manejo de riesgo es una disciplina muy amplia y compleja. La tabla planteada como P6 Plan de Manejo de Riesgos es muy sencilla pero suficiente y adecuada para la mayoría de los proyectos.

RAPE

W1.6 Elaborar P7 Plan de Comunicación para el proyecto a partir de los hábitos efectivos de comunicación del equipo de trabajo, la P1 Descripción del Proyecto, el P4 Mapa de Involucrados y el P6 Plan de Manejo de Riesgos. Durante el proyecto analizar la efectividad del plan y ajustarlo en caso necesario.


Debido a las características de los desarrollos Web como el C6 Cambio continuo, los C9 Múltiples involucrados con múltiples aéreas de especialización y la C7 Tecnología diversa es necesario elaborar un P7 Plan de Comunicación particular para el proyecto. Un plan de comunicación adecuado considera no solo los canales de comunicación sino además las diversas aéreas de especialización, necesidades y antecedentes de los involucrados. El seguimiento y ajuste del plan disminuye drásticamente las D3 Dificultades de comunicación.










RAPE

RDM
ET
*

W1.7 (A1.10) Generar la P8 Cotización a partir de la P1 Descripción del Proyecto, el P6 Plan de Manejo de Riesgos y P5 Protocolo de Entrega.



  • Revisar la P22 Base de Conocimientos

  • Establecer supuestos para las variables desconocidas.

  • Establecer los plazos de entrega condicionados a las fechas de inicio, pagos y entregas de información.

  • Estimar el costo para generar cada entregable.

  • Definir plazos de entregas

  • Estimar el costo de los riegos.

  • Estimar la ganancia esperada.

  • Establecer el precio sumando los costos de los entregables, costos de riegos y la ganancia.





* En este momento aun no se ha formalmente establecido el equipo de trabajo pero es conveniente evaluar costos y tiempos con quienes se prevé que lo formarán o al menos con personas que tengan habilidades similares.

Una de las primeras necesidades del cliente es conocer el tiempo de desarrollo y el precio. La aprobación del proyecto depende en gran medida de estos factores.



Para cotizar con precisión requieren mayor conocimiento sobre el proyecto del que se puede tener en una etapa tan temprana del proyecto. La solución es cotizar haciendo supuestos sobre todas las variables desconocidas por ejemplo número y complejidad de pantallas, robustez, grado de optimización de descarga, requisitos del servidor, colaboración de los CEI y otros involucrados, etc. Dichas suposiciones deben ser comunicadas y especificadas como condicionantes de la cotización presentada.



Una buena opción es generar dos o tres cotizaciones con diversos supuestos y alcances. Es muy importante definir claramente las dimensiones de cada propuesta (aunque sea solo una) y no dejar puntos ambiguos.



Esto cubre la exigencia de una cotización y hace al cliente consciente de los muchos factores que influyen en los costos. Así se facilita lograr acuerdos ante los cambios en los requerimientos.



Para negociar los cambios se debe considerar la relación precio, alcance, tiempo. Los cambios en uno afectan los otros. Si alguno es invariable como el precio las alteraciones en los plazos afectarán el alcance. Si se desea aumentar el alcance deben variar el precio y/o el tiempo y si alguno de estos es invariable el cambio en el otro es mayor.



Hay muchas técnicas para la estimación de costos pero para equipos y proyectos pequeños la mayoría resulta más compleja y costosa que el proyecto en sí. La técnica más viable y recurrida es el juicio de expertos, generalmente los propios desarrolladores. Esta técnica puede ser muy imprecisa, pero se puede mejorar utilizando datos históricos (de la P22 Base de Conocimientos), el análisis de riesgos y contabilizando claramente las pantallas con que contaría cada propuesta.

CAE
RAPE

W1.8 Comunicar, negociar, aclarar y ajustar la P8 Cotización apoyándose en la P1 Descripción del Proyecto los P2 Bocetos y listas de sitios de similares y el P3 Glosario, hasta conseguir la aprobación del proyecto.


Aclarar oralmente lo escrito en la cotización y el contrato y en su defecto corregirlos.



Es muy importante aclarar todos los términos apoyándose en el P3 Glosario y los P2 Bocetos, Listas de Sitios de Similares y prototipos pues ayudan a disminuir la dificultad para describir las funciones y características de los sistemas WEB y la ambigüedad de conceptos y términos.



La forma de aprobación varía según el medio y la relación entre clientes y desarrolladores como por ejemplo contrato convenio VoBo, pero es imprescindible que quede registrada y sea clara para el RAPE, el CAE y el CP.

CAE
RAPE
ET

W1.9 Dar inicio formal al proyecto.

  • (A1.8) Conformar el Equipo de Trabajo, asignando roles y responsabilidades basándose en la Descripción del Proyecto.

  • Notificar a clientes y otros involucrados.

  • Iniciar el P9 Repositorio del Proyecto e incluir los productos generados.

El P9 Repositorio del Proyecto es crucial para que el equipo trabaje organizadamente. Crear y usar el repositorio del proyecto desde el inicio formal del proyecto y el equipo ayuda a su máximo aprovechamiento y adopción.

RAPE

W1.10 (A1.4) Identificar el número de ciclos y las actividades específicas que deben llevarse a cabo para producir los entregables y sus componentes.

  • Revisar los entregables documentados en la P1 Descripción del Proyecto.

  • Establecer el P10 Proceso General de Desarrollo.

  • Generar una primera versión general del P11 WBS para cumplir con el P5 Protocolo de Entrega.

  • Formar el P14 Plan de Proyecto, integrando el resultado como Ciclos y Actividades con el P6 Plan de Manejo de Riesgos, el P5 Protocolo de Entrega, el Costo Estimado obtenido al hacer la P8 Cotización y el Equipo de trabajo.

Es importe recordar que este es una primera versión del P11 WBS y los Ciclos y Actividades del P14 Plan de Proyecto. El objetivo es tener un panorama general de las diversas fases y actividades más generales necesarias para desarrollar el sistema. No es viable ni útil tratar de establecer a detalle un plan con todas las tareas del proyecto. El P11 WBS y el P14 Plan de Proyecto son productos que evolucionan a lo largo de todo proyecto.



Los primeros ciclos pueden dedicarse elaborar prototipos como los sugeridos en las técnicas T2 Prototipos Grises y T3 Prototipos Operativos.



A1. Realización de la fase de Inicio de Desarrollo y Mantenimiento de Software.


(Ver sección 6.3)


RAPE
RDM

W1.11 (A1.5) A partir del P11 WBS identificar y documentar la relación y dependencia de cada una de las actividades.

Esta actividad resaltara la dependencia del proyecto de algunas actividades que deben realizar los clientes como entregas de información o validaciones de la navegación, diseño gráfico o funcionalidad.

RAPERDM

W1.12 (A1.6) Establecer el Tiempo Estimado para desarrollar cada actividad.


RAPE

W1.13 (A1.7) Establecer los P12 Requerimientos de Adquisiciones y Capacitación definiendo las características y el calendario en cuanto a recursos humanos, materiales, equipo y herramientas, incluyendo la capacitación requerida para que el equipo de trabajo pueda desempeñar el proyecto.

Existen una gran cantidad de elementos preprogramados que se pueden encontrar en Internet gratis o por unos pocos dólares ahorrando muchas horas de trabajo. Estos módulos así como la capacitación y otras adquisiciones se deben registrar en el P12 Requerimientos de Adquisiciones y Capacitación.

RAPE

W1.14 (A1.9) Asignar fechas de inicio y fin a cada una de las actividades para generar el P13 Calendario de trabajo tomando en cuenta los recursos asignados, la secuencia y dependencia de las actividades.


RAPE

W1.15 (A1.12) Actualizar el P14 Plan de Proyecto antes de iniciar un nuevo ciclo.


RAPE
CAE

W1.16 Establecer el P15 Protocolo de Cambio.

El P15 Protocolo de Cambio debe planearse con el cliente. Sin embargo es importante que posteriormente el RAPE establezca que harán los miembros del equipo de trabajo cuando los clientes generen solicitudes de cambio que no sigan el protocolo pactado.

RAPE

W1.17 Capacitar al equipo respecto al P15 Protocolo de Cambio y su reacción para canalizar a otros involucrados cuando no lo sigan.


RAPERDM ET

W1.18 (A1.18) Dar inicio formal a un nuevo ciclo.


A2. Realización Inicio de ciclo

Los primeros ciclos deben utilizarse para afinar aun más el mutuo entendimiento de las necesidades y posibilidades del proyecto por parte de clientes y desarrolladores. Los T2 Prototipos Grises y/o los T3 Prototipos Operativos deben desarrollarse durante estos primeros ciclos de forma que se avance en el desarrollo del proyecto y a su vez se perfeccione la definición de requerimientos.

RAPERDM

W2.1 (A2.1) Acordar con el Responsable de Desarrollo y Mantenimiento del proyecto la asignación de tareas al Equipo de Trabajo.


RAPERDM

W2.2 (A2.2) Acordar la distribución de la información necesaria al equipo de trabajo con base en el P7 Plan de Comunicación.



A2. Realización de la fase de Requerimientos de Desarrollo y Mantenimiento de Software.

(Ver sección 6.3)



A3. Realización de la fase de Análisis y Diseño de Desarrollo y Mantenimiento de Software.


(Ver sección 6.3)





A4. Realización de la fase de Construcción de Desarrollo y Mantenimiento de Software.

(Ver sección 6.3)


A3. Evaluación y Control


RAPE
RDM

W3.1 (A3.1) Evaluar el cumplimiento del P14 Plan del Proyecto, con respecto al alcance, costo, calendario, equipo de trabajo, proceso y actualizarlo incluyendo Acciones Correctivas.


RAPE

W3.2 (A3.2) Dar seguimiento y controlar el P6 Plan de Manejo de Riesgos. Identificar nuevos riesgos y actualizar el plan.


A4. Cierre Fin de ciclo



A5. Realización de la fase de Integración y Pruebas

(Ver sección 6.3)


A6. Realización de la fase de Cierre

(Ver sección 6.3)

RAPECAE

W4.1 (A4.1) Formalizar la terminación del ciclo o del proyecto de acuerdo a la P5 Descripción del Producto y Entregables y Protocolo de Entrega establecido en el P1 Plan del Proyecto.


RAPE

W4.2 (A4.4) Integrar productos del proyecto a la P22 Base de Conocimientos.

Al terminar el proyecto además de la entrega y el comunicado apropiado para todos los involucrados. Es importante agregar los diversos productos del proyecto a la P22 Base de Conocimientos del equipo de trabajo o la organización de la que forma parte.




6.3 Actividades del Proceso de Desarrollo y Mantenimiento de software

Rol

Descripción

Observaciones

A1. Realización de la fase de Inicio

ET

W1.1 (A1.1) Revisar con los miembros del Equipo de Trabajo el P14 Plan de Proyecto actual para lograr un entendimiento común y obtener su compromiso con el proyecto.


A2. Realización de la fase de Requerimientos

RAPE
RDM
ET

W2.1 (A2.1) Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al P14 Plan de Proyecto actual.

  • Entregar un P23 Directorio adecuado a sus tareas y lo especificado en el P7 Plan de Comunicación a los miembros del ET.

Es importante destacar las actividades que dependen de los CEI y/o de miembros de diferentes especialidades dentro del Equipo de Trabajo pues muy factible que estas actividades se retrasen si no se monitorean correctamente. Los CEIs generalmente tienen otras ocupaciones y suelen retrasar las entregas. Se debe dar a los miembros del Equipo de Trabajo responsables de estas tareas un P23 Directorio adecuado; pues deben estar en contacto constante con los CEIs para ayudarlos y motivarlos a hacer sus entregas a tiempo.

AN
CAE
CEI
US
DU
DN

W2.2 (A2.2) Documentar o modificar la P16 Especificación de Requerimientos.

  • Identificar y consultar fuentes de información (clientes, usuarios, sistemas previos, documentos, etc.) para obtener nuevos requerimientos.

  • Analizar los requerimientos identificados para delimitar el alcance y su factibilidad, considerando las restricciones del ambiente del negocio del cliente o del proyecto.

  • Elaborar o modificar el prototipo de la interfaz con el usuario.

  • Generar o actualizar la Especificación de Requerimientos.

Debido a que en los sistemas web hay D2 Requisitos altamente cambiantes es necesario revisar los requerimientos en cada ciclo.



En la mayoría de los proyectos es más conveniente usar la técnica T1 Análisis de requerimientos enfocado a metas que otros métodos de levantamiento de requerimientos. Este método es más eficiente cuando existen muchos involucrados y objetivos muy difusos o generales que son muy frecuentes en los desarrollos WEB.


CAE
CEI
US

W2.3 (A2.5) Validar la P16 Especificación de Requerimientos. Utilizar P2 Bocetos, listas de sitios de similares y prototipo para mejorar el proceso de comunicación.

Debido a la gran cantidad de cambios es importante validar siempre con el cliente. Esto ayuda a detectar los malentendidos a tiempo, disminuyendo los cambios por este concepto y ayuda a renegociar los plazos, el precio y el alcance, pues el cliente es más consciente de los cambios y sus implicaciones. Utilizar P2 Bocetos, listas de sitios de similares y prototipos es indispensable para disminuir las D3 Dificultades de comunicación.


AN
DU
DN

W2.4 (A2.6) Corregir los defectos encontrados en la P16 Especificación de Requerimientos con base en el Reporte de Validación y obtener la aprobación de las correcciones.


RPU
AN

W2.5 (A2.7) Elaborar o modificar P17 Plan de Pruebas.

Por la característica C7 Tecnología diversa al generar el P17 Plan de Pruebas se debe poner especial atención en probar el sistema en navegadores que se espera que tendrán los usuarios objetivo. Generalmente es recomendable probar la funcionalidad en al menos los dos navegadores más populares. Pero esto puede variar según el grupo de usuarios objetivo.

A3. Realización de la fase de Análisis y Diseño

RAPE
RDM

W3.1 (A3.1) Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al P14 Plan de Proyecto actual.


ET

W3.2 Probar y elegir las tecnologías a utilizar.

Es necesario probar que la combinación de lenguajes a utilizar funciona bien en conjunto. Probar especialmente los lenguajes y técnicas a utilizar en al menos los dos navegadores más populares (y/o aquellos que el proyecto requiera) pues es muy común que estos tengan comportamientos diferentes ante un mismo código.

AN
DI
DU
DN

W3.3 (A3.2) Documentar o modificar el P18 Análisis y Diseño:

  • Analizar la P16 Especificación de Requerimientos para generar la descripción de la estructura interna del sistema y su descomposición en subsistemas, y éstos a su vez en componentes, definiendo las interfaces entre ellos.

  • Describir el detalle de la apariencia y el comportamiento de la interfaz con base en la P16 Especificación de Requerimientos de forma que se puedan prever los recursos para su implementación.

  • Observar los requisitos de información del sistema de forma que se pueda diseñar una estructura de navegación simple y efectiva y planear la generación y manutención de la información del sistema

  • Describir el detalle de los componentes que permita su construcción de manera evidente.

  • Generar o actualizar el P18 Análisis y Diseño.


Un sistema WEB se debe diseñar en tres aspectos la funcionalidad del software, que es prácticamente idéntico a los sistema tradicionales, la navegación que es propia de los sistemas WEB y la interfaz que aunque existe en los sistemas tradicionales en los sistemas WEB resulta más compleja e importante como se explica en la característica C3 Estética y diseño grafico preponderantes.



En estos tres aspectos es indispensable aplicar la técnica T5 Uso de patrones. A partir de lo observado al generar P2 Bocetos, Listas de Sitios Similares y Prototipos y la propia P16 Especificación de Requerimientos se deben seleccionar, mejorar e integrar los patrones para el sistema guiándose en los objetivos del sistema y lo señalado en las T6 Técnicas para el diseño de arquitecturas, las T7 Técnicas de Diseño gráfico, las T8 Técnicas para el diseño de navegación y las T9 Técnicas para presentar la información.

A4. Realización de la fase de Construcción

RDM

W4.1 (A4.1) Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al P14 Plan de Proyecto actual.





PR

W4.2 (A4.2) Construir o modificar el(los) Componente(s) de P19 Software:

  • Implementar o modificar Componente(s) con base a la parte detallada del P18 Análisis y Diseño.

  • Definir y aplicar pruebas unitarias para verificar que el funcionamiento de cada componente esté acorde con la parte detallada del Análisis y Diseño.

La actividad de programación en sí de los sistemas Web no varía respecto a los sistemas tradicionales.

A5. Realización de la fase de Integración y Pruebas

RDM

W5.1 (A5.1) Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al P14 Plan de Proyecto actual.


PR
RPU
RE

W5.2 (A5.2) Realizar integración y pruebas.

  • Integrar los componentes en subsistemas o en el sistema de P19 Software y aplicar las pruebas siguiendo el P17 Plan de Pruebas

  • Corregir los defectos encontrados o programarlas para el siguiente ciclo.

  • Generar el P20 Registro de errores

Por la salvedad de que es recomendable probar con más de un navegador. Estas pruebas se pueden ejecutar prácticamente igual que en una aplicación tradicional. Es necesario utilizar el P20 Registro de Errores y Cambios y se recomienda usar herramientas específicas para este fin.



Como se indica en T10 Técnicas para probar las aplicaciones WEB es válido apoyarse en los propios clientes y usuarios para lograr una mayor detección de fallos. Si el proyecto lo permite es aconsejable pactar un periodo de pruebas en el que el equipo de desarrollo corrija los errores que encuentren los propios usuarios.

A6. Realización de la fase de Cierre

RM

W6.1 (A6.1) Documentar el P21 Manual de Mantenimiento.