De nición y Adaptación de un Proceso de Desarrollo de ...
162
Transcript of De nición y Adaptación de un Proceso de Desarrollo de ...
De�nición y Adaptación de un Proceso de
Desarrollo de Software Efectivo en el Área de
Informática Educativa. Caso de Estudio: Grupo de
Desarrollo de LIDIE - Proyecto AVA
Trabajo de Tesispresentado al
Departamento de Ingeniería de Sistemas y Computación
por
Erick Escorcia
Asesores: Nicolás López, Rubby Casallas
Para optar al título deIngeniero de Sistemas
Ingeniería de Sistemas y ComputaciónUniversidad de Los Andes
Enero 2006
A mi mamá
y a mis amigos,
que siempre han estado a mi lado en todo momento,
y a mi abuelita, que en estos momentos me cuida desde el cielo.
ii
Prefacio
La motivación para este proyecto se debe a tres razones principales. La primera
razón fue poder aportar todo el conocimiento que adquirí mediante mis estudios
a una situación real, y que este aporte permitiera mejorar dicha situación. La se-
gunda razón fue diseñar la propuesta para este proyecto como una idea propia que
se generó por la constante observación del comportamiento de LIDIE, durante los
diferentes periodos de tiempo en los que trabajaba con ellos. Finalmente, la tercera
y última razón, y no menos importante, fue encontrar el apoyo necesario para que
está propuesta viera la luz, gracias al apoyo de LIDIE y QualDev.
iii
Reconocimientos
Quiero agradecer a Luz Adriana Osorio por sus críticas objetivas, su disponibi-
lidad en todo momento y sus enseñanzas en el área de Pedagogía y Educación, a
Carlos Noguera por ser un guía en la construcción de esta propuesta, a Katalina
Marcos por su corto pero importante apoyo, a Rubby Casallas por apoyar la conti-
nuación de este trabajo y proveer los recursos necesarios para la �nalización de este
proyecto, a Sergio Rodriguez por su disponibilidad para resolver mis constantes pre-
guntas y ser un gran apoyo en la realización de este trabajo, a Guillermo Aristizábal
por su disponibilidad e interés en la ejecución de esta propuesta, a Andrés Rubio
por ayudarme a aliviar la carga de trabajo en momentos donde el tiempo no era
su�ciente, a Nicolás López por sus sugerencias, a Juan Pablo Quiroga por ser una
gran fuente de información y conocimiento y a Rafael García por el apoyo brindado
a mis amigos en momentos críticos.
También quiero agradecer a mi mamá, mi única familia, que creyó en mi como
profesional. Le agradezco mis amigos por esos momentos agradables y desagradables,
en especial a Patricia y a Sonia por ser ejemplos de compromiso y fortaleza en lo
que se involucran, a Frank por seguir sus convicciones, a Ricardo por ser un buen
compañero de trabajo y ser ejemplo de liderazgo y determinación, a Sebastian por
no abrumarse ante la adversidad y verle lo bueno a todo, a Saulo y Camilo por ser
ejemplos de profesionalismo y compromiso en los proyectos en los que se envuelven
y por último y no menos importante, a Jose por ser ejemplo de superación y de
compromiso con sus amigos y con su carrera.
Finalmente, agradezco a Dios por proveerme de su inmensa sabiduría en los
momentos más difíciles.
iv
Tabla de Contenido
Dedicatoria ii
Prefacio iii
Reconocimientos iv
Lista de Figuras viii
Resumen ix
Objetivos 1
I. Introducción 2
II. Arquitectura de TI 4
III. Modelos de Ciclo de Vida de Software 6
3.1. De�nición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Tipos de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Modelos Centrados en la Actividad . . . . . . . . . . . . . . 11
3.3.2. Modelos Centrados en la Entidad . . . . . . . . . . . . . . . 20
3.4. Marco de Comparación de los Modelos de Ciclo de Vida . . . . . . . 22
IV. Diseño de Procesos 25
V. Caso de Estudio: LIDIE 28
5.1. De�nición de LIDIE . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.1. Grupos Interdisciplinarios . . . . . . . . . . . . . . . . . . . . 29
5.1.2. El Proyecto AVA . . . . . . . . . . . . . . . . . . . . . . . . . 30
v
5.2. Estado Actual de LIDIE . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.1. Arquitectura de TI . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.2. Características del MCVS del Proceso Actual . . . . . . . . . 40
5.2.3. Evaluación del Proceso de Desarrollo de Software . . . . . . . 41
VI. Construcción del Proceso 48
6.1. Marco para Caracterizar a LIDIE . . . . . . . . . . . . . . . . . . . 48
6.1.1. Identi�cación de las Características del Proceso Deseado . . . 48
6.1.2. Selección del Proceso . . . . . . . . . . . . . . . . . . . . . . 49
6.2. QualDev Community y la Adaptación del Proceso . . . . . . . . . . 49
6.2.1. QualDev Community . . . . . . . . . . . . . . . . . . . . . . 50
6.2.2. El Modelo IDEAL . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.3. Ejecución de la Adaptación del Proceso . . . . . . . . . . . . 51
VII.PAL: Proceso de Construcción de Software de LIDIE 60
7.1. De�nición del Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2. Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2.1. LANZAMIENTO . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2.2. ESTRATEGIA . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2.3. PLANEACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2.4. ANÁLISIS DE REQUERIMIENTOS . . . . . . . . . . . . . 86
7.2.5. DISEÑO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.2.6. IMPLEMENTACIÓN . . . . . . . . . . . . . . . . . . . . . . 106
7.2.7. PRUEBAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.2.8. POSTMORTEM . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.3. Manual de Uso del Proceso . . . . . . . . . . . . . . . . . . . . . . . 129
7.3.1. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . 129
7.3.2. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
vi
7.4. Uso del Proceso en el Proyecto AVA . . . . . . . . . . . . . . . . . . 131
VIII.Evaluación de Herramientas 134
8.1. Herramientas Actuales . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.1.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.1.2. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . 135
8.2. Herramientas Sugeridas . . . . . . . . . . . . . . . . . . . . . . . . . 137
IX. Resultados 138
X. Conclusiones 141
XI. Trabajo a Futuro 143
Referencias 145
Anexos 148
vii
Lista de Figuras
1. Tabla Comparativa de Actividades de MCVSs I . . . . . . . . . . . . 22
2. Tabla Comparativa de Actividades de MCVSs II . . . . . . . . . . . . 22
3. Tareas vs. Roles I: Tareas Generales Transversales . . . . . . . . . . . 33
4. Tareas vs. Roles II: Tareas de Análisis Educativo . . . . . . . . . . . 33
5. Tareas vs. Roles III: Tareas de Diseño . . . . . . . . . . . . . . . . . . 34
6. Tareas vs. Roles IV: Tareas de Diseño, Tareas de Desarrollo y Montaje 35
7. Tareas vs. Roles V: Tareas de Entrega y Postmortem . . . . . . . . . 35
8. Diagrama de Gant del Proceso de Desarrollo de Software en Lidie porEntregables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Proceso PAL utilizado por el grupo de Desarrollo dentro del Procesode Construcción de un AVA. También se puede observar como seríael proceso utilizado por el grupo de Diseño Instruccional si tambiénutilizará el proceso PAL . . . . . . . . . . . . . . . . . . . . . . . . . 133
10. Problemas del Grupo de Desarrollo de LIDIE, pertenecientes a losprocesos de Administración. . . . . . . . . . . . . . . . . . . . . . . . 140
11. Problemas del Grupo de Desarrollo de LIDIE, pertenecientes a losprocesos de Desarrollo y a los procesos Transversales. . . . . . . . . . 140
viii
Resumen
Este trabajo se basa en el análisis de los diferentes modelos de ciclo de
vida de software, con el �n de desarrollar un proceso de construcción de software
tomando como base un caso de estudio especí�co: el grupo de Desarrollo de LIDIE
y su proyecto AVA, para que el proceso resultante sea la base de su mejoramiento
continuo.
ix
Objetivos
De�nir un proceso de construcción de Software para el grupo de Desarrollo de
LIDIE.
Adaptar una herramienta que soporte el proceso diseñado para el grupo de
Desarrollo de LIDIE.
Adaptar y ajustar el proceso diseñado a las necesidades identi�cadas de LIDIE
y de su grupo de Desarrollo.
1
Capítulo I
Introducción
Esta propuesta surgió de la observación durante periodos de dos meses más o
menos de una empresa, LIDIE. Una vez presentada la propuesta de mejorar su
proceso de desarrollo de software, fue necesario establecer un marco teórico fuerte y
un buen análisis del estado actual del grupo de Desarrollo para que la propuesta fuera
aprobada, una vez entregadas estas investigaciones, era necesario tener experiencia
en la adaptación de procesos para poder comenzar el mejoramiento del proceso de
desarrollo, por lo cual se solicitó el apoyo de QualDev. Gracias a la experiencia de
QualDev, se construyo el proceso a medida que se iba adaptando a las necesidades
de LIDIE.
Durante los capítulos siguientes se explica el proceso descrito anteriormente en
detalle, los primeros capítulos comprenden el marco teórico y el análisis de LIDIE los
cuales justi�can esta propuesta. En el Capítulo 2 - Arquitectura de TI, se justi�ca la
construcción del proceso para la etapa en la que se encuentra LIDIE como empresa,
luego en el Capítulo 3 - Modelos de Ciclo de Vida de Software se explica y se
establecen de�niciones que se van a utilizar a través de todo este documento sobre
los procesos y tipos de procesos de construcción de software para �nalmente hacer
una comparación de los modelos más conocidos, en el Capítulo 4 - Diseño de Procesos
se identi�can una serie de aspectos a tener en cuenta cuando se diseñan procesos, y
en el Capítulo 5 - Caso de Estudio: LIDIE se hace un análisis del funcionamiento de
LIDIE, como opera el equipo de trabajo en uno de sus proyectos más importantes,
especialmente las actividades del grupo de Desarrollo que están funcionando, las que
no o no existen y los objetivos y metas que tienen o esperan alcanzar.
2
La segunda parte de este documento se caracteriza por ser la parte práctica de
esta propuesta donde se aplica todo lo de�nido, especi�cado y analizado en loa ca-
pítulos anteriores. En el Capítulo 6 - Construcción del Proceso se diseña un proceso
basado en los problemas y las necesidades del caso de estudio especi�cado, en los
procesos diseñados por QualDev los cuales se justi�can en su experiencia como grupo
de construcción de software. Luego en el Capítulo 7 - PAL: Proceso de Construcción
de Software de LIDIE se hace la de�nición del proceso junto con su manual de uso,
mientras que en el Capítulo 8 - Evaluación de Herramientas se hace un análisis de
las herramientas que actualmente utilizan para soportar su proceso de desarrollo,
se hacen una serie de sugerencias de como utilizar mejor dichas herramientas y se
hace una serie de sugerencias de herramientas ´necesarias para apoyar procesos es-
pecí�cos y mejorarían el uso del proceso. En el Capítulo 9 - Resultados se presentan
los resultados obtenidos de la ejecución de este proyecto, en especial de la adapta-
ción del proceso. A continuación, en el Capítulo 10 - Conclusiones se presentan las
conclusiones de este trabajo, y �nalmente en el Capítulo 11 - Trabajo a Futuro se
presentan los diferentes campos en los que se puede extender el trabajo realizado en
este proyecto.
3
Capítulo II
Arquitectura de TI
El desarrollo de un producto de software requiere un proceso de�nido para que sea
efectivo y e�ciente. Antes de de�nir una metodología es importante que la empresa
donde se va implantar cumpla una serie de requisitos: Que tenga una de�nición clara
y concreta de si misma (misión, visión, objetivos, metas, estrategias), el segundo paso
es asegurarse que la razón de ser de la empresa provea una ganancia de acuerdo a
las metas establecidas, y por último es necesario que la empresa desee progresar,
evolucionar y mejorarse continuamente para destacarse de la competencia. Una vez
establecido estos objetivos es necesario que la empresa identi�que el valor de la
tecnología y la forma en que puede favorecer a la empresa. Una vez hecho esto
y que la empresa haya identi�cado efectivamente la necesidad de la Tecnología de
Información (TI), en su empresa, es importante de�nir la Arquitectura de TI que
la empresa va a tener.
La Arquitectura de TI [Ros03] es la organización lógica de los aplicativos, datos y
la infraestructura tecnológica, incluyendo el conjunto de políticas y decisiones técni-
cas que soportan las estrategias de la organización. Las capacidades y la limitaciones
en TI se deducen de la arquitectura de TI. La arquitectura de TI especi�ca lo que
la Tecnología de Información permite hacer al negocio.
Para desarrollar la arquitectura de TI de una empresa se debe de�nir los objetivos
estratégicos de la empresa, de�nir las capacidades claves de TI para alcanzar esos
objetivos y de�nir las políticas y decisiones técnicas requeridas para el desarrollo de
esas capacidades.
El desarrollo de una arquitectura de TI, consta de 4 etapas:
4
Arquitectura de Aplicativos Tipo Silo. Busca optimización funcional mediante
aplicativos individuales por unidad de negocio.
Arquitectura de Tecnología Estandarizada. Busca e�ciencia en TI, mediante la
estandarización de la tecnología incluyendo centralización.
Arquitectura de datos racionalizados. Busca optimización de los procesos me-
diante la expansión a la estandarización de datos y procesos.
Arquitectura Modular. Busca elecciones estratégicas mediante estándares em-
presariales con aplicativos levemente acoplados con componentes de datos y
tecnología que preservan los estándares globales permitiendo diferencias loca-
les.
Para crear una capacidad en arquitectura de TI se debe concentrar los esfuerzos
de su arquitectura en los procesos claves del negocio, no saltarse etapas (El orden es:
estandarización de datos, luego estandarización de procesos y �nalmente desarrollo
de módulos y servicios.), reconocer que en organizaciones complejas pueden coexis-
tir diversas arquitecturas en etapas diferentes, institucionalizar su arquitectura a
través de los mecanismos apropiados de gobierno de TI, mantener el diálogo y su
alineamiento con las estrategias del negocio y desarrollar una capacidad interna de
de�nición y control de la arquitectura.
Este trabajo se enfoca en la tercera etapa, por lo cual una estandarización de
tecnología es necesaria para el establecimiento de una estandarización de procesos
de una empresa, lo cual LIDIE posee.
5
Capítulo III
Modelos de Ciclo de Vida de Software
3.1. De�nición
Un Modelo de Ciclo de Vida de Software (MCVS) [Ltd05], es la descripción de
los principales componentes del desarrollo de software, y su interacción entre ellos.
Puede ser representado grá�camente para facilitar su comprensión y entendimiento.
Inicialmente, no existía un MCVS a seguir, por lo cual para el desarrollo de
proyectos pequeños esta carencia de un modelo a seguir era su�ciente, pero al rea-
lizar un proyecto grande, esa carencia se convertía en un proceso caótico que no
era su�ciente debido a la necesidad de trabajar con un grupo grande de personas,
por lo tanto la división de trabajo era indispensable. Debido a la carencia de un
procedimiento a seguir, la efectividad y e�ciencia del equipo de trabajo recaía sobre
sus integrantes, por lo cual se debía tener un equipo de desarrollo excelente. Ante
la necesidad de tener un �equipo de desarrollo perfecto�, lo cual es prácticamente
imposible, se de�nió la forma de trabajo en estándares y de esta forma nacieron los
MCVS.
Un MCVS establece reglas y procedimientos claros para el desarrollo de Software,
facilitando la comprensión de la forma en la cual se va a trabajar para desarrollar
un determinado artefacto1 , las reglas y procedimientos utilizados son:
De�nición del trabajo a realizar. Para poder desarrollar un artefacto, es impor-
tante saber cual es la necesidad que se va a satisfacer, identi�cando claramente
todas las variables que lo afectan y los recursos a utilizar, teniendo en cuenta
1Objeto que ha sido manipulado por el hombre, en este caso, es el producto del desarrollo deun proceso o subproceso
6
siempre las especi�caciones dadas por el cliente.
División del trabajo en piezas manejables. Al desarrollar un artefacto, espe-
cialmente uno de grandes dimensiones, es claro que para poder realizar un
trabajo e�ciente es necesaria una distribución de trabajo que evite con�ictos
entre ellos. Por otro lado, una división de trabajo se debe hacer de una manera
efectiva, para evitar dependencia entre las tareas de sus miembros y de esta
forma retrasar el desarrollo del artefacto, debe permitir evaluar el desarrollo
del artefacto, dividiendo el trabajo en etapas, y evaluar el desarrollo del arte-
facto al �nalizar cada etapa, mediante un seguimiento de la manera como se
está construyendo el producto.
Determinar las métricas mediante las cuales el desempeño del proyecto será
evaluado. Las métricas son un factor importante para evaluar tanto a los de-
sarrolladores como las herramientas utilizadas, la infraestructura de trabajo
y los recursos disponibles. Su importancia radica en que mediante el uso de
métricas, se puede identi�car los problemas existentes al observar que aspec-
tos medidos tienen cali�caciones bajas y buscar soluciones viables, en cuanto
a las cali�caciones aceptables o buenas se puede investigar nuevas alternativas
para mejorarlas (Mejoramiento continuo). De esta forma no solo se puede me-
jorar las condiciones de trabajo, sino en algunos casos se puede innovar para
aumentar el desempeño de los proyectos.
De�nir la interacción de las unidades de trabajo. Mientras una unidad de tra-
bajo es un conjunto de tareas desarrolladas, mediante las cuales un conjunto de
recursos son transformados en un artefacto; su interacción con otras unidades
de trabajo se hace mediante el desarrollo de un conjunto de actividades sobre
el artefacto que cada unidad desarrolla para poder llegar al producto �nal. Es-
ta interacción puede ser el desarrollo de un artefacto mediante la construcción
individual de artefactos para luego integrarlos o añadirle más características a
artefactos previamente desarrollados en unidades de trabajo anteriores.
7
Especi�car como se va a almacenar los artefactos (Administración de con-
�guraciones). Cada artefacto resultante debe estar almacenado en un sitio
especi�co el cual debe ser conocido y de fácil acceso para facilitar las consultas
(artefactos existentes que son similares a los que se están realizando), entregas
(artefactos �nales listos para su entrega al cliente), modi�caciones posteriores
y evaluaciones (Como ha sido la efectividad del producto).
De�nir la estrategia de desarrollo a utilizar (Planeación). Debe ser establecida
la forma en la cual se va a realizar el trabajo y el tiempo destinado, deben
ser establecidos para evitar ambigüedades durante el tiempo de desarrollo del
producto, mediante un seguimiento constante de lo realizado contra lo planea-
do.
Comunicar la estrategia de desarrollo a las personas interesadas (Clientes,
superiores, compañeros de trabajo). La comunicación entre todos los partici-
pantes del grupo es fundamental para el correcto desarrollo de un producto,
para poder hacer un seguimiento de la elaboración correcta del producto y
para el control de riesgos. Este control de riesgos evita que un incidente se
convierta en un problema, evitando la desviación de recursos y el aumento de
costos que genera la solución de problemas.
Un MCVS alcanza estas reglas y procedimientos al:
Proveer una grá�ca simple del trabajo a ser realizado. Es importante saber
comunicar la forma en la cual se está trabajando, por lo que para poder expli-
car cualquier procedimiento, o cualquier proceso un profesor, un gerente, un
administrador, o un ingeniero utiliza dibujos y esquemas, porque para cual-
quier persona es más fácil entender un grá�ca que una serie de procedimientos
complejos explicados oralmente o escritos en un papel, de la misma manera,
es más fácil para los mismo empleados recordar su forma de trabajo.
Permitir enfocarse en aspectos importantes de trabajo, dejando a un lado los
detalles excesivos. Identi�cando los aspectos más importantes del trabajo, un
8
MCVS permite priorizar las actividades y de esta forma organizar adecuada-
mente la forma de trabajar.
Proveer una unidad de trabajo jerárquica estándar para la descomposición pro-
gresiva del trabajo en piezas manejables. Esto permite una buena distribución
de trabajo, una buena forma de hacer seguimiento al artefacto que se está
produciendo.
Proveer adaptación a bajo costo. Esto permite mayor �exibilidad y mantenibi-
lidad tanto a los procesos como a los artefactos cuando se presenten cambios.
3.2. Procesos
Para planear correctamente el desarrollo de un producto de software, este con-
junto de actividades se debe ver como un proceso, el cual a su vez se compone de
un conjunto de subprocesos, los cuales se clasi�can de la siguiente manera:
Procesos de Soporte del Proyecto. Es el conjunto de procesos que se re�eren al
manejo del desarrollo del software y que debe ejecutarse durante todo el ciclo
de vida del proyecto. La administración de con�guraciones es un ejemplo de
este tipo de procesos.
Procesos de Desarrollo. es el conjunto de procesos, típicamente interdepen-
dientes, que contribuyen directamente al desarrollo del entregable del proyecto.
Análisis, diseño e implementación son ejemplos claros de este tipo de procesos.
Procesos Transversales o Integrales. Son el conjunto de procesos que son desa-
rrollados en el contexto de más de una actividad, por ejemplo la administración
de los documentos y la administración de riesgos se aborda tanto en la fase de
diseño, como en la de implementación y de la misma forma en otras activida-
des.
Cada proceso está conformado por un conjunto de unidades de trabajo, haciendo
una analogía, cada unidad de trabajo se puede ver como una pequeña fábrica, la cual
9
tiene: unos criterios de entrada, que en este caso serían las condiciones necesarias
para que la unidad de trabajo pueda comenzar trabajar, unos criterios de salida, los
cuales son un conjunto de condiciones por medio de los cuales se puede a�rmar que
la unidad de trabajo ha cumplido su objetivo. Estos criterios se encargan de veri�car
que los �ujos de trabajo, tanto de entrada como de salida, sean los indicados, mientras
que estos �ujos de trabajo son los artefactos que �uyen de una unidad de trabajo a
otra. Finalmente, los estamentos de trabajo se encargan de describir como se realiza
el trabajo para transformar los �ujos de entrada en �ujos de salida. Cada unidad de
trabajo da retroalimentación a una unidad de trabajo precedente. El de�nir caminos
de retroalimentación, provee mecanismos para el desarrollo de artefactos de mejor
calidad, lo cual permite generar artefactos completos y correctos en su primer punto
de aprobación. Para poder de�nir estos caminos de retroalimentación, es necesario
establecer procedimientos mediante los cuales se identi�quen errores y su contraparte
para corregirlos.
Aunque las unidades de trabajo son pequeñas partes del problema a solucionar
mediante el desarrollo de un producto, siguen siendo complejas por lo cual se requiere
descomponer estas grandes unidades de trabajo en niveles, por lo general se utilizan
tres niveles y son:
Nivel de Fases. Las fases describen los niveles más altos de actividad en el
proyecto. Por ejemplo: Estrategia, Diseño o Implementación.
Nivel de Actividades. Las actividades son unidades de trabajo de una fase,
generalmente se hacen en equipos. Por ejemplo: la entrevista con un usuario
es una actividad que hace parte de la fase de Análisis.
Nivel de Tareas. Las tareas son componentes de una actividad que general-
mente son realizadas por una o dos personas, y tienen un tiempo establecido
en un cronograma. Por ejemplo, se podría establecer que el tiempo promedio
para la elaboración de una tarea simple es de 5 días de trabajo, el tiempo
máximo es de 15 días de trabajo.
Los MCVSs se dividen en dos enfoques[BD04], de acuerdo al aspecto que ataca,
el proceso o el producto. Si el objetivo es atacar el proceso se dice que el modelo es
10
centrado en la actividad, pero si el objetivo es el producto, se dice que el modelo
es centrado en la entidad. A continuación se explica cada uno de los enfoques y los
procesos principales que corresponden a ellos.
3.3. Tipos de Modelos
3.3.1. Modelos Centrados en la Actividad
Los modelos centrados en la actividad se caracterizan por la manera en que los
productos son creados. Existen dos formas de manejar el modelo, secuencialmente
o iterativamente.
3.3.1.1. Modelos Secuenciales
Los modelos secuenciales se caracterizan por ser vistos como líneas de producción
en una fábrica. La debilidad de estos modelos, consiste en asumir que una vez una
actividad es �nalizada y revisada, el artefacto asociado puede considerarse como
línea base y esto sólo sería apropiado sí la especi�cación de los requerimientos fuera
altamente con�able y estable. Los principales modelos secuenciales son:
Cascada. Este es uno de los primeros modelos que se plantearon, propuesto por
W. W. Royce en 1970 [Roy70]. Su autor recomendaba su uso repetidamente (ite-
rativamente), pero este factor nunca se tuvo en cuenta. El modelo de cascada se
caracteriza por la ejecución secuencial de actividades: Procesos de desarrollo y de
administración. Las fases de las que consta son: Análisis de Requerimientos, Diseño,
Implementación, Pruebas, Integración y Mantenimiento. Al �nalizar una fase todas
las actividades de esa fase deben estar terminadas y no se puede regresar a una fase
anterior. Durante todo el proceso hace una veri�cación (Fase de Pruebas) constante
para evitar requerimientos no deseados y se mide el progreso por el número de tareas
que se han completado. Se asume que el desarrollo de software puede ser programado
como un proceso �paso por paso� que transforma las necesidades del usuario en un
artefacto (código).
Ventajas. Es simple para comprender y usar.
11
Desventajas. Cuando se utilizan iteraciones, estas crean problemas en el do-
minio de la aplicación. Una versión no funcional solo estará disponible hasta
el �nal del proyecto. No puede haber retroalimentación.
V. Este modelo es una variación del modelo de cascada, sus primeras publicaciones
fueron en 1995 por Bröhl y Dröschel [BH95] y la versión sacada en 1997 fue adoptada
por la administración federal de Alemania para regular el proceso de desarrollo de
software. Este modelo consta de 7 fases clasi�cadas en:
Actividades de Especi�cación. Especi�caciones de los requerimientos del Usua-
rio, Especi�caciones Funcionales, Especi�caciones del diseño.
Actividades de Desarrollo. Dependiendo del tipo de sistema y el enfoque de la
fase de Desarrollo, estas actividades pueden consistir de codi�cación, con�gu-
ración, o personalización.
Actividades de Cali�cación. Cali�cación de la Instalación, Cali�cación de la
Operación, Cali�cación del Desempeño.
Durante toda la duración del proceso, existe una dependencia entre las activida-
des de desarrollo y las actividades de veri�cación, de esta manera desde la fase de
requerimientos hasta la fase de desarrollo se enfoca en construir incrementalmente
una representación detallada del sistema, mientras que de la fase de desarrollo a
la de desempeño se enfoca en validar el sistema. La última versión corresponde al
año 2005, llamada V-Model XT, la cual actualiza el modelo del 97 con los nuevos
desarrollos tecnológicos, regulaciones y estándares.
Ventajas. Enfatiza la importancia de tener en cuenta desde un comienzo las
pruebas. Las pruebas después de cada fase proporcionan retroalimentación.
Desventajas. El diseño e implementación de pruebas es costoso. Cuando se
utilizan iteraciones, estas crean problemas en el dominio de la aplicación.
12
3.3.1.2. Modelos Iterativos
Los modelos iterativos se enfocan en el desarrollo de un producto en ciclos, es
decir que las fases del proyecto son repetidas varias veces, una secuencia de fases es
un ciclo. Los principales modelos son mencionados a continuación:
Espiral. Este modelo fue de�nido por Barry Boehm en su artículo �A Spiral Model
of Software Development and Enhancement� en 1986 [Boe86], y está caracterizado
por ser el primer modelo en explicar la importancia de las iteraciones además de
adicionar actividades como Administración de riesgos, Reutilización y Desarrollo de
Prototipos para cada fase; estas actividades vistas como una extensión al modelo de
cascada, son llamadas espirales. Las espirales atacan los riesgos incrementalmente en
orden de prioridad. Cada ciclo está compuesto de cuatro fases que se repiten cíclica-
mente en cada espiral: Determinación de los Objetivos y Limitaciones del Proyecto,
Evaluación de los Riesgos, Ingeniería (Desarrollo y Veri�cación del siguiente nivel
del Producto) y, Administración y Planeación. Es utilizado en proyectos de gran
tamaño.
Ventajas. Enfatiza la importancia de hacer un análisis de riesgos. Fácilmente
se puede integrar con otro MCVS.
Desventajas. Es necesario una considerable experiencia en la administración
de riesgos.
Prototyping. El concepto de prototyping, rápidamente generar un prototipo2 ,
ha existido desde hace mucho tiempo, pero fue en 1981 que fue introducido por
Gomaa y Scott como una práctica e�ciente para determinar los requerimientos del
cliente antes de establecer las especi�caciones del sistema para el nuevo producto
de software. Pero fue hasta 1987 que fue de�nido como un MCVS por Guillemete,
Gervickas y Renaldo [Mob99].
Prototyping esta compuesto de cuatro fases: Análisis, Diseño, Prototyping y
2Boceto o borrador de un nuevo producto
13
Evaluación del Usuario. En la fase de análisis se identi�can y se de�nen los reque-
rimientos planteados por el usuario en la aplicación a desarrollar, luego en la fase
de diseño es integrada la información recogida en la fase de análisis, después en la
fase de prototyping se diseña el prototipo, y �nalmente en la fase de evaluación el
usuario cali�ca el prototipo y se comienza otro ciclo desde la fase de Prototyping, al
generar un nuevo prototipo teniendo en cuenta la retroalimentación proporcionada
en la fase de evaluación.
Ventajas. Un prototipo ayuda a comprender mejor el problema y a obtener
retroalimentación del cliente. El re�namiento y el cambio en el prototipo se
basan en la retroalimentación.
Desventajas. No considera la calidad ni la mantenibilidad a largo plazo. Gran
cantidad de compromisos de implementación son hechos, por lo cual el pro-
ducto �nal podría ser inapropiado o ine�ciente.
RAD - Rapid Application Development. Este modelo fue planteado por Ja-
mes Martin en 1991 [Mar91], y se caracteriza por el desarrollo muy rápido de siste-
mas, la dependencia de las características especí�cas del proyecto y el uso de varias
técnicas para la optimización del proceso basado en la rapidez.
El enfoque, la información, las decisiones, el equipo, la arquitectura y los reque-
rimientos no funcionales del proyecto son las características especí�cas del proyecto.
El enfoque está conformado por los objetivos del proyecto, los cuales deben estar
bien de�nidos. La información es el conjunto completo o parcial de datos necesarios
para el desarrollo del proyecto. Las decisiones, son hechas por un número peque-
ño de personas que están disponibles y trabajan relativamente cerca. El equipo, es
pequeño (menor a 7 personas). La arquitectura, debe ser clara y debe estar bien de�-
nida, y los componentes tecnológicos claves se deben encontrar en el lugar de trabajo
y ya debieron haber sido probados. Los Requerimientos no funcionales(tiempos de
respuesta, rendimiento del procesamiento, tamaño de las bases de datos, etc.), son
razonables dentro de las capacidades de la empresa.
Prototipos (Prototyping), iteración y la entrega a tiempo (Timeboxing), son las
14
principales técnicas de optimización. Los Prototipos permiten crear un resultado
demostrable tan pronto como sea posible y re�nándolo según la interacción con el
cliente, donde el problema radica en hacerlo demasiado temprano o demasiado tarde.
La Iteración permite hacer desarrollo incremental basado en el re�namiento. Y la
Entrega a Tiempo centra la atención en la entrega por encima de todos los otros
aspectos que involucra el proceso.
Además empresas como Creative Data Inc. [CD05] utilizan una metodología de
desarrollo llamada Joint Application Development (JAD), la cual es un proceso ori-
ginalmente desarrollado por Wood y Silver en 1995 [WS95] para diseñar un sistema
basado en un computador.
El uso del JAD, permite agrupar a la gente perteneciente al área del negocio y
a los profesionales de TI en un taller estructurado enfocado altamente en el traba-
jo, mediante sesiones. Las sesiones se caracterizan por estar muy bien enfocadas,
conducirsen en un ambiente dedicado, rápidamente manejar los principales requeri-
mientos y el �look and feel� de la interfaz grá�ca. Los participantes de las sesiones
típicamente incluyen:
1 facilitador, que se encarga de reforzar las reglas y moderar las discusiones.
De 3 a 5 usuarios �nales, quienes asisten a todas las sesiones.
De 2 a 3 desarrolladores, quienes hacen preguntas para clari�car el producto
�nal que se desea.
1 cortador de vínculos, el director del proyecto, quien se encarga de cortar los
vínculos de los usuarios, usualmente no asiste.
2 o 3 observadores, quienes no hablan.
Un limitado número de expertos en el tema para comprender el negocio y la
tecnología.
Este MCVS consta de tres fases:
Planeación.
15
Construcción. Esta fase se caracteriza por conformar la parte iterativa del
MCVS, en la cual se desarrollan actividades (Requerimientos documentados,
Diseño, Desarrollo, Pruebas, Evaluación del Usuario y JAD) secuencialmente
en pequeños ciclos
Despliegue.
Ventajas. Optimización del proceso, basado en talleres de discusión interdis-
ciplinarios, priorización de la entrega y comunicación constante con el cliente
para la muestra de prototipos y generación de retroalimentación tanto para el
cliente, como para el desarrollador.
Desventajas. El diseño del prototipo debe hacerse en el momento correcto,
ni demasiado temprano, ni demasiado. El priorizar la fecha de entrega puede
ocasionar que no se tenga en cuenta otros aspectos importantes del proyecto.
tarde.
UP - Uni�ed Process. El proceso uni�cado, es el primer proceso robusto que fue
planteado por Ivar Jacobson en su libro �The Uni�ed Software Development Process�
de 1999 [IJ99]. Su robustez se debe a la gran cantidad de prácticas que utiliza. En este
proceso se identi�can rangos de tiempo llamados çiclos", los cuales son considerados
como el grado de madurez en el tiempo de vida de un sistema de software. Cada
ciclo está compuesto de cuatro fases: Inicio, Elaboración, Construcción y Transición;
y a su vez cada fase puede consistir de un número determinado de iteraciones,
donde cada iteración hace referencia a un conjunto de casos de uso relacionados o
mitiga algunos de los riesgos identi�cados al inicio de la iteración. Durante cada
iteración, unas actividades son desempeñadas en paralelo y son llamadas �ujos de
trabajo (Work�ows). Los �ujos de trabajo orientados al desarrollo son llamados �ujos
de trabajo de ingeniería (Requerimientos, Diseño, Implementación y Pruebas). Se
distinguen cuatro actividades transversales llamadas �ujos de trabajo de soporte:
(Administración, Ambiente, Valoraciones, Despliegue). Continuamente se enfatiza
la asignación de recursos para cada �ujo de trabajo durante fases e iteraciones al
manejar cada iteración como un proyecto de software aislado.
16
Este proceso está compuesto por un modelo de casos de uso que se relaciona con
un modelo de cada �ujo de trabajo, de esta forma cada modelo está relacionado con
otro al tener elementos claramente relacionados debido a que un elemento en un �ujo
de trabajo avanzado es producto de uno o más elementos de un modelo anterior.
Las dependencias entre modelos pueden ser mantenidas de diferentes maneras:
Ingeniería. Proceso de Software soportado en documentos de diseño del pro-
ducto �nal, los cuales fueron realizados para sentar las bases de como atacar
el desarrollo de la aplicación �nal.
Ingeniería en Reversa. Proceso se Software en el cual el desarrollo del producto
se hace primero y los documentos de diseño al �nal.
Ingeniería de Viaje Completo. Proceso de Software que utiliza Ingeniería para
soportar el proceso mediante documentos de diseño de la aplicación, e Inge-
niería en Reversa para actualizar esos documentos de diseño hechos anterior-
mente.
Ventajas. Desarrolla una documentación detallada y especí�ca.
Desventajas. Es muy pesado y complejo.
XP - Extreme Programming. Extreme Programming fue desarrollado por Kent
Beck, Ward Cunningham, and Ron Je�ries, cuyo trabajo fue publicado en 1999 por
Beck en su libro �Extreme Programming Explained� [Bec99]. Este modelo se carac-
teriza por el uso de 15 prácticas, las cuales son generalmente utilizadas con otros
MCVSs. Se le considera un proceso liviano, debido a las pocas prácticas que usa y
a la simplicidad que logra alcanzar cuando se cuenta con un buen grupo de diseña-
dores. Los grupos de trabajo generalmente son pequeños o medianos (Menor a 15
personas). Su principal objetivo es mejorar el manejo del proceso en una organiza-
ción mediante seguimiento y la de�nición de métricas, centrado en la comunicación
(Retroalimentación, cliente involucrado en el proceso). Las prácticas que el mode-
lo utiliza son: Planeación, Iteraciones Pequeñas, Metáfora del Sistema (Utilización
de las palabras adecuadas), Diseño simple (Utilización cuidadosa de Patrones de
17
Diseño), Testing, Refactoring, Pair Programming, Propiedad colectiva del Código,
Estándar de codi�cación, 40 horas a la semana, Integración continua, Cliente en el
sitio de los desarrolladores, Retroalimentación, Pasos Sostenibles y Simplicidad.
Ventajas. La interacción entre desarrolladores y clientes permite resolver dudas
y priorizar los requerimientos, gracias a la retroalimentación dada por el clien-
te. La generación de código simple, permite que la reconstrucción del sistema
y la ejecución y desarrollo de pruebas sea simple.
Desventajas. Si no se de�ne una buena forma de trabajo puede llegar a ser
ine�ciente debido a que carece de una estructura de�nida y un orden a seguir.
Si no se cuenta con buenos diseñadores puede ser caótico.
RUP - Rational Uni�ed Process. Como su nombre lo indica, es descendiente
del Proceso Uni�cado (Sección 3.3.1.2). Este MCVS fue planteado por G. Booch,
I. Jacobsen and J. Rumbaugh, integrando el UP con herramientas3 metodologías
utilizadas en UML4 por Rational Company [Kru03], para la cual trabajaban. Con
respecto al UP, se adicionó un �ujo de trabajo llamado �Modelación del Negocio�
antes del análisis, y debido a las herramientas utilizadas para soportar el proceso el
RUP es más e�ciente. las fases utilizadas por el RUP, son las mismas que en el UP:
Inicio. Toma aproximadamente el 10% del esfuerzo hacerlo, hace énfasis en
hacerse una idea y visión del producto, se hace la planeación (Estimación de
costos, recursos y planeación de la siguiente fase), y se identi�can los riesgos
y sus prioridades. Los �ujos de trabajo Administración y Requerimientos, son
dominantes.
Elaboración. Toma aproximadamente el 20% del esfuerzo hacerla, se especi�-
can los casos de usos5 , se genera la línea base de la Arquitectura de Software,
se hace una estimación detallada de costos y recursos, se re�nan los estimados
3Rational Unify Process (RUP)4Unify Modelling Language5Especi�cación detallada de la funcionalidad
18
iniciales, y se revisan los requerimientos y el modelo de casos de usos por cali-
dad y estimación de riesgos. Los �ujos de trabajo Requerimientos y Análisis,
son dominantes.
Construcción. Toma aproximadamente el 70% del esfuerzo hacerla, el sistema
se construye en una serie de iteraciones incrementales, se utilizan los procesos
de Desarrollo (Basado en el Diseño previo) y Pruebas del software. El artefacto
desarrollado al �nal de la etapa, se conoce como alpha-release. Los �ujos de
trabajo Análisis, Diseño e Implementación son dominantes.
Transición. Toma aproximadamente el 10% del esfuerzo hacerlo, Los artefactos
resultantes en esta fase son llamados b-release. Los �ujos de trabajo Diseño,
Pruebas y Mantenimiento, son dominantes.
Ventajas. Desarrolla una documentación detallada y especí�ca.
Desventajas. Es muy pesado y complejo. Está atado a las herramientas que
usa Rational Company.
TSP. El Team Software Process fue planteado por Watts S. Humphrey en su li-
bro �Introduction to the Team Software Process� del 2000 [Hum00]. TSP centra
sus objetivos en asegurar la calidad de los productos de software mediante métricas
de�nidas en un Plan de Calidad, crear productos de software seguros y mejorar la
administración de los procesos en la organización mediante el uso de estándares de
medidas de calidad y desempeño, para poder hacer Seguimiento y Planeación del
proyecto. El TSP también cuenta con una administración individual (Responsabi-
lidad, metas, Principios Sólidos) para permitir una independencia limitada de los
miembros al completar su misión, la cual esta limitada para poder hacer un buen
trabajo en equipo (Participación Activa, Metas Grupales) a la vez. Este desempe-
ño individual y grupal al mismo tiempo se hace mediante roles de�nidos (División
del Trabajo, Especialización de los Integrantes, Aprovechamiento de las Cualidades,
Habilidades y Experiencias Individuales, Compromisos).
19
Para la optimización del proceso se busca la reutilización de código a través
de ciclos, mejorar la productividad, la producción en cada ciclo de una versión de
prueba de una parte del producto �nal y el seguimiento del proceso a nivel grupal
e individual (PSP - Personal Software Process). El equipo de trabajo se caracteriza
por estar compuesto de dos o más personas cuyo trabajo está encaminado hacia
un objetivo en común. Debido al uso de ciclos puede utilizarse tanto para grandes
como para pequeños proyectos, pero está centralizado en el desarrollo de grandes
proyectos.
Ventajas. Se desarrolla métricas claras, claramente identi�cables. los objetivos
planteados son medibles. La planeación se basa en el desarrollo de proyectos
o ciclos anteriores. Permite el seguimiento del proceso y del trabajo de cada
uno de los integrantes del grupo.
Desventajas. Se requiere disciplina por parte de los integrantes del grupo. Se
requiere de buenas herramientas para que el seguimiento no sea muy costoso.
Un buen ejemplo de la especi�cación de un proceso utilizando este MCVS, es el
planteado por Hugo Arboleda [J.04].
3.3.2. Modelos Centrados en la Entidad
Los modelos centrados en la entidad enfocan sus prácticas en el contenido y la
estructura de los productos trabajados. El modelo basado en eventos es uno de los
mejores ejemplos [BD04].
Basado en Eventos. Este modelo esta basado en la lógica (rationale) del sistema
como un modelo de eventos. Cada proyecto inicia con un conjunto de eventos, en
el cual ocurren cambios frecuentes, los cuales son el objetivo a tratar. La principal
base del modelo es un historial de eventos, si este no existe, se utiliza la experiencia
del administrador o un documento estándar existente.
Los eventos están de�nidos en forma de preguntas, los cuales son guardados
en una �base de datos� de eventos disponible a los participantes del proyecto. Los
20
eventos se caracterizan por tener un estado, el cual puede ser cerrado, cuando el
evento ha sido resuelto, pero puede ser reabierto debido a cambios ocurridos en la
aplicación o en el domino de la solución; o abierto, cuando un evento no ha sido
resuelto. Estos eventos son resueltos a través de la discusión y de la negociación de
los participantes (desarrolladores, clientes) del proyecto. Los eventos también pueden
depender de otros eventos.
Este MCVS es recomendado, cuando la información y las relaciones son comple-
jas.
Ventajas. Es muy útil cuando la información y las relaciones son muy comple-
jas.
Desventajas. Si los cambios en el sistema no son muy frecuentes no se reco-
mienda su uso.
Actualmente se tiene una tendencia más alta a la utilización de MCVSs iterativos,
debido a que son más �exibles, y se pueden utilizar en ingeniería concurrente al
hacerles pequeñas modi�caciones.
21
Figura 1: Tabla Comparativa de Actividades de MCVSs I
3.4. Marco de Comparación de los Modelos de Ciclo de Vida
Observando y analizando los diferentes ciclos de vida, los criterios de comparación
son las características únicas y especí�cas que diferencian un modelo del resto (Ver
Figuras 1 y 2).
Las descripción de las actividades comparadas, clasi�cadas por procesos (Sección
3.2), es la siguiente:
Procesos de Soporte del Proyecto.
Administración. Esta actividad corresponde al establecimiento de objetivos y tác-
ticas de la empresa o grupo de desarrollo, tanto individuales como de grupo.
Aunque muchas veces esto se establece en la de�nición operativa de una empre-
sa, es necesario evaluarla al inicio de un nuevo proyecto cuando las necesidades
del proyecto lo ameriten, por lo cual puede que al iniciar un nuevo proyecto se
22
Figura 2: Tabla Comparativa de Actividades de MCVSs II
necesite rede�nirla totalmente.
Soporte y Mantenimiento. Esta actividad corresponde a la administración de
las con�guraciones y versiones en un proyecto.
Estrategia. Esta actividad corresponde al establecimiento de objetivos y tácticas
(Estimación de la duración del proyecto, como se piensa abordar, riesgos iden-
ti�cados y sus planes de mitigación, el alcance y la estructura de archivos a
utilizar) del proyecto.
Administración del Conocimiento. Esta actividad corresponde a la administra-
ción de la información capturada y transformada en conocimiento adquirido a
través del desarrollo de proyectos, la cual comprende tareas de a�anzamiento
del conocimiento al interior del grupo, mediante la consideración de ese cono-
cimiento como una propiedad colectiva y la capacitación de sus miembros en
nuevas prácticas.
23
Procesos de Desarrollo.
Especi�cación (Análisis y Diseño). Esta actividad corresponde a la de�nición
de requerimientos funcionales y no funcionales, diseño de diagramas y docu-
mentación.
Implementación. Estas actividad corresponde a la creación de la herramienta
computacional mediante la implementación de código.
Veri�cación. Esta actividad corresponde al diseño, implementación y ejecución de
pruebas.
Despliegue. Esta actividad corresponde a la presentación, entrega y lanzamiento
del producto �nal.
Procesos Transversales.
Historial de Eventos. Registro de la historia del desarrollo de las aplicaciones,
como tiempos, actividades desarrolladas, técnicas utilizadas, los productos de-
sarrollados y los clientes.
Optimización. Esta actividad corresponde a la utilización de técnicas para el me-
joramiento continuo y aumento de la productividad.
Refactoring. Esta actividad corresponde a la reutilización y actualización de ar-
tefactos existentes.
Prototyping. Esta actividad corresponde al desarrollo de prototipos de la aplica-
ción.
Planeación y Seguimiento. Esta actividad corresponde a la de�nición de un cro-
nograma en base en el cual se le hace seguimiento tanto al proceso como al
producto.
Taller Interdisciplinario de Discusión. Esta actividad corresponde a la discu-
sión del desarrollo de un proyecto, con representantes de cada uno de los roles
que participan en el proyecto.
24
Capítulo IV
Diseño de Procesos
Una vez establecido el MCVS (Cap. 3) a utilizar para el desarrollo de software,
es necesario diseñar el modo de operación de las actividades y tareas a realizar en
cada fase, para lo cual sin descuidar los aspectos ya tratados en el diseño de un
MCVS, es necesario tener en cuenta los siguientes aspectos:
Experiencia. La experiencia es fundamental como fuente de información al dise-
ñar una actividad especí�ca no solo cuando ya se han diseñado actividades similares,
sino también cuando se han utilizado o se ha sido cliente de una actividad similar,
es decir, cuando se ha recibido un artefacto de dicha actividad. Este aspecto es fun-
damental cuando se están optimizando actividades ya existentes, debido a que es la
base del mejoramiento continuo en un proceso.
De�nición de Objetivos. Es necesario establecer objetivos medibles para la acti-
vidad, tanto para poder evaluarlos, como para poder de�nir el alcance de la actividad
y el artefacto que será generado.
Artefacto a generar. Es necesario establecer las características del artefacto que
será producido durante la actividad, y su utilidad a lo largo del proceso.
Identi�cación de posibles lagunas. Un grave incidente para la ejecución de una
actividad, es cuando surgen lagunas o �malas interpretaciones� durante el desarrollo
de una actividad, debido a que puede producirse un artefacto no esperado y con
poca o ninguna relación con los objetivos planteados en un comienzo.
25
Actividad Anterior. Para el diseño de una actividad es necesario tener claro que
actividades deben estar ya realizadas para poder ejecutar la actual, debido a que se
utilizan artefactos realizados en esas actividades anteriores.
Actividad Siguiente. Para que una actividad llegue a buen término es necesario
saber que actividades necesitan los artefactos realizados por dicha actividad.
Análisis de las tareas. Debido a que cada actividad esta compuesta generalmente
por más de una tarea, es necesario establecer, según Chase y Aquilano [CA00]: la
descripción de las tareas, la secuencia de las tareas, la función de las tareas, la
frecuencia de las tareas, la importancia de las tareas, la relación con tareas de otros
trabajos, los requisitos de actuación, los requisitos de información, el control de los
requisitos, las posibilidades de error, la duración de las tareas, y los requisitos de
herramientas.
Análisis del trabajador. Debido a que la realización de una tarea especí�ca
requiere que la persona a asignar a dicha tarea tenga ciertas características y habili-
dades especí�cas, por lo cual es necesario establecer según Chase y Aquilano [CA00]:
requisitos de capacidad, requisitos de actuación, evaluación, nivel de habilidad, en-
trenamiento del trabajo, requisitos físicos, tensión mental, tedio, motivación, número
de trabajadores, nivel de responsabilidad, nivel de supervisión, responsabilidad de
calidad y nivel de empoderamiento.
Análisis Ambiental. Las características del entorno de trabajo son fundamen-
tales para garantizar la efectiva realización de este por lo cual es necesario, según
Chase y Aquilano [CA00], tener en cuenta: la situación del lugar de trabajo, la lo-
calización del proceso, la temperatura y humedad, la iluminación, la ventilación, la
seguridad, la logística, los requisitos de espacio, el nivel de ruido y la vibración.
Medición del Trabajo. Es necesario y fundamental el medir cada una de las
tareas realizadas por lo cual se utiliza el tiempo como unidad de medida para medir
cuanto fué la demora en la realización de dichas tareas. Adicionalmente, se pueden
26
establecer diferentes medidas tomando como base las características especí�cas de
las tareas o del artefacto generado. Según Niebel [Nie04], la medición del trabajo
facilita la identi�cación del tiempo improductivo y la de�nición de tiempos �jos para
la realización del trabajo.
La importancia del diseño de procesos yace en el conocimiento global que debe
tener cada miembro de una empresa en el desarrollo de todos sus procesos, por lo
cual al establecer este diseño en documentos facilita la comprensión de las funcio-
nes de cada miembro en la empresa, además de evitar tiempo improductivo en el
entendimiento de esas funciones y de su rol como miembro activo de esa empresa.
Aún más, cuando hablamos de una empresa de desarrollo de software, este tema se
vuelve vital, ya que el tiempo es uno de sus recursos más importantes.
27
Capítulo V
Caso de Estudio: LIDIE
Para poder estudiar a LIDIE, es necesario saber cuales son sus objetivos y hacia
donde se dirigen, además de conocer su forma de trabajo, por lo que se vió en la
necesidad de hacer una serie de encuestas para conocer como están organizados los
grupos interdisciplinarios de trabajo y como desarrollan su trabajo, para lo cual se
realizaron tres entrevistas, cada una dirigida a un grupo interdisciplinario utilizando
un formato de�nido (Ver Anexo 1 ).
5.1. De�nición de LIDIE
LIDIE es el Laboratorio de Investigación y Desarrollo sobre Informática en Edu-
cación del Departamento de Ingeniería de sistemas de la Universidad de Los Andes,
el cual comenzó hace 10 años como el Grupo de Informática Educativa (GIE).
LIDIE busca contribuir al mejoramiento de la educación en Colombia, mediante
la integración de nuevas tecnologías de información y comunicación a los procesos de
aprendizaje. Para esto el laboratorio hace investigación y desarrollo sobre ambientes
educativos computarizados de altísima calidad técnica y educativa; lleva a cabo
proyectos multidisciplinarios en áreas críticas para el desarrollo de la educación
y hace alianzas estratégicas con grupos líderes en educación e informática y con
organismos interesados en solucionar problemas educativos con apoyo de tecnología.
Así mismo asesora a empresas e instituciones académicas que deseen incursionar en el
mundo del software educativo, en metodologías, herramientas, estándares de calidad,
sistemas de evaluación, instrumentos de planeación estratégica de la información,
entre otros aspectos. Lidie se encuentra conformado por una Administración, la
28
cual se encarga de establecer y administrar proyectos, administrar las �nanzas y
de la administración de los recursos y liderar los cinco grupos interdisciplinarios
encargados de la construcción de los proyectos. Para más información acerca de
LIDIE, se puede consultar su página web [LID05].
5.1.1. Grupos Interdisciplinarios
Para el desarrollo de sus proyectos, LIDIE se encuentra conformado por cuatro
grupos interdisciplinarios: Pedagógico, Diseño Instruccional, de Desarrollo (El cual
consta de dos subgrupos: Implementación y Diseño Grá�co) y Evaluación.
Pedagógico. Está conformado por psicólogos, trabajadores sociales y peda-
gogos. Su principal objetivo es el diseño de metodologías de aprendizaje de
acuerdo a las necesidades educativas identi�cadas. Tiene un contacto constan-
te con el grupo de Desarrollo, debido a que se necesita una revisión continua
entre el proceso de desarrollo del producto y la satisfacción de esas necesidades
educativas identi�cadas, para que el producto cumpla el propósito para el cual
fue diseñado. Existe un líder del grupo, quien recibe el cargo de coordinador,
y es quien se carga de establecer y de�nir las líneas de investigación del grupo,
así como de guiarlo para que cumpla sus objetivos y metas establecidos.
Diseño Instruccional. Está conformado por ingenieros de sistemas en diferentes
niveles profesionales que van desde estudiantes de pregrado hasta maestros.
Su rol consiste en ser un mediador experto en tecnología entre el cliente y los
demás grupos interdisciplinarios, está labor la complementa al crear manuales
de usuario y asumir el rol de analista de sistemas para realizar el análisis de
requerimientos de la herramienta tecnológica que se va a desarrollar.
Desarrollo. Está conformado por ingenieros de sistemas, diseñadores grá�cos
y artistas. Se divide en dos subgrupos. El grupo de Implementación se encarga
de hacer el diseño y el desarrollo de los productos de software producidos, del
montaje de las aplicaciones y del apoyo tanto a los otros grupos de Desarrollo
como a los otros grupos interdisciplinarios. El grupo de Diseño Grá�co se
29
encarga de la construcción de la parte grá�ca del proyecto. Al igual que en el
grupo pedagógico, el grupo de desarrollo también tiene su coordinador, el cual
se encarga de establecer procedimientos y estrategias para el desarrollo de los
proyectos, así como de establecer todo el conjunto de herramientas necesarias
para el buen desempeño del trabajo del grupo.
Evaluación. Está conformado por psicólogos y antropólogos. Se encarga de la
evaluación de los procesos metodológicos y pedagógicos con y sin el producto
realizado, y de los productos desarrollados por el laboratorio. También se en-
carga de hacer encuestas y entrevistas, y su respectivo análisis para las tareas
que lo ameriten. Hacen seguimiento de los proyectos veri�cando los objetivos
contra la solución y su efectividad. Y al �nalizar un producto se encarga de ha-
cer su respectivo informe de análisis de impacto. Al igual que los otros grupos,
el grupo Pedagógico también cuenta con un coordinador, quien se encarga de
guiar el trabajo en cada uno de los proyectos como del mejoramiento continuo
de sus procedimientos y las líneas de investigación que surgen y pueden ser
aprovechadas.
5.1.2. El Proyecto AVA
Actualmente, LIDIE se encuentra desarrollando uno de sus más grandes e im-
portantes proyectos, el cual está orientado hacia los cursos presenciales de pregrado
dictados en la Universidad de Los Andes. El proyecto AVA - Ambientes Virtuales
de Aprendizaje, busca ser un apoyo a los docentes de planta, en donde mediante
un apoyo virtual se motive al estudiante en su aprendizaje a través del curso. Este
apoyo en el aprendizaje es desarrollado de acuerdo a la necesidad educativa y a los
requerimientos establecidos por el profesor que dicta el curso, teniendo en cuenta
el área de conocimiento en el que se desenvuelve el curso. De esta manera LIDIE
de�ne su proyecto en su página web [LID05] y en el portal diseñado especí�camente
para este proyecto [LID06c].
Los roles establecidos para el desarrollo de un AVA se dividen en roles globales, los
cuales comprenden todo el proyecto y los roles locales, los cuales están delimitados
30
por el grupo interdisciplinario al que pertenecen. Los roles identi�cados son los
siguientes:
Roles Globales
Coordinador de AVA. Su función es la de gerenciar el desarrollo del AVA, por
lo cual debe estar pendiente de su desarrollo por cada una de las fases por las
cuales pasa, y estar en comunicación constante con el cliente. Los coordinadores
de AVA del grupo Pedagógico tienen la capacidad de trabajar en 5 AVAs a
la vez. El coordinador de AVA del grupo de Evaluación se encarga de que el
modelo de evaluación realizado a un AVA especí�co se cumpla.
Coordinador de Grupo. Su función consiste en coordinar el trabajo de su grupo
y presentar propuestas para la mejora en el desempeño de su trabajo.
Director. Su función consiste en dirigir el laboratorio al recibir, identi�car y
aceptar propuestas de desarrollo de AVAs.
Cliente. El cliente puede ser uno o más profesores de un mismo curso, quienes
están interesados en encontrar la solución a una necesidad educativa insatisfe-
cha mediante el desarrollo de un producto, el cual en este caso es un AVA del
curso que el profesor dicta. El cliente debe estar en constante comunicación
con los desarrolladores del AVA para que el producto cumpla las expectativas y
los objetivos planteados para solucionar la necesidad insatisfecha identi�cada.
Roles Locales
Pedagogo. Su función consiste en proponer metodologías de aprendizaje para
el AVA. Este rol es desempeñado por cada uno de los miembros del grupo
Pedagógico.
Interlocutor. Su función consiste en ser un canal de comunicación entre el clien-
te y el grupo de Desarrollo, apoyar la solución desde una parte tecnológica al
establecer las limitaciones tecnológicas que se encuentren e identi�car y hacer
31
el levantamiento de los requerimientos de las herramientas computacionales
que el AVA necesita, para poder realizar a continuación un buen diseño de la
solución. Este rol pertenece al grupo de Diseño Instruccional.
Desarrollador. Su función consiste en desarrollar las aplicaciones necesarias
para la realización del AVA. Este rol es desempeñado por los miembros del
grupo de Desarrollo.
Diseñador. Su función consiste en desarrollar toda la parte grá�ca del AVA,
la cual consiste en el desarrollo de animaciones, grá�cas y plantillas html, y
su continua comunicación con el cliente para que la parte grá�ca del AVA sea
coherente con lo que el cliente desea. Este rol es desempeñado por el subgrupo
de Diseño Grá�co.
Soporte. Su función consiste en solucionar problemas tecnológicos y apoyar al
grupo de Desarrollo con el montaje de los AVAs, sus funciones son prestadas
a todo el laboratorio. Este rol es desempeñado por el grupo de Desarrollo.
Evaluador. Su función consiste en generar modelos de evaluación, realizar en-
trevistas, encuestas y observaciones de clase cuando se requieran, además de
hacerle seguimiento al AVA para veri�car que las metas y necesidades educa-
tivas fueron satisfechas al cumplir el modelo de evaluación de�nido. Este rol
es desempeñado por el grupo de Evaluación.
El proceso utilizado para el desarrollo de un AVA fue de�nido por Álvaro Galvis
en su libro �Ingeniería de Software Educativo� [Gal92], al cual se suma los roles
creados por LIDIE para el proyecto AVA, ocasionando que el proceso funcione de la
siguiente manera:
Actividades Generales Transversales. Este conjunto de actividades que no
corresponden a una fase especí�ca, siendo actividades que se repiten en cada fase o
las que marcan el inicio del proyecto, como lo es la aceptación del desarrollo de un
proyecto (Ver Figura 3).
32
Figura 3: Tareas vs. Roles I: Tareas Generales Transversales
Análisis Educativo. En esta fase se identi�ca la población objetivo y sus ne-
cesidades educativas, para plantear la metodología y las herramientas pedagógicas
necesarias, para construir el modelo de evaluación (Ver Figura 4).
Participantes:
Coordinador de AVA.
Evaluadores.
Interlocutor.
Productos:
Documento de Análisis Educativo.
Documento del Modelo de Evaluación.
Diseño. En esta fase se de�nen las actividades a realizar, la motivación para los
estudiantes, los roles participantes, los objetivos de aprendizaje y la organización
33
Figura 4: Tareas vs. Roles II: Tareas de Análisis Educativo
del AVA. Se divide en varias subfases, de acuerdo al documento a entregar, donde
primero se desarrolla la subfase de Diseño Educativo (Objetivos y Actividades de
aprendizaje), luego la subfase de Análisis de Requerimientos(De�nición del Sistema,
Glosario y Pruebas de Usuario o de Caja Negra) y �nalmente el Diseño Compu-
tacional (Diseño Arquitectónico, Diseño Detallado, Diseño de Interfaz). (Ver Figura
5).
Participantes:
Coordinador de AVA.
Diseñador.
Desarrollador.
Interlocutor.
Pedagogo.
Cliente.
34
Figura 5: Tareas vs. Roles III: Tareas de Diseño
Productos:
Documento de Diseño Educativo.
Documento de Análisis de Requerimientos.
Documento de Diseño Computacional.
Desarrollo y Montaje. En esta fase se construye el ambiente virtual basado en
el diseño previamente hecho, mediante el desarrollo de las herramientas necesarias
y el montaje del curso1 para que se encuentre disponible para los estudiantes y
profesores en cualquier momento (Ver Figura 6).
Participantes:
Coordinador de AVA.
1Integración de los contenidos con la parte grá�ca, plantillas y herramientas computacionalesdesarrolladas
35
Figura 6: Tareas vs. Roles IV: Tareas de Diseño, Tareas de Desarrollo y Montaje
Diseñador.
Desarrollador.
Soporte.
Productos:
AVA funcional.
Entrega. En esta fase se le hacen las pruebas necesarias al AVA, para �nalmente
hacer una entrega formal del AVA al profesor, mediante una completa capacitación
de su manejo (Ver Figura 7).
Participantes:
Coordinador de AVA.
36
Figura 7: Tareas vs. Roles V: Tareas de Entrega y Postmortem
Cliente.
Interlocutor.
Productos:
AVA Corregido y Lanzado formalmente.
Postmortem. En esta fase se realizan ajustes necesarios los cuales sólo se identi-
�caron cuando el AVA ya estaba en uso. Esta fase se termina con la realización del
informe de Impacto (Ver Figura 7).
Participantes:
Coordinador de AVA.
Evaluador.
Cliente.
Desarrollador.
37
Soporte.
Productos:
AVA Ajustado.
Documento de Informe de Impacto.
Todo este proceso de desarrollo del AVA se hace para cada proyecto, debido a que
generalmente cada proyecto no es de un gran tamaño, por lo tanto varios proyectos
se construyen al mismo tiempo. Esto genera un gran problema en el control del
proceso de desarrollo de los AVAs, ya que estos se hacen concurrentemente, a la vez
que el trabajo de cada grupo es concurrente al �nal y al inicio de las fases.
Los principales problemas identi�cados a través de todos los grupos son:
La incertidumbre de los cursos, ya que en cualquier momento de cualquier fase
se puede cancelar el desarrollo de un AVA.
La carencia de un número establecido de AVAs que entran a desarrollarsen en
un tiempo determinado, lo cual puede generar un cuello de botella en cualquier
fase debido al número de AVAs que se están desarrollando y a la complejidad
de cada uno de ellos.
La de�nición de un acuerdo escrito mediante el cual se de�ne especí�camente
los compromisos que tiene LIDIE con el AVA, y con el profesor y la duración
de dichos compromisos.
38
5.2. Estado Actual de LIDIE
5.2.1. Arquitectura de TI
Para el primer semestre del 2005, LIDIE tiene una arquitectura de silos, de acuer-
do a lo especi�cado en el (Cap. 2, debido a que utiliza una herramienta para cada
tarea, esta herramienta busca ser la mejor herramienta disponible para que se adecúe
a las necesidades para la tarea que se necesita hacer. Entre esas necesidades se busca
que la herramienta tenga el menor costo posible, y que sea completa, garantizando
de esta forma un desarrollo e�ciente de dicha tarea. Otra característica de este tipo
de arquitectura, y que afecta el modo en el cual se trabaja en LIDIE, es el bajo
grado de integración de estas aplicaciones, por lo cual no existe una comunicación
entre ellas que facilite el desarrollo de las tareas, es decir no existe un �ujo de trabajo
(De�nido en la Sección 3.1) que lo soporte, por ejemplo la comunicación constante
del estado de un proyecto con otro grupo de trabajo.
La Arquitectura de Software está conformada de acuerdo a los grupos interdis-
ciplinarios (De�nidos en la Sección 5.1.1) por:
Grupo de Evaluación
SPSS - Software de ciencias sociales para manejo de estadísticas. Es utilizado
para analizar la población objetivo de la necesidad del proyecto a satisfacer, y
el análisis de impacto del proyecto.
Atlas TI - Software para análisis cualitativo de encuestas. Es utilizado para
la identi�cación de los indicadores del modelo a formular y para facilitar el
análisis cualitativo de encuestas.
Perseus - Software para aplicación y administración de encuestas. Esta herra-
mienta es utilizada para facilitar más adelante los análisis cuantitativos de las
encuestas hechas.
O�ce - Software utilizado como herramienta de productividad, para el desa-
rrollo de documentos.
39
Grupo Pedagógico
O�ce - Software utilizado como herramienta de productividad, para el desa-
rrollo de documentos.
Dotproject - Bitácora del tiempo y de las tareas realizadas por cada persona
en el proyecto.
Grupo de Desarrollo
O�ce - Software utilizado como herramienta de productividad, para el desa-
rrollo de documentos.
MySQL - Manejo de Bases de Datos.
Eclipse - Programación. Esta herramienta es utilizada por el subgrupo de
Implementación para desarrollar las herramientas computacionales.
Macromedia Dreamweaver - Desarrollo de Páginas web. Esta herramienta es
utilizada para el desarrollo de plantillas por el subgrupo de Diseño Grá�co y
para la edición y/o creación de plantillas y/o páginas web por el subgrupo de
Implementación.
Apache - Plataforma utilizada para el servidor de LIDIE. Es administrada por
el subgrupo de Implementación.
Macromedia Flash, Fireworks y Director - Desarrollo de animaciones. Estas
herramientas son utilizadas por el subgrupo de Diseño Grá�co para crear y
editar animaciones y videos.
Adobe Photoshop - Diseño grá�co. Esta herramienta es utilizada por el sub-
grupo de Diseño Grá�co, para crear y editar imágenes.
Dotproject - Bitácora del tiempo y de las tareas realizadas por cada persona
en el proyecto.
40
CVS - Administración de versiones y de con�guración de los proyectos. Esta
herramienta es utilizada para la administración de los backups de los AVAs
terminados y para las herramientas computacionales creadas.
phpWiki - Hosting. Esta herramienta es utilizada para el hospedaje de herra-
mientas y documentos, y como bitácora de los productos.
Tomcat - Java Servlet Engine. Esta herramienta es utilizada por Apache para
el correcto funcionamiento del servidor manejado por el subgrupo de Imple-
mentación.
La Arquitectura de Hardware está conformada por:
1 servidor. Este servidor está instalado en una máquina con Windows 2000, la
cual se utiliza de dominio.
18 PCs. Estos computadores están distribuidos entre los tres grupos interdisci-
plinarios, los cuales son indispensables para realizar el trabajo correspondiente
de cada uno de los miembros del laboratorio.
1 LAN. Esta red es utilizada para la conexión externa como lo es el acceso a
Internet, y para el acceso a herramientas públicas e n la red interna como lo
es una de las impresoras.
2 portátiles. Estos portátiles son utilizados como medios de apoyo para el
trabajo individual cuando haga falta un computador para en el cual trabajar.
3 impresoras. Las impresoras son utilizadas para imprimir el trabajo realizado,
como ayuda presentada en documentos, o documentos que se necesiten.
1 escáner. El escáner es utilizado para tareas varias, como lo es digitalizar una
imagen.
1 cámara digital. El uso de la cámara digital se hace cuando se necesiten
fotografías para la parte grá�ca del AVA o para realizar alguna otra tarea
relacionada.
41
5.2.2. Características del MCVS del Proceso Actual
LIDIE, especí�camente su grupo de Desarrollo, consta con un grupo de acti-
vidades (Ver Figura 8), que en el proyecto AVA (De�nido en la Sección 5.1.2) se
encuentra ubicado en:
5.2.2.1. Fase de Diseño
Especi�cación.
Diseño Computacional. Establecimiento del diseño de la herramienta, me-
diante la elaboración de los diagramas necesarios para su correcto enten-
dimiento. El artefacto generado durante este proceso es el documento de
Diseño Computacional.
5.2.2.2. Fase de Desarrollo y Montaje
Desarrollo. Construcción de la herramienta computacional y montaje del
AVA.
Veri�cación. Realización de pruebas por requerimientos para veri�car el
correcto funcionamiento de la aplicación.
5.2.2.3. Fase de Diseño y Fase de Desarrollo y Montaje
A través de todo el proceso especi�cado en las fases anteriores se realizan las
siguientes actividades:
Soporte Instalación de las herramientas adecuadas y administración de ver-
siones de código de los backup de los productos.
Planeación y Seguimiento Realización de tareas de planeación semanal,
y reuniones de seguimiento de dicha planeación.
42
Figura 8: Diagrama de Gant del Proceso de Desarrollo de Software en Lidie porEntregables
43
5.2.3. Evaluación del Proceso de Desarrollo de Software
En LIDIE, especí�camente en el grupo de Desarrollo se ha visto la necesidad de
mejorar su proceso, lo cual ha generado que el área de investigación del grupo de
Desarrollo se centre en la mejora de su proceso de construcción de AVAs probando el
uso de varias prácticas para mejorar su proceso. Al observar su proceso de desarrollo
se identi�caron las actividades de los procesos (Sección 3.4) que están funcionando,
las que no y los objetivos y metas que se esperan para mejorar las actividades de
cada proceso:
5.2.3.1. Actividades que están funcionado
Procesos de Soporte del Proyecto
Administración. La diferenciación de los roles, genera un alto grado de
especialización no técnica, facilitando la asignación de tareas de acuerdo a sus
habilidades.
Optimización. La planeación de actividades, con sus respectivos tiempos
asignados para su desarrollo, genera un efectivo control del tiempo y experien-
cia para planear mejor el siguiente cronograma de actividades.
Procesos de Desarrollo.
Desarrollo. El desarrollo esta funcionando y cumple con los requerimientos
establecidos.
Despliegue. La presentación y entrega se hace de una forma adecuada.
44
5.2.3.2. Actividades que no están funcionado o que no existen
Procesos de Soporte del Proyecto
Administración.
No se tienen objetivos establecidos del grupo y de cada uno de los roles
de los participantes que sean medibles.
No se tiene asignado un rol que se encargue del seguimiento y la planea-
ción de actividades lo que ocasiona que uno de los miembros del grupo
de Implementación se encargue de esta labor, ocasionando que una gran
cantidad de tiempo se gaste en tareas de seguimiento.
No se tiene asignado un rol que se encargue del aseguramiento de la
calidad, tanto del producto como del proceso, ocasionando que no se
sigan los pocos estándares de�nidos, y que el valor agregado del producto
se incremente.
El �contrato� con el profesor no está de�nido, por lo cual no es clara la
mantenibilidad del producto en cuanto a actualización, el mantenimiento
que se le debería hacer y la persona responsable de ello.
No se tienen políticas de�nidas para la administración de la calidad.
No se tiene un modelo de ciclo de vida en el cual se base el proceso, y el
proceso no esta de�nido, por lo cual no existe una correspondencia entre
el modelo de ciclo de vida y el proyecto.
Soporte y Mantenimiento.
La migración de los productos terminados es problemática, debido a que
además de los backup de los AVAs terminados, estos pasan a estar a cargo
de la DTI, y el proceso de migración es costoso, dispendioso, y no está
de�nido.
No está de�nido el alcance del soporte que se le hace al producto.
45
La integración de las herramientas es poca lo que ocasiona la alta frag-
mentación de la información, y el difícil acceso a ella para los demás
grupos interdisciplinarios.
Estrategia.
No se tiene ni objetivos ni tácticas a utilizar.
No se hace un análisis de riesgos, ocasionando que no se haga una ad-
ministración de riesgos, por lo tanto no se tiene políticas de�nidas para
cuando el profesor no cumple con su tarea en la identi�cación de las nece-
sidades educativas y ocasiona el retraso en el desarrollo del AVA del cual
es responsable. Esto también ocasiona retrasos en el proceso de desarrollo
de otros AVAs.
Administración del Conocimiento.
La información y el conocimiento del grupo está disperso.
No se tiene establecido un plan de capacitación tanto para nuevos como
para antigüos miembros.
Procesos de Desarrollo.
Especi�cación.
El establecimiento de los requerimientos de una aplicación, debido a los
constantes cambios en los objetivos de aprendizaje y a la falta de comuni-
cación en el momento requerido para esta comunicación de cambios entre
los grupos interdisciplinarios.
Implementación.
No se tiene un proceso de�nido y documentado que soporte el proceso de
construcción de la herramienta computacional.
46
Veri�cación. No se hace un diseño de pruebas, por lo que las pruebas a
veces llegan a ser incompletas y super�ciales.
Procesos Transversales.
Historial de Eventos.
La documentación es casi inexistente.
La información se encuentra fragmentada por la de�ciencia en la docu-
mentación de los productos y de los procesos, y por la rotación continua
de los miembros del grupo.
La documentación existente que se tiene es poco útil.
Optimización.
El realizar trabajo en equipo es difícil, aunque se intenta, debido a la
gran cantidad de proyectos a desarrollar obligando a cada miembro del
subgrupo de Implementación a trabajar individualmente.
No hay un análisis del proceso de construcción de las herramientas de-
sarrolladas en cada uno de los proyectos con el cual retroalimentar el
proceso.
Refactoring.
La reutilización no es efectiva debido a la de�ciencia en la ubicación y
centralización de la información de proyectos anteriores, ocasionando que
la consulta de la información sea difícil.
La información se encuentra fragmentada por la ausencia de documenta-
ción de los productos y de los procesos, y por la rotación continua de los
miembros del subgrupo de Implementación.
Prototyping. No se tiene ni un proceso, ni estándares para la construcción
y modi�cación de los prototipos de la herramienta, ya sea antes o durante su
desarrollo.
47
Planeación y Seguimiento.
No se tienen objetivos del proyecto establecidos que sean medibles.
El seguimiento del proceso, aunque se ha mejorado un poco, falta mucho
debido a que el grupo se encuentra en etapa de experimentación de prác-
ticas para mejorar el proceso y debido a que no existen documentos de
estándares a seguir.
No existen estándares de métricas para medir el grado de cumplimiento
de las actividades planeadas con respecto a los objetivos establecidos.
Taller Interdisciplinario de Discusión. La comunicación no es efectiva,
ni clara con los otros grupos interdisciplinarios cuando intercambian artefactos
entre si al comienzo y al �nal de las fases, lo cual ocasiona grandes lagunas
en la interpretación de lo que es requerido para la elaboración correcta del
trabajo.
5.2.3.3. Objetivos y Metas
Los objetivos van orientados hacia el grupo de Desarrollo, pero debido a
que es un grupo interdisciplinario, este depende de los artefactos realizados por otros
grupos, por lo que cuando de habla de proyecto se re�ere al AVA en el que el grupo de
Desarrollo está participando con los otros grupos interdisciplinarios. La aplicación de
estos objetivos para los otros grupos interdisciplinarios es responsabilidad de ellos,
por lo cual es recomendable que ellos también los apliquen ya que afecta el trabajo
del grupo de Desarrollo en ese proyecto y por lo tanto todo el proyecto en sí. Estos
objetivos y sus metas son planteados como una propuesta que re�eja la forma de
solucionar los problemas anteriormente expuestos, y no todos serán abordados en la
de�nición del proceso que construcción de software de LIDIE, que es el eje principal
de esta propuesta debido a que el alcance es demasiado grande, sin embargo los
objetivo o metas que no sean abordados servirán como guía al grupo de Desarrollo
de LIDIE para el mejoramiento continuo de sus procesos.
48
Mejorar el Trabajo en Grupo.
Establecer mejores canales de comunicación a nivel grupal(# de con�ictos
<1).
Establecer mejores canales de comunicación a nivel del proyecto(# de
con�ictos <5).
Establecer una mejor distribución del trabajo a nivel grupal (El desfase
en tiempo de la carga de trabajo de un integrante del grupo debe ser
menor al 5% con respecto al integrante con menor carga de trabajo).
Establecer una mejor distribución del trabajo a nivel del proyecto (El
desfase en tiempo de la entrega del proyecto debe ser menor al 5% con
respecto al tiempo estimado).
De�nición de las tareas que le corresponden a cada rol a nivel grupal-
roles locales(# de con�ictos <1).
De�nición de las tareas que le corresponden a cada rol a nivel del proyecto
- roles globales(# de con�ictos <1).
Mejorar la Calidad del Producto y del Proceso.
Aumentar la satisfacción del cliente(# de quejas o reclamos <1).
Entregar el producto a tiempo (El desfase en tiempo de la entrega del
proyecto es medido como el porcentaje del valor absoluto de la diferencia
entre el tiempo estimado y el tiempo utilizado, el cual debe ser menor a
l 5%).
Disminuir el tiempo utilizado en la modi�cación del producto en las fases
�nales del proceso (El # de errores encontrados en la fase de veri�cación
anterior a la entrega del producto, debe ser menor a 5).
Optimizar el uso de recursos (El desfase en tiempo de la entrega del
proyecto es medido como el porcentaje del valor absoluto de la diferencia
entre el tiempo estimado y el tiempo utilizado, el cual debe ser menor a
l 5%).
49
Evaluar el proceso de desarrollo (El desfase entre la correspondencia de
métricas por objetivo debe ser mayor o igual a 1).
Tener una propiedad colectiva de conocimiento (Por cada nuevo tema
investigado y aplicado un documento explicando lo realizado con dicho
tema).
Mejorar el Manejo de la Población Flotante.
Realizar e implantar un buen plan de formación.
Mejorar el proceso de selección (Per�les especí�cos para la selección de
nuevos integrantes).
Mejorar la e�ciencia en el desarrollo de tareas (De�nir procedimientos
claros y concisos).
Mantener información actualizada de cada integrante �otante(Por cada
integrante �otante, una �cha técnica).
Realizar e implantar un buen plan de formación.
Mejorar la e�ciencia en el desarrollo de las tareas (La relación tiempo-
complejidad de una tarea disminuye gradualmente con respecto a la tarea
anterior).
Mejorar la administración de con�guraciones.
Estandarizar artefactos.
Estandarizar los artefactos (Utilización de patrones únicos en el desarrollo
de los artefactos).
50
Capítulo VI
Construcción del Proceso
Para la construcción de un proceso de desarrollo, es necesario identi�car prime-
ro las necesidades más importantes que se desean cubrir y la metodología que se
va a utilizar para su construcción, ya que estas son las principales bases para la
construcción de un buen proceso.
6.1. Marco para Caracterizar a LIDIE
Antes de abordar una metodología de construcción de procesos es necesario esta-
blecer las características principales del proceso que se desean en el producto �nal, y
en el diseño de un proceso de construcción de software es indispensable establecer en
que MCVS se va a basar, no quiere decir que sea una garantía pero si aumentará la
probabilidad de que el resultado sea lo deseado. Las principales características sobre
las cuales se va a basar la construcción del proceso provienen de dos análisis previa-
mente realizados, el primero es la evaluación del proceso actual de construcción de
software del grupo de Desarrollo (Sección 5.2.3) y el segundo es la comparación de
MCVSs (Sección 3.4).
6.1.1. Identi�cación de las Características del Proceso Deseado
Las características identi�cadas y que el proceso de construcción de software de
LIDIE debería tener, son:
Estándares claros para el manejo de los contenidos de la documentación, pa-
ra la ubicación de documentos y para el nombramiento de artefactos y su
versionamiento.
51
Métricas claras para poder medir la calidad y efectividad del producto.
Liviano y fácil de soportar por herramientas de software libre y que no se ate
a una tecnología especí�ca.
Fácilmente adaptable a nuevos proyectos que puedan surgir, es decir que no
sea fuertemente dependiente del proyecto que se va a desarrollar.
6.1.2. Selección del Proceso
Teniendo en cuenta la tabla comparativa de MCVSs (Figuras 1 y 2), el modelo
más adecuado es una combinación entre TSP (Sección 3.3.1.2 y XP (Sección 3.3.1.2,
debido a que el TSP es uno de los MCVSs más completos, y las técnicas que utiliza
XP pueden adaptarse fácilmente al TSP, además de complementarlo y mejorarlo.
Uno de los aportes de XP es la propiedad colectiva del código, el cual se extiende a
una propiedad colectiva del conocimiento necesario en un grupo que realiza proyectos
concurrentemente, el otro aporte es la simplicidad de la comprensión del proceso, lo
cual no signi�ca que haya poco trabajo o que la complejidad de las tareas sea trivial,
signi�ca que hay un alto grado de entendimiento sobre las tareas que se tienen que
realizar, y el aporte �nal son iteraciones pequeñas, que a pesar que el proceso utiliza
ciclos para todo su desarrollo, las iteraciones pequeñas se aplicarán a las fases que
contengan las actividades más complejas.
6.2. QualDev Community y la Adaptación del Proceso
Para la adaptación del proceso se decidió utilizar como base el proceso de�nido
para el Proyecto Changeset, proyecto perteneciente a QualDev Group [Gro06e], que
hace parte del grupo de Construcción de Software de la Universidad de Los Andes.
El proceso de Changeset se caracteriza por ser un TSP �light�, debido a la aplicación
de varias prácticas de XP y otros procesos para el desarrollo de proyectos ágiles. Para
poder hacer esta adaptación se requirió entrar a participar en QualDev Group para
conocer más de cerca la forma de trabajo y observar el proceso que utilizaban en
el desarrollo de su proyecto Changeset, cuyo �n es desarrollar un software de apoyo
52
a la administración de con�guraciones, utilizando tecnología de punta y realizando
un proceso de desarrollo con énfasis en calidad [Gro06c]. Mediante esta alianza se
entró a participar en el proyecto QualDev Community, mediante el cuál se utilizó el
Modelo IDEAL para la adaptación del proceso de Changeset a la realidad que vive
el grupo de Desarrollo de LIDIE en la construcción de software.
6.2.1. QualDev Community
El proyecto QualDev Community tiene como �n ayudar a las empresas peque-
ñas y medianas de software de la industria nacional creando una relación en ambos
sentidos, donde QualDev como equipo aporta su conocimiento en procesos y herra-
mientas y las empresas como LIDIE acercan el proceso de Changeset a contextos
reales dentro de la industria del software [Gro06d]. Para el caso de LIDIE, la relación
creada con QualDev le permitió la creación de su proceso y a QualDev le permi-
tió retroalimentarse y estrechar sus vínculos con LIDIE para la creación de nuevos
proyectos a futuro.
6.2.2. El Modelo IDEAL
El proyecto de QualDev Community llevaba 4 meses de creado antes de su im-
plantación para la creación del proceso de LIDIE, pero el equipo de QualDev lleva
ya tres años de experiencia en conocimiento acerca de procesos, lo cual facilitó la
adaptación del proceso debido a la ejecución del modelo IDEAL, metodología uti-
lizada para la planeación de mejoramiento de procesos de desarrollo de software
propuesta por el Instituto de Ingeniería de Software (SEI por sus siglas en inglés) en
la Universidad de Carnegie Mellon [Uni06]. La implementación del modelo IDEAL
se basó en la metodología a seguir para su correcta implementación, descrita por
Camilo Rincón y Sergio Rodriguez en su tesis �Mejoramiento del Proceso de Planea-
ción y Seguimiento de Proyectos de Desarrollo de Software en Pequeñas Empresas�
[ySR05].
La metodología IDEAL recibe su nombre de las cinco iniciales de las fases que la
53
componen: Initiating (Inicialización), Diagnosis (Diagnóstico), Establishing (Esta-
blecimiento), Acting (Ejecución) y Leverage (Aprendizaje). El objetivo de la metodo-
logía es desarollar un trabajo efectivo cuando se construyen planes de mejoramiento
de procesos, este trabajo efectivo se realiza mediante la ejecución de la secuencia de
fases en iteraciones, de esta forma se presentan resultados a los objetivos planteados
inicialmente y al iniciar nuevos ciclos se ejecutan nuevos objetivos para continuar el
mejoramiento del proceso de construcción de software.
6.2.3. Ejecución de la Adaptación del Proceso
La ejecución del modelo IDEAL se realizó en dos ciclos, pero para el segundo ciclo
no se modi�có ni la fase de inicialización ni el diagnóstico debido a que los mismos
objetivos de la inicialización se mantuvieron para el segundo ciclo y el diagnóstico
continuaba siendo vigente. A continuación se describen todos los puntos a tratar en
cada fase del modelo IDEAL y como su ejecución permitió la adaptación del proceso
de construcción de software.
Inicialización. La inicialización es considerada la fase donde se de�nen las pautas
principales que se van a llevar durante toda la ejecución del modelo IDEAL para
lograr aplicar la metodología, por lo tanto se de�ne el proceso que se va a mejo-
rar, los objetivos globales, el alcance y �nalmente las responsabilidades para cada
participante.
Punto Crítico a Trabajar. La selección del punto crítico a trabajar se basó
en la identi�cación de los problemas encontrados en el grupo de Desarrollo
de LIDIE (Sección 5.2.3.2 y debido a que el alcance hubiera sido demasiado
grande si se hubiera considerado que se atacarían todos los problemas, por lo
tanto se escogió el proceso de Administración del Conocimiento. La selección
del proceso de Administración del Conocimiento como punto crítico a trabajar
se debió a que:
• No hay un proceso documentado ni unas líneas básicas que seguir, lo cual
ocasionaría un gran caos si se decidiera atacar cualquier otro problema,
54
debido a que se asumiría muchas cosas que no existen, por ejemplo si se
decidiera atacar el proceso de planeación, al �nal no se podría evaluar el
grado de éxito de la implantación debido a que no se de�nieron objetivos
medibles sobre los cuales evaluar dicho proceso.
• La administración de conocimiento contempla la propiedad colectiva del
conocimiento un punto importante, el cual debido a que no se tiene un
proceso de�nido, abarca todo el problema de de�nición del proceso ata-
cando todos los problemas encontrados en el grupo de Desarrollo de LI-
DIE en cierto grado, que por pequeño que sea sienta las bases para luego
poder atacar esos problemas puntualmente. Por ejemplo, al de�nir en el
proceso de construcción de software la fase de Estrategia, se comienza a
atacar la Administración de Riesgos.
Objetivos Globales.
• Centralizar el conocimiento del grupo de Desarrollo.
• Mejorar la metodología de construcción de software del grupo de Desa-
rrollo.
• Integrar el proceso de Construcción de Software del grupo de Desarrollo
con el proceso de Administración del Conocimiento.
Alcance de la Implantación. Implantación de un espacio de administración del
conocimiento que soporte el proceso de construcción de software que se genere
para el grupo de Desarrollo de LIDIE.
Asignación de Roles. Las responsabilidades asignadas para cada participante
son:
• Luz Adriana Osorio y Sergio Rodriguez se encargarían de hacer segui-
miento del proceso, lo cual generó sugerencias y recomendaciones a través
de la ejecución de la adaptación del proceso.
• Guillermo Aristizábal se encargaría de la revisión y discusión de la im-
plantación del proceso de Administración del Conocimiento. Gracias a
55
este rol, se entablaron discusiones sobre la adaptación de cada fase y
las actividades que se necesitarían en cada una, ayudando a construir el
proceso de construcción de software.
• Erick Escorcia se encargaría de la implantación del proceso de adminis-
tración del conocimiento. Al ejecutar este rol se construyó lo que sería
el proceso de construcción de software y su adaptación al ambiente de
LIDIE.
Diagnóstico. En esta fase, como su nombre lo indica, se hace un diagnóstico del
proceso que se decidió atacar, en este caso fue la Administración del Conocimiento,
especi�cando los objetivos a trabajar por niveles, y describiendo tanto el estado
actual del proceso como el estado deseado.
Objetivos Concretos a Trabajar. Se especi�can los objetivos globales por niveles
donde el número del nivel indica la profundidad de la especi�cación del objetivo
y al atacar los objetivos de los niveles más especí�cos se alcanzan los objetivos
del nivel superior:
• Nivel 1: Mejorar la Metodología de Construcción de Software del grupo
de Desarrollo.
• Nivel 2:
◦ Administrar y centralizar el conocimiento del grupo de Desarrollo.
◦ Integrar el proceso de Construcción de Software del grupo de Desa-
rrollo con el Proceso de Administración de Conocimiento.
◦ Implantación de un TSP básico y liviano adaptado al grupo de De-
sarrollo.
• Nivel 3:
◦ De�nición y adaptación de un espacio para la administración de cono-
cimiento: Wiki.
◦ De�nir las fases, las actividades necesarias por fase y sus plantillas.
◦ De�nir la clasi�cación de requerimientos y sus plantillas.
56
◦ De�nir los artefactos por fases y por tipos de requerimientos y sus
plantillas.
Estado Actual del Proceso.
• Descripción General: El proceso de construcción de software se centra en
la creación de aplicaciones tanto web (Basadas o no en un LMS - Learning
Management System) como standalone para el proyecto AVA (Ambientes
Virtuales de Aprendizaje), y no tienen un proceso de Administración de
Conocimiento que soporte dicho proceso.
• Detalle de la Metodología Actual: Actualmente la metodología que se
sigue está en las personas que trabajan en el grupo de Desarrollo, y se ca-
racteriza por hacer un diseño de la herramienta luego su implementación
y �nalmente pruebas de usuario.
• Puntos de Falla Identi�cados:
◦ No existe una metodología de construcción del software de LIDIE
que se pueda consultar.
◦ No hay una metodología para capacitar al personal de rotación.
◦ El conocimiento esta centrado en una sola persona: no hay propiedad
colectiva del conocimiento.
◦ No se tienen métricas para evaluar el proceso y el producto.
◦ No se tienen objetivos establecidos a nivel de grupo.
◦ No se hace una planeación global, que soporte la planeación indivi-
dual que se hace.
• Herramientas de Soporte: Se tiene una Wiki que no se utiliza y que está
desactualizada, es una Wiki orientada al desarrollador: phpWiki
• Reportes y Entregables:
◦ Diseño Computacional.
◦ AVA (Producto) Funcional.
57
Estado Deseado del Proceso.
• Descripción General: Se desea una administración del conocimiento que
soporte las labores de capacitación de la rotación personal, que facilite el
uso de estándares constantemente y que permita una propiedad colectiva
del conocimiento.
• Herramientas que se Pueden Implementar: Una Wiki, que se actualice
fácil y continuamente y que no este orientada únicamente al desarrollador,
ya que se desea extender el uso de la Wiki a todo LIDIE y LIDIE no esta
conformado sólo por ingenieros de sistemas, por lo cual la Wiki estaría
orientada a la edición de documentos: DokuWiki.
• Diagnóstico de la Ayuda del Qualdev Process: Se adaptará el Change-
set Process, basándose en las necesidades del grupo de Desarrollo junto
con el desarrollo de una Wiki, para que el grupo como equipo sea ca-
paz de administrar su conocimiento y descentralice el conocimiento de la
metodología del proceso para que se comience a generar una propiedad
colectiva de este en todo el grupo de Desarrollo. Debido a las caracterís-
ticas de LIDIE, para los procesos adicionales que se requieran de�nir y el
Changeset Process no lo de�na, se recurrirá principalmente al QualDev
Process y a TSP.
Establecimiento y Ejecución. En la fase de Establecimiento se de�ne el crono-
grama detallado. Para la de�nición de los cronograma de trabajo para la construcción
del proceso de LIDIE, se especi�có la tarea, su descripción, su fecha estimada de
entrega, su duración y el responsable. En cada uno de los ciclos se trabajo en la
adaptación de cada una de las fases a trabajar y su registro correspondiente en la
Wiki.
El objetivo de la fase de Ejecución es ejecutar el cronograma de�nido en la fase
de Establecimiento, y registrar cada una de las reuniones realizadas. La adaptación
del proceso para los dos ciclos consistió en llevar una propuesta para cada una de
las fases a adaptar, se discutía la propuesta, a la siguiente reunión se llevaba la
58
propuesta con las modi�caciones acordadas, y en la próxima reunión se dejaba lista
dicha fase y se llevaba lista la propuesta de la siguiente fase, de esta forma se adaptó
cada una de las fases (Sección 7.2. Al mismo tiempo que se adaptaba cada fase, se
iba preparando la Wiki [LID06a].
A continuación se describe lo planeado y se compara con lo realizado en la fase
de Ejecución:
Ciclo 1. El ciclo comenzó en septiembre y terminó en noviembre, como estaba
estipulado, aunque hubo problemas con respecto a la instalación de la Wiki,
debido a problemas de migración, se resolvió invirtiéndole más tiempo a la
instalación y al retraso que hubo en cuanto a la de�nición del proceso en la
Wiki, a pesar de que ya se tenía de�nido en documentos temporales. Las fases
adaptadas fueron: Lanzamiento, Estrategia, Planeación y Análisis de Requeri-
mientos; de las cuales hubo problemas de planeación en la de�nición de la fase
de Estrategia debido a que implicó la de�nición de más tareas de las cuales al-
gunas eran complejas como la administración de riesgos y la administración de
con�guraciones. Aunque el Análisis de Requerimientos no pertenece al grupo
de Desarrollo sino al grupo de Diseño Instruccional, fue necesario de�nir este
proceso para tener claro lo que necesitaba el grupo de Desarrollo para realizar
un correcto Diseño Computacional.
Ciclo 2. El ciclo comenzó en noviembre y terminó en diciembre, como estaba
estipulado, continuó el retraso que ocasionó la documentación del proceso en
la Wiki pero se terminó con éxito. Las fases adaptadas fueron: Diseño1 ,
Implementación, Pruebas y Postmortem. Se añadieron instructivos a manera
de tutoriales además de las plantillas para la correcta comprensión de como se
deberían llenar dichas plantillas.
Aprendizaje. En la fase de aprendizaje se evalúan los objetivos propuestos en
la fase de inicialización, se identi�can las lecciones aprendidas durante la ejecución
1De aquí en adelante a la fase de Diseño que pertenece al grupo de procesos de Desarrollo se ledenominará Diseño, la explicación se hace para evitar que sea confundido el nombre de la fase conla fase de Diseño propia del proyecto AVA y para simpli�car el lenguaje manejado.
59
del modelo IDEAL y �nalmente las propuestas de mejora, ya sean para próximos
ciclos o para una próxima ejecución del modelo IDEAL en la adaptación de nuevos
procesos.
Evaluación de los Objetivos. Debido a que los objetivos del nivel tres eran los
objetivos más especí�cos, esos fueron los que se evaluaron:
• Ciclo 1:
◦ De�nición y adaptación de un espacio para la administración de cono-
cimiento: Wiki. Como inconvenientes encontrados, hubo problemas
con la con�guración de la Wiki y con la disponibilidad del servidor
donde se debía instalar; mientras que como resultados de las mejoras,
el grupo de Desarrollo y el grupo de Diseño Instruccional comenzaron
a explorar la herramienta.
◦ De�nir las fases, las actividades necesarias por fase y sus plantillas.
Como inconvenientes encontrados, se percibió la inercia del grupo de
Desarrollo y su resistencia al cambio. Como resultados de las mejoras,
el grupo comenzó a concientizarse de que debían mejorar su proceso
debido a las exigencias que le estaba haciendo la DTI y a con�ictos
con el grupo de Diseño Instruccional con respecto a las tareas que
cada grupo debía realizar y la mejor forma para realizarlas; y �nal-
mente se de�nieron las fases de Lanzamiento, Estrategia, Planeación
y Análisis.
◦ De�nir la clasi�cación de requerimientos y sus plantillas. Como in-
convenientes encontrados no se percibió ninguno; mientras que como
resultados de las mejoras se identi�caron dos tipos de requerimientos
adicionales a los funcionales y no funcionales, que fueron los requeri-
mientos grá�cos y los de interacción.
◦ De�nir los artefactos por fases y por tipos de requerimientos y sus
plantillas. Como inconvenientes encontrados no se percibió ninguno;
mientras que como resultados de las mejoras se identi�có que desde la
60
fase de análisis hasta la de implementación se generaba un artefacto
por fase que debía contener cada uno de los tipos de requerimientos.
• Ciclo 2:
◦ De�nición y adaptación de un espacio para la administración de cono-
cimiento: Wiki. Como inconvenientes encontrados, hubo problemas
con la exportación a pdf debido a que para la versión de html2ps
instalada se maneja diferente a la versión con la cual se especí�co en
el tutorial de QualDev �Adaptación de DokuWiki� [Gro06a] y pre-
senta algunos problemas en algunos navegadores; mientras que como
resultados de las mejoras, el grupo de Desarrollo y el grupo de Diseño
Instruccional comenzaron a registrar su información en la Wiki.
◦ De�nir las fases, las actividades necesarias por fase y sus plantillas.
Como inconvenientes encontrados, se continúo percibiendo la inercia
del grupo de Desarrollo y su resistencia al cambio, aunque compa-
rándola con el ciclo anterior se redujo bastante; mientras que como
resultados de las mejoras, el grupo comenzó a reconocer lo necesario
de la de�nición de las tareas en un alto nivel de detalle y se de�nieron
las fases de Diseño, Implementación, Pruebas y Postmortem.
◦ De�nir la clasi�cación de requerimientos y sus plantillas. Como in-
convenientes encontrados no se percibió ninguno; mientras que como
resultados de las mejoras se corrigieron y mejoraron las plantillas
creadas el ciclo pasado.
◦ De�nir los artefactos por fases y por tipos de requerimientos y sus
plantillas. Como inconvenientes encontrados no se percibió ninguno;
mientras que como resultados de las mejoras se corrigieron los arte-
factos generados por fase al igual que las tareas especi�cadas para la
generación de dichos artefactos.
Lecciones Aprendidas. Las lecciones aprendidas constituyen la principal base
de retroalimentación del proceso de adaptación con respecto al conocimiento
adquirido gracias a su utilización.
61
• Ciclo 1:
◦ Es importante la retroalimentación que se hace y la comunicación de
las dos partes en todo momento.
◦ Los cambios deben hacerse poco a poco, ser adaptativos y utilizar el
diálogo adecuadamente para evitar con�ictos de intereses.
• Ciclo 2:
◦ La de�nición de tareas y sus plantillas no basta para a�anzar el cono-
cimiento, es necesario de�nir tutoriales, ejemplos y capacitaciones u
otras actividades complementarias.
◦ Es importante en la adaptación de procesos no seguir el proceso base
al pie de la letra sino proponer mejoras basadas en los comentario
recibidos de quienes lo utilizan diariamente y tener en cuenta otros
procesos existentes.
Puntos a Mejorar. Los puntos a mejorar se basan en los resultados obtenidos
de la evaluación de los objetivos y las lecciones aprendidas.
• Ciclo 1:
◦ Lograr mostrar cambios contínuamente y lo más rápido posible.
• Ciclo 2:
◦ Planear mejor las actividades a realizar de acuerdo al tiempo dispo-
nible y al tiempo requerido.
62
Capítulo VII
PAL: Proceso de Construcción de Software de
LIDIE
El proceso de Construcción de software de LIDIE se bautizó PAL para su fácil
reconocimiento y fácil referencia. Para la de�nición de PAL (Proceso de Administra-
ción de la Construcción de Software de LIDIE) se tomó la decisión de únicamente
centrar su de�nición en los procesos que representaban fases en el proceso de cons-
trucción de software de LIDIE, ya que esta es la base necesaria para la creación de
los procesos que extenderán a PAL a futuro.
7.1. De�nición del Proceso
Se toman los procesos analizados en el análisis hecho de los diferentes MCVSs
(Sección 3.4), para explicar el origen de cada una de las fases:
De los procesos de Soporte se de�nió la fase de Lanzamiento perteneciente
al proceso de Administración y la fase de Estrategia que representa el mismo
proceso que lleva su nombre.
De los procesos de Desarrollo se de�nieron las fases de Análisis de Reque-
rimientos y Diseño que pertenecen al proceso de Especi�cación, la fase de
Implementación que representa al proceso que lleva su mismo nombre y la fase
de Pruebas que es de�nida por el proceso de Veri�cación.
De los procesos Transversales se de�nió la fase de Planeación que hace parte
del proceso de Planeación y Seguimiento.
63
Finalmente, la fase de Postmortem es generada de la interacción de los pro-
cesos de Soporte y los procesos Transversales, ya que del primer tipo utiliza
la evaluación de los objetivos de�nidos en Lanzamiento (Parte del proceso de
Administración) junto con las lecciones aprendidas (Parte del proceso de Ad-
ministración de Conocimiento) para rede�nir la ejecución de próximos ciclos
y proyectos; y del segundo tipo utiliza la reutilización de históricos (Parte de
los procesos de Historial de Eventos y Refactoring) para cada una de las fases
y de�nición de métricas para poder realizar seguimiento al proyecto y al pro-
ducto y generar propuestas de mejora (Parte de los procesos de Optimización
y, Planeación y Seguimiento).
7.2. Fases
Para cada una de las fases se de�nió su propósito, su motivación y las actividades
que componen cada fase. Para cada actividad se de�nió su justi�cación, criterio de
entrada, descripción, entregables o documentos de soporte, criterio de salida y par-
ticipantes en el desarrollo de la actividad descrita. La estructura utilizada proviene
de la estructura manejada por el proceso de Changeset [Gro06b]. A continuación se
especi�can cada uno de las de�niciones mencionadas anteriormente para cada fase,
el único punto que no se muestra a continuación son las plantillas, instructivos y
ejemplos que se generaron para apoyar el desarrollo de cada tarea, por lo tanto se
recomienda consultar la Wiki de LIDIE [LID06a] donde quedó de�nido el proceso
con sus documentos de soporte [LID06b].
7.2.1. LANZAMIENTO
7.2.1.1. Motivación
Al iniciar un proyecto, sin importar el tipo de proyecto o el mercado en el cual
se va a desarrollar, lo más importante es de�nir el equipo y las reglas de trabajo,
ya que estos elementos son indispensables para la correcta ejecución del proyecto, es
por esta razón que la fase de Lanzamiento se hace necesaria cuando se va a ejecutar
un proyecto.
64
7.2.1.2. Propósito
La fase de Lanzamiento es el primer proceso de desarrollo que se lleva a cabo
una vez iniciado el proyecto. El lanzamiento de un proyecto de software consiste en
organizar el equipo y el proceso para que sean capaces de enfrentar el proyecto que se
inicia. Esta fase se realiza cada vez que se inicia un ciclo de desarrollo. Sin embargo,
su principal aporte ocurre en el inicio del proyecto cuando apenas se organiza toda la
infraestructura de desarrollo. Es por esta razón que el tiempo invertido en el proceso
de Lanzamiento es signi�cativamente mayor al inicio del proyecto.
El �n del proceso es lograr organizar el equipo bajo lineamientos claramente
establecidos, de manera que todos inviertan tiempo en actividades que converjan
al mismo punto. Esto se hace mediante la de�nición de roles, objetivos a diferentes
niveles, reglas de trabajo y horario de disponibilidad.
7.2.1.3. Proceso
A continuación se presentan las actividades que hacen parte del proceso de Lan-
zamiento desde la perspectiva de esta propuesta.
Actividad 1. De�nición de Roles
Justi�cación. La principal característica de esta propuesta es la adaptabi-
lidad del marco de referencia. No se puede esperar que para todos los proyectos,
los mismos y tradicionales roles sean adecuados. Por ejemplo, en algunos casos
de proyectos ágiles es muy probable necesitar un rol de líder de RyD.
De manera adicional, liderar el desarrollo de un conjunto de actividades refuer-
za y expande los conocimientos de los desarrolladores en un área especí�ca.
También genera más empoderamiento y capacidad de liderar. Estas cualidades
son importantes dentro del equipo. Al dividir la responsabilidad de liderar, se
genera sinergia dentro del equipo dejando de lado las tradicionales estructuras
jerárquicas de líderes y desarrolladores.
65
Criterio de Entrada.
Documento de levantamiento de requerimientos narrativos.
Documento de casos de uso generales.
Descripción. Dentro de un equipo es necesario que existan diferentes �gu-
ras que aseguren el buen desarrollo de un conjunto de actividades lógicamente
agrupadas. Por ejemplo, para el conjunto de actividades de planeación, es ne-
cesario asignar un integrante del equipo que sea el responsable de que estas se
realicen adecuadamente. A estas �guras dentro del proyecto se dice que se les
asigna un rol. Para el caso del ejemplo, sería el rol de planeación. La de�nición
de roles generalmente está limitada tanto por el número de integrantes del
grupo como por las características especiales del proyecto a desarrollar, es por
esto que los roles se de�nen teniendo en cuenta estos dos elementos, y no al
contrario ya que la de�nición de roles es una tarea que soporta el desarrollo
del proyecto y no al contrario.
Cada rol tiene un conjunto de actividades y tareas de las cuales es responsable.
Es importante resaltar que la disposición innata de los integrantes para ejecu-
tar un rol, es la base para asegurar el éxito de la tarea de ejercerlo. Por esto,
los roles no deben ser impuestos a los desarrolladores. Los roles son asignados
de acuerdo a la disposición inicial, y con la experiencia conocida de cada de-
sarrollador. Con la evolución del proyecto se puede ver si los roles estuvieron
bien asignados o por el contrario deben ser rotados.
Esta actividad consiste básicamente en revisar el proyecto para determinar
los roles que será necesario asignar dentro del equipo. Esta actividad no toma
mucho tiempo. Sin embargo, es sumamente importante para asegurar el buen
desempeño de todo el conjunto de actividades que se realizan en cada periodo
de desarrollo.
Diferentes roles pueden ser de�nidos dentro de un proyecto. Los roles que
generalmente se de�nen son:
Líder del Proyecto.
66
Líder de Planeación.
Líder de Calidad y del Proceso.
Líder de Desarrollo.
Líder de Soporte.
Es posible que para un proyecto particular sea necesario incluir nuevos roles
dentro del equipo. Por ejemplo, en el caso particular de los proyectos ágiles, se
hace necesario incluir un rol de pruebas. Adicionalmente al de�nir un nuevo
rol, es necesario establecer claramente cuales son las responsabilidades que este
va a tener.
Es importante aclarar que ejercer un rol no implica realizar todas las activida-
des del área a la que se re�ere el rol, en este caso como cada rol es el líder en
un área la persona que ejerce un rol es responsable de liderar esas actividades
más no hacerlas solo, a menos que así se especi�que en la fase de Estrategia.
También se pueden manejar diferentes tipos de roles, por ejemplo se pueden
manejar roles operativos y roles de coordinación, ya que en un proyecto de De-
sarrollo de Software todos los desarrolladores por la de�nición de su profesión
deben hacer tareas de desarrollo de software, de esta forma esta propuesta en-
fatiza la importancia de que cada miembro del equipo haga tareas operativas
(de desarrollo) y de coordinación, algo que es muy recomendado cuando un
grupo realiza proyectos ágiles, ya que puede que un desarrollador no realice
tareas de coordinación, pero lo contrario, un desarrollador que no realice tareas
operativas, nunca debe suceder.
Se propone la realización de las siguientes tareas:
1. Con base en el documento de levantamiento de requerimientos narrativos
se realiza un estudio que permita identi�car los roles necesarios para
abordar el proyecto. Esta información se consigna sobre el documento de
lanzamiento.
2. De ser necesario, se crean nuevos per�les de roles requeridos y se docu-
menta las responsabilidades necesarias sobre el documento de de�nición
67
de roles.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describen la forma
de documentación de la fase de Lanzamiento del proyecto.
Ejemplo de la de�nición de varios tipos de roles.
Criterio de Salida.
1. Primera versión del documento de Lanzamiento del proyecto: De�nición
de Roles.
Participantes. Todos los roles.
Actividad 2. Conformación del Equipo
Justi�cación. Es importante que todos en el equipo se conozcan y puedan
saber las responsabilidades de cada miembro del equipo, así como su ubicación
y las maneras de comunicarsen entre sí. De esta forma se evitan retrasos o
con�ictos en la realización de las tareas.
Criterio de Entrada.
Información de personal disponible.
Documento de levantamiento de requerimientos narrativos.
Primera versión del documento de Lanzamiento del proyecto.
Descripción. Esta actividad consiste en escoger los miembros del equipo y
asignarles roles y responsabilidades. Las características de los proyectos ágiles
dejan un amplio margen de posibilidades para que un desarrollador pueda
pertenecer al equipo. No es necesario que los desarrolladores sean brillantes
o tengan cualidades difíciles de encontrar. Lo realmente importante de un
desarrollador que pertenezca al equipo que desarrolla proyectos ágiles, es que
68
tenga disponibilidad para buscar las oportunidades de mejora y adaptar el
proceso de desarrollo a la conveniencia del proyecto. Lógicamente, todo esto es
posible con constancia en el trabajo y responsabilidad al momento de cumplir
con las actividades asignadas.
Si el proyecto ágil se desarrolla en medio de una organización con su�cientes
recursos disponibles, es posible que la actividad tenga algo más de complejidad.
Se propone la realización de las siguientes tareas:
1. El personal disponible es clasi�cado de acuerdo a sus áreas de experiencia
e interés.
2. Se asignan los roles buscando la manera de fortalecer los puntos débiles
y al mismo tiempo, expandir el conocimiento y experiencia del equipo.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describen la forma
de documentación de la fase de Lanzamiento del proyecto.
Criterio de Salida.
1. Segunda versión del documento de Lanzamiento del proyecto: Se añadió
la Información del Equipo.
Participantes. Todos los roles.
Actividad 3. Establecimiento de Objetivos
Justi�cación. Cada objetivo debe estar asociado con métricas que per-
mitan al momento de realizar una evaluación, conocer si el objetivo ha sido
cumplido. Es importante de�nir métricas cuantitativas que permitan ponderar
los logros obtenidos en el tema de objetivos trazados.
Con los objetivos y las métricas es posible conocer la evolución del equipo,
el producto y el proyecto. En cuanto al equipo es posible conocer el avance
69
en la adaptabilidad y la sinergia del trabajo en equipo, para el producto se
puede evaluar su completitud y su calidad y, para el proceso se pueden evaluar
estándares utilizados y cumplimiento de compromisos. Esto se re�eja en los
alcances logrados en cada proyecto desarrollado.
Criterio de Entrada.
Documento de levantamiento de requerimientos narrativos.
Segunda versión del documento de Lanzamiento del proyecto.
Descripción. Dentro de los proyectos ágiles se debe establecer dos grupos
de objetivos en la fase de lanzamiento. Los objetivos del equipo y los objetivos
del proyecto. Mientras que según TSP se añaden los objetivos de los roles y
los objetivos de los miembros del grupo.
Los objetivos del equipo hacen referencia a lo esperado en el tema de la evolu-
ción del grupo de desarrollo en las metodologías de trabajo y el apoyo general
de cada integrante a todo el grupo. Los objetivos del proyecto son más espe-
cí�cos y dependen del proyecto sobre los que se establezcan. Los objetivos de
los roles describen las actividades que va a liderar cada rol. Finalmente, los
objetivos de los miembros del grupo se re�eren a los objetivos que busca cada
miembro del equipo como individuo al realizar el proyecto.
Se propone la realización de las siguientes tareas:
1. Con base en las características del equipo y del proyecto, cada desarro-
llador escoge los objetivos que considere más importantes de alcanzar.
Estos objetivos deben ir acompañados de la de�nición de métricas que
sustenten el avance alcanzado.
2. Se realiza una lluvia de ideas para escoger nuevos objetivos y sus respec-
tivas métricas para su seguimiento.
70
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Lanzamiento del proyecto.
Criterio de Salida.
1. Tercera versión del documento de lanzamiento del proyecto: Se añadieron
los Objetivos del Proyecto, del Grupo, de los Miembros del Equipo y de
los Roles.
Participantes. Todos los roles.
Actividad 4. Establecimiento de Reglas del Equipo
Justi�cación. Todo equipo necesita manejar un conjunto de reglas para su
correcto funcionamiento. Estas reglas incluyen desde horarios para reuniones
hasta penalidades por incumplimiento en las actividades asignadas. En general,
es el equipo quien determina las reglas necesarias para trabajar.
Criterio de Entrada.
Tercera versión del documento de Lanzamiento del proyecto.
Descripción. Se propone la realización de las siguientes tareas:
1. Con base en las características del equipo y del proyecto, cada desarro-
llador escoge las reglas que le parezca importantes seguir para el equipo
funcione adecuadamente.
2. Se realiza una lluvia de ideas para escoger nuevas reglas.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Lanzamiento del proyecto.
71
Criterio de Salida.
1. Versión �nal del documento de Lanzamiento del proyecto: Se añadieron
las Reglas de Trabajo, el Horario de Trabajo de cada integrante y, el
Horario y Lugar de las Reuniones de Seguimiento.
Participantes. Todos los roles.
7.2.2. ESTRATEGIA
7.2.2.1. Motivación
Cuando se forma un equipo es necesario de�nir el esquema de trabajo al igual
que las tácticas a utilizar para lograr los objetivos establecidos, es por eso que es
necesario de�nir esas tácticas, ya que son las que describen como se van a atacar los
eventos generados en el transcurso del camino para alcanzar los objetivos iniciales
de�nidos. Es aquí donde la fase de Estrategia es vital ya que el conjunto de tácticas
que se de�nen forman la estrategia para alcanzar los objetivos planteados en la fase
de Lanzamiento.
7.2.2.2. Propósito
El propósito de esta fase es establecer lineamientos especí�cos de la forma en
como el equipo, de�nido en la fase de Lanzamiento, va a trabajar y que tácticas
va a utilizar para alcanzar los objetivos propuestos, también de�nidos en la fase de
Lanzamiento. Estos lineamientos y tácticas son vitales para el grupo ya que es en
esta fase donde el grupo gana una primera apreciación del trabajo que debe hacerse.
Las actividades realizadas dentro de esta fase en el entorno de proyectos ágiles
con una arquitectura orientada a componentes, son: Planeación preliminar, Admi-
nistración de Riesgos, Modi�cación de procesos. Adicionalmente TSP especi�ca:
Estrategia General, Estrategia Especí�ca, Estrategia de Aseguramiento de Calidad,
Alcance del Ciclo, Administración de Con�guraciones. Como la modi�cación de los
procesos es una táctica a tomar para poder ejecutar el proyecto, esta se incluye en
la parte de Estrategia de TSP.
72
7.2.2.3. Proceso
A continuación se presentan las actividades que hacen parte del proceso de Es-
trategia desde la perspectiva de esta propuesta.
Actividad 1. Estrategia General
Justi�cación. Para la ejecución correcta de un proyecto es necesario tener
una comprensión preliminar de cual es la �nalidad del proyecto, que es lo
que se desea hacer y como se piensa realizar, es por eso que en esta primera
actividad se especi�ca la forma de trabajo no solo del primer ciclo de desarrollo,
sino de todos los ciclos de desarrollo del proyecto, esta forma de trabajo se va
adaptando o modi�cando de acuerdo a las necesidades que se presenten durante
cada ciclo de desarrollo.
Esta tarea ayuda a los participantes del proyecto a pulir sus habilidades para
abordar los proyectos de acuerdo a sus características particulares y generales.
Criterio de Entrada.
Documento de levantamiento de requerimientos narrativos.
Documento de Lanzamiento del proyecto.
Descripción. La Estrategia General consiste en la especi�cación de tres
elementos que de�nen la forma en la que se va a trabajar durante todo el
proyecto. Estos elementos son:
Adaptación del Proceso.
Identi�cación de Requerimientos.
Identi�cación Preliminar de Objetos.
En la adaptación del proceso, se establece la forma que en que se va a opti-
mizar el proceso de desarrollo para la ejecución del proyecto, esta adaptación
puede consistir de la fusión de fases, la supresión de algunas de ellas o cam-
bios en su orden de ejecución, en todo caso la decisión que se tome debe estar
73
justi�cada. Si no se modi�ca el proceso para la ejecución del proyecto, igual
se debe especi�car las fases que se van a seguir, y la importancia de seguir el
proceso de esta manera. También se debe especi�car cuantos ciclos se van a
ejecutar para que el proyecto llegue a buen término o la estimación del tiempo
invertido en cada ciclo.
La identi�cación de requerimientos, consiste en la realización de una lista de
requerimientos de todo el proyecto que debe contener un identi�cador y un
nombre por cada requerimiento. Esto es vital para las siguientes tareas en
donde se hace una planeación preliminar y la de�nición del alcance del ciclo.
Finalmente, se hace una identi�cación de los objetos que pertenecen al dominio
del problema, con el único objetivo de tener una idea preliminar de que sustan-
tivos representan componentes y tienen fuertes relaciones entre ellos mismos
en el sistema, y de esta forma facilitar la planeación preliminar que se debe
hacer posteriormente.
Se propone la realización de las siguientes tareas:
1. Con base en las entradas en el documento de levantamiento de requeri-
mientos narrativos y el documento de lanzamiento, se establece como se
va adaptar el proceso de desarrollo al proyecto.
2. Teniendo en cuenta el documento de levantamiento de requerimientos
narrativo se nombran los requerimientos teniendo en cuenta el lenguaje
del cliente y se les asigna un identi�cador de acuerdo a los estándares
establecidos o a los que se van a establecer en la administración de con-
�guraciones.
3. Finalmente, se listan los posibles componentes o entidades que se van ma-
nejar de acuerdo al lenguaje utilizado en el documento de levantamiento
de requerimientos narrativos.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Estrategia del proyecto.
74
Criterio de Salida.
1. Primera versión del documento de Estrategia del proyecto: Estrategia
General.
Participantes. Todos los roles.
Actividad 2. Estrategia Especí�ca
Justi�cación. Una vez especi�cada la forma en que se va a abordar el
proyecto, es necesario especi�car un nivel más detallado el trabajo a desarrollar
para que los avances sean fácilmente percibibles, para lo cual el desarrollo por
ciclos es adecuado. Pero para que este desarrollo sea adecuado es necesario
especi�car que es lo que se va a realizar en cada ciclo que soporte las decisiones
que se tomaron con respecto a la ejecución total del proyecto. La Estrategia
Especí�ca de cada ciclo especi�ca en detalle la Estrategia general del proyecto,
ayudando a identi�car el alcance que va a tener el ciclo de desarrollo.
Esta actividad ayuda a los participantes a administrar mejor el proyecto y de
acuerdo a esto establecer la mejor forma de trabajo para que el proceso no
obstaculice el desarrollo del proyecto debido a su tamaño.
Criterio de Entrada.
Documento de levantamiento de requerimientos narrativos.
Documento de Lanzamiento del proyecto.
Primera versión del documento de Estrategia del proyecto.
Descripción. La estrategia especí�ca consiste en la especi�cación de tres
elementos que de�nen la forma en la que se va a trabajar durante el ciclo de
desarrollo del proyecto. Estos elementos son:
Objetivo del Ciclo.
Esquema y Alcance de las Fases del Ciclo.
75
Esquema de Trabajo.
En el objetivo del ciclo se establecen las metas que se persiguen en el ciclo
actual, las cuales van a ser los criterios de selección para escoger que requeri-
mientos se van implementar en el ciclo.
En el esquema y alcance por fases del ciclo se establecen que tareas por fase se
van a desarrollar, que tareas transversales a las fases se van a ejecutar, como
se va a hacer el seguimiento y como se van a desarrollar dichas tareas.
Finalmente en el esquema de trabajo se asignan responsabilidades a cada
miembro del grupo por actividades, por componentes de la arquitectura, o
por requerimientos de acuerdo a los conocimientos de cada integrante.
Cada uno de los elementos anteriores deben tener explícitas las razones que
llevaron a tomar dichas decisiones.
Se propone la realización de las siguientes tareas:
1. Establecer el objetivo del ciclo.
2. Establecer el esquema y alcance de las fases del ciclo.
3. Establecer el esquema de trabajo del ciclo del proyecto.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Estrategia del proyecto.
Criterio de Salida.
1. Segunda versión del documento de estrategia del proyecto: Se añadió la
Estrategia Especí�ca.
Participantes. Todos los roles.
76
Actividad 3. Estrategia de Aseguramiento de Calidad
Justi�cación. Al desarrollar un proyecto, no basta con tener un proceso de
desarrollo de�nido con unas serie de pasos establecidos a seguir, es importante
que con cada desarrollo del proyecto este evolucione, y eso sólo se puede hacer
evaluando dicho proceso, es por esta razón que es importante asegurarnos que
tanto el proceso como el proyecto cumpla las expectativas que se establecieron
en un inicio.
Criterio de Entrada.
Documento de Lanzamiento del proyecto.
Segunda versión del documento de Estrategia del proyecto.
Descripción. El propósito del aseguramiento de la calidad es proveer al
equipo de trabajo una adecuada visibilidad sobre el proceso que se está ade-
lantando y de los productos que están siendo construidos, para que se pueda
veri�car que el proceso se esta realizando de acuerdo a lo establecido y que los
resultados sean válidos y aplicables al proyecto.
Para cumplir este proceso, se deben de�nir las tareas que se ejecutarán para
controlar las actividades. Las cuales son:
1. De�nición del plan de administración de con�guraciones.
2. Evaluación sobre productos entregables y no entregables.
3. Plan de seguimiento, revisión y documentación del mismo.
4. De�nición del esquema de retroalimentación.
5. Formulación del Plan de Aceptación por parte del cliente.
6. De�nición de las técnicas de inspección y documentación de sus resulta-
dos.
7. De�nición de diseño y ejecución de pruebas y la documentación de sus
resultados.
77
Para la realización de las actividades anteriores, son necesarias todas las en-
tradas, la secuencia en que se realicen no importa.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Estrategia del proyecto.
Criterio de Salida.
1. Tercera versión del documento de Estrategia del proyecto: Se añadió la
Estrategia de Aseguramiento de Calidad.
Participantes. Todos los roles.
Actividad 4. Planeación Preliminar
Justi�cación. En todo proyecto es necesario hacer una planeación para po-
der estimar los costos que se van a generar, pero esta planeación generalmente
necesita una buena cantidad de información para generarse de una manera
adecuada. Debido a que realizar una planeación detallada en la fase de Estra-
tegia es demasiado lejano, se debe hacer una planeación preliminar para tomar
decisiones concernientes al alcance del ciclo que se debe de�nir en la siguiente
tarea.
Criterio de Entrada.
Documento de levantamiento de requerimientos narrativos.
Tercera versión del documento de Estrategia del proyecto.
Descripción. La planeación preliminar consiste en la estimación del tra-
bajo a desarrollar por casos de uso de todo el proyecto y por fases del ciclo,
algunas veces se pueden necesitar estimaciones adicionales (Por módulos o
componentes), entonces las tareas que generalmente se realizan son:
78
Estimación de casos de uso.
Estimación de fases.
La estimación de casos de uso se hace generalmente por tiempo y por líneas
de código, aunque se pueden agregar otros criterios, como costos.
La estimación de fases se hace generalmente por tiempo, y es muy útil agregarle
el porcentaje estimado que cada fase representa en la ejecución de todo el
proyecto.
Se propone la realización de las siguientes tareas:
1. Estimar el tiempo y el tamaño de cada caso de uso del proyecto.
2. Estimar el tiempo y el porcentaje de la ejecución del proyecto que toma
cada fase para el ciclo actual.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Estrategia del proyecto.
Criterio de Salida.
1. Cuarta versión del documento de Estrategia del proyecto: Se añadió la
Planeación Preliminar.
Participantes. Todos los roles.
Actividad 5. Alcance del Ciclo
Justi�cación. En el desarrollo de un proyecto es necesario realizar las cosas
bien, y para ello es necesario tomarse el tiempo adecuado para cumplir con
las expectativas del cliente, debido a esto es fundamental partir el proyecto
en ciclos, ya que para proyectos grandes se facilita su control y modi�cación
cuando eventos inesperados ocurran, además que le permite al cliente estar
79
informado sobre los avances del proyecto. Debido a esto es necesario de�nir
que parte del proyecto se va a realizar en cada ciclo.
Criterio de Entrada.
Cuarta parte del documento de Estrategia del proyecto.
Descripción. En el alcance del ciclo se de�nen los requerimientos a desa-
rrollar para el ciclo actual.
Se propone la realización de la siguiente tarea:
1. Escoger los requerimientos a desarrollar en el ciclo teniendo en cuenta la
lista de requerimientos de�nida en la Estrategia General y la estimación
de los casos de uso en la Planeación Preliminar.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Estrategia del proyecto.
Criterio de Salida.
1. Quinta versión del documento de estrategia del proyecto: Se añadió el
Alcance del Ciclo.
Participantes. Todos los roles.
Actividad 6. Administración de Riesgos
Justi�cación. En el desarrollo de un proyecto es necesario identi�car los
eventos inesperados que puedan surgir y seleccionar cuales afectarían a gran
escala la ejecución del proyecto, es por esta razón que es necesario establecer
los riesgos que puedan surgir y la manera como se van a afrontar.
80
Criterio de Entrada.
Documento de levantamiento de requerimientos narrativos.
Quinta versión del documento de Estrategia del proyecto.
Descripción. Esta tarea consiste en la realización de tres actividades del
proceso de Administración de Riesgos. Estas actividades son:
Identi�cación, de�nición y valoración de riesgos.
Priorización de riesgos a mitigar.
De�nición de planes de mitigación y contingencia.
En la identi�cación, de�nición y valoración de riesgos se establece su identi�-
cación, su nombre, su descripción, su probabilidad de ocurrencia y su impacto,
de acuerdo a los tipos de riesgo establecidos (Por ejemplo: Proyecto, Producto,
Proceso, Costo). De acuerdo a lo anterior los riesgos identi�cados se priorizan
de acuerdo a su importancia la cual se re�eja en una matriz de ocurrencia
contra impacto. Finalmente, se escogen los riesgos más importantes y se crean
los planes de mitigación y contingencia para cada uno de ellos.
Se propone la realización de las siguientes tareas:
1. Con base en el documento de levantamiento de requerimientos narrativo
cada integrante de�ne un número determinado de riesgos.
2. Uno de los integrantes (Por ejemplo el líder del proyecto) se encarga de
priorizar los riesgos y de asignarlos a los otros integrantes del grupo.
3. Cada integrante se encarga de de�nir los planes de mitigación y contin-
gencia de los riesgos que le fueron asignados.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Estrategia del proyecto.
81
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la Administración de Riesgos del proyecto.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la Identi�cación, De�nición y Valoración de Riesgos
del proyecto.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación del Control y Seguimiento de Riesgos del proyecto.
Criterio de Salida.
1. Sexta versión del documento de Estrategia del proyecto: Se añadió la
Administración de Riesgos.
Participantes. Todos los roles.
Actividad 7. Administración de Con�guraciones
Justi�cación. Al desarrollar un proyecto, la información necesitada y ge-
nerada debe ubicarse en un solo sitio para que todo el grupo pueda acceder a
ella en cualquier momento, además de tener un centro de información, se ne-
cesita que la consulta sea fácil para que las tareas que se necesiten desarrollar
se demoren lo menos posible, es por esta razón que se necesita el manejo de
estándares en todos los productos generados durante la ejecución del proyecto.
Criterio de Entrada.
Documento de levantamiento de requerimientos narrativos.
Sexta versión del documento de Estrategia del proyecto.
Descripción. La Administración de Con�guraciones se hace mediante el
establecimiento de estándares para cada producto que se genera durante la
ejecución del proyecto, estos estándares pueden ser de ubicación o de nombra-
miento, y deben ser seguidos durante toda le ejecución del proyecto ya que son
estos estándares los que in�uyen directamente en la calidad del producto �nal.
82
Para la de�nición de estándares es necesario tener en cuenta todas las entradas
ya que ellas indican los documentos que se generan por fases y las herramientas
que se van a utilizar durante todo el proyecto y para las cuales se necesitan
de�nir dichos estándares.
La propuesta que se presenta a continuación busca de�nir las características
mínimas de la administración de la con�guración, que asegure las caracterís-
ticas mínimas requeridas, en las que se asegure la asociación de los productos
de trabajo intermedios del proyecto (Documentos, avances de implementación,
etc).
Se proponen las siguientes tareas:
1. De�nición de estándares de nombramiento.
2. De�nición del versionamiento de artefactos.
Cuando el versionamiento o los estándares de nombramiento que se tiene para
el grupo o empresa cambian de proyecto a proyecto se genera un documento de
Administración de Con�guraciones Especí�ca el cual enumera y describe los
cambios que se le hicieron al documento de Administración de Con�guraciones
General.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Estrategia del proyecto.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la Administración de Con�guraciones General del
proyecto.
Ejemplo que describe la forma de documentación de la Administración
de Con�guraciones Especí�ca del proyecto. Su plantilla e instructivo son
los mismos que se utilizan para la Administración de Con�guraciones
General.
83
Criterio de Salida.
1. Versión �nal del documento de Estrategia del proyecto: Se añadió la Ad-
ministración de Con�guraciones.
Participantes. Todos los roles.
7.2.3. PLANEACIÓN
7.2.3.1. Motivación
La planeación de un proyecto de desarrollo de software se lleva a cabo a lo largo
de todo el proyecto, adaptando los planes en cada fase tanto como sea necesario.
Todo desarrollo inicia con una declaración de requerimientos que realiza el cliente.
Normalmente las horas invertidas en estas reuniones preliminares no son cargadas a
un proyecto en particular dado que este todavía no existe. Una vez terminadas las
reuniones preliminares de familiarización con el problema, y una vez un proyecto ha
sido establecido, el proceso de planeación inicia. Desde ese momento se debe llevar a
cabo una planeación activa. El concepto de planeación activa hace referencia a una
planeación que se realiza a lo largo de todo el desarrollo, revisando continuamente
el plan y adaptándolo a las necesidades del proyecto.
Gran parte de los éxitos o fracasos de los proyectos de desarrollo son atribuidos
al proceso de planeación. Este debe estar claramente de�nido, pero debe construirse
de tal manera que tenga en cuenta los cambios que se puedan presentar en cualquier
momento a lo largo del proyecto.
7.2.3.2. Propósito
Dadas las limitaciones de tamaño del equipo en el contexto de proyectos ági-
les, resulta crítico invertir demasiados recursos para administrar el plan. Por eso
la estrategia establecida para el proceso se basa en el apoyo de todo el grupo de
desarrolladores para llevarlo a cabo. El proceso debe ser apoyado por todos los de-
sarrolladores, de�niendo claramente un responsable principal, pero sin dejar la res-
ponsabilidad completa sobre él a menos que las características propias del proyecto
84
lo exijan.
Aunque la adaptación de los planes del proyecto en cada iteración del desarrollo
es fundamental para lograr hacer predecibles los resultados de cada actividad, se
debe tener en cuenta las fechas globales de terminación de cada ciclo de desarrollo.
Cuándo se establecen fechas con el cliente, estas deben ser respetadas. Es por eso
que se debe realizar un monitoreo constante del avance del proyecto durante todo el
ciclo, e impactar los planes cuando se haga necesario. Con un seguimiento continuo
de planeación, se puede conocer con tiempo de anticipación si es requerido mover
fechas de entregas a los clientes. De esta manera se puede negociar con el cliente
para no generar falsas expectativas de entregas que incurran en costos adicionales,
como costos generados por cláusulas de incumplimiento.
A lo largo de un ciclo de desarrollo, los planes de trabajo deben incluir cada
actividad necesaria para desarrollar el producto de software requerido, y su completa
documentación técnica y de soporte.
Entre las características de los proyectos ágiles está el poco conocimiento inicial
de métricas de velocidad de desarrollo. Esta característica afecta de manera directa
el proceso de planeación ya que se hace complicado realizar planes con estimaciones
acertadas en las primeras iteraciones del proyecto. De ahí la importancia de adaptar
constantemente los planes a medida que se tienen más métricas de desarrollo. De
igual forma, el mantenimiento de históricos de los planes modi�cados es fundamen-
tal para aprender acerca de los cambios y re�ejar este aprendizaje en métricas de
desarrollo.
7.2.3.3. Proceso
A continuación se presentan las actividades que hacen parte del proceso de Pla-
neación desde la perspectiva de esta propuesta.
Actividad 1. Planeación Global
Justi�cación. Para lograr hacer adaptable el proceso y los planes de tra-
bajo, es necesario dividir el desarrollo en varios ciclos. Esto es lo que se conoce
85
como desarrollo iterativo. Además de la adaptabilidad lograda, el desarrollo
iterativo hace posible construir productos de software terminados en cortos
espacios de tiempo, de manera que se pueda presentar avances funcionales al
cliente. Estos avances permiten al cliente conocer el desarrollo y retroalimentar
al equipo. De igual forma, permite de�nir acciones preventivas y correctivas
para ajustarse a un plan que permita �nalizar un desarrollo de acuerdo a las
fechas programadas.
Realizar ciclos de desarrollo cortos favorece la comunicación de un equipo
disperso. Las actividades llevadas a cabo dentro de un ciclo corresponden al
desarrollo de un grupo pequeño de requerimientos, por lo que se hace más
manejable el intercambio de información dentro del equipo. Los ciclos de de-
sarrollo permiten planear gradualmente actividades que apoyen el proceso de
investigación y desarrollo necesario para mejorar el conocimiento del equipo
en el tema tecnológico y de lógica del negocio.
Criterio de Entrada.
Documento de Lanzamiento del proyecto.
Documento de Estrategia del proyecto.
Descripción. El proceso de planeación consiste en aumentar la granurali-
dad de las tareas por cada fase del proceso desarrollo, de tal forma que se pueda
estimar el costo de implementar un caso de uso en el ciclo de desarrollo actual,
de acuerdo al alcance y la forma de trabajo especi�cados en el documento de
estrategia y a la disponibilidad de los recursos especi�cada en el documento
de lanzamiento.
Para cada ciclo de desarrollo se estiman sus fechas de inicio y �nalización.
Estas fechas deben estar comprendidas entre 4 y 6 semanas, pero esto es muy
dependiente de las características inherentes de cada proyecto. Además de
de�nir la duración del ciclo, se debe de�nir la periodicidad que tendrán las
reuniones de seguimiento de planeación dentro de este. A esta periodicidad se
le llama periodo de desarrollo. Se recomienda que los periodos de desarrollo
86
sean semanales. Sin embargo, dada la dispersión de los equipos en proyectos
ágiles, el equipo escoge el tiempo que resulte más conveniente.
La estimación de los casos de uso a implementar se debe cruzar con las fases
que se ejecutarán durante el ciclo actual de desarrollo, entre más se pueda
dividir una tarea la estimación será más precisa y de esta forma las fechas
serán más exactas.
Para aumentar la precisión de la estimación y distribuir adecuadamente el
recurso del tiempo en el desarrollo de un proyecto se sugiere el uso de las
siguientes fórmulas:
Casos de uso de alto nivel con prioridad asociada + modelo conceptual
+ estimación de tiempo de desarrollo de cada caso de uso + tiempo
disponible en el ciclo + recursos de personal disponible = casos de uso a
implementar.
Casos de uso de alto nivel con prioridad asociada + modelo conceptual
+ estimación de tiempo de desarrollo de cada caso de uso + casos de uso
a implementar + recursos de personal disponible = tiempo disponible en
el ciclo.
Las fórmulas anteriores se pueden modi�car de acuerdo a las fases del proceso
de desarrollo que se deseen ejecutar. Fácilmente se puede observar que se
podrían añadir otros elementos como pruebas e implantación.
Se propone la realización de las siguientes tareas:
1. Se de�ne la planeación por fases y por casos de uso teniendo en cuenta el
número y duración de los ciclos de desarrollo estimados en el documento
de Estrategia en la sección de Estrategia General, así como la Planea-
ción Preliminar de ese mismo documento y la Disponibilidad de Recursos
(Equipo de Trabajo) de�nida en el documento de Lanzamiento.
2. Se asignan los tiempos estimados de duración y la fechas estimadas de
inicio y �n de cada tarea.
87
3. A medida que se van realizando las tareas se ingresa el tiempo real de du-
ración de la tarea el cual corresponde al tiempo utilizado en la realización
de cada tarea.
Es recomendable utilizar una herramienta para manejar la planeación, la cual
también permita el ingreso de reportes en los cuales se pueda especi�car como
se realizó la tarea y los problemas ocurridos y como se solucionaron. Esto
facilitará la realización del postmortem del ciclo de desarrollo si adicionalmente
se pueden generar reportes de los tiempos invertidos y de los comentarios
realizados por cada tarea.
Entregables o Documentos de Soporte.
Plantilla y su correspondiente Instructivo que describe la forma de docu-
mentación de la fase de Planeación del Ciclo de Desarrollo, documentos
utilizados por el grupo de Diseño Instruccional para planear las tareas
correspondientes a la fase de Análisis de Requerimientos. La secuencia
de planeación de las tareas debe ser: Planeación (Se especi�ca el tiempo
estimado para la planeación de las tareas de Análisis de Requerimientos),
Reuniones, Documento de Levantamiento de Requerimientos Narrativos,
Análisis de Requerimientos. La fase de Análisis está dividida por Itera-
ciones(Fachada, Detallar, Focalizar, Finalizar)1 en las cuales el orden de
las actividades se resume de la siguiente manera: Descripción del Sistema,
De�nición del Sistema, Glosario, Pruebas de Caja Negra, Inspecciones.
Plantilla y su correspondiente Instructivo que describe la forma de docu-
mentación de la fase de Planeación del Ciclo de Desarrollo, documentos
utilizados por el grupo de Desarrollo para planear las tareas correspon-
dientes a las fases de Diseño, Implementación, Pruebas e Implantación.
La actividad de Planeación se re�ere al tiempo gastado en la planeación
de estas actividades. La secuencia de planeación de actividades de Diseño,
1Los nombres de las iteraciones y las actividades a realizar dentro de cada iteración para estafase son tomadas de las notas del curso �Taller de Análisis y Diseño de Software por Objetos�,dictado en el segundo semestre del 2005 por Gloria Cortés.
88
la cual al igual que la fase de Análisis de Requerimientos esta dividida
por iteraciones (Fachada, Detallar, Focalizar, Finalizar), es: Validación
de Entradas, Justi�cación, Diseño del Mundo, Diseño de Arquitectura,
Diseño de Interfaz, Inspecciones, Diseño de Persistencia. La secuencia a
seguir para la fase de Implementación corresponde: Automatización de
Pruebas, Implementación de la Aplicación (Lógica del Negocio, Interfaz
y Persistencia) e Inspección de Código. Para la fase de Pruebas primero
se hace el diseño de las pruebas faltantes (No funcionales), para luego
ejecutar todas las pruebas y presentar el producto al cliente. Luego sigue
la fase de Postmortem: Análisis Global, Análisis por Persona, Evalua-
ción de Pares, Evaluación de Objetivos y el PIP. Finalmente, para la fase
de Implantación, se hace la Implantación en producción, y los manuales
técnicos de uso de la aplicación.
Criterio de Salida.
1. Documento de Planeación Global del ciclo por Fases y por Casos de Uso.
Participantes. Participantes Líder de Desarrollo, Interlocutor.
7.2.4. ANÁLISIS DE REQUERIMIENTOS
7.2.4.1. Motivación
Después de haber comenzado la ejecución de un proyecto de construcción de
software, el proceso de análisis es la línea base de la solución que se va a desarrollar
para llevar a buen terminó el proyecto. Por está razón este proceso es el que describe
la esencia de la solución debido a que en este punto es independiente de la tecnología
que se va a utilizar.
7.2.4.2. Propósito
El proceso de análisis de caracteriza por ser un primer acercamiento a la solu-
ción �nal, pero por ser el primer acercamiento no es menos importante ya que a
89
pesar de que se modi�que va a in�uenciar las consecuentes modi�caciones y nuevas
soluciones. Como primer acercamiento a la solución �nal, esta es independiente de
la tecnología y estructuras de datos a manejar por lo cual se plantean las siguientes
tareas: Descripción del Sistema, De�nición del Sistema, Glosario, Pruebas de Caja
Negra e Inspección de Requerimientos.
Al realizar todas las actividades concernientes a este proceso secuencialmente
puede generar imprecisiones o errores como en cualquier proceso secuencial, y para
que estos errores no se pasen por alto, se recomienda hacer este proceso por itera-
ciones: Fachada, Detallar, Focalizar y Finalizar. La �nalidad de hacer un proceso
de análisis por iteraciones, es la de disminuir errores, presentar avances al cliente
inmediatamente superior (En cualquier empresa hay tanto clientes internos como
otros departamentos o grupos interdisciplinarios, y externos como usuarios �nales)
y garantizar al �nalizar cada iteración que la esencialidad de la solución se está de-
sarrollando de tal forma que permita entender tanto el problema como su solución.
7.2.4.3. Proceso
A continuación se presentan las actividades que hacen parte del proceso de Aná-
lisis de Requerimientos desde la perspectiva de esta propuesta.
Actividad 1. Descripción del Sistema
Justi�cación. Describir adecuada y completamente el objeto de un análisis
es una de las tareas más importantes en un proyecto, por lo tanto el describir
el proyecto es fundamental tener en cuenta cada una de las características
especi�cadas por el usuario �nal y que de una u otra manera deberán in�uir
en la solución que se va a de�nir.
Criterio de Entrada.
Documento de levantamiento de requerimientos narrativos.
Documento de Lanzamiento del proyecto.
Documento de Estrategia del proyecto.
90
Descripción. Para una correcta descripción del sistema se debe tener en
cuenta la información, los objetivos y los usuarios del sistema, así como las
reglas de negocio que maneja el sistema.
Para la elaboración de esta actividad se propone el desarrollo de las siguientes
tareas por iteraciones:
1. Iteración Fachada
Información del Sistema: Es un resumen que describe la aplicación
que se va a desarrollar. Se debe tener en cuenta que no debe especi-
�car nada técnico (Por ej. no debe indicar que se realizará en java o
que su persistencia se hará con archivos).
Objetivos del Sistema: Son los objetivos que el sistema deberá cum-
plir una vez esté realizado.
Actores del Sistema: Los usuarios �nales que interactuarán con el
sistema (Por ej. estudiante y profesor cuando es una apliación edu-
cativa o empresa e inversionista cuando es una aplicación referente a
un portafolio o bolsa de acciones).
Reglas de Negocio: Son las características especi�cas que debe cum-
plir la lógica del negocio como comportamientos y atributos (Por
ej. al ejecutar una de las opciones deberá indicar cuales están se-
leccionadas, o al entregar un trabajo deberá noti�cársele por correo
electrónico a todo el grupo).
2. Iteración Detallar
Actores del Sistema: Se de�nen sus características (Función, conoci-
miento, nivel cultural, objetivo, visibilidad y prioridad).
Reglas de Negocio: Se adicionan, complementan y corrigen.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Análisis de Requerimientos del proyecto
91
Criterio de Salida.
1. Primera versión del documento de Análisis de Requerimientos: Descrip-
ción del Sistema.
Participantes. Interlocutor.
Actividad 2. De�nición del Sistema
Justi�cación. En el análisis de requerimientos la de�nición del sistema
es el eje central de la solución al problema planteado por el proyecto que
se está desarrollando, debido a esto es indispensable de�nir detalladamente
esta solución para evitar ambigüedades y malas interpretaciones, tanto a nivel
interno (En el equipo), como externo (Con el cliente).
Criterio de Entrada.
Documento de levantamiento de requerimientos narrativos.
Primera versión del documento de Análisis de Requerimientos.
Descripción. La De�nición del Sistema comprende la realización del mode-
lo de casos de uso y la especi�cación de los requerimientos. Para la elaboración
de esta actividad se propone el desarrollo de las siguientes tareas por iteracio-
nes:
1. Iteración Fachada
Modelo de Casos de Uso
• Diagrama de Casos de Uso: Es un diagrama UMP de Casos de
Uso, el cual describe la interacción entre los actores y los casos
de uso (Requerimientos Funcionales Gruesos).
Requerimientos
92
• Funcionales Gruesos: Son los casos de Uso en los cuales se especi-
�ca su Contrato con Identi�cador, Nombre, Importancia, Necesi-
dad, Actores, Autor, Fecha, Categoría, Descripción, Precondición
y Postcondición.
• No funcionales: Su contrato se caracteriza por tener Identi�cador,
Tipo, Nivel y Descripción.
• Grá�cos: Se caracterizan por tener Identi�cador, Nivel y Descrip-
ción.
2. Iteración Detallar
Modelo de Casos de Uso
• Matriz de Casos de Uso Granulados: Mediante una Matriz se
relacionan los casos de uso granulados con sus actores.
Requerimientos
• Funcionales Granulados: Son los casos de Uso granulados a par-
tir de uno de los casos de uso grueso (p. ej el caso de uso R1.1-
Adicionar Usuario es un caso de uso granulado del caso de uso
grueso R1-Administrar Usuarios) en los cuales se especi�ca su
Contrato con Identi�cador, Nombre, Importancia, Necesidad, Ac-
tores, Autor, Fecha, Categoría, Descripción, Precondición y Post-
condición, los cuales son tomados de los casos de uso gruesos
pero más especí�cos. Adicionalmente a los contratos se les agre-
ga Curso Básico de Eventos, Caminos Alternativos, Caminos de
Excepción, Puntos de Extensión, Criterios de Aceptación.
• No funcionales: A su contrato se les adiciona criterios de acepta-
ción.
• Grá�cos: A su contrato se les adiciona criterios de aceptación.
• De Interacción: Se crea el prototipo (Este puede ser uno o varios
archivos).
93
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Análisis de Requerimientos del proyecto.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de los requerimientos funcionales gruesos.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de los requerimientos funcionales granulados.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de los requerimientos no funcionales.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de los requerimientos grá�cos.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de los requerimientos de interacción.
Criterio de Salida.
1. Segunda versión del documento de Análisis de Requerimientos, corres-
pondiente a la �nalización de la iteración Fachada: Se añadió parte de la
De�nición del Sistema.
2. Tercera versión del documento de Análisis de Requerimientos, correspon-
diente a la �nalización de la iteración Detallar: Se añadió parte de la
De�nición del Sistema.
3. Séptima y última versión del documento de Análisis de Requerimientos,
correspondiente a la �nalización de la iteración Finalizar: Se añadió la
De�nición del Sistema inspeccionada y terminada.
Participantes. Interlocutor, Diseñador Grá�co.
94
Actividad 3. Glosario
Justi�cación. Es claro que en el mundo existe una gran diversidad de idio-
mas, dialectos y regionalismos, sin contar las múltiples de�niciones que existen
de una misma palabra, esto ocasiona que los signi�cados múltiples de una pa-
labra sean mal interpretados si no existe un ambiente de comunicación como
lo hay durante una conversación o en un escrito hecho correctamente. Por esta
razón existen diccionarios y por esta razón se necesita uno en el análisis de
requerimientos, que describa el signi�cado de las palabras que se utilizan y que
justi�que su uso.
Criterio de Entrada.
Tercera versión del documento de Análisis de Requerimientos.
Descripción. El Glosario está compuesto de todas las palabras utilizadas
para nombrar los objetos y acciones que describen la de�nición y descripción
del sistema, las cuales provienen del lenguaje utilizado por el cliente y se
encuentran en el documento de levantamiento de requerimientos narrativos.
Se propone la realización de las siguientes tareas en la Iteración Detallar:
1. Identi�cación de conceptos utilizados.
2. Organizar los conceptos alfabéticamente.
3. De�nir los conceptos en lenguaje natural (No técnico).
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Análisis de Requerimientos del proyecto.
Criterio de Salida.
1. Cuarta versión del documento de Análisis de Requerimientos: Se añadió
el Glosario.
Participantes. Interlocutor.
95
Actividad 4. Planes de Prueba de Caja Negra
Justi�cación. Esta es la primera actividad dentro del grupo de actividades
de aseguramiento de calidad del producto que sigue el principio de Test First
Design (Pruebas antes de diseño). Las TFD además de apoyar el proceso de
veri�cación ayudan a llevar a cabo el proceso de validación. Estas pruebas
hacen que se generen inquietudes alrededor de los requerimientos de manera
que el entendimiento de desarrolladores y clientes sea absoluto en cuanto a lo
que se quiere construir.
Los planes de prueba, y en general todas las actividades de pruebas de veri�-
cación, permiten asegurar el entendimiento de los requerimientos funcionales
por parte de todos los integrantes de equipo, incluso los que se encuentran
dispersos.
Criterio de Entrada.
Cuarta versión del Documento de Análisis de Requerimientos.
Descripción. Con los requerimientos documentados, se construyen planes
de prueba que ayudan a la veri�cación del trabajo realizado sobre los requeri-
mientos. La entrada de esta actividad son los requerimientos funcionales que
se implementan en un ciclo de desarrollo. Parte de la inspección sobre estos
requerimientos es realizada construyendo lo que se conoce como un plan de
pruebas. De esta manera el plan de pruebas apoya la labor de corrección de
los requerimientos funcionales.
Se propone la realización de la siguiente tarea en la iteración Detallar:
1. Cada responsable de la construcción de los planes de prueba los construye
con base en el instructivo, sobre el formato de construcción de planes de
prueba.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Análisis de Requerimientos del proyecto.
96
Criterio de Salida.
1. Quinta Versión del Documento de Análisis de Requerimientos: Se añadió
los Planes de Prueba de Caja Negra.
Participantes. Interlocutor.
Actividad 5. Inspecciones
Justi�cación. Cuando realizamos un documento de cualquier tipo que es de
suma importancia es necesario revisarlo para que este coherente y presentable,
de la misma forma uno debe realizar esta tarea en esta fase. La importancia
de de�nir las inspecciones como una tarea, radica en que, por ejemplo, debido
a que el formato del contrato es extenso y se basa en la metodología que Craig
Larman, de�nida en su libro �Applying UML and Patterns: An Introduction
to Object-Oriented Analysis and Design� de 1998 [Lar98], es necesario hacer
la inspección contra listas de chequeo debido a que el estándar con el que se
realiza los requerimientos debe ser manejado por cada uno de los integrantes
del equipo y debido al tamaño de los contratos es fácil cometer errores que le
quitan claridad a la especi�cación y ocasionarán errores en las siguientes fases
especialmente en la de Diseño, lo cual sería costoso sino se identi�carán en esta
fase, ya que además de corregir el documento de Análisis de Requerimientos
también se tendría que corregir el documento de Diseño.
Criterio de Entrada.
Lista de Chequeo de Casos de Uso.
Lista de Chequeo de Planes de Prueba.
Quinta Versión del Documento de Análisis de Requerimientos.
Descripción. La inspección de requerimientos consiste en una compara-
ción de cada uno de los campos de los contratos o de los planes de prueba
97
de los requerimientos, contra una lista de chequeo que indica como deben es-
tar los elementos especi�cados. Al encontrarse alguna inconsistencia esta se
documenta en un reporte con la descripción del defecto encontrado.
Esta tarea se realiza durante la Iteración de Focalizar, si se quiere inspeccio-
nar los requerimientos y los planes de prueba en una sola inspección, pero se
recomienda hacer inspecciones individuales apenas se termina la elaboración
de cada documento, si el tiempo empleado no es un recurso limitado.
Se propone la realización de las siguientes tareas:
1. Seleccionar la metodología para realizar la inspección (Grupal o Indivi-
dual).
2. Asignar la(s) persona(s) encargadas de realizar la inspección.
3. Estimar el tiempo destinado a la inspección.
4. Realizar la inspección reportando los defectos encontrados y el tiempo
invertido.
5. Asignar la corrección de los defectos encontrados.
6. Corregir los defectos asignados.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Análisis de Requerimientos del proyecto.
Lista de Chequeo de Casos de Uso para la Inspección de Requerimientos.
Lista de Chequeo de Planes de Prueba para la Inspección de Planes de
Prueba de Caja Negra.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación del Reporte de Defectos.
Criterio de Salida.
1. Sexta versión del Documento de Análisis de Requerimientos: Requeri-
mientos y Planes de Prueba corregido e inspeccionados.
98
2. Reporte de Defectos Encontrados.
Participantes. Interlocutor, Líder de Desarrollo.
7.2.5. DISEÑO
7.2.5.1. Motivación
En la construcción de software, el proceso de diseño es uno de los más importantes
ya que el diseño del sistema que es obtenido al �nal de proceso es la base para la
construcción de la herramienta que será obtenida al �nal el proyecto. No solo en los
proyectos de software es importante hacer un diseño, ya que para cualquier actividad
metodología o herramienta a realizar es fundamental tener un diseño previo ya que
este es el resultado del análisis del problema realizado al traer a la realidad dicho
análisis para su consecuente implementación.
7.2.5.2. Propósito
La fase de Diseño busca acercar a la realidad el análisis realizado en la fase ante-
rior (Análisis de Requerimientos) para identi�car las herramientas metodológicas, de
software y de hardware que son necesarias para implementar la solución propuesta
en la siguiente fase (Implementación).
Es en la fase de diseño, donde se de�nen las herramientas más fuertes del proceso
que soportan la implementación de la herramienta, más especí�camente es la razón
para implementar la solución de esa manera. Además, también sirve como soporte
para su posterior mantenimiento o actualización y para que la persona que diseño o
implementó la herramienta no sea la única persona que pueda modi�carla.
Para el diseño del sistema es indispensable la documentación posea unos buenos
estándares para facilitar la comprensión del documento realizado y para que su man-
tenimiento sea efectivo, por lo cual se recomienda tener una buena Administración
de Con�guraciones que se pueda consultar.
99
7.2.5.3. Proceso
A continuación se presentan las actividades que hacen parte del proceso de Diseño
desde la perspectiva de esta propuesta.
Actividad 1. Justi�cación de las Decisiones de Diseño
Justi�cación. Antes de diseñar una solución a un problema dado con un
conjunto de decisiones tomadas, es necesario registrar las causas de la elección
de dichas soluciones con su respectiva justi�cación y comunicarlas al grupo
entero para evitar más adelante preguntas innecesarias sobre la causa de tomar
dicha decisión sobre el diseño de la solución. Una buena justi�cación es la
selección de patrones de diseño de construcción de software que fácilmente
soporten la elección tomada, evaluando no solo la correcta selección del patrón
de diseño, sino también la viabilidad que la solución signi�ca para el proyecto.
Criterio de Entrada.
Documento de Análisis de Requerimientos.
Descripción. Esta actividad consiste en de�nir las decisiones que se to-
marán para el diseño de la solución, con su respectiva justi�cación, la cual
debe ser completa, clara y su�cientemente convincente para cada uno de los
miembros del equipo.
Para la realización de esta actividad se proponen las siguientes tareas:
Identi�cación de las principales decisiones de diseño, que se pueden obtener
fácilmente al revisar el documento de Análisis de Requerimientos. Identi�ca-
ción de las posibles decisiones de diseño adicionales que se podrían tomar y
selección de las mejores en términos de viabilidad y que a la vez sean acordes
con las decisiones de diseño identi�cadas del documento de análisis de requeri-
mientos. Registro de las decisiones de diseño y su correspondiente justi�cación.
100
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Diseño del proyecto.
Criterio de Salida.
1. Primera versión del documento de Diseño: Justi�cación de las Principales
Decisiones de Diseño.
Participantes. Líder de Desarrollo.
Actividad 2. Diseño del Mundo
Justi�cación. Al diseñar un sistema se pasa por la realización de prototipos
en diferentes momentos, por lo cual el realizar un prototipo en UMP de una
aplicación no es la excepción y es la base fundamental de la construcción
de software por objetos. Por esta razón para el poder realizar esta tarea es
necesario tener identi�cado del análisis las entidades y sus comportamientos
entre sí y con su entorno para que este prototipo se genere de una forma
adecuada.
Criterio de Entrada.
Documento de Análisis de Requerimientos del proyecto.
Primera versión del documento de Diseño del proyecto.
Descripción. El desarrollo de un modelo del mundo es fundamental, ya que
permite la identi�cación de los objetos y sus comportamientos en la solución
que se está desarrollando. Generalmente este modelo se comienza a desarrollar
en la fase de Análisis y se completa en la fase de Diseño, pero en proyectos
ágiles generalmente es omitido y se pasa directamente al diseño de arquitec-
tura en la fase de Diseño, lo cual no es recomendable ya que es la primera
aproximación a la organización y estructura del sistema y generalmente ayuda
101
a simpli�car el problema a diferencia de cuando se empieza con el diseño de
la arquitectura. Para apoyar este diseño de entidades generalmente se utilizan
diagramas de secuencia para describir como se comportan los casos de uso
dentro del diagrama de entidades, pero estos diagramas no son los únicos ya
que los diagramas de secuencia son utilizados cuando un requerimiento utiliza
muchas entidades al ejecutarse esto implica que el sistema es altamente com-
plejo en su lógica. Cuando las relaciones son simples pero la utilización de un
diagrama de secuencia no es nada útil es mucho mejor utilizar un diagrama
de colaboración, además es fácilmente comprendido por el usuario �nal si se
le es mostrado para explicarle el comportamiento del sistema. Finalmente el
diagrama que se seleccione para explicar la relación entre los requerimientos y
el diagrama de entidades es responsabilidad de las personas que participan en
esta fase de Diseño, y debe estar claramente justi�cado en la Justi�cación de
las Principales Decisiones de Diseño, actividad previamente desarrollada.
Se propone la realización de las siguientes tareas:
1. Iteración Fachada
Identi�cación de sustantivos y verbos que describen el comportamien-
to de la solución detallada en el documento de Análisis de Requeri-
mientos (El Glosario es la primera fuente que se debe consultar).
Diseño del diagrama del mundo teniendo en cuenta que los sustanti-
vos representan entidades o atributos de alguna entidad y los verbos
representan relaciones entre las entidades.
Diseño de los diagramas que describen la relación entre el diagrama de
entidades del mundo y los requerimientos. Generalmente se hace uno
por cada requerimiento. Pueden ser de secuencia o de colaboración.
2. Iteración Detallar
Identi�cación de las estructuras y los tipos a utilizar para convertir
el diagrama de entidades a un diagrama de clases del mundo.
Modi�cación del diseño del diagrama del mundo para adicionarle
estructuras de datos y tipos que se van a manejar.
102
Modi�cación de los diagramas que describen el comportamiento del
sistema (De secuencia o de colaboración) para adicionarle estructuras
de datos y tipos que se van a manejar de acuerdo al diagrama de
clases.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Diseño del proyecto, para las iteraciones
Fachada y Detallar.
Criterio de Salida.
1. Segunda versión del documento de Diseño: Se añadió el Diseño del Mundo.
Participantes. Líder de Desarrollo.
Actividad 3. Diseño de la Arquitectura
Justi�cación. Cuando se diseñan aplicaciones complejas, el diseño de una
solución está fuertemente ligado a los requerimientos no funcionales, por lo cual
es necesario de�nir componentes que pueden garantizar esos requerimientos no
funcionales y que afectarán dicha solución, es por esta razón que la arquitectura
de un sistema y en especial su diseño son tan importantes.
Criterio de Entrada.
Documento de Análisis de Requerimientos del proyecto.
Segunda versión del documento de Diseño del proyecto.
Descripción. Debido a la complejidad del sistema y al nivel de detalle
que se necesite, se puede hacer un diseño general de la arquitectura, en el
cual se especi�que lo necesario. Se especi�ca desde las estructuras que cada
componente contiene hasta las excepciones y como va a ser su manejo. Si es
103
necesario se realizan diagramas que describan el comportamiento de la lógica
del sistema (Diagramas de secuencia o de colaboración).
Se propone la realización de las siguientes tareas:
1. Iteración Detallar
Diseño del diagrama de componentes o Nodos que describe el tipo de
arquitectura que se va a manejar.
Diseño del diagrama general por componentes de la arquitectura (Si
se necesita más detalle se construye un diagrama especí�co para el
componente más representativo y que sirva de ejemplo para los de-
más).
Justi�cación de los Atributos de Calidad (Como los Requerimientos
no funcionales requeridos se ven re�ejados en los diagramas de la
arquitectura).
2. Iteración Focalizar
De�nición detallada de la arquitectura mediante la especi�cación de
los requerimientos y las clases que tienen que ver con el Diseño del
Mundo en el diagrama general o en el diagrama del componente re-
presentativo previamente realizado.
Realización de un diagrama del comportamiento de la arquitectu-
ra del sistema (Depende de que tipos de diagrama se utilizaron en
el Diseño del Mundo, ya sean de secuencia o de colaboración) que
sea de un requerimiento representativo (El más complicado, el más
importante o el más prioritario).
Creación de la línea base del código con las clases de�nidas en el Di-
seño de Arquitectura y su respectiva documentación (Documentación
para clases, métodos y atributos).
Entregables o Documentos de Soporte.
Ejemplo que describe la forma de documentación de la fase de Diseño del
proyecto.
104
Criterio de Salida.
1. Tercera versión del documento de Diseño: Se añadió el Diseño de Arqui-
tectura del Sistema.
Participantes. Líder de Desarrollo.
Actividad 4. Diseño de Interfaz
Justi�cación. Al diseñar una aplicación generalmente el esfuerzo en el di-
seño se centra en la lógica del negocio, pero la interacción con el usuario es
igual de importante y a veces podría ser más importante ya que esa interfaz
que se comunica con el usuario �nal representa la primera impresión de dicho
usuario e in�uencia mucho los demás criterios que el usuario �nal utiliza para
la cali�cación de la aplicación. Debido a esto y dependiendo de las caracte-
rísticas del negocio para el cual se hace la aplicación es necesario dedicarle el
tiempo su�ciente al Diseño de la Interfaz y no restarle importancia.
Criterio de Entrada.
Documento de Análisis de Requerimientos del proyecto.
Tercera versión del documento de Diseño del proyecto.
Descripción. Esta actividad consta de dos partes, la primera consiste en
diseñar el diagrama de clases de la interfaz y el segundo es el diseño de los pro-
totipos grá�cos. La primera actividad debe tener en cuenta principalmente los
requerimientos de interacción, los requerimientos funcionales y no funcionales
y el diseño realizado hasta el momento, mientras que la segunda actividad debe
tener en cuenta los requerimientos grá�cos y los de interacción. Prácticamente
la segunda tarea consiste en mejorar los requerimientos de interacción espe-
ci�cados en el documento de análisis de requerimientos. Una tarea adicional
y dependiendo de la complejidad de la interfaz es el diseño de diagramas de
estado, los cuales se utilizan cuando el sistema que se está desarrollando es
105
altamente interactivo y la funcionalidad está representada más en la parte de
la interfaz que en la lógica del negocio o cuando la interfaz o la relación de la
interfaz con la lógica del negocio tiene un alto grado de complejidad.
Se propone la realización de las siguientes actividades:
1. Iteración Focalizar
Diseño del diagrama de clases de la interfaz.
Diseño del prototipo grá�co de la interfaz (Rediseño de los requeri-
mientos de interacción teniendo en cuenta los requerimientos grá�-
cos).
2. Iteración Finalizar
Diseño del diagrama de estados que re�eje la interacción entre la
lógica del negocio y la interfaz.
Creación de la línea base del código con las clases de�nidas en el
diagrama de clases de la interfaz y su respectiva documentación (Do-
cumentación para clases, métodos y atributos).
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Diseño del proyecto.
Criterio de Salida.
1. Cuarta versión del documento de Diseño: Se añadió el Diseño de la In-
terfaz.
Participantes. Líder de Desarrollo, Diseñador Grá�co.
Actividad 5. Inspecciones
Justi�cación. Cuando se realiza un documento de cualquier tipo que es de
suma importancia, es necesario revisarlo para que esté coherente y presentable,
106
de la misma forma uno debe realizar esta tarea en esta fase. La importancia de
de�nir las inspecciones como una tarea, radica en que, por ejemplo, debido a
que el diseño de diagramas en UMP es complejo y dispendioso pero muy claro
e informativo es necesario hacer la inspección contra listas de chequeo debido
a que el estándar con el que se realiza los diagramas debe ser manejado por
cada uno de los integrantes del equipo y debido al detalle que debe tener los
diagramas de clases en UMP es fácil cometer errores que le quitan claridad
al diseño y ocasionará errores en las siguientes fases especialmente en la de
Implementación, lo cual sería costoso.
Criterio de Entrada.
Lista de Chequeo de Diagramas.
Cuarta Versión del Documento de Análisis de Requerimientos.
Descripción. La inspección de diagramas consiste en una comparación de
cada uno de los ids de una lista de chequeo contra los diagramas realizados,
para veri�car que cada uno de los elementos y su descripción correspondan
con la forma en que se diseñó la aplicación. Al encontrar alguna inconsistencia
esta se documenta en un reporte con la descripción del defecto encontrado.
Esta tarea se realiza durante la Iteración de Focalizar.
Se propone la realización de las siguientes tareas:
1. Seleccionar la metodología para realizar la inspección (Grupal o Indivi-
dual).
2. Asignar la(s) persona(s) encargadas de realizar la inspección.
3. Estimar el tiempo destinado a la inspección.
4. Realizar la inspección reportando los defectos encontrados y el tiempo
invertido.
5. Asignar la corrección de los defectos encontrados.
6. Corregir los defectos asignados.
107
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Diseño del proyecto.
Lista de Chequeo de Diagramas para la Inspección de Diseño.
Ejemplo , plantilla y su correspondiente instructivo que describe la forma
de documentación del Reporte de Defectos.
Criterio de Salida.
1. Quinta versión del documento de Diseño: Se inspeccionaron y corrigieron
los diagramas del Diseño del Mundo y de la Arquitectura del Sistema.
2. Reporte de Defectos Encontrados.
Participantes. Líder de Desarrollo.
Actividad 6. Diseño de la Persistencia
Justi�cación. El diseño de la persistencia es muy importante y en algunos
proyectos es la base de toda la solución por esto es necesario establecer su
necesidad de acuerdo a la lógica que maneja el negocio y a los requerimien-
tos, generalmente los requerimientos no funcionales son los que nos indican la
necesidad de una base de datos o un parser para el manejo de la persistencia.
Criterio de Entrada.
Quinta versión del documento de Diseño del proyecto.
Descripción. El diseño de la persistencia consiste en la especi�cación de
como la aplicación va a manejar la persistencia, esta debió verse re�ejada
un poco en el Diseño de la Arquitectura, a causa de los requerimientos no
funcionales, o en el Diseño del Mundo, di la persistencia era sencilla de manejar.
La persistencia se puede manejar de diversas formas, ya sea utilizando una base
de datos, archivos planos o parsers especí�cos (p. ej. XML, DTD, XHTML).
108
Se propone la realización de las siguientes tareas correspondientes a la iteración
�nalizar:
1. Diseño del Manejo de la persistencia. Dependiendo de como se va a ma-
nejar la persistencia se hace lo siguiente:
Base de Datos: Diagrama Entidad-Relación.
Parser: Diagrama de clases del parser y descripción del estándar de
almacenamiento de los archivos.
Archivos Planos: Diagrama de clases (Si no fue especi�cado en el
diagrama de clases del mundo o en el diagrama por componentes) o
descripción del estándar de almacenamiento de los archivos.
2. Creación de la línea base del código con las clases de�nidas en el diseño
de la persistencia y su respectiva documentación (Documentación para
clases, métodos y atributos).
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Diseño del proyecto.
Criterio de Salida.
1. Versión �nal del documento de Diseño: Se añadió el Diseño de la Persis-
tencia del Sistema.
Participantes. Líder de Desarrollo
7.2.6. IMPLEMENTACIÓN
7.2.6.1. Motivación
La construcción de una solución llega a su etapa crítica cuando ingresa a la fase
de Implementación, debido a que ya se tiene un análisis y un diseño que sustenta
la construcción de la solución, y es en esta fase donde se ven los resultados de las
109
fases de análisis y diseño, ya que si algo quedó mal en las fases antes mencionadas
se verán re�ejadas en el proceso de ejecución o en el artefacto resultante de esta
fase. Es indispensable que si se encuentran defectos en los documentos resultantes
de las fases anteriores, se corrijan inmediatamente ya que entre más tarde sean las
correcciones incrementa el tiempo gastado en la mantenibilidad de la solución.
7.2.6.2. Propósito
Al terminar esta fase es donde se pueden ver resultados prácticos de la solución
propuesta, por lo tanto en esta fase es en donde se crea la solución diseñada y se crean
las pruebas de caja negra (Pruebas para los casos de uso) y las pruebas de caja blanca
(Pruebas unitarias ya sea por clases o por componentes). Esta es una de las fases
cuyas actividades no tienen un orden de ejecución secuencial y se pueden realizar en
el orden deseado o hasta concurrentemente. Se recomienda en aplicaciones grandes
el codi�car por requerimientos (Las tareas se podrían hacer por requerimientos,
por componentes o por el criterio que más se adapte a las necesidades), pero todo
depende de la lógica que maneja el proyecto y la organización que se tiene.
7.2.6.3. Proceso
A continuación se presentan las actividades que hacen parte del proceso de Im-
plementación desde la perspectiva de esta propuesta.
Actividad 1. Automatización de Pruebas
Justi�cación. Justi�cación Cuando una solución es creada es necesario pro-
barla y entre más automáticas sean estas pruebas mejor ya que la prueba de
una aplicación es una de las actividades consume más tiempo junto con las
correcciones e inspecciones. Por esta razón es necesario automatizar las prue-
bas mediante la codi�cación en un lenguaje especí�co, generalmente se utiliza
el mismo que se maneja para la construcción de la aplicación, pero se podrían
utilizar otros lenguajes (p. ej. en webservices se podría probar con otro lenguaje
para demostrar su interoperabilidad entre diversos sistemas o lenguajes).
110
Criterio de Entrada.
Documento de Análisis de Requerimientos del proyecto.
Documento de Diseño del proyecto.
Descripción. En esta actividad se codi�can las pruebas de caja negra y las
pruebas unitarias de acuerdo a los estándares y herramientas a utilizar especi-
�cadas en el documento de Administración de Con�guraciones. Esta tarea se
considera opcional, debido a que podría resultar poco viable el automatizar las
pruebas, ya sea porque el tiempo gastado en su elaboración no es justi�cable
o porque es más rápido realizar las pruebas sin necesidad de automatizarlas.
Se propone la realización de las siguientes tareas:
1. Codi�cación de las pruebas de caja negra teniendo en cuenta los planes
de prueba construidos.
2. Codi�cación de las pruebas de caja blanca, se recomienda que sea por
componentes cuando se utiliza una arquitectura multinivel, de lo contrario
se recomienda que las pruebas sean por clase.
Entregables o Documentos de Soporte.
Ninguno
Criterio de Salida.
1. Pruebas de Caja Negra y Caja Blanca codi�cadas en el sitio donde se
encuentra el código de la aplicación.
Participantes. Líder de Desarrollo.
Actividad 2. Implementación de la Lógica del Negocio
Justi�cación. Esta actividad consiste en la implementación de la base de
la funcionalidad de la aplicación, donde se de�nen los comportamientos (Mé-
todos) de los objetos o entidades (Clases) con sus similares y con el usuario, es
111
en donde se de�nen todos los elementos necesarios que se necesitan para que
los requerimientos de�nidos por el cliente se ejecuten correctamente según su
de�nición en el documento de Análisis de Requerimientos y con la estructura
y patrones propuestos en el documento de Diseño.
Criterio de Entrada.
Documento de Análisis de Requerimientos del proyecto.
Documento de Diseño del proyecto.
Descripción. Esta actividad se caracteriza por la implementación de los
métodos necesarios para que los requerimientos funcionales se ejecuten, los
cuales fueron de�nidos en la línea base del código que se hizo en la fase de Di-
seño. Generalmente también se completan cosas como atributos o métodos no
de�nidos en la línea base del código y el ambiente de ejecución de la aplicación.
Se propone la realización de las siguientes tareas:
1. Revisión y corrección de la línea base del código.
2. Implementación del ambiente de ejecución de la aplicación (P. ej. scripts
para la automatización de la generación del código, con�guración de la
comunicación con el servidor).
3. Codi�cación de la lógica del negocio.
Entregables o Documentos de Soporte.
Ninguno.
Criterio de Salida.
1. Código de la lógica del negocio en el sitio donde se encuentra el código
de la aplicación.
2. Código del ambiente de ejecución en el sitio donde se encuentra el código
de la aplicación.
Participantes. Líder de Desarrollo.
112
Actividad 3. Implementación de la Interfaz
Justi�cación. Toda aplicación debe tener una interfaz amigable, sencilla,
llamativa e informativa, es por esta razón que la implementación de la interfaz
debe tener la misma importancia que la implementación de la lógica del negocio
o la de la persistencia, ya que como se mencionó en el documento de Diseño
es la parte de la aplicación le proporciona al cliente la primera impresión del
producto desarrollado.
Criterio de Entrada.
Documento de Análisis de Requerimientos del proyecto.
Documento de Diseño del proyecto.
Descripción. En esta actividad no solo se codi�ca la interfaz, sino que se
añaden todos los recursos grá�cos que fueron establecidos en los requerimientos
grá�cos y en los requerimientos de interacción.
Se propone la realización de las siguientes tareas:
1. Se añaden los recursos necesarios.
2. Codi�cación de Interfaz.
Entregables o Documentos de Soporte.
Ninguno.
Criterio de Salida.
1. Recursos grá�cos en el sitio donde se encuentra el código de la aplicación.
2. Codi�cación de la interfaz en el sitio donde se encuentra el código de la
aplicación.
Participantes. Líder de Desarrollo.
113
Actividad 4. Implementación de la Persistencia
Justi�cación. La persistencia es generalmente una de las características
manejadas por los requerimientos no funcionales más importantes en una apli-
cación, y de acuerdo a su grado de importancia, también es el grado de di�cul-
tad y esfuerzo que se requiere para su implementación. Su importancia radica
en el grado de disponibilidad que debe tener la información y la cantidad de
recursos que representan dicha información, características de la persistencia
entre muchas otras que la aplicación debe manejar para su correcta ejecución.
Criterio de Entrada.
Documento de Análisis de Requerimientos del proyecto.
Documento de Diseño del proyecto.
Descripción. Esta actividad depende del tipo de persistencia que se debe
manejar, ya que lo que se debe hacer para una base de datos es diferente para
el manejo de archivos planos o un parser especí�co. El tipo de persistencia
también in�uye en el orden de ejecución de las tareas de esta fase, por ejemplo,
para el manejo de la persistencia con una base de datos es necesario tener la
base de datos con todas las tablas listas para poder con�gurar correctamente
el ambiente de ejecución, tarea que pertenece a la actividad de Codi�cación
de la Lógica del Negocio.
Se propone la realización de las siguientes tareas:
1. Base de Datos
Tomando como base el diagrama de entidad-relación generar los scripts
de creación y eliminación de tablas y, los scripts de inserción y elimi-
nación de datos.
2. Archivos Planos
Si falta codi�car clases que funcionan como parsers para el manejo
de estos archivos implementarlas.
114
3. Parser Especí�cos
Si falta codi�car clases para el manejo de estos archivos implemen-
tarlas.
Entregables o Documentos de Soporte.
Ninguno.
Criterio de Salida.
1. Artefactos de persistencia en el sitio donde se encuentra el código de la
aplicación.
Participantes. Líder de Desarrollo.
Actividad 5. Inspección de Código
Justi�cación. Cuando realizamos un documento de cualquier tipo que es de
suma importancia es necesario revisarlo para que este coherente y presentable,
de la misma forma uno debe realizar esta tarea en esta fase. La importancia de
de�nir las inspecciones como una actividad, radica en que, por ejemplo, debido
a que la codi�cación de la aplicación es compleja y dispendiosa es necesario
hacer la inspección contra listas de chequeo debido a que el estándar con el
que se codi�ca debe ser manejado por cada uno de los integrantes del equipo
y debido a la cantidad de nombres que se manejan para nombrar variables y
métodos es fácil cometer errores que ocasionan poca claridad del código, oca-
sionaría errores de comprensión y di�cultaría el mantenimiento debido a que
no es probable que la persona que escribió el código vaya a permanecer siempre
en la empresa o grupo que participó en el proyecto o que recuerde dentro de
10 años de lo que hizo especí�camente en una línea de código especí�ca.
Criterio de Entrada.
Lista de Chequeo de Código.
115
Documento de Análisis de Requerimientos del proyecto.
Descripción. La inspección de código consiste en una comparación de cada
uno de los ids de una lista de chequeo contra el código, para veri�car que cada
uno de los elementos y su descripción correspondan con la forma en que se
codi�có la aplicación. Al encontrar alguna inconsistencia esta se documenta
en un reporte con la descripción del defecto encontrado.
Se propone la realización de las siguientes tareas:
1. Se agrega el link del sitio donde se encuentra el link de la aplicación.
2. Seleccionar la metodología para realizar la inspección (Grupal o Indivi-
dual).
3. Asignar la(s) persona(s) encargadas de realizar la inspección.
4. Estimar el tiempo destinado a la inspección.
5. Realizar la inspección reportando los defectos encontrados y el tiempo
invertido.
6. Asignar la corrección de los defectos encontrados.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Implementación del proyecto.
Lista de Chequeo de Código para la Inspección de Código.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación del Reporte de Defectos.
Criterio de Salida.
1. Sitio donde se encuentra el código de la aplicación.
2. Reporte de Defectos Encontrados.
Participantes. Líder de Desarrollo.
116
7.2.7. PRUEBAS
7.2.7.1. Motivación
Las pruebas del sistema corresponden a las pruebas de validación del software
construido. El proceso de validación se lleva a cabo para saber que el software
desarrollado cubre las expectativas del cliente. Por lo tanto en esta fase se completan
los planes de prueba para hacer las pruebas más robustas. De está forma se tiene
una mayor certeza y seguridad para decir que el sistema cumple con las necesidades
identi�cadas del cliente.
7.2.7.2. Propósito
El principal �n de este proceso es asegurarse de que los objetivos del producto
fueron alcanzados mediante una solución efectiva y completa al problema inicial
planteado. Esto se veri�ca no solo con los planes de prueba, su codi�cación y la
codi�cación de pruebas unitarias, adicionalmente se necesita diseñar pruebas no
funcionales para �nalmente ejecutar todo este conjunto de pruebas y recopilar los
defectos encontrados. Cuando los participantes de esta fase son dos o más personas,
se recomienda que el encargado de reportar los defectos sea diferente del que diseño
las pruebas y quien los corrija sea diferente de quien encontró los defectos, esto
ayuda a retroalimentar el proceso con comentarios de los miembros del grupo sobre
la forma en como hacen las pruebas, la forma en como diseñan los planes de prueba,
la forma en como se describen los defectos encontrados y �nalmente la forma en
como se corrigen.
7.2.7.3. Proceso
A continuación se presentan las actividades que hacen parte del proceso de Prue-
bas desde la perspectiva de esta propuesta.
117
Actividad 1. Diseño de Pruebas de Req. No Funcionales
Justi�cación. No sólo la funcionalidad de una aplicación es importante, la
misma importancia tienen las características no funcionales que son especi�-
cadas por el cliente. Esos atributos de calidad afectan de una u otra forma
una aplicación dependiendo de la lógica que maneje. La seguridad por ejemplo
es indispensable en las organizaciones que centran su negocio en el manejo de
la información, mientras que un sistema de reserva de pasajes se basa en su
persistencia y disponibilidad.
Criterio de Entrada.
Documento de Análisis de Requerimientos del proyecto.
Documento de Diseño del proyecto.
Descripción. La elaboración de pruebas no funcionales depende mucho de
la aplicación que se ha construido, a veces las mismas pruebas de caja negra o
de caja blanca pueden probar persistencia o seguridad, por lo que las pruebas
no funcionales no siempre se pueden automatizar o seguir un esquema de�nido.
Se propone la realización de las siguientes tareas:
Por cada requerimiento no funcional, describir como se va a realizar la prueba
y los recursos necesarios para realizarla. Se diseña un plan de pruebas para
requerimientos no funcionales. Se codi�can las pruebas si es viable y recomen-
dable y si su automatización se justi�ca.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Pruebas del proyecto.
Ejemplo, plantilla y su correspondiente instructivo que describe la for-
ma de documentación de los planes de pruebas de los requerimientos no
funcionales.
118
Criterio de Salida.
1. Primera versión del documento de Pruebas del Sistema: Documento de
planes de prueba de los requerimientos no funcionales.
2. Codi�cación de las pruebas de requerimientos no funcionales en el sitio
donde se encuentra el código de la aplicación.
Participantes. Líder de Desarrollo.
Actividad 2. Ejecución de Pruebas de Caja Negra y Caja Blanca
Justi�cación. La ejecución de pruebas como parte de los procesos de veri-
�cación del software son de vital importancia para garantizar la funcionalidad
del sistema de acuerdo a los requerimientos establecidos por el cliente, debido
a que la fase de pruebas es la fase previa a la �nalización de un proyecto de
construcción de software, pero una de las más importantes ya que contempla
los ajustes �nales de la aplicación.
Criterio de Entrada.
Documento de Análisis de Requerimientos del proyecto.
Código para la automatización de las pruebas.
Primera versión del documento de Pruebas del Sistema.
Descripción. Esta actividad, como hace alusión su título, se re�ere a la
ejecución de las pruebas de caja negra y caja blanca previamente construidas.
La ejecución de esta actividad se realiza con base en el plan de pruebas de caja
negra y en la codi�cación de estas pruebas y las de caja blanca. El resultado de
esta actividad corresponde a un reporte de defectos encontrados en ejecución.
Cuando no se hace la parte de automatización de las pruebas sólo se realiza la
ejecución en base a los planes de prueba.
Se propone la realización de las siguientes tareas:
119
1. Se añade un link al documento de planes de prueba del documento de
Análisis de Requerimientos.
2. El desarrollador asignado realiza la ejecución de las pruebas codi�cadas
si las hay si no, se basa en el plan de pruebas diseñado en el documento
de Análisis de Requerimientos.
3. Se reportan los defectos encontrados sobre el documento de Reporte de
Defectos.
4. Asignación de la corrección de los defectos encontrados.
5. Corrección de los defectos asignados.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Pruebas del proyecto.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación del Reporte de Defectos del sistema.
Criterio de Salida.
1. Segunda versión del documento de Pruebas del Sistema: Se añadió el
Reporte de Defectos.
Participantes. Líder de Desarrollo.
Actividad 3. Ejecución de Pruebas de Req. No Funcionales
Justi�cación. La ejecución de pruebas como parte de los procesos de veri-
�cación de software son de vital importancia no sólo para garantizar la funcio-
nalidad del sistema de acuerdo a los requerimientos establecidos por el cliente,
sino también para garantizar los requerimientos que deben soportar esa funcio-
nalidad aunque no se perciban a simple vista. Debido a que la fase de pruebas
es la fase previa a la �nalización de un proyecto de construcción de software y
120
una de las más importantes ya que contempla los ajustes de la aplicación �nal,
es necesario garantizar la ejecución correcta de la aplicación y son los reque-
rimientos no funcionales los que dan esta garantía, al garantizar la ejecución
correcta de los requerimientos funcionales.
Criterio de Entrada.
Segunda versión del documento de Pruebas del Sistema.
Código para la automatización de las pruebas.
Descripción. Esta actividad, como hace alusión su título, se re�ere a la
ejecución de las pruebas de requerimientos no funcionales previamente cons-
truidas. La ejecución de esta actividad se realiza con base en el plan de pruebas
de requerimientos no funcionales y en su codi�cación. El resultado de esta acti-
vidad corresponde a un reporte de defectos encontrados en ejecución. Cuando
no se hace la parte de codi�cación de las pruebas sólo se realiza la ejecución
en base a los planes de prueba.
Se propone la realización de las siguientes tareas:
1. El desarrollador asignado realiza la ejecución de las pruebas codi�cadas
si las hay, sino se basa en el plan de pruebas diseñado anteriormente.
2. Se reportan los defectos encontrados sobre el documento de reporte de
defectos.
3. Asignación de la corrección de los defectos encontrados.
4. Corrección de los defectos asignados.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Pruebas del proyecto.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación del Reporte de Defectos del sistema.
121
Criterio de Salida.
1. Tercera versión del documento de Pruebas del Sistema: Se modi�có el
Reporte de Defectos.
Participantes. Líder de Desarrollo.
Actividad 4. Presentación del Producto
Justi�cación. Esta actividad consiste en la presentación del producto al
cliente. Esta presentación se realiza con el �n de obtener una retroalimentación
�nal del cliente al estar interactuando con el resultado del desarrollo del ciclo.
La ejecución de esta actividad se realiza con base en el plan de pruebas de
caja negra, y el resultado corresponde a un reporte de defectos encontrados en
ejecución.
Criterio de Entrada.
Documento de Análisis de Requerimientos del proyecto.
Tercera versión del documento de Pruebas del Sistema.
Descripción. Se propone la realización de las siguientes tareas:
1. El desarrollador asignado realiza la ejecución del plan de pruebas del
sistema junto con el responsable asignado por el cliente.
2. Se reportan los defectos encontrados sobre el documento de reporte de
defectos.
3. Asignación de la corrección de los defectos encontrados.
4. Corrección de los defectos asignados.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Pruebas del proyecto.
122
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación del Reporte de Defectos del sistema.
Criterio de Salida.
1. Cuarta versión del documento de Pruebas del Sistema: Se modi�có el
Reporte de Defectos.
Participantes. Líder de Desarrollo, Cliente.
7.2.8. POSTMORTEM
7.2.8.1. Motivación
La fase de Postmortem corresponde al último proceso en la secuencia de procesos
de desarrollo. El objetivo de este proceso es revisar el ciclo de desarrollo en busca
de oportunidades de mejora. De forma paralela se identi�can y resaltan las buenas
prácticas seguidas en el ciclo, de manera que se institucionalicen dentro del equipo
de desarrollo.
El proceso de Postmortem es el punto de referencia en el que se basa la carac-
terística de adaptabilidad de los proyectos ágiles. Reconocer las actividades que son
efectivas dentro del proceso de desarrollo, y las que no lo son, sirven como guía para
establecer un plan de mejoramiento del proceso. Realizar de manera consciente un
buen proceso de postmortem, e implantar cambios que surjan de la revisión del pro-
ceso, asegura un mejoramiento continuo junto con la adaptabilidad de los procesos
que lo requieran.
El proceso de postmortem tiene como resultado un producto de trabajo que
resume al �nal del ciclo las impresiones de todo el equipo en el tema de seguimiento
del proceso.
7.2.8.2. Propósito
La participación activa del equipo en el proceso de Postmortem, apoya el proceso
de culturización de los desarrolladores en el tema de adaptación y mejoramiento de
123
los procesos. Con esto se puede lograr que todo el equipo se convierta en multiplica-
dor de la cultura. Esta fase tiene como �n, lograr generar habilidades para aprender
a capitalizar el conocimiento adquirido en cada proceso de un proyecto de desarrollo.
7.2.8.3. Proceso
A continuación se presentan las actividades que hacen parte del proceso de Post-
mortem desde la perspectiva de esta propuesta.
Actividad 1. Análisis Global
Justi�cación. Cuando se �naliza cualquier trabajo, actividad, proyecto o
tarea, inconscientemente se re�exiona sobre lo que se hizo y sobre las decisiones
tomadas y que posibles decisiones podrían haber sido una mejor elección. Es
vital tener esa información y registrarla en algún lado, pero es más importante
hacer un análisis más detallado para asegurarnos de que lo que pensamos es lo
correcto, porque la opinión personal podría estar sesgada por diversos factores
ya que se tiene solo un punto de vista.
Criterio de Entrada.
Documento de Planeación Global del proyecto.
Documento de Diseño del proyecto.
Código de la Aplicación.
Documento de Pruebas del proyecto.
Descripción. Esta actividad consiste en la evaluación del trabajo realizado
en los diferentes frentes (Proceso y Producto), que servirá de base para la
evaluación de los objetivos planteados en la fase de Lanzamiento.
Se propone la realización de las siguientes tareas:
1. Generación de reportes por medio de grá�cas o tablas. Se proponen los
siguientes reportes cuando el equipo maneja únicamente un proyecto a la
vez:
124
Reporte de Tiempo por fase.
Reporte de Tiempo por persona.
Reporte de Porcentaje de Tiempo gastado en cada fase por persona.
Reporte de Tiempo por actividad.
Reporte de Tiempo estimado de cada requerimiento por fase.
Reporte de Tiempo gastado de cada requerimiento por fase.
LOC Global (Líneas de Código de la Aplicación).
Tamaño Detallado: Descripción de cada una de las interfaces, clases,
métodos, etc que formen el producto identi�cando el componente al
que pertenecen y sacando total, promedio y desviación estándar. Se
pueden sacar varios tipos de reportes (Número de Clases, Número
de Interfaces, Número de Atributos, Número de Métodos, Número
de Métodos Estáticos, Número de Atributos Estáticos, DIT, Com-
plejidad Ciclomática, Peso de los métodos por clase, Acoplamiento
Aferente y Eferente, Instanciabilidad, Número de Parámetros, Pro-
fundidad de los Bloques Anidados).
Reporte de Defectos (Defectos por fase contra defectos encontrados
por fase, contra defectos corregidos por fase).
Productividad (Líneas de Código por Hora para cada Fase).
Se sugiere que dependiendo del tipo y el tamaño del proyecto se saquen
únicamente los reportes necesarios y los cuales efectivamente van a ser
analizados, debido a que la tarea de generación es dispendiosa. Se reco-
mienda utilizar herramientas que ayuden en la generación de los reportes,
en especial los que tienen que ver con el tamaño detallado.
2. Generación de reportes por medio de grá�cas o tablas. Se proponen los
siguientes reportes cuando el equipo maneja varios proyectos a la vez:
Reporte de Tiempo gastado por proyecto.
Reporte de Tiempo estimado por proyecto.
Reporte de Porcentaje de Tiempo gastado del proyecto en cada fase.
125
Reporte de Tiempo estimado de cada requerimiento por fase.
Reporte de Tiempo gastado de cada requerimiento por fase.
Reporte de Defectos (Defectos por fase contra defectos encontrados
por fase, contra defectos corregidos por fase).
Productividad (Líneas de Código por Hora para cada Fase).
De la misma forma que se recomienda el uso de herramientas para la
generación de reportes cuando se trabaja en un solo proyecto a la vez,
también se recomienda para el manejo concurrente de los proyectos, ya
que el tiempo invertido en la generación de estos reportes es alto, y generar
únicamente los reportes necesarios.
Los reportes mencionados anteriormente no son los únicos que se pueden ge-
nerar, se pueden hacer combinaciones entre ellos, depende de los gustos y las
comparaciones que se deseen hacer.
Entregables o Documentos de Soporte.
1. Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Postmortem del proyecto.
Criterio de Salida.
1. Primera versión del documento de Postmortem: Análisis Global.
Participantes. Participantes Todos los roles.
Actividad 2. Análisis por Persona
Justi�cación. Un análisis global no es el único criterio para observar el
trabajo realizado, ya que es necesario observar el desempeño de cada persona
individualmente, y su in�uencia en el trabajo del equipo, por esta razón es
necesario analizar el trabajo desempeñado por cada persona.
126
Criterio de Entrada.
Reportes del trabajo realizado y el tiempo utilizado por cada persona.
Primera versión del Documento de Postmortem.
Descripción. Este análisis consiste en observar el trabajo de cada persona
durante todo el proceso de ejecución del proyecto y su aporte tanto al proceso
como al producto, esto permite evaluar la efectividad de la ejecución de las
actividades propuestas a cada rol y poder mejorarlas o mejorar su distribución
entre los demás integrantes del equipo. También permite examinar el equipo
y sus relaciones entre sus integrantes.
Se propone la realización de las siguientes tareas:
1. Generación de los siguientes reportes por persona (Es útil añadir una
comparación entre los integrantes y una comparación contra lo estimado,
para observar el desempeño de un integrante contra otro y para observar
él desfase en la planeación de las actividades que realizó cada persona):
Cuando el equipo trabaja en un sólo proyecto se recomienda sacar
los siguientes reportes:
• Reporte de Porcentaje de Tiempo gastado en cada fase por per-
sona.
• Reporte de Porcentaje de tiempo gastado por cada persona sobre
el total del equipo.
Cuando el equipo trabaja en varios proyectos se recomienda sacar los
siguientes reportes:
• Reporte de Porcentaje de Tiempo gastado de cada proyecto por
persona.
• Reporte de Porcentaje de Tiempo gastado de cada persona por
proyecto.
• Reporte de Porcentaje de tiempo gastado por cada persona sobre
el total del equipo.
127
2. Realizar un resumen del trabajo realizado por cada persona de acuerdo a
los reportes del trabajo realizado y el tiempo utilizado por cada persona.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Postmortem del proyecto.
Criterio de Salida.
1. Segunda versión del documento de Postmortem: Se añadió el Análisis por
Persona.
Participantes. Todos los roles.
Actividad 3. Evaluación de Pares
Justi�cación. La característica más importante que se debe tener en cuen-
ta para que un desarrollador trabaje en un proyecto ágil, es la constancia y
el compromiso con el proyecto. El equipo no debe estar integrado por desa-
rrolladores brillantes, pero sí necesita desarrolladores comprometidos. Por el
esquema de trabajo que se propone, y especialmente por la característica de
dispersión del equipo, el trabajo de un desarrollador se mide de acuerdo a los
resultados y al aporte general para el proyecto. Esto se puede revisar al �na-
lizar cada periodo de desarrollo. Sin embargo, es importante al �nal del ciclo,
revisar si el resto del equipo está conforme con el trabajo de un desarrollador.
De no ser así, este debe adaptar su forma de trabajo a los parámetros del
equipo, o debe salir de este.
Criterio de Entrada.
Reportes del trabajo realizado y el tiempo utilizado por cada persona.
Segunda versión del documento de Postmortem.
128
Descripción. Esta actividad consiste en la realización por parte de cada
integrante del equipo de una evaluación del resto de los integrantes. Esta eva-
luación tiene como objetivo recoger la opinión de cada integrante, acerca de
sus compañeros. En la evaluación se debe tener en cuenta diferentes tópicos
que agrupen el comportamiento general del desarrollador.
Se propone la realización de la siguiente tarea:
1. Cada integrante del equipo llena el formato de evaluación de pares con
base en el instructivo de formato de evaluación de pares.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la Evaluación de Pares.
Criterio de Salida.
1. Documentos de Evaluación de Pares de cada integrante del equipo.
Participantes. Todos los roles.
Actividad 4. Evaluación de Objetivos
Justi�cación. Todos los objetivos propuestos deben ser evaluados cuando
se alcanzan o en la fecha para la cual se determinó que se alcanzarían, de esta
forma se evalúa el grado o porcentaje alcanzado de los objetivos de acuerdo a
las métricas iniciales que se establecieron.
Criterio de Entrada.
Documento de Lanzamiento del Proyecto.
Reportes del trabajo realizado y el tiempo utilizado por cada persona.
Segunda versión del Documento de Postmortem.
Documentos de Evaluación de Pares de cada integrante del equipo.
129
Descripción. Esta actividad consiste en la evaluación de los objetivos es-
tablecidos en el documento de Lanzamiento del proyecto de acuerdo a las
métricas establecidas para las metas de cada objetivo.
Se propone la realización de las siguientes tareas:
1. Evaluación de cada objetivo de acuerdo a los reportes del trabajo reali-
zado, de acuerdo a lo registrado hasta el momento en el postmortem y
de acuerdo a los documentos de Evaluación de Pares.
2. Resumen del alcance del ciclo, todo lo que se hizo teniendo en cuenta lo
que se planeó y lo que no fue planeado pero se realizó, y lo que no se
realizó o no se logró terminar.
Entregables o Documentos de Soporte.
Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Postmortem del proyecto
Criterio de Salida.
1. Tercera versión del documento de Postmortem: Se añadió la Evaluación
de Objetivos.
Participantes. Todos los roles.
Actividad 5. PIP
Justi�cación. Al �nalizar todo proyecto es necesario recopilar toda la ex-
periencia aprendida y plantear mejoras para el proceso de ejecución de nuevos
proyectos y de esta forma evitar cometer los mismos errores. Durante la ejecu-
ción de un proyecto y de cualquier otra actividad es necesario estar consciente
de que constantemente se está en un proceso de aprendizaje continuo. El PIP
(Process Improvement Proposal) es una de las actividades más enriquecedoras
para cualquier proceso que aplique o desee aplicar políticas de mejoramiento
continuo.
130
Criterio de Entrada.
Reportes del trabajo realizado y el tiempo utilizado por cada persona.
Tercera versión del documento de Postmortem.
Descripción. Está es la ultima actividad del proceso de postmortem pero
no la menos importante, ya que puede que su importancia no sea tan relevante
para este proyecto o para este ciclo, pero para próximos proyectos es vital para
el continuo del contínuo mejoramiento del proceso y el equipo así como de los
nuevos productos que van a ser generados.
Se propone la realización de las siguientes tareas:
Resumen de los principales problemas encontrados durante la ejecución
del proyecto.
Evaluación de la Administración de Riesgos (¿Que riesgos se administra-
ron?, ¿cómo se mitigaron o detuvieron?, ¿sirvieron los planes de mitiga-
ción y contingencia?, propuestas de mejoramiento).
Evaluación de las Herramientas utilizadas (¿Qué herramientas se utiliza-
ron?, ¿para que se utilizaron?, ¿se utilizaron adecuadamente?, ¿al utili-
zar las herramientas se mejoraron las tareas en las que fueron utilizadas?,
¿si no se utilizaran, que ocurriría?, propuestas de Mejoramiento)
Propuestas de Mejoramiento del Proceso.
Propuestas de Mejoramiento del Trabajo en Equipo.
Propuestas de Mejoramiento del Producto.
Enumeración de las Lecciones Aprendidas por los miembros del equipo.
Enumeración de los objetivos para próximos ciclos o proyectos.
Entregables o Documentos de Soporte.
1. Ejemplo, plantilla y su correspondiente instructivo que describe la forma
de documentación de la fase de Postmortem del proyecto.
131
Criterio de Salida.
1. Versión �nal del documento de Postmortem: Se añadió el PIP.
Participantes. Todos los roles.
7.3. Manual de Uso del Proceso
La de�nición de un proceso no es su�ciente para su aplicabilidad, por lo tanto a
continuación se explica como usarlo.
7.3.1. Recomendaciones
Para utilizar adecuadamente el proceso PAL se debe tener en cuenta las siguientes
recomendaciones cada vez que se vaya a utilizar dicho proceso:
El proceso se debe considerar como una guía para la construcción de software,
por lo que si en algún momento el proceso no se aplica, se debe adaptar al
proyecto en el que se va a utilizar. Si la adaptación produjo buenos resulta-
dos, es bueno evaluarla en la fase de Postmortem y proponerla como cambió
al proceso con su correspondiente justi�cación, esta es una de las bases del
mejoramiento continuo.
Siempre se deben buscar herramientas que soporten el proceso y no al con-
trario, porque una herramienta se actualiza más rápido que un proceso, y el
hacer un proceso dependiente de la tecnología causa que sea poco mantenible
cuando la tecnología se vuelva obsoleta. Pero esto no signi�ca que no se uti-
lice ninguna herramienta sino que hay que saber escoger las herramientas y
utilizarlas adecuadamente.
Todo cambio permanente al proceso debe ser documentado, si se hace una
adaptación al proceso que sólo será momentánea esta debe ir en el documento
de Estrategia del proyecto.
132
Siempre se debe leer el proceso antes de su aplicación, debido a cambios que
se pudieron realizar entre ejecución de cada proyecto, esto permitirá aclarar
dudas a tiempo evitando de esta manera afectar la ejecución del proyecto.
7.3.2. Metodología
Teniendo en cuenta las anteriores recomendaciones la metodología que se debe
seguir para la aplicación del proceso, es la siguiente:
1. Con el primer documento que se utiliza de base para iniciar un proyecto (Do-
cumento de levantamiento de requerimientos narrativos), se debe reconocer la
viabilidad de la aplicación del proyecto de acuerdo a como se de�nió el proceso
en esta propuesta. Generalmente, esta viabilidad se reconoce en la fase de Es-
trategia, pero puede haber algunos proyectos que de acuerdo a la información
dada en un principio se pueden reconocer modi�caciones inmediatas que se le
deben hacer al proceso, pero se necesita establecer la organización especí�ca
del equipo (Lanzamiento), para poder plantear las modi�caciones al proceso
con justi�caciones claras (Estrategia).
2. Identi�car las herramientas que se van a utilizar para soportar el proceso, si ya
se tiene alguna experiencia, la identi�cación de las herramientas que se pueden
utilizar será más fácil pero al igual que las personas que no tienen experiencia
es bueno investigar nuevas herramientas que mejoren la ejecución del proceso.
3. Si se tiene ya un documento de estándares, ubicarlo en un lugar de fácil ubica-
ción y acceso para todo el equipo, si ya se ha desarrollado proyectos con este
proceso se debe hacer buen uso de los históricos y utilizar la sección de Admi-
nistración de Con�guraciones de los documentos de Estrategia, de lo contrario
crear un documento de estándares muy básico y que sirva como un criterio de
entrada más para la construcción de la Administración de Con�guraciones.
4. Se recomienda establecer una buena administración de riesgos que no se limite
a identi�car riesgos del producto del proceso o del equipo, su extensión puede
133
alcanzar criterios como el costo o el soporte, estos tipos de riesgos pueden ser
importantes para una empresa con poca capacidad de adquisición de recursos,
pero pueden no ser importantes para otras empresas que tienen un alto capital
y un buen poder de adquisición o simplemente en el proyecto no se identi�can
ese tipo de riesgos.
5. Se debe de�nir un buen proceso de seguimiento, si no se tiene es bueno de�nirlo
en la fase de Estrategia del proyecto e incluirlo en la sección de Aseguramiento
de la Calidad, de esta forma facilita los cambios, la adaptación, la solución de
problemas y futuras mejoras a este proceso.
6. Finalmente, es necesario considerar los históricos de proyectos pasados, junto
con la administración de con�guraciones del proyecto actual como criterios de
entrada para cada una de las fases del proceso y sus respectivas actividades.
7.4. Uso del Proceso en el Proyecto AVA
Para el grupo de Desarrollo, y en especial para la ejecución del proyecto AVA,
debido a sus características se de�nió:
Los documentos De Lanzamiento y Estrategia que se utilizarán en la etapa en
la cual se encuentra el proyecto AVA en este momento, la cual se caracteriza
por la creación de varios AVAs concurrentemente, son iguales para cada AVA,
por lo que los ciclos de desarrollo contemplan las fases de Planeación, Diseño,
Implementación, Pruebas y Postmortem. El Análisis de Requerimientos debe
ser manejado por ciclos también, pero está fase es responsabilidad del grupo
de Diseño Instruccional y se sale del alcance de esta propuesta.
Debido a que en el documento de Estrategia se especi�can actividades depen-
dientes del ciclo en el que se ejecutan, se extrae las secciones de Alcance del
Ciclo, Planeación Preliminar y Administración de Riesgos, para formar una
fase que va antes de la Planeación denominada Estrategia del Ciclo.
134
Las fases de Lanzamiento y Estrategia se trabajan en equipo, por lo cual
participan los roles de Líder de Equipo y Líder de Desarrollo.
La correspondencia entre roles del Grupo de Desarrollo y los roles del proceso
es:
• El Coordinador del grupo de Desarrollo asume el rol de Líder de Equipo.
• Los desarrolladores asumen el rol de Líderes de Desarrollo, debido a que
como su rol lo indica se encargan de �Liderar el Desarrollo� de los AVAs
que les fueron asignados por el Líder del Equipo.
La asignación de los AVAs a los desarrolladores se hace en la fase de Estrategia.
El tipo de AVA se debe de�nir en la fase de Diseño, pero la decisión del tipo
de AVA es tomada por el Interlocutor y debe ir a modo de sugerencia con
su respectiva justi�cación al Desarrollador en el momento de entregarse el
documento de Análisis de Requerimientos para su validación.
El máximo nivel de detalle que se debe alcanzar en el documento de Planeación
Global, en la Planeación Preliminar de la fase de Estrategia del ciclo y en los
reportes generados de la fase de Postmortem es el de Requerimiento.
El máximo nivel de detalle que se debe alcanzar en el Análisis del Ciclo del
Postmortem es el de Fase.
El grupo de Diseño Instruccional es el responsable de facilitarle el documento
de levantamiento de requerimientos narrativo al grupo de Desarrollo.
Debido a que el grupo de Diseño Instruccional es el encargado de realizar el
documento de Análisis de Requerimientos, se puede simpli�car el proceso al
cambiar el documento de levantamiento de requerimientos narrativos por el
documento de Análisis de Requerimientos como criterio de entrada de la fase
de Estrategia, como consecuencia el documento de Estrategia y el documento
de Planeación se mejoran acercándolos mejor a la realidad del proyecto (Ver
Figura 9).
135
Figura 9: Proceso PAL utilizado por el grupo de Desarrollo dentro del Proceso deConstrucción de un AVA. También se puede observar como sería el proceso utilizadopor el grupo de Diseño Instruccional si también utilizará el proceso PAL
136
Capítulo VIII
Evaluación de Herramientas
Finalmente, teniendo en cuenta el proceso de�nido en el capítulo anterior, es
necesario evaluar las herramientas actuales que sirven de soporte al proceso de cons-
trucción de software en el grupo de Desarrollo para realizar unas recomendaciones
sobre como usar las herramientas actuales y como usarlas adecuadamente.
8.1. Herramientas Actuales
Actualmente, el grupo de Desarrollo utiliza dos herramientas de soporte al proce-
so de construcción de software: DotProject y una Wiki. Existen otras herramientas
utilizadas como lo son Eclipse y Poseidon, pero no dan soporte a todo el proceso
sino a fases especí�cas por lo que no hacen parte de la evaluación.
8.1.1. Descripción
DotProject Es una herramienta para la administración de proyectos [Dot06].
LIDIE la utiliza para la administración de sus proyectos, documentando en que
fase se encuentra el proyecto en un momento determinado de la ejecución del
proyecto, el coordinador que es responsable del AVA y todas las personas vin-
culadas al proyecto, así como la planeación de cada una de las actividades que
van a ser ejecutadas para la ejecución del proyecto. A medida que va avanzan-
do el proyecto, se van registrando los tiempos utilizados por cada actividad con
su correspondiente comentario sobre la descripción de la actividad que se hizo
y los problemas encontrados. Finalmente, esta herramienta también se utiliza
para adjuntar los documentos relacionados con el proyecto, tanto documentos
137
con información proveída por el cliente, como entregas generadas no sólo por
el grupo de Desarrollo sino también por los demás grupos interdisciplinarios.
Wiki Es una herramienta para la construcción de documentos colaborativa-
mente en la red, permitiendo su consulta en línea, es considerada �la base de
datos en línea más simple que pueda funcionar�[Fou06]. Inicialmente LIDIE
intentó usar una Wiki llamada phpWiki, en la cual se quería registrar toda la
documentación y herramientas que utilizaba el grupo de Desarrollo, se quería
utilizar como un sitio de información centralizada para el grupo de Desarrollo.
Debido a sus limitaciones en cuanto a edición y a la poca documentación que
se manejaba en el grupo de Desarrollo sobre los proyectos en los cuales parti-
cipaba, su acogida fue muy baja. Actualmente, para soportar la de�nición del
proceso PAL, artefacto resultante del objetivo de mejorar la Administración
de Conocimiento para LIDIE, se reevaluó el uso de la Wiki, dando como re-
sultado la instalación de la DokuWiki cuyo principal objetivo es registrar todo
el conocimiento adquirido por el Grupo de Desarrollo, lo cual incluye desde
manuales para la utilización de herramientas y plantillas hasta la descripción
de los diferentes procesos que se ejecutan para sus proyectos.
CVS Es una herramienta para el control de versiones [Xim06], mediante el
cual se registra los artefactos generados con sus respectivos comentarios y
que permite el trabajo colaborativo distribuido, permitiendo que los proyectos
trabajados bajo esta herramienta puedan estar disponibles para su trabajo en
cualquier momento. LIDIE utiliza esta herramienta únicamente en su grupo
de Desarrollo para las aplicaciones que se encuentran en desarrollo.
8.1.2. Recomendaciones
DotProject
• Se debería clasi�car el estado del proyecto por fase en la que se encuentra
y no por grupo en el que se encuentra, o utilizar como segundo criterio
el grupo, porque actualmente pasa de estar clasi�cada por grupo a estar
138
clasi�cada por fase lo que di�culta a�rmar el estado en el que se encuentra
el proyecto.
• Se debería utilizar estándares de nombramiento para los documentos que
son adjuntados, debido a que la búsqueda de un documento especi�co
no es nada fácil con los nombres que actualmente se le asignan a los
documentos.
• Se debería revaluar el uso se DotProject como repositorio, ya que el grupo
de Desarrollo ya utiliza un sistema controlador de versiones que es CVS.
y DotProject está orientado a la administración de proyectos y no como
un sistema controlador de versiones.
• Se debería utilizar un formato más liviano para la elaboración de do-
cumentos, o por lo menos hacer que los documentos adjuntados a Dot-
Project sean lo más livianos posible, para que el mantenimiento de la
documentación y de la herramienta sea sencillo. Se recomienda adjuntar
archivos en formato PDF.
Wiki
• Antes de comenzar a utilizar la Wiki, es bueno realizar un mapa de na-
vegación para que la ubicación de los documentos sea sencilla, además de
revisar la estructura que se está manejando actualmente.
• Cada página debería tener una pequeña explicación de lo que se puede
encontrar entre sus contenidos.
• Mediante un manejo adecuado de estándares de nombramiento y docu-
mentación la Wiki es una buena herramienta para el registro y generación
de documentación, debido a que no se necesita un programa adicional
para su edición por su facilidad para la edición de documentos en línea,
adicionalmente provee un sistema básico de control de versiones y permite
generar documentos portables en PDF o en XHTML.
• Se debe restringir el acceso a determinadas carpetas o secciones de la
Wiki de acuerdo a los roles especi�cados o a los grupos interdisciplinarios
139
participantes, de esta forma el grupo de Desarrollo no puede editar los
documentos del grupo de Diseño Instruccional y viceversa.
8.2. Herramientas Sugeridas
Para que el proceso de�nido tenga un soporte completo es necesario contar con
herramientas adicionales a las mencionadas anteriormente, por lo que a continuación
se mencionan los procesos para los cuales se necesitan herramientas de soporte.
Se necesita una herramienta para la admininistración de riesgos, ya que este es
un proceso importante pero costoso en tiempo si se maneja una alta cantidad
de riesgos. La mayoría de las veces se priorizan los riesgos para poder admi-
nistrar los más importantes ocasionando que algunos riesgos no se tengan en
cuenta y hasta se menosprecien.
Se necesita una herramienta para el reporte de defectos encontrados en pruebas
e inspecciones, debido a que el mantenimiento y ejecución de históricos de estos
procesos es alto. Actualmente existen herramientas como Mantis e Insectivore
para el reporte de defectos y Hammurapi para la inspección de código.
Se necesita un herramienta para la generación de reportes y análisis de métricas
como HackyStat, también se puede pensar en extender la funcionalidad de
herramientas existentes, especialmente para herramientas de administración
de proyectos como DotProject.
Finalmente, es importante recordar que para la utilización de una nueva he-
rramienta es importante aprender a utilizarla adecuadamente, ya que aunque el
aprendizaje es una inversión alta y es altamente costoso cuando se esta empezando
a utilizar, es una buena práctica el saber administrar los recursos utilizados para
dicho aprendizaje.
140
Capítulo IX
Resultados
Los resultados generados de la elaboración del trabajo enunciando en este docu-
mento se presentan a continuación:
Durante la ejecución de este trabajo, el grupo de Desarrollo se concientizó
de sus propios problemas y comenzó a solucionarlos, de los cuales uno de
los más importantes fué la diferenciación de las responsabilidades del grupo de
Desarrollo de las responsabilidades del grupo de Diseño Instruccional. Además,
el grupo de Diseño Grá�co se independizó del grupo de Desarrollo ya que
además de prestar servicios en la parte grá�ca al grupo de Desarrollo, comenzó
a prestar servicios similares al grupo de Diseño Instruccional.
La de�nición del proceso permitió la estandarización de los procedimientos y
documentos, y la especi�cación de las tareas, de esta forma evitando malen-
tendidos y la mejor ubicación de los artefactos generados.
La adaptación del proceso permitió de�nir el proceso de acuerdo a las nece-
sidades que tenía LIDIE en cuanto a su proceso de desarrollo, esto ocasionó
que el proceso fuera fácilmente adaptable debido a las características de los
procesos manejados por QualDev.
Gracias al proyecto QualDev Community se pudo adaptar una herramien-
ta como la Wiki, que pudiera soportar el proceso de la Administración del
Conocimiento, comenzando con la de�nición del proceso en esta herramienta,
y extendiendo su uso a lo demás grupos interdisciplinarios para registrar su
141
propio conocimiento.esto adicionalmente generó en el grupo de Desarrollo una
concientización de la importancia de la propiedad colectiva del conocimiento
como base para la administración del conocimiento en una empresa en continua
rotación de personal.
El uso del modelo IDEAL en el marco del proyecto QualDev Community
permitió hacer mejoras continuas a la adaptación del proceso, y de esta manera
la adaptación del cronograma de acuerdo a los problemas ocurridos.
Fácilmente se identi�có la adaptabilidad del proceso generado para el grupo
de Diseño Instruccional, en el cual se aplicarían las fases de Lanzamiento, Es-
trategia, Análisis de Requerimientos y Postmortem. La justi�cación de esta
adaptabilidad se reconoce al observar desde una perspectiva general que fácil-
mente las fases de Lanzamiento, Estrategia y Postmortem contienen prácticas
que deberían ser utilizadas por cualquier equipo de cualquier disciplina.
La de�nición del proceso, plantillas y tutoriales permitió fácilmente identi�car
y clasi�car los AVAs, y los requerimientos.
Para QualDev el desarrollo de este trabajo, además de retroalimentar las prác-
ticas utilizadas en la ejecución de los procesos utilizados en la construcción de
software y en la adaptación de sus procesos en otras empresas, generó un
vínculo para el desarrollo de nuevos proyectos que se basarán en el trabajo
desarrollado en esta propuesta.
Finalmente el estado de LIDIE al �nalizar este trabajo se puede observar en
las (Figuras 10 y 11) que clasi�can los problemas del grupo de Desarrollo
de LIDIE por proceso y por tipo de proceso, donde para cada problema se
identi�có la viabilidad de su solución, si era de un alto interés para LIDIE y
�nalmente, si el problema fue atacado1 , todo en el marco de esta propuesta.
1Que un problema fuera atacado no signi�ca necesariamente que fue solucionado completamente,pero si que el proceso al que pertenece fue mejorado para gradualmente eliminar los problemas quelo afectan
142
Figura 10: Problemas del Grupo de Desarrollo de LIDIE, pertenecientes a los pro-cesos de Administración.
143
Figura 11: Problemas del Grupo de Desarrollo de LIDIE, pertenecientes a los pro-cesos de Desarrollo y a los procesos Transversales.
144
Capítulo X
Conclusiones
A continuación se listan las conclusiones de este trabajo:
La principal di�cultad de este tipo de trabajos es el grado de acercamiento que
se tiene con la empresa analizada, ya que además de la necesidad de solicitar
la información correcta es necesario saber también solicitar la cantidad de
información necesaria y adecuada. Para la adquisición de la información es
necesario tener una comunicación continua y si es posible una relación estrecha
con los contactos de la empresa, debido a que durante todo el proceso se
presenta una retroalimentación continua como se dió en este caso para QualDev
y para LIDIE.
Para poder seleccionar el punto crítico a trabajar y la metodología adecuada,
fue necesario hacer un análisis global de los problemas encontrados en el grupo
de Desarrollo, para identi�car los procesos que tenían problemas. Luego se hizo
una identi�cación del proceso que al mejorarlo ocasionará el mayor impacto,
para �nalmente establecer la metodología que se iba a llevar a cabo para el
mejoramiento del proceso seleccionado. De no haberse hecho de esta forma la
identi�cación de los problemas hubiera sido sesgada y la solución identi�cada
no hubiera sido la correcta ocasionando que las actividades para ejecutar la
solución propuesta no mostrara resultados.
Debido a que no se tienen términos globales para el manejo de nombres de pro-
cesos, fue necesario analizar diferentes MCVSs, identi�car procesos comunes y
145
de�nirlos para evitar un manejo inapropiado de conceptos. Esto adicionalmen-
te llevó a la identi�cación del MCVS adecuado para la de�nición y adaptación
del proceso de construcción de software para el grupo de Desarrollo de LIDIE.
La importancia de desarrollar este trabajo de la forma descrita en este do-
cumento, es que permitió la retroalimentación continua generando mejoras
continuas durante el proceso y sobre la cultura organizacional.
El proceso de construcción de software resultante, es fácilmente adaptable a las
necesidades del grupo de desarrollo de LIDIE, así como a otras empresas que
presenten características similares, debido a que permite adecuarse al proyecto
que se desee llevar acabo, de esta forma se considera que el proceso tiene
una alta mantenibilidad, especialmente cuando se utilizan las herramientas
adecuadas.
Finalmente, la construcción de un proceso de desarrollo de software educativo
no es diferente de la construcción de cualquier otro tipo de software, pero para
el caso de LIDIE y en especial para el proyecto AVA, la forma de trabajar
en equipo, sus integrantes y la naturaleza del proyecto si in�uencian la for-
ma de construir el software, debido a que es un proyecto que maneja varios
proyectos y a la interacción que tienen en la construcción del software grupos
interdisciplinarios diferentes al de Desarrollo como lo es el grupo de Diseño
Instruccional y el grupo de Diseño Grá�co.
146
Capítulo XI
Trabajo a Futuro
Teniendo en cuenta los resultados (Cap. 9) y las conclusiones (Cap. 11), a con-
tinuación se presentan una serie de actividades (Sección 3.4) que se proponen como
continuación a este trabajo clasi�cadas por procesos (Sección 3.2):
De�nición y Adaptación de los procesos de Soporte:
• Formalización del proceso de Administración de Conocimiento.
• Aunque ya existe una Administración de Con�guraciones desarrollada
como producto de la fase de Estrategia, falta formalizar su proceso y
completarla.
• Utilizar Changeset como una herramienta de soporte para la adminis-
tración de los cambios en los requerimientos y manejar las prioridades,
así como clasi�car los proyectos de acuerdo a su tipo (Web-Standalone,
SICUA) y a su servicio (Soporte o Desarrollo).
• Aunque ya existe una Administración de Riesgos desarrollada adaptada
en la fase de Estrategia, es necesario una herramienta que facilite este
proceso, por lo cual sería interesante investigar sobre las herramientas
disponibles y su adaptación o el diseño de una nueva.
• Finalmente se necesita una herramienta que administre estadísticas, re-
portes y estados de los proyectos y que permita su integración con las
herramientas que se manejan para soportar cada uno de los procesos de
construcción de software.
147
De�nición y adaptación de los procesos transversales:
• Aunque ya existe una Planeación desarrollada como una fase del proceso
de Desarrollo, falta formalizar la parte de su seguimiento y reforzar Dot-
project con el uso de una herramienta que facilite la creación de multiples
tareas y genere reportes y estadísticas.
• Aunque se especi�có brevemente en la Estrategia del Proyecto AVA prác-
ticas de Calidad en el plan de Aseguramiento de Calidad, es necesario for-
malización de la Administración de la Calidad perteneciente al proceso
de Optimización.
• Es necesario la adaptación de herramientas para la ejecución de inspec-
ciones tanto de código como de documentos y para la administración de
los defectos resultantes.
De los procesos de desarrollo, se necesita una herramienta general que auto-
matice la ejecución de pruebas, en especial para pruebas de requerimientos no
funcionales, y que administre los defectos resultantes.
148
Referencias
[BD04] Bernd Bruegge and Allen H. Dutoit. Object-Oriented Software Enginee-ring: using UML, patterns and Java. Prentice Hall, New York, 2004.
[Bec99] Kent Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley Professional, 1st edition, October 1999.
[BH95] A.-P. Brohl and W. Droschel (Hrsg.). Das V-Modell � Der Standard furdie Softwareen-twicklung mit Praxisleitfaden. Software � Anwendungssys-teme � Informationssysteme, Oldenbourg, Munchen, second edition, 1995.
[Boe86] B.W. Boehm. A Spiral Model of Software Development and Enhancement,volume 11 (4). Software Engineering Notes, August 1986.
[CA00] Richard B. Chase and Nicholas J. Aquilano. Administración de la produc-ción y las operaciones. McGraw Hill Iberoamericana, 2000.
[CD05] Inc. Creative Data. Development methodology - joint application deve-lopment (jad). http://www.credata.com/research/jad.html, 2005.
[Dot06] DotProject. Dotproject. http://www.dotproject.net/, 2006.
[Fou06] Wikimedia Foundation. Wikipedia. http://es.wikipedia.org/wiki/Wiki,2006.
[Gal92] A. H. Galvis. Ingeniería de Software Educativo. Ediciones Uniandes,Santafé de Bogotá, 1992.
[Gro06a] QualDev Group. Adaptación de dokuwiki.http://chie.uniandes.edu.co/%7Echangeset/process/doku.php?id=development:resources:tutorials:tools:adaptacion_dokuwiki, 2006.
[Gro06b] QualDev Group. Changeset process.http://chie.uniandes.edu.co/%7Echangeset/process/doku.php?id=development:process:process, 2006.
149
[Gro06c] QualDev Group. Changeset project.http://chie.uniandes.edu.co/%7Echangeset/process/doku.php?id=development:projects:changeset:changeset/, 2006.
[Gro06d] QualDev Group. Qualdev community.http://chie.uniandes.edu.co/%7Echangeset/process/doku.php?id=development:projects:empresas:empresas, 2006.
[Gro06e] QualDev Group. Qualdev group. http://chie.uniandes.edu.co/%7Echangeset/,2006.
[Hum00] Watts S. Humphrey. Introduction to the team software process. AddisonWesley Longman, Inc., Massachussets, 2000.
[IJ99] James Rumbaugh Ivar Jacobson, Grady Booch. The Uni�ed SoftwareDevelopment Process. Book News, Inc., Portland, 1999.
[J.04] Hugo Fernando Arboleda J. Procesos adaptables de desarrollo de softwarepara proyectos Ágiles. Master's thesis, Universidad de Los Andes, 2004.
[Kru03] P. Kruchten. The Rational Uni�ed Process. Addison-Wesley, May 2003.
[Lar98] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall PTR, Upper Saddle River,N.J., 1998.
[LID05] LIDIE. Laboratorio de desarrollo e investigación sobre informática eneducación (lidie). http://lidie.uniandes.edu.co, 2005.
[LID06a] LIDIE. Lidiewiki. http://tereque.uniandes.edu.co/doku/doku.php?id=presentacion, 2006.
[LID06b] LIDIE. Pal: Proceso de administración de la construcción desoftware de lidie. http://tereque.uniandes.edu.co/doku/doku.php?id=desarrollo:proceso:descripcion, 2006.
[LID06c] LIDIE. Proyecto ava: Ambientes virtuales de aprendizaje.http://ava.uniandes.edu.co, 2006.
[Ltd05] Chambers & Associates Pty Ltd. Concept: Life cycle model.http://www.chambers.com.au/Sample_p/c_pmodel.htm, 2005.
[Mar91] James Martin. Rapid Application Development. Macmillan Coll Div, May1991.
150
http://chie.uniandes.edu.co/~changeset/process/doku.php?id=development:projects:changeset:changeset/
[Mob99] Prototyping Your Process, Team and Tools Improving the Usability ofWork. Karen L. Mobley and Judith R. Fisher, 1999.
[Nie04] Benjamin W. Niebel. Ingeniería Industrial, Métodos, Estándares y Diseñodel trabajo. Ediciones Alfaomega, 2004.
[Ros03] Jeanne W. Ross. Creating a strategic it architecture competency: Learningin stages. Center for Information Systems Research, (CISR WP 335),2003.
[Roy70] W. W. Royce, editor. Managing the Development of Large Software Sys-tems. IEEE WESCON, August 1970.
[Uni06] Carnegie Mellon University. The ideal sm model.http://www.sei.cmu.edu/ideal/, 2006.
[WS95] J. Wood and D. Silver. Joint Application Development. Wiley, New York,2nd edition, 1995.
[Xim06] Derek Robert Price & Ximbiot. Cvs - concurrent versions system.http://www.nongnu.org/cvs/, 2006.
[ySR05] Camilo Rincón y Sergio Rodríguez. Mejoramiento del proceso de planea-ción y seguimiento de proyectos de desarrollo de software en pequeñasempresas. Master's thesis, Universidad de Los Andes, 2005.
151
Anexos
Anexo 1: Formato de Entrevistas
a. ¾Cómo es el proceso de desarrollo de un producto?
b. ¾De que manera se distribuye el trabajo?
c. ¾Qué herramientas son utilizadas?
d. ¾Qué tareas comunes son desarrolladas?
e. ¾Cómo es la interacción con los otros grupos de trabajo?
152
f. ¾Cuales son los roles establecidos dentro del grupo?
g. ¾Qué aspectos de la manera en que el grupo trabaja, están funcionando?
h. ¾Qué aspectos de la manera en que el grupo trabaja, no están funcionando?
i. ¾Qué expectativas tiene?
153
