Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
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.
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:
10
11
12
Documento de
Definicin de
Requisitos
Documento de
Especificacin de
Requisitos
Cliente
Analista de Sistemas
13
Gerente de Producto
SOFTWARE
Cliente
Equipo de Desarrollo
14
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
15
16
17
18
19
20
Metodologas Tradicionales
Metodologas
giles
Enfatizan en el
desarrollo
iterativo
construyendo
software
en
perodos cortos
de tiempo, como
cajas cerradas de
un
tiempo
estricto.
El trabajo
realiza
manera
colaborativa.
Desarrollo
Iterativo
El perodo de
tiempo
es
medido
en
meses y si no
se tiene una
buena
planificacin, los
proyectos
se
salen de control.
se
A veces no es
de
muy
colaborativo.
Modelo de Cascada
Cowboy Coding
El perodo de tiempo
es medido en meses
y si no se tiene una
buena planificacin,
del tiempo que debe
durar cada etapa, los
proyectos se salen
de control, ya que, es
la ms predictiva de
todas
las
metodologas,
pasando
por
la
exigencia
de
la
captura
de
requerimientos,
anlisis,
diseo,
codificacin
y
pruebas
en
una
secuencia
estricta
preplaneada.
Tiende
a
ser
sumamente
colaborativo porque
cada etapa tiene que
estar bien definida y
terminada para pasar
a la siguiente.
Es la ausencia de
un mtodo definido:
los miembros de
equipo hacen lo
que ellos sienten
que es lo correcto.
La
nueva
evaluacin
frecuente
del
desarrollo gil de
proyectos, enfatiza
en la comunicacin
cara a cara y el
empleo
relativamente
escaso
de
documentos, que
en ocasiones hace
que
los
desarrolladores lo
confundan
con
Cowboy
Coding
(Codificacin
de
Vaquero).
Sin
embargo,
los
Equipos
giles,
realmente siguen
Producen
un
desarrollo
completo
y
probado (pero a
una
menor
escala) en pocas
semanas
o
meses. Enfatizan
en
obtener
piezas
funcionando que
le den un valor
agregado
al
negocio
prontamente
y
continuamente
mejoran
y/o
adicionan
funcionalidad
durante el tiempo
de
vida
del
proyecto;
en
ocasiones, no se
realizan pruebas,
sino hasta que el
software
se
encuentra
completamente
trabajando.
El porcentaje de
las
pruebas
abarca un 40%
de
todo
el
desarrollo
del
software y en
ocasiones, si no
se planifica bien
el tiempo para
pruebas puede
ser causante de
que el proyecto
falle.
21
procesos definidos
(a
menudo
de
forma
muy
disciplinada
y
rigurosa),
distinguiendo
accesos giles de
la codificacin de
vaquero.
Como con todas las
metodologas,
la
habilidad
y
la
experiencia
del
usuario define el
grado de xito y/o
abuso
de
tal
actividad.
Los controles y/o
chequeos
ms
rgidos
y
los
balances encajados
dentro
de
un
proceso,
ofrecen
niveles
rigurosos
de responsabilidad
del usuario; es
decir,
la
degradacin
de
procedimientos
22
Acentan en que
el
software
trabajando es la
primera medida
del progreso.
El progreso se
mide por cada
entregable
tangible al final
de
una
iteracin.
El progreso se mide
en trminos de datos
especficos
que
exigen
artefactos
entregables,
documentos
de
diseo, proyectos de
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.
bien intencionados
que conducen a
actividades,
a
menudo definidas
como Codificacin
de Vaquero.
No
existe
contrato
tradicional o al
menos,
es
bastante flexible.
El
cliente
es
parte del equipo
de desarrollo.
Grupos
pequeos
(menos de 10
integrantes)
y
trabajando en el
mismo sitio y
tienen que ser
personal
altamente
calificado en el
tipo
de
desarrollo.
Menos nfasis en
la
arquitectura
del software.
Poco nfasis en
el seguimiento de
una Gestin de
Calidad.
23
24
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 200605-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)
25
[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