Академический Документы
Профессиональный Документы
Культура Документы
Echeverría CUJAE
DEFINICIÓN DE UN PROCESO
DE DESARROLLO DE
SOFTWARE EN UN ENTORNO
UNIVERSITARIO.
La Habana, 2011
Tesis de Maestría
Página Legal
ddiazp@udio.cujae.edu.cu
Profesor Titular
marta@ceis.cujae.edu.cu
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.
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.
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]
Todos estos elementos dan origen al problema que ocupa la presente investigación.
Objetivo General
2
Objetivos específicos
Para cumplir con los objetivos planteados se han definido las siguientes Tareas:
¾ Realizar un estudio del estado del arte de las herramientas que intervienen en
la administración del ciclo de vida del software.
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.
4
Procesos de Desarrollo de Software
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).
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
Procesos de Desarrollo de 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.
6
Procesos de Desarrollo de Software
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]
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]
7
Procesos de Desarrollo de Software
¾ 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.
8
Procesos de Desarrollo de Software
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]
9
Procesos de Desarrollo de Software
10
Procesos de Desarrollo de Software
¾ 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]
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]
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]
12
Procesos de Desarrollo de Software
13
Procesos de Desarrollo de Software
14
Procesos de Desarrollo de Software
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]
15
Procesos de Desarrollo de Software
16
Procesos de Desarrollo de Software
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.
17
Procesos de Desarrollo de Software
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.
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
Procesos de Desarrollo de Software
¾ Sub prácticas: Son descripciones detalladas que proveen guías para interpretar
prácticas específicas o genéricas.
19
Procesos de Desarrollo de Software
¾ Á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.
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]
20
Procesos de Desarrollo de Software
“…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]
21
Procesos de Desarrollo de Software
“…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]
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
Procesos de Desarrollo de Software
Una vez concluida esta actividad se procede al Diseño, aquí se diseña la solución para
satisfacer los requisitos definidos.
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 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.
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]
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]
25
Procesos de Desarrollo de Software
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]
26
Procesos de Desarrollo de Software
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.
27
Procesos de Desarrollo de Software
20
programadas y un editor de tabla Gantt para crear planes de proyectos.
[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]
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]
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
Procesos de Desarrollo de Software
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]
29
Procesos de Desarrollo de Software
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]
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
Procesos de Desarrollo de Software
con Visual Studio / TFS y Eclipse, que crea la trazabilidad entre los requisitos, defectos
y código fuente. [HP, 2011b]
31
Procesos de Desarrollo de Software
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
Procesos de Desarrollo de Software
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.
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]
¾ Check-in Atómicos:
¾ Relación de check-in - WI:
¾ Shelving:
¾ Políticas de check-in:
¾ Notas de check-in:
¾ Proxy de TFS:
34
Procesos de Desarrollo de Software
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]
35
Procesos de Desarrollo de Software
36
Procesos de Desarrollo de Software
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.
37
Procesos de Desarrollo de Software
CMMI
PDS Flexible y SI Si Si Si Si
adaptable
Tabla 1: Aspectos de selección para la herramienta ALM
1.13. Conclusiones
38
Procesos de Desarrollo de Software
¾ 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.
39
Entorno para el desarrollo de software
en el CITI
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]
40
Entorno para el desarrollo de software
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.
41
Entorno para el desarrollo de software
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.
42
Entorno para el desarrollo de software
en el CITI
43
Entorno para el desarrollo de software
en el CITI
4. Analizar los sistemas o recursos que pueden ser heredados o utilizados por
otros sistemas.
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.
44
Entorno para el desarrollo de software
en el CITI
1. Definir o Refinar la arquitectura
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.
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.
45
Entorno para el desarrollo de software
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.
La arquitectura debe dar soporte a los procesos de negocio y debe poder evolucionar
con este.
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.
46
Entorno para el desarrollo de software
en el CITI
sistema, tales como fuentes de datos, interfaces de programación de
aplicaciones (por sus siglas en inglés API), servicios web.
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.
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.
47
Entorno para el desarrollo de software
en el CITI
2. Diseñar los elementos principales de interfaz de usuario, visualizando las
ventanas primarias que deberá tener dicha interfaz.
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.
1. Analizar los casos de uso para identificar las clases de análisis y las relaciones
requeridas para su realización.
48
Entorno para el desarrollo de software
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.
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.
49
Entorno para el desarrollo de software
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.
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
Entorno para el desarrollo de software
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].
51
Entorno para el desarrollo de software
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]
52
Entorno para el desarrollo de software
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:
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
Entorno para el desarrollo de software
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.
Tener en cuenta una lista de chequeo con el conjunto de pruebas de mayor relevancia
a realizar en cada iteración.
54
Entorno para el desarrollo de software
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.
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:
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.
55
Entorno para el desarrollo de software
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
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.
56
Entorno para el desarrollo de software
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.
57
Entorno para el desarrollo de software
en el CITI
58
Entorno para el desarrollo de software
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.
4. Definir la lista con los aspectos identificados, para comunicar las decisiones
tomadas.
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.
2. Definir los casos de prueba para el 100 % de la cobertura, según los objetivos,
estrategias y tipos de pruebas.
5. Evaluar el esfuerzo necesario para ejecutar las pruebas con el fin de hacer más
eficaz el proceso.
59
Entorno para el desarrollo de software
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:
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:
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
Entorno para el desarrollo de software
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.
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.
61
Entorno para el desarrollo de software
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.
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:
62
Entorno para el desarrollo de software
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.
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.
5. Realizar una evaluación de los riesgos potenciales del proyecto que pueden
afectar la calidad del producto.
63
Entorno para el desarrollo de software
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.
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:
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.
Una buena práctica elaborada por el autor de este trabajo, tomando como referencia
[Rational, 2003] es la siguiente:
64
Entorno para el desarrollo de software
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.
65
Entorno para el desarrollo de software
en el CITI
El flujo de trabajo de la Disciplina Despliegue se muestra en la Figura 12.
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
Entorno para el desarrollo de software
en el CITI
disciplina Despliegue de RUP. Esta actividad genera un artefacto y una guía para su
construcción.
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.
Empaquetar el Sistema
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
Entorno para el desarrollo de software
en el CITI
Escribir Documentación de Usuario
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 en Producción
68
Entorno para el desarrollo de software
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:
69
Entorno para el desarrollo de software
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.
¾ 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.
70
Entorno para el desarrollo de software
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.
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.
71
Entorno para el desarrollo de software
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.
72
Entorno para el desarrollo de software
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.
2.6. Conclusiones
73
Herramienta de soporte al proceso de
desarrollo de software en el 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]
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
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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.
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
Herramienta de soporte al proceso de
desarrollo de software en el CITI
3.2.1. Elementos de Trabajo.
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
76
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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.
77
Herramienta de soporte al proceso de
desarrollo de software en el CITI
¾ 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 generales
Grupos y Permisos.
78
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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:
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 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
Herramienta de soporte al proceso de
desarrollo de software en el CITI
descargar versiones, etiquetar, realizar ramas y combinaciones, administrar las ramas,
en fin todas las tareas de control de código.
3.2.2. Reportes.
¾ Reporte de la Evaluación.
¾ Carta de Aceptación de Requerimientos del Cliente.
80
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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.
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.
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
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
Herramienta de soporte al proceso de
desarrollo de software en el CITI
mayor reutilización, además de esta forma la administración se hace mucho más
sencilla.
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.
83
Herramienta de soporte al proceso de
desarrollo de software en el CITI
siguiente estructura dentro del repositorio de control de código de TFS.
84
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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.
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
Herramienta de soporte al proceso de
desarrollo de software en el CITI
86
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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
87
Herramienta de soporte al proceso de
desarrollo de software en el CITI
88
Herramienta de soporte al proceso de
desarrollo de software en el CITI
¾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.
89
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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.
90
Herramienta de soporte al proceso de
desarrollo de software en el CITI
¾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.
¾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
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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.
92
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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.
93
Herramienta de soporte al proceso de
desarrollo de software en el CITI
¾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]
94
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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.
95
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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
96
Herramienta de soporte al proceso de
desarrollo de software en el CITI
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
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.
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.
98
Conclusiones
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:
¾ 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.
¾ 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
[David et al.,2006] David, J.-L.; T. Loton, et al. Professional Visual Studio 2005
Team System. Wiley Publishing, Inc., 2006. p.
101
Referencias Bibliográficas
[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.
[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
Referencias Bibliográficas
[Len Bass,2003] Len Bass, P. C., Rick Kazman. Software Architecture in Practice, Second
Edition. 2003. p. 0-321-15495-9
[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
103
Referencias Bibliográficas
[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
104
Referencias Bibliográficas
[Polarion,2011] Polarion. Polarion ALM, Everything You Need in One Single ALM
Solution, 2011. [Disponible en: http://www.polarion.com/products/alm/index.php
[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
105
Referencias Bibliográficas
106
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
Glosario de Siglas y Términos
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.
108
Glosario de Siglas y Términos
109