3.- Características de los sistemas WEB 6
C3 Estética y diseño grafico preponderantes 6
C4 Intuitivos y autoexplicativos 6
C8 Usuarios simultáneos y diversos 7
C9 Múltiples involucrados con múltiples aéreas de especialización 7
4.- Dificultades en los desarrollos de sistemas WEB 8
D2 Requisitos altamente cambiantes 8
D3 Dificultades de comunicación 8
D4 Tecnología diversa y cambiante 8
5.- Involucrados en el desarrollo de un sistema WEB 9
5.1 Roles del equipo de desarrollo: 9
5.2 Roles de clientes y usuarios: 11
6.- Proceso sugerido para el desarrollo de sistemas WEB 12
6.1 Notas sobre los procesos 12
6.2 Actividades del Proceso de Administración de Proyectos Específicos 13
6.3 Actividades del Proceso de Desarrollo y Mantenimiento de software 19
7.- Técnicas útiles en el desarrollo WEB
T1
Análisis de requerimientos enfocado a objetivos
T2
Prototipos Grises
T3
Prototipos operativos
T4
Técnicas para modelación
T5
Uso de patrones
T6
Técnicas para el diseño de arquitecturas
T7
Técnicas de Diseño gráfico
T8
Técnicas para el diseño de navegación
T9
Técnicas para presentar la información
T10
Técnicas para probar las aplicaciones WEB
P1 Descripción del Proyecto 29
P2 Bocetos, Listas de Sitios Similares y Prototipos 30
P5 Descripción del Producto y Entregables 32
P6 Plan de Manejo de Riesgos 33
P9 Repositorio del Proyecto 34
P10 Proceso General de Desarrollo 35
P12 Requerimientos de Adquisiciones y Capacitación 35
P16 Especificación de Requerimientos 37
P20 Registro de Errores y Cambios 39
P21 Manual de Mantenimiento 40
Referencias bibliográficas: 41
Administración de proyectos: 42
Todo profesionista que viva de desarrollar sistemas se enfrenta en algún momento a retos de interacción, organización y trabajo humanos radicalmente diferentes a la vez inevitablemente vinculados a la tarea del desarrollo del software. Los desfases en los calendarios, los continuos cambios, las horas extra y sistemas con fallas o que no ahorran tanto trabajo como deberían, parecen ser constantes en la industria de software y el sector de sistemas WEB no es la excepción. Una de las muchas aportaciones para disminuir estos problemas es MoProSoft, el Modelo de Procesos para la Industria de Software en México. Es resultado de un esfuerzo conjunto de la industria de software y el gobierno Mexicanos para ayudar a las empresas del sector a operar de manera más eficiente y eficaz. Este modelo de procesos resume y adapta a la realidad mexicana las prácticas, normas y modelos más efectivos utilizados por la industria de software a nivel mundial.
Dentro del contexto de la industria de software el desarrollo de sistemas WEB ha cobrado vital importancia por sus efectos sociales, versatilidad y costos. A pesar de esta creciente importancia por la relativa novedad de las tecnologías WEB y su gran dinamismo la cantidad de empresas y equipos de trabajo bien capacitados para desarrollar eficientemente sistemas WEB es muy pequeña. Es en este contexto que se ha desarrollado esta que guía que es para pequeños equipos de desarrollo de aplicaciones WEB que deseen mejorar sus metodologías de trabajo. Se enfoca principalmente en el primer nivel de MoProSoft por lo tanto es ideal para aquellos equipos de desarrollo que estén migrando de procesos totalmente empíricos hacia MoProSoft o equipos que estén iniciando sus actividades. Da las bases y los primeros procesos para mejorar la producción de sistemas WEB y facilita la posterior adopción de MoProSoft en todos los niveles y tareas de la empresa o equipo.
Esta guía está formada de varias secciones que son complementarias. Estas son:
Características de los sistemas WEB
Dificultades más frecuentes en los desarrollos de sistemas WEB
Los involucrados más frecuentes en los desarrollos de sistemas WEB
Proceso sugerido para el desarrollo de sistemas WEB
Técnicas útiles en el desarrollo WEB
Productos del proceso de desarrollo de sistemas WEB
Referencias y enlaces.
Ejemplos.
Se sugiere que se lean todas las secciones al menos una vez pero están diseñadas para permitir su consulta directa en cualquier momento.
Cada sistema es único sin embargo hay un grupo de características que se repiten en casi todos los sistemas WEB. Estas características están directamente relacionadas con la naturaleza de la propia Internet, con las funciones y usos de los sistemas así como con las dificultades en de desarrollo de los sistemas los mismos.
La función intrínseca de todos los componentes de Internet es transmitir y recibir información o en otros términos comunicar. “La comunicación es obviamente el factor subyacente del éxito de la WEB a la vez que la mayor fuente de complejidad y retos para el desarrollo WEB”[2, pag 38]. Los sistemas de software tradicionales almacenan, procesan y organizan la información, pero en comparación con los sistemas WEB sus posibilidades de transmitirla son limitadas. Lo sistemas WEB pueden o no cumplir alguna o todas las funciones “tradicionales” pero inevitablemente deben transmitir información. En este contexto la generación, actualización, confiabilidad y adecuación de la información de un sitio o sistema WEB es un factor de singular importancia.
Un factor adicional que da aun más versatilidad y complejidad a la WEB es la bidireccionalidad del flujo de la información. Los usuarios no solo reciben información, también pueden enviarla. Esto permite que los usuarios puedan asumir una amplia gama de roles al usar un sistema. Pueden ser desde simples lectores, como en el caso de un portal de noticias, hasta los responsables casi absolutos de los contenidos de los sistemas, como ocurre en Wikipedia. La tendencia general es involucrar a los usuarios en algún grado en todos los sistemas. Los sitios de noticias permiten a los lectores hacer cometarios sobre las mismas, los de ventas permiten evaluar los productos, etc.
El esquema Cliente/Servidor implica que el cambio de un sistema a otro es simple e inmediato para los usuarios. Internet da a los sistemas instantáneamente millones de usuarios en potencia, pero a la vez miles de sistemas competidores. La utilidad, la facilidad de uso, el precio, la accesibilidad, la oportunidad y el atractivo visual son los factores más significativos para retener usuarios. Ante la gran oferta, los usuarios hacen juicios velozmente basándose a veces en un solo vistazo. Esto hace que la estética y el diseño gráfico sean más importantes que en los sistemas tradicionales. Pues resultan claves para retener al usuario lo suficiente para que decida evaluar las otras características.
Los mismos factores que causan C3 también fuerzan que los sitios sean fáciles de usar e intuitivos, los usuarios que decidan usar el sitio, lo abandonarán si no logran lo que pretenden fácilmente.
La abundancia de sitios y la facilidad de cambiar de uno a otro no representa únicamente retos, también es una oportunidad. Los sistemas WEB pueden valerse de otros para atraer visitantes y cubrir funciones y contenidos si gastar en implementarlos o mantenerlos.
La tecnología de Internet permite el cambio continuo y además el mercado lo exige. La información es un bien perecedero y la mejora continua una herramienta para atraer a más usuarios. Estos factores refuerzan la necesidad de cambios muy frecuentes a todos los niveles en la mayoría de los sistemas WEB.
La estandarización de los protocolos y la tecnología Cliente/Servidor permite la integración de una red muy heterogenia. El hecho de que la interoperabilidad sea posible fomenta la diversidad de los sistemas. La variedad de sistemas existe tanto en características relacionadas al hardware como al software. En cuanto a hardware existen una gran variedad de tipos de computadoras, tamaños y resoluciones de la pantalla así como diversos dispositivos de entrada como ratones, pantallas táctiles, teclados, lápices apuntadores, etc. En el terreno del software varía el navegador, su versión, y los plugins (complementos) que tenga para interpretar formatos adicionales de archivos.
La diversidad de los usuarios es igual o más compleja que la de la tecnología. Hay que considerar factores variables en cada individuo como el idioma, la familiaridad con la información del sistema, el tiempo disponible, etc. También es necesario evaluar si la información es sensible al acceso simultáneo. En sitios dependientes de operaciones con fechas y horas se debe atender las confusiones y problemas que puede causar el acceso desde lugares con otro uso horario. La meta generalmente es satisfacer lo mejor posible a un amplio número de miembros de un segmento de mercado específico, pues satisfacer plenamente a todos es imposible.
La transferencia de información es crítica en Internet y no es un elemento puramente tecnológico. Intervienen muchos otros factores relativos a la experiencia y cognición humana. Este fenómeno ocasiona la necesidad de roles e involucrados en los sistemas WEB que son inexistentes o muy poco frecuentes en los sistemas tradicionales. Debe haber quienes generen la información, quienes diseñen como organizarla para hacerla accesible, quienes la actualicen, quienes la validen y evidentemente quienes la consulten. Para cumplir estas tareas suelen ser necesarias personas de diversas especialidades.
En términos muy amplios los desarrollos de sistemas WEB no se diferencian del desarrollo de otros sistemas de software, incluso son comparables con el desarrollo de proyectos en general. Todos son en esencia “un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.”[PMBOOK, 5]. Siendo únicos e irrepetibles cada proyecto o sistema presenta circunstancias y retos también únicos. Sin embargo por las características propias de los sistemas WEB la ocurrencia de ciertas problemáticas o peculiaridades es elevada y se les identifica generalizando como propias de los sistemas WEB.
Los criterios para diseñar los sistemas suelen considerar las preferencias, necesidades y capacidades de los usuarios. El uso a distancia, que permite Internet, implica que no sea fácil o viable un contacto personal con ellos. Por esta razón es comun que los usuarios estén ausentes durante el desarrollo de los sistemas WEB. Esta ausencia presencial ocasiona muchas veces que se omitan algunos aspectos importantes. Por la misma razón muchos otros aspectos se diseñen con base en supuestos, interpretaciones y preferencias, de otros involucrados con mayor injerencia directa en el proyecto. Generalmente dichos involucrados reflejan sus gustos personales y no las necesidades de quienes serán los verdaderos usuarios.
Aunado al factor de cambio constante de Internet, los propios requisitos de los sistemas suelen cambiar antes de que estos estén terminados. Los factores exactos que causan esto no son muy estudiados. El iniciar con objetivos muy generales, las nuevas ideas que surgen a partir del aprendizaje que resulta de la interacción de los diversos involucrados y el número mismo de involucrados, son solo algunos ejemplos de posibles causas. En cualquier caso el cambio de requisitos es muy frecuente y esto tiene impactos significativos en el desarrollo de sistemas WEB.
Las comunidades y grupos generan sus propios sub-lenguajes. Dan usos particulares a expresiones generales, tienen expresiones propias y utilizan términos que desconocen otros grupos de personas. En los desarrollos WEB, aun en el caso de sistemas pequeños, intervienen personas de diversas disciplinas, grupos y comunidades. Esto ocasiona dificultades de comunicación que suelen ser muy costosas.
La arquitectura de Internet y el uso de estándares permiten la heterogeneidad pero no eliminan todos los problemas que ésta causa. Estos incluyen desde diferencias en características físicas como el tamaño de la pantalla, hasta pequeñas sutilezas en la forma y detalle con que cada navegador interpreta un estándar. Aun sobre las bases de los estándares más generales como HTML los navegadores tienen algunas diferencias que pueden causar serias dificultades en algunos sistemas. Además hay un gran número de tecnologías complementarias que permiten desarrollar funciones complejas a bajo costo pero que no están ampliamente difundidas en los sistemas clientes. La oferta de dispositivos, protocolos, formatos, navegadores y servidores cambia constantemente. En ocasiones el sistema que estamos desarrollando o manteniendo se puede ver afectado por un cambio en un componente que no tiene efecto en el 99.9% de los sistemas. La dificultad para programar ciertas funciones o acceder a otros sistemas de apoyo como bases de datos, varía entre los diversos lenguajes con que se puede programar el sistema en el servidor. Nuevas tecnologías pueden ser muy sencillas de implementar pero no ser utilizadas por la mayoría de los clientes objetivo. La diversidad de navegadores y servidores puede volver compleja y critica la selección de los lenguajes y tecnologías a utilizar.
Las siguientes tablas muestran los roles más comunes de los involucrados en los desarrollos WEB. Se consideran tanto los miembros del equipo de desarrollo como los clientes y los usuarios.
Rol |
Responsabilidades |
Conocimientos |
Herramientas y apoyos |
Responsable de Administración de Proyectos Específicos |
- Establecer con el cliente encargado los objetivos del sistema. - Coordinar a todos los miembros del equipo. - Comunicación y relación oficial con el cliente - Asegurar que el sistema cumpla sus objetivos - Procurar recursos necesarios |
- Administración de proyectos - Desarrollo WEB básico |
- Agenda - Teléfono - Presentaciones - Diagramas - Pizarrón - Etc. |
AN Analista |
- Establecer los requerimientos en términos entendibles para clientes y desarrolladores - Determinar que requerimientos cambiarán más rápidamente - Identificar perfiles de los usuarios - Determinar las limitantes técnicas - Detallar qué información se usara en el sitio y quién la proveerá |
- Desarrollo WEB básico - Tendrá que aprender sobre temas relativos al sitio y las actividades de los clientes y usuarios |
- Sitios WEB relacionados o similares - Entrevistas con los clientes - Prototipos: grises, dumies, power point, etc. |
DN Diseñador de Navegación |
- Diseñar la navegación (pantallas con sus funciones y ligas) del sistema en función de los objetivos, requerimientos e información |
Deseables: - Conocimientos sobre cómo se percibe de la información |
- Sitios WEB relacionados o similares - Prototipos: grises, dumies, power point, etc. |
DU Diseñador de Interfaz de Usuario |
- Diseñar la interfaz del sistema en función de la navegación, los objetivos, requerimientos e información |
- Diseño grafico - Manejo de herramientas graficas
Deseables: - XHTML - CSS |
- Sitios WEB relacionados o similares - Patrones de interfaz - Templates - Circulo del color - GIMP, PhotoShop, PowerPoint, CorelDraw, etc.
|
DI Diseñador |
- Establecer la arquitectura y módulos del sistema |
- Noción de las habilidades y conocimientos de los programadores - Técnicas de programación - Patrones - Plataformas existentes - Lenguajes - Estándares - Limitaciones técnicas del sistema |
- Sistemas y librerías previos - Sistemas y librerías de código abierto - Catálogos de patrones - Diagramadores UML |
PR Programador |
- Construir el sistema. |
- Técnicas de programación - Patrones - Plataformas existentes - Lenguajes - Estándares - Limitaciones técnicas del sistema |
- Eclipse - Dreamweaver - Visual Studio - NotePad++ - HTMLKit |
RE Revisor |
- Verificar que los componentes separados y el sistema integrado funcionen como se espera |
- Conocimiento de técnicas de revisión y experiencia en el desarrollo y mantenimiento de software. |
- Documentación - Sistema
Deseable: - Herramientas especializadas en pruebas y/o estrés de servidores |
RDM |
- Coordinar la construcción del sistema |
- Conocimiento y experiencia en el desarrollo y mantenimiento de software. |
- IDEs - Subversion, SourceSafe |
RM |
- Elaborar los manuales |
- Conocimiento en las técnicas de redacción y experiencia en el desarrollo y mantenimiento de software. |
|
RPU |
- Coordinar la elaboración de las pruebas |
- Conocimiento y experiencia en la planificación y realización de pruebas de integración y de sistema. |
- Bugzilla |
ET |
|
- Conocimiento y experiencia de acuerdo a su rol. |
|
Rol |
Descripción |
Participación |
Observaciones para miembros del equipo de desarrollo |
CP Cliente Patrocinador |
Es quien paga por el sistema |
- Provee los recursos - Valida el sistema al final |
Si el CP no es el encargado directo del proyecto, se debe documentar a detalle todas las interacciones con el encargado CAE para prever y solucionar malos entendidos. |
CAE Cliente Administrador Encargado |
El responsable del proyecto en la practica |
- Coordina los diferentes recursos que deben proporcionar los clientes a los desarrolladores. - Valida el sistema durante todas sus etapas |
- Cerciorarse de identificarlo formalmente junto con el patrocinador - No saltar su autoridad - Infórmale y acordar con él todos los cambios en los requerimientos, plazos y pagos - Informar de cualquier falla de los CEIs que afecte plazos o costos - No aceptar a priori todas sus observaciones o caprichos; discutirlas y recordarle constantemente los objetivos del sistema y los posibles deseos y criterios de los usuarios y el patrocinador |
CEI Clientes Encargados de Información |
- Tienen la responsabilidad sobre la información que presentará o recibirá el sitio |
- Proveer y mantener o recibir y procesar información del sistema. |
- Identificarlos y aclarar con ellos y el cliente encargado que su participación es necesaria para que el sistema se pueda crear y mantener - Considerarlos especialmente en el diseño - Procurar que se vuelvan usuarios con privilegios y puedan manejar la información que les compete por si mismos - Prever que se tardarán en sus entregas de información - Solicitar su información frecuentemente - Condicionar plazos y costos a su participación y recordar dicho condicionamiento con antelación a los plazos |
US Usuarios |
Son los que utilizarán el sistema |
Uso del sistema |
- Identificarlos a todos; habrá usuarios dentro de los clientes pero además usuarios externos (cibernautas). No olvidarlos aunque sean anónimos. Definirlos por grupos ej: Médicos, profesores, pasantes, hombres con ingresos X de 24 a 30 años, etc. - NO OLVIDARLOS, parece absurdo pero es muy común anteponer los criterios de los clientes a los de usuarios. Que los clientes conozcan o entiendan la aplicación no implica que los usuarios podrán hacerlo. |
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.
Rol |
Descripción |
Observaciones |
A1. Aprobación |
|
|
W1.1 (A1.1) Generar con el Cliente Patrocinador y el Cliente Administrador Encargado la 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 |
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.
* 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 |
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 |
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 |
W1.5 (A1.11) Generar el P6 Plan de Manejo de 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 |
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.
* 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 |
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 |
W1.9 Dar inicio formal al proyecto.
|
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.
|
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 |
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 |
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 |
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. |
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 |
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.
|
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 |
W2.2 (A2.2) Documentar o modificar la P16 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 |
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 |
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 |
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 |
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 |
W3.3 (A3.2) Documentar o modificar 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:
|
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 |
W5.2 (A5.2) Realizar integración y pruebas.
|
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. |
|
Si bien el proceso general permanece prácticamente inalterado en cuanto a sus etapas requerimientos, diseño, construcción y pruebas. En el área de técnicas y/o metodologías específicas para alguna de las etapas encontramos varias propuestas.
El desarrollo WEB involucra información, navegabilidad, estética y personas de diversas disciplinas además de la funcionalidad fundamental en todo sistema de software. En [7] se propone el levantamiento de requerimientos enfocado a objetivos. Consiste en términos generales en listar a los diversos involucrados y sus objetivos. Posteriormente descomponer dichos objetivos en sub-objetivos que si son complementarios se marcan con –y- (AND) y si son alternativos se marcan con – ó - (OR). Después se marcan las relaciones entre los diversos arboles y/o ramas con líneas punteadas. Los objetivos contradictorios se marcan con una línea cruzada con una X. “Las raíces de los árboles son los objetivos mientras que las hojas son los requerimientos” [7, pag:6]. Las hojas o requerimientos se pueden catalogar después como:
Content (labeled with C); -Contenido-
Structure of Content (SC); -Estructura del contenido-
Access Paths to Content (A); -Ruta a contenido-
Navigation (N); -Navegación-
Presentation (P); -Presentación-
User Operation (U); -Operación del usuario-
System Operation (O); -Operación del sistema-
Interaction (I). -Interacción-
El árbol resultante del ejemplo utilizado en [7] se muestra en la figura 2-4.
Los requerimientos resultantes se pueden listar y priorizar para resolver los que sea posible de acuerdo al alcance del proyecto. Los conflictos se resuelven haciendo propuestas y discutiendo con los involucrados.
Este procedimiento es inicialmente poco específico. Esto es una ventaja, en los desarrollos WEB, pues no obliga a hacer decisiones de diseño cuando aun no se tienen todos los elementos necesarios. Por su propia definición y proceso el levantamiento de requerimientos enfocado a objetivos también obliga a considerar a todos los involucrados en el sistema. En sistemas WEB estos suelen ser más que únicamente el cliente y los usuarios. Adicionalmente una vez terminado el análisis de los objetivos proporciona datos tanto de los requerimientos funcionales como de la información e inclusive varios requerimientos no funcionales. Es importante tener en cuenta que esta técnica permite resolver de mejor manera las dificultades que causan usuarios con objetivos difusos o muy generales. Millones de cibernautas acceden a sitios sin más objetivo que ver que encuentran. En los sistemas tradicionales este tipo de usuario es muy improbable pero en los sistemas WEB es más bien la norma.
La comunicación no es solo una de las principales funciones de un sistema WEB, es también uno de los principales problemas durante el su desarrollo. En [6] Eric Holter describe la metodología de trabajo usada en su empresa Newfangled WEB Factory. Bajo la premisa de evitar la ilusión de comunicación se plantea un esquema de trabajo cuyo eje conductor es la elaboración de prototipos denominados grises.
Los prototipos grises son páginas con ligas funcionales y contenidos pero que se enfocan únicamente en la información que cada página o sección debe contener. El calificativo gris, color que la mayoría de las personas no encuentra atractivo, es intencional y se da por la ausencia de todo diseño gráfico. Estos prototipos permiten que clientes y desarrolladores se enfoquen en los contenidos sin distractores. El trabajo y los avances se hacen tangibles y evaluables inmediatamente en los prototipos y evitan ambigüedad y la ilusión de comunicación que pueden dar los términos y descripciones abstractas utilizados cuando no se hacen prototipos. Son también instrumentos fáciles de hacer y que sirven de base para el producto final.
Los e-prototipos o prototipos operativos son un nuevo paradigma que aborda dos de los principales problemas de los desarrollos WEB, el contacto con el cliente y el cambio constante. Son descritos en [5] y básicamente consisten en elaborar prototipos funcionales que se pongan en operación para que los usuarios reales puedan probarlos y dar sus opiniones. En el software tradicional también se llegan a usar algunas versiones beta que son distribuidas a usuarios selectos, con este fin. Pero la naturaleza técnica de estos sistemas hace difícil la implementación de este esquema como principal estrategia de desarrollo. En la WEB por el contrario es fácil y natural; se puede trabajar directamente con los que serán los usuarios reales y los cambios se pueden implementar fácil y constantemente. La bidireccionalidad propia del medio también hace extremadamente sencilla la retroalimentación. Los prototipos generalmente pueden ser reaprovechados parcial o totalmente. Los usuarios no sugieren o expresan necesidades supuestas sino reales, fruto de su propia experiencia con el producto.
El desarrollo por e-prototipos se basa en un paradigma de evolución constante del software en ciclos cortos. Esto se ajusta a las demandas del mercado WEB de cambio constante. Además establece comunicación directa con los usuarios, que generalmente no se pueden consultar en otros modelos de desarrollo WEB. Los prototipos operativos son ya ampliamente utilizados por diversas compañías de gran éxito en Internet. Los que podemos identificar son aquellos sistemas con la leyenda BETA como en su momento fueron por ejemplo G-Mail o Yahoo-Groups. Pero puede haber muchos otros sistemas que omitan este calificativo y sin embargo operen bajo el esquema de recopilación de requerimientos directos de los usuarios finales por medio de correos, foros, etc.
Aun no existe un estándar para modelar los sistemas WEB. Existen muchas propuestas como son OOWS[2], WebML, UWE, entre otros. Estos lenguajes no son idénticos pero en general todos siguen la misma estrategia y paradigmas. Toman como base UML y lo extienden para poder modelar también los contenidos y la navegación. En los ejemplos del apéndice se puede encontrar un sistema modelado con OOWS.
En la sección de arquitecturas de [1] se puede ver que en los sistemas WEB se pueden usar la mayoría de los patrones del diseño de software tradicionales. Sin embargo explorar la propia Internet y los sitios [19] y [20] veremos el uso de patrones no se limita a éstos. Los usuarios de sistemas WEB están poco dispuestos a leer indicaciones y manuales. Por esto los sitios deben ser intuitivos y fáciles de usar para sus usuarios objetivo. Los patrones son una gran herramienta para lograr la simplicidad y familiaridad de los usuarios con el sistema. El uso de elementos comunes en muchos sitios facilita a los usuarios el uso de los mismos. Así podemos encontrar patrones casi universales en los sitios WEB como son la barra de navegación, las tablas o los contenidos indexados. Hay también patrones para sistemas o componentes con funciones específicas, por ejemplo los buscadores básicamente constan de un campo de texto y un botón para iniciar la búsqueda; en el caso de los sistemas que venden productos utilizan alguna variante de los “carritos de compras”. Otro caso son patrones para mostrar cierto tipo de información como las ligas o secciones tituladas “Inicio”, “Acerca de” o “Contacto”. Otros patrones se encargan de la presentación de la información así podemos encontrar contenidos indexados, tablas, pestañas, paginación, mosaicos de imágenes, etc. La taxonomía y clasificación de los diversos patrones WEB aun no está unificada sin embargo esto no impide su uso. La observación de los sitios WEB similares resulta crítica en este sentido. El uso de patrones para el diseño de la interfaz y la estructura de la información es indispensable para generar sistemas sencillos para el usuario.
En la sección de arquitecturas de [3] se describen muchas posibles arquitecturas de los sistemas WEB en su mayoría son tomadas de la arquitectura de los sistemas de software tradicional. Las más comunes son la arquitectura de dos o más capas y la de modelo, vista, controlador. La primera se plantea generalmente con una capa de interfaz con la que interactúa el usuario, una o varias capas de procesamiento de información una última capa persistente donde se almacenan los datos. Los datos y comandos en este modelo son propagados capa por capa y cada capa puede interactuar directamente sólo con las capas superior y/o inferior. La segunda nos presenta un modulo de interfaz, uno de procesamiento de datos o control y uno de almacenamiento persistente. En este caso los tres módulos pueden interactuar indistintamente con los otros dos. Estas arquitecturas se utilizan porque tienden a aislar y facilitar el manejo de la información que como se menciono en las características C1 Comunicación, C2 Interacción es preponderante en los sistemas WEB.
Aun cuando los paradigmas y estructura básica de estas arquitecturas no varían es importante tener en cuenta la influencia de la información en los sistemas WEB y las tendencias y técnicas que se están generando para su manejo. En la actualidad los estándares WEB se enfocan en separar la información de su presentación y de la funcionalidad del sistema. A su vez la propia información se puede distinguir entre los datos y descriptores de los datos. Por ejemplo si guardáramos esta guía como parte de un sistema WEB la información de esta sección tendría la cadena “T6 Técnicas para el diseño de arquitecturas” y está sería clasificada como un título. Así dependiendo del tipo de programación se podrían manejar datos tipo título como objetos, atributos o variables dando el mismo trato y aplicando la misma funcionalidad a todos los títulos cualesquiera que sean. Esta separación esta en sincronía con la programación y también facilita el manejo de la información en las interfaces que puede tener el sistema WEB tanto con usuarios humanos como con otros sistemas. Así en la capa o modulo de interfaz se pueden poner colores y tipos de letra a todos los datos de una cierta categoría o reacomodar en diverso orden y con diversas etiquetas un mismo grupo de datos para que puedan leerlos diversos sistemas clientes.
Como se explica en C3 Estética y diseño grafico preponderantes son muy importantes y tienen un rol fundamental en retener a los navegantes en los primeros instantes en que visitan un sistema WEB sin embargo resultan inservibles si el sistema no resulta útil a usuario. El diseño gráfico debe entonces procurar una presentación clara de la información en forma estética. En [18] se proporciona mucha información sobre los diversos criterios, técnicas, estrategias y errores a evitar en el diseño de interfaces. En sistemas WEB el mejor lenguaje para manejar estos aspectos son las hojas de estilos CSS que, con un poco de práctica, permiten el manejo y manipulación de los siguientes elementos:
Tipografía (tipo, tamaño, color y decorado de las letras): En este caso se recomienda utilizar tipografía más grande y clara, que en medios impresos pues leer en la pantalla es incomodo. El tamaño y la decoración se deben utilizar para destacar la información más importante.
Agrupación: La información y elementos visuales deben agruparse para facilitar su entendimiento al lector. Las categorías pueden ser por función, tipo de dato, formato de presentación, etc. Los diferentes grupos pueden hacerse evidentes por proximidad de sus elementos e incluso el uso de elementos agrupadores como márgenes, líneas, recuadros e imágenes. También se puede usar el color o tipografía.
Orden: El orden de lectura de arriba abajo y de izquierda a derecha o el que venga al caso según la lengua de los usuarios objetivo. Debe considerarse al momento de ubicar los contenidos dentro de la pantalla pues determina en buena medida en que zona de la misma pondrá su atención en primera instancia el lector.
Imagen y color: El uso de colores e imágenes es una de las formas más sencillas de hacer visualmente atractivo un sistema WEB. El poder de estas herramientas es tal que muchas veces se cae en el abuso. El primer punto es evitar que la combinación de colores dificulte la lectura el color de las letras debe tener un alto contraste con el color que se use de fondo. Si se usan imágenes como fondo es muy recomendable utilizarlas como sello de agua con los colores muy atenuados.Las imágenes deben usarse como elementos que sean a la vez informativos y decorativos. Iconos, delimitadores de conjuntos de elementos, botones, títulos o encabezados. Son excelentes opciones para utilizar imágenes que aporten tanto al fácil entendimiento del sistema como a la estética del mismo. La selección cuidadosa del color las combinaciones de colores son un tema delicado no solo pueden hacer fácil o difícil la lectura alteran drásticamente la percepción de los usuarios. Una de las mejores herramientas para hacer dicha selección es el círculo de color. El círculo de color es un acomodo de los colores en una circunferencia que utilizando simples separaciones de diversos grados como 180 o 120 permite encontrar los colores que combinan con aquel que seleccionamos. En la propia Internet se pueden encontrar gran variedad de versiones de esta herramienta y lograr fácilmente buenas combinaciones de colores.
Es importante además tener constancia y congruencia en todo el sistema. Mantener procesos, criterios de clasificación y formas de presentación similares para el mismo tipo funciones, datos y/o elementos a lo largo de todo el sistema evita que los usuarios deban aprender e interpretar en cada pantalla.
Un factor único de los sistemas WEB es la navegación la información y su presentación no pueden ser usados ni apreciados si no se encuentran. El acceso a la información debe también diseñarse. En [2] y [3] se señalan diversas guías para diseñar la navegación de un sistema WEB. Hay muchos factores que varían con cada proyecto. Por ejemplo elegir entre un menú sencillo o una estructura de árbol o si se debe incluir o no un buscador dentro del propio sistema, etc. Sin embargo hay lineamientos generales que es recomendable seguir en la mayoría de los casos.
Siempre informar al usuario donde se encuentra: La versatilidad de ir de una sitio WEB a otro y de una sección a otra con un solo clic. Puede causar rápidamente desorientación en el usuario. Ya sea por ligas poco claras o distracciones ajenas al sistema el usuario puede perder noción de lo que está viendo. Por eso casi 100% de los sitios utiliza un encabezado presente en todas sus pantallas que indica de que sitio se trata. Además es recomendable indicar exactamente en qué pantalla del sistema está el usuario mostrando un titulo en cada una. En sistemas medianos y grandes también se debe poner la ruta o clasificación de la pantalla dentro del sistema.
Tres clics de distancia: Los contenidos deben ser accesibles. La regla de los tres clics sugiere hacer una estructura del sitio muy horizontal en donde no se necesiten más de tres ligas o pasos para llegar a cualquier contenido. Si se deben dar más pasos dificultan que se encuentren los contenidos en primera instancia y que los usuarios logren recordar cómo encontrarlos en visitas posteriores.
Ligas externos: Un sistema no está aislado, se deben generar ligas desde y hacia otros sitios relacionados. Esto facilitara que los usuarios encuentren la información y que se aprovechen desentenderte de tareas e información útil para los objetivos del sistema pero que están más allá de su alcance. Al apoyarse en otros sistemas los contenidos y funciones pueden mantenerse simples y actualizados facilitando entre otras cosas cumplir con la regla de los tres clics.
Como se constata en [21] la información en Internet puede ser video, imagen, audio o texto pero en todos los casos estos elementos deben adaptarse al medio. La C7 Tecnología diversa, los C8 Usuarios simultáneos y diversos y limitaciones como la velocidad de transmisión o el tamaño de las pantallas, influyen sobre la efectividad de estas formas de comunicación. En todos los casos se debe buscar un equilibrio de dos factores contrapuestos presentar información clara y completa pero a la vez breve y concisa.
En el marco del C6 Cambio continuo que impone Internet la información es el aspecto que más cambia de todos. La generación de información clara y completa pero a la vez breve y concisa es muy costosa y tardada por lo tanto es muy importante distribuir esta tarea entre diversos miembros de la organización cliente e involucrar a los propios usuarios de sistema, lo más posible, en las tareas de generación y actualización de la información.
En el caso de los textos deben ser breves, generalmente es recomendable elaborar resúmenes de la información que manejan diariamente los clientes o usuarios en otros medios. En los casos en que los objetivos del sistema incluyan justamente el acceso a grandes volúmenes de información lo más recomendable es presentarla en formatos descargables para su consulta fuera de línea y/o diseñados para ser impresos. Los datos en texto ofrecen una gran variedad de patrones de presentación como son la tabulación, el paginado, el indexado, el listado, etc.
En el caso de las imágenes se deben adaptar la resolución y el formato para que se vean bien en pantalla pero ocupen el menor espacio posible.
El audio y el video deben también codificarse en formatos de alta compresión y a baja resolución para que puedan ser vistos y/o escuchados aun en enlaces que presenten baja velocidad. En el caso de video es recomendable generar video donde el fondo cambie poco y/o cambie lentamente.
En la sección de pruebas en [3] se puede apreciar que las pruebas de las aplicaciones WEB son similares a las de aplicaciones tradicionales pero presentan dos diferencias fundamentales. Primero debido a la C7 Tecnología diversa son necesarias muchas pruebas para probar la misma funcionalidad en diversas plataformas. Segundo, gracias a la facilidad con que se puede actualizar el sistema y a que se cuenta con C8 Usuarios simultáneos y diversos estos se pueden involucrar más fácilmente en las pruebas de la aplicación, como se sugiere en [5]. Dentro del espectro de pruebas que puede desarrollar un equipo pequeño se recomienda lo siguiente:
Probar la combinación de las tecnologías a utilizar en varios navegadores antes de incorporarlas al desarrollo.
Seguir un procedimiento de pruebas tradicional para probar la funcionalidad de la aplicación.
Utilizar la retroalimentación de clientes y usuarios para mejorar la detección de errores y reducir costo y tiempo de las pruebas. Un extremo de este enfoque apoyándose en los propios usuarios es la técnica de T3 Prototipos operativos.
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.
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:
Descripción del Producto, que explica en términos generales cómo será el sistema.
Objetivos, aclara la finalidad del sistema.
Entregables, es el listado de todos los productos y subproductos del proyecto que serán entregados al cliente.
Alcance, específica el nivel de detalle y funcionalidad de cada entregable y del sistema en su conjunto.
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.
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.
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.
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:
Alto poder, alto interés: Esta categoría de personas son las se deben atender con más atención y hacer el mayor esfuerzo por satisfacer. Los comunicados deben ser frecuentes y claros y pueden ser amplios.
Alto poder, poco interés: Es necesario esforzarse para satisfacer a estos involucrados pero es necesario ser breve y claro al comunicarse con ellos pues de lo contrario pueden aburrirse.
Poco poder, alto interés: Es conveniente mantener suficientemente informados a estos involucrados, es muy conveniente hablar personalmente con ellos para recibir puntos de vista diferentes y detectar problemas tempranamente.
Poco poder, poco interés: Se deben monitorear a estos involucrados pero no es necesario poner demasiado esfuerzo o atención en ellos.
Adicionalmente es recomendable utilizar colores para establecer su actitud hacia el proyecto, rojo = negativa, naranja = neutra y verde = positiva.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
[1] Modelo de Procesos para la Industria de Software MoProSoft Por Niveles de Capacidad de Procesos Versión 1.3. Secretaría de economía Agosto 2005.
[2] O. Pastor, D. Schwabe, G. Rossi, et al. Web Engineering: Modelling and Implementing Web Applications Springer London Ltd Octubre 2007.
[3] G. Kappel, B. Pröl, et al. WEB Engineering: The Discipline of Systematic Development of Web Applications, John Wiley & Sons, Ltd Julio 2006.
[4] A Guide to the Project Management Body of Knowledge third edition. Project Management Institute 2004.
[5] Wolf-Gideon Bleek, Martti Jeenicke, Ralf Klischewski Developing Web-based Applications through e-Prototyping Proceedings of the 26 th Annual International Computer Software and Applications Conference IEEE 2002.
[6] Eric Holter Client vs. Developer Wars Newfangled Web Factory 2006.
[7] Davide Bolchini , John Mylopoulos From Task-Oriented to Goal-Oriented Web Requirements Analysis Proceedings of the Fourth International Conference on Web Information Systems Engineering IEEE 2003.
[8] Victoria Torres, Javier Muñoz, Vicente Pelechano A Model Driven Method for the Integration of Web Applications Proceedings of the Third Latin American Web Congress IEEE 2005.
[9] Rashid Ahmad2, Zhang Li, Farooque Azam Web Engineering: A New Emerging Discipline International Conference on Emerging Technologies IEEE 2005.
[10] Lasse Vogelsang, Peter Carstensen New Challenges for the Collaboration in Web-based Information Systems Development IEEE 2001
[11] http://www.software.net.mx/desarrolladores/prosoft/
[12] http://www.iso.org/
[13] http://alarcos.inf-cr.uclm.es/Competisoft/
[14] http://www.w3.org/
[15] http://www.sei.cmu.edu/cmmi/
[16] SWEBOK, Trial Version. Software engineering Coordinating Committee, Computer Society, Software Engineering Institute. 2001.
[17] Stakeholder Analysis. http://www.mindtools.com/pages/article/newPPM_07.htm
[18] Kevin Mullet, Darrell Sano Designing Visual Interfaces, communication oriented techniques Sun Press, 1995
[19] http://webpatterns.org/
[20] http://www.ui-designpatterns.org/
[21] http://www.w3schools.com/media/media_intro.asp
Server2go http://www.server2go-web.de/
XAMPP http://www.apachefriends.org/en/xampp.html
Tomcat http://sourceforge.net/projects/easytomcat
MS-Project http://office.microsoft.com/en-us/project/default.aspx
Open WorkBench http://www.openworkbench.org/
DreamWeaver http://www.adobe.com/products/dreamweaver/
HTMLKit http://www.chami.com/html-kit/
Eclipse for LAMP http://www.easyeclipse.org/site/distributions/lamp.html
PhotoShop http://www.adobe.com/products/photoshop/index.html
Gimp http://www.gimp.org/
Corel Draw http://www.corel.com/
Ink Space http://www.inkscape.org/
Subversion http://subversion.tigris.org/
Source Safe http://msdn.microsoft.com/en-us/vstudio/aa700907.aspx
Bugzilla http://www.bugzilla.org/
Comunidad Moprosoft http://www.comunidadmoprosoft.org.mx/
Project Management Institute http://www.pmi.org/
Software Engineering Institute http://www.sei.cmu.edu/
Web Patterns Project http://www.ui-designpatterns.org/index.html
WebPatterns http://webpatterns.org/
W3Schools http://www.w3schools.com/
JavaScript Reference http://www.javascriptkit.com/jsref/