Calidad de Software en El Uso de Metodologias Agiles para El Desarrollo de Sotware PDF

Calidad de Software en el uso de Metodologas giles para el Desarrollo de
Software
Sandra Dinora Orantes Jimnez
Centro de Investigacin en Computacin, Instituto Politcnico Nacional, Av. Juan

de Dios Btiz s/n esquina Miguel Othn de Mendizbal, Col. Nueva Industrial
Vallejo, Mxico, D.F. C.P. 07738
dinora@cic.ipn.mx
Resumen. El desarrollo de software no es tarea fcil y por ello, existen

numerosas propuestas metodolgicas que inciden en distintas
dimensiones del proceso de desarrollo; as, por un lado se encuentran
propuestas tradicionales que se centran en el control del proceso,
estableciendo de forma rigurosa actividades involucradas, artefactos
que deben producir y herramientas y notaciones que se emplearn.
Todas las propuestas han demostrado ser efectivas y necesarias en
varios proyectos, pero tambin han presentado problemas en otros
tantos. Se sugieren mejoras, como admitir en los procesos de desarrollo
ms actividades, artefactos y restricciones, en base a los puntos dbiles
detectados, como consecuencia se tendra un proceso de desarrollo
complejo, que es posible que limite la propia habilidad del equipo para
llevar a cabo el proyecto. Es as que, en el proceso de buscar
soluciones, hoy en da se encuentran metodologas que se centran en
otros aspectos, como por ejemplo el factor humano o el producto de
software, siendo esta la filosofa de las Metodologas giles, donde se
da mayor importancia a la colaboracin con el cliente y al desarrollo
incremental del software con iteraciones cortas, mostrando su
efectividad en proyectos con requisitos cambiantes y donde se exige
reducir drsticamente los tiempos de desarrollo, pero manteniendo una
alta calidad. Por consiguiente, esta investigacin se centra, en lograr
mantener la Calidad de Software en ciclos de desarrollo cortos como los
que plantean las Metodologas giles.
2 Sandra Dinora Orantes Jimnez
Palabras Clave: Metodologas giles, Calidad de Software, Individuos e

Interacciones, Software Funcional, Colaboracin con Clientes,
Respuesta al Cambio.
1 Introduccin
Existen muchas metodologas para el desarrollo de software y varias de ellas se

acoplan bajo el guin de giles; todas las metodologas existentes comparten
caractersticas y algunas diferencias significativas, aunque la presente
investigacin no se enfoca en resaltar estos puntos, al enfocarse en las
Metodologas giles pueden sealarse algunos lugares donde se ven claras
semejanzas y diferencias, pese a no tener experiencia significativa sobre muchas
de ellas.
El desarrollo de software gil es un marco de trabajo conceptual para emprender
proyectos de Ingeniera de software y as, existe un nmero de mtodos de
desarrollo de software giles, que son apoyados por la llamada Alianza gil (The
Agile Alliance).
Los llamados Mtodos giles, intentan minimizar riesgos en tiempos de
desarrollo de software cortos, a travs de iteraciones que duran de una a cuatro
semanas y donde cada iteracin, es como un proyecto de software en miniatura
que incluye las tareas necesarias para liberar en cada mini-incremento, una nueva
funcionalidad que pas por todas las etapas: planeacin, anlisis de
requerimientos, diseo, codificacin, pruebas y documentacin. En las
metodologas normales basadas en incrementos, no se adiciona suficiente
funcionalidad que garantice la liberacin de un producto, en tanto, los proyectos de
software gil intentan ser capaces de que un nuevo software se termine al final de
cada iteracin y que incluso el equipo de desarrollo, reevalue las prioridades del
proyecto esperando por supuesto, que cada producto sea de calidad.
Los Mtodos giles enfatizan una comunicacin en tiempo real,
preferentemente cara a cara sobre documentos escritos; los equipos giles deben
involucrar todas las personas necesarias para garantizar la finalizacin del
software, como mnimo se involucran programadores y los clientes (que son
finalmente los que definen el producto, quien lo manejar, anlisis de negocios o
consumidores actuales), el grupo tambin puede incluir a probadores, diseadores
de interaccin, escritores tcnicos y gerentes.
Calidad de Software en el uso de Metodologas giles para el Desarrollo de Software 3
Las Metodologas giles tambin acentan en que el software trabajando es la

primera medida del progreso, combinado con la comunicacin cara a cara en todo
momento, se produce poca documentacin en relacin con otros mtodos, dando
como resultado que se crtique a los Mtodos giles considerndoseles
indiciplinados y poniendo a veces en riesgo la Calidad del producto resultante y
que es donde se centra la presente investigacin, tratar de lograr Calidad de
Software en el uso de Metodologas giles para el Desarrollo de Software.
El artculo est organizado de la siguiente manera: en la seccin 2 se introducen
las las Metodologas giles y un poco de la historia de cmo surgieron, se habla
del Manifiesto y se comparan con metodologas no giles. La seccin 3 habla de
la conveniencia del empleo de Metodologas giles. En la seccin 4 se habla
brevemente de la Evaluacin de la Calidad de Software. En la seccin 5 se habla
de cmo adaptar los Mtodos giles, tomando en cuenta la Calidad de Software.
En la seccin 6 se dice como manejar un proyecto empleando Metodologas
giles asegurando la Calidad de Software. Finalmente, aparecen las conclusiones,
que incluyen algunas crticas y las referencias bibliogrficas.
2 Metodologas giles, un poco de historia
La definicin moderna de Desarrollo de Software gil surge a mediados de los

aos 90 como parte de una reaccin en contra de los llamados mtodos de peso
pesado (heavyweight), tipificados, regulados, reglamentados, micromanejados del
modelo de desarrollo de Cascada, ya que los procesos que provienen del uso del
modelo de cascada fueron vistos como burocrticos, lentos y que contradecan los
caminos para que los ingenieros de software realizaran un trabajo eficaz.
El hecho es que los mtodos de desarrollo giles e iterativos son como regresar
a las primeras prcticas de desarrollos de software [1].
Al principio las Mtodos giles fueron llamados Mtodos de peso ligero
(lightweight methods) y en el 2001, los miembros prominentes de la comunidad,
que incluan 17 expertos de la industria del software, tomando en cuenta a algunos
de los creadores o impulsores de metodologas de software, se encontraron en
Snowbird, Utah, USA y adoptaron el nombre "Mtodos giles" y posteriormente,
algunos de los miembros de esta comunidad formaron la llamada Alianza gil (The
Agile Alliance) [2], que es una organizacin no lucrativa que promueve el
desarrollo gil.
El punto de partida fue el Manifiesto gil (Agile Manifesto) [3], un documento

que resume la filosofa gil.
Entre los primeros mtodos giles que surgieron antes de 2000 se incluyen
Scrum (en cuanto a direccin) (1986), Crystal Clear (software development), XP
(eXtreme Programming, Programacin Extrema) (1996), el Desarrollo de Software
Adaptable (Adaptive Software Development), Desarrollo Conducido (Feature
Driven Development) y DSDM (Dynamic Systems Development Method, Mtodos
de Desarrollo Dinmico de Sistemas) (1995).
Aunque definitivamente XP no fue el primer mtodo gil, estableci la
popularidad de los mtodos giles y fue creado por Kent Beck en 1996 como un
modo de rescatar el proyecto C3 (Chrysler Comprehensive Compensation,
Chrysler Compensacin Comprensiva), no obstante, aquel proyecto fue cancelado
en su momento y la metodologa XP fue refinada por Ron Jeffries, realizndose
una discusin pblica en Ward Cunningham's Portland Pattern Repository
(Repositorio de Patrones en Portland de Cunningham) y posteriormente, en un
trabajo publicado por Beck en 1999, que incluyo un libro [4]. Los elementos de
Programacin Extrema estn basados en Scrum y Episodios del Lenguaje de
Patrones de Cunningham (Ward Cunningham's Episodes pattern language).
2.1 Manifiesto gil Principios detrs de los Mtodos giles
Los Mtodos giles no son una familia de procesos de desarrollo, ni un

acercamiento al desarrollo de software; en 2001, 17 figuras prominentes [5] en el
campo del desarrollo gil (entonces llamados Mtodos de peso ligero) se
reunieron en Utah para discutir la manera de crear software rpidamente y la
forma de centrar a las personas en ello y finalmente, ellos elaboraron el Manifiesto
gil (Agile Manifesto), extensamente considerado como la definicin cannica de
desarrollo gil y acompandolo de principios giles.
Algunos de los principios detrs del Manifiesto gil [6] son:
Satisfaccin del cliente debido a la entrega rpida y continua de software til.
El software trabajando es entregado con frecuencia (en semanas en lugar de
meses).
El software trabajando es la medida principal de progreso.
Incluso las exigencias de cambios tardos son bienvenidos.
Una cercana y diaria cooperacin entre la gente del negocio (clientes) y los
desarrolladores.
La conversacin frente a frente es la mejor forma de comunicacin.
Los proyectos son construidos alrededor de individuos motivados, que se

sienten confiados en su trabajo.
La atencin continua en la excelencia tcnica y un buen diseo.
Simplicidad.
Equipos con Organizacin Propia.
Adaptacin regular a circunstancias cambiantes.
La publicacin del manifiesto engendr un movimiento en la industria de
software conocida como el desarrollo de software gil y en 2005, Alistair Cockburn
y Jim Highsmith juntaron a otro grupo de personas - expertos de direccin, esta
vez - y escribieron un apndice, llamado la PM Declaracin de Interdependencia.
2.2 Comparacin con otras Metodologas
Las Metodologas giles a veces se caracterizan por ser lo opuesto de las

llamadas Metodologas conducidas por plan o disciplinadas y esto implica, que
los mtodos giles son imprevistos o indisciplinados y que adems, tienden a
ser adaptables y predictivos [7].
Los Mtodos Adaptativos enfocan rpidamente la adaptacin a una realidad
cambiante y si las necesidades del proyecto cambian, el equipo de trabajo es
adaptable y se cambia tambin, tomando en cuenta la dificultad, que el equipo
siempre tendr que poder describir exactamente lo que pasar en el futuro y entre
ms lejana sea una fecha, ms vago ser lo que un mtodo adaptable permitir
predecir para aquella fecha. Un equipo adaptable debe poder relatar exactamente
que tareas tendrn que realizarse la prxima semana, aunque slo podr decir
cuales rasgos sern planeados durante el prximo mes y si se trata de una
liberacin para dentro de seis meses, slo pueden ser capaces de reportar el
estado del producto para su liberacin o una declaracin de valor esperado contra
el coste.
Los Mtodos Predictivos, enfocan la planificacin del futuro detalladamente y los
equipos predictivos pueden reportar exactamente que caractersticas y tareas
estn planeadas para todo el proceso de desarrollo. Sin embargo, a los equipos
predictivos se les dificulta cambiar de direccin, ya que el plan es optimizado
tpicamente para un destino prefijado y si hay cambios, tendra que modificarse
tambin la planificacin, con el riesgo que el trabajo completo sea desechado y
tengan que hacer todo nuevamente de manera diferente. Los equipos predictivos
a menudo elaboran una tabla de control de cambios o riesgos, para asegurar que
slo los cambios valiosos sean considerados. Entre los Mtodos Predictivos, el
Modelo en Cascada es realmente con el que menos tienen en comn las

Metodologas giles y aunque para algunos este modelo no es para nada
adecuado, desde el 2004, se ha comprobado que todava se emplea comnmente
[8].
Las Metodologas giles tienen mucho en comn con las tcnicas de las
Metodologas RAD (Rapid Application Development, Desarrollo Rpido de
Aplicaciones) proporcionadas y expuestas en 1980 por James Martin y otros
autores [9].
Algunos Equipos giles, utilizan el modelo en cascada en una pequea escala,
repitiendo el modelo completo en cada iteracin; otros equipos, son notablemente
Equipos XP, trabajando en varias actividades simultneamente.
La Tabla 1 recoge un comparativo, marcando las principales diferencias de las
metodologas giles con respecto a las Tradicionales no giles que se
consideran son las que han servido de base para otras metodologas, las
diferencias afectan no slo al proceso, sino tambin al contexto del equipo as
como a su organizacin.
3 Conveniencia del Uso de Mtodos giles
Aunque los Mtodos giles se diferencian en sus prcticas, ellos comparten un

nmero de caractersticas comunes, incluyendo el desarrollo iterativo y un enfoque
sobre interaccin, comunicacin y reduccin de artefactos intermedios intensivos
en recursos. [10]
La conveniencia de las Metodologas giles en general, puede ser examinada
desde mltiples perspectivas; desde el punto de vista del producto, los Mtodos
giles son ms convenientes cuando los requerimientos son cambiantes y
requieren una rpida modificacin y son menos convenientes, para los sistemas
que son altamente riesgosos, fiables y con muchos requerimientos de seguridad,
aunque no hay ningn consenso sobre este punto. [10]
Desde una perspectiva organizacional, la conveniencia puede ser evaluada
examinando tres dimensiones claves de una organizacin: cultura, personal y
comunicacin. En relacin con estas reas un nmero de factores claves han sido
identificados para lograr el xito de los proyectos [10]:
1. La cultura de la organizacin debe dar soporte a la negociacin
2. Las personas involucradas en el desarrollo deben ser confiables
3. Las personas responsables del desarrollo deben ser pocas pero muy
competentes
4. Las Organizaciones deben vivir con las decisiones de los desarrolladores
5. Las Organizaciones deben de tener un ambiente que facilite la comunicacin
rpida entre miembros del equipo de trabajo
El factor ms importante a tomar en cuenta, es probablemente, el tamao del
proyecto. [10] Cuando el tamao crece, la comunicacin cara a cara se hace ms
difcil. Por lo tanto, los Mtodos giles son convenientes para proyectos con
equipos pequeos, es decir, que involucren menos de 20 personas.
Para determinar la conveniencia individual del empleo de Mtodos giles, se
requiere de un anlisis sofisticado; los Mtodos DSDM, por ejemplo, proporcionan
para este propsito un filtro de conveniencia (suitability-filter); la familia de
Mtodos Crystal proporcionan criterios que ayuden a seleccionar el mtodo
adecuado para un proyecto y la eleccin est basada, en el tamao del proyecto,
riesgos y prioridades. Sin embargo, otros Mtodos giles no proporcinan ningn
instrumento explcito para evaluar su conveniencia para un proyecto.
Algunos Mtodos giles, como DSDM y FDD (Feature Driven Development,
Desarrollo Conducido por Rasgos), son considerados convenientes para cualquier
proyecto de desarrollo de software gil, independientemente de caractersticas
circunstanciales. [11]
Una comparacin de Mtodos giles revela que ellos soportan diferentes fases
de un ciclo de vida de desarrollo de software en varios grados y esta caracterstica
individual puede ser empleada como criterio de seleccin para elegir al Mtodo
gil adecuado.
El desarrollo gil ha sido documentado extensamente [7] y se conoce que
trabaja bien para equipos pequeos (menos de 10 desarrolladores) que son
capaces de afrontar requerimientos imprevisibles o que se cambian rpidamente.
La aplicabilidad del Desarrollo gil a los siguientes escenarios es cuestionable:
Los esfuerzos de desarrollo a gran escala (ms de 20 desarrolladores), las
estrategias empleadas, ya han sido descritas. [12]
Los esfuerzos de desarrollo distribuido (equipos no localizables dentro de la
compaa), sus estrategias han sido descritas en Bridging the Distance
(Acortamiento de Distancia) [13] y en Using an Agile Software Process with
Offshore Development (Utilizando un Proceso de Software gil con Desarrollo
en el Exterior) [14].
Esfuerzos Crticos: Misin - y vida (Mission- and life-critical efforts).
Culturas de Empresa: Comando y Control (Command-and-control).
Barry Boehm y Richard Turner sugieren que el anlisis de riesgo sea usado para
escoger entre mtodos adaptables ("gil") y predictivos ("conducidos por plan"). [7]
Los autores sugieren que cada mtodo tenga su propio sitio:
Mtodos giles:
Bajo riesgo
Desarrolladores Senior
Requerimientos muy cambiantes
Nmero pequeo de desarrolladores
Cultura que prospera sobre el caos
Mtodos Predictivos:
Alto riesgo
Desarrolladores Junior
Bajos cambios en los requerimientos
Nmero grande de desarrolladores
Cultura que exige tener orden
4 Evaluacin de la Calidad del Software
Al hablar de la calidad del software, pueden distinguirse dos reas principales:

calidad del producto y calidad del proceso de desarrollo [18][19].
4.1 Evaluacin del Producto
Para las organizaciones dedicadas al desarrollo de software, es importante ofrecer

productos de un alto grado de calidad y as, enfrentarse a la fuertemente creciente
competitividad que existe en ese ramo, no solamente a nivel local, sino incluso
internacional. Por esta razn, necesitan definirse un conjunto de actividades
cuidadosamente planificadas que les permita vigilar los productos a lo largo de
todas las etapas del ciclo de vida de desarrollo del software, para asegurar la
calidad del producto final.
Para evaluar la calidad de un producto de software, han surgido distintos
modelos que toman en cuenta diversos atributos de calidad. Al evaluar estos
atributos de calidad en diferentes etapas (jerarqua de atributos), se puede
determinar la calidad del producto de software. Entre los modelos ms importantes
que evalan la calidad del producto de software se encuentran los siguientes:
El modelo de McCall. Incorpora once factores, desde el punto de vista de tres

ejes: operacin del producto, revisin del producto y transicin del producto. Las
mtricas son preguntas, que ponderan numricamente un determinado atributo
del producto de software. Tras obtener los valores para todas las mtricas de un
criterio especfico el promedio de ellas es el valor para dicho criterio [20].
El modelo de Bohem. Propone una jerarqua de niveles, en forma de un rbol
con tres ramas principales de los criterios de calidad que permiten que el
software sea de utilidad: Portabilidad, Facilidad de Uso y Facilidad de
Mantenimiento. Tiene tres niveles: Aplicaciones primarias, Construcciones
Intermedias y Construcciones Primitivas, y finalmente las Mtricas que
determinan los valores para los criterios (construcciones primitivas) [21].
ISO/IEC 9126. Estndar internacional (ISO), aplicable a todo tipo de software.
Est basado en un modelo jerrquico con tres niveles: Caractersticas,
Subcaractersticas y Mtricas. En el primer nivel tiene seis caractersticas
principales: Funcionalidad, Confiabilidad, Eficiencia, Facilidad de Mantenimiento,
Portabilidad y Facilidad de Uso. Estas caractersticas (factores) estn
compuestas a su vez por 27 subcaractersticas (subfactores) relacionadas con la
calidad externa, y 21 subcaractersticas relacionadas con la calidad interna [22].
4.2 Evaluacin del Proceso de Desarrollo de Software
Al evaluar la calidad de los procesos de desarrollo de software, se pretende

determinar su rendimiento para corregir problemas o para mejorarlos, con el
propsito de disminuir los costos de desarrollo, aumentar la productividad y elevar
la calidad de los productos.
Un proceso de desarrollo de software es el conjunto de actividades, mtodos y
prcticas que se usan para desarrollar un producto de software y darle
mantenimiento. Entindase como producto de software tanto a los programas,
componentes y sistemas y la variedad de documentos asociados al mismo
(documentos de planificacin, diseo, cdigo, casos de prueba, manuales,
reportes).
Una organizacin debe establecer estrategias para que al evaluar los procesos
que intervienen en el desarrollo de un producto de software y que al conocer su
estado actual, se pueda alcanzar el estado deseado para los mismos. El estado
actual o deseado de un proceso se asocia directamente con su rendimiento, es
decir, los resultados logrados actualmente o que se pretenden alcanzar siguiendo
ese proceso de software.
Es importante que todas las tareas que intervienen en el desarrollo de un

producto de software sean tratadas como procesos, para que puedan ser medidas
y controladas. Se mencionan a continuacin, el modelo de CMM (Capability
Maturity Model, Modelo de Madurez de Capacidades) y los estndares
internacionales considerados importantes para la evaluacin de los procesos de
desarrollo software:
CMM-SEI. El Modelo de Madurez de Capacidades del SEI (Software
Engineering Institute, Instituto de Ingeniera de Software), es un modelo que
determina la madurez de los procesos de desarrollo de software y que busca
mejorar esa madurez, reconociendo las prcticas clave necesarias para lograrlo.
En una organizacin dedicada al desarrollo de software, las prcticas se pueden
repetir mediante el establecimiento y uso de polticas y procedimientos que
permitan implementarlas y llevarlas a cabo regularmente (estandarizacin).
Estas prcticas deben aplicarse en todos los proyectos que la organizacin
maneja, y por todos los grupos de trabajo que en ella colaboran. Se establecen
objetivos cuantitativos y se realizan evaluaciones. Un proceso puede ubicarse
en un determinado Nivel de Madurez, el cual es una plataforma evolutiva bien
definida, en la bsqueda de la madurez de un proceso de desarrollo de
software. En cada uno de los niveles se indica el nivel de la capacidad de un
proceso determinado. Existen cinco Niveles de Madurez de Procesos: Inicial,
Repetible, Definido, Administrado y Optimizado [23].
ISO/IEC 12207:AMENDMENT 1:2002. Esta norma que tiene por nombre
Software life-cycle processes (Procesos del ciclo de vida del Software).
Describe los procesos principales que componen un ciclo de vida de software
integral, incluyendo sus interrelaciones. No establece un paradigma de
Ingeniera de Software a ser utilizado, pero indica los requisitos mnimos de
ingeniera necesarios en el contexto del ciclo de vida de software. Agrupa los
procesos del ciclo de vida en 3 grandes clases: Procesos Primarios, Procesos
de Soporte, y Procesos de Organizacin. Cada proceso se considera como un
conjunto de actividades, que a su vez se subdividen en tareas. Estas ltimas
transforman las entradas del proceso y generan sus salidas. Se definen en la
norma un total de 22 procesos, 95 actividades y 325 tareas. Se identifican dos
roles principales desempeados en una organizacin a lo largo del ciclo de vida
del software: cliente y proveedor [24].
ISO/IEC 15504. La norma tiene como titulo Process Assessment (Evaluacin
del Proceso de Software). Establece los requisitos para realizar una evaluacin
de los procesos de desarrollo de software, para lograr una mejora de tales
procesos y para determinar su capacidad. La evaluacin se lleva a cabo

tomando en cuenta los procesos y sus capacidades. Para evaluar los procesos,
se acude a un modelo externo, que consta de un conjunto de procesos divididos
en cinco categoras, caracterizados por sus objetivos y sus repercusiones. La
evaluacin de capacidades hace uso de un marco de trabajo que contiene seis
niveles de capacidad del proceso (Incompleto, Realizado, Administrado,
Establecido, Previsible y Optimizado), con una serie de atributos del proceso, los
cuales se relacionan directamente con la administracin y mejora de su
capacidad de realizacin. Cada atributo se evala, para ubicarlo en alguno de
los siguientes estados: No conseguido, Parcialmente conseguido, Ampliamente
conseguido, Completamente conseguido. Se realiza la evaluacin de todos los
atributos de un proceso especfico y se calcula su nivel de capacidad. Para
alcanzar un determinado nivel, todos los atributos asociados con los niveles
inferiores deben haberse valorados como Completamente conseguidos y los
atributos de ese nivel especfico deben haberse valorado como Ampliamente
conseguidos o Completamente conseguidos [25].
5 Adaptacin de Mtodos giles asegurando la Calidad de Software
Tomando en cuenta lo planteado en la seccin 4, sobre la Evaluacin de la

Calidad del Software, tanto para el producto como para el proceso y que los
modelos y estndares han sido elaborados pensando en el empleo de
Metodologas Tradicionales y adems, considerando que un mtodo debera ser
bastante flexible para permitir ajustes durante la ejecucin de proyecto. Hay tres
problemas claves relacionados con la adaptacin de Mtodos giles a proyectos
de software intentando garantizar la Calidad de Software: la confiabilidad de los
Mtodos giles (en general y en particular), Mtodos Adaptables al Entorno
(Tailoring) y finalmente, soporte brindado por la administracin al desarrollo del
proyecto.
5.1 Confiabilidad de los Mtodos giles
Lograr que los proyectos desarrollados con Metodologas giles sean de calidad
no es una tarea fcil, se tiene que garantizar que el mtodo elegido es confiable y
que el producto resultante tambin lo es.
Como es sabido, comprender los requisitos del cliente es fundamental para

asegurar que el desarrollo de software es exitoso, el problema est, en que los
usuarios rara vez tienen la habilidad para articular lo que realmente requieren y
sus necesidades cambian cuando ven el potencial del sistema y comprenden lo
que ste puede hacer por ellos. Por otra parte, la tecnologa y el dominio tambin
cambian y mientras ms tiempo tome el desarrollo, ms cambiarn.
Por consiguiente, intentar conocer todos los requisitos del producto al comienzo
del proyecto no es factible a un costo razonable.
El proceso normal empleando una Metodologa Tradicional, es entrevistar al
cliente, elaborar un documento de Definicin de Requisitos que ser revisado por
el responsable del proceso que se automatizar y que da como resultado el
documento de Especificacin de Requisitos que es el que se le entregar al Jefe
de Proyecto (Analista de Sistemas) para iniciar el desarrollo, sabiendo que se iter
lo suficiente, para que las necesidades del Cliente hayan quedado realmente bien
definidas y entendidas, para que el sistema resultante sea lo que se espera y que
se obtenga un desarrollo de Calidad, el problema est en que solamente en la
recopilacin de requerimientos pasaron semanas o meses (vase Fig. 1).
Con las Metodologas giles el proceso no es tan riguroso y el Cliente forma
parte del equipo de desarrollo en todo momento y en lugar de revisar documentos,
se examinar software funcionando, garantizando que lo que el Cliente observa es
lo que necesita y con la calidad que l espera, recordando que la Calidad del
Software depende de las necesidades del negocio y que los requisitos irn
evolucionando en cada iteracin y para que el riesgo no aumente en la explotacin
del Sistema, se focalizar el esfuerzo en los requisitos que tienen el mayor valor
de retorno (vase Fig. 2). Para lograrlo, al comienzo de cada iteracin se hace un
Levantamiento y Anlisis de los Requisitos, donde participa el equipo completo
incluyendo al dueo del producto y expertos tcnicos que sean necesarios.
Adems, se realizarn entrevistas sobre caractersticas relevantes que se tienen
que considerar en el proyecto que se est desarrollando, se harn tantas
entrevistas como se requieran para garantizar que el producto sea lo que se
espera y cada una durar tiempos cortos prefijados, para elaborar correctamente
la lista de requisitos y establecer prioridades. Ser necesario dejar claramente
establecido con el cliente los Atributos para medir la Calidad.
Documento de Documento de
Definicin de Especificacin de
Requisitos Requisitos
Cliente Gerente de Producto

Analista de Sistemas
Fig. 1. Aproximacin Clsica (Rigurosa)
SOFTWARE
Cliente Equipo de Desarrollo
Fig. 2. Aproximacin gil
5.2 Mtodos giles y Mtodos de Entorno
En la literatura, trminos diferentes se refieren a la nocin de mtodos de

adaptacin, incluyendo el ' Mtodo de Entorno ' (method tailoring), ' Mtodo de
adaptacin de fragmento ' (method fragment adaptation) e ' Ingeniera
Circunstancial de Mtodos ' (situational method engineering). El Mtodo de
Entorno se define como:
Un proceso o capacidad, en el cual, los seres humanos responden al cambio y a
interacciones dinmicas entre contextos, intenciones y fragmentos de mtodos
para determinar el mejor enfoque para el desarrollo de un sistema para un
proyecto o situacin especfica. [15]
Potencialmente, casi todos los Mtodos giles son convenientes para adaptarse
como mtodos de entorno. Incluso el mtodo DSDM se est utilizando para este
propsito y se ha adaptado con xito al contexto de CMM [11]. Se puede
considerar en situaciones apropiadas, que una caracterstica que distingue entre
los mtodos giles y los mtodos tradicionales del desarrollo del software, es que
tienden a ser relativamente mucho ms rgidos y prescriptivos y no tan fcilmente
adaptables.
La implicacin prctica es que los mtodos giles permiten que los equipos de
proyecto adapten prcticas de trabajo segn las necesidades de proyectos
individuales. Las prcticas son actividades concretas y los productos son parte del
marco de trabajo del mtodo. En un nivel extremo, la filosofa detrs del mtodo,
consiste en un nmero de principios, que pueden ser adaptados [15].
En el caso de XP la necesidad de adaptacin del mtodo se hace explcita y una
de sus ideas fundamentales, es que no hay un proceso fijo para cada proyecto
como tal, pero en la prctica debe ser adaptado a las necesidades de proyectos
individuales. No hay tampoco informes de la experiencia con las prcticas, en las
cuales, se ha adoptado XP; sin embargo, una adopcin parcial de las prcticas de
XP, segn lo sugerido por Beck (Kent Beck es el creador de eXtreme
Programming y uno de los fundadores del Manifiesto gil), s ha sido reportado en
varias ocasiones [16].
Puede hacerse una distincin entre la adaptacin esttica y la adaptacin
dinmica del mtodo. [17] La clave detrs de la adaptacin esttica, es que el
contexto del proyecto est dado al comienzo y el resto es fijado durante su
ejecucin y el resultado, es una definicin esttica del contexto del proyecto y
dada tal definicin, los mapas de ruta se pueden utilizar para determinar cules
fragmentos estructurados de mtodos, se deben emplear para ese proyecto
particular, basndose en un conjunto de criterios predefinidos.
La adaptacin dinmica del mtodo, en contraste, asume que los proyectos estn
situados en un contexto inesperado. Un contexto inesperado implica que un
proyecto tiene que ocuparse de los factores imprevisibles que afectan condiciones
relevantes que no son previsibles y esto tambin significa, que el contexto del
proyecto no es fijo, cambia durante su ejecucin y que en el caso de rutas
reguladas, no son apropiados. La implicacin prctica de la adaptacin dinmica
del mtodo es que los encargados de proyecto tienen que modificar fragmentos
estructurados o innovar a menudo nuevos fragmentos, durante la ejecucin de un
proyecto.[17]
5.3 Soporte brindado por la administracin al desarrollo del proyecto
No hay que olvidar que al emplear Mtodos giles, el Cliente pasa a formar parte
del equipo de desarrollo, se le tomar en cuenta como tal en todas las iteraciones
y para el xito del proyecto, la administracin de la organizacin debe estar dando
el soporte necesario durante todo el desarrollo, brindando todo lo que sea
necesario para que el producto automatizado resultante, sea con la Calidad

esperada por la empresa.
Se tendrn que elaborar talleres y delimitar el tiempo que se dedicar a cada
uno de ellos y a las actividades a revisar en cada reunin, los estudios sugeridos
son:
1. Levantamiento y Anlisis de los Requisitos: que tiene que tener una duracin fija
y corta como sigue:
El dueo del producto presenta sus requisitos y el equipo participa a travs de
preguntas (duracin 4 horas).
El equipo de desarrollo realiza una lista de tareas que deben realizarse para
cumplir con los requisitos (duracin 8 horas), las tareas son estimadas en
duracin (no ms de 8 horas cada una).
El dueo del producto revisa las estimaciones del equipo y prioriza sus
requerimientos por valor, de manera que puedan ser implementados por el
equipo en una iteracin corta, estableciendo la visin comn para la iteracin
(duracin 4 horas).
2. Entrevista sobre caractersticas Relevantes: tiene como objetivo obtener del
cliente informacin para elaborar una lista de requisitos, para ello, se
establecern trabajos en grupo (duracin 20 minutos), por lo cual, debern
preparse un conjunto de preguntas previas a la entrevista con el cliente que
permitan generar una lista con los requerimientos detectados. Una
recomendacin al elaborar el cuestionario gua para la entrevista, es reflexionar
lo siguiente: Cun difcil es preparse? Cun consistente es el cliente en sus
respuestas? Fue fcil ordenar la informacin del cliente para hacer una lista de
requisitos?
3. Especificacin de Atributos de Calidad: su objetivo es identificar atributos de
calidad considerados crticos para el xito del proyecto, para ello se analiza el
Backlog del Producto (Trabajo atrasado del Producto), para poder listar los
atributos crticos cuantitativos priorizados. Las tareas a realizar en esta reunin
son: una lluvia de ideas sobre atributos (pueden tomarse ideas de la norma
ISO/IEC 9126 de otro modelo que evale la calidad del producto), se reunen
atributos en temas relacionados, se identifican los atributos considerados
crticos, se especifcan cuantitativamente los dos atributos ms crticos mediante
Escala, Prueba, Plan, Peor y se comparten los resultados. Y al final de la
reunin, el equipo debe reflexionar sobre Cmo partir inventando atributos?
Qu determina que un atributo sea o no crtico? Qu tan difcil es inventar
una escala y prueba? Qu tan importante es tener los valores planificados,

bien definidos desde el comienzo?
5.4 Requisitos de Calidad
En resumen y tomando en cuenta los tres problemas claves relacionados con la

adaptacin de Mtodos giles a proyectos de software, que garanticen que el
producto resultante sea de calidad y que el proceso seguido por el mtodo
tambin lo sea, de alguna forma es necesario tomar en cuenta la Especificacin
de Atributos de Calidad e incrustarla como parte del mtodo a seguir, no olvidando
lo que ya se mencion, que la calidad depende de las necesidades del negocio o
cliente, as algunos esperan: buen desempeo y funcionamiento, que trabaje bien
tanto en una plataforma como en otra (UNIX, PC), que el producto se adapte a
necesidades especficas (AD HOC), que sea fcil de usar, que no tenga defectos,
que tenga buena manufactura y que dure mucho tiempo, etc.
Para establecer bien la lista de requerimientos, es necesario tomar en cuenta
que existen dos tipos de requisitos: Funcionales, los cuales, se cumplen o no se
cumplen (responden al Qu) y de Calidad o Atributos, que se pueden cumplir en
distinto grado (responden a Qu tan bien).
Todos los atributos se pueden y se deben expresar sin ambigedades, si un
requisito se expresa claramente, se le da prioridad sobre los no tan claros, as por
ejemplo, si se desea que los datos sean consistentes puede establecerse el grado
de consistencia que se considera aceptable.
Para describir un atributo, se sugiere utilizar el siguiente modelo:
Atribu Nombre del Atributo
to:
Tipo: Si es cuantificable, facilidad de uso, facilidad de
aprendizaje, completez, recursos, etc.
Escala Qu se mide (una dimensin)
:
Prueb Cmo se mide (un procedimiento)
a:
Peor: Valor apenas aceptable
Plan: Valor que se desea alcanzar, en conjunto con los
dems requisitos de calidad
Autori Quin, Qu o de Dnde sale (sus orgenes)
dad:
Actual Valor alcanzado en el sistema

:
Mejor: El mejor valor alcanzado por alguien en alguna parte
Adems, suele ser conveniente expresar los atributos como una jerarqua,
existirn atributos que son usualmente importantes y la lista de estos requisitos de
calidad, debera ser parte de una plantilla para la especificacin de requisitos.
De acuerdo a la norma ISO/IEC 9126 [22] son 6 los atributos que se consideran
importantes: Funcionalidad, Confiabilidad, Usabilidad, Eficiencia, Mantenibilidad y
Portabilidad; puede tomarse como base este modelo de evaluacin de la calidad
del producto u otro que se considere conveniente o que el Cliente considere
adecuado.
Para poder establecer el listado de atributos es necesario conocer el Backlog del
Producto a desarrollar.
Backlog del Producto
Para establecerlo, es necesario elegir una Metodologa gil, como puede ser:
XP, IXP (Industrial Extreme Programming, Programacin Extrema Industrial),
Scrum, Agile Modeling (Modelado gil), ASD (Adaptive Software Development,
Desarrollo de Software Adaptativo), Crystal Clear y otras Crystal Methodologies
(Metodologas Crystal), DSDM, FDD, Lean software development (Desarrollo de
Software de Soporte), AUP (Agile Unified Process, Proceso Unificado gil) o
Dialogue-Driven Development (Desarrollo Manejado por Dilogo) y seguir el
proceso, que dicte la metodologa elegida.
Lo importante es que el Backlog del Producto incluye elementos que se
necesitan para iniciar el proyecto y los elementos del retraso, estn clasificados
(Funcin).
Adems, deben tomarse en cuenta factores que tpicamente, complican el
Backlog del Producto:
Complejidad del Producto: acuerdo en los requisitos y estabilidad de la
tecnologa a utilizar.
Complejidad del Equipo de Desarrollo: experiencia del equipo trabajando juntos,
conocimiento por parte del equipo de la tecnologa a utilizar, conocimiento por
parte del equipo de negocio donde el producto se desarrolla.
La Complejidad se usa para corregir el esfuerzo estimado.
Se deber estimar el esfuerzo de implementacin de cada requisito, incluyendo
esfuerzo para anlisis, diseo, desarrollo, documentacin y pruebas, as como el
estimado de la cantidad de personas-das y corregir el esfuerzo de cada requisito
segn su complejidad.
Resumiendo, para la creacin del Backlog del Producto se tiene que:

1. Priorizar y estimar el Backlog del Producto.
2. Se necesita para ello, la lista de requisitos y atributos crticos.
3. Las tareas a realizar son: Reunir las entradas ponindolas en una nica lista,
priorizar y estimar las caractersticas relevantes, planificar el nmero de
iteraciones que se requieren para implementar el retraso.
4. Se deben considerar equipos en donde los desarrolladores han estado
trabajando juntos al menos durantes los ltimos 12 meses en la tecnologa
requerida por el proyecto. Al menos tres de los integrantes del equipo, tienen
que tener bastante experiencia en desarrollos para el sector en el que se lleva a
cabo el proyecto.
6 Mtodos giles y la Administracin del Proyecto
Los Mtodos giles se diferencian grandemente de los tradicionales, por la

manera en que cubren la administracin de proyectos y algunos mtodos, se
complentan con guas para la administracin del proyecto, pero generalmente no
existe ninguna documentacin de soporte [11].
Tomando en cuenta todo lo descrito en la seccin 5 de esta investigacin, si se
elige un Mtodo gil para el desarrollo de un proyecto, es posible que el producto
resultante sea de calidad.
Como ejemplo, PRINCE2 (PRojects IN Controlled Environments, Proyectos en
Ambientes Controlados) es una metodologa gil recomendable para la
administracin de proyectos que cubre la administracin, control y organizacin de
un proyecto.[26]
7 Conclusiones
En muchas ocasiones no es posible disponer de unas especificaciones correctas

desde el primer momento, porque puede ser difcil para el usuario establecer al
inicio todos los requisitos; en otras, hay cambio de parecer de los usuarios sobre
las necesidades reales cuando ya se ha comenzado el proyecto, siendo probables
que los verdaderos requisitos no se reflejen en el producto final. Otro de los
problemas de esta aproximacin es que los resultados no se ven hasta muy
avanzado el proyecto, por lo tanto la realizacin de modificaciones, si ha habido un

error, es muy costosa.
El desarrollo gil se confunde en ocasiones con la Codificacin de Vaquero
(Cowboy Coding), sin embargo ofrece soluciones al problema de la especificacin
de requerimientos, tratando de garantizar que el producto resultante sea de
calidad y lo esperado por el cliente, las Metodologas giles han tenido muchas
crticas, por ejemplo, XP inicialmente ocasion mucho ruido y controversia, sin
embargo incluso los partidarios de desarrollos con Mtodos giles, lo interpretaron
como malos entendidos acerca del desarrollo gil.
Los Mtodos giles no presuponen algn tipo de ciclo de vida para su ejecucin,
es ms bien una filosofa de valores, ideas, conceptos y principios para aplicar en
la metodologa que se desarrolle. Los Mtodos giles y las tcnicas de desarrollo
orientadas a objetos, se adaptan mejor o manejan mejor la incertidumbre, pero,
como nada es gratis son ms costosas. Por tanto, no siempre se justifican y
adems, su adopcin general, como un camino ms, requiere de un cambio
cultural que se est produciendo, pero que no se ha completado an.
Existen muchos otros artculos y discusiones sobre este tema de los Mtodos
giles. Mientras stas pueden no ser metodologas completas, ofrecen una luz
sobre este campo creciente.
Metodologas Tradicionales
Metodologas Desarrollo
Modelo de Cascada Cowboy Coding
giles Iterativo
El perodo de tiempo Es la ausencia de
es medido en meses un mtodo definido:
y si no se tiene una los miembros de
buena planificacin, equipo hacen lo
del tiempo que debe que ellos sienten
Enfatizan en el durar cada etapa, los que es lo correcto.
El perodo de
desarrollo proyectos se salen La nueva
tiempo es
iterativo de control, ya que, es evaluacin
medido en
construyendo la ms predictiva de frecuente del
meses y si no
software en todas las desarrollo gil de
se tiene una
perodos cortos metodologas, proyectos, enfatiza
buena
de tiempo, como pasando por la en la comunicacin
planificacin, los
cajas cerradas de exigencia de la cara a cara y el
proyectos se
un tiempo captura de empleo
salen de control.
estricto. requerimientos, relativamente
anlisis, diseo, escaso de
codificacin y documentos, que
pruebas en una en ocasiones hace
secuencia estricta que los
preplaneada. desarrolladores lo
Tiende a ser confundan con
sumamente Cowboy Coding
El trabajo se (Codificacin de
A veces no es colaborativo porque
realiza de Vaquero). Sin
muy cada etapa tiene que
manera embargo, los
colaborativo. estar bien definida y
colaborativa. Equipos giles,
terminada para pasar
a la siguiente. realmente siguen
Producen un procesos definidos

desarrollo (a menudo de
completo y forma muy
probado (pero a disciplinada y
una menor rigurosa),
escala) en pocas distinguiendo
semanas o accesos giles de
Puede dar como
meses. Enfatizan la codificacin de
resultado una
en obtener El porcentaje de vaquero.
integracin y
piezas las pruebas Como con todas las
esfuerzos de
funcionando que abarca un 40% metodologas, la
pruebas a travs de
le den un valor de todo el habilidad y la
todo el ciclo de
agregado al desarrollo del experiencia del
desarrollo, un
negocio software y en usuario define el
perodo de tiempo
prontamente y ocasiones, si no grado de xito y/o
que a veces se
continuamente se planifica bien abuso de tal
extiende a varios
mejoran y/o el tiempo para actividad.
meses o varios aos.
adicionan pruebas puede Los controles y/o
El tamao y dificultad
funcionalidad ser causante de chequeos ms
de la integracin y
durante el tiempo que el proyecto rgidos y los
esfuerzo de pruebas
de vida del falle. balances encajados
es causante de que
proyecto; en dentro de un
el proyecto falle.
ocasiones, no se proceso, ofrecen
realizan pruebas, niveles rigurosos
sino hasta que el de responsabilidad
software se del usuario; es
encuentra decir, la
completamente degradacin de
trabajando. procedimientos
El progreso se mide bien intencionados

en trminos de datos que conducen a
El progreso se
Acentan en que especficos que actividades, a
mide por cada
el software exigen artefactos menudo definidas
entregable
trabajando es la entregables, como Codificacin
tangible al final
primera medida documentos de de Vaquero.
de una
del progreso. diseo, proyectos de
iteracin.
prueba y revisiones
de cdigo.
Se produce poca
Se produce mucha documentacin.
documentacin.
Ms Artefactos.
Pocos artefactos.
Basadas en
heursticas
Basadas en normas provenientes de
provenientes de
estndares seguidos por el entorno de
prcticas de
desarrollo.
produccin de
cdigo.
Especialmente Cierta resistencia a los cambios, debido
preparados para a que al planeacin tiene que rehacerse
cambios durante y se corre el riesgo de desechar todo el
el proyecto. trabajo y volver a empezar todo de
nuevo.
Impuestas Impuestas externamente y en
internamente (por ocasiones es necesario combinar las
el equipo) que metodologas para llegar al buen
es altamente termino de los proyectos y cumplir as
colaborativo y con la planificacin establecida, por otra
existen pocos parte, existen ms roles que controlar.
roles, bien
definidos.
Proceso mucho ms controlado, con
Proceso menos
numerosas polticas/normas que
controlado, con
ayudan a acotar la planificacin de cada
pocos principios.
etapa.
No existe
contrato
Existe un contrato prefijado, para la
tradicional o al
planificacin y tiempos establecidos.
menos, es
bastante flexible.
El cliente interacta con el equipo de
El cliente es desarrollo mediante reuniones, pero no
parte del equipo se considera parte del equipo,
de desarrollo. solamente aporta opiniones y da su
visto bueno.
Grupos
pequeos
(menos de 10
integrantes) y
trabajando en el
Grupos grandes y posiblemente
mismo sitio y
distribuidos, no necesariamente con
tienen que ser
experiencia en el nuevo desarrollo.
personal
altamente
calificado en el
tipo de
desarrollo.
Menos nfasis en La arquitectura del software es esencial
la arquitectura y se expresa mediante modelos.
del software.
Poco nfasis en Mucho nfasis en el seguimiento de
el seguimiento de una Gestin de Calidad.
una Gestin de
Calidad.
Tabla 1. Comparativo entre Metodologas giles y Metodologas Tradicionales (No

giles)
Referencias
[1] Craig Larman, Victor R, Basili. Iterative and Incremental Development: A Brief
History. Published by the IEEE Computer Society. June 2003.
[2] Vase la liga de Alianza gil: http://www.agilealliance.com/
[3] Vase la liga del Manifiesto gil: http://agilemanifesto.org/
[4] Ron Jeffries, Ann Anderson, Chet Hendrickson. Extreme Programming
Installed (Paperback). The XP Series. December 2001.
[5] Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward
Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt,
Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken
Schwaber, Jeff Sutherland, Dave Thomas.
[6] Vanse los principios en la liga: http://www.agilemanifesto.org/principles.html
[7] Barry Boehm, R. Turner. Balancing Agility and Discipline: A Guide for the
Perplexed. Boston, MA: Addison-Wesley. ISBN 0-321-18612-5. Appendix A,
pages 165-194. 2004.
[8] Laplante, P.A., C.J. Neill (February 2004). The Demise of the Waterfall Model
Is Imminent and Other Urban Myths. ACM Queue 1 (10). Retrieved on 2006-
05-13.
[9] Coleman and Verbruggen: A quality software process for rapid application
development, Software Quality. Journal 7, p. 107-1222. 1998.
[10] Cohen, D., Lindvall, M., & Costa, P. An introduction to agile methods. In
Advances in Computers (pp. 1-66). New York: Elsevier Science, 2004.
[11] Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. New Directions
on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254,
2003.
[12] Scott Ambler. Architecture and Design: Supersize Me. Dr. Dobbs Magazine.
February 15, 2006. (Dr. Dobbs Portal The World of Software Development:
http://www.ddj.com/dept/architect/184415491)
[13] Scott Ambler. Architecture and Design: Bridging the Distance. Dr. Dobbs
Magazine. August 12, 2002. (Dr. Dobbs Portal The World of Software
Development: http://www.ddj.com/dept/architect/184415491)
[14] Martin Fowler. Using an Agile Software Process with Offshore Development.
Significant Revisions: 18 Jul 06: Updated again after a trip to India. Added a lot
of small changes around the document. (Vase liga:
http://www.martinfowler.com/articles/agileOffshore.html)
[15] Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. An Agile
Information Systems Development Method in use. Turk J Elec Engin, 12(2),
127-138, 2004.
[16] Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. Agile Software
Development Methods: Review and Analysis. VTT Publications 478, 2002.
[17] Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. On the Adaptation
of An Agile Information Systems Development Method. Journal of Database
Management Special issue on Agile Analysis, Design, and Implementation,
16(4), 20-24, 2005.
[18] Somerville, I., Software Engineering, Sixth Edition. Pearson Education
Limited, 2001.
[19] Pressman, R. S., Software Engineering. A Practitioners Approach, Fifth
Edition. McGraw-Hill International, 2001.
[20] McCall, J.A., Cavano, J.P., A Framework for the Measurement of Software
Quality, ACM Software Quality Assurance Workshop, 1978.
[21] Bohem, B.W. , Software Engineering Economics, Prentice Hall, 1981.
[22] ISO/IEC 9126: Software Engineering - Product quality, International
Organization for Standardization, 2000.
[23] Paulk, M., Capability Maturity Model for Software, Software Engineering
Institute, Carnegie Mellon University, 1993.
[24] ISO/IEC 12207: AMENDMENT 1:2002: Information technology - Software life
cycle processes, International Organization for Standardization, 2002.
[25] ISO/IEC 15504: Information technology - Process assessment, International
Organization for Standardization, 2004.
[26] Agile Alliance at http://agilealliancebeta.org/article/file/904/file.pdf

Calidad de Software en El Uso de Metodologias Agiles para El Desarrollo de Sotware PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Calidad de Software en El Uso de Metodologias Agiles para El Desarrollo de Sotware PDF

Uploaded by

Copyright:

Available Formats

Calidad de Software en el uso de Metodologas giles para el Desarrollo de

Sandra Dinora Orantes Jimnez

Centro de Investigacin en Computacin, Instituto Politcnico Nacional, Av. Juan

Resumen. El desarrollo de software no es tarea fcil y por ello, existen

Palabras Clave: Metodologas giles, Calidad de Software, Individuos e

Existen muchas metodologas para el desarrollo de software y varias de ellas se

Las Metodologas giles tambin acentan en que el software trabajando es la

2 Metodologas giles, un poco de historia

La definicin moderna de Desarrollo de Software gil surge a mediados de los

El punto de partida fue el Manifiesto gil (Agile Manifesto) [3], un documento

2.1 Manifiesto gil Principios detrs de los Mtodos giles

Los Mtodos giles no son una familia de procesos de desarrollo, ni un

Los proyectos son construidos alrededor de individuos motivados, que se

2.2 Comparacin con otras Metodologas

Las Metodologas giles a veces se caracterizan por ser lo opuesto de las

Modelo en Cascada es realmente con el que menos tienen en comn las

3 Conveniencia del Uso de Mtodos giles

Aunque los Mtodos giles se diferencian en sus prcticas, ellos comparten un

4 Evaluacin de la Calidad del Software

Al hablar de la calidad del software, pueden distinguirse dos reas principales:

4.1 Evaluacin del Producto

Para las organizaciones dedicadas al desarrollo de software, es importante ofrecer

El modelo de McCall. Incorpora once factores, desde el punto de vista de tres

4.2 Evaluacin del Proceso de Desarrollo de Software

Al evaluar la calidad de los procesos de desarrollo de software, se pretende

Es importante que todas las tareas que intervienen en el desarrollo de un

procesos y para determinar su capacidad. La evaluacin se lleva a cabo

5 Adaptacin de Mtodos giles asegurando la Calidad de Software

Tomando en cuenta lo planteado en la seccin 4, sobre la Evaluacin de la

5.1 Confiabilidad de los Mtodos giles

Como es sabido, comprender los requisitos del cliente es fundamental para

Cliente Gerente de Producto

Fig. 1. Aproximacin Clsica (Rigurosa)

Cliente Equipo de Desarrollo

Fig. 2. Aproximacin gil

5.2 Mtodos giles y Mtodos de Entorno

En la literatura, trminos diferentes se refieren a la nocin de mtodos de

5.3 Soporte brindado por la administracin al desarrollo del proyecto

necesario para que el producto automatizado resultante, sea con la Calidad

una escala y prueba? Qu tan importante es tener los valores planificados,

5.4 Requisitos de Calidad

En resumen y tomando en cuenta los tres problemas claves relacionados con la

Actual Valor alcanzado en el sistema

Resumiendo, para la creacin del Backlog del Producto se tiene que:

6 Mtodos giles y la Administracin del Proyecto

Los Mtodos giles se diferencian grandemente de los tradicionales, por la

En muchas ocasiones no es posible disponer de unas especificaciones correctas

avanzado el proyecto, por lo tanto la realizacin de modificaciones, si ha habido un

Producen un procesos definidos

El progreso se mide bien intencionados

Tabla 1. Comparativo entre Metodologas giles y Metodologas Tradicionales (No

You might also like