Definición de Un Proceso de Desarrollo de Software en Un Entorno PDF

Instituto Superior Politécnico José Antonio
Echeverría CUJAE
DEFINICIÓN DE UN PROCESO
DE DESARROLLO DE
SOFTWARE EN UN ENTORNO
UNIVERSITARIO.
Daynel Díaz Polo
La Habana, 2011
Tesis de Maestría
Página Legal
Definición de un proceso de desarrollo de software en un entorno universitario. – La Habana

: Instituto Superior Politécnico José Antonio Echeverría (CUJAE), 2011. – Tesis (Maestría).
Dewey: 621.39 Ingenieía de computadoras.

Registro No.: Maestria1001 CUJAE.
(cc) Daynel Díaz Polo, 2011.

Licencia: Creative Commons de tipo Reconocimiento, Sin Obra Derivada.
En acceso perpetuo: http://www.e-libro.com/titulos
Instituto Superior Politécnico “José Antonio
Echeverría”
Facultad de Ingeniería Informática
Centro de Estudios de Ingeniería y Sistemas

Ingeniería en Informática
Definición de un proceso de desarrollo de software en

un entorno universitario.
Tesis presentada en opción al Título de Máster en Informática Aplicada
Autor: Ing. DaynelDíaz Polo
ddiazp@udio.cujae.edu.cu
Tutor: Dra. Martha Dunia Delgado Dapena
Profesor Titular
marta@ceis.cujae.edu.cu
Ciudad de La Habana, Cuba
Octubre, 2011
Agradecimientos
A mis padres por confiar todo el tiempo en mí, y apoyarme en todos los momentos con
su cariño y amor.
A mi hermana por estar a mi lado, quererme y ser la amiga con la que siempre puedo
contar. Aunque estés lejos siempre estaremos juntos. TE QUIERO.
A Jennifer por aguantar y soportar mis pesadeces, y por tener tanta paciencia conmigo,
gracias por tu apoyo y amor.
A todos mis amigos por ayudarme en todos los momentos e insistir tanto en que lograra
esto.
A mi tutora Martha por apoyarme y confiar en mí, e insistir para que lograra esto,
nunca perdió la esperanza.
A todo el equipo del proyecto en especial a Dailin y Daniel por ayudarme en todo
momento, gracias por aguantarme y por sacar adelante este trabajo.
En fin gracias a todos por el apoyo incondicional ….

Resumen
La definición de un Proceso de Desarrollo de Software puede convertirse en una
actividad caótica teniendo en cuenta la diversidad de procesos, técnicas y paradigmas
que existen en la actualidad. Por otra parte la elección y adecuación de una
Metodología de desarrollo resulta un elemento clave en el éxito que se alcance en un
Proceso de Desarrollo. Esto adquiere una significación especial en la industria de
software por las características inherentes al producto final que lo hacen diferente de
otros procesos tecnológicos y productivos.
Teniendo en cuenta las características del Complejo de Investigaciones Tecnológicas

Integradas que serán ampliadas posteriormente en este documento, que aunque se
dedique a la investigación y producción de software al igual que otras organizaciones
ofrece un marco distinto para esta actividad. Este entorno está matizado por la
presencia de estudiantes y especialistas que se dedican además a otras actividades;
por estas razones resulta una labor ardua para el líder del proyecto organizar y guiar al
equipo de desarrollo de manera acertada.
En el presente documento, se hace un estudio de los distintos tipos de procesos y

algunas de las metodologías tradicionales y ágiles más usadas para llevar a cabo
dicho proceso. Además se resaltan las principales áreas claves del Proceso de
Desarrollo de Software, según CMMI, otro aspecto a tener en cuenta a la hora de
definir un proceso de desarrollo de software es garantizar un herramienta que le de
soporte a dicho proceso, agilizando y aumentando la calidad del producto final,
además de establecer un contexto homogéneo en la gestión de las soluciones del
centro. Que teniendo en cuenta la creciente complejidad de los sistemas se hacía
necesario incluir a la hora de definir dicho proceso.
Índice
Introducción .................................................................................................................................. 1
1. Procesos de Desarrollo de Software .................................................................................... 5
1.1. Introducción .................................................................................................................. 5
1.2. Proceso de desarrollo de software ............................................................................... 5
1.3. Metodologías de Desarrollo de software ...................................................................... 6
1.3.1. Proceso Unificado de Rational .............................................................................. 7
1.3.2. eXtreme Programming .......................................................................................... 9
1.3.3. SCRUM ................................................................................................................. 11
1.3.4. Ágil Unified Process ............................................................................................. 14
1.4. Conclusiones del estudio de las metodologías y procesos de desarrollo ................... 16
1.5. CMMI: Áreas claves en el Proceso de desarrollo de software .................................... 17
1.6. Estructura de CMMI .................................................................................................... 18
1.7. Gestión del Ciclo de Vida de las Aplicaciones ALM. .................................................... 21
1.8. Actividades dentro de ALM. ........................................................................................ 22
1.9. Disciplinas dentro de ALM........................................................................................... 24
1.10. Beneficios ALM ........................................................................................................ 26
1.11. Herramientas para la administración del Proceso de Desarrollo de Software ....... 27
1.11.1. Rational Team Concert 3.0 (RTC). ....................................................................... 27
1.11.2. MKS Integrity. ...................................................................................................... 28
1.11.3. HP ALM 11. .......................................................................................................... 30
1.11.4. Micro Focus (Borland Division) Plataforma Open ALM. ...................................... 31
1.11.5. Oracle Team Productivity Center ........................................................................ 32
1.11.6. Visual Studio Team Foundation Server 2010 (TFS). ............................................ 33
1.12. Aspectos a tener en cuenta para la selección de la herramienta ALM ................... 36
1.13. Conclusiones............................................................................................................ 38
2. Entorno para el desarrollo de software en el CITI ............................................................. 40
2.1. Introducción ................................................................................................................ 40
2.2. Entorno de desarrollo ................................................................................................. 40
2.3. Modelo para el proceso de desarrollo de software del CITTI ..................................... 42
2.3.1. Disciplina Modelado ............................................................................................ 43
2.3.2. Flujo de trabajo de la Disciplina Modelado ......................................................... 43
2.3.3. Actividades Disciplina Modelado ........................................................................ 44
2.3.4. Artefactos Disciplina Modelado .......................................................................... 50
2.3.5. Disciplina Implementación .................................................................................. 52
2.3.6. Actividades Disciplina Implementación .............................................................. 52
2.3.7. Artefactos Disciplina Implementación ................................................................ 56
2.3.8. Disciplinas Prueba ............................................................................................... 58
2.3.9. Actividades Disciplinas Prueba ............................................................................ 58
2.3.10. Artefactos Disciplina Prueba ............................................................................... 65
2.3.11. Disciplina Despliegue........................................................................................... 65
2.3.12. Actividades Disciplina Despliegue ....................................................................... 66
2.3.13. Artefactos Disciplina Despliegue ......................................................................... 69
2.4. CMMI en el CITI ........................................................................................................... 69
2.5. Alineación del proceso definido para el CITI con CMMI ............................................. 71
2.6. Conclusiones................................................................................................................ 73
3. Herramienta de soporte al proceso de desarrollo de software en el CITI ........................ 74
3.1. Introducción ................................................................................................................ 74
3.2. Modificación de la Plantilla de TFS según las necesidades del CITI ............................ 74
3.2.1. Elementos de Trabajo. ........................................................................................ 76
3.2.2. Reportes. ............................................................................................................. 80
3.2.3. Modificaciones al Portal del Proyecto................................................................. 80
3.2.4. Áreas e Iteraciones. ............................................................................................. 81
3.2.5. Mapeo entre los campos de los elementos de trabajo y los campos del
Microsoft Project................................................................................................................. 81
3.3. Estructura organizativa dentro de TFS. ....................................................................... 82
3.4. Estructura dentro del Repositorio Control de Versiones ............................................ 83
3.4.1. Políticas de Check-in............................................................................................ 85
3.5. Construcciones ............................................................................................................ 87
3.5.1. Arquitectura de Team Build ................................................................................ 87
3.5.2. Mecanismos para la ejecución de las construcciones......................................... 88
3.5.3. Despliegue del Servidor de Compilación ............................................................. 89
3.5.4. Estrategia para las build. ..................................................................................... 90
3.6. Despliegue. .................................................................................................................. 93
3.6.1. Requisitos de hardware....................................................................................... 93
3.7. Flujo Básico.................................................................................................................. 94
3.8. Alineación de TFS con las vistas de Proceso de CMMI en el contexto del CITI ........... 95
3.9. Conclusiones................................................................................................................ 97
4. Conclusiones ....................................................................................................................... 98
5. Recomendaciones ............................................................................................................. 100
6. Referencias Bibliográficas ................................................................................................. 101
7. Glosario de Siglas y Términos ............................................................................................ 107
Índice de Figuras
Figura 1 Capas de la Ingeniería de Software ................................................................................. 6
Figura 2Proceso Unificado de Rational ......................................................................................... 8
Figura 3 Ciclo de vida del Proceso XP .......................................................................................... 10
Figura 4 Ciclo de vida del Proceso SCRUM .................................................................................. 14
Figura 5 Ciclo de vida del proceso unificado ágil ........................................................................ 15
Figura 6 Componentes de modelo CMMI ................................................................................... 19
Figura7 Actividades dentro de ALM. ........................................................................................... 23
Figura 8 Disciplinas dentro de ALM ............................................................................................. 25
Figura 9 Flujo de actividades de la Disciplina Modelado. ........................................................... 43
Figura13 Definiciones de tipos de WI en la Plantilla de Procesos............................................... 76
Figura 14 Visualización de los documentos en el Portal del Proyecto. ....................................... 81
Figura 15 Estructura dentro del repositorio de código fuente del CITI. ..................................... 84
Figura 16Politicas de Check-in de TFS. ........................................................................................ 86
Figura 19 Arquitectura de Team Build ........................................................................................ 88
Figura 20 Propuesta de arquitectura de compilación para el CITI. ............................................. 90
Figura 21 Ventana de selección de tipo de build para realizar una definición. .......................... 90
Figura 22 Formulario de visualización de la ejecución de una build. .......................................... 92
Figura 23 Despliegue de TFS en el CITI ........................................................................................ 93
Figura 24 Flujo básico de TFS ..................................................................................................... 94
Índice de Tablas
Tabla 1: Aspectos de selección para la herramienta ALM .......................................................... 38
Tabla 2: Vistas de Procesos CMMI vs Manual para el desarrollo de Software ........................... 72
Tabla 3 Vistas de Procesos CMMI en el CITI vs áreas de TFS ...................................................... 96
Introducción
Introducción
El Complejo de Investigaciones Tecnológicas Integradas (CITI1) es una entidad de
nueva creación donde se desarrollan proyectos de software, los cuales deben
realizarse con una buena organización, para esto es importante sentar las bases en
cuanto a la formalización de un proceso a seguir que garantice la calidad de los
distintos proyectos que ahí se desarrollen.
Se hace necesario destacar que este entorno de desarrollo presenta características

peculiares, vale destacar que tanto los Líderes de Proyecto (LP 2 ), como los
especialistas y desarrolladores (en este caso estudiantes) pueden faltar al proyecto ya
sea por problemas docentes o sencillamente porque se termine su período en dicha
entidad.
El desarrollo de aplicaciones informáticas es cada vez más complejo y se encuentra

influenciado por múltiples factores. La necesidad de responder con aplicaciones que
tengan la calidad requerida, cumpliendo con el cronograma y presupuesto planificado,
es un requerimiento del desarrollo de software a nivel internacional.
Es abrumadora la cantidad de paradigmas, tecnologías y herramientas que existen y

se emplean para el desarrollo de software. Existes diversas propuestas que
constituyen robustas alternativas para los equipos de desarrollo en entornos
empresariales. Entre las más utilizadas están: Scrum, Programación Extrema (por sus
siglas en inglés XP3), Proceso Unificado Ágil (por sus siglas en inglés AUP4), Proceso
Unificado de Rational (por sus siglas en inglés RUP5) entre otras.
Hasta hace pocos años, un desarrollador de software que quisiera utilizar

herramientas para todo el ciclo de vida, tenía que recurrir a muchas herramientas
diferentes, que se ejecutaban de forma independiente, y no se comunicaban entre sí.
Esto nos llevaba al escenario de que, al mismo tiempo era necesario tener cuatro o
cinco aplicaciones abiertas (un IDE6, un controlador de versiones, el repositorio de
requerimientos y una consola para depurar, entre otros), esto trae consigo grandes
inconvenientes. [Jones,2010]
En los últimos años los proveedores de herramientas han mejorado muchísimo las
capacidades de integración entre herramientas e incluso existen herramientas que
cubren y dan soporte en su totalidad al ciclo de vida del software, y otras resuelven
este tema mediante Plugins7 que las comunican entre sí. Una aplicación de gestión de
ciclo de vida del software es una suite de potentes herramientas que puede servir
1
como un activo valioso para cualquier organización con operaciones intensivas de
desarrollo. Con estas soluciones, las compañías que diseñan y desarrollan software
aseguran que las aplicaciones que desarrolla sean más efectivas dirigidas a las
necesidades de los clientes y permitan el logro los objetivos. [Business-
Software,2011a]
Las herramientas ALM8 pueden simplificar, automatizar y mejorar todas las fases del
desarrollo de software, incluida la definición de requisitos, estructuración y seguimiento
del flujo de trabajo, modelado y diseño de la solución, la escritura y programación de
código, gestión del cambio y versiones, así como las pruebas y aseguramiento de la
calidad. Con esta solución las empresas pueden gestionar con más eficacia, controlar
y brindar un seguimiento de la forma en que sus programas se construyen,
implementan y utilizan, así como las técnicas utilizadas para desarrollarse y adaptarse
en el tiempo. Esto les concede la agilidad que necesitan para responder de forma
inmediata a las demandas cambiantes de los clientes, o la dirección de las nuevas
necesidades del negocio, tan pronto como se produzcan. [Business-Software,2011a]
Existen muchas herramientas ALM, según [Business-Software,2011b]

[Pronschinske,2009] [Gartner,2011] los productos más notables en esta área son: HP
ALM 11 de la División de Software HP, Visual Studio ALM con TFS 2010 (TFS) de
Microsoft, Rational Team Concert 3.0 de la compañía IBM, MKS Integrity de MKS Inc.
y Microfocus (Borland) con su plataforma Open ALM.
Todos estos elementos dan origen al problema que ocupa la presente investigación.
El problema de esta investigación se expresa en la pregunta siguiente ¿Es posible

definir un entorno homogéneo para el desarrollo de proyectos de software en el CITI?
El objeto de estudio lo constituyen los procesos de desarrollo de software,

específicamente las diferentes metodologías para el desarrollo de software, las
actividades y disciplinas dentro de la Administración del Ciclo de Vida del Software y
las herramientas que le dan soporte a éste.
El campo de acción es el desarrollo de proyectos de software en las condiciones del

CITI.
Objetivo General
Proponer un entorno para el desarrollo de los proyectos de software en el CITI.
2
Objetivos específicos
¾ Definir las disciplinas para el desarrollo de proyectos de software adecuado a

las condiciones del CITI.
¾ Proponer una herramienta, de Administración del Ciclo de Vida del Software,

que de soporte al proceso de desarrollo definido y se integre con el resto de las
herramientas utilizadas en el CITI.
Para cumplir con los objetivos planteados se han definido las siguientes Tareas:
¾ Analizar las potencialidades de los Metodologías Ágiles y RUP para identificar

cual será aplicada en el CITI.
¾ Estudiar los paradigmas actuales para el desarrollo de software.
¾ Estudiar un conjunto de áreas claves en los procesos de desarrollo de

software.
¾ Caracterizar el entorno desarrollo para el cual se propone la investigación.
¾ Identificar herramientas que de soporte a la administración del ciclo de vida del

software.
¾ Definir una arquitectura donde se integre la herramienta seleccionada y las

existentes en la organización.
¾ Entrevistar a los jefes de proyecto para entender las características de estos.
¾ Estudiar el CITI y las condiciones en que se trabaja en la organización.
¾ Clasificar los proyectos del CITI, según sus características.
¾ Estudiar las metodologías y procesos de desarrollo de software existentes.
¾ Realizar un estudio del estado del arte de las herramientas que intervienen en
la administración del ciclo de vida del software.
¾ Seleccionar una herramienta de acuerdo a los criterios de comparación que se

adecue a las características de la institución.
¾ Identificar que procesos o actividades dentro del ciclo de vida se van a

administrar con esta herramienta.
¾ Integrar la herramienta con las soluciones existentes en el centro.
¾ Documentar la solución propuesta.
El presente trabajo está formado por introducción, tres capítulos, conclusiones,

recomendaciones y bibliografía. El primer capítulo, Fundamentos Teóricos, muestra
3
las metodologías y procesos de desarrollo seleccionados para su análisis. Son
documentadas sus principales características, donde se identifican elementos
importantes a incorporar en la elaboración de la propuesta. Se hace un estudio sobre
la administración del ciclo de vida del software. Se realiza un estudio sobre las
herramientas que se utilizan para este proceso, finalizando con la selección de una de
ellas.
En el segundo capítulo denominado Entorno para el desarrollo de software en el CITI,

se detallan las disciplinas Modelado e Implementación, Prueba y Despliegue
pertenecientes a la propuesta, mostrando sus flujos de trabajo. Se describen las
actividades, algunos artefactos, un conjunto de buenas prácticas a considerar; además
se proporcionan plantillas, guías de construcción y listas de chequeo.
En el tercer capítulo se exponen la configuración y personalización de la herramienta

seleccionada en aras de adaptarla al flujo de trabajo actual de la organización. Se
mencionan los requerimientos de hardware necesarios para la adopción de la
herramienta. Además se proponen un conjunto de buenas prácticas y estrategias para
algunas de las fases del ciclo de vida del software.
Como parte de la definición de este proceso de desarrollo de software se realizaron

dos tesis de pregrado tituladas “Administración del Ciclo de Desarrollo de Software en
los proyectos informáticos del CITI” y “Propuesta de Desarrollo de Proyectos
Informáticos para las condiciones del CITI” las cuales sentaron las bases para el
desarrollo de este trabajo.
4
Procesos de Desarrollo de Software
1. Procesos de Desarrollo de Software

1.1. Introducción
La Ingeniería de Software se sustenta en una estrecha relación entre los métodos y las
herramientas para lograr que las tareas de desarrollo sean exitosas. Por tanto se hace
necesario, la revisión de las metodologías, herramientas y tecnologías existentes que
le den soporte al Proceso de Desarrollo se Software (PDS9).
En este capítulo se presenta un estudio de conceptos esenciales en la ingeniería de

software, así como metodologías y herramientas que dan soporte al proceso de
desarrollo de software. Se lleva a cabo una comparación entre RUP como metodología
de desarrollo ampliamente utilizada y reconocida, con los Métodos Ágiles que cuentan
hoy con amplia popularidad. Se realiza un análisis de las principales herramientas
sobre las que se apoya el proceso de desarrollo de software así como aspectos a
tener en cuenta para su elección.
1.2. Proceso de desarrollo de software
Como se define en [Pressman,2002b] “Cuando se trabaja para construir un producto o

un sistema, es importante seguir una serie de pasos predecibles -un mapa de
carreteras que ayude a obtener el resultado oportuno de calidad-. El mapa de
carreteras a seguir es llamado Proceso del Software...”. “El PDS juega un papel
primordial en el éxito o fracaso que se pueda obtener…sin una guía adecuada no se
llega a ningún lugar correcto.”
Sea cual fuere el PDS que se adopte en una organización es importante destacar que
éste debe ser adaptado a las necesidades y condiciones del entorno de desarrollo y a
las características del software que se pretende desarrollar; también entran en
valoración las características del cliente o usuario de la futura solución así como las
relaciones que se establezcan entre estos últimos y el entorno de desarrollo
[Pressman,2002b]. Es una realidad el hecho de que no existen PDS malos sino malas
prácticas.
La Ingeniería del software (IS10) es una tecnología multicapa como muestra la Figura 1
tomada [Pressman,2002b]
5
Figura 1 Capas de la Ingeniería de Software
Conjunto de pasos y procedimientos que deben seguirse para el desarrollo del

software es el concepto más usado para definir las Metodologías de Desarrollo.
[Pressman,2002b]
Algunos autores definen las metodologías como un conjunto de procedimientos,

técnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a
realizar nuevo software
Una metodología debería definir con precisión los artefactos11, roles12 y actividades13
involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la
metodología al proyecto, guías para uso de herramientas de apoyo etc.
1.3. Metodologías de Desarrollo de software
La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la

diversidad de propuestas y diferencias en el grado de detalle, información disponible y
alcance de cada una de ellas. A grandes rasgos, si se toman como criterio las
notaciones utilizadas para especificar artefactos producidos en actividades de análisis
y diseño, podemos clasificar las metodologías en dos grupos: Metodologías
Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su
filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y
control del proyecto, en especificación precisa de requisitos y modelado, reciben el
nombre de Metodologías Tradicionales. [Méndez,2008] Otras metodologías,
denominadas Metodologías Ágiles, están más orientadas a la generación de código
con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños,
hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e
involucran activamente al cliente en el proceso. [Agile Alliance,2008; Alliance,2008]
La metodología de desarrollo que se siga en un PDS tiene un factor de peso

fundamental en el éxito o fracaso que se pueda tener. Particularmente, en la
fabricación de un producto de software, “…el desarrollo de software es una actividad
6
caótica a menudo caracterizada por la frase Codificar y Arreglar.” [Fowler,2001a;

2001b] La metodología pretende dar una guía a los desarrolladores en el medio de
este caos.
Existe un movimiento que se ha dado a conocer como la “Alianza Ágil” o “Movimiento

Ágil”[Agile Alliance,2008]. Este cuenta ya con un número grande de miembros y se ha
tornado frecuente el empleo del término “Desarrollo Ágil de Software” (a partir de
ahora se hará referencia al mismo como Desarrollo Ágil). Se han definido un conjunto
de metodologías que buscan proporcionar agilidad al PDS, sobre la base de reglas y
prácticas audaces, conocidas como Metodologías Ágiles, entre las cuales ha ganado
relevancia eXtreme Programming y SCRUM.
1.3.1. Proceso Unificado de Rational
“El Proceso Unificado de Racional es más que un simple proceso; es un marco de

trabajo genérico que puede especializarse para una gran variedad de sistemas de
software, para diferentes áreas de aplicación, diferentes tipos de organizaciones,
diferentes niveles de aptitud y diferentes tamaños de proyectos.”[Ivar Jacobson,2000]
RUP Utiliza el Lenguaje Unificado de Modelado (UML 14 ) para preparar todos los
esquemas de un sistema de software. De hecho UML es parte esencial del proceso.
[James Rumbaugh,1999]
Provee un enfoque para asignar tareas y responsabilidades dentro de una

organización de desarrollo. Su objetivo es asegurar la producción de software de alta
calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto
previsible.
RUP puede ser ajustado y aplicado de disímiles maneras y ésta bondad a veces
provoca que se haga mal, generalmente abusando de la gran variedad de artefactos
que contempla y por tanto enlenteciendo el desarrollo. Vale destacar que existen
disimiles bibliografía que exponen las potencialidades de RUP para ser usado de
manera ágil.[Corporation,2002]
El proceso puede ser descrito en dos dimensiones a lo largo o en los dos ejes
[Kruchten,2001] como se muestra en la Figura 2 tomada de [Rational,2003]
¾ El eje horizontal representa el tiempo y muestra los aspectos dinámicos del

proceso como pueden ser ciclos de vida, fases iteraciones e hitos.
7
¾ El eje vertical representa los aspectos estáticos del proceso como la

descripción en términos de actividades, artefactos trabajadores y flujo de
trabajo.
Figura 2Proceso Unificado de Rational
En la Figura 2 se puede apreciar que RUP se divide en cuatro fases:[Per Kroll,2003]
¾ Inicio: Durante esta fase se establece el alcance y los límites del sistema, Se
describen las necesidades de los clientes. Se identifican los casos de uso
críticos del sistema, se identifica una propuesta de arquitectura y se estima el
costo y esfuerzo del proyecto entre otras.
¾ Elaboración: Tiene como propósito analizar el dominio del problema, definir la

arquitectura base del sistema para proveer una base estable al esfuerzo de
diseño e implementación en la fase de construcción, se define el plan de
desarrollo. Se establece la infraestructura y soporte del sistema. La
arquitectura evoluciona hasta los requerimientos más significativos y a
estabilizar el riesgo. La estabilidad de la arquitectura se evalúa a través de
prototipos.
¾ Construcción: En esta fase se desarrollan, se integran y se prueban todos los

componentes da la aplicación. RUP considera ésta fase como un proceso de
8
manufacturado donde el énfasis lo hace en la administración de los recursos,

control de los costos, planificación y la calidad del sistema. Uno o más
entregables son hecho durante esta fase antes de pasar a la entrega del
producto final.
¾ Transición: Se centra en asegurar la disponibilidad del producto, esta fase

puede abarcar varias iteraciones e incluye pruebas y preparación del producto
que se va a liberar. Se hacen algunos ajustes al sistema basados en la
retroalimentación con los usuarios. Los clientes se centra en el refinamiento del
producto, configuración e instalación del mismo.
RUP provee una guía para los miembros del equipo de desarrollo de software en
cuanto a las actividades y artefactos de los cuales son responsables en función del rol
o roles que desempeñan dentro del equipo. En otro sentido RUP provee para los
Ingenieros de Proceso una guía de cómo definir, configurar e implementar los
procesos de ingeniería para resolver problemas concretos. [Rational,2003]
Finalmente se puede agregar que existe toda una familia de productos en torno a
RUP, que ayudan a los miembros del Equipo de Desarrollo (ED15) a llevar a cabo sus
diversas actividades, siempre y cuando deseen involucrar dichas herramientas en su
proceso específico. La descripción detallada de estas herramientas se puede
encontrar en [Rational,2003]
1.3.2. eXtreme Programming
La programación extrema se basa en la simplicidad, la comunicación y el reciclado

continuo de código. Los objetivos de XP son muy simples: la satisfacción del cliente.
Esta metodología trata de dar al cliente el software que él necesita y cuando lo
necesita. El segundo objetivo es potenciar al máximo el trabajo en grupo. Tanto los
jefes de proyecto, los clientes y desarrolladores, son parte del equipo y están
involucrados en el desarrollo del software. [Kent Beck 2000b]
Su ciclo de vida consta de 6 etapas: exploración, planificación, iteraciones,

producción, mantenimiento y muerte. En dichas etapas intervienen diferentes roles y
se llevan a cabo prácticas como la programación en parejas, las pruebas y el cliente
presente, entre otras. [Pekka Abrahamssom,2002]
Como se muestra en la Figura 3 tomada de [Pekka Abrahamssom,2002]
9
Figura 3 Ciclo de vida del Proceso XP
A continuación se describen las etapas definidas en XP [Kent Beck 2000a]
¾ Exploración: Es donde se gana confianza en las herramientas que se

utilizarán, los miembros del ED se conocen y aprenden a confiar unos en otros.
Durante esta fase los programadores deben estimar cada tarea de
programación en la que hayan sido divididas las historias de usuario, mientras
los clientes van escribiendo las historias de usuarios.
¾ Planificación: El objetivo de la fase de planificación es que el cliente y el ED

lleguen a una serie de acuerdos y se elabore el plan de entrega. En esta fase
el cliente asigna prioridad a las historias de usuario, se estima el costo total del
sistema, el alcance de las entregas y para qué fecha culminará.
¾ Iteraciones: Esta fase incluye varias iteraciones antes de que se libere la

primera versión del software. El plan de entrega se divide en diferentes planes
de iteración. Cada iteración puede tener de una a cuatro semanas de duración.
De la primera iteración se obtendrá la arquitectura del futuro sistema.
¾ Producción: Requiere de pruebas y chequeos de funcionamiento y

rendimiento del sistema antes de ser liberado a los clientes. Durante esta fase
las iteraciones deben dinamizarse, duran entre una y tres semanas. Las
nuevas ideas y sugerencias se posponen, y se documentan para ser
implementadas en la fase de mantenimiento.
10
¾ Mantenimiento: En esta fase, después de que el sistema pasó la fase de

producción la velocidad de desarrollo tiende a disminuir. Esta fase requiere de
un cambio en el equipo desarrollo y en su estructura.
¾ Muerte: En esta fase el cliente debe quedar satisfecho con el trabajo realizado
y no escribir ninguna otra historia de usuario. Se procede a escribir la
documentación del sistema si no va a haber más cambios en la arquitectura, ni
en el código.
XP, delega una gran responsabilidad en las pruebas del software, por lo que se dice
que sigue un desarrollo dirigido por pruebas (TDD16), de tal manera que se asegura la
calidad del producto según los requisitos capturados durante el desarrollo. [Kent Beck
2000a; 2000b]
Los creadores de XP aseguran el éxito de esta metodología en proyectos de alto

riesgo, con una fecha de terminación fija, en los cuales el equipo de desarrollo no
tenga una experiencia anterior similar e incluso en proyectos innovadores; plantean
que XP ha sido creada para mitigar esos riesgos e incrementar la posibilidad de éxito.
[Smith,2001]
Los ED de XP deben ser pequeños, de entre 2 y 10 personas puesto que se defiende

la idea de que en proyectos de alto riesgo y con requisitos muy cambiantes resulta
imposible manejar ED muy grandes.[Kent Beck 2001; 2000b]
1.3.3. SCRUM
Desarrollado por Ken Schwaber, Jeff Sutherland y Mike Vedle en 1989. Define un
marco para la gestión de proyectos. Está especialmente indicado para proyectos con
un rápido cambio de requisitos. Es un proceso de software iterativo utilizado
comúnmente en entornos basados en el desarrollo ágil de software, en el que se
aplican de manera regular un conjunto de mejores prácticas para trabajar en equipo y
obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a
otras y su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.[Schwaber,2005]
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que

puede tomarse como punto de partida para definir el proceso de desarrollo que se
ejecutará durante un proyecto. Los roles principales en Scrum son el “ScrumMaster”,
que mantiene los procesos y trabaja de forma similar al director de proyecto, el
11
“ProductOwner”, que representa a los stakeholders (clientes externos o internos), y el

“Team” que incluye a los desarrolladores.[Schwaber,2005]
Durante cada sprint, un periodo entre 15 y 30 días (la magnitud es definida por el
equipo de desarrollo), el equipo de desarrollo crea un incremento de software
potencialmente entregable (utilizable). El conjunto de características que forma parte
de cada sprint viene del “ProductBacklog”, que es un conjunto de requisitos de alto
nivel priorizados que definen el trabajo a realizar. Los elementos del “ProductBacklog”
que forman parte del sprint se determinan durante la reunión de “Sprint Planning”.
Durante esta reunión, el “ProductOwner” identifica los elementos del “ProductBacklog”
que quiere ver completados y los hace del conocimiento del equipo. Entonces, el
equipo determina la cantidad de ese trabajo que puede comprometerse a completar
durante el siguiente sprint. Durante el sprint, nadie puede cambiar el “Sprint Backlog”,
lo que significa que los requisitos están congelados durante el sprint.[Pete
Deemer,2007]
Las actividades que se llevan a cabo en Scrum son las siguientes:[Pekka

Abrahamssom,2002]
Planificación de la iteración: El primer día de la iteración se realiza la reunión de

planificación de la iteración. Tiene dos partes:
9 Selección de requisitos (4 horas máximo). El cliente presenta al equipo

la lista de requisitos priorizada del producto o proyecto. El ED pregunta
al cliente las dudas que surgen y selecciona los requisitos más
prioritarios que se compromete a completar en la iteración, de manera
que puedan ser entregados si el cliente lo solicita.
9 Planificación de la iteración (4 horas máximo). El equipo elabora la lista

de tareas de la iteración necesarias para desarrollar los requisitos a que
se ha comprometido. La estimación de esfuerzo se hace de manera
conjunta y los miembros del equipo se auto asignan las tareas.
¾ Ejecución de la iteración: Cada día el equipo realiza una reunión de

sincronización (15 minutos máximos). Cada miembro del equipo inspecciona el
trabajo que el resto está realizando (dependencias entre tareas, progreso hacia
el objetivo de la iteración, obstáculos que pueden impedir este objetivo). En la
reunión cada miembro del equipo responde a tres preguntas:
12
9 ¿Qué he hecho desde la última reunión de sincronización?
9 ¿Qué voy a hacer a partir de este momento?
9 ¿Qué impedimentos tengo o voy a tener?
9 Cada iteración incluye las fases tradicionales del desarrollo de software

(requisitos, análisis, diseño, implementación y su entregable). La
arquitectura y diseño del sistema evolucionan durante el desarrollo de
cada iteración. Una iteración dura entre una semana y un mes.
¾ Inspección y adaptación: El último día de la iteración se realiza la reunión de

revisión de la iteración. Tiene dos partes:
9 Demostración (4 horas máximo). El equipo presenta al cliente los

requisitos completados en la iteración, en forma de incremento de
producto preparado para ser entregado con el mínimo esfuerzo. En
función de los resultados mostrados y de los cambios que haya habido
en el contexto del proyecto, el cliente realiza las adaptaciones
necesarias de manera objetiva.
9 Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su

manera de trabajar y cuáles son los problemas que podrían impedirle
progresar adecuadamente, mejorando de manera continua su
productividad.
A continuación se muestra la Figura 4 donde se puede apreciar el ciclo de vida del

proceso.[Pekka Abrahamssom,2002]
13
Figura 4 Ciclo de vida del Proceso SCRUM
1.3.4. Ágil Unified Process
El Proceso Unificado Ágil es una versión simplificada de RUP [Ambysoft,2009]

Describe un acercamiento simple, fácil de entender para aplicación comercial en vías
de desarrollo usando técnicas ágiles. El AUP es una mezcla entre XP y RUP,
adoptando muchas de las técnicas ágiles de XP y otros procesos ágiles pero
reteniendo una parte de la formalidad del RUP [Prabhudas,2007]. La Figura 5 tomada
de [Ambysoft,2009] describe el ciclo de vida del AUP, como se aprecia las disciplinas
se han alterado. La disciplina de Modelación en AUP abarca el modelo del negocio, los
requerimientos y las disciplinas de análisis y diseño de RUP, por lo tanto el modelado
es una parte importante del AUP. Por otra parte la gestión de la configuración y la
gestión del cambio de RUP son ahora la disciplina Gestión de la Configuración la cual
no hace énfasis en el cambio, se centra fundamentalmente en el uso de una estructura
de directorios estándar y de un esquema de numeración de versión.[Ambysoft, 2009]
14
Figura 5 Ciclo de vida del proceso unificado ágil
Las disciplinas del AUP son realizadas de una manera iterativa, definiendo las
actividades que el equipo de desarrollo ejecuta para construir y validar el software
funcional que cumpla con las necesidades del usuario. En comparación con las
disciplinas de RUP que son 9, el AUP tiene solamente 7 las cuáles algunas son
combinaciones de dos disciplinas del RUP.[Prabhudas,2007]
¾ El modelo: La meta de esta disciplina es entender el negocio de la

organización, el dominio del problema que el proyecto aborda e identificar una
solución viable para abordar el dominio del problema. Además de iniciar el
modelado de requerimientos de alto nivel.
¾ La implementación: La meta de ésta disciplina es transformar el modelo en

código ejecutable y llevar a cabo un nivel básico de las pruebas.
¾ La prueba: La meta de ésta disciplina es ejecutar una evaluación de los

objetivos para asegurar la calidad. Esto incluye encontrar defectos, validar que
el sistema funciona como fue diseñado y verificar que los requerimientos están
completos.
¾ Despliegue: La meta de ésta disciplina es planificar la entrega del sistema y

ejecutar el plan para que el sistema esté disponible para los usuarios finales.
15
¾ La Administración de Configuraciones: La meta de ésta disciplina es

administrar el acceso a los entregables o productos del proyecto. Esto incluye
no sólo el rastreo de versiones del producto en el tiempo, sino que también
incluye controlar y administrar los cambios que ocurran.
¾ La Administración del Proyecto: La meta de ésta disciplina es dirigir las

actividades que se llevan a cabo en el proyecto. Esto incluye administración del
riesgo, la dirección de personas (asignar tareas, seguimiento de los procesos,
etc.), y coordinar con los sistemas y personas fuera del alcance del proyecto
para que el este termine a tiempo y dentro del presupuesto.
¾ El ambiente o entorno: La meta de ésta disciplina es apoyar el resto de los

esfuerzos por garantizar que, el proceso adecuado, la orientación (normas y
directrices) y herramientas (hardware, software, etc.) estén disponibles para el
equipo según sea necesario.
Al igual que las metodologías ágiles, AUP presenta características como la

programación en parejas, TDD, de tal manera que se asegura la calidad del
producto.[Mark Lines,2008]
AUP además se caracteriza por crear incrementos de software potencialmente

entregable, el énfasis a las personas, la comunicación con el cliente, la elaboración de
software orientado a los servicios de las empresas, la respuesta al cambio y no hace
enfatiza en la documentación del sistema.[Prabhudas,2007]
1.4. Conclusiones del estudio de las metodologías y procesos de

desarrollo
Después de haber realizado el estudio de las metodologías y procesos de desarrollo,

en cuestión, se puede concluir que poseen ventajas y desventajas. Por ejemplo,
algunas de las ventajas presentes en Scrum son: la entrega de un producto funcional
al culminar cada sprint (iteración), la visualización del proyecto día a día, además de
un alcance acotado y viable. Scrum resulta fácil de aprender y requiere muy poco
esfuerzo para comenzarse a utilizar. A pesar de las ventajas que posee, también
presenta algunas desventajas teniendo en cuenta las características del entorno del
CITI como son: su utilización en proyectos a corto plazo, no es adecuado para todos
los proyectos, ya que es recomendable que se lleve a cabo en equipos pequeños. Otro
16
de los inconvenientes, es que todos los miembros del equipo de desarrollo deben
poseer gran experiencia, ya que la agilidad está determinada por las habilidades de
cada uno de los integrantes del equipo de desarrollo [Beck, 2001]. De igual manera,
mediante el uso de casos de prueba XP permite una disminución de los errores,
además de que garantiza la satisfacción del cliente, ya que este posee una
participación activa durante todo el proceso [Beck, 1999b]. Al igual que Scrum, XP no
debe ser utilizada por equipos de más de 10 personas, a menos que se utilice una
variante de XP con Scrum [Sutherland Victorov &Blount., 2006]. XP es más bien
utilizado cuando los requisitos son inciertos y cambiantes. En resumen, se puede decir
que XP y Scrum, al ser metodologías ágiles, poseen características comunes. Un
ejemplo de esto, es el enfoque en las personas y los resultados. Existe un estrecho
vínculo entre el cliente y el equipo de trabajo, ya que el cliente tiene una amplia
participación en todo el desarrollo del producto [Kent, 2001]. También las
metodologías ágiles utilizan herramientas que apoyan el desarrollo dirigido por
pruebas, la integración continua, así como herramientas para el trabajo en equipo,
además de que cuentan con una infraestructura ya establecida.
Como se explica a lo largo de este capítulo, RUP constituye la base sobre la cual se
desarrolla la propuesta; la cual enfatiza en sus principios y buenas prácticas. Además,
es la que posee un alto nivel de conocimiento y experiencia por parte de los miembros
de equipo de desarrollo. AUP es una versión ágil de RUP, por lo que su uso en la
organización constituye un avance en el desarrollo de los proyectos, ya que toma
elementos ágiles, pero retiene parte de la formalidad de RUP. Una de los aspectos a
tener en cuenta en RUP, es que se recomienda que sea personalizado, es decir,
definir las actividades y artefactos a desarrollar. Con respecto a esto, AUP define las
actividades y artefactos a tener en cuenta en el desarrollo de los proyectos, lo que trae
consigo que el proceso se realice de manera organizada en cada uno de estos. Los
elementos expuestos garantizan de alguna manera dar agilidad en el proceso de
desarrollo de la organización.
1.5. CMMI: Áreas claves en el Proceso de desarrollo de software
El conjunto de prácticas de software y el manejo específico de los niveles de madurez

son llamadas Áreas Claves del Proceso(KPA17 por sus siglas en ingles).[Piattini,2007]
Tradicionalmente la IS se ha centrado en metodologías y lenguajes de programación,

modelo de desarrollo y herramientas. Sin embargo teniendo en cuenta la creciente
17
complejidad de los sistemas se hacía necesario incluir determinadas áreas que hoy en
día son críticas para la IS.
CMMI18 es una evolución de CMM, que surge debido a la necesidad de integrar: los
modelos de madurez de la capacidad de software, ingeniería de sistemas y desarrollo
integrado de programas. El objetivo principal de dicho modelo es ayudar a las
organizaciones a mejorar su capacidad para entregar los productos a sus clientes.
CMMI puede utilizarse para mejorar toda la organización o un subconjunto de

esta[SEI,2006], brinda la posibilidad de encaminar esfuerzos hacia la mejora continua
y la evolución de software utilizando dos representaciones diferentes: 1) continua y 2)
escalonada. Ambas representaciones conducen a un fin común. [SEI,2006] [Piattini,
2007]
1.6. Estructura de CMMI
El modelo CMMI define que deben existir áreas o procesos claves en la organización.
Las áreas de proceso son un conjunto de prácticas relacionadas que ejecutadas
colectivamente satisfacen un conjunto de metas consideradas importantes para
realizar mejoras significativas en esa área. Estas Metas u Objetivos son definiciones
de resultados a obtener por la implementación efectiva de los grupos de prácticas y
pueden estar definidas en Genéricas y Específicas. Las Prácticas tienen esta misma
clasificación, las cuales son acciones a realizar para cumplir objetivos de las áreas de
procesos. [Shrum,2009]
Existen 22 áreas de proceso distribuidas a lo largo de los niveles del 2-5, estas están
compuestas como se muestra en la Figura 6. Para obtener una descripción de cada
uno de los elementos de la Figura 6 dirigirse a [SEI,2006]
18
Figura 6 Componentes de modelo CMMI
¾ Metas u Objetivos Específicos: Corresponden a un área de proceso y

direccionan a características únicas que deben ser implementadas para
satisfacer los objetivos de ésta.
¾ Prácticas Específicas: Define las actividades para conseguir la meta específica

asociada.
¾ Productos de trabajo típicos: Provee ejemplos de las salidas desde una

práctica específica o una genérica.
¾ Sub prácticas: Son descripciones detalladas que proveen guías para interpretar
prácticas específicas o genéricas.
¾ Meta Genérica: Se definen genéricas debido a que la misma descripción

aparece en múltiples áreas de proceso.
¾ Prácticas Genéricas: Proveen un marco de trabajo institucionalizado para

asegurar que los procesos asociados con las áreas de procesos puedan ser
efectivos, repetibles y duraderos.
¾ Declaración de propósitos: Detalla la finalidad del área de proceso.
¾ Notas introductorias del área de proceso: Describe los conceptos principales

cubiertos por el área de proceso.
19
¾ Áreas de proceso relacionadas: Refleja en una lista las relaciones de alto nivel
entre las áreas de proceso, las cuales pueden estar clasificadas por básicas y
avanzadas.
Las áreas de proceso se agrupan en cuatro categorías [SEI,2006] [Piattini,2007]:
Gestión del proceso

Agrupa todas las áreas que contienen las actividades de: definición, planificación,
despliegue, implementación, seguimiento, control, evaluación, medición y mejora de
procesos, separándolas a su vez, en básicas y avanzadas.
Gestión del proyecto

Agrupa las áreas relativas a la gestión del proyecto que cubren las actividades:
planificación, seguimiento y control del proyecto. Se clasifican igualmente en básicas y
avanzadas.
Ingeniería
Se agrupan aquí las áreas con actividades relativas al desarrollo y mantenimiento que
se ejecutan durante la ingeniería como por ejemplo la gestión de requisitos. En este
caso no se clasifican en básicas y avanzadas.
Soporte
Este grupo se compone de las áreas con actividades cuyo objetivo principal es el de
dar soporte al desarrollo y mantenimiento del producto, al igual que las dos primeras
se clasifican en básicas y avanzadas.
Los procesos siguientes son los identificados en el nivel 2 de CMMI: [CMMI, 2009]
¾ Gestión de requerimientos: Describe las actividades para obtener y controlar

los cambios a los requerimientos, y asegurar que otros planes y datos
relevantes se mantengan actualizados. Proporciona la trazabilidad de los
requerimientos desde el cliente al producto y de éste a sus componentes.
¾ Planificación del Proyecto: Comienza con los requerimientos que definen el
producto y el proyecto. Incluye el desarrollo del plan de proyecto, la
involucración de las partes interesadas de forma apropiada, la obtención de
compromisos con el plan y el mantenimiento del mismo.
¾ Monitorización y Control de proyecto: Incluye las actividades de monitorización
y toma de decisiones correctivas.
20
¾ Gestión de acuerdos con proveedores: Trata aquellas necesidades del

proyecto de adquirir las partes del trabajo que son producidas por proveedores.
¾ Medición y análisis: Guía a los proyectos y a las organizaciones durante la
alineación de las necesidades y objetivos de comprobación con una forma de
medir que proporciona resultados correctos. Éstos pueden utilizarse en la toma
de decisiones y en la toma de acciones correctivas apropiadas.
¾ Aseguramiento de la calidad de proceso y de producto: Evalúa objetivamente
los procesos, los productos de trabajo y los servicios realizados frente a las
descripciones aplicables de procesos, estándares y procedimientos, para
asegurar que cualquier problema planteado en las revisiones posea un
tratamiento adecuado.
¾ Gestión de configuración: Establece y mantiene la integridad de los productos
de trabajo utilizando la identificación, el control, los informes de estado y las
auditorías de la configuración.
1.7. Gestión del Ciclo de Vida de las Aplicaciones ALM.
La complejidad creciente del proceso de desarrollo, hace la entrega de software de

alta calidad una lucha entre gigantes, haciendo que la alta productividad dentro del
desarrollo de una aplicación sea una meta continua, el énfasis actual es lograr la mejor
integración entre diferentes fases del ciclo de vida de la aplicación, incluyendo gestión
de requerimientos, modelado, desarrollo, gestión del cambio, pruebas y despliegue.
[Lizama,2006]
ALM es un enfoque de producción, sistematización y despliegue de proyectos de

software diseñado con el objetivo de facilitar la gestión de proyectos de forma global.
[Lizama,2006]
Entre las múltiples definiciones que identifican a ALM se encuentran:
“…término usado para expresar las personas, los procesos, y las soluciones utilizadas
en la creación, gestión y distribución de software. Es un término general de todas las
fases por las que transita el software durante su existencia” [Lanowitz,2011]
“…es el proceso de controlar todo el ciclo de vida de una aplicación, desde el

momento de su definición, hasta el momento de su despliegue y mantenimiento
posterior” [Raona,2009]
21
“…es el proceso continuo de gestión de la vida de una aplicación a través del control,
el desarrollo y mantenimiento. Es la unión de la gestión empresarial a la ingeniería de
software, posible gracias a herramientas que facilitan e integran la gestión de
requisitos, arquitectura, codificación, prueba, seguimiento y gestión de versiones”
[Borland,2007; Reinboldt,2011]
Otras referencias como [Borland,2007] [IBM,2011] [MKS,2011a] [Polarion,2011]

[Rally,2011] [Seapine,2011] revisadas apuntan al mismo concepto refiriéndose a ALM
como un conjunto de procesos predefinidos y herramientas con la capacidad de
integrar, coordinar y gestionar las personas y procesos en un ciclo repetitivo de
actividades relacionadas entre sí, en las diferentes fases del proceso de desarrollo de
software, desde el inicio hasta la implementación.
La mayor parte de las organizaciones que desarrollan proyectos de software están

enfocándose en cómo aplicar estos principios a sus propios equipos de desarrollo.
[Lanowitz,2011]
1.8. Actividades dentro de ALM.
ALM incluye la gestión activa de todas las actividades relacionadas con las ideas de
negocio. Todas las empresas que desarrollan software como parte de su negocio
toman parte en el ciclo de vida de la aplicación, sin embargo muy pocas empresas
gestionan el ciclo de vida de sus aplicaciones. [NotionSolutions,2011]
La gestión del ciclo de vida de la aplicación implica la realización de una serie de
actividades que trabajan juntas para proporcionar un valor para el negocio.
[NotionSolutions,2011]
En el caso más simple, las actividades involucradas en el ciclo de vida de la aplicación
fluyen como se muestra en la Figura 7, en esta se resume el flujo entre las actividades.
Los detalles pueden variar dependiendo del proyecto o necesidades de la
organización, pero el flujo base debe ser similar. [NotionSolutions,2009a]
22
Figura 7 Actividades dentro de ALM.
La Figura 7 tomada de [NotionSolutions,2011] define la línea base de las actividades

comunes que existen en el ciclo de vida de una aplicación:
La primera actividad es la Solicitud del proyecto, en esta se capturan ideas del

negocio, demandas y peticiones, lo que constituye la base del proyecto.
Después de la aprobación de los proyectos se procede a la actividad de Planificación.

La planificación justifica cómo y cuándo un proyecto se llevará a cabo.
A continuación llega la actividad de Definición, en esta se capturan los requisitos para

el proyecto para cumplir con las solicitudes originales. Hay que tener en cuenta que
esta actividad impacta en la de Planificación.
Una vez concluida esta actividad se procede al Diseño, aquí se diseña la solución para
satisfacer los requisitos definidos.
La actividad que le sigue es Construcción, en ella se genera la solución. Durante el

proyecto, el desarrollo de la aplicación incluye implementar las soluciones de software
para satisfacer el diseño. Esta actividad también incluye la construcción de otros
artefactos, tales como casos de prueba, las pruebas unitarias, los scripts de
construcción, etc.
La Prueba es otra actividad en la cual se válida que la solución construida cumple con
los requisitos y se desempeña como se esperaba, si es así entonces se entra en la
actividad de Liberación del Software, en esta se despliega la solución en producción.
El Mantenimiento es otra actividad que tiene como objetivo mantener la solución

después de que se encuentra en producción. El mantenimiento incluye el seguimiento
23
y toda la infraestructura de apoyo y puede conducir iteraciones adicionales de la

construcción, validación y liberación de la solución.
El Retiro es la terminación del ciclo de vida de una aplicación. Esta actividad puede ser
corta y simple, pero normalmente el acto de terminar una aplicación acciona requisitos
para otras aplicaciones. El retiro de una aplicación podría conllevar un esfuerzo
considerable.
A diferencia de las actividades anteriores, la Supervisión es una actividad continua. Su

propósito es asegurar que todas las demás actividades están siguiendo las normas y
directrices. Estas normas pueden imponerse internamente debido a las políticas
corporativas (por ejemplo, CMMI o ISO).
La Administración al igual que la Supervisión, es una actividad genérica que abarca

otras actividades. Implica la coordinación y seguimiento de las actividades en contra
del plan. [NotionSolutions,2009a]
Este modelo muestra la complejidad relacionada con el ciclo de vida de la aplicación.

Cada una de estas actividades involucra a diferentes personas, se centra en diferentes
aspectos del problema. Cada actividad tiene diferentes pasos que deben llevarse a
cabo. Dependiendo de la organización, los procesos que facilitan estas actividades
pueden ser bien organizados y comprendidos o muy informales. Es común que las
empresas tengan éxito en procesos para algunas actividades, pero una falta grave en
otros, no obstante todos los procesos que se llevan a cabo para cumplir con estas
actividades son igual de importantes. La realización consiente y eficaz de todas y cada
una de estas actividades es imprescindible para la obtención de una solución con la
calidad requerida. [CHAPPELL,2010]
La industria, en general, ha creado varias disciplinas para ayudar a las empresas a

cumplir con éxito las actividades mencionadas anteriormente. Las siguientes
disciplinas forman parte de ALM: Administración del Portafolio del Proyecto, Gestión
de Proyectos, Gestión de Requisitos, Desarrollo de Aplicaciones, Control de Calidad,
Gestión del Cambio y Gestión de Operaciones. [NotionSolutions,2009b]
1.9. Disciplinas dentro de ALM.
El proceso de Gestión de Ciclo de Vida de la Aplicación se compone de muchas

disciplinas y prácticas que definen las normas de conducta para las organizaciones
exitosas. A medida que las personas adquieren más experiencias con las prácticas de
24
ALM serán más capaces de entregar soluciones más consistentes. Sin embargo, más
importante que el reconocimiento y la adopción de estas disciplinas, una exitosa
estrategia de ALM le permitirá maximizar el éxito mediante la integración de la
planificación, el seguimiento y la comunicación entre disciplinas.
[NotionSolutions,2011]
Figura 8 Disciplinas dentro de ALM
La Figura 8muestra las disciplinas que conforman ALM. A continuación se describen:
Administración del Portafolio del Proyecto: por sus siglas en inglés Project Portfolio
Management (PPM), ayuda a las organizaciones a seleccionar los proyectos que
mejor respondan a sus objetivos de negocio. [NotionSolutions,2009b]
Gestión de proyectos: Si bien PPM se ocupa de seleccionar los proyectos adecuados,

la gestión de proyectos se centra en la planificación y el seguimiento de los proyectos
que la organización está llevando a cabo. [NotionSolutions,2009b]
Gestión de Requisitos: Se refiere a la programación, coordinación, control y

documentación de las actividades anteriores. [Dorfman and Thayer,1997]
[Piattini,2007] Ayuda al equipo de trabajo a identificar, controlar y seguir los requisitos
y sus cambios en cualquier momento. Propone la utilización de técnicas repetibles y
sistemáticas, para asegurar la completitud, consistencia y relevancia de los requisitos
de un sistema. Su objetivo básico es la especificación de que debe hacer un sistema y
las restricciones de diseño que condicionan cómo ha de ser implementado.
[Piattini,2006]
Desarrollo de aplicaciones: Se centra en la traducción de las necesidades de negocio

en productos de software. El desarrollo de aplicaciones puede ser un activo
estratégico para una organización o puede ser simplemente un costo de hacer
25
negocios. Las empresas de hoy tienen una amplia gama de técnicas de desarrollo y
metodologías que van desde las tradicionales hasta las ágiles. [NotionSolutions,2011]
Aseguramiento de la Calidad: Se centra en el control de la calidad de los requisitos y el

producto de software. La calidad del software a menudo puede ser difícil de medir,
pero las mejores prácticas han evolucionado para hacer esto no sólo posible, sino
repetible. [IEEE,2001]
Gestión de Cambios: También conocida como Administración de la Configuración, se

centra en el seguimiento de los cambios en el software a través del tiempo. Las
técnicas de esta disciplina se utilizan para crear y almacenar las revisiones de
software y también pueden utilizarse para reproducir una versión del software en
cualquier punto de su evolución. [Len Bass,2003]
Gestión de Operaciones: Se centra en la gestión de software de la organización y los

activos de hardware. Una sólida estrategia incluye los mecanismos y procesos de
apoyo a atención al cliente, aprovisionamiento de hardware y gestión de
infraestructuras. [Janet E. Burge,2008]
La adopción de buenas prácticas hechas a la medida de la organización en cualquiera

de estas disciplinas puede mejorar su éxito en la entrega de soluciones.
1.10. Beneficios ALM
Entre de los principales beneficios de utilizar una herramienta ALM se

encuentran:
¾ Potenciar a los equipos de desarrollo de software con las herramientas y

tecnologías que necesitan para agilizar el proceso de desarrollo de software
desde el diseño y la programación, hasta la implementación y las pruebas.
[Business-Software,2011a]
¾ Mejora la comunicación y el intercambio de información entre los equipos
involucrados en las distintas fases del ciclo de vida de desarrollo.[Business-
Software,2011b]
¾ Permite a los líderes de proyectos controlar el estado de cada actividad
relacionada en tiempo real, permite tomar medidas correctivas inmediatas si
surge un problema, mucho antes de que afecte negativamente la capacidad del
equipo para cumplir los plazos programados.[Business-Software,2011b]
26
¾ Proporciona los mecanismos necesarios para definir claramente todos los

requisitos, y especificaciones, y aplicar y hacer cumplir las directrices de
garantía de calidad. Como resultado, las empresas pueden asegurar que el
software que diseñan y desarrollan satisface todas las necesidades del usuario
final, ya que se construye de acuerdo a metodologías, estándares y buenas
prácticas. [Business-Software,2011a]
En general todas estas ventajas se combinan para producir una mayor confianza en el
producto final, lo que convierte a las empresas en un centro de producción de software
de calidad, con mayor madurez, solides y respeto a nivel internacional.
1.11. Herramientas para la administración del Proceso de

Desarrollo de Software
1.11.1. Rational Team Concert 3.0 (RTC).
Construido sobre la plataforma de tecnología Jazz 19 , ofrece soluciones adaptables

tanto para pequeños equipos como para grandes empresas. [IBM,2011]
Integra el seguimiento de elementos de trabajo, la gestión de control de código fuente,

procesos de integración continua, la planificación de las iteraciones, etc. Sus procesos
son altamente configurables para adaptarse a cualquier forma de trabajo, permitiendo
a los desarrolladores, arquitectos, jefes de proyecto y responsables de los proyectos
trabajar juntos de manera efectiva. [Jazz.net,2011b]
Los elementos de trabajo son el mecanismo fundamental para seguir y coordinar

tareas y flujos de trabajo de desarrollo. Son el centro de enlace entre muchos
artefactos, así como también pueden integrarse con otros productos. Se pueden
adaptar con el propósito de crear nuevos tipos de elementos de trabajo o simplemente
pueden modificarse los existentes con el fin de adaptarse al proceso de desarrollo que
se desee. [Jazz.net,2011a]
El componente de planificación de RTC provee herramientas para asistir y ejecutar

proyectos tradicionales y agiles. Para proyectos agiles provee herramientas para crear
productos, lanzar versiones, crear planes individuales por desarrollador, para seguir el
progreso durante una iteración y para equilibrar la carga de trabajo de los
desarrolladores. Para equipos tradicionales RTC soporta dependencias y restricciones
27
20
programadas y un editor de tabla Gantt para crear planes de proyectos.
[Jazz.net,2011b]
El componente Team Build integra los equipos de construcción proveyendo al equipo

control, seguimiento y conciencia con las construcciones. Se puede seguir el progreso
de las construcciones, ver alertas y resultados de las construcciones, solicitar
construcciones y seguir el rastro de construcciones para otros artefactos.
[Jazz.net,2011b]
Los reportes de equipo y dashboards21 del proyecto son componentes que ayudan a
mantenerse al tanto del estado de los proyectos. Los dashboards proveen vistas de
elementos de trabajo y otros elementos que son críticos para entender el progreso del
proyecto. Los reportes proveen vistas en tiempo real y tendencias históricas de
construcciones, elementos de trabajo y otros artefactos. [Jazz.net,2011a]
Provee una interfaz web para la configuración del servidor por ejemplo: configuración
de la base de datos, notificaciones por correo, administración de usuarios y la
integración con LDAP22. [Jazz.net,2011a]
Proporciona a los usuarios una interfaz de cliente basada en Eclipse, una interfaz de
cliente Microsoft Visual Studio y una interfaz Web. [IBM,2011]
La arquitectura web de la plataforma Jazz cuenta con un manejador para compartir

servicios reusables y soporte para Open Services for Life Cycle Management (OSLC).
Provee integración y colaboración entre herramientas. [Rotibi,2010]
Jazz Integration Architecture (JIA por sus siglas en inglés) cuenta con un conjunto de
servicios, llamado Jazz Fundation Server (JFS por sus siglas en inglés) los cuales
pueden ser utilizados por las herramientas para implementar las capacidades
genéricas entre herramientas. Las herramientas exponen sus servicios específicos de
dominio con un lenguaje neutro, interfaz REST 23para que los clientes puedan acceder
a ellos. [Rotibi,2010]
1.11.2. MKS Integrity.
Es una plataforma empresarial para la gestión del ciclo de vida de las aplicaciones,
coordina y gestiona todas las actividades y los artefactos asociados al desarrollo de
software como parte de un producto integrado o como una aplicación independiente
incluyendo: la gestión de los requisitos, modelado y diseño de sistemas, software de
28
gestión de la configuración, gestión de pruebas, gestión de defectos, gestión de

liberación de versiones y PPM. [MKS,2011a]
La automatización de procesos y la administración de flujos de trabajo aseguran

repetición, fiabilidad y seguimiento de un lado a otro de la organización reduciendo
costos y mejorando la eficiencia y la productividad. [MKS,2011d]
Se enfrenta a las pruebas mediante equipos de pruebas, los cuales necesitan ejecutar
y mantener los artefactos de prueba para productos y sistemas complejos, mientras
conservan altos niveles de calidad de software. [MKS, 2011c]
Provee administración de cambios basada en flujos de trabajo que puede ser aplicada
consistentemente a lo largo de todas las disciplinas en el desarrollo de la aplicación,
garantizando de forma automática el seguimiento del ciclo de vida completo.
[Baer,2011]
MKS Integrity proporciona capacidades consistentes en todas las disciplinas del ciclo
de vida de desarrollo mediante la definición de jerarquías, relaciones y procesos de
gestión de cambio para numerosos artefactos definidos por el usuario. Brinda una
plataforma unificada, proporciona escalabilidad de clase empresarial y capacidad
multiplataforma de apoyo a iniciativas a gran escala de reutilización del software, flujos
de trabajo basados en la colaboración y la minería de datos. [MKS,2011c]
Provee procesos flexibles para adaptase a las necesidades de la empresa. Trabaja

con algunos procesos y metodologías como: las ágiles, CMMI, ITIL16 y Spice17.
[MKS,2011d]
La plataforma central tiene una arquitectura cliente-servidor J2EE, en la capa de datos

se acopla con un repositorio de base de datos empresarial. Expone un conjunto de
servicios e interfaces de usuario para interactuar con el desarrollo y la manipulación de
los activos y elementos de proceso. La estructura de datos flexible permite configurar
elementos de datos que se pueden definir como los requisitos, planes de prueba,
casos de prueba, características, las tareas de desarrollo, las solicitudes de despliegue
etc. [MKS,2011b]
La plataforma de integración de Integrity, un conjunto de tecnologías para llevar a cabo

servicios web y Lenguaje de Ejecución de Procesos de Negocio, por sus siglas en
inglés Business Process Execution Language (BPEL) lo cual facilita la integración con
procesos de negocio. [MKS,2011c]
29
Se integra con disimiles herramientas: herramientas de productividad como Microsoft

Office, IDE como Eclipse y Visual Studio, herramientas de respuesta de requisitos,
herramientas de modelado y otras las cuales proveen alternadas interfaces en el
repositorio MKS. La integración con las herramientas es mediante APIs en diferentes
lenguajes y con diferentes niveles de complejidad abstrayéndose de la tecnología.
[MKS, 2011b]
1.11.3. HP ALM 11.
Cubre todos los aspectos relacionados al ciclo de vida de las aplicaciones, desde el
momento inicial del desarrollo hasta que pasa a producción, tocando procesos tan
críticos como las pruebas de aplicaciones y el control de calidad y rendimiento.
[Fernández,2011]
Sirve como punto de referencia de soluciones como HP Quality Center y HP

Performance Center, soluciones diseñadas para facilitar a los equipos de desarrollo la
gestión y procesos de pruebas de las aplicaciones durante todo ese ciclo de vida,
como la monitorización y trazabilidad de los proyectos.[Fernández,2011]
HP responde a la necesidad de usar herramientas de terceros con un conjunto de

APIs para la extensibilidad. Estas API permiten la sincronización de las actividades de
desarrollo y control de calidad. [HP,2011b]
Ofrece una línea completa de planificación, construcción y liberación de aplicaciones.

La plataforma es escalable, y ofrece una arquitectura orientada a servicios que puede
ser extendida fácilmente. [HP,2011a]
El nuevo proyecto de planificación y seguimiento, característica incluida en HP ALM

11, mejora la previsibilidad del avance de un proyecto. Los jefes de proyecto pueden
crear un plan de proyecto y definir los hitos, los indicadores clave de rendimiento (KPI
por sus siglas en ingles) y los criterios de salida para cada tarea. Tiene un seguimiento
automático de las actividades y de los KPI relacionados en todo el ciclo de vida de la
aplicación en contra de los hitos establecidos, y alerta a las principales partes
interesadas de los riesgos del programa. [HP,2011b]
Está pre integrado con todos los principales entornos de desarrollo permitiendo a los
desarrolladores ver los requisitos de aplicación y defectos, directamente en su entorno
de trabajo sin tener acceso a una herramienta independiente. Incluye una integración
30
con Visual Studio / TFS y Eclipse, que crea la trazabilidad entre los requisitos, defectos
y código fuente. [HP, 2011b]
1.11.4. Micro Focus (Borland Division) Plataforma Open ALM.
Su arquitectura permite el uso de cualquier combinación de herramientas de ciclo de

vida y apoya los procesos establecidos, tales como cascada, ágil, RUP u otro
adaptado. [Pronschinske, 2009]
Provee soluciones que transforman la entrega de software en un proceso de negocio

más manejable, eficiente y previsible. El software de Borland, servicios y clientes de
formación ayudan a administrar, medir y mejorar cada proceso crítico dentro del ciclo
de vida. Ofrece una integración basada en procesos a través de todos los activos del
ciclo de vida, actividades y herramientas para que los clientes puedan colaborar,
compartir información y realizar el seguimiento del proceso de entrega de software
completo. [technologyexecutivesclub,2011]
Cada área de la plataforma Open ALM se basa en una capa de infraestructura

modular y extensible y ofrece su valor de negocio a través de un conjunto de servicios.
El propósito de la capa de infraestructura es permitir a la plataforma Open ALM y a las
aplicaciones trabajar con cualquier combinación de herramientas de desarrollo o de
código abierto y procesos, independientemente del proveedor o de una tecnología.
[Borland, 2007]
La solución Borland Tempo tiene la capacidad PPM, permitiendo a las organizaciones
mejorar la toma de decisiones y ejecución de proyectos, incrementando su inversión
en tecnologías. [Borland, 2011a; 2011c]
Borland Caliber Define IT, sistema de definición de requisitos de software que

permite ajustar y completar los requisitos de software al comienzo de un nuevo
proyecto. Borland Caliber RM, un software para la gestión de requisitos que facilita la
colaboración, análisis de impacto y comunicación a través de todo el ciclo de vida del
desarrollo. [Borland, 2011c].
Borland Star Team, un software de gestión de la configuración y gestión del cambio,
integrado y diseñado para entornos de desarrollo centralizados y geográficamente
distribuidos. [Borland, 2011a; 2011c].
31
Borland Together, plataforma de modelado visual para el diseño de arquitecturas de

software que da soporte a arquitectos, desarrolladores, diseñadores UML, analistas de
procesos de negocio, y modeladores de datos. [Borland, 2011c]
Borland Gauntlet, herramienta para la integración continua y la cobertura de código
para el desarrollo de software Agile, que mejora la visibilidad, la calidad del software y
la productividad del desarrollador construyendo código de pruebas, aislando los
defectos e informando de las métricas claves. [Borland, 2011c]
Borland Silk Central Test Manager, herramienta de gestión de pruebas que permite
planificar y gestionar activamente cada fase del proceso de pruebas, mejorando la
calidad y la productividad. Borland Silk Test, herramienta para realizar pruebas
automatizadas. Borland Silk Performer, para rendimiento de aplicaciones y pruebas
de carga. [Borland, 2011c]
El proceso de Aseguramiento de la Calidad (QA por sus siglas en ingles), está
dirigido por los requisitos, medido y mejorado durante el desarrollo, maximizado
con una apropiada automatización de las pruebas. [Borland, 2011a]
La infraestructura Open ALM incluye dos componentes que se comparten entre
todas las áreas de soluciones: [Borland, 2007]
¾ ALM meta-modelo: un lenguaje común para describir los procesos de
software, las relaciones proceso activo (trazabilidad) y unidades de
medidas (métricas).
¾ Cuenta con un SDK y un mecanismo de integración accesible y
extensible, que define la manera estándar en la que las herramientas
ALM se pueden invocar.
1.11.5. Oracle Team Productivity Center
Oracle Team Productivity Center (OTPC por sus siglas en inglés) permite a los
equipos de desarrollo de software colaborar y trabajar en el desarrollo de aplicaciones
utilizando JDeveloper.
Al ser una herramienta ALM garantiza la gestión del ciclo de vida del desarrollo de
software (requisitos, construcción, prueba, control de cambios, gestión de defectos,
etc.) integrados juntos a través de la aplicación del proceso, la presentación de
informes, la trazabilidad y la colaboración.[Duncan,2010]
32
OTPC ofrece un marco de trabajo que permite a aplicación de terceros, herramientas

de gestión del ciclo de vida para ser integrado en Oracle JDeveloper.
Entre los repositorios que ofrece OTPC se encuentra la gestión de tareas, la gestión
de proyectos, control de versiones, gestión de documentos, informes de errores, la
construcción y los sistemas de gestión. La integración de los repositorios en
JDeveloper permite a los usuarios interactuar directamente con los artefactos
existentes ALM mientras trabajaban en su IDE. Adicionalmente, Oracle ofrece
administración configurable, de gestión de instalaciones, de equipo diseñado para
mejorar la productividad y la comunicación entre sus miembros.
La arquitectura de esta herramienta se basa fundamentalmente en tres componentes

principales: [Duncan,2010]
JDeveloper Client Model: Actúa como un framework de extensiones en el lado del

cliente, este cliente incluye todas las funciones relacionadas con TPC (Team
Productivity Center por sus siglas en ingles) para desde ahí manejar la herramienta.
Para garantizar la colaboración entre los miembros del equipo trae extensiones de
chat, de correo, de alertas todo integrado al IDE de desarrollo.
Team Productivity Center Server: Se encarga de garantizar la comunicación con el

cliente a través de su capa de servicio, se encarga de manejar las credenciales de los
usuarios garantizando la integridad de la información en sus tres repositorios.
Team Productivity Center Connector: La infraestructura de TPC conector se encarga

de crear una instancia que permita la conexión de los repositorios ALM dentro de
JDeveloper. Se basa en estándares garantizando una interfaz a través de la cual
publica sus servicios. Cada conector define que campos de cada tipo de artefactos son
manejados a través de consultas. Es extensible mediante la implementación de una
interfaz de conexión y algunos metadatos XML.
1.11.6. Visual Studio Team Foundation Server 2010 (TFS).
Es la plataforma de colaboración en el núcleo de la solución Visual Studio para la

administración del ciclo de vida de la aplicación. Proporciona servicios fundamentales
como control de versiones, seguimiento de elementos de trabajos y de errores, gestión
de casos de pruebas, automatización de la compilación y almacenamiento de datos,
reportes y dashboards que proporcionan un histórico dando visibilidad en el
mantenimiento total del proyecto. Se integra con Microsoft Project y Project Server
33
ayudando a planear y administrar los proyectos de una mejor manera.

[Microsoft,2011a]
El control de versiones de TFS incluye todas las facilidades para gobernar los
conjuntos de cambios, bifurcaciones, fusión, historiales de cambios, y presenta nuevas
características e innovaciones alrededor del desarrollo en paralelo, check-in
24
atómicos, y el desarrollo remoto. No es un sistema solamente para gestionar el
código fuente, se integra con políticas de TFS, notificación por correo electrónico,
automatización de las construcciones, almacén de datos, y seguimiento de elementos
de trabajo logrando de esta manera un seguimiento completo desde el código hasta
los requisitos. [David et al.,2006]
TFS adiciona características que ayudan a enriquecer la calidad del código y el

seguimiento completo de los elementos de trabajo: [Blankenship et al.,2011] [Gousset
et al.,2010] [J.D. Meier et al.,2007] [Martorell,2006]
¾ Check-in Atómicos:
¾ Relación de check-in - WI:
¾ Shelving:
¾ Políticas de check-in:
¾ Notas de check-in:
¾ Proxy de TFS:
El seguimiento de elementos de trabajo en TFS permite un nuevo nivel de integración

en el ciclo de vida durante el desarrollo de software. Proporciona un mecanismo que
relaciona los procesos del equipo de desarrollo de software y permite lograr las tareas
necesarias para mover un proyecto con éxito desde su concepción hasta el
despliegue. La integración con las funciones de desarrollo y prueba le permite
documentar su trabajo con poco esfuerzo adicional. [David et al., 2006; Gousset et al.,
2010]
Team Foundation Build proporciona un proceso de construcción basado en Windows

Workflow 4.0 como mecanismo de orquestación principal.La automatización de
construcciones, generaciones, compilaciones como se mencionará indistintamente
desde ahora en este documento, es el proceso de racionalizar el proceso de
construcción de modo que sea posible reunir la aplicación en un producto utilizable
con una acción simple. Esto implica que no sólo la parte del código de un
34
desarrollador en particular funcione, sino que además se realicen otras

actividades: [Blankenship et al., 2011]
¾ Compilación de código fuente en archivos binarios.

¾ Empaquetado de binarios en módulos instalables como ficheros MSI25,
ficheros DLL26, archivos JAR27 y así sucesivamente.
¾ Ejecución de pruebas.
¾ Creación de documentación.
¾ Despliegue de los resultados listos para su uso.
TFS expone un modelo de eventos completo y un API que permite integraciones

personalizadas de cualquier aplicación o dispositivo para poder recibir
notificaciones de los resultados de las construcciones, además proporciona dos
sistemas de notificación principales: herramienta de notificación de construcciones
en Windows y alertas por e-mail. [Blankenship et al., 2011; Gousset et al., 2010;
J.D. Meier et al., 2007]
Se integra con varios componentes de TFS para habilitar un flujo de trabajo de
extremo a extremo, automatiza los pasos de la construcción, empezando con iniciarla
desde un servidor, sincronizar las fuentes, documentar el ambiente de la construcción,
construir la aplicación, analizar los binarios generados, ejecutar las pruebas, generar
excepciones, calcular las métricas del código, actualizar elementos de trabajos, crear
notas y documentación de la liberación, y finalmente producir y publicar un reporte de
la construcción. Incrementa la visibilidad del trabajo del equipo produciendo
generaciones regulares y exhaustivas del proyecto de forma rápida y sencilla. [David
et al., 2006; Gousset et al., 2010]
Team Foundation Reporting usa SQL Reporting Services para proveer al equipo con
datos históricos de métricas del proyecto guardadas en el almacén de datos de Team
Foundation. [David et al., 2006; Gousset et al., 2010]
TFS cuenta con dos plantillas de procesos predeterminadas, Microsoft Solution

Framework (MSF) for Agile Software Development y MSF for CMMI Process
Improvement. Cada una de ellas se basa en un proceso de MSF diferente que tiene un
enfoque distinto con respecto al desarrollo de software. Estas plantillas dan forma a
cómo se configura el proyecto. Se puede personalizar cualquiera de estas plantillas de
procesos del modo más adecuado a las necesidades individuales de la
35
empresa.[Microsoft,2007a] La ventaja de contar con una Plantilla y Guía de Procesos

Integrada es la incorporación de teoría sobre el proceso a las herramientas.
Aprovechando mejores prácticas reconocidas, se gana en coherencia iniciando cada
proyecto basándose en un referente probado y satisfactorio. [David et al., 2006;
Gousset et al., 2010]
Brinda la posibilidad de construir un sitio del proyecto o Portal del Proyecto en

Windows Share Point Services, lugar para gestionar la información de alto nivel del
proyecto. La integración entre TFS y Productos de SharePoint proporciona a los
administradores, responsables de proyecto y colaboradores del proyecto las
herramientas organizativas para compartir conocimientos. Los equipos pueden utilizar
este portal para compartir la guía de procesos, los documentos del proyecto, plantillas
e informes según el rol de cada miembro del equipo en el proyecto. [David et al., 2006;
Gousset et al., 2010; Microsoft, 2011]
Ofrece un modelo de objetos de desarrollo, útil para crear herramientas

personalizadas, clientes especializados, WebParts25 personalizados para el portal de
SharePoint y así sucesivamente. TFS se desarrolló pensando en la extensibilidad, está
construido basándose en Team Foundation Core Services que son un conjunto de
Servicios Web usados por el propio TFS para implementar las diferentes áreas
funcionales del servidor. Este modelo de objetos está expuesto mediante API 26
públicas que pueden ser reutilizadas por el desarrollador. [David et al., 2006; Gousset
et al., 2010]
Visual Studio Team Explorer Everywhere es un ejemplo de la utilización de estos

servicios de TFS permitiendo a los equipos de desarrollo colaborar fácilmente.
Contiene las herramientas y los Plugins necesarios para acceder a Visual Studio TFS
2010 desde los entornos basados en Eclipse, de manera que todo el mundo puede
trabajar y lograr los objetivos del negocio. [Microsoft, MSDN,2011b]
1.12. Aspectos a tener en cuenta para la selección de la

herramienta ALM
En la Tabla 1 se realiza una comparación entre las distintas herramientas ALM

estudiadas para su posterior selección, teniendo en cuenta los siguientes criterios de
comparación: Tabla 1: Aspectos de selección para la herramienta ALM
36
Coste del Hardware: Es un elemento importante debido a que la mayoría de las

herramientas analizadas imponen su hardware en cuanto a servidor de Base de Datos,
Servidor de Integración Continua, Servidor Controlador de Versiones más el propio
servidor de la herramienta ALM.
Orientación a Servicio: Aspecto importante a la hora de seleccionar las herramientas

ya que cumpliendo esto nos permite garantizar la integración con el resto de los
procesos del Centro.
Integración con Share Point: De igual manera es importante tener en cuenta este
elemento debido a que tanto el CITI como el MININT desarrollan sus portales con esta
tecnología lo que nos facilita la integración entre el portal de la organización y el de los
proyectos.
Integración con Microsoft Project: Debido a que en la Organización se realiza la

planificación con Microsoft Project es importante que la herramienta seleccionada se
integre con el mismo.
Integración con Integración con CMMI: Es de vital importancia que la herramienta

seleccionada se integre con CMMI ya que la Institución está inmersa en un proceso de
mejora continua basado en esta metodología.
PDS Flexible y adaptable: Otro aspecto importante a tener en cuenta es la flexibilidad

de la plantilla de procesos ya que debe ser adaptada al flujo de trabajo definido en la
Entidad.
Aspectos RTC MKS HP ALM MicroFocus TFS

Comparativos Integrity 11
Costos de Altos Altos Altos Altos Mínimos
Hardware
Orientada a SI SI Si Si Si
Servicios
Integración con No No No No Si
SharePoint
Integración con No No No No SI
Microsoft
Project
Integración con No Si No No Si
37
CMMI
PDS Flexible y SI Si Si Si Si
adaptable
Tabla 1: Aspectos de selección para la herramienta ALM
Como resultado del análisis de las herramientas ALM se selecciona la herramienta

Microsoft TFS 2010 para su aplicación a la entidad, debido a que se integra de manera
nativa con SharePoint, beneficio que puede ser aprovechado debido a que nuestro
centro ya utiliza un servidor de SharePoint, se integra de manera nativa con Microsoft
Project, lo cual es una característica que las herramientas anteriores resuelven
mediante Plugins adicionales, garantiza el proceso de Gestión de Requisitos e incluso
lo mejora permitiendo un seguimiento completo desde los requisitos hasta al código.
Su capacidad de tener integrado el controlador de versiones es una de sus mayores
fortalezas ya que nos garantiza una total trazabilidad de los elementos de trabajo
llegando hasta el código fuente. El despliegue dela herramienta no implica tantos
gastos en recursos de hardware debido a que la necesidad de un servidor SQL y uno
de SharePoint ya están resueltas en nuestra institución. Al igual que las otras
candidatas brinda soporte de extremo a extremo a todas las actividades y disciplinas
ALM. Cuenta con la plantilla de procesos (MSF for CMMI Process Improvement v5.0)
que puede ser adaptada al proceso definido en el centro y de esta manera ayudar al
proceso de alineación que viene realizando la organización por alcanzar el nivel 2 de
madurez en esta metodología.
1.13. Conclusiones
Se realizó una caracterización del marco universitario para el PDS y se profundizó en

las metodologías como guías esenciales en el éxito o fracaso del mismo. Se analizó
RUP como metodología reconocida y ampliamente extendida y los Métodos Ágiles
como XP, SCRUM y AUP que han cobrado gran popularidad en los últimos años.
Además se analizó CMMI que surge debido a la necesidad de integrar los modelos de
madurez de la capacidad de software, ingeniería de sistemas y desarrollo integrado de
programas, con el objetivo de ayudar a la organización a mejorar su capacidad para
entregar los productos a sus clientes y lograr en nivel dos que ofrece dicho modelo.
De las herramientas ALM encontradas, se profundizó en las características de algunas

de ellas. Microsoft TFS 2010 es la herramienta que por sus características, antes
explicadas, reúne las condiciones para ser implantada en la organización, ya que se
38
acopla a las políticas de la organización, de igual manera se integra con las

herramientas ya definidas y actualmente en ejecución en el centro y brinda todas las
características ALM.
Por otra parte se pueden sacar las siguientes conclusiones generales:
¾ No existe una metodología universal para hacer frente con éxito a cualquier
proyecto de desarrollo de software. Toda metodología debe ser adaptada al
contexto del proyecto recursos técnicos y humanos, tiempo de desarrollo, tipo
de sistema, etc.
¾ Los proyectos de desarrollo de software en la universidad cuentan con

características especiales que complejizan la manera en que el proceso puede
ser llevado a cabo.
¾ RUP constituye una metodología para el desarrollo de software flexible que

puede ser ajustada a las condiciones de cualquier proyecto.
¾ Existen un conjunto de prácticas de los Métodos Ágiles que combinadas con

RUP pueden ajustar el proceso al entorno analizado, lográndose ventajas
considerables en cuanto a la producción.
¾ Los enfoques ágiles proponen un conjunto de prácticas que aceleran el

desarrollo de software y que han demostrado arrojar resultados positivos.
39
Entorno para el desarrollo de software
en el CITI
2. Entorno para el desarrollo de software en el CITI

2.1. Introducción
En este capítulo se describen algunos aspectos importantes sobre el entorno particular

de desarrollo que poseen los proyectos del CITI. Se analizan los diferentes criterios
para la clasificación de proyectos informáticos, para de esta manera lograr clasificar
los proyectos de la entidad. Además contiene la descripción de la propuesta de
entorno de desarrollo que se diseñó para el CITI, serán descritos los elementos que
conforman esta propuesta como el flujo de procesos, las actividades y los artefactos.
Se mostrará la implementación que se está dando en el CITI al proceso de CMMI y la
alineación de la propuesta con dicho proceso.
2.2. Entorno de desarrollo
El CITI es una entidad de nueva creación, la cual está compuesta por diferentes
proyectos encaminados, de manera general, a desarrollar tecnologías integradas y a la
formación y superación de estudiantes y profesionales que allí trabajan. [Ruiz,2009]
Actualmente en el CITI, se ejecutan aproximadamente 30 proyectos informáticos, los

cuales poseen características diferentes entre sí, sin embargo existen un conjunto de
elementos que son comunes a todos. Por lo que se hace necesario definir cuáles son
las características del centro como entorno. Este entorno se diferencia del empresarial
tradicional, en que la mayor parte de la fuerza de trabajo son estudiantes
universitarios, que llevan, en paralelo con la ejecución del proyecto, la docencia
universitaria, por lo que no se pueden dedicar a tiempo completo al trabajo en el
proyecto. Para aliviar un poco la carga docente de los estudiantes se realizan algunos
ajustes en la docencia, que incrementa, en alguna medida, el tiempo y esfuerzo
dedicado a las labores de desarrollo en estos proyectos. [Carralero,2008]
Además, es importante tener en cuenta, que existen períodos muertos en la utilización

de esta fuerza de trabajo, como son: períodos de vacaciones, períodos de exámenes
finales y parciales, en los cuales resulta comprensible que los estudiantes dediquen
más tiempo al estudio que a las tareas del proyecto. Es importante destacar que no
todos los estudiantes pueden ser incorporados al trabajo en los proyectos, una de las
razones puede ser que los estudiantes se encuentren cursando los dos primeros años
40
en el CITI
de la carrera, los cuales producto de su plan de estudio no están lo suficientemente
capacitados o que no posean los conocimientos necesarios, ni se encuentran bien
preparados. Un aspecto de interés, es que la mayoría de los integrantes de los
proyectos son estudiantes, que se consideran especialistas, por lo que existen pocos
especialistas con experiencia en estos proyectos.
Otro aspecto que influye directamente en la planificación de los proyectos, es que una
parte importante de los líderes de proyecto son profesores universitarios, que producto
a sus responsabilidades en la universidad, también presentan períodos de menor
dedicación al trabajo en el proyecto.
Por otro lado, la fuerza de trabajo proveniente de la academia no tiene la estabilidad

deseada, pues los estudiantes están, a lo sumo, tres años como integrantes del
equipo, ya que una vez que se gradúan, pueden dejar de trabajar en el proyecto
[Carralero,2008]
Según lo analizado en [Hernández,2010] existen diferentes criterios para la

clasificación de proyectos informáticos. Atendiendo a la forma en que se desarrollan,
los criterios de clasificación son los siguientes: Tareas y roles, Desarrollo del proyecto,
Esencia, Modelo del desarrollo, Origen del proyecto, Tipos de productos que generan,
Participantes en el proceso y Estructura organizacional. De acuerdo a la situación de
partida del producto de software vinculado al proyecto, los criterios de clasificación
son: Nuevo, Mejora incremental, Mantenimiento, Adaptación, Conformidad, Evolución,
Reingeniería e Ingeniería inversa. De acuerdo al tipo de aplicación que produce, los
criterios de clasificación son: Software de sistema, Software de tiempo real, Software
de gestión, Software de ingeniería y científico, Software empotrado, Software de
computadoras personales, Software de Inteligencia Artificial y Multimedia. Para
clasificar los proyectos de acuerdo al modo de desarrollo se utilizan algunas métricas
como son: Líneas de código fuente, Conocimiento del dominio de la aplicación,
Complejidad, Tamaño del equipo y Entorno de desarrollo.
De acuerdo a lo descrito anteriormente se clasifican los proyectos de la entidad

atendiendo a la forma en que se desarrollan, siguiendo el criterio de clasificación Tipos
de productos que generan. De esta manera la diversidad de proyectos pertenecientes
a la organización quedan organizados en cinco grupos de acuerdo al tipo de aplicación
que producen o productos que obtienen. Los grupos conformados se describen a
continuación [Hernández,2010]
41
en el CITI
¾ Software de Sistema: Son un conjunto de programas que han sido escritos
para servir a otros programas. Son sistemas creados para resolver un
problema general, utilizándose en diferentes contextos. Por ejemplo,
herramientas que pueden ser un sistema operativo u otras que ayuden a
desarrollar determinados procesos como el planificador de recursos
empresariales (por sus siglas en inglés ERP).
¾ Software de Gestión: Se puede decir que las aplicaciones en esta área
reestructuran los datos existentes para facilitar las operaciones comerciales o
gestionar la toma de decisiones. Son sistemas creados para resolver un
problema más específico, por ejemplo, un sistema de nómina, de contabilidad,
entre otros.
¾ Software de Ingeniería y Científico: Los Software de Ingeniería y Científico se
caracterizan por incluir algoritmos de procesamiento complejo de números.
¾ Software de Inteligencia Artificial: Los Software de Inteligencia Artificial son
aplicaciones que dan respuesta a un problema usando técnicas de Inteligencia
Artificial.
¾ Multimedia: Se basan en el tratamiento de la información usando los diferentes
medios (texto, imagen, sonido, video, animaciones, etc.) para presentarla en
forma más asequible y amena.
2.3. Modelo para el proceso de desarrollo de software del CITTI
Después de estudiar algunas metodologías y procesos de desarrollos de software, se

tuvieron en cuenta algunos elementos de dichas metodologías y procesos para la
elaboración de la metodología en el CITI. Algunos de estos elementos son: las fases
definidas: Inicio, Elaboración, Construcción y Transferencia, las cuatro primeras
disciplinas de AUP: Modelado, Implementación, Prueba y Despliegue, además de
algunas actividades y artefactos que proponen RUP y AUP. Otros de los elementos
importantes es que la planificación permita conocer el alcance de los entregables al
final de cada iteración, así como las reuniones sistemáticas para dar seguimiento al
avance del proyecto. También el desarrollo basado en pruebas, con el objetivo de
producir aplicaciones más confiables y en menos tiempo.
42
en el CITI
2.3.1. Disciplina Modelado
Es importante destacar que la Disciplina Modelado se conforma con el resultado de

dos proyectos de investigación pertenecientes a uno de los programas del CITI,
denominado Soporte Tecnológico. Se describen de forma detallada las actividades
propuestas, que incluyen un conjunto de buenas prácticas a considerar para la
realización de algunas de estas. Además, se especifican algunos de los artefactos
propuestos, proporcionándose varias listas de chequeo, plantillas y guías para su
construcción. Esta disciplina en AUP posee características distintivas con respecto a
RUP. La propuesta adopta la estructura de AUP
2.3.2. Flujo de trabajo de la Disciplina Modelado
Es importante destacar que la macro actividad Modelado del Negocio y Captura de

Requisitos se encuentra documentada en [CITI,2010]. La Figura 9 se muestra el flujo
de trabajo de la disciplina Modelado.
Figura 9 Flujo de actividades de la Disciplina Modelado.
43
en el CITI
2.3.3. Actividades Disciplina Modelado
A continuación se muestran las actividades de la Disciplina de Modelado.
Identificar Oportunidades de Reusabilidad
El propósito de esta actividad es identificar si existen subsistemas o componentes que

puedan ser reutilizados, basados en cualquier elemento existente que pueda
adaptarse a estas condiciones. Para la realización de esta actividad es importante
tener en cuenta los pasos siguientes:
1. Buscar componentes o subsistemas existentes que ofrezcan elementos

similares.
2. Modificar los elementos recientemente identificados para mejorar el ajuste. Los

cambios simples incluyen reacomodar o añadir parámetros a los elementos a
reutilizar.
3. Reemplazar los elementos candidatos por los existentes, donde se produzcan

coincidencias exactas. Después de la simplificación si hay una coincidencia
exacta con un elemento existente, se elimina el elemento candidato y se usa el
existente.
4. Analizar los sistemas o recursos que pueden ser heredados o utilizados por
otros sistemas.
5. Crear un Modelo de Contrato (también denominado especificación de interfaz

externa), si el sistema requiere acceso a una fuente de información externa.
Esta es una actividad propuesta por AUP. Los pasos del 1 al 3 conforman un paso de
la actividad Incorporar Elementos de Diseño Existentes presente en la disciplina de
Análisis y Diseño de RUP. Los pasos 4 y 5 son elaborados por el equipo de desarrollo,
tomando como referencia AUP. En la actividad se generan dos artefactos con una
plantilla, una guía de construcción y una lista de chequeo de estos artefactos.
Definir / Refinar Arquitectura
El propósito de esta actividad es crear un esbozo inicial de la arquitectura del sistema.

Es importante destacar que el artefacto Arquitecturas de Referencia sólo entra en las
primeras iteraciones. Hay que tener en cuenta que a partir de la segunda iteración de
la fase de Elaboración, el propósito de la actividad es Refinar la Arquitectura. Para la
realización de esta actividad se deben tener en cuenta los siguientes pasos:
44
en el CITI
1. Definir o Refinar la arquitectura
2. Definir una estrategia de reutilización.
3. Documentar los mecanismos de diseño.
4. Construcción de las vistas Lógica, Proceso y Despliegue.
5. Aprobación de los elementos o modificaciones a la arquitectura de referencia.
6. Documentar el estilo arquitectónico seleccionado.
7. Identificar los patrones de diseño.
8. Identificar los lineamientos de diseño.
9. Refinar el Documento de Arquitectura de Software.
10. Probar la arquitectura, con el objetivo de sintetizar al menos una solución (que
puede ser simplemente conceptual) que cumpla con los requisitos críticos de la
arquitectura.
Es de interés tener en cuenta un conjunto de buenas prácticas para el desarrollo de la

actividad, entre las que se encuentran [Franco, 2010] [Ambler, 2006]:
Los mecanismos de diseño son refinados en cualquier fase menos en la de Inicio.
Es recomendable que la arquitectura sea definida por un equipo con experiencia.
La arquitectura debe estar basada en los requisitos y la activa participación de los

interesados del proyecto (en inglés stakeholders) es fundamental para su éxito,
cuando se trata de identificar los requisitos.
Los requisitos deben provenir de los interesados, no de los desarrolladores.
Poseer amplio conocimiento del negocio y centrarse en los casos de uso esenciales
que provienen de los requisitos y reglas de negocio, potencialmente aplicables al
sistema.
Es importante tener en cuenta los futuros cambios que pueda sufrir la arquitectura,
preparándola para aceptar los cambios, pero no actuar sobre ellos hasta que
realmente se necesite.
Garantizar el cumplimiento de los principios de diseño (Ej. alta cohesión y bajo

acoplamiento).
45
en el CITI
Probar la arquitectura o verificar que esa arquitectura ha sido probada en otros
proyectos similares de manera exitosa.
Los elementos seleccionados para probar la arquitectura tienen que responder a los
elementos significativos de la aplicación.
Debe quedar documentado si la arquitectura propuesta resuelve el problema

presentado, sino que problemas posee y la justificación de los mismos.
La arquitectura debe dar soporte a los procesos de negocio y debe poder evolucionar
con este.
La arquitectura es también un medio de comunicación y el hecho de documentar la

arquitectura de manera clara, sirve como enlace entre perfiles técnicos y no técnicos.
Utilizar estereotipos de manera conveniente, puede resultar de gran ayuda.
Refinar el prototipo de interfaz de usuario, utilizando la tecnología con la que se va a

desarrollar el producto final.
Esta es una actividad propuesta por el equipo de desarrollo. Los pasos a seguir en
esta actividad son elaborados, tomando como base las macro actividades Definir
Arquitectura Candidata y Refinar Arquitectura, presente en la disciplina de Análisis y
Diseño de RUP. Además, se tienen en cuenta opiniones y sugerencias de expertos en
la materia, sobre elementos importantes que no deben faltar a la hora de construir la
arquitectura, entre los que se encuentran: los lineamientos, mecanismos, patrones de
diseño, el estilo arquitectónico, entre otros. Las buenas prácticas asociadas a dicha
actividad son elaboradas basándose en AUP y en la experiencia de los especialistas
que trabajan en los proyectos que se desarrollan en la organización. En la actividad se
genera un artefacto. Además, es refinado el artefacto Prototipo de interfaz y el
Documento de Arquitectura de Software el cual se explica en el epígrafe 2.4. Además
se generan dos listas de chequeo, dos guías de construcción y una plantilla.
Analizar Aspectos de Seguridad
El propósito de esta actividad es analizar algunos aspectos importantes referentes a la

seguridad del producto. Para la realización de esta actividad es importante tener en
cuenta los siguientes pasos:
1. Identificar las amenazas, ya sea con un diagrama de clases o de despliegue. A

partir de uno de estos diagramas, se pueden identificar puntos de entrada al
46
en el CITI
sistema, tales como fuentes de datos, interfaces de programación de
aplicaciones (por sus siglas en inglés API), servicios web.
2. Comprender la amenaza, identificando las actividades críticas de seguridad

que se producen, identificando las vulnerabilidades en el sistema.
3. Clasificar las amenazas de seguridad e identificar estrategias de mitigación que

puedan ser usadas en ellas.
4. Crear el modelo de amenazas de seguridad.
Existe un conjunto de buenas prácticas para el desarrollo de la actividad, entre las que
se encuentran [Howard & Lipner, 2006]:
La seguridad debe tenerse en cuenta a lo largo de todo el ciclo de vida del proyecto.
Es importante considerar el impacto que tienen los aspectos de seguridad definidos en

la realización de los casos de uso del sistema.
La seguridad debe ser diseñada, implementada y probada, de manera tal que se

reduzca el número y gravedad de las posibles vulnerabilidades de la aplicación.
La seguridad debe ser aplicada al código, a los datos de la base de datos, a las
interfaces de programación, interfaz de usuario y canales de comunicación.
Los pasos a seguir en la actividad son elaborados por el equipo de desarrollo,

tomando como referencia AUP. Las autoras del trabajo consideran que es de interés
incluir esta actividad en la propuesta, debido a la importancia que posee el control de
la seguridad en el desarrollo de cualquier producto de software, ya sea un
componente, una plataforma o un sistema de gestión. Para la realización de las
buenas prácticas, se tienen en cuenta algunas opiniones de expertos en la materia.
Esta actividad genera un artefacto, que no posee plantilla, ni lista de chequeo ni una
guía para su construcción.
Diseñar Interfaz de Usuario
El propósito de esta actividad es producir un diseño de interfaz de usuario que apoye

el razonamiento y la mejora de su usabilidad. Para la realización de esta actividad es
importante considerar los siguientes pasos:
1. Identificar los elementos principales de interfaz de usuario del sistema,

basándose en algunos requisitos, especialmente los casos de uso del sistema
y los lineamientos de diseño.
47
en el CITI
2. Diseñar los elementos principales de interfaz de usuario, visualizando las
ventanas primarias que deberá tener dicha interfaz.
3. Crear el Modelo de Interfaz de Usuario.
Es de interés tener en cuenta un conjunto de buenas prácticas propuestas por el autor

de esta tesis:
Tener en cuenta los Lineamientos de Diseño definidos en el Documento de

Arquitectura de Software y los tipos de interfaz existentes.
Describir una navegación completa del sistema sin que para llegar a un punto haya
que transitar un largo camino.
Los pasos son elaborados por el equipo de desarrollo tomando como referencia AUP y
la actividad Diseñar Interfaz de Usuario que se encuentra en la Disciplina Análisis y
Diseño en RUP. Las buenas prácticas propuestas a tener en cuenta en el desarrollo
de la actividad, se conforman siguiendo algunos criterios de especialistas de la
entidad. Esta actividad genera un artefacto que posee una guía para su construcción.
Analizar y Diseñar el Sistema
El propósito de esta actividad es obtener una comprensión más detallada de los

requisitos funcionales y no funcionales, de manera que permita una estructuración del
sistema, que sirva de punto de partida para los flujos de trabajo de Implementación y
Prueba. Para la realización de esta actividad es importante tener en cuenta los
siguientes pasos:
1. Analizar los casos de uso para identificar las clases de análisis y las relaciones
requeridas para su realización.
2. Determinar cómo estas clases de análisis forman parte en la arquitectura lógica

(los principales subsistemas y clases) del sistema.
3. Estructurar la aplicación en paquetes.
4. Refinar las clases y sus relaciones, subsistemas e interfaces, tomando en

consideración las características de los lenguajes y plataformas a utilizar.
5. Construir los diagramas de comportamiento estáticos y dinámicos requeridos,

para representar los elementos identificados.
Un conjunto de buenas prácticas a considerar, elaboradas por el equipo de desarrollo

tomando como referencia [Cockburn,2001] son:
48
en el CITI
Los diagramas de secuencia representan la lógica dinámica dentro del código fuente y
deben tenerse en cuenta para su construcción los patrones de diseño identificados en
el Documento de Arquitectura de Software.
Los diagramas de paquetes deben ser usados cuando se necesite organizar los
elementos del modelo UML en grupos o paquetes, ya sean clases, casos de uso o
datos de las entidades.
Los diagramas de comunicación son utilizados cuando se necesita mostrar el flujo de

mensajes entre los objetos y las relaciones (asociaciones, composición, dependencias
o herencia) entre las clases.
Los diagramas de máquinas de estado representan los diferentes estados de un objeto

y las transiciones entre los estados. Solo deben ser utilizados cuando los objetos
poseen atributos dinámicos que cambian de manera significativa en el tiempo.
En la construcción de un diagrama de clases no deben faltar las clases del sistema,

sus interrelaciones (incluyendo herencia, agregación y asociación), las operaciones y
atributos de las clases.
Realizar el diagrama de estructuración en capas en sus dos variantes.
Esta es una actividad propuesta por el equipo de desarrollo. Sus pasos son
elaborados tomando como referencia [Pressman,2002a] y la macro actividad Analizar
Comportamiento presente en RUP. Las buenas prácticas recomendadas están
basadas en AUP y en las consultas realizadas a los especialistas que trabajan en los
proyectos de la organización. Esta actividad genera un artefacto y una guía de
construcción. Además es refinado el Documento de Arquitectura de Software, el cual
se encuentra descrito en el epígrafe 2.3.4.
Diseñar la Base de Datos
El propósito de esta actividad es diseñar la estructura de la base de datos requerida

para la aplicación. Para la realización de esta actividad es importante tener en cuenta
los siguientes pasos a seguir:
1. Identificar las clases persistentes en el diseño.
2. Diseñar la estructura de la base de datos apropiada para almacenar las clases

persistentes.
49
en el CITI
3. Definir mecanismos y estrategias para almacenar y recuperar datos
persistentes, de tal manera que se cumplan los criterios de rendimiento para el
sistema.
Es de interés tener en cuenta la buena práctica elaborada por el equipo de desarrollo

que se muestra a continuación:
Utilización de herramientas que permitan, a partir de modelos, la generación

automática del modelo físico.
Esta actividad es documentada basándose en la actividad Diseñar Base de Datos de

la disciplina de Análisis y Diseño en RUP. Contiene algunas buenas prácticas
elaboradas por el equipo de desarrollo, de acuerdo a la experiencia de los
especialistas que forman parte de los proyectos de la entidad. Esta actividad genera
un artefacto, una guía y una lista de chequeo.
2.3.4. Artefactos Disciplina Modelado
En las actividades propuestas para la Disciplina Modelado, se generan un total de

siete artefactos, entre los que se encuentran: Modelo de Contrato, Arquitecturas de
Referencia, Modelo de Despliegue, Modelo de Amenazas de Seguridad, Modelo de
Interfaz de Usuario, Modelo de Objeto y el Modelo Físico de Datos. Además, se
refinan los artefactos Documento de Arquitectura de Software y Prototipo de interfaz.
Alguno de estos artefactos son propuestos por RUP, por lo que son conocidos por los
integrantes de los proyectos que se desarrollan en el CITI; no obstante las
descripciones detalladas se encuentran en [CITI,2010] .Es importante destacar que el
Documento de Arquitectura de Software, creado en la macro actividad Modelado del
Negocio y Captura de Requisitos contiene solo la Vista Funcional. Esta macro
actividad se encuentra descrita en [CITI,2010]. El resto del documento de arquitectura
es realizado a partir de la actividad Definir / Refinar Arquitectura. A pesar de ser un
artefacto propuesto por RUP, el autor de este trabajo considera importante
incorporarle algunos aspectos que deben tenerse en cuenta en la elaboración de este
documento. Estos aspectos son: la identificación de los patrones y lineamientos de
diseño, la fundamentación de las decisiones tomadas acerca de la selección de la
arquitectura, la selección y documentación del estilo arquitectónico, la documentación
de los mecanismos de diseño y la estrategia de reutilización a seguir.
Algunos de los artefactos presentes en la disciplina son propuestos por AUP, entre los
que se encuentran: el Modelo de Contrato, Modelo de Amenazas de Seguridad,
50
en el CITI
Modelo de Interfaz de Usuario y Modelo de Objeto. Es importante señalar que el
Modelo de Interfaz de Usuario contiene elementos del artefacto Mapa de Navegación
presente en RUP. A continuación se describen dichos artefactos, debido a que no son
tan conocidos por los miembros de los equipos de desarrollo de la organización. Para
su documentación se tuvo en cuenta [Highsmith,2001] [Rational, 2003].
El Modelo de Contrato constituye un contrato entre el propietario de un recurso de

información y los propietarios de otros sistemas que van a ser utilizados. El estilo más
común de este modelo es una interfaz externa (IE), la cual describe cómo tener
acceso a un sistema externo. El Modelo de Amenazas de Seguridad consta de un
proceso de documentación y evaluación de riesgos en la seguridad de un sistema.
Este modelo permite comprender el perfil de la amenaza de un sistema, mediante un
examen a través de los ojos de sus enemigos potenciales. Las amenazas de
seguridad son frecuentemente representadas en un diagrama de despliegue, por lo
que podría no tener un esquema definido para ello. El Modelo de Interfaz de Usuario
describe las interfaces de usuario del sistema. Las interfaces de usuario son útiles
durante las fases de Inicio y Elaboración, pero durante la fase de Construcción se
debe escribir el código actual de trabajo y no el código del prototipo de interfaz. La
navegación de los diagramas de Interfaces de Usuario es utilizada para ver la vista
general de sus interfaces de usuario y explorar los problemas de usabilidad. El mapa
de navegación expresa la estructura de los elementos de interfaz de usuario en el
sistema, junto con sus vías potenciales de navegación. El mapa de navegación hace
que sea fácil de ver cuántos "clicks" llevarán a un usuario llegar a una pantalla
específica. Es importante destacar, que este artefacto contiene algunos elementos del
artefacto Mapa de Navegación presente en RUP. El Modelo de Objeto es un artefacto
similar al Modelo de Diseño que propone RUP. Está compuesto por una vista estática
y una vista dinámica. Para la vista estática se debe considerar utilizar los diagramas
de clases, diagramas de componente, diagramas de paquete y diagramas de
estructuración en capas. Para los aspectos dinámicos, es importante considerar los
diagramas de secuencia, diagramas de comunicación y diagramas de máquina de
estado. De manera general, en la disciplina se crean seis guías de construcción, dos
plantillas y cuatro listas de chequeo. Para su elaboración se tuvo en cuenta [Rational,
2003] y las consultas realizadas a los especialistas que forman parte de los equipos de
desarrollo de la entidad. Esta documentación se encuentra en [CITI,2010].
51
en el CITI
Los artefactos Plantilla de especificación de requisitos, Modelo de Casos de Uso del
Sistema, datos generales del Proyecto, prototipo de interfaz y Modelo del Dominio se
encuentran documentados en [CITI,2010]
2.3.5. Disciplina Implementación
El flujo de trabajo de la Disciplina Implementación se puede observar en la Figura 10.
Figura 10 Flujo de actividades de la Disciplina Implementación.
2.3.6. Actividades Disciplina Implementación
A continuación se muestran las actividades de la Disciplina de Implementación.
Estructurar el Modelo de Implementación
52
en el CITI
Esta actividad tiene como propósito describir cómo se debe establecer la estructura de
los elementos de implementación, basándose en las responsabilidades asignadas de
los subsistemas de implementación y su contenido. Para la realización de esta
actividad es importante tener en cuenta los siguientes pasos:
1. Realizar el Plan de Iteración.
2. Establecer la estructura del modelo de implementación, utilizando el artefacto

Modelo de Objeto para la creación de un diagrama que represente dicha
estructura.
3. Adaptar la estructura del modelo reflejando las restricciones que existan en la

organización del equipo de desarrollo y en el lenguaje de implementación.
4. Definir las dependencias entre lo subsistemas de implementación.
5. Decidir la estructura de elementos de configuración que se va a aplicar al

Modelo de Implementación.
6. Actualizar la Vista de Implementación del artefacto Documento de Arquitectura

de Software, mediante diagramas de componentes que muestren las capas y la
asignación de subsistemas de implementación a las capas, así como las
dependencias entre los subsistemas.
7. Evaluar el Modelo de Implementación.
8. Crear el Plan de Integración a partir del Modelo de Implementación y el Plan de

Iteración.
Un conjunto de buenas prácticas elaboradas por el equipo de desarrollo, tomando

como referencia [Rational, 2003] [James Rumbaugh,1999] son:
Se recomienda hacer uso de los subsistemas de implementación, teniendo en cuenta

como correlacionar los paquetes del diseño con los subsistemas y directorios de la
implementación, decidiendo cuántos niveles de subsistema son necesarios realizar.
Se recomienda definir elementos de configuración que contengan un conjunto de

programas ejecutables que puedan ser desplegados, utilizando el Modelo de
Despliegue.
En el Plan de Integración debe ser evaluado de forma determinante contra todos los
criterios de evaluación descritos en el Plan de Iteración en el desarrollo final de una
iteración.
53
en el CITI
El esquema del Plan de Integración se debe ajustar de acuerdo con las necesidades
del proyecto.
Esta actividad es propuesta por RUP. Los pasos a seguir se elaboran basándose en
las actividades Desarrollar Plan de Iteración, Estructurar Modelo de Implementación y
Crear Plan de Integración que pertenecen a la disciplina Implementación de RUP. Aquí
se generan 3 artefactos y en el caso del artefacto Documento de Arquitectura de
Software, solo se documenta la Vista de Implementación. Además se crea una guía de
construcción.
Escribir Pruebas Unitarias
El propósito de esta actividad es escribir una o más pruebas de unidad y desarrollar

pruebas que puedan ser ejecutadas en conjunto con otras pruebas, como parte de una
infraestructura de prueba más grande. Para la realización de la actividad es importante
tener en cuenta los siguientes pasos:
1. Identificar el objetivo (subsistema/validación de la interfaz de un componente,

la validación de la implementación), el alcance (el cual constituye el elemento
al que se le hace la prueba: clase, componente, subsistema, grupo de
componentes) y el tipo de prueba (caja negra, caja blanca, entrada – salida,
etc.).
2. Definir el conjunto de pruebas a realizar en la presente iteración.
3. Seleccionar las técnicas apropiadas para implementar dichas pruebas,

utilizando herramientas de automatización.
4. Verificar el correcto funcionamiento de las pruebas y generar el soporte

necesario para la ejecución de las mismas posteriormente.
5. Valorar cuáles son las pruebas unitarias que se van a automatizar.
Es de interés tener en cuenta un conjunto de buenas prácticas, elaboradas por el autor

de este trabajo tomando como referencia [Ambler,2006]:
Tener en cuenta una lista de chequeo con el conjunto de pruebas de mayor relevancia
a realizar en cada iteración.
Es recomendable automatizar las pruebas y ejecutarlas tan frecuentemente como sea

posible, sobre todo cuando ocurre algún cambio.
54
en el CITI
Esta es una actividad propuesta por AUP. Los pasos 1, 2, 3 y 5 son elaborados,
tomando como base la actividad Implementar Pruebas de Desarrollo, presente en la
disciplina Implementación de RUP. El paso 4 es modificado por el equipo de
desarrollo, ya que se considera que deben existir todas las condiciones necesarias
para que las pruebas puedan ser ejecutadas. Esta modificación es motivada, debido a
las consultas realizadas a especialistas en la materia. Esta actividad genera un
artefacto y una plantilla.
Escribir el Código de Producción
El propósito de esta actividad es realizar la implementación para una parte del diseño
(clases de diseño, diseño de subsistemas o realización de casos de uso). El resultado
es el código fuente o actualizaciones de dicho código. Para la realización de esta
actividad es importante tener en cuenta los pasos siguientes:
1. Configurar el entorno de desarrollo y analizar si el código existente puede ser

reutilizado o adaptado, antes de realizar la implementación de alguna clase.
2. Realizar la elección del algoritmo, su adecuada estructura de datos, definición

de nuevas clases, operaciones que resulten necesarias y escribir el código de
la operación.
Esta es una actividad propuesta por AUP. Los pasos son elaborados, tomando como
base la actividad Implementar Elementos de Diseño, presente en la disciplina de
Implementación de RUP. En esta actividad se genera un artefacto.
Correr las Pruebas
El propósito de esta actividad es verificar la especificación de una unidad de prueba y

la estructura interna de la misma. Para la realización de la actividad se deben tener en
cuenta los pasos siguientes:
1. Ejecutar las pruebas unitarias ya sea de forma manual o mediante pruebas

automáticas.
2. Evaluar la ejecución de las pruebas para verificar que fueron completadas

exitosamente. Si esto ocurre se verifican los resultados de las pruebas, de lo
contario, es decir, si existe alguna anomalía en la ejecución, se debe corregir el
problema, buscando la causa de la mala terminación y ejecutar de nuevo la
prueba.
55
en el CITI
Esta es una actividad propuesta por AUP. Los pasos son elaborados, tomando como
base la actividad Ejecutar Pruebas de Desarrollo, presente en la disciplina de
Implementación de RUP. Esta actividad genera un artefacto.
Construir el Sistema
El propósito de esta actividad es integrar las partes de los subsistemas de

implementación para conformar el sistema. Para la realización de esta actividad es
importante tener en cuenta los siguientes pasos:
1. Construir los subsistemas en dependencia de la complejidad y el número de

subsistemas a ser integrados, basándose en el Plan de Integración.
2. Integrar el subsistema de acuerdo a su estructura en capa, asegurándose que

las versiones del mismo sean coherentes.
3. Incorporar el sistema a la línea base del proyecto según el controlador de

versiones y cambios utilizado.
Esta es una actividad propuesta por AUP. Los pasos a seguir en esta actividad son
elaborados por el equipo de desarrollo, tomando como base la actividad Integrar
Sistema, presente en la disciplina de Implementación de RUP. En esta actividad se
genera un artefacto.
2.3.7. Artefactos Disciplina Implementación
En las actividades propuestas para la Disciplina Implementación, se generan un total

de siete artefactos, entre los que se encuentran: Plan de Iteración, Modelo de
Implementación, Plan de Integración, Suite de Pruebas de Regresión, Código Fuente,
Sistema y el Modelo de Prueba. Además se refina el Documento de Arquitectura de
Software. Los artefactos presentes en esta disciplina propuestos por RUP son: Modelo
de Implementación, Plan de Iteración, Plan de Integración y Documento de
Arquitectura de Software. La descripción de dichos artefactos se encuentra en
[CITI,2010], aunque es importante destacar que en el caso del Documento de
Arquitectura de Software, solo se documenta la Vista de implementación. El resto de
los artefactos de la disciplina son propuestos por AUP, no obstante las autoras
consideran que algunos son conocidos por los integrantes de los proyectos del CITI.
Estos artefactos se encuentran documentados en [CITI, 2010b], para su descripción se
tuvo en cuenta lo consultado en [Ambler,2006]. A continuación se describen algunos
que pueden resultar de interés:
56
en el CITI
La Suite de Pruebas de Regresión constituye una colección de casos de prueba y el
código para correrlas en un orden adecuado. Incluye un gran rango de pruebas,
tomando en cuenta las pruebas de aceptación, pruebas de unidad, pruebas de
sistema, entre otras. El artefacto Sistema constituye el software, el hardware y la
documentación para ser liberada a ejecución. El artefacto Modelo de Prueba describe
cómo ha sido probado el sistema. Este constituye un artefacto agrupador, incluyendo
la suite de pruebas de regresión, la cual es una colección de casos de prueba, entre
las que se encuentran las pruebas de unidad y de sistema. Además, incluye un reporte
de defectos, que define un conjunto de problemas relacionados con el sistema. A este
artefacto el equipo de desarrollo le incluye los artefactos: script de prueba y registro de
prueba, los cuales se encuentran en RUP.
El Plan de Iteración forma parte de un artefacto agrupador denominado Plan de

Proyecto, el cual contiene además el Plan de Prueba, Plan de Despliegue, Plan de
Integración, el cronograma del proyecto que indica las actividades y las dependencias
entre ellas, la estimación de los costos del proyecto; así como el presupuesto recibido.
Es importante destacar que estos dos últimos son definidos en [CITI,2010], donde se
encuentra la documentación referente a cada uno de los proyectos de la entidad. De
manera general, en la disciplina se realiza una guía de construcción y una plantilla.
Para su elaboración se tiene en cuenta [Rational, 2003] y las consultas realizadas a
los especialistas que forman parte de los equipos de desarrollo de la entidad. Esta
documentación se encuentra en [CITI, 2010]. Los artefactos reglas del negocio,
Plantilla de especificación de requisitos, Modelo del Dominio, Modelo de casos de uso
del sistema y datos generales del proyecto se encuentran documentados en [CITI,
2010].
57
en el CITI
2.3.8. Disciplinas Prueba
El flujo de trabajo de la Disciplina Prueba se puede observar en la Figura 11.
Figura 11 Flujo de actividades de la Disciplina Prueba.
2.3.9. Actividades Disciplinas Prueba
A continuación se muestran las actividades de la Disciplina de Prueba.
Definir Requisitos de Prueba
El propósito de esta actividad es identificar los elementos individuales del sistema,

tanto de hardware como de software, que necesitan ser probados. Para la realización
de esta actividad es importante tener en cuenta los siguientes pasos:
58
en el CITI
1. Determinar qué software será implementado, para comprender las tareas
principales del equipo de desarrollo.
2. Identificar los elementos del sistema candidato a probar, para así determinar
los elementos objetivos en los que se deben centrar las pruebas.
3. Refinar la lista de los aspectos identificados en el paso anterior, para de esa

forma eliminar los objetivos innecesarios y añadir los elementos faltantes para
realizar la prueba.
4. Definir la lista con los aspectos identificados, para comunicar las decisiones
tomadas.
5. Refinar las estrategias y tipos de pruebas definidas para el proyecto.
Esta es una actividad propuesta por AUP. Los pasos del 1 al 4 son elaborados
tomando como referencia la actividad Identificar Objetivos de Prueba, presente en la
disciplina de Prueba en RUP. El paso 5 es elaborado por el equipo de desarrollo,
debido a las necesidades actuales de las características del entorno, basándose en
consultas realizadas a especialistas en la materia. En esta actividad se genera un
artefacto.
Planificar la Ejecución de las Pruebas
El propósito de esta actividad es planificar las pruebas a ejecutar en la iteración

correspondiente; definir detalles de la estrategia de evaluación para el esfuerzo de la
prueba, de manera opcional, evaluar el esfuerzo asociado a cada una de las pruebas.
Los pasos a seguir para la realización de esta actividad son los siguientes:
1. Definir los elementos y objetivos de la prueba para cada iteración.
2. Definir los casos de prueba para el 100 % de la cobertura, según los objetivos,
estrategias y tipos de pruebas.
3. Priorizar los casos de prueba, hacer un listado de los casos de prueba

priorizados.
4. Realizar un cálculo de la cobertura de las pruebas que están siendo

planificadas, para saber qué se está garantizando.
5. Evaluar el esfuerzo necesario para ejecutar las pruebas con el fin de hacer más
eficaz el proceso.
59
en el CITI
6. Generar el plan de prueba, considerando el esfuerzo, el tiempo que se tiene y
los recursos humanos y materiales.
Una buena práctica elaborada por el autor de este trabajo, tomando como referencia
[Ivar Jacobson,2000] para la ejecución del paso 2 se muestra a continuación:
Un caso de prueba específica una forma de probar el sistema, incluyendo la entrada

con lo que se ha de probar y las condiciones que deben existir para desarrollar la
prueba. Para definir los casos de prueba se parten de los casos de uso y sus posibles
escenarios y se tienen en cuenta las estrategias y los tipos de pruebas que existen.
Algunos casos de prueba comunes son: un caso de prueba que especifica cómo
probar un caso de uso o un escenario específico de un caso de uso y un caso de
prueba que especifica cómo probar una realización de caso de uso de diseño o un
escenario específico de la realización.
Esta actividad es propuesta por el equipo de desarrollo. Los pasos son elaborados por
el equipo de desarrollo, tomando como referencia [Jacobson et al., 2004], además de
las actividades Evaluar y Mejorar el Esfuerzo de la Prueba y Evaluar y Promover la
Calidad, pertenecientes a la disciplina Prueba en RUP. Esta actividad genera un
artefacto con una guía de construcción y una plantilla.
Implementar Prueba
El propósito de esta actividad es llevar a cabo uno o más objetos de prueba que
permitan la validación de los productos de software a través de la ejecución física.
Además, desarrollar las pruebas que pueden ser ejecutadas en relación con otras
pruebas como parte de una infraestructura más grande de prueba. Los pasos para la
realización de esta actividad son:
1. Seleccionar la técnica de aplicación adecuada para aplicar la prueba.
2. Preparar el entorno (hardware, software….) para que las pruebas se

desarrollen en condiciones reales.
3. Implementar la prueba, para llevar a cabo uno o más activos reutilizables para
la aplicación de la prueba.
4. Establecer los conjuntos de datos externos, para crear y mantener los datos
almacenados en el exterior, a la secuencia de comandos de prueba, que se
utilizan en la prueba durante la ejecución.
60
en el CITI
5. Verificar la implementación de la prueba, para comprobar el funcionamiento
correcto de la secuencia de comandos de prueba mediante su ejecución.
6. Restaurar el estado anterior del entorno, dejando el sistema en las condiciones

anteriores a que se ejecutara la prueba.
7. Mantener relaciones de trazabilidad, para analizar de esta forma el impacto que

trae consigo el cambio en los requisitos. Este paso es realizado también en las
actividades Implementar Suite de Prueba y Ejecutar Pruebas de Sistema.
Esta actividad es propuesta por AUP. Los pasos son elaborados por el equipo de
desarrollo, tomando como base la actividad Implementar Prueba, que se encuentra en
la disciplina Prueba de RUP. En esta actividad es refinado el Modelo Prueba.
Implementar Suite de Prueba
El propósito de la actividad es reunir colecciones de pruebas que deben ejecutarse en

conjunto, para capturar el valor de los registros de prueba y facilitar la adecuada
amplitud y profundidad de la cobertura de la prueba, mediante el ejercicio de
combinaciones de las mismas. Los pasos para la realización de esta actividad son:
1. Examinar la suite de pruebas de regresión y seleccionar las candidatas a

implementar.
2. Entender las relaciones entre las pruebas planificadas y el objetivo de los

elementos de prueba.
3. Identificar las dependencias de las pruebas en términos de otras pruebas y en

términos generales en relación con el estado del sistema.
4. Identificar las oportunidades para la reutilización, para mejorar el

mantenimiento de la suite de prueba, tanto mediante la reutilización de
recursos existentes, como la consolidación de nuevos recursos.
5. Determinar los requisitos de recuperación, para habilitar la suite de pruebas de

regresión, que debe recuperarse sin necesidad de la completa re-ejecución de
la serie de pruebas.
6. Implementar los requisitos de recuperación, para implementar y verificar que el

proceso de recuperación funcione adecuadamente.
61
en el CITI
7. Estabilizar la suite de pruebas, para resolver los problemas de dependencia
tanto en términos de estado del sistema, como las secuencias de ejecución de
la prueba.
Esta actividad es propuesta por AUP. Los pasos se elaboran por el equipo de
desarrollo, tomando como base la actividad Implementar Suite de Prueba, que
pertenece a la disciplina Prueba en RUP. En esta actividad se genera un artefacto y
una plantilla.
Ejecutar Pruebas de Sistema
Esta actividad tiene como propósito ejecutar las colecciones apropiadas de las
pruebas necesarias para evaluar la calidad del producto y registrar los resultados de
pruebas que faciliten la evaluación continua del producto. Los pasos a seguir para la
realización de esta actividad son los siguientes:
1. Establecer con precisión el entorno de prueba de preparación para la suite de

pruebas de ejecución.
2. Establecer opciones de la herramienta de ejecución, para configurar

correctamente las herramientas utilizadas en la suite de pruebas de ejecución.
3. Desarrollar el calendario de ejecución de la suite de pruebas, para determinar

el momento apropiado para empezar la ejecución de las pruebas.
4. Ejecutar la suite de pruebas, es decir, llevar a cabo el conjunto de pruebas y

supervisar su cumplimiento.
5. Evaluar la ejecución de la suite de pruebas, para determinar si el conjunto de

pruebas fueron ejecutadas hasta el final o se detuvo de forma anormal y hacer
una evaluación de sí es necesaria una acción correctiva.
6. Recuperase cuando las pruebas se detienen, para determinar las acciones

correctivas apropiadas para recuperarse cuando se detiene la ejecución de la
suite de pruebas y si es necesario corregir el problema, recuperar y volver a
ejecutar el conjunto de pruebas.
7. Realizar una inspección de los registros de prueba para la integridad y

exactitud, para determinar si la ejecución de la suite de pruebas genera
información de la prueba que vale la pena y si no, para determinar las medidas
correctivas apropiadas.
62
en el CITI
8. Restaurar el entorno de prueba, para asegurar que el ambiente se reinicia
correctamente después de ejecutada la suite de pruebas.
Esta actividad es propuesta por AUP. Su documentación está basada en la actividad

Ejecutar Suite de Pruebas, que pertenece a la disciplina Prueba en RUP. En esta
actividad es refinado el Modelo de Prueba.
Analizar Resultados de Prueba
Esta actividad tiene como propósito realizar evaluaciones resumidas de manera

continua que permita percibir la calidad del producto, identificar y capturar los
resultados detallados de las pruebas y proponer las medidas correctoras apropiadas
para resolver las fallas en la calidad. Los pasos para la realización de esta actividad se
describen a continuación:
1. Examinar todos los incidentes y fracasos de las pruebas, para investigar cada
incidente ocurrido y obtener una comprensión detallada de los problemas
resultantes.
2. Crear y mantener las solicitudes de cambio, para introducir información de

solicitud de cambio en una herramienta de seguimiento para la evaluación,
gestión y resolución.
3. Analizar y evaluar el estado, para calcular y entregar las medidas e indicadores

claves de la prueba.
4. Hacer una evaluación de las experiencias actuales acerca de la calidad en los

productos de software.
5. Realizar una evaluación de los riesgos potenciales del proyecto que pueden
afectar la calidad del producto.
6. Realizar una evaluación del resumen del análisis de la cobertura de la prueba.
7. Analizar el tiempo real de la funcionalidad terminada, el cual es documentado

en el artefacto Plantilla de especificación de requisitos.
8. Realizar el Resumen de Evaluación de la Prueba, permitiendo comunicar los

resultados de las pruebas a las partes interesadas y hacer una evaluación
objetiva de la calidad y el estado de la prueba.
9. Asesorar a las partes interesadas de los resultados importantes, dando a

conocer el Resumen de Evaluación de la Prueba.
63
en el CITI
Es de interés tener en cuenta un conjunto de buenas prácticas elaboradas por el autor
de este trabajo tomando como referencia [Jacobson et al., 2004]:
Para evaluar los resultados de la prueba se comparan los resultados obtenidos con los
objetivos trazados en el plan de prueba.
Es importante preparar métricas que permitan determinar el nivel de calidad del

software y la cantidad de pruebas necesarias a desarrollar.
Esta actividad es propuesta por AUP. Los pasos se elaboran basándose en la

actividad Determinar Resultados de Prueba, la cual pertenece a la disciplina Prueba
en RUP. El paso 7 es elaborado por el equipo de desarrollo, permitiendo así conocer
la correlación que existe entre el tiempo estimado y el tiempo real de la terminación de
una funcionalidad. La creación de este paso es motivado por algunos criterios de
especialistas, que forman parte de los proyectos de la organización. Esta actividad
genera dos artefacto y una plantilla.
Administrar Pruebas de Aceptación del Sistema
Esta actividad tiene como propósito garantizar que el producto desarrollado cumpla
con los criterios de aceptación, tanto en su desarrollo como en el lugar de instalación
de destino. Para la realización de la actividad hay que tener en cuenta los siguientes
pasos:
1. Garantizar la preparación para la prueba formal. La prueba de aceptación es la

prueba formal llevada a cabo para determinar si un sistema se ajusta a los
criterios de aceptación y para que el cliente, usuario o entidad autorizada
determine si acepta o no el sistema.
2. Iniciar la prueba. La prueba comienza cuando existen todos los elementos que
necesitan ser probados y están presente los participantes necesarios para
ejecutar la prueba.
3. Revisar los resultados y anomalías a eliminar. Los resultados del examen

deben ser revisados al final de cada día en un Resultado de Revisión y generar
peticiones de cambio.
4. Obtener un resultado final, donde quede claro cuáles son las no

conformidades.
Una buena práctica elaborada por el autor de este trabajo, tomando como referencia
[Rational, 2003] es la siguiente:
64
en el CITI
Los resultados de cada caso de prueba deben ser revisados y señalados como
"aceptables” o “no aceptables".
Esta actividad es propuesta por AUP. Los pasos se elaboran tomando como referencia
la actividad Administrar Pruebas de Aceptación, perteneciente a la disciplina
Despliegue de RUP. Esta actividad se refina el artefacto Solicitud de Cambio.
2.3.10. Artefactos Disciplina Prueba
En las actividades propuestas para la Disciplina Prueba, se generan un total de cinco

artefactos, entre los que se encuentran: Estrategia de Prueba, Plan de Prueba,
Registro de Prueba, Resumen de Evaluación de Prueba y Solicitud de Cambio.
Además se refinan los artefactos Modelo de Prueba. La mayoría de los artefactos
presentes en esta disciplina son propuestos por RUP, por lo que las autoras
consideran que son conocidos por el equipo de desarrollo de los proyectos del CITI.
En el caso de la Estrategia de Prueba es propuesta por AUP. La documentación de
dichos artefactos se encuentra en [CITI, 2010].
De manera general, en la disciplina se crea una guía de construcción y tres

plantillas. Para su elaboración se tiene en cuenta [Rational, 2003]. Esta
documentación se encuentra en el [CITI, 2010]. El artefacto Plantilla de
especificación de requisitos se encuentra documentado en [CITI, 2010].
2.3.11. Disciplina Despliegue
65
en el CITI
El flujo de trabajo de la Disciplina Despliegue se muestra en la Figura 12.
Figura 12: Flujo de actividades de la Disciplina Despliegue.
2.3.12. Actividades Disciplina Despliegue
A continuación se muestran las actividades de la Disciplina de Despliegue.
Crear Plan de Despliegue
Esta actividad tiene como propósito proporcionar el cómo y cuándo el producto va a

ser puesto a disposición de la comunidad de usuarios. Para la realización de la
actividad es importante tener en cuenta los pasos siguientes:
1. Entender como empaquetar, distribuir e instalar el software.
2. Tener en cuenta la migración como parte de la instalación del software.
3. Prestar ayuda y asistencia al usuario mediante cursos de capacitación formal,

líneas de orientación, soporte telefónico, internet, entre otros.
Los pasos de esta actividad son elaborados por el equipo de desarrollo, tomando
como referencia la actividad Desarrollar Plan de Despliegue, que se encuentra en la
66
en el CITI
disciplina Despliegue de RUP. Esta actividad genera un artefacto y una guía para su
construcción.
Escribir Notas de Entregable
Esta actividad tiene como propósito describir las principales características y cambios
ocurridos en los nuevos entregables o versiones. También debe describir las
limitaciones de errores conocidos y soluciones temporales. La actividad es propuesta
por RUP y AUP. Su documentación está basada en la actividad Escribir Notas de
Entregable, perteneciente a la disciplina Despliegue en RUP. Esta actividad genera un
artefacto.
Desarrollar Script de Instalación
El propósito de esta actividad es producir todo el software necesario para instalar y

desinstalar el producto de forma rápida, fácil y segura sin afectar a otras aplicaciones o
características de los sistemas. Para la realización de la actividad se debe:
1. Escribir y probar el script de instalación necesario para entregarlo en polígono

del ambiente de pruebas.
2. Redactar la documentación de soporte del sistema, creando el artefacto

Documentación de Soporte.
La actividad es propuesta por AUP. El primer paso es elaborado tomando como

referencia la actividad Desarrollar Artefactos de Instalación, que pertenece a la
disciplina Despliegue en RUP. El segundo paso es agregado por el equipo de
desarrollo, basándose en consultas realizadas a especialistas de los proyectos que se
desarrollan en la organización. Esta actividad genera dos artefactos.
Empaquetar el Sistema
El propósito de esta actividad es realizar el empaquetado del producto. Los pasos a

seguir para su desarrollo son:
1. Producir una versión reducida del producto de software.
2. Asegurar que el producto terminado sea completo (tenga todos los artefactos y
atributos requeridos) y usable.
Esta actividad es propuesta por AUP. Los pasos son elaborados basándose en la
macro actividad Empaquetar Producto que pertenece a la disciplina Despliegue en
RUP. En esta actividad es refinado el artefacto Sistema.
67
en el CITI
Escribir Documentación de Usuario
El propósito de esta actividad es redactar la documentación del producto para los

usuarios. Esta actividad es propuesta por AUP, de acuerdo a las opiniones de los
especialistas que trabajan en los proyectos de la entidad, es necesario tener en cuenta
el artefacto de entrada Documento Arquitectura de Software el cual es necesario para
la creación del artefacto Documentación de Usuario.
Escribir Materiales de Capacitación
El propósito de esta actividad es producir el material necesario para entrenar a los

usuarios en la utilización del producto. Los pasos a seguir para su realización son:
1. Definir el personal, los objetivos y la duración de los programas de

capacitación.
2. Escribir los materiales de capacitación.
Esta actividad es propuesta por AUP. Los pasos son elaborados basándose en la
actividad Desarrollar Materiales de Capacitación que pertenece a la disciplina
Despliegue en RUP. Esta actividad genera un artefacto.
Desplegar Entorno de Preproducción
El propósito de esta actividad es implementar el sistema en entornos de polígono.

Para la realización de esta actividad se debe tener en cuenta:
1. Realizar entregas regularmente del sistema en un ambiente de pre-producción

para efectuar pruebas y llevar a cabo el control de calidad necesario, así como
realizar demostraciones a los involucrados (stakeholder).
Esta actividad es propuesta por AUP. El paso es elaborado por el equipo de

desarrollo, basándose en AUP. En esta actividad se refina el artefacto Sistema.
Administrar Pruebas de Aceptación del Sistema
Esta actividad se encuentra documentada en el epígrafe 2.3.9.7. En esta disciplina se

debe volver a realizar esta actividad, ya que el Usuario Final es el encargado de
realizar las pruebas de aceptación del sistema, una vez que este se encuentra en
polígono. El rol Probador es el encargado de analizar los resultados de la prueba y
entre otras cosas puede además diseñar nuevos casos de prueba.
Desplegar en Producción
68
en el CITI
El propósito de esta actividad es la puesta del sistema en ejecución. Para la
realización de esta actividad se debe tener en cuenta:
1. Realizar cualquier conversión o migración de datos y puede ser todo de una

vez o una conversión gradual de los datos, conforme lo requieran los usuarios.
Esta actividad es propuesta por AUP. El paso es elaborado por el equipo de

desarrollo, basándose en AUP. En esta actividad se refina el artefacto Sistema.
2.3.13. Artefactos Disciplina Despliegue
En las actividades propuestas para la Disciplina Despliegue, se generan un total de

seis artefactos, entre los que se encuentran: Plan de Despliegue, Notas de Entregable,
Script de Instalación, Documentación de Soporte, Documentación de Usuario y
Materiales de Capacitación. Además son refinados los artefactos Sistema y Solicitud
de Cambio. Todos los artefactos de esta disciplina son propuestos por AUP, aunque
en el caso de los artefactos Plan de Despliegue, Notas de Entregable y Materiales de
Capacitación, también se encuentran en RUP. A continuación se especifican dos de
los artefactos propuestos por AUP, que el autor considera de interés. Para la
descripción de dichos artefactos se tuvo en cuenta lo consultado en [Ambler,2006]. La
Documentación de Soporte constituye la documentación requerida por el personal de
apoyo, solución de problemas tales como guías; información de contacto para el
equipo de desarrollo, que les permite apoyar a los usuarios finales. La Documentación
de Usuario contiene los manuales, documentación de ayuda, entre otros; que los
usuarios finales utilizan para ayudarles a entender el sistema. Aquí debe indicarse
cómo ponerse en contacto con el personal de apoyo. Los restantes artefactos
generados en esta disciplina se encuentran documentados en [CITI, 2010], donde
además se encuentra una guía de construcción.
2.4. CMMI en el CITI
El CITI se encuentra enfrascado en la mejora de la organización implantando el

perfeccionamiento en múltiples procesos, para lograr satisfacer sus objetivos
estratégicos. Adopta la representación por etapas, que define un orden para
implementar las áreas de procesos según varios niveles de madurez y permite una
mejora incremental y duradera. La entidad pretende alcanzar el nivel 2 de madurez,
por lo que debe satisfacer los objetivos de todas las áreas de proceso que intervienen
en él.
69
en el CITI
Hasta este momento cuenta con la definición de una serie de artefactos y elementos
fundamentales para lograr dicho objetivo, entre ellos están: El área de Infraestructura
que incluye los siguientes artefactos: plan de riesgos, roles, el ciclo de vida etc., este
último cuenta con las siguientes fase definidas a partir del estudio realizado de las
metodologías y procesos de desarrollo en epígrafes anteriores.
A continuación se describen brevemente las Fases del Ciclo de Vida del Proyecto de
Investigación que han sido definidas en al CITI como parte de la infraestructura de
CMMI y que tuvo en cuenta las disciplinas y fases ya definidas en el manual pare el
desarrollo de software en el CITI.
¾ Identificación: Se definió que como resultado de esta fase deben obtenerse las
principales funciones del producto o servicio, una propuesta inicial de la
arquitectura, los riesgos más importantes, un plan y una estimación
aproximada del proyecto.
¾ Elaboración: Se definió que como resultado de esta fase debe obtenerse una
arquitectura y un plan estable, los riesgos se consideran controlados como
para hacer un compromiso con los funcionales.
¾ Ejecución: Se definió que en esta fase se crea el producto o servicio y se

comprueba que cumple con las necesidades de los funcionales de manera
suficiente como para realizar una primera entrega.
¾ Transferencia: Se definió que en esta fase el producto o servicio así como toda
la documentación establecida debe ser transferida al funcional y quedar
operativo, realizándose las evaluaciones requeridas por los órganos
establecidos.
De igual forma en este proceso de mejora se definieron cuatro vistas de procesos:
¾ Vista de Procesos de Ingeniería: Contiene las actividades y tareas de un

desarrollador.
¾ Vista de Procesos de Gestión de Proyectos: Define las actividades básicas de

gestión, incluyendo la gestión de proyectos dentro del ciclo de vida.
¾ Vista de Procesos Empresariales: Define las actividades para el registro de la

información producida por un proceso del ciclo de vida.
70
en el CITI
¾ Vista de Procesos de Soporte: Define las actividades correspondientes al
proceso de gestión de la configuración, medición y análisis y aseguramiento y
control de la calidad.
Los proyectos se desarrollan de forma iterativa e incremental, es decir, en cada fase

se pueden definir varias iteraciones y se trabaja incrementalmente en la solución
pasando por los procesos definidos, en mayor o menor medida en dependencia de la
fase.
Todos los proyectos, con independencia de su tipo, deben pasar por las cuatro fases.
En función de los objetivos y los resultados que se vayan alcanzando en el proyecto se
condiciona el pase a la fase siguiente, a la anterior o incluso, la decisión de terminar el
proyecto.
La organización tiene definidas dos de las Áreas de Procesos (AP)según CMMI,

díganse Planificación de Proyectos (PP) y Gestión de Requerimientos (REQM) y se
está trabajando en Aseguramiento de Calidad de Procesos y de Productos (PPQA),
Monitoreo y Control (PMC). Contando con los artefactos y documentación que generan
cada una de ellas.
En el AP de PP se definieron un conjunto de artefactos de gestión entre los que están:

Fundamentación de PI, WBS, Método de estimación, Tarea técnica, Plan de desarrollo
entre otros.
En el AP de REQM igualmente se han definido un conjunto de artefactos que dan

cumplimiento al objetivo de esta área (administrar los requisitos y detectar las
inconsistencias entre ellos) entre los que están: Especificación de requisitos, Revisión
de inconsistencias, Registros de revisiones, Solicitud de cambio entre otros.
2.5. Alineación del proceso definido para el CITI con CMMI
En el proceso de mejora en el que se encuentra enfrascado el CITI ha sido

considerada la definición hecha con anterioridad en el Manual para el desarrollo de
software en el CITI lo que se evidencia en la alineación que existe entre las disciplinas
definidas y las vistas de procesos definidas posteriormente en CMMI en el contexto del
CITI.
En la Tabla 2 se muestra la alineación de las vistas definidas en el CITI para la mejora

de procesos con CMMI y las disciplinas definidas en Manual para el desarrollo de
software en el CITI.
71
en el CITI
Vistas de Procesos Manual para el Desarrollo de Software en el CITI
Modelación Implementación Prueba Despliegue
Procesos de Ingeniería
Modelado del Negocio X
Gestión de Requisitos X
Análisis y Diseño X
Implementación X
Prueba X
Despliegue X
Procesos de Gestión de Proyectos
Planificación de X
proyectos
Monitoreo y Control X X X X
Gestión de acuerdos con X X X X
Proveedores
Gestión de Riesgos X X X X
Procesos Empresariales (Gestión de Procesos)
Control y Registro de la X X X
Documentación
Procesos de Soporte
Gestión de la X X X X
Configuración
Medición y Análisis X X X
Aseguramiento de la X X
Calidad del Proceso y del
Producto
Tabla 2: Vistas de Procesos CMMI vs Manual para el desarrollo de Software
Como se puede apreciar existe relación entre la disciplina de Modelación y las tres
primeras disciplinas de la vista de Procesos de Ingeniería, aquí vale aclarar que las
disciplina de Modelación como se explicó en el capítulo anterior es propuesta por AUP
e incluye Modelado del Negocio, Gestión de Requisitos y Análisis y Diseño. Las
restantes disciplinas de la vista de ingeniería coinciden totalmente con el proceso
propuesto igualmente analizado en el capítulo anterior.
La vista de Gestión de Proyectos no entra en contradicción con el modelo propuesto,

ya que la disciplina de modelación debido a que incluye la gestión de tareas y
requisitos debe alinearse a lo planteado por la disciplina de planificación, lo mismo
pasa con monitoreo y control la cual debe estar presente en las cuatro fases del
proceso en aras de alcanzar la calidad y las metas requeridas. En la gestión de
acuerdos con proveedores al igual que en la gestión de riesgos ocurre algo similar
puede darse el casos de que haga falta en cada una de las disciplinas, es por eso que
aparece relacionado con cada una de ellas.
72
en el CITI
El control de la documentación está presente con mayor fuerza en la disciplina de
Modelación, Prueba y Despliegue para de esta manera garantizar un control estricto
con los documentos del proyecto.
En la vista de soporte se puede apreciar que existe relación con cada una de las
disciplinas propuestas, el objetivo de esto es en mantener cada uno de los artefactos
que se generen con total control y versionado.
Con respecto a la medición y análisis se está trabajando en el centro en la definición

de un conjunto de indicadores para de esa manera mejorar el proceso de desarrollo,
como se puede apreciar es importante analizar las disciplinas de modelación
implementación y prueba para de esa manera mejorar en la calidad del producto final.
Por último y no menos importante es el área de Aseguramiento de la Calidad del

Proceso y del Producto la cual tiene una estrecha relación con la disciplina de
Modelación que tiene como meta entender el negocio de la organización, el dominio
del problema que el proyecto aborda, identificar una solución viable para abordar este
dominio e iniciar el modelado de requerimientos de alto nivel, por lo tanto se hace de
vital importancia garantizar la calidad de dicha disciplina. Lo mismo ocurre con las
pruebas que tiene como meta ejecutar una evaluación de los objetivos para asegurar
la calidad del producto final.
2.6. Conclusiones
En este capítulo se conforman los flujos de trabajo de las disciplinas de Modelado,

Implementación, Prueba y Despliegue que forman parte de la propuesta realizada.
Estos flujos muestran la secuencia de actividades que deben seguir los integrantes del
equipo de trabajo en el desarrollo de los proyectos informáticos del CITI. Cada
actividad se descompone en un conjunto de pasos para llevarla a cabo, que incluye
artefactos de entrada y salida, además de algunas sugerencias o buenas prácticas
recomendadas para su realización. Se proponen también varios artefactos que
incluyen un conjunto de plantillas, listas de chequeo y guías que pueden ser utilizadas
para facilitar su construcción. Todo lo explicado anteriormente, posibilita que la
ejecución de los proyectos se realice de una manera más organizada, aprovechando
al máximo el tiempo y los recursos disponibles, además de generar la documentación
necesaria que puede ser utilizada posteriormente.
73
Herramienta de soporte al proceso de
desarrollo de software en el CITI
3. Herramienta de soporte al proceso de desarrollo de

software en el CITI
3.1. Introducción
Para completar la propuesta de entorno para el desarrollo de software en el CITI es

necesario definir cómo integrar la herramienta ALM que le daría soporte, en este caso
TFS al proceso definido en el Manual para el desarrollo de software en el CITI. En este
capítulo se describe en detalle el soporte que brinda la herramienta a cada proceso y
su alineación con lo establecido para cumplir con el nivel 2 de CMMI en la entidad.
A continuación se mencionaran cada uno de los cambios hechos en la plantilla de

procesos para adaptar el flujo de trabajo de TFS al de la organización. Se trataran
aspectos sobre la estructura organizativa dentro de TFS para la distribución de los
proyectos y la estructura dentro del repositorio de control de código, además de hablar
de las recomendaciones y buenas prácticas para una efectiva estrategia de realización
de construcciones. Otros temas a los que se hará alusión son: despliegue de TFS,
requisitos de software y hardware de los distintos niveles de TFS, y una descripción
general del flujo básico de trabajo con la herramienta.
3.2. Modificación de la Plantilla de TFS según las necesidades del

CITI
Una plantilla de proceso define las características por defecto de cualquier nuevo TP,
que incluye los tipos de elementos de trabajo por defecto, informes, documentos, guía
de procesos, y otros artefactos asociados que proporcionan todo lo necesario para
comenzar el proyecto. [Blankenship et al.,2011] [Microsoft,2011a]
Microsoft proporciona las siguientes plantillas de procesos por defecto en la instalación

de TFS: [Gousset et al.,2010]
¾ Microsoft Solutions Framework (MSF) para el Desarrollo de Software Ágil.

¾ MSF para la Integración de Modelos de Capacidad y Madurez (CMMI).
Teniendo en cuenta que el CITI está llevando a cabo el proceso de mejora continua
basado en la metodología CMMI, se utilizará como punto de partida la plantilla MSF
for CMMI Process Improvement v5.0, la cual se adaptará (o adecuará) a las
necesidades del centro.
74
Las plantillas de procesos son en TFS el esqueleto de los proyectos de equipo, la
adaptación a los procesos del CITI son una tarea imprescindible para gestionar el ciclo
de vida de las soluciones del centro.
A continuación se especifican cada una de las modificaciones realizadas en los

distintos componentes de la plantilla de procesos, dejar claro que pueden haber
variaciones debido a que todavía en la organización se están definiendo áreas de
proceso las cuales impactan en cambios de dicha plantilla.
Cuando se crea un nuevo proyecto de equipo, una plantilla de procesos se utiliza para
crear y configurar las diversas partes del proyecto de equipo, incluyendo las
siguientes:
¾ Elementos de trabajo
¾ Consultas de elementos de trabajo.
¾ Portal del Proyecto de equipo.
¾ Documentos del proyecto
¾ Grupos y permisos.
¾ Los informes que se incluyen en una plantilla determinada.
¾ Mapeo de campos entre los elementos de trabajo y los campos en el Microsoft
Project.
¾ Áreas e iteraciones Predefinidas.
¾ Configuración del control Versiones.
75
3.2.1. Elementos de Trabajo.
Figura 13 Definiciones de tipos de WI en la Plantilla de Procesos.
Las definiciones de tipo de elementos de trabajo son los archivos que contienen
información acerca de los estados, transiciones, campos, y diseños de formulario de
un tipo de WI. Estos ficheros son los artefactos más modificados en una plantilla de
procesos. Al cargar la Plantilla de Procesos en TFS, mediante el Process Editor
(funcionalidad que se agrega al Visual Studio Team Explorer luego de instalar el
paquete de herramientas TFS Power Tools), el fichero principal de la plantilla de
procesos lista cada una de las definiciones de tipos de elementos de trabajo, como se
muestra en la Figura 13, los cuales serán incluidos cuando se inicie un nuevo proyecto
de equipo utilizando dicha plantilla.
La definiciones de tipos de elementos de trabajo que vienen con la plantilla son: (Bug,
Task, Issue, Change Request, Risk, Requirement, Review, Test Case y Shared Steps).
Como se mencionó anteriormente el CITI está alineándose con CMMI, basado en el
avances de la organización en algunas de las AP de CMMI, díganse PP, PPQA, PMC,
REQM y teniendo en cuenta las incidencias y reportes que hay que recoger para cada
una de ellas se definieron algunos nuevos WI y redefinieron otros, los cambios se
muestran a continuación:
Cambios según el AP PP
¾ Se modificó el WI Task. Algunas de las transformaciones son: adición de los

campos Clasificación o Tipo de Tarea (Colaboración, Mitigación, Acción
76
Correctiva, Documentación, etc.) e Hito. También se redefinieron los estados y
transiciones del flujo de trabajo de este WI.
¾ Se creó un nuevo WI, Producto Reusable, debido a las necesidades
existentes de recoger los productos reutilizables por cada proyecto de la
organización al momento de desarrollar una nueva solución, ganando en el
control y seguimiento de los distintos artefactos de cada proyecto.
¾ Se redefinió el WI Risk. Algunas de las modificaciones son: se agregó el
campo criticidad (multiplicación del campo Impacto por el campo Probabilidad)
utilizado para medir el grado de riesgo, además se adicionaron una pestaña
para la relación con las Tareas de tipo mitigación y otra para la relación con las
Tareas de contingencia. También se redefinieron los estados y transiciones del
flujo de trabajo de este WI.
Cambios según el AP REQM
¾ Se creó un nuevo WI, Requisito Inicial, a partir del WI Requirement, debido a

que como parte del proceso de gestión de requisitos es necesario capturar los
requisitos iníciales con el funcional 27 y a partir de estos generar requisitos
derivados. Algunas de las transformaciones son la adición de una pestaña para
la relación con los Requisitos. También se redefinieron los estados y
transiciones del flujo de trabajo de este WI.
¾ Se creó un nuevo WI, Revisión de Inconsistencia con el objetivo de agrupar
todas las inconsistencias detectadas en una revisión y hacer más cómoda y
factible la gestión de este proceso. Mediante este WI se puede establecer
relaciones con Inconsistencias. También se definieron los distintos estados y
transiciones de este elemento de trabajo.
¾ Se creó un nuevo WI, Inconsistencia, se definió a partir del WI Issue. Su
objetivo es dar cumplimiento a la práctica específica 1.5 del AP de REQM la
cual plantea que deben encontrarse las inconsistencias entre requisitos, planes
del proyecto y los productos de trabajo, iniciando a su vez las acciones
correctivas para solucionarlas. Algunos de los campos que tiene este elemento
de trabajo son: Fuentes (se recogen todas las relaciones con los Requisitos),
Acciones Correctivas (se recogen todas las relaciones con los WI de tipo
Acción Correctiva), Solicitud de Cambio (se establecen todas las relaciones
con los WI de tipo Solicitud de Cambio), etc. También se redefinieron los
estados y transiciones del WI Requisito.
77
¾ Se modificó el WI Requirement. Se va a utilizar para almacenar los requisitos
funcionales y los no funcionales. Algunas de las modificaciones realizadas a
este WI son: se adicionó el campo categorías, este se activa si se selecciona
en el campo Tipo de Requisito, no funcional. Otros campos agregados son:
Relevancia, Reutilización, Criterio de aceptación, Usuario Final, entre otros.
Fueron redefinidos los estados y transiciones del flujo de trabajo de este WI.
Cambios según el AP PPQA
¾ Se creó un nuevo WI, No Conformidad, ya que se requiere como necesidad

del proceso de PPQA hacer un levantamiento, control y seguimiento de las No
Conformidades detectadas en las revisiones. Alguno de los datos que se
recogen con este WI son: Acciones Correctivas (vínculos a WI de tipo Tarea),
Causa, Estado y Área de Procesos.
¾ Se modificó el WI Review, renombrándose Revisar Adherencia, agregándole
un número de campos debido a la necesidad de registrar todas las revisiones
planificadas. Se adicionaron y modificaron algunos campos, a continuación se
menciona lo más significativo. Campo Equipo de Revisores (enlaces a Tareas),
No Conformidades (enlaces con WI No Conformidad), Causa, Área de
procesos. Además en la pestaña Minutas se definió un adjunto el cual será el
F-00-00-01 Acta de Reunión. El resto de los campos vienen predefinidos con la
plantilla.
Cambios generales
Se modificó el WI Change Request. Se debe tener en cuenta que este impacta en

varias AP de CMMI, díganse PPQA y REQM, por lo que se realizaron ajustes basado
en ambas áreas. Los ajustes realizados fueron: se agregaron los campos: Tipo
Solicitud, Área de Procesos, se eliminaron los campos Evaluación de Errores, la
Pestaña Otros, la Pestaña Justificación. Se redefinió el flujo del WI modificando
estados y transiciones.
Grupos y Permisos.
Para administrar la seguridad es necesario definir usuarios y grupos con determinados

privilegios que garanticen el acceso a TFS. El componente Grupos y Permisos dentro
de la Plantilla de Procesos es donde se define la seguridad inicial en TFS.
78
Partiendo de un análisis de la composición de los proyectos del centro, teniendo en
cuenta sus integrantes y los roles que estos desempeña, unido a las funcionalidades
de TFS, se han creado los siguientes grupos:
¾ Program Managers: Está formado por los Jefes de Programa.

¾ Developers: Está formado por Estudiantes y Especialistas.
¾ Project Administrators: Está formado por los Jefes de Proyecto.
¾ Readers: Está formado por usuarios interesados que el jefe de proyecto o de

programa considere que puede tener acceso de lectura en los datos del
proyecto.
¾ Builders: Está formado por los usuarios encargados de las construcciones y

las pruebas.
Los permisos fueron asignados teniendo en cuentas las áreas de seguridad de TFS
(colección de proyectos, proyecto de equipo, control de versiones, compilación, áreas
e iteraciones) y el rol de cada grupo de usuarios de los mencionados anteriormente en
el proceso de desarrollo de una solución.
La Plantilla de Procesos cuenta con el fichero, Grupos y Permisos, para definir los
permisos a nivel de colección, de proyectos y en las áreas e iteraciones. Por otra parte
los ficheros Build y Version Control de la plantilla solucionan los permisos de estas dos
áreas.
Los permisos a nivel de proyecto, afectan a un Proyecto de Equipo en específico,

mediante estos se conceden libertades para administrar ejecuciones de builds y
pruebas, administrar la seguridad del proyecto, administrar configuraciones y entornos
de prueba.
Las autorizaciones en el nivel de áreas e iteraciones determinan que usuarios y grupos

podrán gestionar los distintos nodos en cada uno de estos sitios, permitiendo
administrar planes de prueba, crear elementos de trabajo, etc.
Las autorizaciones en el nivel de compilaciones autorizan a los usuarios y grupos a

administrar definiciones de compilaciones, administrar la calidad de las compilaciones,
administrar la cola de compilación, entre otros.
Los permisos en el control de versiones garantizan los derechos para acceder a una
determinada ruta en el repositorio de código, asignando los privilegios para subir y
79
descargar versiones, etiquetar, realizar ramas y combinaciones, administrar las ramas,
en fin todas las tareas de control de código.
Teniendo en cuenta esto se le asignó al grupo Project Administrators todos los

permisos a nivel de proyecto, en las áreas e iteraciones, en las compilaciones y en el
control de código. El grupo Developers, tiene permisos básicos, puede crear
elementos de trabajo, subir y descargar código del repositorio, y puede consultar la
información a nivel de proyecto. El grupo Builders tiene los privilegios para gestionar
lo relacionado con las definiciones y recursos de builds en el proyecto. Por su parte el
grupo Program Managers contará con los mismos permisos de solo lectura del grupo
Readers lo que adicionalmente podrá descargar código fuente del repositorio y crear
elementos de trabajo.
3.2.2. Reportes.
Con la redefinición de algunos elementos de trabajo, y la creación de otros nuevos fue

necesario crear un conjunto de nuevos reportes, teniendo en cuenta además las
necesidades de las AP analizadas de CMMI.
Los reportes incluidos hasta este momento son:
¾ Reporte de la Evaluación.
¾ Carta de Aceptación de Requerimientos del Cliente.
3.2.3. Modificaciones al Portal del Proyecto.
Como se mencionó el CITI cuenta con un portal sobre SharePoint en el cual

actualmente se gestiona la documentación referente a la organización, incluyendo la
referente a todos los Programas de Investigación con sus respectivos Proyectos.
Teniendo en cuenta que una de las potencialidades que TFS brinda es la generación
de un portal en SharePoint para cada proyecto de equipo, se decidió gestionar toda la
documentación referente de los proyectos en los portales generados por TFS, díganse
las presentaciones del proyecto, las publicaciones, los planes de resultado de sus
integrantes, etc. Además se van a controlar otros documentos asociados al proyecto
que tienen que ver con otras aristas como los medios inventarios etc.
Manteniendo la alineación con el proceso de mejora con CMMI en el cual está

enfrascada la organización se va a crear una carpeta en el portal de cada proyecto
llamada CMMI, con las distintas AP, para gestionar las evidencias que desean ser
80
recogidas por cada una de estas. Ya se han dado los primeros pasos, un ejemplo de
esto es el Excel para el método de estimación, que surge debido a una necesidad de
PP el cual ejecuta una consulta de TFS, recoge un conjunto de requisitos y resuelve
esta necesidad de esta AP.
Esto ofrece grandes ventajas, una de ellas es que se gestionará a nivel de Proyectos
la documentación y será accesible desde el Portal del Proyecto, Team Explorer y el
Web Access lo que garantiza una mayor colaboración.
La Figura 14muestra la visualización de estos documentos desde el Portal del Proyecto

y el Team Explorer.
Figura 14 Visualización de los documentos en el Portal del

Proyecto.
3.2.4. Áreas e Iteraciones.
Las áreas e iteraciones son creadas para organizar lógicamente los elementos de
trabajo. Esta sección de la plantilla de procesos se modificó teniendo en cuenta las
fases definidas para el ciclo de vida de los proyectos del CITI (Procesos de Ingeniería)
quedando definidas las aéreas de identificación, elaboración, ejecución y
transferencia.
3.2.5. Mapeo entre los campos de los elementos de trabajo y

los campos del Microsoft Project
81
El Microsoft Project Enterprise es la herramienta que la organización usa actualmente
para la planificación de tareas, al definir nuevos campos en el WI de tipo tarea fue
necesario modificar el fichero de mapeo con Project de la plantilla de procesos a fin de
sincronizar correctamente el Project con los WI Task de TFS.
Por esta razón se definieron dos nuevos elementos al mapear entre los WI de tipo
Task y el Project ellos son:
¾ Clasificación
¾ Hito
3.3. Estructura organizativa dentro de TFS.
La organización dentro del servidor se refiere a los mecanismos para ordenar,

distribuir y colocar una estructura correcta teniendo en cuenta la disposición de
Colecciones de Proyectos de Equipo y Proyectos de Equipo. Esta estructuración es de
vital importancia ya que determina en el desarrollo futuro del centro y en la realización
de los distintos procesos del ciclo de vida de las soluciones definidas en el mismo.
Analizando los conceptos de proyecto de equipo y colecciones de proyectos de

equipo, además de las ventajas y desventajas de las distintas estructuras posibles en
que estos pueden organizarse se determinó lo siguiente.
Se crearán dos colecciones de Proyectos de Equipo (CITI y Calidad), la primera de

ellas contendrá todos los proyectos del centro díganse AFIS, Banco de Soluciones, y
así sucesivamente, cada uno de ellos será un Proyecto de Equipo con sus respectivos
artefactos, documentación, elementos de trabajo, código fuente, etc. La segunda
colección Calidad llevara consigo de igual forma un Proyecto de Equipo por cada una
de los proyectos del centro en los cuales se realizaran las pruebas para cada solución
existente, por eso la idea de tener la misma estructura que la colección CITI con el fin
de tener organizado los planes de pruebas, errores, videos, etc. por cada uno de los
proyectos, esto se irá nutriendo a medida que cada solución vaya requiriendo pruebas
funcionales.
Esta estructura se decide a fin de lograr mayor colaboración entre todos los proyectos
del centro, de ahí parte la agrupación de todos en la colección CITI, para que de esta
manera puedan compartir elementos de trabajo, código, consultas, etc. logrando una
82
mayor reutilización, además de esta forma la administración se hace mucho más
sencilla.
Lo que puede parecer confuso es la palabra colaboración, que se menciona en el

párrafo anterior, y contradictoriamente a esto se han creado dos colecciones las
cuales necesitan colaborar. La solución para esta problemática es usar la herramienta
TFS Integration Platform, mediante la cual se pueden exportar conjuntos de elementos
de trabajo entre colecciones además de código fuente, y de este modo se garantizara
la retroalimentación necesaria entre los procesos de aseguramiento de calidad de los
distintos proyectos de la colección Calidad y las soluciones de cada proyecto del
centro en la colección CITI.
3.4. Estructura dentro del Repositorio Control de Versiones
En este epígrafe se proponen algunas buenas prácticas que deben ser adoptadas por
los Equipos de Proyectos del CITI para mejorar en organización del repositorio de
código y aumentar la calidad e impacto de las fuentes que este protege.
Un factor importante es la estructura dentro del repositorio de control de versiones;

al comienzo no se muestra como algo tan grave pero luego cuando los proyectos
evolucionan puede ser algo complicado localizar alguna documentación, código
fuente de una determinada versión, o de un proyecto que ya paso a producción, en
fin múltiples escenarios que demuestran la necesidad de una estructura
organizada y bien concebida.
Según la bibliografía consultada [Blankenship et al.,2011; J.D. Meier et al.,2007] se

plantea que todos los proyectos de la organización sigan la estructura que se
muestra en la Figura 15 ya que además de brindar los beneficios antes
mencionados, las definiciones en cuanto a las generaciones automáticas se van a
establecer tomando como base esta estructura.
Partiendo de que la mayoría de los proyectos de equipo contienen uno o más

soluciones y cada una de estas contiene uno o más proyectos, se propone la
83
siguiente estructura dentro del repositorio de control de código de TFS.
Figura 15 Estructura dentro del repositorio de código fuente del CITI.
La lógica general es que un proyecto de equipo puede contener un solo proyecto

lógico o varios, relacionados en forma de una suite de productos o la herramienta.
Los tres contenedores grandes se llaman de Development, QA y Builds.
En el contenedor Development se almacenan los archivos con los cuales

trabajaran los desarrolladores del proyecto, dentro de este, el contenedor Main
contiene en Sources la línea principal de desarrollo del proyecto. En Docs se
almacena la documentación generada del código fuente. Documentación no
generada, como los requisitos, documentos de diseño, planes de prueba, etc. no
va a ser reflejada por una carpeta en la estructura de control de código fuente sino
que utilizando la carpeta Documentos de Team Explorer la cual proporciona más
beneficio, ya que refleja la estructura en el Portal del Proyecto y además algunos
usuarios (de negocios) no necesitan conocer el trabajo del control de código con
TFS. En Dependencias se almacenan los binarios de terceros díganse (controles,
bibliotecas, etc.) que son utilizados por la solución.
Dentro de Development el contenedor Branches adquiere la estructura a partir de

crearse una rama en la carpeta de origen de la línea de desarrollo principal
(Development/Trunk/), esta se utiliza para apoyar el mantenimiento continuo del
84
producto o corrientes paralelas de desarrollo, además de que puede ser utilizada
para proporcionar aislamiento de características o de los equipos de desarrollo.
Cuando se desea hacer algún tipo de prueba o tarea que pueda corromper la línea
principal o gestionar cambios en una versión vieja, se puede utilizar una rama.
La carpeta QA en un principio se crea como una rama del contenedor

(Development/Trunk/). Aquí se almacenaran versiones estables que hayan sido
recomendadas para pasar a la colección Calidad para ser tratada en el laboratorio
de pruebas.
La carpeta Builds almacena todas las definiciones de construcciones de proyectos

ajenos a Visual Studio en TeamBuildTypes y en la carpeta BuildProcessTemplate,
carpeta generada por la plantilla de procesos con las distintas plantillas para
realizar las definiciones de builds como se mencionó anteriormente cuando se
crea un nuevo proyecto de equipo, se almacenan todas las plantillas de
construcciones.
3.4.1. Políticas de Check-in.
Unas de las ventajas que tiene el Control de Versiones de TFS es que permite
mediante una configuración adecuada de un conjunto de políticas, mantener el
desarrollo del código fuente bajo algunos parámetros de calidad.
Las políticas se configuran mediante el cliente a través de las opciones del Control
de Versiones de cada Proyecto de Equipo, aclarar que el alcance de las mismas
es a nivel de Proyecto de Equipo.
La Figura 16muestra la ventana de selección de políticas de check-in para aplicar a
un Proyecto. Algo importante es la capacidad de esta característica de ser
extensible, pueden implementar políticas de check-in propias y adicionar a TFS,
utilizando el modelo de objetos de este.
85
Figura 16Politicas de Check-in de TFS.
Como estrategia es factible el uso de algunas de estas políticas inmediatamente

de empezar a usar el Control de Versiones de TFS.
Con las investigaciones realizadas sobre el tema y unido a pruebas realizadas se

propone para los Proyectos de Equipo del ¡Error! No se encuentra el origen de la
eferencia., la aplicación de la política Changeset Comments Policy para garantizar
que todos los cambios subidos al repositorio tengan un comentario que de una
idea de que se va a almacenar con el check-in. Otra propuesta importante es el
uso de la política Custom Path Policy, (permite establecer otro conjunto de
políticas a una ruta especifica del repositorio de código) unido a la política
WokItems (establece que debe asociarse el check-in a un elemento de trabajo. Si
dicha política esta activada, cuando se realiza un checkin, el VSTS mediante un
diálogo permite asociar la acción al WI correspondiente. Otras políticas pueden
ser activadas por el Jefe de Proyecto.
Sobre la política de asociación del check-in con el WI se puede agregar que esta
es una de las ventajas del control de versiones de TFS ya que garantiza un
seguimiento completo desde el requisito o tarea hasta el código fuente que le da
solución. Además esta característica es aprovechada por los Informes de TFS
dando una vista más clara del avance del proyecto, garantizando mayor calidad en
86
el código fuente permitiendo la trazabilidad de los elementos de trabajo y los
fuentes de la solución.
3.5. Construcciones
Las construcciones automáticas son un proceso crucial dentro del ciclo de vida de
las aplicaciones. Para el correcto funcionamiento de este proceso se deben tener
en cuenta diversos aspectos, entre ellos está tener el repositorio de control de
versiones estructurado y organizado. Por eso después de control de versioneses
este el segundo elemento más importante que se puede hacer para mejorar la
calidad del software.
TFS proporciona un servidor de automatización con todas las funciones que
permite estandarizar la infraestructura de construcción del equipo. Las
generaciones del equipo se configuran en el sistema mediante una definición de
construcción que usa Windows Workflow 4.0 como mecanismo de orquestación
principal. Otras características notables son el mecanismo de check-in cerrados,
construcciones privadas, las notificaciones y alertas, donde TFS expone un modelo
de eventos completo y un API que permite integraciones personalizadas de
cualquier aplicación o dispositivo para poder recibir notificaciones de los resultados
de las construcciones, además proporciona dos sistemas de notificación
principales: herramienta de notificación de construcciones en Windows y alertas
por e-mail.[Blankenship et al.,2011; Gousset et al.,2010; J.D. Meier et al.,2007]
3.5.1. Arquitectura de Team Build
Un Build se define mediante una definición de build, la cual detalla el proceso de

construcción, incluyendo que debería ser construido, cómo y dónde; esta
pertenece a un TP en TFS. [Blankenship et al.,2011]
87
Figura 17 Arquitectura de Team Build
Como se muestra en la Figura 17cuando la capa de aplicación determina la

ejecución de una definición de build, envía una solicitud de build a un servicio web
corriendo en el BC (Build Controller por sus siglas en ingles). El BC, descarga la
plantilla del proceso de construcción basada en Windows Workflow 4.0 asociado a
la definición y la ejecuta. Esto produce que la generación se ejecute en un BA
(BuildAgentpor sus siglas en ingles), que este habilitado del conjunto de agentes
del BC. [Blankenshipet al., 2011]
Un BA es la máquina que ejecuta la construcción, cada uno tiene un BC como
padre, pero este último puede tener múltiples BA que puede usar para las
generaciones. Cada BC puede estar asignado a una TPC. [Blankenshipet a, 2011]
Un BA ejecuta la parte principal del proceso de construcción como se definió en la
plantilla de la definición del build, incluyendo las llamadas a MSBuild 28 para
ejecutar los pasos de prueba y compilación. Además expone un número de
servicios web que son usados para controlar el proceso de construcción por el BC.
[Blankenshipet al., 2011]
3.5.2. Mecanismos para la ejecución de las construcciones.
Existen una serie de disparadores que definen cuando una generación se va a

ejecutar. Este punto no es extensible en TFS, sin embargo, los tipos predefinidos
son muy amplios y abarcan la gran mayoría de escenarios de construcción que
pueden realizarse: [Blankenship et al., 2011; Gousset et al., 2010]
88
¾Manual: La construcción se iniciará manualmente por una persona, clientes de
terceros o código.
¾Integración Continua: Esto permite realizar una construcción en cada check-
in hacia el repositorio de control de versiones que afecta a las carpetas o ficheros
especificados previamente en la definición de la construcción.
¾Compilaciones acumuladas: Esto es similar a la activación mediante

integración continua. Sin embargo, los check-in se agrupan de manera que todos
los cambios dentro de un plazo definidos se incluyen en la compilación.
¾Check-in Cerrado: Este disparador obliga al cliente a subir el check-in como
un conjunto de cambios aplazados, en lugar de comprobar el código directamente
con el código del servidor, compila contra el código del área de trabajo.
¾Construcciones Programadas: Esto le permite configurar un tiempo en

determinados días de la semana en el cual la construcción se debe realizar.
3.5.3. Despliegue del Servidor de Compilación
Teniendo en cuenta la arquitectura del proceso de compilación y adicionando las

limitaciones de hardware, a continuación se plantea la propuesta de despliegue del
Servidor de Compilación:
¾Dos máquinas virtuales corriendo en un servidor, cada una de ellas con un
controlador de compilación instalado, uno para brindar servicios a la colección CITI
y el otro para la colección Calidad.
¾Cada equipo de proyecto debe tener en alguna de sus máquinas un agente de
compilación el cual será encargado de realizar los builds de sus soluciones, este
será configurado para formar parte del controlador correspondiente a su Colección
de Proyectos de Equipo.
La Figura 18 muestra la arquitectura de compilación propuesta, esta beneficia la

organización del proceso de compilación debido a que hay un aislamiento dentro
de los procesos de compilación de cada Proyecto de Equipo, además de que se
garantiza que las generaciones no padezcan de la inexistencia de un agente de
compilación disponible, ya que cada Proyecto de Equipo cuenta con uno, el cual
tendrá instalado lo necesario para realizar las generaciones de sus soluciones.
89
Figura 18 Propuesta de arquitectura de compilación para el CITI.
3.5.4. Estrategia para las build.
Luego de realizar un estudio de las características que brinda TFS en esta área,
además de recoger buenas prácticas de usuarios y empresas que usan la
herramienta, unido a un conjunto de pruebas realizadas utilizando los distintos
tipos de construcciones que propone la herramienta, a continuación se
mencionarán algunas propuestas que deben seguir los proyectos de la
organización para realizar las construcciones e integraciones de su código fuente.
Figura 19 Ventana de selección de tipo de build para realizar una definición.
La Figura 19muestra la opción selección de tipo de build, dentro de la ventana de

definición de construcciones. La propuesta consiste en crear los siguientes tipos de
definiciones de build:
90
¾Se propone realizar construcciones de tipo GatedCheck-in Builds, builds
rápidas y sencillas, para cada una de las soluciones que se encuentran en
desarrollo por el proyecto de equipo con el fin de que todo el código que se
resguarde en el repositorio sea útil y funcione correctamente.
¾Se propone la definición de Schedule-Builds(cada noche) donde se

programen construcciones con un conjunto de pruebas para cada uno de las
soluciones. Además si la aplicación consta de distintos módulos se propone definir
integraciones de este mismo tipo, lo que con menor frecuencia, preferentemente
uno o dos días a la semana, con el objetivo de analizar las distintas soluciones de
todos los desarrolladores del proyecto integradas y verificar su comportamiento.
¾Por ultimo para casos específicos (builds con métricas de código, análisis
estático de código, generar documentación, generar instaladores, etc.) o alguna
prueba inmediata que se necesite, o generar una versión completa, pueden
definirse Builds Manuales y ser ejecutadas posteriormente.
Otra de las ventajas que ofrece Team Foundation Build son los formularios para la
visualización de la ejecución de la build. Es posible analizar la mayoría de la
información sin tener que salir del mismo y además poder realizar acciones
básicas como acceder al directorio donde se encuentra los ficheros generados,
incluye una vista basada en Windows Presentation Foundation (WPF29) del archivo
plano de texto, que incorpora un navegador gráfico a la izquierda del mismo, para
ayudarnos a conocer qué sección del archivo de log estamos visualizando. El visor
de Log, también incluye un formato enriquecido para la visualización de
advertencias y errores. La Figura 20 muestra este formulario.
91
Figura 20 Formulario de visualización de la ejecución de una build.
Vale aclarar que todas estas estrategias que se proponen para realizar las
definiciones de builds son ejemplos de integración continua, facilitando la
detección de errores tempranamente, correr pruebas y ver el avance del proyecto
con cada check-in.
Todas las definiciones de build mencionadas antes pueden ejecutarse
manualmente de ser necesario, por ejemplo: un escenario donde un build nocturno
falla o no se realiza por algún motivo, el Jefe de Proyecto, o algún integrante del
grupo Builders, puede ejecutarlo a la mañana siguiente para asegurarse del buen
funcionamiento de los recursos de compilación.
Vale aclarar como ya se mencionó antes, que una buena organización y estructura
dentro del repositorio de código tributa a una eficiente realización del proceso de
construcciones automáticas, partiendo de esto, se proponen algunas buenas
prácticas que los proyectos de la organización deben seguir o tener en cuenta
durante el proceso de automatización de sus builds:
¾Dentro del repositorio se debe contar con una carpeta donde se almacenen las
dependencias a librerías de terceros usadas en nuestra solución a fin de garantizar
que la construcción pueda ser efectuada, ver epígrafe 3.4, donde aparece una
propuesta de organización para el repositorio de código dentro de TFS.
¾Los binarios generados por las compilaciones, necesarios para otras

soluciones deben estar en un espacio de trabajo común (carpeta de dependencias
que se mencionó en el epígrafe 3.4).
92
Esta estrategia de build puede ser adaptada o no por los proyectos del centro, no
obstante deben tener en cuenta las prácticas expuestas anteriormente a fin de
contar con un correcto y eficiente proceso de builds automáticos.
3.6. Despliegue.
La Figura 21 muestra la implementación adoptada en la organización para los

distintos niveles de TFS, así como la comunicación entre los mismo mediante los
diferentes protocolos.
Figura 21 Despliegue de TFS en el CITI
3.6.1. Requisitos de hardware.
Para la implementación de TFS en el centro solamente se necesita los recursos

para el Nivel de Compilación y el de Aplicación, los cuales se describirán más
adelante, debido a que ya que la capa de datos se resuelve integrándose a algún
servidor SQL Server del centro y la integración con SharePoint se resuelve
integrándose el servidor SharePoint montando en la institución.
Recomendaciones de Hardware para cada uno de las los niveles
¾Nivel de Aplicación: De 400 a 800 usuarios, se recomienda un procesador
único a 2.8 GHz, almacenamiento en disco 20 GB y memoria RAM 1 GB.
[Microsoft,2009]
93
¾Nivel de Compilación: Son iguales que los del sistema operativo en el que se
está ejecutando, salvo el espacio en disco. Más de 20 proyectos, de 100 a 250
usuarios, 50 GB de almacenamiento, más de 50 proyectos, de 250 a 500 usuarios,
80 GB de almacenamiento. [Microsoft, 2009]
¾Nivel del Cliente: Team Explorer, requisitos mínimos: procesador 2.0 GHz,
memoria RAM 512 MB, almacenamiento 8 GB. Requisitos recomendados:
procesador 2,6 GHz, memoria RAM 1 GB, almacenamiento 20 GB. [Microsoft,
2009] Team Explorer Everywhere, requisitos recomendados: procesador 1.6
GHz, Memoria RAM 1 GB, almacenamiento 3 GB. [Microsoft, 2009]
3.7. Flujo Básico.
La Figura 22 describe de manera resumida como el conjunto de componentes y

funcionalidades de TFS se orquesta para trabajar y desarrollar un producto durante
distintas fases del ciclo de vida, desde la definición de la solución hasta la entrega
de la misma.
Figura 22 Flujo básico de TFS
94
Dando algunas pinceladas del flujo que se describe en la Figura 22, podemos
argumentar que en el desarrollo de un producto van a intervenir los siguientes
roles: Funcionales (interesados en el producto), jefe o líder de proyecto y
miembros del equipo (desarrolladores, builders, etc.). El producto empieza su
desarrollo partiendo de un análisis con los interesados de donde nacen los
primeros requerimientos, estos se guardan como elementos de trabajo de tipo
requisitos y tareas, los cuales comienzan a tener un seguimiento dentro de TFS.
Después de esto el protagonismo pasa a los miembros del equipo que deben
responder con artefactos, componentes, código fuente que resuelva esta tarea,
estos se almacenan en el control de versiones de TFS, y se vinculan a los
elementos de trabajos que le da solución, aprovechando las políticas de check-in,
descritas anteriormente. Luego de esto interviene en este ciclo el servidor de
integración o compilaciones (Team Foundation Build) el cual mediante políticas o
estrategias de integración definidas, o simplemente de forma manual ejecuta las
builds y compila e integra la información en el repositorio de código fuente
sometiéndola a procesos como análisis estático de código, o un conjunto de
pruebas unitarias y funcionales, etc. Como resultado se obtienen binarios (dll, msi,
jar, exe,,zip, rar, etc). Al tener una versión estable del producto se envía este al
Laboratorio de Pruebas en el cual se le aplican un conjunto de baterías de pruebas
más riguroso. Como resultado de esto se pueden obtener nuevos elementos de
trabajo de tipo Bug, No conformidades los cuales se envían de vuelta a los
miembros del equipo, para ser solucionados y obtener una nueva versión, y de
esta forma realizar otra iteración en el laboratorio. Una vez realizada las pruebas
en el laboratorio, si todo procede satisfactoriamente, se obtiene una solución final
con calidad la cual es desplegada pasando a ser usada por los funcionales.
3.8. Alineación de TFS con las vistas de Proceso de CMMI en el
contexto del CITI
Como se ha venido explicando TFS cuanta con un conjunto de áreas que dan soporte
al ciclo de vida de los proyectos de la organización, por otra parte el proceso de
mejora basado en CMMI que está llevando a cabo el CITI ha definido un conjunto de
vistas de procesos que debe seguir los proyectos de la entidad.
En la Tabla 3 se muestra la alineación de las vistas definidas en el CITI para la mejora

de procesos con CMMI y las áreas de TFS.
95
Vistas de Procesos Áreas de TFS
Seguimiento Control de Automatización Reportes y
de Elementos Versiones de las Dashboards
de Trabajo Compilaciones
Procesos de Ingeniería
Modelado del Negocio X X
Gestión de Requisitos X
Análisis y Diseño X X
Implementación X X X
Prueba X X X
Despliegue X
Procesos de Gestión de Proyectos
Planificación de proyectos X X
Monitoreo y Control X X
Gestión de acuerdos con X X
Proveedores
Gestión de Riesgos X X
Procesos Empresariales (Gestión de Procesos)
Control y Registro de la X X X
Documentación
Procesos de Soporte
Gestión de la Configuración X X X X
Medición y Análisis X
Aseguramiento de la Calidad X X X X
del Proceso y del Producto
Tabla 3 Vistas de Procesos CMMI en el CITI vs áreas de TFS
Para las disciplinas de Modelado de Negocio, Análisis y Diseño e Implementación

de la vista de Proceso de Ingeniería, TFS proporciona un repositorio para versionar
el resultado de estas, además de facilitar su seguimiento y relación con los
elementos de trabajo, garantizando la traceabilidad desde los requisitos y tareas
hasta el modelo y código fuente. Las disciplinas de Prueba y Despliegue la
herramienta los resuelve con su mecanismo de automatización de las
compilaciones (Team Build) el cual garantiza la integración de las soluciones,
además con la realización de baterías de prueba a fin de obtener un producto final
con la calidad requerida. La integración de TFS con las herramientas Microsoft
Test Management y el Lab. Management proveen al equipo de desarrollo de
instrumentos para realizar disimiles pruebas al producto y luego desplegarlo en
diferentes entornos garantizando su correcto funcionamiento.
Con respecto a la vista de Procesos de Gestión la cual cuenta con las disciplinas
de Planificación de proyectos, Monitoreo y Control, Gestión de acuerdos con
Proveedores y Gestión de Riesgos TFS cuenta con el área de Seguimiento de
Elementos de Trabajo explicada anteriormente. Para la disciplina de Acuerdo con
proveedores que hoy el centro lo recoge en un documento se puede gestionar
igual que la documentación de los proyectos de la organización.
96
La integración de TFS con SharePoint, además del propio controlador de versiones
nativo de la herramienta facilita el proceso de Control y Registro de la
Documentación ya que al tener un portal a nivel de proyecto, se puede gestionar
toda la documentación referente a los mismos en SharePoint o en el repositorio de
versiones.
Vale mencionar que los Reportes y Dashboards con el que cuenta la herramienta
en su plantilla de procesos y las facilidades que proporciona para la definición de
estos garantiza seguir y medir el avance del proyecto, potencialidad que favorece a
la mayoría de las Áreas de Procesos.
Por último la vista de Procesos de Soporte que como se evidencia tiene una fuerte
relación con las disciplinas de Gestión de la Configuración y Aseguramiento de la
Calidad del Proceso y del Producto ya que TFS proporciona seguimiento completo
a cada uno de los artefactos a los cuales se le gestione la configuración para de
esta manera garantizar la calidad de cada uno de ellos.
3.9. Conclusiones
A lo largo de este capítulo se han explicado las transformaciones realizadas a la

herramienta en aras de adaptarla al funcionamiento y flujo de trabajo de la Institución.
Se describió el despliegue de la herramienta y la estructura seleccionada para
representar los proyectos del centro. Además se han expuesto un conjunto de buenas
prácticas a tener en cuenta por los distintos proyectos para que la asimilación de la
herramienta no sea un choque, y todos los procesos del ciclo de vida sean
emprendidos correctamente.
Quedó expuesto el flujo de trabajo que va a seguir la organización una vez desplegada
la herramienta así como el proceso de desarrollo a seguir teniendo en cuenta los
avances de la entidad en el proceso de mejora.
Se mostró la relación que existe entre la herramienta seleccionada y el proceso de

desarrollo definido en el capítulo anterior.
97
Conclusiones
4. Conclusiones
A partir del estudio y análisis de las metodologías y procesos de desarrollo de software
existentes se ha propuesto un proceso que combina las mejores prácticas de estos,
adaptado a las condiciones en que se desarrollan los proyectos en el CITI. Para dar
respuesta a esta necesidad se define una propuesta que contiene como base RUP y
es guiada por AUP, debido a que ambos son procesos de desarrollo, que pueden ser
adaptados al entorno.
Se realizó un estudio sobre ALM dejando claras las ventajas que proporciona este
enfoque aplicado a las empresas de producción de software.
Se seleccionó TFS como propuesta de herramienta ALM para su implantación en el

CITI.
Durante el desarrollo de este trabajo se han obtenido los siguientes resultados:
¾ Definición de una propuesta, para el desarrollo de software en el CITI, a partir

de las mejores prácticas y sistematización de las disciplinas.
¾ Flujos de trabajo para las disciplinas Modelado, Implementación, Prueba y

Despliegue.
¾ Fichas de las actividades que contienen buenas prácticas, plantillas de

artefactos.
¾ Artefactos para cada una de las actividades de estos flujos.
¾ Integración con proceso de desarrollo, y a la metodología CMMI.
¾ Garantizar la integración con las soluciones ya establecidas en la entidad.
¾ Garantizar un seguimiento completo de todos los elementos de trabajo (tareas,

requisitos, riesgos, errores, etc.).
¾ Centralizar la información de todas las soluciones de la organización, pudiendo

obtener métricas y reportes de estas.
¾ Garantizar la gestión de todo el proceso de desarrollo con una única

herramienta.
¾ Se detallaron un conjunto de buenas prácticas y estrategias para guiar a la

organización a una mejor gestión de sus soluciones.
¾ Se estableció la infraestructura para el pilotaje de los proyectos con las

adaptaciones hechas de acuerdo a las AP de CMMI ya definidas en la entidad.
98
Conclusiones
En general, con la puesta en marcha de TFS basado en el flujo de trabajo propuesto la

Institución da los primeros pasos en aras de alcanzar mayor madurez, solides y
calidad en sus soluciones.
99
Recomendaciones
5. Recomendaciones
En el documento se reflejan los aspectos fundamentales que conforman la
propuesta inicial para el desarrollo de software en el CITI soportado por TFS como
herramienta para la gestión de sus soluciones, por lo que se recomienda:
¾ Continuar con el estudio sobre sus fases y se incorporen las restantes

disciplinas en aras de culminar la propuesta presentada.
¾ Crear, de ser necesario, las Plantillas y/o Guías y/o Listas de Chequeo en
los artefactos que no se tuvieron en cuenta para esta propuesta inicial.
¾ Poner en práctica los lineamientos y técnicas ágiles presentados en la

propuesta y observar su impacto en el entorno del CITI.
¾ Profundizar en la actividad Analizar Aspectos de Seguridad, con el objetivo

de garantizar que los productos desarrollados en el CITI, tengan los
atributos de seguridad requeridos, teniendo en cuenta que las soluciones
obtenidas serán desplegadas en el MININT.
¾ Definir un conjunto de métricas e indicadores con el objetivo de validar la

propuesta presentada.
¾ Llevar a cabo un proceso de mejora continua una vez implantada la

propuesta en los proyectos del CITI.
¾ Profundizar en el proceso de generación de construcciones automáticas así

como en sus plantillas a fin de enriquecerlo con pruebas automáticas, análisis
estático de código, con el objetivo de modificarlas para generar instaladores en
las distintas tecnologías.
¾ Abundar e investigar en el proceso de Pruebas y Aseguramiento de la Calidad

con TFS a fin de establecer todo un entorno de pruebas, donde se utilicen los
binarios generados por las construcciones automáticas de TFS.
¾ Crear una capa de servicios para facilitar las necesidades inmediatas y futuras
del centro, así como la alineación con el proceso de mejora con CMMI.
100
Referencias Bibliográficas
6. Referencias Bibliográficas
[Agile Alliance,2008] Agile Alliance. 2008.http://www.agilealliance.org/
[Alliance,2008] Alliance, A. Agile Alliance, 2008. [2009]. Disponible en:

http://www.agilealliance.org/
[Ambler,2006] Ambler, S. Agile Unified Process., 2006. [Disponible en:

http://www.ambysoft.com/unifiedprocess/agileUP.html
[Ambysoft,2009] Ambysoft. The Agile Unified Process (AUP), 2009. [2009].

Disponible en: http://www.ambysoft.com/unifiedprocess/agileUP.html
[Baer,2011] Baer, T. MKS Integrity V2009 sp4 OVUM,

2011.http://www.mks.com/resources/data/documents/reports/ovum-technology-
audit-for-application-lifecycle-management-mks-integrity-v2009-sp4/at_download/file
[Blankenship et al.,2011] Blankenship, E.; M. Woodward, et al. Professional

Team Foundation Server 2010. Wiley Publishing, Inc., 2011. p.
[Borland,2007] Borland. Open Application Lifecycle Management (ALM). UNLOCKING

THE FULL VALUE OF MANAGED SOFTWARE DELIVERY,
2007.http://www.borland.com/resources/en/pdf/company/open-alm-whitepaper.pdf
[Business-Software,2011a] Business-Software. Benefits of Application Lifecycle

Management Software, 2011a. [Disponible en: http://www.business-
software.com/application-lifecycle-management/benefits-of-application-lifecycle-
management-software.php
[Business-Software,2011b] ---. TOP 10 Application Lifecycle Management Software

Vendors REVEALED 2011b.http://www.Business-Software.com/ALM
[Carralero,2008] Carralero, M. J. Un enfoque integrador para el desarrollo de

software, Instituto Superior Politécnico José Antonio Echeverría, 2008.
[CITI,2010] CITI. Manual para el desarrollo de software en el CITI, 2010.
[Cockburn,2001] Cockburn, A. The Agile Software Development. 2001. p.
[Corporation,2002] Corporation, R. S. Rational Unified Process Best Practices for

Software Development Teams, 2002.www.rational.com
[CHAPPELL,2010] CHAPPELL, D. APPLICATION LIFECYCLE MANAGEMENT AND

BUSINESS STRATEGY 2010.
[David et al.,2006] David, J.-L.; T. Loton, et al. Professional Visual Studio 2005
Team System. Wiley Publishing, Inc., 2006. p.
101
[Dorfman and Thayer,1997] Dorfman, M. and R. Thayer. Software Engineering. Los

Alamitos, CA. , 1997. p.
[Duncan,2010] Duncan, S. Oracle Team Productivity Center Overview 2010.
[Fernández,2011] Fernández, P. HP ALM 11: En busca de la aplicación perfecta,

2011. [Disponible en: http://www.eweekeurope.es/knowledge-center/hp-alm-11-en-
busca-de-la-aplicacion-perfecta-9435
[Fowler,2001a] Fowler, M. Martin Fowler, 2001a. [2009]. Disponible en:

http://www.martinfowler.com.
[Fowler,2001b] ---. Martin Fowler.com, 2001b. [2009]. Disponible en:

http://www.martinfowler.com.
[Gartner,2011] Gartner. Magic Quadrant for Integrated Software Quality Suites,

2011.http://blogs.gartner.com/tom_murphy/2011/01/31/magic-quadrant-for-
integrated-software-quality-suites/
[Gousset et al.,2010] Gousset, M.; B. Keller, et al. Professional Application LIfecycle

Management with Visual Studio 2010. Wiley Publishing, Inc., 2010. p.
[Hernández,2010] Hernández, A. G. Revisión bibliográfica sobre el tema de

clasificación de proyecto, 2010.
[Highsmith,2001] Highsmith, M. F. a. J. The Agile Manifesto,

2001.www.martinfowler.com/articles/newMethodology.html
[HP,2011a] HP. Development management with HP Application Lifecycle

Management software and new HP Development Tool integrations,
2011a.https://h10078.www1.hp.com
[HP,2011b] ---. HP Application Lifecycle Management 11 New solutions empower

clients to better plan, build and release quality applications to accelerate innovation
2011b.https://h10078.www1.hp.com
[IBM,2011] IBM. Ayuda Rational Team Concert. Visión general del producto, 2011.
[Disponible en:
http://publib.boulder.ibm.com/infocenter/rtc/v2r0m0/index.jsp?topic=/com.ibm.tea
m.concert.doc/topics/c_product-overview.html
[IEEE,2001] IEEE. IEEE Standard for Software Life Cycle Processes Risk
Management, 2001.
[Ivar Jacobson,2000] Ivar Jacobson, G. B., James Rumbaugh. El Proceso Unificado de

Desarrollo de Software. 2000. p. 84-7829-036-2
[J.D. Meier et al.,2007] J.D. Meier; Jason Taylor, et al. Team Development with Visual
Studio Team Foundation Server. 2007. 496 p.
102
[James Rumbaugh,1999] James Rumbaugh, I. J., Grady Booch. The Unified

Modeling Language Reference Manual. 1999. p. 0-201-30998-X
[Janet E. Burge,2008] Janet E. Burge, J. M. C., Raymond McCall, Ivan Mistrík.

Rationale-Based Software Engineering. 2008. p. 978-3-540-77582-9
[Jazz.net,2011a] Jazz.net. Rational Team Concert Features, 2011a. [Disponible

en: http://jazz.net/projects/rational-team-concert/features/
[Jazz.net,2011b] ---. Rational Team Concert. A collaborative software

development environment, 2011b. [Disponible en: http://jazz.net/projects/rational-
team-concert/
[Jones,2010] Jones, M. Understanding application lifecycle management's complex

identity, 2010. [Disponible en:
http://searchsoftwarequality.techtarget.com/resources/Application-Lifecycle-
Management-Software-Fundamentals
[Kent Beck 2000a] Kent Beck , M. F. eXtreme Programming Explained. 2000a. p. 0-

321-27865-8
[Kent Beck 2001] ---. Extreme Programming Installed. 2001. p.
[Kent Beck 2000b] ---. Planning eXtreme Programming. 2000b. p.
[Kruchten,2001] Kruchten, P. The Rational Unified Process, An Introduction,

Second Edition, 2001.
[Lanowitz,2011] Lanowitz, T. HP - Application Lifecycle Management (ALM) 11,

2011.https://h10078.www1.hp.com
[Len Bass,2003] Len Bass, P. C., Rick Kazman. Software Architecture in Practice, Second
Edition. 2003. p. 0-321-15495-9
[Lizama,2006] Lizama, H. R. Application lifecycle management making a difference,

2006. [Disponible en:
http://www.cbronline.com/comment/application_lifecycle_management_making_a_d
ifference
[Mark Lines,2008] Mark Lines, S. W. A., Joshua Barnes. Agile RUP: Experiences
from the trenches, 2008. [2009]. Disponible en:
http://www.ibm.com/developerworks/rational/library/edge/08/feb08/lines_barnes_h
olmes_ambler/index.html
[Martorell,2006] Martorell, A. Softwaere Configuration Management (SCM),

2006.http://www.ort.edu.uy/fi/publicaciones/ingsoft/investigacion/ayudantias/VSTS_
GestionConfiguracion.pdf
103
[Méndez,2008] Méndez, G. Proceso Software y Ciclo de Vida, Dpto. de Ingeniería de

Software e Inteligencia Artificial Facultad de Informática Universidad Complutense de
Madrid, 2008.http://www.agilealliance.org/system/article/file/1135/file.pdf
[Microsoft,2011a] Microsoft. Microsoft Visual Studio Team Foundation Server

2010, 2011a. [Disponible en: http://www.google.com/gwt/x?oe=utf-8&client=firefox-
a&q=ventajas+Team+Foundation+Server&ei=5RxkTbDvKcKNlge9ialr&ved=0CAgQFjAB
&hl=es&source=m&rd=1&u=http://www.microsoft.com/business/smb/es-
es/servidores-y-herramientas/visual-studio.mspx
[Microsoft,2009] ---. TFSInstall,

2009.http://www.microsoft.com/downloads/en/details.aspx?familyid=E54BF6FF-
026B-43A4-ADE4-A690388F310E&displaylang=en
[Microsoft,2011b] Microsoft, M. Extender Visual Studio Application Lifecycle

Management, 2011b. [Disponible en: http://msdn.microsoft.com/es-
es/library/dd470570.aspx
[MKS,2011a] MKS. ALM, A Unified Engineering Platform for Product Development,

2011a. [Disponible en: http://www.mks.com/solutions/discipline/application-lifecycle-
management
[MKS,2011b] ---. End-to-End Coverage 2011b. [Disponible en:

http://www.mks.com/solutions/discipline/overview
[MKS,2011c] ---. Managing Change Across Development, 2011c. [Disponible en:

http://www.mks.com/platform/our-product
[MKS,2011d] ---. Process & Methodology 2011d. [Disponible en:

http://www.mks.com/solutions/process/process-overview
[NotionSolutions,2011] NotionSolutions, A. Activities and Disciplines 2011. [Disponible

en: http://www.notionsolutions.com/alm/Pages/ActivitiesDisciplines.aspx
[NotionSolutions,2009a] ---. ALM Activity Summary, 2009a. [Disponible en:

http://www.notionsolutions.com/alm/Pages/ALMActivities.aspx
[NotionSolutions,2009b] ---. ALM Discipline Summary, 2009b. [Disponible en:

http://www.notionsolutions.com/alm/Pages/ALMDisciplines.aspx
[Pekka Abrahamssom,2002] Pekka Abrahamssom. Agile Software Development

Methods. 2002. p. 951-38-6010-8
[Per Kroll,2003] Per Kroll, P. K. Rational Unified Process Made Easy: A Practitioner's
Guide to the RUP. 2003. p. 0-321-16609-4
[Pete Deemer,2007] Pete Deemer, G. B. The SCRUM Primer An Introduction to Agile

Project Management with Scrum, 2007.
104
[Piattini,2006] Piattini, M. Calidad de sistemas informáticos. 2006. p. 84-7897-734-1
[Piattini,2007] ---. Fabricas de softtware: Experiencias tecnologías y organizacion.

2007. p. 978-4-7897-809-0
[Polarion,2011] Polarion. Polarion ALM, Everything You Need in One Single ALM
Solution, 2011. [Disponible en: http://www.polarion.com/products/alm/index.php
[Prabhudas,2007] Prabhudas, S. Agile Unified Process,

2007.http://tarpit.rmc.ca/cficse/2002/lectures/GL/Agile%20Modeling%20and%20Agile
%20Data.pdf
[Pressman,2002a] Pressman, R. Ingeniería del Software Un Enfoque Práctico

Quinta edición. 2002a. p. 0-07-709677-0
[Pressman,2002b] ---. Ingeniería del Software Un Enfoque Práctico Sexta edición.

2002b. p. 0-07-709677-0
[Pronschinske,2009] Pronschinske, M. Top ALM Tools and Solutions Providers, 2009.

[Disponible en: http://architects.dzone.com/news/top-10-alm-
solutions?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zo
nes%2Fsoa+(SOA+Zone)
[Rally,2011] Rally. 2011. [Disponible en:

http://www.rallydev.com/company/news_events/press/2009-125-rally-software-
expands-global-reach-of-its-agile-alm-solutions-with-uk-office.html
[Raona,2009] Raona. Qué es ALM?, 2009. [Disponible en:

http://www.raona.comes_esOfferingCustomDevelopmentalmPaginasalm.aspx/alm.as
px.htm
[Rational,2003] Rational, C. S. Rational Unified Process, 2003.
[Reinboldt,2011] Reinboldt, B. Application Life Cycle Management 2011.

[Disponible en: http://www.lovemytool.com/blog/2011/02/application-life-cycle-
management-by-brad-reinboldt-.html
[Rotibi,2010] Rotibi, B. JAZZ: IBM Rational’s open framework for smart business
valued software delivery
2010.http://www.informationweek.com/whitepaper/Software/Productivity-
Applications/-ibm-rational-s-open-framework-for-smart-business-wp1296492102121
[Ruiz,2009] Ruiz, H. L. Plan Estratégico del Complejo de Investigaciones

Tecnológicas Integradas Ciudad de la Habana
2009.http://portalciti/ProcesoMejora/Paginas/EPG.aspx
[Schwaber,2005] Schwaber, K. SCRUM Development Process. 2005. p.
105
[Seapine,2011] Seapine. 2011. [Disponible en:

http://www.seapine.com/seapinealm.html
[SEI,2006] SEI. CMMI for Development,Version 1.2. . Pittsburgh, SEI, 2006. p.

CMU/SEI-2006-TR-008
[Shrum,2009] Shrum, M. B. C. M. K. S. Guía para la integración de procesos y la

mejora de productos. 2009. p. 9788478290963
[Smith,2001] Smith, J. A Comparison of RUP and XP. CORPORATION., R. S., 2001.
[technologyexecutivesclub,2011] technologyexecutivesclub. Borland the Open

ALM Company, 2011. [Disponible en:
http://www.technologyexecutivesclub.com/sponsorpages/borland.php
106
Glosario de Siglas y Términos
7. Glosario de Siglas y Términos
1
CITI: Siglas de Complejo de Investigaciones Tecnológicas Integradas.
2
LP: Líderes de Proyecto
3
XP: Siglas de Programación Extrema (en inglés eXtreme Programming).
4
AUP: Siglas de Proceso Unificado Ágil (en inglés Agile Unified Process).
5
RUP: Siglas de Proceso Unificado de Rational (en inglés Rational Unified
Process).
6
IDE: Siglas de Entorno de Desarrollo Integrado (en inglés Integrated
Development Environment). Es un entorno de programación que ha sido
empaquetado como un programa de aplicación, es decir, consiste en un
editor de código, un compilador, un depurador y un constructor de interfaz
gráfica
7
Plugins: Enchufable. Es una aplicación que se relaciona con otra para
aportarle una función nueva y generalmente muy específica. Esta aplicación
adicional es ejecutada por la aplicación principal e interactúan por medio de
una API o algún servicio.
8
ALM: Siglas de Gestión del Ciclo de Vida de las Aplicaciones (en inglés
Application Lifecycle Management).
9
PDS: Proceso de Desarrollo se Software
10
IS: Ingeniería del software
11
Artefactos: Fragmento de información que es producido, modificado o
utilizado por un proceso; define un área de responsabilidad y está sujeto a
un control de versiones. Constituye las entradas y salidas de las
actividades.
12
Roles: Definen la conducta y las responsabilidades de uno o varios
individuos que trabajan juntos como equipo en el contexto de una
organización de ingeniería de software.
13
Actividades: Unidad de trabajo que es desempeñada por un rol.
14
UML: Siglas de Lenguaje Unificado de Modelado (en inglés Unified Model
Language).
15
ED: Equipo de Desarrollo
16
TDD: Siglas de Desarrollo guiado por Pruebas (en inglés Test Driven
Development).
17
KPA: Áreas Claves del Proceso (Key Process Area)
107
18
CMMI: Siglas de Integración de Modelos de Madurez de Capacidades (en
inglés Capability Maturity Model Integration). Es un modelo para la mejora y
evaluación de procesos para el desarrollo, mantenimiento y operación de
sistemas de software.
19
Jazz: Plataforma extensible de colaboración de equipos que integra las
tareas realizadas a lo largo del ciclo de vida de desarrollo del software.
20
Tabla Gantt: Gráfico que sirve para programar tiempos y actividades de
proyectos y el control de sus ejecuciones.
21
Dashboards: Cuadro de mando. Engloba a varias herramientas que
muestran información relevante para la empresa a través de una serie de
indicadores de rendimiento, también denominados KPIs.
22
LDAP: Siglas de Protocolo Ligero de Acceso a Directorios (Lightweight
Directory Access Protocol). Es un protocolo a nivel de aplicación que
permite el acceso a un servicio de directorio ordenado y distribuido para
buscar diversa información en un entorno de red.
23
REST: Siglas de Transferencia de Estado Representacional (en inglés
Representational State Transfer). Es una arquitectura basada en acciones
sobre recursos, para permitir la interacción de un cliente con un servidor.
24
Check-in: Operación del control de versiones de TFS en la cual se suben
los cambios del espacio de trabajo hacia el repositorio central de control de
versiones.
25
WebParts: Es un control de ASP.NET que se añade a una página de
elementos web por los usuarios en tiempo de ejecución y permite a los
usuarios modificar el contenido, la apariencia y el comportamiento de las
páginas Web directamente desde un navegador.
26
API: Siglas de Interfaz de Programación de Aplicaciones (en inglés
Application Programming Interface). Es el conjunto de funciones y
procedimientos (o métodos, en la programación orientada a objetos) que
ofrece cierta biblioteca para ser utilizado por otro software como una capa
de abstracción.
27
Funcional: Persona asignada por la dirección de la organización,
responsables de comunicar las necesidades de los clientes y usuarios.
28
MSBuild: Es el sistema de build usado por Visual Studio. Se instala como
parte del framework .NET.
WPF: Siglas de Windows Presentation Foundation. Es una tecnología de

29
Microsoft que permite el desarrollo de interfaces de interacción en Windows
108
tomando las mejores características de las aplicaciones Windows y de las

aplicaciones web.
109

Definición de Un Proceso de Desarrollo de Software en Un Entorno PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Definición de Un Proceso de Desarrollo de Software en Un Entorno PDF

Transféré par

Droits d'auteur :

Formats disponibles

Instituto Superior Politécnico José Antonio

Daynel Díaz Polo

Definición de un proceso de desarrollo de software en un entorno universitario. – La Habana

Dewey: 621.39 Ingenieía de computadoras.

(cc) Daynel Díaz Polo, 2011.

Centro de Estudios de Ingeniería y Sistemas

Definición de un proceso de desarrollo de software en

Tesis presentada en opción al Título de Máster en Informática Aplicada

Autor: Ing. DaynelDíaz Polo

Tutor: Dra. Martha Dunia Delgado Dapena

Ciudad de La Habana, Cuba

En fin gracias a todos por el apoyo incondicional ….

Teniendo en cuenta las características del Complejo de Investigaciones Tecnológicas

En el presente documento, se hace un estudio de los distintos tipos de procesos y

Se hace necesario destacar que este entorno de desarrollo presenta características

El desarrollo de aplicaciones informáticas es cada vez más complejo y se encuentra

Es abrumadora la cantidad de paradigmas, tecnologías y herramientas que existen y

Hasta hace pocos años, un desarrollador de software que quisiera utilizar

Existen muchas herramientas ALM, según [Business-Software,2011b]

El problema de esta investigación se expresa en la pregunta siguiente ¿Es posible

El objeto de estudio lo constituyen los procesos de desarrollo de software,

El campo de acción es el desarrollo de proyectos de software en las condiciones del

Proponer un entorno para el desarrollo de los proyectos de software en el CITI.

¾ Definir las disciplinas para el desarrollo de proyectos de software adecuado a

¾ Proponer una herramienta, de Administración del Ciclo de Vida del Software,

¾ Analizar las potencialidades de los Metodologías Ágiles y RUP para identificar

¾ Estudiar los paradigmas actuales para el desarrollo de software.

¾ Estudiar un conjunto de áreas claves en los procesos de desarrollo de

¾ Caracterizar el entorno desarrollo para el cual se propone la investigación.

¾ Identificar herramientas que de soporte a la administración del ciclo de vida del

¾ Definir una arquitectura donde se integre la herramienta seleccionada y las

¾ Entrevistar a los jefes de proyecto para entender las características de estos.

¾ Estudiar el CITI y las condiciones en que se trabaja en la organización.

¾ Clasificar los proyectos del CITI, según sus características.

¾ Estudiar las metodologías y procesos de desarrollo de software existentes.

¾ Seleccionar una herramienta de acuerdo a los criterios de comparación que se

¾ Identificar que procesos o actividades dentro del ciclo de vida se van a

¾ Integrar la herramienta con las soluciones existentes en el centro.

¾ Documentar la solución propuesta.

El presente trabajo está formado por introducción, tres capítulos, conclusiones,

En el segundo capítulo denominado Entorno para el desarrollo de software en el CITI,

En el tercer capítulo se exponen la configuración y personalización de la herramienta

Como parte de la definición de este proceso de desarrollo de software se realizaron

1. Procesos de Desarrollo de Software

En este capítulo se presenta un estudio de conceptos esenciales en la ingeniería de

1.2. Proceso de desarrollo de software

Como se define en [Pressman,2002b] “Cuando se trabaja para construir un producto o

Figura 1 Capas de la Ingeniería de Software

Conjunto de pasos y procedimientos que deben seguirse para el desarrollo del

Algunos autores definen las metodologías como un conjunto de procedimientos,

1.3. Metodologías de Desarrollo de software

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la

La metodología de desarrollo que se siga en un PDS tiene un factor de peso

caótica a menudo caracterizada por la frase Codificar y Arreglar.” [Fowler,2001a;

Existe un movimiento que se ha dado a conocer como la “Alianza Ágil” o “Movimiento

1.3.1. Proceso Unificado de Rational

“El Proceso Unificado de Racional es más que un simple proceso; es un marco de

Provee un enfoque para asignar tareas y responsabilidades dentro de una

¾ El eje horizontal representa el tiempo y muestra los aspectos dinámicos del

¾ El eje vertical representa los aspectos estáticos del proceso como la

Figura 2Proceso Unificado de Rational

En la Figura 2 se puede apreciar que RUP se divide en cuatro fases:[Per Kroll,2003]

¾ Elaboración: Tiene como propósito analizar el dominio del problema, definir la