Guía para el desarrollo de aplicaciones WEB, basada en MoProSoft. - Productos -

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
7.- Técnicas útiles en el desarrollo WEB
8.- Productos
P1 Descripción del Proyecto
P2 Bocetos, Listas de Sitios Similares y Prototipos
P3 Glosario
P4 Mapa de Involucrados
P5 Descripción del Producto y Entregables
P6 Plan de Manejo de Riesgos
P7 Plan de Comunicación
P8 Cotización
P9 Repositorio del Proyecto
P10 Proceso General de Desarrollo
P11 WBS
P12 Requerimientos de Adquisiciones y Capacitación
P13 Calendario
P14 Plan de Proyecto
P15 Protocolo de Cambio
P16 Especificación de Requerimientos
P17 Plan de Pruebas
P18 Análisis y Diseño
P19 Software
P20 Registro de Errores y Cambios
P21 Manual de Mantenimiento
P22 Base de Conocimientos
P23 Directorio

Referencias bibliográficas
Referencias a aplicaciones
Sitios de interés



8.- Productos

Es importante destacar que se habla de productos y no de documentos porque no se generan forzosamente documentos de texto convencional. El tipo y profundidad de cada producto debe adaptarse a cada equipo de trabajo y proyecto. Documentar y organizar es sin duda útil pero también costoso; no tiene sentido realizar un proyecto donde la documentación en si cueste más que el valor que aportará el proyecto. Normalmente entre más involucrados, tiempo y esfuerzo requiera el proyecto más formal debe de ser la documentación pero intervienen muchos otros factores.

En un trabajo muy sencillo, para un amigo cuya necesidad se conoce bien, puede ser suficiente (pero poco recomendable) simplemente platicar y establecer oralmente qué se requiere, escribir un breve listado, desarrollar el sistema y entregarlo. El mismo trabajo para un desconocido probablemente requiera no solo mas dialogo sino esquemas y una lista completa de las secciones y prestaciones del sistema. Algo muy similar para una empresa requiere, además de las secciones y prestaciones del sistema, especificar tráfico esperado, tiempo de garantía, etc.

Lo mismo ocurre con otros productos si hay mas involucrados o el proyecto es más complejo. Si el equipo de trabajo prefiere XP (eXtreme Programming) o RUP (Rational Unified Process) el plan de desarrollo y otros productos son, en su forma, muy diferentes pero en su fondo y objetivos similares.

Lo importante es tener en mente que los productos son útiles, deben adaptarse según las circunstancias para optimizar el trabajo presente y futuro del equipo así como la calidad del sistema. Los productos son unidades de información que se deben generar y/o conseguir y organizar. Se pueden usar diversos medios y técnicas, siempre que la información se pueda plasmar, consultar y comunicar cuando sea necesario. Los productos tampoco implican que se requiere un documento o elemento por cada uno, solo que es necesario tener esa información. En el propio MoProSoft se puede ver que hay productos conformados por otros productos. Por ejemplo es posible que en un proyecto el contrato especifique los entregables y las fechas de entrega mientras que en otro puede no haber un contrato formal y la aceptación y los entregables estén en documentos separados.

La principal función de los productos es registrar y comunicar. Los productos deben ayudar al trabajo aportando claridad, testimonio y una referencia común entre los diferentes involucrados y los miembros del equipo de desarrollo. Hay que tener en cuenta que el alcance de los productos debe ir más allá del proyecto en cuestión y servir como base para facilitar futuros proyectos. Es necesario encontrar un punto medio, demasiada documentación y detalle volverá su consulta más compleja que el volver a enfrentar los problemas en sí. Por otra parte productos breves e incompletos generan problemas durante el proyecto y resultaran inútiles en el futuro.

Los productos evolucionan con el proyecto, no hay que pretender hacer productos completos y perfectos en cuanto son mencionados en las actividades. Hay ciclos de desarrollo y además se debe trabajar simultánea y continuamente en diversos productos que dependen unos de otros. A continuación listamos los productos en el orden en que cronológicamente se inician.



P1 Descripción del Proyecto

Ejemplos: Descripción del proyecto

Descripción: Este documento explica qué se necesita, para qué se necesita y qué grado de automatización, perfeccionamiento y calidad se requiere. Está formado por las siguientes secciones:

Utilidad: Este producto es el eje conductor del proyecto; indica que se hará y para qué. Es indispensable para cotizar, planear y diseñar correctamente; simplifica la comunicación y ayuda a unir al equipo y todos los involucrados.

Observaciones:

Los componentes de la Descripción del Proyecto suelen estar dispersos en diversos documentos y medios y por lo tanto es fácil que la descripción esté incompleta. Generalmente los clientes proveen uno o más componentes al solicitar el proyecto pero no todos. Se debe cerciorar su recopilación, documentación y validación con los clientes y/o el responsable de gestión de proyectos. Todo el equipo de trabajo debe conocer al detalle la Descripción del Proyecto pues solo así podrán trabajar, evaluar y decidir correctamente. En general en toda interacción con cualquier involucrado es recomendable recordar lo plasmado en el Descripción del Proyecto, pues de lo contrario cada involucrado genera expectativas propias sobre el sistema. Por ejemplo: Se está desarrollando un sistema de administración para Empresaejemplo S.A.de C.V. donde los objetivos y el alcance no están claramente especificados. Es muy probable que los clientes del área de contabilidad pidan un sistema que reciba las facturas escaneadas, las reconozca y las procese automáticamente, los del almacén pidan que el sistema haga pedidos automáticamente a los proveedores, y los programadores deseen probar un complejo sistema de encriptación para evitar que se levanten pedidos o facturas falsos. En el mismo escenario, pero con el objetivo especifico de mostrar al dueño en todo momento el estado de la empresa y definiendo que el alcance de una primera etapa es únicamente reportar el estado de la empresa sin intervenir directamente en ninguna área, ninguno de los involucrados hubiese generado esas expectativas ni todas las horas hombre de discusión, estimación y validación que implican.

En sistemas WEB es posible que incluso algunos componentes de la descripción del proyecto cambien, conforme clientes y desarrolladores conocen más del proyecto. El impacto de dichos cambios suele ser más complejo y costoso de lo que los clientes imaginan y si no se documentan y validan todos estos es probable que los cambios no sean percibidos como tales y menos aun que los clientes entiendan los retrasos y costos extra que ocasionan.

El primer punto para desarrollar la descripción del proyecto es revisar la información que se tenga hasta el momento. Si existe un contrato es muy probable que este ya contenga todo o casi todos los apartados. Si en su organización hay un responsable de gestión de proyectos éste debería haber generado una Descripción del Proyecto adecuada. Los correos electrónicos y/o las conversaciones con el cliente patrocinador (CP) y/o administrador encargado (CAE) pueden proveer toda la información faltante. Una vez que se tenga toda la información es indispensable documentarla y sobre todo corroborarla y comunicarla con el CAE aun cuando se haya basado en información que él mismo haya proporcionado. Suponer que todos ya conocen la Descripción del Proyecto es uno de los errores más costoso y comunes. Es imprescindible que tanto el CAE como el responsable de la administración de proyecto especifico RAPE tengan constancia documental de todos los componentes de la descripción del proyecto. Es importante además verificar que cada componente se entiende y el CAE y el RAPE están de acuerdo en su contenido independientemente de en qué documentos se encuentren. Así mismo el equipo de desarrollo y casi todos los otros involucrados deben ser informados de los objetivos y alcances del sistema.

 

 

P2 Bocetos, Listas de Sitios Similares y Prototipos

Ejemplos: Descripción del proyecto Datos en pantallas Diseño gráfico Diagramas MDA Dummie Menús por usuario

Descripción: Referencia a sitios similares o con características similares a las deseadas en el sistema. Dibujos sencillos que describen alguna idea o patrón y sistemas con funcionalidad parcial o enfocados solo a algún aspecto del sistema.

Utilidad: Ayudan a expresar o describir conceptos, funciones y características difíciles de describir con palabras y/o diagramas UML. Aumenta notoriamente la efectividad de la comunicación casi sin esfuerzo adicional.

Observaciones:

Muchas de las solicitudes de cambios en los desarrollos WEB ocurren hasta que los clientes ven el sistema o algún modulo operando. Los prototipos, modelos y ejemplos ayudan a prevenir este problema detectando los cambios necesarios en etapas más tempranas. Pues permiten visualizar diversos aspectos del sistema antes de construirlo completamente. Los prototipos y diagramas pueden abarcar todos los aspectos del sistema pero son mucho más efectivos al enfocarlos en solo uno de estos, como la navegación, la interfaz, el contenido, la funcionalidad, etc. Por ejemplo para determinar qué pantallas habrá y qué información se presentará en cada una puede construirse un prototipo gris, que es un sitio sin ningún elemento de diseño grafico pero con la información que llevara cada pantalla. Esto ayuda a que el cliente y los diversos evaluadores se enfoquen en los contenidos sin distraerse por el diseño. De la misma forma se pueden desarrollar diversas alternativas graficas en programas de creación de imágenes para determinar el estilo visual del sitio sin que los contenidos específicos de una pantalla o su funcionalidad afecten el juicio de los elementos estéticos. La navegación es generalmente más fácil de entender modelándola con diagramas como los que para este propósito ofrecen prácticamente todos los métodos de modelado WEB como OOWS, WebML, WebRatio, OOHDM, etc. Finalmente también es recomendable extender la lista de sitios similares o relacionados con referencias mas explicitas de qué funcionalidades se desean emular y con qué cambios e incluso qué se desea evitar. No solo no es necesario inventar el hilo negro tampoco es práctico describirlo.

El trabajo con prototipos funcionales o versiones simples y reducidas del sistema puede resultar útil también como parte del desarrollo en sí. Esta aproximación está siendo ampliamente utilizada en Internet, es por esto que a menudo nos encontraremos con servicios denominados BETA. Es especialmente útil cuando se desea contemplar la opinión de los usuarios finales que en muchos casos no se conocen ni se pueden contactar personalmente hasta que el sistema está operando. En este esquema se ponen en operación versiones incompletas del sistema pero con varias de sus funcionalidades ya operativas y los propios usuarios aportan retroalimentación tanto sobre los requerimientos y características del sistema como acerca de sus errores. Este mecanismo puede resultar mucho más efectivo rápido y económico que las pruebas tradicionales en cierto tipo de sistemas.

 

 

P3 Glosario

Ejemplos: Glosario

Descripción: Definición en el contexto del proyecto de términos clave y que puedan resultar ambiguos, desconocidos y/o tengan significados específicos dentro proyecto.

Utilidad: Evita la confusión, mejora y agiliza la comunicación.

Observaciones:

El glosario explicara en términos del propio proyecto palabras que se usen normalmente en este. Es una herramienta muy sencilla y útil que es suele ser muy poco apreciada. Tener claridad en los términos puede ahorrar muchas horas de discusión y trabajo. Los sistemas WEB involucran a personas con una gran variedad de especialidades y su vocabulario puede resultar ambiguo. Por ejemplo en un sistema para una escuela para el personal de la escuela la palabra clase se refiere a un grupo de alumnos con un profesor en un salón cubriendo los materiales de un curso X en un horario Y. Para el diseñador de la interface se trata de una definición de estilos CSS. Los programadores pueden interpretar dicha palabra tanto como un registro de la tabla clases como o como un elemento de conceptual de la programación orientada a objetos. Esto puede ocurrir con cualquier palabra y en ocasiones su efecto se circunscribe únicamente a un grupo de personas específico. Por ejemplo en una oficina de recursos humanos un puesto y una plaza pueden ser usados indistintamente y mientas que en otra (aun dentro de una misma organización) una plaza puede ser un puesto ya ocupado por empleado. Por esto es indispensable aclarar y definir los términos en cada proyecto y en ocasiones con cada uno de los involucrados por parte del cliente, pues incluso dentro de una misma organización pueden dar un uso diferente a algunos términos.

El glosario es una herramienta para mejorar la comunicación y esta se da desde el inicio del proyecto al establecerse los requerimientos iníciales. El RAPE y el CAE y/o el CP deben clarificar diversos términos para poder elaborar los requerimientos de forma efectiva y sin tener conflictos posteriores. Es desde este momento que el glosario se debe utilizar.

El glosario no debe hacerse con la expectativa de que será disciplinadamente leído por quienes no conocen algún termino. El glosario no es un diccionario y sus términos no son exclusivamente palabras que algunos involucrados desconocen. Son además palabras que resultan ambiguas dentro del proyecto por la gran variedad de disciplinas, áreas e involucrados que abarca un sistema WEB. La gran mayoría de los involucrados asumirá que estas palabras significan para todos lo mismo que para él y no sentirá la necesidad de consultar el glosario.

El glosario sirve para recordar a quien ya es consciente de esas ambigüedades y usos particulares qué sentido tiene en particular dentro del proyecto. En todo proceso de comunicación quienes transfieren la información deben detenerse al usar dichos términos y verificar con su interlocutor que entienden lo mismo al usarlos apoyándose en el glosario. En otras palabras el glosario sirve cuando se usa activamente en las conversaciones.

 

 

P4 Mapa de Involucrados

Ejemplos: Mapa de involucardos

Descripción: Plano que ubica en uno de cuatro cuadrantes a todos y cada uno de los involucrados, documentando su actitud, interés e influencia ante el proyecto.

Utilidad: Documentar la actitud, interés e influencia ante el proyecto de cada involucrado.

Observaciones:

El mapa de involucrado ubica en dos ejes, poder e interés, a los involucrados en un sistema esto permite catalogarlos en cuatro categorías que dan pautas de que tiempo de acciones tomar con cada uno. Las categorías son:

Adicionalmente es recomendable utilizar colores para establecer su actitud hacia el proyecto, rojo = negativa, naranja = neutra y verde = positiva.

 

 

P5 Descripción del Producto y Entregables

Ejemplos: Ver P14 - Plan de proyecto

Descripción: Documento que especifica que se entregará.

Utilidad: Documenta la meta acordada dando claridad y certidumbre a clientes y desarrolladores.

Observaciones:

Es indispensable hacerlo al inicio del proyecto y que lo discutan el RAPE y el CAE y el RAPE y el ET también debe actualizarse con cada cambio. Es importante especificar además a quien, donde y bajo qué condiciones se entregará, es decir de sebe acordar un protocolo de entrega. Tanto clientes como desarrolladores deben tener constancia de lo pactado. Es muy común que esta información esté incluida en el contrato pero no siempre es así. Si es el caso se debe plantear y acordar que como cuando y donde se debe entregar. Es importante recordar también que puede haber pagos y/o entregas por parte de los clientes y generalmente se vinculan unas con otras.

Este es producto importante y seguramente muchos involucrados harán varias consultas a lo largo del proyecto. Importante que sea un producto fácil de identificar y encontrar, si por ejemplo se por utilizar el correo electrónico para comunicarlo y simultáneamente almacenarlo es aconsejable dedicar un correo únicamente a este producto y no mezclarlo con otros. Igualmente si está incluido en el contrato es recomendable plasmar la información por separado en otro medio de forma tal que se pueda difundir sin distribuir el contrato que puede tener información no apta para difundirse.

 

 

P6 Plan de Manejo de Riesgos

Ejemplos: Plan de manejo de riesgos

Descripción: El repositorio del proyecto es el almacén de todos los productos del proyecto.

Utilidad: Mantiene la información del proyecto accesible y organizada.

Observaciones:

Debe Los riesgos son inherentes a todo proyecto. Prevenirlos o reaccionar adecuadamente ante su ocurrencia es indispensable. Un Plan de Manejo de Riesgos viable y sencillo es una tabla que relaciona los riegos que ya hayas identificado que pueden ocurrir con la probabilidad de que ocurran el grado en que afectarían al proyecto y diversas medidas de contención y/o reacción para reducir el riesgo de incidencia y/o los efectos negativos. En caso de que tu grupo o empresa ya cuente con una base de conocimientos debes consultar los planes de riesgo de proyectos similares. Es importen notar que en proyectos WEB puedes considerar (salvo en muy contadas excepciones) que el cambio en los requisitos ocurrirá y por lo tanto no es un riesgo si no una característica. Uno de los riesgos que más frecuentemente ocurren es que los Clientes encargados de información se retrasen en sus entregas. Pero hay muchos otros como que el servidor de trabajo y el desarrollo tengan diferencias de configuración que vuelvan algún modulo del sistema inoperante, que se domine el lenguaje de desarrollo, que no se tengan fondos para hacer las adquisiciones más importantes, etc.

 

 

P7 Plan de Comunicación

Ejemplos: Plan de comunicación

Descripción: Comunicación especifica las formas y medios de comunicación entre los diversos involucrados en el proyecto.

Utilidad: Reduce los problemas de comunicación.

Observaciones:

El plan de El glosario, la agenda y los protocolos de cambio son componentes indispensables pero no suficientes. Es necesario establecer diversas normas o guías como pueden ser: los criterios para hacer reuniones, formatos de los correos, que tipo de información le es útil a cada involucrado, etc. Depende del equipo de desarrollo los clientes y proyecto el detalle con que esto se documenta. Es importante no suponer nada, hay clientes que tienen requerimientos específicos de comunicación, suele haber involucrados que no conocen expresiones, términos ni/o agendas que pueden compartir otros involucrados que se conozcan previamente o compartan la misma formación.

 

 

P8 Cotización

Ejemplos: Cotizacion 1 Cotizacion 2

Descripción: Documento que especifica formalmente el costo del sistema para el cliente. Además de los costos para el cliente las cotizaciones deben incluir condiciones de entrega tanto del sistema y sus entregables así como de los recursos que proporcione el cliente patrocinador al equipo de trabajo.

Utilidad: Establece los recursos que el cliente patrocinador debe proporcionar al equipo de desarrollo para que se construya el sistema.

Observaciones:

Se trate de un proyecto interno o de la venta de un sistema a medida, una de las principales demandas de los clientes es saber tiempo y costo. Hay muchas técnicas para calcular estos datos como puntos de función, regla de los tres puntos, datos históricos, juicio de expertos, etc. La elección de una técnica depende del equipo y el proyecto. Una práctica muy común es usar el juicio de expertos respaldada con información de proyectos anteriores. La estimación de costos en sí es toda una disciplina más allá del alcance de esta guía. Independientemente de la técnica que se utilice en la mayoría de los proyectos web se tendrá que hacer una cotización con requerimientos muy incompletos y sujeta a cambios.

La solución es cotizar haciendo supuestos sobre todas las variables desconocidas. Dichas suposiciones deben ser comunicadas y especificadas como condicionantes de la cotización presentada. Esto cubre la exigencia inicial y hace consciente al cliente de los muchos factores que influyen en los costos. Permite mejores acuerdos ante los cambios en los requerimientos.

Conforme se trabaje más en el proyecto, se resuelvan dudas y aparezcan cambios la cotización inicial se transformará en una cotización definitiva. Los supuestos pasarán a ser condiciones y según el proyecto y las prioridades del cliente se establecerán nuevos requerimientos, precios, plazos y/o niveles de calidad.

Es importante no dar fechas, precios o funcionalidades específicas sin condicionarlas. Hay que vincular estos factores a las acciones del cliente de las que dependen, como la aprobación del proyecto, los pagos y la oportuna participación y entrega de información. Por ejemplo: La primera fase del sistema que consta de… se entregará al mes de haber recibido los formularios de… Esto protege a los desarrolladores de la incertidumbre inicial y hace consciente al cliente de su corresponsabilidad en el proyecto. Si el proyecto exige la entrega en una fecha específica entonces se debe condicionar el precio y/o la calidad y/o se debe establecer una fecha límite para iniciar el proyecto.

 

 

P9 Repositorio del Proyecto

Ejemplos: Repositorio

Descripción: Almacén de todos los productos del proyecto

Utilidad: Mantiene en forma accesible y organizada toda la información referente al proyecto.

Observaciones:

Debes tener normas para mantener organizado el repositorio del proyecto. El repositorio debe responder a la naturaleza de tus productos y puede incluso constar de una combinación de medios y elementos. Pude ser un directorio en el sistema de archivos de tu computadora, un grupo de yahoo, msn, etc, un sitio operando con sistema especializado como sourceforge, un pizarrón con post-it’s como en scrum y/o un archivero con los documentos impresos, etc. Lo importante es que cada miembro del equipo de trabajo sepa que lo puede acezar e incluso modificar lo que sea su responsabilidad así como cuándo y cómo hacerlo. En todos los medios que lo permiten debes tener un sistema de nombrado de los productos que permita almacenar y distinguir las diferentes versiones de cada documento. Igualmente es importante hacer un respaldo periódico del repositorio, aun en el caso de medio fisco como el pizarrón o los documentos impresos esto es posible con fotografías y/o fotocopias.

 

 

P10 Proceso General de Desarrollo

Ejemplos: Proceso General de Desarrollo

Descripción: Descripción de las fases y metodología de trabajo que se adoptara en el proyecto.

Utilidad: Dar un punto de partida a la planificación del proyecto.

Observaciones:

El Proceso General de Desarrollo es el punto de partida para determinar las actividades. Está muy ligado con la metodología de trabajo del equipo. Las diversas metodologías dividen el desarrollo de software en diferentes fases. Por ejemplo en RUP se establecen Inicio, elaboración, construcción y transición y Scrum divide el desarrollo en ciclos que llamados Sprints que a su vez subdivide en sprints diarios y juntas de planeación. A partir de estos marcos de referencia que impone la metodología de trabajo debes establecer las características propias del proyecto cuantos ciclos o sprints, las fechas de entregas ya pactadas, etc. Esto da una lista de fases a hitos para el desarrollo de un sistema específico. A partir de estas grandes fases se establecen paulatinamente las actividades necesarias para general el trabajo necesario en cada una.

 

 

P11 WBS

Ejemplos: Ver P13 Calendario - WBS-Calendario

Descripción: Lista de las tareas y subtareas necesarias para completar el sistema

Utilidad: Descompone tareas complejas en tareas pequeñas, comprensibles y ejecutables por los involucrados.

Observaciones:

WBS son las iníciales de Work Break Down Stucture o estructura de descomposición del trabajo. Se toma la tarea principal, por ejemplo hacer la Especificación de requerimientos y se divide en sub tareas necesarias para lograrlo, ver al cliente, buscar alternativas de solución, presentar opciones al cliente, etc. Luego se toma cada una de estas y se vuelven a dividir en subtareas y así sucesivamente, hasta llegar al detalle deseado. Que debe contener actividades puntuales que los diferentes involucrados puedan ejecutar. Una forma muy efectiva de representarlo es utilizando un árbol o listado indexado en el que se listan todas las tareas y subtareas necesarias para desarrollar el sistema. Muchos elementos dependen de la definición del proceso de desarrollo sin embargo estos son a su vez necesarios para detallar correctamente todas las actividades y/o productos y tener así un WBS completo. Para romper este círculo de dependencias se elabora inicialmente un proceso de desarrollo general y conforme el tiempo y el proyecto avanzan se van detallado las secciones que sean pertinentes del mismo. Ve la sección de ejemplos para mayor detalle.

 

 

P12 Requerimientos de Adquisiciones y Capacitación

Ejemplos: Plan de adquisiciones

Descripción: Lista de elementos y conocimientos que se tienen adquirir para poder realizar el proyecto.

Utilidad: Ayuda a la planeación y oportuna ejecución de las adquisiciones y capacitaciones.

Observaciones:

Muchos sistemas tienen requerimientos que implican el uso de lenguajes y herramientas de programación desconocidos por los programadores. En otros es más conveniente comprar algún modulo ya sea como un producto comercial o solicitado a medida a otro grupo de desarrolladores. Lo mismo pude ocurrir con equipo de computo, boletos para viajar, etc. Tener registro de todo esto es indispensable para adquirirlo oportunamente y no retrasar o alterar las actividades planeadas ni la calidad del producto.



 

P13 Calendario

Ejemplos: WBS-Calendario

Descripción: Especificación de las fechas planeadas de inicio y fin de las diversas actividades.

Utilidad: Clarifica que se debe hacer cada día y fase para desarrollar el sistema.

Observaciones:

Ubica en el tiempo las actividades establecidas en el WBS y por lo tanto evoluciona junto con este. Para establecer el orden cronológico de las tareas necesitas determinar dos factores las dependencias que existen entre una tarea y las otras pues por ejemplo no se puede empezar a programar si haber hecho los requerimientos y quien ejecutara cada tarea. En proyectos grandes y complejos la distribución de las tareas en el tiempo y la asignación de los recursos humanos y materiales para que se puedan llevar acabo se vuelve tan complicado como importante. Hay muchas herramientas para hacer esta asignación desde programas especializados como Microsoft Project y OpenWorkBench hasta rótulos y cartulinas calendarizado donde se marcan las tareas y los responsables de cada una. Uno de los modelos más populares para representar la calendarización de actividades es el diagrama de Gantt.

 

 

P14 Plan de Proyecto

Ejemplos: Plan de Proyecto

Descripción: Documento formal usado como guía para la ejecución y control del proyecto.

Utilidad: Contiene toda la información para administrar y monitorear la ejecución del proyecto.

Observaciones: Este producto se forma al integrar los siguientes productos:

• Ciclos y Actividades

• Tiempo Estimado

• Plan de Adquisiciones y Capacitación.

• Equipo de Trabajo

• Costo Estimado

• Calendario

• Plan de Manejo de Riesgos

• Protocolo de Entrega

 

 

P15 Protocolo de Cambio

Descripción: Descripción clara y paso a paso del procedimiento para solicitar y aceptar los cambios así como de cómo reaccionar ante solicitudes de cambios de los clientes que no sigan el protocolo.

Utilidad: Establece las pautas para atender y procesar los cambios disminuyendo el desorden y el retrabajo.

Observaciones:

La Los cambios son muy frecuentes en todos los proyectos y los desarrollos WEB que destacan de entre otros sistemas justamente por la gran cantidad estos. El descontrol en los cabios puede llevar fácilmente al fracaso del proyecto y en cualquier caso generara trabajo innecesario y tensión entre desarrolladores y clientes. Lo más recomendable es establecer un procedimiento junto con los clientes para llevar acabo dichos cambios. Pero es muy poco frecuente que el cliente siga dicho procedimiento en primera instancia, los clientes expresan sus deseos y expectativas en cuanto les surgen y generalmente en forma oral y ante cualquier miembro del equipo de desarrollo. Las propias dimensiones del proyecto y la estrecha relación que puede tener una empresa pequeña o un equipo de desarrollo con los clientes fomentan que se pacten de informalmente muchos cambios en el proyecto. Es necesario establecer en el equipo de trabajo un protocolo para canalizar y tratar adecuadamente las solicitudes informales de cambios. El manejo de los cambios debe incluir una forma para solicitarlos, evaluarlos y aprobarlos o rechazarlos una forma para documentarlos y comunicarlos. Cuando un miembro del equipo de desarrollo reciba una solicitud de cambio informal debe evitar aceptarla o rechazarla y por el contrario guiar al solicitante a que siga el procedimiento pactado. También pueden existir cambios que no involucren a los clientes como si se decide cambiar una clase o método es importante que estos cambios se traten con el mismo cuidado que los solicitados por los clientes pues las consecuencias de no comunicarlos ni evaluar sus impactos son prácticamente idénticas.

En cuanto a la documentación y la comunicación esta debe ser congruente con los otros productos y modelo de trabajo elegido. En muchos proyectos se recomienda que incluso la solicitud de cambio sea un documento formal. Sin embargo se pueden establecer otros mecanismos como la solicitud y discusión personal con el RAPE y el CAE. En todo caso un cambio aprobado se debe documentar y comunicar incluyendo que productos afecta, porque se hizo y quienes evaluaron y autorizaron el cambio. Así por ejemplo si se están manejando casos de uso en UML con un repositorio accesible desde Internet es congruente actualizar los archivos cambiando el número de versión y enviar un email a todos los desarrolladores. Si en cambio se está usando un método un pinzaron como sugiere Scrum se deben plasmar los cambios en este hacer mención de los mismos durante la reunión inicia los sprints.



 

P16 Especificación de Requerimientos

Ejemplos: Ejemplo 1 Ejemplo 2 Inicial Ejemplo 2 Final

Descripción: Describe a detalle qué funcionalidad y datos es necesario que tenga el producto final para cumplir lo planteado en la descripción del proyecto. También puede incluir otros requisitos referentes al equipo de trabajo, los plazos, la calidad y/o características del sistema.

Utilidad: Completa la información de la descripción del proyecto. Clarifica qué información debe contener y qué debe hacer el sistema para cumplir con los objetivos. Especifica características necesarias para que el sistema y el proyecto operen y/o se desarrollen en su contexto y circunstancias específicas.

Observaciones:

Los requerimientos determinan el diseño y la construcción del sistema y cambian constantemente en los desarrollos WEB. Es necesario no solo documentarlos sino documentar sus cambios y aclarar las consecuencias de dichos cambios con el equipo de trabajo y los clientes.

Éste es uno de los documentos más variables en los desarrollos WEB y se debe ajustar durante todas las etapas. Su elaboración y perfeccionamiento es paulatina y suele darse gracias a constantes revisiones con los clientes.

Los requerimientos suelen catalogarse en dos tipos, los funcionales que describen qué debe hacer el sistema, por ejemplo listar facturas o imprimir recibos, y los no funcionales que especifican las otras características del sistema como pueden ser el uso de un leguaje especifico, capacidad de operar en sistema operativo determinado, el formato en que se deben guardar los datos, que colores, logos o letras se deben usar en la interfaz grafica, etc.

Para documentar los requerimientos no funcionales suele ser suficiente listarlos. Generalmente basta hablar con el CAE y/o el SCT. En el caso de los funcionales existen algunas posibilidades como son las listas, los casos de uso de UML e incluso hay quienes han utilizado los diagramas de BPMN (modelado de procesos de negocios por sus siglas en ingles). Lo importante es que la técnica seleccionada cumpla lo mejor posible dos condiciones: que sea suficientemente expresiva y precisa así como comprensible por clientes y desarrolladores. La documentación de los requerimientos requiere del intercambio de información entre desarrolladores y clientes. Se recomiendan entrevistas personales y telefónicas combinadas con el intercambio y revisión de los documentos en sí.

En algunas ocasiones los requerimientos funcionales se manejan en forma de lista con el cliente y sin embargo para fines del desarrollo se generan y utilizan los diagramas de casos de uso.

 

 

 

P17 Plan de Pruebas

Ejemplos: Pruebas de integración

Descripción: Descripción de las evaluaciones que se deben hacer al sistema, calendarización y responsables de las mismas. Las evaluaciones incluyen que se componente se está evaluando datos a introducir y que se espera obtener como resultado correcto.

Utilidad: Disminuye los errores en el sistema y el costo de encontrarlos

Observaciones:

Las pruebas aseguran un nivel mínimo de operatividad y funcionalidad del sistema. Durante la construcción del mismo se debe establecer que se probara y a qué grado. Generalmente se prueban los diversos componentes por separado y posteriormente todos juntos. Hay una gran variedad de metodologías de pruebas desde revisiones pro el mismo desarrollador o sus similares al momento de desarrollar hasta sistemas especializados que simulan miles de usurarios simultáneos. Mientras sea posible lo más recomendable es que las pruebas no las realice el desarrollador. La mejor metodología depende del proyecto. Además de las metodologías aplicadas en el desarrollo de software en general en sistemas WEB es posible involucrar directamente a los usuarios en la pruebas al usar el desarrollo basado en prototipos funcionales que ya se mencionó en la sección de prototipos.

 

 

P18 Análisis y Diseño

Ejemplos: Arquitectura y diseño

Descripción: Este documento contiene la descripción textual y grafica de la estructura de los componentes de software.

Utilidad: Describe el sistema, su descomposición en partes y el funcionamiento de las mismas.

Observaciones:

Consta de las siguientes partes:

Estructura de navegación: Contiene la estructura el sistema web en términos de pantallas (información) y ligas. Describe que información contendrá cada pantalla y como se accederá a esta.

Especificaciones y modelos de diseño: Especifica el diseño grafico que será utilizado a lo largo del sistema.

Descripción arquitectónica: Contiene la estructura interna del sistema, es decir la descomposición del sistema en subsistemas. Así como la identificación de los componentes que integran los subsistemas y las relaciones de interacción entre ellos.

Detalle de componentes: Contiene el detalle de los componentes que permita de manera evidente su construcción y prueba en el ambiente de programación.

 

 

P19 Software

Descripción: Sistema de software objetivo del proyecto.

Utilidad: Varia en cada proyecto.

Observaciones:

A pesar de su gran variedad los sistemas WEB suelen usar un grupo pequeño de patrones y por lo tanto el reutilizar diversos componentes es posible si se diseñan pensando en esta posibilidad.



 

P20 Registro de Errores y Cambios

Ejemplos: Ver P17 Plan de Pruebas - Pruebas de integración

Descripción: Repositorio con los reportes de errores y cambios.

Utilidad: Mantiene documentados y organizados los errores reportados y los cambios solicitados

Observaciones:

La forma de comunicar los errores y cambios debe ser establecida en el plan de comunicación. Puede tener componentes orales y registro en medios no específicos para esto como pizarrón de trabajo pero en todo caso debe documentarse de forma ordena y consensada cada error y cambio. Cuando se usa el correo electrónico este puede ser simultáneamente el testimonio y el medio de comunicación. También se pueden usar sistemas especializados en rastreo de errores como bugzilla o reportes detallados que incluyan revisor fecha pruebas ejecutadas etc. Como todos los otros productos el grado de detalle y formalismo así como el medio dependen del proyecto pero todos los casos es indispensable tener una forma homologada para todo el equipo de trabajo de registro de los errores encontrados y cambios requeridos.

 

 

P21 Manual de Mantenimiento

Descripción: Documento que especifica a los clientes como instalar y/o mantener operando el sistema.

Utilidad: Facilitar el mantenimiento del sistema.

Observaciones:

Un sistema WEB no debe tener manual de usuario pues debe ser auto explicativo o los navegantes simplemente cambiaran de sitio. Sin embargo los sistemas WEB deben cambiar y mantenerse continuamente. Por eso es importante entregar la documentación del desarrollo de mismo e incluso un manual con información sobre la instalación y las rutinas de mantenimiento que requiera el sistema.

 

 

P22 Base de Conocimientos

Descripción: Repositorio de los proyectos e información referente a los mismos que ha desarrollado la empresa o equipo.

Utilidad: Sirve para aprovechar el trabajo invertido en otros proyectos. Se pueden reutilizar tanto componentes de los sistemas como la información de la administración y el aprendizaje que se generaron durante los proyectos anteriores.

Observaciones:

Para el nivel de competencia que cubre la guía se pueden utilizar para revisar y reutilizar los componentes, las cotizaciones, el plan de riesgos y en general los todos los otros productos si resultan útiles para un proyecto en particular. En niveles de competencia más avanzados se genera un producto específico que se llama lecciones aprendidas que complementa los productos generados durante el proyecto con notas y observaciones específicas para guardarse en la base de conocimientos y ser utilizadas en futuros proyectos.

 

 

P23 Directorio

Ejemplos: Directorio

Descripción: Directorios adecuados a cada grupo de involucrados con los involucrados su rol y sus datos de contacto.

Utilidad: Facilitar la comunicación entre los involucrados, que deben interactuar entre sí.

Observaciones:

La comunicación es la principal herramienta del administrador del proyecto. El primer paso para que esta sea posible es tener un directorio con todos los involucrados y diversos medios para contactarlos. Es muy importante procurar más de una forma de contacto por cada involucrado pues ninguno es 100% fiable. Ya que no todos los involucrados deben comunicarse entre sí, es importante generar directorios específicos para cada involucrado o grupo de involucrados, que contengan únicamente los datos de los involucrado con quienes debe interactuar.