Académique Documents
Professionnel Documents
Culture Documents
11:19 a. m.
2.11.3 Metodologas.
Las metodologas han evolucionado de manera significativa en las ltimas dcadas como
se puede observar en la tabla 2.7 Permitiendo as el xito o el fracaso de muchos de los
sistemas desarrollados para distintas reas.
Algunas de las metodologas tradicionales ms utilizadas para el desarrollo de software han
sido, la denominada proceso personal de software (PSP) y la proceso en equipo para el
software TSP. El TSP toma sus fundamentos en que los ingenieros deben de dar a
conocer bien su trabajo y que puedan implementar un plan para poderlo realizar mejor,
cuando el plan se implementa, pueden ahorrarse tiempo en realizar el trabajo y por ende
generar productos de calidad. El TSP contempla dos componentes principales:
1) Creacin de equipo
2) Trabajo en equipo o componente de gestin.
El TSP es una metodologa para dirigir el desarrollo de software adems de establecer un
entorno donde el trabajo efectivo de equipo sea normal y natural. En donde involucra a los
ingenieros a desarrollar un trabajo en equipo. El desarrollo del (TSP) toma sus bases en la
estrategia de calidad que propuso W. Edwards Deming (1982), con las etapas de planear,
hacer, verificar y actuar. Y J.M. Juran (1988). El TSP ofrece un contexto disciplinado para el
trabajo de la ingeniera del software. La motivacin principal es que los ingenieros siguiendo
esta metodologa pueden hacer un excelente trabajo. Los ingenieros deben estar bien
Notas rpidas pgina 4
esta metodologa pueden hacer un excelente trabajo. Los ingenieros deben estar bien
capacitados, bien entrenados y deben ser bien dirigidos por un miembro calificado que
entienda bien la metodologa del TSP. El objetivo principal del TSP es guiar debidamente a
sus equipos de ingenieros. El TSP proporciona un proceso operacional definido para guiar a
los ingenieros y administradores a travs de diferentes pasos para la formacin de equipos
de trabajo.
Antes de que los miembros del equipo de trabajo participen en el equipo de TSP, deben
saber cmo organizar bien su trabajo. Se requiere que el equipo o el personal se encuentre
entrenado primero con el Personal Software Process (PSP). Esto le permite a los ingenieros
obtener el conocimiento en saber cmo crear un plan detallado, reuniendo y usando
procesos de datos, usando valores obtenidos para seguir un proyecto en donde puedan
medir y dirigir la calidad del producto. El objetivo del PSP es poner a los profesionales de
software a cargo de su trabajo y para que se sientan personalmente responsables de la
calidad de los productos que producen. PSP puede trabajar a la par con los objetivos de la
metodologa (TSP) son:
1) Proporcionar un entorno de equipo que apoya el trabajo de la PSP
2) Construir y mantener un equipo autodirigido.
PSP y TSP son potentes herramientas que proporcionan los conocimientos necesarios, la
disciplina y el compromiso necesarios para los proyectos de software exitoso. Se sabe que
en nuestro pas para que se pueda producir software con calidad se debe de adoptar un
nivel de madurez de procesos alto, es decir, que sea equiparable a los niveles
internacionales, esto es a travs del CMMI (Capability Maturity Model Integration), pero es
difcil implementarlo en organizaciones pequeas. En Mxico se cuenta con la norma
mexicana basada en MoProsoft (Modelo de Procesos para la Industria del Software), pero
esta se centra en los procesos de las organizaciones pero no en las personas, que son los
ms importantes para que ellas funcionen. En Mxico no solamente se debe incrementar el
nivel de madurez en los procesos de la industria de Software, si no que, se debe incluir el
mejoramiento del elemento bsico que sustente la industria, que son las personas.
Con PSP, los desarrolladores utilizan procesos bien definidos y medibles. Se toma
informacin de tamao, tiempo y defectos al momento de realizar el trabajo. Se utilizan los
datos para: planear y monitorear el trabajo, as como administrar la calidad de los productos
que se producen y medir el desempeo. TSP ha permitido resolver problemas tpicos de
negocio: como predecir el costo y tiempo, mejorar la productividad y establecer ciclos de
desarrollo para generar la mejora en la calidad de los productos. PSP/TSP mejoran el
desempeo tanto de equipos como de individuos; es disciplinado y dirigida en todo su
desarrollo a la planeacin; provee beneficios inmediatos y medibles; acelera las iniciativas
de mejora de los procesos organizacionales. Con TSP, los equipos encuentran y reparan
defectos en etapas tempranas del proceso de desarrollo. Esto reduce de manera importante
el tiempo de pruebas.
pequeos con alta motivacin, mtodos informales y una simplicidad general del desarrollo.
Los procesos de desarrollo rpido de software estn diseados para producir software til
de forma rpida. Generalmente, son procesos interactivos en los que se entrelazan la
especificacin, el diseo, el desarrollo y las pruebas.
En los aos 80 y principios de los 90, exista una opinin general de que la mejor forma de
obtener un software de calidad era a travs de una planificacin cuidadosa del proyecto y
de la utilizacin de mtodos de anlisis y diseo soportados por herramientas CASE
(Computer Aided Software Engineering). Esta opinin vena fundamentalmente de la
comunidad de ingenieros de software implicado en el desarrollo de grandes sistemas y que
normalmente se componan de un gran nmero de programas individuales. Este software
era desarrollado por grandes equipos que trabajaban para compaas diferentes y que a
menudo estaban dispersos geogrficamente y trabajaban durante largos periodos de
tiempo.
Sin embargo, cuando este enfoque era aplicado a sistemas de negocios pequeos y de
tamao medio, el esfuerzo invertido era tan grande que algunas veces dominaba el proceso
de desarrollo del software, es decir, se pasaba ms tiempo pensando en cmo se deba
desarrollar el sistema que en cmo programar el desarrollo y cmo hacer las pruebas
pertinentes. El descontento de esto produjo que varios desarrolladores propusieran nuevos
mtodos que eran ms giles. Aunque estos mtodos se basan principalmente en la nocin
del desarrollo y en las entregas incrementales, proponen procesos diferentes para alcanzar
el objetivo.
En una reunin celebrada en febrero de 2001 en Utah-EEUU, nace el trmino "gil" aplicado
al desarrollo de software. En esta reunin participan un grupo de diecisiete expertos de la
industria del software, incluyendo algunos de los creadores o impulsores de metodologas
de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los
equipos a desarrollar software rpidamente y respondiendo a los cambios que podran
surgir a lo largo de los proyectos. Se pretenda ofrecer una alternativa a los procesos de
desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos por la
documentacin que se genera en cada una de las actividades desarrolladas. Varias de las
denominadas metodologas giles ya estaban siendo utilizadas con xito en proyectos
reales, pero les faltaba una mayor difusin y reconocimiento. Tras esta reunin se cre The
Agile Alliance (2001), una organizacin, sin nimo de lucro, dedicada a promover los
conceptos relacionados con el desarrollo gil de software y ayudar a las organizaciones
para que adopten dichos conceptos.
El punto de partida fue el manifiesto gil, un documento que resume la filosofa "gil". A
continuacin en la tabla 2.8, vamos a enumerar las principales diferencias de una
Metodologa gil respecto a las Metodologas Tradicionales (llamadas peyorativamente no
giles o pesadas). Estas diferencias que no se refieren slo al proceso en s, sino
tambin al contexto de equipo y organizacin que es ms favorable a cada uno de estas
filosofas de procesos de desarrollo de software.
Si bien la idea de participacin del cliente en el proceso de desarrollo es atractiva, el xito
depender de tener un cliente que est dispuesto y lo ms importante pueda pasar tiempo
con el equipo de desarrollo para as presentar a todos los implicados del sistema, los
clientes estn sometidos a otras presiones y no pueden participar plenamente en el
desarrollo del software. El cliente es el punto clave, solicita los requerimientos que se deben
de incluir. Los miembros individuales del equipo puede no tener la personalidad propia para
una participacin intensa. Por lo tanto, es posible que no se relacionen adecuadamente con
los otros miembros del equipo. Priorizar los cambios puede ser extremadamente difcil,
especficamente en sistemas en los que existen muchos implicados.
Mantener la simplicidad requiere un trabajo extra. Cuando se trabaja bajo presin por las
agendas de entregas, los miembros del equipo no pueden tener a tiempo las
especificaciones del sistema. Por consiguiente los mtodos giles tienen que depender de
contratos donde el cliente paga por el tiempo necesario para el desarrollo del sistema en
lugar de por el desarrollo de un conjunto de requerimientos especficos. Siempre y cuando
el proyecto vaya caminando en forma, esto beneficiar tanto al cliente como al
desarrollador. Todos los mtodos tienen lmites y los mtodos giles son apropiados para
algunos tipos de desarrollo de sistemas. Son los ms idneos para el desarrollo de
sistemas para pequeos negocios y medianas empresas. No son adecuados para el
desarrollo de sistemas a gran escala con equipos de desarrollo situados en diferentes
lugares geogrficamente hablando ya que puede haber complejas interacciones con otros
sistemas o hardware.
Los mtodos giles no se deben de utilizar para el desarrollo de sistemas crticos en los que
Notas rpidas pgina 6
Los mtodos giles no se deben de utilizar para el desarrollo de sistemas crticos en los que
es necesario generar un anlisis detallado de todos los requerimientos del sistema para as
comprender mejor sus implicaciones de seguridad o de proteccin. El crecimiento de los
mtodos giles y su penetracin ocurre a un ritmo pocas veces visto en la industria: en tres
o cuatro aos, segn el Cutter Consortium, el 50% de las empresas define como giles
ms de la mitad de los mtodos empleados en sus proyectos (Charette, 2004). Algunas de
las metodologas agiles mas usadas en la actualidad se describen a continuacin.
Metodologa XP programacin extrema
La programacin extrema XP es posiblemente el mtodo gil ms conocido y ampliamente
utilizado. El nombre de XP fue acuado por Beck (2000), debido a que el enfoque fue
desarrollado utilizando las mejores prcticas del desarrollo iterativo y con la participacin
extrema del cliente. La programacin extrema (XP), que algunos consideran una innovacin
extraordinaria y otros creen cnica (Rakitin, 2001). En la metodologa extrema, todos los
requerimientos se expresan como escenarios (llamados historias de usuario), los cuales se
implementan directamente como una serie de tareas. Los programadores trabajan en
parejas y desarrollan pruebas para cada tarea antes de escribir el cdigo. Todas las
pruebas se deben ejecutar satisfactoriamente cuando el cdigo nuevo se integra al sistema.
Existe un pequeo espacio de tiempo entre las entregas del sistema.
El desarrollo incremental se lleva a travs de entregas pequeas y frecuentes del sistema y
por medio de un enfoque que sirve para la descripcin de requerimientos basado en las
historias del clientes o escenarios que pueden ser la base para el proceso de planificacin.
La participacin del cliente se lleva a cabo a travs del compromiso y del tiempo completo
del cliente en el equipo de desarrollo. Los colaboradores directos de los clientes participan
en el desarrollo y son los responsables de definir las pruebas necesarias que servirn para
la aceptacin del sistema. El inters de las personas, en vez de los procesos, se lleva a
travs de la programacin en parejas, la propiedad colectiva del cdigo y un proceso de
desarrollo sostenible que no implique excesivas jornadas de trabajo. El cambio se lleva a
cabo a travs de las entregas regulares del sistema, un desarrollo previamente probado y la
integracin continua. El mantenimiento se lleva a cabo a travs de una recta actualizacin
constante para mejorar la calidad del cdigo y la utilizacin de diseos sencillos que no
prevn cambios futuros en el sistema.
En XP, los clientes estn implicados en la especificacin y establecimiento de prioridades
de los requerimientos del sistema. Dichos requerimientos no se especifica como una lista de
funciones requeridas en el sistema. Ms bien, los clientes del sistema son parte
fundamental del equipo de desarrollo esto permite que discutan escenarios con todos los
miembros del equipo. Desarrollar conjuntamente tarjetas de historia (story card) que
recogen las necesidades del cliente. Por ende el equipo de desarrollo intentar implementar
esos escenarios en una entrega futura del software. Un punto fundamental en la ingeniera
del soporte tradicional es que se debe de disear para futuros. Esto es que se deben de
prever los cambios futuros y disear ste de forma que tales cambios se puedan
implementar fcilmente. La metodologa XP ha descartado este principio partiendo del
hecho de que disear para el cambio es a menudo un esfuerzo intil. Con frecuencia los
cambios previstos nunca se materializa y realmente se efectan peticiones de cambios
completamente diferentes. La metodologa extrema aborda este problema sugiriendo que
se debe revisar constantemente el software. Esto es, que el equipo de programacin busca
posibles mejoras y las implementa de forma inmediata as lo que se busca es que siempre
sea fcil de entender y cambiar cuando simplemente nuevas historias.
Metodologa SCRUM
A pesar de que la metodologa XP recibe la mayor atencin bibliogrfica, las organizaciones
estn enfocando su atencin en la metodologa gil denominada SCRUM (Schwaber &
Shuterland, 2011) (Shuterland, 2012), la cual aplica las mismas premisas conceptuales que
XP pero para resolver un problema ligeramente distinto como es el de desarrollo evolutivo
de aplicaciones. SCRUM es una metodologa gil y flexible que sirve para gestionar el
desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversin para
su empresa. Se basa principalmente en construir la funcionalidad de mayor valor para el
cliente y en los principios de inspeccin continua, adaptacin, auto-gestin e innovacin.
Con SCRUM el cliente es pieza fundamental en el desarrollo de software, se entusiasma y
se compromete con el proyecto dado que lo ve crecer iteracin a iteracin. Asimismo le
permite en cualquier momento realinear el software con los objetivos de negocio de su
empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada
nueva iteracin. Esta forma de trabajo promueve la innovacin, motivacin y el compromiso
Notas rpidas pgina 7