Está en la página 1de 12

Serie Científica de la Universidad de las Ciencias Informáticas

http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

Tipo de artículo: Artículo original


Temática: Ingeniería de Software
Recibido: 19/03/2012 | Aceptado: 04/06/2012 | Publicado: 15/06/2012

Aplicando el método de Boehm y Turner

Applying the Boehm and Turner method


Mairelys Boeras Velázquez1, Laritza Cabrera Barroso2, Eileén Llano Castro3, Ana María Sánchez Gonzalez4,
Yaima Oval Riveron4, Eylin Hernández Luque4

1
CISED. Departamento de Identificación. Universidad de las Ciencias Informáticas, Carretera a San Antonio de los
Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP.: 19370
2
CENIA. Departamento Gestión Documental. Universidad de las Ciencias Informáticas, Carretera a San Antonio de
los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP. 19370
3
CENIA. Centro de Informatización Universitaria. Universidad de las Ciencias Informáticas, Carretera a San Antonio
de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP. 19370
4
Departamento de Ingeniería y Gestión de Software y PP. Facultad 1. Universidad de las Ciencias Informáticas,
Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, La Habana, Cuba. CP. 19370

Autores para la correspondencia: {mbohera, lcabrera}@uci.cu

Resumen
La ingeniería de software bajo restricciones de tiempo, costo y calidad trata sobre la aplicación de prácticas y métodos
para construir productos de software que cumplan las expectativas de clientes y usuarios. En ocasiones, la mala
selección de los métodos no permite obtener los resultados esperados en los proyectos de desarrollo de software. Pero
en la actualidad, ya se cuentan con técnicas que teniendo en cuenta las características de estos proyectos permiten
realizar una selección más acertada del método de desarrollo a utilizar. En el presente trabajo, tomando como
referencia un caso de estudio y utilizando el método de Boehm y, a partir del análisis, sus cinco criterios, se realiza la
selección más acertada del enfoque, la metodología y las prácticas a utilizar en el proceso de desarrollo de software.
Palabras clave: Enfoque; método de Boehm y Turner; metodología.

Grupo Editorial “Ediciones Futuro” 1


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

Abstract
Software engineering under constraints of time, cost and quality, is about the application of practices and methods to
build software products that meet the expectations of customers and users. Sometimes, a poor selection of methods
does disallows achieving the expected results in projects. But nowadays, there are some techniques that taking into
account the characteristics of a project, allows a proper selection of the right development method to use. In this
paper presents, taking a case study as reference and using the Boehm and Turner method from the analysis five
criteria, the selection of the most appropriate approach, methodology and practices to use in the software
development process.
Keywords: Approach, Boehm and Turner method, methodology.

Introducción
La ingeniería de software supone la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo,
operación y mantenimiento del software (IEEE, 1993). Sucede que lo que puede entenderse como “sistemático”,
“disciplinado” y “cuantificable” para un equipo de desarrollo, puede resultar inconsecuente o caótico para otros. La
experiencia de años de trabajo en el desarrollo de software indica que el éxito radica en una mayor planificación,
siguiendo una guía de procesos que permiten la organización y control del proyecto. Por otro lado, tendencias actuales
van dirigidas al uso de metodología que parecen contradecir esta visión tradicional. Las necesidades de los clientes
pueden ser muy cambiantes y por ello es preciso adoptar mecanismos que faciliten la adaptación rápida a dichos
cambios, porque puede correrse el riesgo de estar resolviendo el problema equivocado. Por otro lado, la dinámica del
mercado, exige entregas constantes que demandan tiempos de desarrollo cada vez más cortos. A estas corrientes que
coexisten en la construcción del software actual se les conoce como enfoque ágil y enfoque prescriptivo de desarrollo.
El enfoque prescriptivo, denominado en algunas bibliografías como tradicional o pesado, busca la estructura, orden y
consistencia del proyecto de desarrollo de software en cuestión. Se les llama prescriptivos porque prescriben un
conjunto de elementos del proceso (acciones, tareas, productos de trabajo, mecanismos de control y aseguramiento de
la calidad). Además definen la forma en que los elementos del proceso mencionados anteriormente deben relacionarse
entre sí (Pressman, 2005).
El enfoque ágil, llamado también como enfoque ligero se centra en los miembros del equipo y su interacción, en la
entrega rápida de versiones de software funcional, en la colaboración constante del cliente y la facilidad para manejar
los cambios, dándole menor importancia a las herramientas, documentación, la formalidad y planificación exhaustiva
del proceso (Manifiesto Ágil, 2001).

Grupo Editorial “Ediciones Futuro” 2


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

Aunque estas visiones parezcan opuestas, lo cierto es que se requiere disciplina, pero también adaptabilidad y
agilidad. La selección de un enfoque y en función de este la metodología a utilizar, dependen de las circunstancias y
características específicas de cada proyecto de desarrollo de software. El análisis de estas cuestiones, así como de
todas las decisiones que se toman en cuanto a la forma de enfrentar el proyecto, facilitan o no, la adopción de un
enfoque.
La realidad en la mayoría de los proyectos de software actuales, es que el esfuerzo dedicado a la valoración de estas
cuestiones todavía es insuficiente. Esto hace que la selección de la metodología a utilizar parezca un acto de fe, en
lugar de una evaluación de alternativas técnicas, costos, beneficios, condiciones sociales y riesgos asociados.
La presente investigación tiene como objetivo, a partir de un caso de estudio, seleccionar el enfoque, metodología y
prácticas más adecuadas a utilizar en el proceso de desarrollo de software, mediante el método Boehm y Turner que
permite caracterizar el proyecto de software a partir de 5 criterios y estimar cuan ágil o prescriptivo debía ser el
enfoque a utilizar.

Materiales y métodos
Por la diversidad de características de los proyectos hoy día, donde se mezclan elementos que favorecen el uso de
ambos enfoques, existe una tendencia a utilizar un enfoque híbrido, donde se apliquen las prácticas que se proponen
en diferentes metodologías y permitan una mejor adaptación a las particularidades de cada proyecto de desarrollo de
software.
Es muy común encontrar, la definición de criterios de evaluación para la valoración del ambiente en el que se
desarrolla un proyecto, o para la selección de la metodología de desarrollo bajo la que se estará desarrollando el
mismo. En búsquedas realizadas para determinar un método que pudiera ser usado en la determinación del enfoque y
la metodología para la ejecución del proyecto, se encontraron el de Boehm y Turner y otros que basan su
funcionamiento en criterios de selección, como son: la presencia y el conocimiento (Tinoco et al., 2010). Se
selecciona el método de Boehm y Turner debido a que los otros métodos encontrados van más encaminados a la
selección de la metodología de desarrollo en sí, y no a determinar el enfoque del proyecto dado sus características.
El método de Boehm y Turner plantea 5 criterios fundamentales mediante los que se estará valorando el proyecto;
estos son: tamaño del equipo, criticidad del producto, dinamismo de los cambios, cultura del equipo y personal con
que se cuenta. Cada uno de esos criterios tiene elementos que lo discriminan y por tanto se tienen en cuenta a la hora
de seleccionar uno u otro enfoque (Gabardini y Campos, 2004). Para la selección del valor que se ubicará en cada eje

Grupo Editorial “Ediciones Futuro” 3


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

(uno para cada criterio) de la estrella se debe tener en cuenta el comportamiento de estos criterios en el proyecto. En
lo sucesivo se describe cada uno:
Tamaño: Este criterio se utiliza para representar el número de personas involucradas en el proyecto. Pueden tenerse
en cuenta el nivel de complejidad que pueda presentarse en la comunicación entre los miembros del proyecto y los
costos que pueden provocar cambios esperados.
Criticidad: Se utiliza para evaluar la naturaleza del daño ocasionado por defectos que no hayan sido detectados al
producto. Su evaluación puede ser cualitativa.
Dinamismo: Representa la rapidez con la que pueden estar cambiando los requerimientos del proyecto.
Personal: Representa la proporción del personal con experiencia alta, media y baja. Los métodos orientados al plan
no se ven afectados negativamente por este factor pues no interesa el nivel de experiencia con la que cuenten los
miembros del equipo.
Cultura: Las organizaciones y las personas que relaciona el proyecto pueden depender de la confianza o de la
relación contractual. Esto refleja el nivel de ceremonia necesario y aceptado: documentación, control, formalismo en
las comunicaciones.
La Figura 1 muestra una representación de la estrella de Boehm y Turner para un proyecto de desarrollo de software.
Tomada de (Gabardini et al., 2004).

Figura 1. Representación de la estrella de Boehm y Turner.

Grupo Editorial “Ediciones Futuro” 4


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

Resultados y discusión
A través del siguiente caso de estudio se analiza el enfoque, metodologías y prácticas más adecuadas a utilizar, según
los criterios que propone el método de Boehm y Turner.
Caso de estudio
El proyecto para el desarrollo del Sistema para la emisión de pasaportes diplomáticos, de servicio y acreditaciones
diplomáticas de la República Bolivariana de Venezuela, perteneciente al Centro de Identificación y Seguridad Digital
(CISED), tiene como principal objetivo dotar a este país de un sistema que posibilite la emisión de estos documentos
cumpliendo los estándares internacionales para documentos de este tipo. El proyecto dentro del cual se desarrolla el
sistema es guiado por un contrato que puede ser difícilmente modificado.
El pasaporte diplomático y el pasaporte de servicio son los documentos de viaje que el Gobierno Venezolano emite
para los funcionarios que viajarán cumpliendo actividades en función del mismo.
La acreditación diplomática es el documento que emite la República Bolivariana de Venezuela para identificar a los
ciudadanos extranjeros que son acreditados ante el Gobierno en función del cumplimiento de actividades diplomáticas
en el país.
Para el desarrollo del sistema fueron seleccionados 11 especialistas graduados del área de informática con una
experiencia promedio de 3 años en proyectos de desarrollo de software. De los especialistas, el 20 % ha trabajado
anteriormente con la tecnología a utilizar, la otra parte del equipo aunque no domina totalmente la tecnología, se
siente comprometido con el nuevo reto a asumir. El equipo de desarrollo trabajará de manera agrupada en un mismo
local en Venezuela, donde tendrán todas las condiciones de trabajo necesarias. Cuenta dentro de su estructura
organizativa con un jefe de desarrollo; el cual tiene como papel fundamental guiar, organizar y controlar el proceso de
desarrollo de software. Entre los miembros del equipo existe confianza y una buena comunicación, lo que propiciará
un buen ambiente de trabajo. Por experiencias en otros desarrollos en los que el equipo ha trabajado junto, se
evidencia una buena adaptación a los cambios imprevistos.
Durante el tiempo de desarrollo del sistema, permanecerán de forman regular especialistas funcionales de la
institución venezolana para la que se desarrolla el sistema. La interacción de los especialistas funcionales con el
equipo de desarrollo posibilitará el ajuste del software a las necesidades del cliente de forma controlada. A pesar de la
presencia de estos especialistas, se pronostican cambios sustanciales en los requerimientos del sistema una vez
levantados; pues las áreas involucradas no tienen bien definidos sus procesos. Además, los especialistas funcionales
no tienen una clara visión de todas sus necesidades.

Grupo Editorial “Ediciones Futuro” 5


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

Análisis de la propuesta
A continuación se caracteriza el proyecto a partir de los criterios que propone el método y se ubican los resultados en
la Estrella de Boehm y Turner.
Tamaño: El equipo de desarrollo está formado por 11 especialistas para la implementación de un total de 73
funcionalidades con ciertos elementos de complejidad, características que permiten clasificar el equipo de desarrollo
como pequeño y al sistema como mediano.
Para determinar la cantidad de especialistas necesarios para el desarrollo del proyecto bajo las condiciones que se han
descrito se utilizó el método de estimación COCOMO II. Método de estimación que relaciona características del
personal, condiciones o restricciones bajo las cuales se lleva a cabo el proyecto (Gómez y López, 2009).
Teniendo en cuenta los elementos antes descritos, el esfuerzo que realizarán los miembros del equipo para dominar la
tecnología con la ayuda de los especialistas experimentados, y la experiencia que tienen trabajando como equipo; será
posible ubicar el punto de evaluación más cercano al centro del eje de coordenadas apuntando desde esta perspectiva
a un enfoque ágil.
Criticidad: El equipo de desarrollo tiene una elevada responsabilidad con la calidad del producto a obtener, debido al
impacto social del mismo. Este sistema permitirá a los funcionarios venezolanos obtener un pasaporte que cumpla con
las normas de la Organización de Aviación Civil Internacional (OACI). Los defectos que se detecten una vez obtenido
el producto pueden provocar:
o Que los funcionarios extranjeros y venezolanos se vean involucrados en problemas de falsa identidad debido a
fallas del sistema.
o Gastos para la Institución debido a que la materia prima utilizada para la impresión de los documentos es muy
costosa.
El valor para este criterio dentro de la estrella se pondera como medio, debido a que los efectos por errores del
producto, si bien no provocarán pérdidas de vidas tendrán un fuerte impacto social y monetario para la institución en
caso de presencia.
Dinamismo: Las áreas de la institución que involucra la solución son objeto de una transformación organizacional,
por lo que no se tiene claridad de todos los procesos del negocio que se pretenden automatizar. Como consecuencia de
ello pueden aparecer cambios en los requerimientos del sistema en cualquier fase del proceso de desarrollo.
El constante cambio en los requisitos es un riesgo que se asumirá durante todo el ciclo de desarrollo del software.
Para mitigarlo, deben adoptarse mecanismos que faciliten la asimilación y adaptación rápida a dichos cambios.
Tomando en cuenta esta necesidad como una de las ventajas que brinda el enfoque ágil, se ha ubicado este punto bien

Grupo Editorial “Ediciones Futuro” 6


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

cercano al centro de la Estrella. El valor se tomó teniendo en cuenta la cantidad de funcionalidades que no pudieran
cambiar a lo largo del desarrollo, como se prevé que cambien casi todas se determinó que solo el 5 % del total de ellas
no cambiarían, valor que se refleja en el eje correspondiente.
Personal: Todos los desarrolladores son graduados de la especialidad de informática con un promedio de 3 años de
experiencia laboral, pero solo el 20 % domina el trabajo con la tecnología que se pretende utilizar. Estos elementos
evidencian claramente que la evaluación del proyecto en este punto no converge a un desarrollo ágil por lo que el
punto de evaluación distará en gran medida del centro eje de coordenadas.
Para determinar este valor se realizaron evaluaciones a los miembros del equipo donde se determinó si eran
programadores Junior (menos experimentados) o Senior (más experimentados). Luego se aplicó el cálculo básico para
determinar el porciento que representaba cada grupo del total de miembros. Esto arrojó como resultado que el 80 %
de los desarrolladores formaban parte del grupo de programadores poco experimentados y el resto del grupo más
experimentado, valores que fueron representados en el eje correspondiente.
Cultura: El equipo de proyecto presenta una estructura de mando bien definida, donde cada miembro del equipo
conoce sus responsabilidades y actividades. Existe una buena comunicación y confianza entre sus miembros puesto
que han trabajado juntos en otras ocasiones. Las decisiones tomadas son previamente analizadas y consultadas con
todos los involucrados. Las actividades son planificadas en función de los hitos del proyecto y asignadas a cada
miembro, teniendo en cuenta la carga de trabajo y el rol que desempeñan. El trabajo es supervisado por la dirección
del proyecto para identificar posibles problemas que provoquen el atraso del mismo.
Los elementos antes descritos evidencian organización en el desarrollo del trabajo, pero al ser un equipo pequeño no
necesitan relación contractual dada la buena comunicación y confianza entre sus miembros. Cada especialista en el
desempeño de su rol será libre de incorporar ideas que no afecten el diseño del sistema, ni los compromisos
planificados.
Para la obtención del valor colocado en el eje se realizó el siguiente análisis: se fueron ubicando las características en
cada uno de los enfoques tratados (ágil o pesado) teniendo en cuenta su fuerte presencia en el mismo. Un ejemplo es:
“Cada especialista será libre de incorporar ideas al desarrollo, siempre que no afecten el diseño del mismo; esta
característica fue ubicada en el grupo de enfoque ágil. Así se hizo con cada una de las características. Después fue
sumada la cantidad en cada uno de los grupos, y fue hallado el porciento que representa cada grupo sobre el total de
características. Obteniendo como resultado que las agrupadas como ágiles representan el 33 % del total de las
analizadas y las pesadas el 67 %. Luego, analizando los valores, se concluye que el equipo presenta poca libertad en el
desarrollo del proyecto por lo que se ubica el valor 33 % en el eje, valor más cercano a la formalidad.

Grupo Editorial “Ediciones Futuro” 7


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

La Figura 2 muestra la representación de los criterios analizados en la Estrella de Boehm y Turner. La forma obtenida
no sugiere con claridad la aplicación de un enfoque en específico, los vértices que representan los valores de
Dinamismo y Tamaño, se ubican en Territorio ágil, pero aspectos como Personal y Cultura del equipo, apuntan a la
utilización de un enfoque prescriptivo. La Criticidad se muestra en un área de incertidumbre donde la agilidad y el
formalismo se encuentran balanceados. En resumen, la disposición de las aristas propone la hibridación de los
enfoques, pero analizando el peso que tienen criterios como el Dinamismo, debido al elevado riesgo de requisitos
cambiantes y el tamaño reducido de personas que involucra el desarrollo de un número considerable de
funcionalidades, se propone adoptar un enfoque ágil.

Figura 2. Estrella que representa el proyecto según la aplicación de Boehm y Turner.

Entre las metodologías de desarrollo ágil más referenciadas se destacan: XP (Letelier y Penadés, 2006), Scrum
(Palacio, 2007), FDD (Calabria, 2003) y Crystal (Chicaiza, 2007). Del estudio de estas metodologías, FDD resultó ser
la propuesta que mejor se ajusta a las características del proyecto a ejecutar. A pesar de ser clasificada como una
metodología ágil, es considerada por sus características una metodología, que está en el punto medio del enfoque ágil
y prescriptivo (Amaro y Valverde, 2007). FDD engloba las características que se necesitan mantener en el proceso de

Grupo Editorial “Ediciones Futuro” 8


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

desarrollo a ejecutar. La selección de una metodología ágil como XP, muy usada en el mundo no se ajusta primero a
las características del equipo de desarrollo y luego a la cantidad de documentación que se necesita generar para el
proyecto. Por otro lado, una metodología pesada se iría al otro extremo. De utilizar la hibridación de dos
metodologías, se está queriendo resolver el problema con la selección de prácticas en diferentes metodologías que
podían encontrarse de manera absoluta en la metodología FDD.

FDD. Prácticas
La metodología FDD está pensada para proyectos con tiempo de desarrollo relativamente cortos. Se basa en un
proceso iterativo, con iteraciones cortas que produce un software funcional que el cliente y la dirección de la empresa
pueden ver y monitorizar. Las iteraciones se deciden de acuerdo a las funcionalidades o rasgos (Molpeceres, 2003).
Estas iteraciones cortas o resultados a corto plazo posibilitarán entregas al cliente en tiempos cortos, lo que permitirá
dar cumplimiento a los diferentes hitos registrados como parte del contrato en el que está enmarcado el proyecto.
Se concibió para equipos de trabajo pequeños al igual que XP. Basa la obtención de requisitos en la elaboración de
una lista de funcionalidades y no en la descripción detallada de casos de uso o historias de usuarios como en RUP y
XP respectivamente. La definición de requisitos como lo propone FDD puede ser un elemento favorable cuando hay
presencia de requisitos cambiantes o dinámicos. Posibilita al equipo de desarrollo, trabajar con ellos de la manera más
conveniente y en caso de cambios no se afectarían ni las historias de usuarios, ni las descripciones de casos de usos.
La metodología XP propone no colocar demasiada carga de trabajo (tareas organizativas) sobre los desarrolladores.
RUP es un proceso pesado en este sentido, ya que el desarrollador debe documentar su trabajo. Y FDD sin embargo,
está en nivel medio, en el sentido de que genera más documentación que XP pero menos que RUP, documenta solo lo
que posibilite la integración de desarrolladores fácilmente al proyecto. Esta práctica de FDD es conveniente para el
proyecto, pues la inclusión de nuevos desarrolladores no es una idea descartada; además, puede servir de base para la
generación de la documentación definida como entregable al cliente, elemento necesario para el cumplimiento de lo
pactado en el contrato.
RUP para las relaciones con el cliente propone presentar artefactos al final de cada fase, pero para el aseguramiento
XP y FDD se basan en controles propios y una comunicación fluida con el cliente. La comunicación frecuente con el
cliente será importante debido a que durante el desarrollo los especialistas funcionales pondrán ir validando los
release obtenidos de cada una de las iteraciones.
Para el conocimiento de la arquitectura, RUP intenta reducir la complejidad del software a producir a través de una
planificación intensiva; XP lo hace a través de la programación a pares ya en la creación del código se pueden evitar

Grupo Editorial “Ediciones Futuro” 9


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

errores y malos diseños; y FDD usa las sesiones de trabajo conjuntas en la fase de diseño para conseguir una
arquitectura sencilla y sin errores. La característica de esta última, unida a la decisión de contar con desarrolladores
líderes (jefe de desarrollo, arquitecto) dentro del grupo, permite que el conocimiento fluya en el equipo, elemento
importante a fomentar teniendo en cuenta experiencia del grupo de trabajo.
FDD divide los roles en tres categorías: Roles claves, Roles de soporte y Roles adicionales. (Amaro y Valverde,
2007). En la siguiente Tabla se relacionan los roles que desempeñan los miembros del equipo. En una columna se
muestra el rol principal que desarrolla y en la otra se ubican otros que en alguna fase del proyecto podrían estar
realizando:

Tabla 1. Roles que desempeñan los miembros del equipo.


Rol principal Otro incorporado
Jefe de proyecto (Project Manager). Ingeniero desarrollador (Build Engineer)
Jefe de desarrollo (Development Manager) Jefe de programadores (Chief Programmer)
Jefe de versiones (Realese Manager)
Ingeniero desarrollador (Build Engineer)
Desarrollador (Deployer)
Arquitecto principal (Chief Architect) Toolsmith
Desarrollador (Deployer)
Administrador de sistema (System Administrator) Toolsmith
Desarrollador (Deployer)
Responsables de clases (Class Owner) Desarrollador (Deployer)
Expertos del dominio Jefe de dominio (Domain Manager)
Analista Documentador (Technical Writer)
Especialista de transformación Probador (Tester)
organizacional Ingeniero desarrollador (Build Engineer)

Conclusiones
El análisis de las condiciones bajo las cuales cada enfoque o metodología tiene mayor probabilidad de éxito, tiene
como punto de partida las circunstancias y características del entorno en el que se pretende aplicar. El método de
Boehm y Turner constituye una herramienta útil para la valoración de dicho entorno, basado en 5 criterios que
permiten diagnosticar cuan ágil o prescriptivo debe ser el proceso de desarrollo a seguir.

Grupo Editorial “Ediciones Futuro” 10


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

En el caso de estudio analizado, la forma de la figura obtenida como resultado de la ubicación de criterios en la
Estrella de Boehm y Turner, no sugiere con claridad la aplicación de un enfoque en específico sino la hibridación de
estos. De los 5 criterios analizados, 2 se ubican en territorio ágil, 2 en territorio prescriptivo u orientado al plan y uno
se muestra en un área de incertidumbre donde la agilidad y el formalismo se encuentran balanceados. Valorando el
peso que tienen para la administración del proyecto de desarrollo de software factores como el Dinamismo, debido al
elevado riesgo de requisitos cambiantes en todas las etapas del proceso y el Tamaño reducidos de personas que
involucra el desarrollo de un número considerable de funcionalidades, se ha decidido adoptar un enfoque ágil como
método base y manejar los riesgos ocasionados por los factores que no están concebidos bajo este enfoque. Para ello,
se ha seleccionado como metodología de desarrollo FDD que pesar de ser clasificada como una metodología ágil, es
considerada punto medio entre RUP y XP, lo cual favorece considerablemente, la hibridación de enfoques que
propone el resultado de la aplicación del método de Boehm y Turner para el proyecto.

Referencias
AMARO CALDERÓN, SARAH DÁMARIS y VALVERDE REBAZA, JORGE CARLOS. Metodologías
Ágiles. 2007.
BECK, KENT; BEEDLE, MIKE; BENNEKUM, ARIE VAN; et al., Manifiesto Ágil. 2001. [Consultado el:
20 de febrero de 2012]. Disponible en: [http://www.agilemanifesto.org/iso/es].
CALABRIA, LUIS. Metodología FDD. 2003.
CENTELLA HINOJOSA, MILCA. Resumen comparativo entre las metodologías pesadas vs ligeras, Bolivia.
2012.
CHICAIZA AYALA, ALEXANDRA PATRICIA. Desarrollo de software de nómina de empleados utilizando
la Metodología Crystal, Ingeniería en Sistemas e Informática, Sangolquí. 2007.
COCKBURN A. Just-In-Time Methodology Construction. 2000.
GABARDINI, JUAN y CAMPOS, LUCAS. Balanceo de Metodologías Orientadas al Plan y Ágiles.
Herramientas para la Selección y Adaptación. En: PMI Global Congress Proceedings. Buenos Aires,
Argentina. 2004.
GÓMEZ, ADRIANA, LÓPEZ, MARÍA DEL C., Migani Silvina, Otazú Alejandra. Un modelo de estimación
de proyectos de software. 2009.
IEEE. Ingeniería de Software, Pressman capítulos [1-9] 2002 [Consultado el: 20 de febrero de 2012].
Disponible en: [http://es.scribd.com/doc/32166526/Ingenieria-de-Software-Pressman-capitulos-1-9].

Grupo Editorial “Ediciones Futuro” 11


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu
Serie Científica de la Universidad de las Ciencias Informáticas
http://publicaciones.uci.cu/index.php/SC| seriecientifica@uci.cu
No. 6, Vol. 5, Año: 2012
ISSN: | RNPS:

LETELIER, PATRICIO y PENADÉS, Mª CARMEN. Metodologías ágiles para el desarrollo de software:


eXtreme Programming (XP). 2006.
MOLPECERES, ALBERTO. Procesos de desarrollo: RUP, XP, FDD. 2003. [Consultado: 24 de febrero de
2012]. Disponible en: [www.willydev.net/descargas/Articulos/General/cualxpfddrup.PDF].
PALACIO, JUAN. Flexibilidad con Scrum. Principios de diseño e implantación de campos de Scrum. 2007.
PRESSMAN, ROGER. Ingeniería del Software: Un Enfoque Práctico (Sexta Edición). McGraw-Hill. 2005. P
900.
TONOCO GÓMEZ, OSCAR; ROSALES LÓPEZ, PEDRO PABLO y SALAS BACALLA, JULIO. Criterios
de selección de metodologías de desarrollo de software. 2010.

Grupo Editorial “Ediciones Futuro” 12


Universidad de las Ciencias Informáticas. La Habana, Cuba
seriecientifica@uci.cu

También podría gustarte