| |
|
|
|
|
|
| |
METODOLOGIA
Dentro del contexto mundial, el desarrollo
de software se convierte en un proceso cada
vez mas difícil de dimensionar y controlar,
AVATAR considera que la metodología
de desarrollo es la base del éxito
de todos los proyectos que emprende y la calidad
de los productos que entrega, sin ella no
se podría medir el impacto real de
su ejecución y la afectación
tanto en nuestros clientes como en nuestra
propia empresa. También considera que
cada proyecto de desarrollo posee características
propias que los hacen convertirse en únicos
tanto por el reto tecnológico que presupone
como por el entorno organizacional de las
empresas a las que servimos. |
| |
|
| |
CICLO
DE VIDA |
| |
|
| |
Modelo
El
ciclo de vida de los proyectos de desarrollo
de software en Avatar se basa en el modelo
del Proceso Unificado de Rational (RUP por
sus siglas en inglés). Por esta razón el ciclo
de vida se descompone en el tiempo en cuatro
fases secuenciales, cada una de las cuales
concluye con un hito principal. Al final de
cada fase se realiza una evaluación para determinar
si se alcanzaron los objetivos de la misma.
Si la evaluación es satisfactoria entonces
el proyecto podrá continuar con la siguiente
fase. (Referencia RUP: RUP LIFECYCLE)
Alcance
Los proyectos de desarrollo
de software para los cuales aplica el presente
modelo de ciclo de vida tienen como objetivo
desarrollar un producto nuevo en ambiente
web o cliente/servidor. De acuerdo a la experiencia
de Avatar, a la fecha este modelo ha sido
probado con equipos de trabajo conjuntos de
5 a 20 personas, y una duración de 3 a 9 meses. |
| |
|
| |
Fases
Las
cuatro fases del ciclo de vida son:
|
| |
| ü |
Concepción |
| ü |
Elaboración |
| ü |
Construcción |
| ü |
Transición |
|
| |
|
| |
ü
Concepción |
| |
La
fase de Concepción por definición tiene como
finalidad principal confirmar que existe consenso
entre todos los interesados al interior del
cliente acerca de los objetivos a alcanzar
y la rentabilidad del proyecto, de modo que
se tome la decisión si el proyecto continúa
o no. (Referencia RUP: Phase: Inception).
La realidad sin embargo es que los clientes
envían sus proyectos a las posibles empresas
ejecutoras (entre ellas Avatar) con esta decisión
ya tomada y con la convicción que una de ellas
se ajustará a sus estimados de tiempo y costo
de manera razonable y beneficiosa para ambas
partes. Por esta razón la fase de Concepción
en la metodología de Avatar tiene como razón
de ser encausar el proyecto dentro del modelo
RUP. |
| |
|
| |
Objetivos
ü Encontrar
todos los actores y los casos de uso del software,
y agruparlos por módulos.
ü Delinear
la arquitectura, e identificar las partes
de la misma que requerirán ser atendidos durante
la elaboración.
ü Confirmar
el alcance funcional, técnico y de gestión
bajo los cuales se planificó el proyecto e
identificar los controles de cambio que sean
necesarios.
Entregables
De acuerdo al alcance del presente modelo
de ciclo de vida de proyectos, los entregables
de la fase de concepción son los siguientes
(en orden de importancia): |
| |
|
| |
|
Entregables esenciales |
Descripción |
|
Visión |
ü
Donde
se documenta la descripción de los
módulos, la relación de casos de uso,
los actores y la arquitectura del
sistema.
ü
Incluye los siguientes modelos:
- El
modelo de casos de uso
- El
modelo de despliegue
- El
modelo de clases de análisis
- Prototipos
de la interfaz con el usuario
-
Prototipos de la arquitectura
|
|
Plan de Desarrollo de Software |
ü
Donde se documenta la descripción
de las actividades que se desarrollarán
durante cada fase, la necesidad de
recursos (personal, infraestructura,
etc.), los criterios de aceptación
y la programación de fechas.
ü
En caso sea necesario, debe incluir
también:
- El
plan de migración
- El
plan de pruebas
-
El plan de capacitación
|
|
Lista de Riegos |
ü
Donde se enumera la lista de riesgos
identificados durante esta fase del
proyecto, con su correspondiente evaluación
cuantitativa y cualitativa, y sus
respectivos planes de mitigación y/o
contingencia.
|
|
| |
|
| |
Supuestos
Los supuestos que a continuación se describen
deben ser fehacientemente comprobados por
los responsables de dirigir el proyecto, tanto
por parte del cliente como de Avatar. |
| |
|
| |
|
Supuesto |
Fuente |
|
El alcance, los supuestos, las dependencias,
y los criterios de aceptación del
proyecto están claramente establecidos
|
ü
Oferta Técnica, elaborada por el Jefe
de Proyecto de Avatar y aprobada por
la Gerencia de Sistemas del Cliente
|
|
El
personal asignado al proyecto ha pasado
por el proceso de inducción con por
lo menos una semana de anticipación.
|
ü
Tablero de Control Interno, elaborado
por el Jefe de Proyecto y revisada
por el Gerente de Operaciones
|
|
El
plan de trabajo ha sido revisado y
aprobado por ambas partes
|
ü
Plan de Desarrollo de Software, elaborado
por los Jefes de Proyecto de Avatar
y del Cliente, y aprobado por las
Gerencias de Operaciones de Avatar
y de Sistemas del Cliente.
|
|
El
mbiente de trabajo está listo para
ser utilizado por personal de Avatar
|
ü
Acta de Iniciación (Kick-off) del
Proyecto, elaborado por los Jefes
de Proyecto de Avatar y del Cliente,
y aprobado por las Gerencias de Operaciones
de Avatar y de Sistemas del Cliente.
|
|
| |
|
| |
ü
Elaboración |
| |
|
| |
La
fase de Elaboración por definición tiene como
finalidad establecer una base sólida de la
arquitectura del software (Referencia RUP:
Concepts: Software Architecture). La arquitectura
se desarrolla a partir del análisis y diseño
de los requerimientos funcionales y técnicos
más significativos, y se _evalúa por medio
de uno o más prototipos. (Referencia RUP:
Phase: Elaboration). Esto demanda una fuerte
participación de los Líderes Funcionales y
Técnicos del cliente. Siendo la realidad que
los clientes mantienen a sus Líderes Funcionales
y Técnicos en diferentes proyectos y/o tareas
propias de la operatividad del día a día y
que por lo tanto su disponibilidad en el proyecto
es siempre mucho mayor al inicio y mucho menor
después, la fase de Elaboración en la metodología
de Avatar tiene como razón de ser el análisis
y diseño de todos los requerimientos funcionales
y técnicos del software, empezando por aquellos
que son críticos para establecer su arquitectura.
Objetivos
Confirmar que los requerimientos, la arquitectura
y los planes son suficientemente estables,
y que los riesgos están suficientemente mitigados,
de modo que los esfuerzos del Cliente y de
Avatar estén adecuadamente estimados para
completar el proyecto en los plazos previstos.
Entregables
De acuerdo al alcance del presente modelo
de ciclo de vida de proyectos, los entregables
de la fase de elaboración son los siguientes
(en orden de importancia): |
| |
|
| |
|
Entregables esenciables |
Descripción |
|
Documento de Especificaciones Funcionales
y Técnicos |
ü
Resultado
de la labor de análisis y diseño,
complementa el documento de la Visión
porque describe la arquitectura del
software en todos sus aspectos relevantes,
y cómo se implementarán sus casos
de uso.
ü
Incluye los siguientes modelos:
- El modelo de casos de uso
-
El modelo de despliegue
-
El modelo de clases de análisis
-
El modelo de datos
-
El modelo lógico, a nivel de paquetes,
módulos, subsistemas, clases de diseño,
atributos y métodos
-
El modelo de componentes
-
Prototipos de la interfaz con el usuario
-
Prototipos de la arquitectura
-
La definición de la línea gráfica
|
|
Plan de Desarrollo de
Software |
ü
Revisado y aprobado a la fecha. Su
contenido puede ser mejorado y/o complementado
siempre a través de un control de
cambio.
|
|
Lista de Riesgos |
ü
Revisado y aprobado a la fecha. Su contenido
puede ser mejorado y/o complementado
siempre a través de un control de cambio. |
|
Casos de Prueba |
ü
Relación de casos de prueba de los módulos
que se implementaran en la siguiente
iteración. |
|
Adendas a la Visión |
ü
Resultado de los controles de cambio
que hayan sido solicitados |
|
| |
|
| |
Supuestos
Los supuestos que a continuación se describen
deben ser fehacientemente comprobados por
los responsables de dirigir el proyecto, tanto
por parte del cliente como de Avatar. |
| |
|
| |
|
Supuesto |
Fuente |
|
El plan de trabajo ha sido revisado
y aprobado por ambas partes
|
ü
Plan de Desarrollo de Software actualizado
a la fecha, elaborado por los Jefes
de Proyecto de Avatar y del Cliente,
y aprobado por las Gerencias de Operaciones
de Avatar y de Sistemas del Cliente.
|
|
El ambiente de trabajo está listo
para ser utilizado por personal de
Avatar, específicamente el ambiente
de desarrollo
|
ü
E-Mail
de Confirmación por del Jefe de Proyecto
del Cliente.
|
|
| |
ü
Construcción |
| |
|
| |
La
fase de Construcción por definición tiene
como finalidad culminar el análisis y diseño
de los requerimientos que hayan quedado pendientes
de la fase de elaboración y completar el desarrollo
del sistema siguiendo la arquitectura del
software ya definida (Referencia RUP: Phase:
Construction). Los requerimientos que puedan
quedar pendientes de analizar y diseñar deben
ser excepcionales, deben haber surgido como
adicionales al alcance original, y no deben
tener impacto alguno en la arquitectura. Siendo
así, la fase de Construcción en la metodología
de Avatar tiene como razón de ser culminar
la implementación iterativa e incremental
de todos los requerimientos funcionales y
técnicos del software.
Objetivos
ü
Implementar las versiones del sistema con
un equilibrio entre calidad y rapidez
ü
Minimizar los costos de desarrollo optimizando
el uso de recursos y previniendo retrasos,
re-trabajo, desperdicio.
Entregables
De acuerdo al alcance del presente modelo
de ciclo de vida de proyectos, los entregables
de la fase de elaboración son los siguientes
(en orden de importancia):
|
| |
|
| |
|
Entregables
esenciables |
Descripción |
|
El Sistema
|
ü El
sistema ejecutable en sí, listo para
pruebas de certificación por parte
del Cliente
|
|
Informe de Pruebas
|
ü Un
reporte con los casos de prueba que
se han podido ejecutar, la estadística
de cuántos han sido satisfactorios
y qué observaciones están quedando
pendientes
|
|
Manual de Usuario
|
ü La
documentación de ayuda para el usuario
final respecto al uso del sistema
|
|
Manual de Sistema
|
ü La
documentación de ayuda para los operadores
de sistemas respecto a como instalar,
configurar, operar y dar soporte al
sistema
|
|
Plan de Desarrollo de Software
|
ü Revisado
y aprobado a la fecha. Su contenido
puede ser mejorado y/o complementado
siempre a través de un control de
cambio.
|
|
Lista de Riesgos
|
ü Revisado
y aprobado a la fecha. Su contenido
puede ser mejorado y/o complementado
siempre a través de un control de
cambio.
|
|
Casos de Prueba
|
ü Relación
de casos de prueba de los módulos
que se implementaran en la siguiente
iteración.
|
|
Adendas a la Visión
|
ü Resultado
de los controles de cambio que hayan
sido solicitados
|
|
Adendas al Documento de Especificaciones
Funcionales y Técnicos
|
ü Resultado
de los controles de cambio que hayan
sido solicitados
|
|
| |
|
| |
Supuestos
Los supuestos que a continuación se describen
deben ser fehacientemente comprobados por
los responsables de dirigir el proyecto, tanto
por parte del cliente como de Avatar. |
| |
|
| |
|
Supuesto |
Fuente |
|
El plan de trabajo ha sido revisado
y aprobado por ambas partes
|
ü Plan
de Desarrollo de Software actualizado
a la fecha, elaborado por los Jefes
de Proyecto de Avatar y del Cliente,
y aprobado por las Gerencias de Operaciones
de Avatar y de Sistemas del Cliente.
|
|
El ambiente de trabajo está listo
para ser utilizado por personal de
Avatar, específicamente el ambiente
de desarrollo del cliente
|
ü E-Mail
de Confirmación por del Jefe de Proyecto
del Cliente.
|
|
| |
|
| |
ü
Transición |
| |
|
| |
La
fase de Transición por definición tiene como
finalidad asegurar que el software esté disponible
para sus usuarios finales. (Referencia RUP:
Phase: Transition). Esto implica que se lleven
a cabo las pruebas de certificación del software
en el ambiente de control de calidad, y se
genere la documentación final necesaria para
utilizarlo en producción. De esta manera el
cliente comprobará tiene todo lo necesario
para efectuar el pase a producción. Esto se
debe a que los clientes muchas veces deciden
no pasar a producción inmediatamente porque
está a la espera de que culminen otros proyectos
satélites, ó simplemente no dispone el acceso
a todos los usuarios finales hasta que se
termine un periodo de marcha blanca en producción
atendiendo a un conjunto limitado de usuarios.
En cualquier de estos casos, las observaciones
que puedan surgir son atendidas por Avatar
como parte de la garantía sobre el software.
Siendo así, la fase de Transición en la metodología
de Avatar tiene como razón de ser culminar
la entrega del software certificado por los
responsables de control de calidad del cliente,
esto incluye toda la documentación y entrenamiento
necesario para que el cliente efectúe el pase
a producción y utilice el software en el momento
que lo crea conveniente.
Objetivos
ü
Probar que el sistema cumple las especificaciones
funcionales y técnicas requeridas
ü
Cumplir con la lista de verificación que da
por culminado el proyecto
Entregables
De acuerdo al alcance del presente modelo
de ciclo de vida de proyectos, los entregables
de la fase de elaboración son los siguientes
(en orden de importancia):
|
| |
|
| |
|
Entregables
esenciables |
Descripción |
|
El Sistema
|
ü El
sistema ejecutable en sí, incluido
sus fuentes, listo para ser instalado,
configurado y utilizado en producción
por parte del Cliente
|
|
Manual de Usuario
|
ü La
documentación de ayuda para el usuario
final respecto al uso del sistema,
aprobada por el Cliente
|
|
Manual de Sistema
|
ü La
documentación de ayuda para los operadores
de sistemas respecto a como instalar,
configurar, operar y dar soporte al
sistema, aprobada por el Cliente
|
|
Adendas a la Visión
|
ü Resultado
de los controles de cambio que hayan
sido solicitados
|
|
Adendas al Documento de Especificaciones
Funcionales y Técnicos
|
ü Resultado
de los controles de cambio que hayan
sido solicitados
|
|
| |
|
| |
Supuestos
Los supuestos que a continuación se describen
deben ser fehacientemente comprobados por
los responsables de dirigir el proyecto, tanto
por parte del cliente como de Avatar. |
| |
|
| |
|
Supuesto |
Fuente |
|
El plan de trabajo ha sido revisado
y aprobado por ambas partes
|
ü Plan
de Desarrollo de Software actualizado
a la fecha, elaborado por los Jefes
de Proyecto de Avatar y del Cliente,
y aprobado por las Gerencias de Operaciones
de Avatar y de Sistemas del Cliente.
|
|
El ambiente de trabajo está listo
para ser utilizado por personal de
Avatar, específicamente el ambiente
de certificación y de producción del
cliente
|
ü E-Mail
de Confirmación por del Jefe de Proyecto
del Cliente.
|
|
| |
|
| |
CONSIDERACIONES
ADICIONALES
De
acuerdo a la experiencia de AVATAR, en la
industria nacional se carece mucho de los
siguientes dos factores críticos de éxito
en el proceso de desarrollo de software
(independientemente de la tecnología que
se utilice): La Gestión de la Calidad y
la Disciplina de Pruebas de Software.
Gestión de la Calidad
La gestión de la calidad es responsabilidad
de todos los miembros del proyecto y de
la empresa, y se lleva a cabo en cada una
de las actividades que se emprenden. La
gestión de la calidad se enfoca principalmente
en el proceso de desarrollo de software,
como garantía de un adecuado producto. Adicionalmente
a las tareas internas de control, resaltamos
a continuación aquellas tareas que se llevan
a cabo con la participación de un Analista
del área de Calidad de Avatar
Tareas de Prevención
ü Prevención
contra Entregables no adecuados para el
Proyecto.- El Analista de Calidad revisa
la estructura y el tipo de contenido de
cada entregable con los miembros del proyecto
involucrados en su elaboración. Resultado
de esta tarea se revisa y complementa la
Lista de Verificación (checklist).
ü Prevención
contra Entregables poco claros para el Cliente.-
El Jefe de Proyecto envía una copia de ejemplo
de cada entregable con la intención de mostrarle
un mayor detalle a lo descrito en la propuesta,
y confirmar su aprobación respecto a la
estructura y el tipo de contenido. Resultado
de esta tarea se oficializa la Lista de
Verificación (checklist).
Tareas de Control
ü Control
de un adecuado seguimiento del avance del
proyecto.- El Analista de Calidad revisa
la documentación de seguimiento del avance
del proyecto (carta gantt, reporte de estado,
reporte de pendientes, actas de reunión),
visita el ambiente de trabajo periódicamente
y conversa con los miembros del proyecto,
con la finalidad de:
- Verificar que la documentación de seguimiento
señale, de manera explícita, entregables,
plazos y responsables.
- Verificar que se estén cumpliendo los
plazos del proyecto y el alcance establecido
por cada entregable.
- Verificar que el proceso de desarrollo
de software sea fluido y no se generen desperdicios
o retrabados.
ü Control
de la Lista de Verificación por Entregable.-
El Analista de Calidad acompaña al Jefe
de Proyecto en la tarea de revisar la Lista
de Verificación contra un Entregable, desde
el inicio de su elaboración hasta antes
de la entrega al cliente.
Disciplina de Pruebas de Software
Esta disciplina complementa a la gestión
de la calidad, toda vez que tiene como propósito
principal el aseguramiento y el control
de la calidad del producto final, el software.
Las actividades de esta disciplina se llevan
a cabo a lo largo de las cuatro fases, sin
embargo consideramos crítico establecer
con el Cliente el alcance de las pruebas
necesarias para cada proyecto, por lo que
a continuación exponemos brevemente las
principales formas como se puede probar
un sistema, cada una de las cuales tiene
un objetivo específico y una técnica que
lo soporta.
ü Prueba
de Estructura Web.- Es el tipo de prueba
que se enfoca en certificar que todos los
enlaces del sitio web estén conectados a
la página web que le corresponde, y que
no hay contenido que no pueda ser consultado
de ninguna manera (contenido huérfano).
ü Prueba
de Funcionalidad.- Es el tipo de prueba
que se enfoca en certificar que el funcionamiento
del sistema esté acorde a lo descrito en
el documento de especificaciones funcionales,
esto es que provea los casos de uso que
ahí se indican, y de la manera como ahí
se especifica.
ü Prueba
de Seguridad Funcional.- Es el tipo
de prueba que se enfoca en certificar que
los datos y las funciones del sistema solo
son accesibles por los actores debidamente
autorizados, acorde a lo descrito en el
documento de especificaciones funcionales.
ü Prueba
de Volumen Funcional.- Es el tipo de
prueba que se enfoca en certificar la capacidad
del sistema de manejar volúmenes de datos
extremos, acorde a lo descrito en el documento
de especificaciones funcionales.
ü Prueba
de Robustez.- Es el tipo de prueba que
se enfoca en certificar la capacidad de
resistencia a fallar que tiene el sistema,
acorde a lo descrito en el documento de
especificaciones técnicas.
ü Prueba
de Estructura de Programas.- Es el tipo
de prueba que se enfoca en comprobar que
los programas han sido codificados de acuerdo
a los estándares de programación establecidos.
ü Prueba
de Resistencia (Stress).- Es el tipo
de prueba que se enfoca en comprobar cuál
es el comportamiento del sistema bajo condiciones
anormales, por ejemplo carencia de recursos
de memoria, procesador, sistemas externos
con los que interactúa y carga excesiva
de trabajo. El objetivo de estas pruebas
es identificar las partes débiles del sistema,
de modo qu | | | | | |
