Separata de metodologia desarrollo software

INSTITUTO DE EDUCACION SUPERIOR
LUIS E. VALCARCEL
GHOMET U.D. METODOLOGIA DE DESARROLLO DE SOFTWARE 1
UNIDAD DIDACTICA
METODOLOGIA DE DESARROLLO DE SOFTWARE
EDITADO POR :
Lic Hugo Moisés Gómez Torres
www.hugoilo.webnode.es
Email hugoiloperu@gmail.com

LUIS E. VALCARCEL
METODOLOGIA DE DESARROLLO DE SOFTWARE
Introducción
Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su
producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha
actividad está claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de
cualquier otra máquina construida por el hombre. Sin embargo, respecto del software, su
construcción y resultados han sido históricamente cuestionados debido a los problemas
asociados, entre ellos podemos destacar los siguientes [1]:
• Los sistemas no responden a las expectativas de los usuarios.
• Los programas “fallan” con cierta frecuencia.
• Los costes del software son difíciles de prever y normalmente superan las estimaciones.
• La modificación del software es una tarea difícil y costosa.
• El software se suele presentar fuera del plazo establecido y con menos prestaciones de las
consideradas inicialmente.
• Normalmente, es difícil cambiar de entorno hardware usando el mismo software.
• El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.)
no suele cumplirse.
HISTORIA DE DESARROLLO DE SOFTWARE

LUIS E. VALCARCEL
VIDEO EN : https://www.youtube.com/watch?v=o6hWmAwpklc
Desde sus inicios en la década de 1940, escribir software ha evolucionado hasta convertirse en
una profesión que se ocupa de cómo crear software y maximizar su calidad. La calidad puede
referirse a cuán mantenible es el software, su estabilidad, velocidad, usabilidad,
comprobabilidad, legibilidad, tamaño, costo, seguridad y número de fallas o "bugs", así como,
entre muchos otros atributos, a cualidades menos medibles como elegancia, concisión y
satisfacción del cliente. La mejor manera de crear software de alta calidad es un problema
separado y controvertido cubriendo el diseño de software, principios para escribir código,
llamados "mejores prácticas", así como cuestiones más amplias de gestión como tamaño óptimo
del equipo de trabajo, el proceso, la mejor manera de entregar el software a tiempo y tan
rápidamente como sea posible, la "cultura" del lugar de trabajo, prácticas de contratación y así
sucesivamente
HISTORIA DEL SOFTWARE LIBRE
La historia del software libre y de código abierto como lo conocemos actualmente, se remonta
a inicios de los años 1980, época en la que la mayoría de software era privativo y surgió la
necesidad, por parte de algunos programadores, de crear proyectos que impulsaran la creación
de software libre.1 Cabe mencionar que antes, cuando las primeras computadoras nacieron (y por
ende los primeros programas informáticos), el software tenía un modelo de desarrollo cooperativo,
similar al de otras ciencias como la física; esto empezó a cambiar en los años 1960 y los años
1970, cuando nacieron las primeras compañías que «privatizaron» su código.2
Es importante señalar que el software libre y de código abierto, no debe ser confundido con el
llamado "freeware"; el software libre y de código abierto suele ser gratuito, lo que puede llevar a
confusión. El FOSS (acrónimo en inglés para free and open source software) también puede ser
comprado y vendido. La confusión es aún mayor en países de habla inglesa por la ambigüedad
de la palabra free que significa tanto libertad, como gratuidad.
En 1983, Richard Stallman lanzó el proyecto GNU para escribir un sistema operativo completo
libre de restricciones para el uso, modificación y distribuirlo con o sin mejoras. Uno de los
incidentes particulares que lo motivaron a esto fue el caso de una molesta impresora que no
podía ser arreglada porque el código fuente no era revelado.12
Otro posible evento de inspiración
para el proyecto GNU y su manifiesto fue el desacuerdo entre Stallman y Symbolics, Inc. sobre el
acceso a las actualizaciones, por parte del MIT, que Symbolics había realizado a su máquina Lisp,
la cual estaba basada en código del MIT.13
Poco tiempo después de su lanzamiento, acuñó el
término "software libre" y para promover el concepto fundó la Free Software Foundation.
Una definición de software libre fue publicada en febrero de 1986.
En 1989, fue publicada la primera versión de la Licencia Pública General de GNU.14
En 1991 se
publicó la ligeramente actualizada la versión 2 de la licencia.

LUIS E. VALCARCEL
En 1989, algunos desarrolladores de GNU crearon la compañía Cygnus Solutions.15
El núcleo (kernel) del proyecto GNU, posteriormente llamado GNU Hurd, fue retrasado
continuamente, pero la mayor parte de los demás componentes fueron completados para 1991.
Algunos de éstos, especialmente la Colección de Compiladores de GNU, se han convertido en
líderes del mercado por méritos propios. El Depurador de GNU y GNU Emacs también fueron
éxitos notables.
ERAS DE LA HISTORIA DEL SOFTWARE
PRIMERA ERA
Durante los primeros años de la era de la computadora, el software se contemplaba como
un añadido. Desde entonces el campo se ha desarrollado tremendamente. La programación de
computadoras era un “arte de andar por casa” para el que existían pocos métodos
sistemáticos. El desarrollo del software se realizaba virtualmente sin ninguna planificación,
hasta que los planes comenzaron a descalabrarse y los costos a correr. Los programadores
trataban de hacer las cosas bien, y con un esfuerzo heroico, a menudo salían con éxito. Los
problemas a ser resueltos eran principalmente de una naturaleza técnica, el énfasis estaba en
expresar algoritmos conocidos eficazmente en algún lenguaje de programación.
En estos primeros años lo normal era que el hardware fuera de propósito general. Por
otra parte, el software se diseña a medida para cada aplicación y tenía una distribución
relativamente pequeña. El software como producto estaba en su infancia. La mayoría del
software se desarrollaba y era utilizado por la misma persona un organización. La misma
persona lo escribía , lo ejecutaba y, si fallaba, lo depuraba. Debido a que la movilidad en el
trabajo era baja, los ejecutivos estaban seguros de que esa persona estará allí cuando se
encontrara algún error. Debido a este entorno personalizado del software, el diseño era un
proceso implícito, realizado en la mente de alguien, y la documentación normalmente no
existía.
A lo largo de los primeros años aprendimos mucho sobre la implementación de sistemas
informáticos, pero relativamente poco sobre la ingeniería de las computadoras. Sin embargo,
en honor de la verdad, debemos reconocer que durante esa era se desarrollaron muchos
sistemas informáticos excepcionales. Algunos de ellos todavía se siguen utilizando hoy y, por
sus características, siguen siendo admirados con toda justicia.
SEGUNDA ERA
La segunda era en la evolución de los sistemas de computadora se extienden desde la
mitad de la década de los sesenta hasta finales de los setenta. La multiprogramación y los
sistemas multiusuario introdujeron nuevos conceptos de interacción hombre - máquina. Las
técnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de
sofisticación del hardware y del software. Los sistemas de tiempo real podían recoger, analizar
y transformar datos de múltiples fuentes, controlando así los procesos y produciendo salidas en

LUIS E. VALCARCEL
milisegundos en lugar de en minutos. Los avances en los dispositivos de almacenamiento en
línea condujeron a la primera generación de sistemas de gestión de bases de datos.
La segunda era se caracterizó también por el establecimiento del software ya se
desarrollaba para tener una amplia distribución en un mercado multidisciplinario. Los
programas se distribuían para computadoras grandes y para minicomputadoras, a cientos e
incluso a miles de usuarios. Los patronos de la industria, del gobierno y de la universidad se
aprestaban a “desarrollar el mejor paquete de software” y ganar así mucho dinero.
Conforme crecía el número de sistemas informáticos, comenzaron a extenderse as
bibliotecas de software de computadora. Las casas desarrollaban proyectos en los que se
producían programas de decenas de miles de sentencias fuente. Los productos de software
comprados al exterior incorporaban cientos de miles de nuevas sentencias. Una nube negra
apareció en el horizonte. Todos esos programas, todas esas sentencias fuente tenían que ser
corregidos cuando se detectaban fallos, modificados cuando cambiaban los requisitos de los
usuarios o adaptados a nuevos dispositivos hardware que se hubieran adquirido. Esta
actividades se llamaron colectivamente mantenimiento del software. El esfuerzo gastado en el
mantenimiento del software comenzó a absorber recursos en una medida alarmante.
Aún peor, la naturaleza personalizada de muchos programas los hacía virtualmente
imposibles de mantener. Había comenzado una crisis del “software”
TERCERA ERA
La tercera era en la evolución de los sistemas de computadora comenzó a mediados de
los años setenta y continuó más allá de una década. El sistema distribuido, múltiples
computadoras, cada una ejecutando funciones concurrentemente y comunicándose con alguna
otra, incrementó notablemente la complejidad de los sistemas informáticos. Las redes de área
local y de área global, las comunicaciones digitales de alto ancho de banda y creciente
demanda de acceso “instantáneo” a los datos, supusieron una fuente presión sobre los
desarrolladores del software. Aún más, los sistemas y el software que lo permitían continuaron
residiendo dentro de la industria y de la academia. El uso personal era extraño.
La conclusión de la tercera era se caracterizó por la llegada y amplio uso de los
microprocesadores. El microprocesador ha producido un extenso grupo de productos
inteligentes, desde productos inteligentes, desde automóviles hasta hornos microondas, desde
robots industriales a equipos de diagnóstico de suero sanguíneo, pero ninguno ha sido más
importante que la computadora personal. En menos de una década, las computadoras llegarán
a ser fácilmente accesibles al público.
CUARTA ERA
La cuarta era de la evolución de sistemas informáticos se aleja de las computadoras
individuales y da los programas de computadoras, dirigiéndose al impacto colectivo de las
computadoras individuales y de los programas de computadoras, dirigiéndose al impacto
colectivo de las computadoras y del software. Potentes máquinas personales controladas por
sistemas operativos sofisticados, en redes globales y locales, acompañadas por aplicaciones de
software avanzadas se han convertido en la norma. Las arquitecturas informáticas están
cambiando de entornos centralizados de grandes computadoras a entornos descentralizados

LUIS E. VALCARCEL
cliente/servidor. Las redes de información en todo el mundo proporcionan una infraestructura
que iguala a expertos y políticos en pensar sobre una “superautopista de información” y una
“conexión del ciberespacio”. De hecho internet se puede observar como un “software” al que
pueden acceder usuarios individuales.
La industria del software ya es la cuna de la economía del mundo. Las decisiones
tomadas por gigantes de la industria tales como Microsoft arriesgan billones de dólares. A
medida que la cuarta generación progresa, han comenzado a surgir nuevas tecnologías. Las
tecnologías orientadas a objetos están desplazando rápidamente los enfoques de desarrollo de
software más convencionales en muchas áreas de aplicaciones. Aunque las predicciones de las
computadoras de “quinta generación”” continúan eludiéndonos, “las técnicas de cuarta
generación” para el desarrollo del software están cambiando en forma en que la comunidad del
software construye programas informáticos. Los sistemas expertos y el software de
inteligencia artificial han salido del laboratorio para entrar en aplicaciones prácticas de una
gran variedad de problemas del mundo real. El software de redes neuronales artificiales junto
con la aplicación de lógica difusa ha abierto posibilidades excitantes para el reconocimiento de
patrones y habilidades de procesamiento de información de carácter humano. La
programación de realidad virtual y los sistemas multimedia ofrecen formas radicalmente
diferentes de comunicar información al usuario final. “Los algoritmos genéricos” ofrecen el
potencial para el software que reside dentro de las computadoras biológicas masivamente en
paralelo.
RESUMEN
DESARROLLO DE SOFTWARE
Según el Centro Experimental de Ingeniería de Software (CEIS)1
, el estudio de mercado The
Chaos Report realizado por Standish Group Internactional2
en 1996, concluyó que sólo un 16% de
los proyectos de software son exitosos (terminan dentro de plazos y costos y cumplen los
1 http://www.ceis.cl/Gestacion/Gestacion.htm (5.3.2003)
2 http://standishgroup.com/ (5.3.2003)

LUIS E. VALCARCEL
requerimientos acordados). Otro 53% sobrepasa costos y plazos y cumple parcialmente los
requerimientos. El resto ni siquiera llega al término. Algunas deficiencias comunes en el desarrollo
de software son:
• Escasa o tardía validación con el cliente.
• Inadecuada gestión de los requisitos.
• No existe medición del proceso ni registro de datos históricos.
• Estimaciones imprevistas de plazos y costos.
• Excesiva e irracional presión en los plazos.
• Escaso o deficiente control en el progreso del proceso de desarrollo.
• No se hace gestión de riesgos formalmente.
• No se realiza un proceso formal de pruebas.
• No se realizan revisiones técnicas formales e inspecciones de código.
El primer reconocimiento público de la existencia de problemas en la producción de software tuvo
lugar en la conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN en Garmisch
(Alemania), dicha situación problemática se denominó crisis del software. En esta conferencia,
así como en la siguiente realizada en Roma en 1969, se estipuló el interés hacia los aspectos
técnicos y administrativos en el desarrollo y mantenimiento de productos software. Se pretendía
acordar las bases para una ingeniería de construcción de software. Según Fritz Bauer [2] lo que
se necesitaba era “establecer y usar principios de ingeniería orientados a obtener software de
manera económica, que sea fiable y funcione eficientemente sobre máquinas reales”. Esta
definición marcaba posibles cuestiones tales como: ¿Cuáles son los principios robustos de la
ingeniería aplicables al desarrollo de software de computadora? ¿Cómo construimos el software
económicamente para que sea fiable? ¿Qué se necesita para crear programas de computadora
que funcionen eficientemente no en una máquina sino en diferentes máquinas reales?. Sin
embargo, dicho planteamiento además debía incluir otros aspectos, tales como: mejora de la
calidad del software, satisfacción del cliente, mediciones y métricas, etc.
El “IEEE Standard Glossary of Software Engineering Terminology” (Stad. 610.12-1990) ha
desarrollado una definición más completa para ingeniería del software [1]: “(1) La aplicación de un
enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del
software; es decir, la aplicación de ingeniería al software. (2) El estudio de enfoques en (1)”.
Pressman caracteriza la Ingeniería de Software como “una tecnología multicapa”, ilustrada en la
Figura 1.

LUIS E. VALCARCEL
Figura 1: Capas de la Ingeniería de Software.
Dichas capas se describen a continuación:
• Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe descansar sobre un
esfuerzo de organización de calidad. La gestión total de la calidad y las filosofías similares
fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques
cada vez más robustos para la ingeniería del software.
• El fundamento de la ingeniería de software es la capa proceso. El proceso define un marco de
trabajo para un conjunto de áreas clave, las cuales forman la base del control de gestión de
proyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos, se
producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se
gestiona adecuadamente.
• Los métodos de la ingeniería de software indican cómo construir técnicamente el software.
Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño,
construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un
conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades
de modelado y otras técnicas descriptivas.
• Las herramientas de la ingeniería del software proporcionan un soporte automático o semi-
automático para el proceso y los métodos, a estas herramientas se les llama herramientas
CASE (Computer-Aided Software Engineering).
Dado lo anterior, el objetivo de la ingeniería de software es lograr productos de software de
calidad (tanto en su forma final como durante su elaboración), mediante un proceso apoyado por
métodos y herramientas.
A continuación nos enfocaremos en el proceso necesario para elaborar un producto de software.
El proceso de desarrollo del software
Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un
producto software que reúna los requisitos del cliente. Dicho proceso, en términos globales se
muestra en la Figura 2 [3]. Este proceso es intensamente intelectual, afectado por la creatividad y

LUIS E. VALCARCEL
juicio de las personas involucradas [4]. Aunque un proyecto de desarrollo de software es
equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de
software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del
producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de
software y que influyen en su proceso de construcción.
Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de
confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores
que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se
puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras
aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).
Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del
producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software
similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los
cambios en los requisitos son inevitables, no sólo después de entregado en producto sino
también durante el proceso de desarrollo.
Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del
software como disciplina, justificada por su corta vida comparada con otras disciplinas de la
ingeniería. Sin embargo, esto no es más que un inútil consuelo.
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software
Figura 2: proceso de desarrollo de software.
El proceso de desarrollo de software no es único. No existe un proceso de software universal que
sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es
difícil automatizar todo un proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades
fundamentales que se encuentran presentes en todos ellos [4]:
1. Especificación de software: Se debe definir la funcionalidad y restricciones operacionales
que debe cumplir el software.
2. Diseño e Implementación: Se diseña y construye el software de acuerdo a la

LUIS E. VALCARCEL
especificación.
3. Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el
cliente.
4. Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.
Además de estas actividades fundamentales, Pressman [1] menciona un conjunto de “actividades
protectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a
continuación:
• Seguimiento y control de proyecto de software.
• Revisiones técnicas formales.
• Garantía de calidad del software.
• Gestión de configuración del software.
• Preparación y producción de documentos.
• Gestión de reutilización.
• Mediciones.
• Gestión de riesgos.
Pressman [1] caracteriza un proceso de desarrollo de software como se muestra en la Figura 3.
Los elementos involucrados se describen a continuación:
• Un marco común del proceso, definiendo un pequeño número de actividades del marco de
trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o
complejidad.
• Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos
de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad,
que permiten que las actividades del marco de trabajo se adapten a las características del
proyecto de software y los requisitos del equipo del proyecto.
• Las actividades de protección, tales como garantía de calidad del software, gestión de
configuración del software y medición, abarcan el modelo del proceso. Las actividades de
protección son independientes de cualquier actividad del marco de trabajo y aparecen durante
todo el proceso.

LUIS E. VALCARCEL
Figura 3: Elementos del proceso del software
Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es
establecer las relaciones entre elementos que permitan responder Quién debe hacer Qué,
Cuándo y Cómo debe hacerlo [5].
Figura 4: Relación entre elementos del proceso del software
En la Figura 4 se muestran los elementos de un proceso de desarrollo de software y sus
relaciones. Así las interrogantes se responden de la siguiente forma:
• Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más
Roles específicos.

LUIS E. VALCARCEL
• Qué: Un Artefacto3
es producido por un Rol en una de sus Actividades. Los Artefactos se
especifican utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de
Artefactos soportando ciertas Notaciones.
• Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el
proceso de desarrollo. El avance del proyecto está controlado mediante hitos que establecen
un determinado estado de terminación de ciertos Artefactos.
La composición y sincronía de las actividades está basada en un conjunto de Principios y
Prácticas. Las Prácticas y Principios enfatizan ciertas actividades y/o la forma como deben
realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en
componentes, modelar visualmente, verificar continuamente la calidad, gestionar los cambios, etc.
PROGRAMACION EXTREMA
La programación extrema es una metodología de desarrollo ágil que tiene como principal
objetivo aumentar la productividad a la hora de desarrollar un proyecto software. Da
prioridad a los trabajos que dan un resultado directo y en los cuales se reduce la
burocracia que pueda existir en el entorno de trabajo.
¿QUÉ ES UNA METODOLOGÍA ÁGIL?
Las metodologías ágiles tienen como punto fuerte la adaptación a cualquier cambio en un
proyecto para aumentar sus posibilidades de éxito.
Una metodología ágil tiene varios principios:
• Los individios y sus interacciones son más importantes quue los procesos y las
herramientas.
• El software que funciona es más importante que la documentación exhaustiva.
• Colaboración con el cliente en lugar de negociación de contratos.
• No hay que seguir un plan cerrado, sino adaptarse al cambio.
Estos 4 puntos los veremos más adelante.
PRINCIPIOS BÁSICOS
Tenemos 12 principios básicos que se agrupan en 4 categorías distintas:
3 Un artefacto es una pieza de información que (1) es producida, modificada o usada por el proceso, (2) define un área de
responsabilidad para un rol y (3) está sujeta a control de versiones. Un artefacto puede ser un modelo, un elemento de modelo o
un documento.

LUIS E. VALCARCEL
• Retroalimentación.
• Proceso continuo en lugar de por bloques.
• Propiedad intelectual compartida.
• Entendimiento compartido.
RETROALIMENTACIÓN
• Principio de pruebas: lo primero que se debe hacer es establecer un período de pruebas
de aceptación del programa, en el cual se definirán las entradas y salidas del sistema.
Básicamente se define lo que debe hacer el software desarrollado. Como si fuese una caja negra.
• Planificación: el cliente (o su representante) escribirá sus necesidades para definir
concretamente las actividades que el sistema debe realizar. En esta fase se creará un documento
que contendrá historias de usuario que forman el plan de liberación, el cual define los tiempos
de entrega de la aplicación para poder recibir feedback por parte del cliente.
• Cliente in-situ: el cliente (o su representante) deberá formar parte del equipo de
desarrollo. Se le dará poder para determinar los requisitos de la aplicación, definir la
funcionalidad y dar prioridad a determinadas cosas. Gracias a esto, habrá una fuerte interacción
con los programadores, disminuyendo así el tiempo de comunicación y la cantidad de
documentación a redactar. El cliente estará con el equipo durante todo el proceso de
desarrollo del proyecto.
• Pair-programming: este punto junto con el anterior son los más radicales de esta
metodología. Consiste en escribir código en parejas compartiendo una sola máquina. Según
los experimentos ya realizados sobre este método, se producen mejores y más consistentes
aplicaciones a igual o menor coste.
METODOLOGIAS AGILES vs PESADAS
El análisis servirá para hacer una comparación entre metodologías agiles como ser Xp, Scrum, etc. Entre
metodologías pesadas como ser PUDS.
El objetivo final siempre será tener metodologías diferentes para aplicar de acuerdo con el proyecto que se
desarrolle resulta una idea interesante. Estas metodologías pueden involucrar prácticas tanto de
metodologías ágiles como de metodologías tradicionales. De esta manera podríamos tener una metodología
para cada proyecto, la problemática sería definir cada una de las prácticas, y en el momento preciso definir
parámetros para saber cual usar.
Es importante tener en cuenta que el uso de un método ágil no es para todos. Sin embargo, una de las
principales ventajas de los métodos ágiles es su peso inicialmente ligero y por eso las personas que no
estén acostumbradas a seguir procesos encuentran estas metodologías bastante agradables.
Tabla de comparación
Metodologías Agiles Metodologías Tradicionales
Están orientadas hacia las necesidades del
cliente.
Están orientados hacia el proceso del software.
Basadas en heurísticas o estadísticas
provenientes de prácticas de producción de
código.
Basadas en normas provenientes de
estándares seguidos por el entorno de
desarrollo.
Especialmente preparadas para cambios
durante el proyecto.
Cierta resistencia a los cambios.

LUIS E. VALCARCEL
Proceso menos controlado, con pocas políticas
para el desarrollo.
Procesos mucha más controlados, con
numerosas políticas o normas.
El cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de desarrollo
mediante reuniones.
Grupos pequeños (<10 integrantes) y
trabajando en el mismo sitio.
Grupos grandes y posiblemente distribuidos.
Pocos artefactos Más artefactos
Pocos roles Más roles.
Menos énfasis en la arquitectura del software. La arquitectura del software es esencial y se
expresa mediante modelos.
Conclusión: Hoy en día existe diversidad de metodologías que podemos hacer uso para el desarrollo de
software. Pero la interrogante es que metodología debemos usar o cual es la más adecuada. Concluyo
diciendo, que mientras más metodologías conozcamos será mucho mejor adecuar una exacta para cada
empresa, sacando ventajas y buenas prácticas de cada una y adecuándola a la forma de trabajo de cada
empresa.
METODOLOGIAS LIGERAS
Qué es SCRUM
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas
prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un
proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la
manera de trabajar de equipos altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio
que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos
en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y
la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que
necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es
aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los
equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias
sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo
de producto.
Ver en detalle cuales son los beneficios de Scrum, sus fundamentos y sus requisitos.
El proceso
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones que
normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite
máximo de feedback y reflexión). Cada iteración tiene que proporcionar un resultado completo, un
incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al
cliente cuando lo solicite.

LUIS E. VALCARCEL
El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan
del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan
respecto a su costey quedan repartidos en iteraciones y entregas.
Las actividades que se llevan a cabo en Scrum son las siguientes:
Planificación de la iteración
El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes:
1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de
requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y
selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de
manera que puedan ser entregados si el cliente lo solicita.
2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la
iteraciónnecesarias para desarrollar los requisitos a que se ha comprometido. La estimación de
esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas.
Ejecución de la iteración
Cada día el equipo realiza una reunión de sincronización (15 minutos máximo). Cada miembro del
equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso
hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer
las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión
cada miembro del equipo responde a tres preguntas:
• ¿Qué he hecho desde la última reunión de sincronización?
• ¿Qué voy a hacer a partir de este momento?
• ¿Qué impedimentos tengo o voy a tener?
Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con
su compromiso y de que no se merme su productividad.
• Elimina los obstáculos que el equipo no puede resolver por sí mismo.

LUIS E. VALCARCEL
• Protege al equipo de interrupciones externas que puedan afectar su compromiso o su
productividad.
Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos (para prepararlos
para las siguientes iteraciones) y, si es necesario, cambian o replanifican los objetivos del
proyecto para maximizar la utilidad de lo que se desarrolla y el retorno de inversión.
Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:
1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados
en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo
esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el
contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde
la primera iteración, replanificando el proyecto.
2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y
cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera
continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos
identificados.
• XP
• SCRUM
• CRYSTAL
• RUP
Modelos de proceso software
Sommerville [4] define modelo de proceso de software como “Una representación simplificada de
un proceso de software, representada desde una perspectiva específica. Por su naturaleza los
modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de
un proceso real.”
Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo,
son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del
desarrollo de software.
Modelos que se van a discutir a continuación:
• Codificar y corregir
• Modelo en cascada
• Desarrollo evolutivo
• Desarrollo formal de sistemas

LUIS E. VALCARCEL
• Desarrollo basado en reutilización
• Desarrollo incremental
• Desarrollo en espiral
Codificar y corregir (Code-and-Fix)
Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:
• Escribir código.
• Corregir problemas en el código.
Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño,
validación, y mantenimiento.
Este modelo tiene tres problemas principales [7]:
• Después de un número de correcciones, el código puede tener una muy mala estructura,
hace que los arreglos sean muy costosos.
• Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario,
por lo que es rechazado o su reconstrucción es muy cara.
• El código es difícil de reparar por su pobre preparación para probar y modificar.
Modelo en cascada
El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de
ingeniería [8]. Éste toma las actividades fundamentales del proceso de especificación, desarrollo,
validación y evolución y las representa como fases separadas del proceso.
El modelo en cascada consta de las siguientes fases:
1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con
los usuarios del sistema. Se busca hacer esta definición en detalle.
2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se
establece la arquitectura total del sistema. Se identifican y describen las abstracciones y
relaciones de los componentes del sistema.
3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de software.
Se realizan pruebas de cada unidad.
4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en

LUIS E. VALCARCEL
conjunto. Se entrega el conjunto probado al cliente.
5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en
marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de
implementación. Se identifican nuevos requisitos.
La interacción entre fases puede observarse en la Figura 5. Cada fase tiene como resultado
documentos que deben ser aprobados por el usuario.
Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección
de los problemas encontrados en fases previas.
Figura 5: Modelo de desarrollo en cascada.
En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las
distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son:
• Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación
de documentos.
• Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las
siguientes fases.
• Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean
ignorados o corregidos de una forma poco elegante.
• Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por
el largo tiempo de entrega del producto.
• Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder
a cambios en los requisitos.
Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte
de proyectos grandes.

LUIS E. VALCARCEL
Desarrollo evolutivo
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a
los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema
adecuado. En la Figura 6 se observa cómo las actividades concurrentes: especificación,
desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto
final.
Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las
actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.
Figura 6: Modelo de desarrollo evolutivo.
Existen dos tipos de desarrollo evolutivo:
• Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos
hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más
claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el
usuario.
• Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar
para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se
comienza por definir los requisitos que no están claros para el usuario y se utiliza un
prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos
requisitos.
Entre los puntos favorables de este modelo están:
• La especificación puede desarrollarse de forma creciente.
• Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en
una mejora de la calidad del software.
• Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas

LUIS E. VALCARCEL
del cliente.
Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:
• Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el
sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen
cada versión del sistema.
• Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para
la estructura del software haciendo costoso el mantenimiento.
• Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas
que pueden ser incompatibles con otras o que poca gente sabe utilizar.
Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos
(hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación
para cada versión.
Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede
hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más
estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar
utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.
Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa
ejecutable.
Especificación
Tranformación
Interactiva
Transformación
Automática
Optimización
Validación de
Especificación
Mantenimiento
Especificación
de alto nivel
(prototipo)
Desarrollo
FormalDesiciones
Especificación
de bajo nivel
Código
Fuente
Especificación
Informal
Figura 7: Paradigma de programación automática.
La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programación automática. Se
distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las

LUIS E. VALCARCEL
características principales de este paradigma son: la especificación es formal y ejecutable
constituye el primer prototipo del sistema), la especificación es validada mediante prototipación.
Posteriormente, a través de transformaciones formales la especificación se convierte en la
implementación del sistema, en el último paso de transformación se obtiene una implementación
en un lenguaje de programación determinado. , el mantenimiento se realiza sobre la
especificación (no sobre el código fuente), la documentación es generada automáticamente y el
mantenimiento es realizado por repetición del proceso (no mediante parches sobre la
implementación).
Observaciones sobre el desarrollo formal de sistemas:
• Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las
pruebas que verifican la correspondencia con la especificación no son necesarias.
• Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad
importantes.
• Requiere desarrolladores especializados y experimentados en este proceso para llevarse a
cabo.
Desarrollo basado en reutilización
Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo
consta de 4 fases ilustradas en la Figura 9. A continuación se describe cada fase:
1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para el
sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.
2. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los
componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos,
hay que seguir buscando componentes más adecuados (fase 1).
3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el
sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o
determinar este marco.
4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los
componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad
separada.
Las ventajas de este modelo son:
• Disminuye el costo y esfuerzo de desarrollo.
• Reduce el tiempo de entrega.

LUIS E. VALCARCEL
• Disminuye los riesgos durante el desarrollo.
Figura 8: Desarrollo basado en reutilización de componentes
Desventajas de este modelo:
• Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no
cumpla las expectativas del cliente.
• Las actualizaciones de los componentes adquiridos no están en manos de los
desarrolladores del sistema.
Procesos iterativos
A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de
las iteraciones:
• Desarrollo Incremental.
• Desarrollo en Espiral.
Desarrollo incremental
Mills [9] sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los
requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una combinación del
Modelo de Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las
decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo,
dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un
buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

LUIS E. VALCARCEL
Figura 9: Modelo de desarrollo iterativo incremental.

LUIS E. VALCARCEL
Entre las ventajas del modelo incremental se encuentran:
• Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar
a usarlo desde el primer incremento.
• Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas
del sistema.
• Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada
incremento.
• Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más
pruebas en estos módulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
• Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).
• Cada incremento debe aumentar la funcionalidad.
• Es difícil establecer las correspondencias de los requisitos contra los incrementos.
• Es difícil detectar las unidades o servicios genéricos para todo el sistema.
Desarrollo en espiral
El modelo de desarrollo en espiral (ver Figura 11) es actualmente uno de los más conocidos y fue
propuesto por Boehm [7]. El ciclo de desarrollo se representa como una espiral, en lugar de una
serie de actividades sucesivas con retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
1. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y
del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los
riesgos y se elaboran estrategias alternativas dependiendo de estos.
2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo
identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos.
Se llevan a cabo los pasos para reducir los riesgos.
3. Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del
riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del
riesgo identificado para esa fase.
4. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del

LUIS E. VALCARCEL
proyecto.
Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una
actividad importante en la administración del proyecto.
El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se
determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las
alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación,
prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.
Figura 10: Modelo de desarrollo en Espiral
¿Cuál es el modelo de proceso más adecuado?
Cada proyecto de software requiere de una forma de particular de abordar el problema. Las
propuestas comerciales y académicas actuales promueven procesos iterativos, donde en cada
iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios
(Por ejemplo: grado de definición de requisitos, tamaño del proyecto, riesgos identificados, entre
otros).

LUIS E. VALCARCEL
En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos criterios básicos para la
selección de un modelo de proceso [10], la medida utilizada indica el nivel de efectividad del
modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un nivel
de efectividad Bajo cuando los Requisitos y arquitectura no están predefinidos ):
Modelo de
proceso
Funciona
con
requisitos y
arquitectura
no
predefinidos
Produce
software
altamente
fiable
Gestión de
riesgos
Permite
correcciones
sobre la
marcha
Visión del
progreso
por el
Cliente y el
Jefe del
proyecto
Codificar y
corregir
Bajo Bajo Bajo Alto Medio
Cascada Bajo Alto Bajo Bajo Bajo
Evolutivo
exploratorio
Medio o Alto Medio o Alto Medio Medio o Alto
Medio o
Alto
Evolutivo
prototipado
Alto Medio Medio Alto Alto
Desarrollo
formal de
sistemas
Bajo Alto Bajo a Medio Bajo Bajo

LUIS E. VALCARCEL
Desarrollo
orientado a
reutilización
Medio Bajo a Alto Bajo a Medio Alto Alto
Incremental Bajo Alto Medio Bajo Bajo
Espiral Alto Alto Alto Medio Medio
Tabla 1: Comparación entre modelos de proceso de software.
PARADIGMAS DE PROGRAMACION
Metodologías para desarrollo de software
Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías
se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo,
incremental, etc.). Adicionalmente una metodología debería definir con precisión los artefactos,
roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de
adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc.
Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías
asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por
ejemplo, suele hablarse de métodos de análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad
de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una
de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar
artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en
dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte,
considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la
planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el
apelativo de Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas,
o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a

LUIS E. VALCARCEL
la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo
pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e
involucran activamente al cliente en el proceso. A continuación se revisan brevemente cada una
de estas categorías de metodologías.
Metodologías estructuradas
Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación
Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el
diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de
Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan
para la implementación lenguajes de 3ra y 4ta generación.
Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE4
(Francia),
MÉTRICA5
(España), SSADM6
(Reino Unido). Ejemplos de propuestas de métodos estructurados
en el ámbito académico: Gane & Sarson7
, Ward & Mellor8
, Yourdon & DeMarco9
e Information
Engineering10.
Metodologías orientadas a objetos
Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más
representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de
C++ por Bjarne Stroustrup en 1981 y actualmente Java11
o C# de Microsoft. A fines de los 80’s
comenzaron a consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir
una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más
modesto, para dar lugar al Unified Modeling Language (UML)12, la notación OO más popular en la
actualidad.
Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE
(Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh).
Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified
4 http://perso.club-internet.fr/brouardf/SGBDRmerise.htm (7.5.2002)
5 http://www.map.es/csi/metrica3/ (7.5.2003)
6 http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html (7.5.2003)
7 http://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.doc (29.8.2003)
8 http://www.yourdon.com/books/coolbooks/notes/wardmellor.html (29.8.2003)
9 http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarco (29.8.2003)
10 http://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.html (29.8.2003)
11 http://java.sun.com/ (7.5.2003)
12 http://www.uml.org/ (7.5.2003)

LUIS E. VALCARCEL
Process (RUP)13
, OPEN14
, MÉTRICA (que también soporta la notación estructurada).
Metodologías tradicionales (no ágiles)
Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante
todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se
realiza una intensa etapa de análisis y diseño antes de la construcción del sistema.
Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías
tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en
cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a
aplicarse), realizando una configuración adecuada, podría considerarse Ágil.
Metodologías ágiles
Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de
software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de
aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último
momento) [11].
Entre las metodologías ágiles identificadas en [11]:
• Extreme Programming [6].
• Scrum ([12], [13]).
• Familia de Metodologías Crystal [14].
• Feature Driven Development [15].
• Proceso Unificado Rational, una configuración ágil ([16]).
• Dynamic Systems Development Method [17].
• Adaptive Software Development [18].
• Open Source Software Development [19].
13 http://www.rational.com/products/rup/index.jsp (7.5.2003)
14 http://www.open.org.au/ (17.9.2003)

LUIS E. VALCARCEL
Referencias
[1] Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.
[2] Naur P., Randell B., Software Engineering: A Report on a Conference Sponsored by the NATO Scienc,
1969.
[3] Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, Addison
Wesley 2000.
[4] Sommerville, I., Ingeniería de Software, Pearson Educación, 2002.
[5] Letelier, P., Proyecto Docente e Investigador, DSIC, 2003.
[6] Beck, K., Una explicación de la Programación Extrema. Aceptar el cambio, Pearson Educación, 2000.
[7] Boehm, B. W., A Spiral Model of Software Develpment and Enhancement, IEEE Computer ,1988.
[8] Royce, W., Managing the developmento of large software systems: concepts and technique, IEEE
Westcon, 1970.
[9] Mills, H., O´Neill, D., The Management of Software Engineering, IBM Systems, 1980.
[10] Laboratorio Ing. Soft., Ingeniería de software 2, Departamento de Informática, 2002.
[11] Abrahamsson, P., Salo, O., Ronkainen, J., Agile Software Development Methods. Review and Analysis,
VTT, 2002.
[12] Schwaber, K., Scrum Development Process. Workshop on Business Object Design and Implementation,
OOPSLA´95, 1995.
[13] Schwaber, K., Beedle, M., Agile Software Development With Scrum, Prentice Hall, 2002.
[14] Cockburn, A., Agile Software Development, Addison Wesley, 2002.
[15] Palmer, S. R., Felsing, J. M., A Practical Guide to Feature Driven Development, Prentice Hall, 2002.
[16] Kruchten, P., A Rational Development Process, Crosstalk, 1996.
[17] Stapleton, J., Dynamic Systems Development Method - The Method in Practice, Addison Wesley, 1997.
[18] Highsmith, J., Adaptive Software Development: A Collaborative Approach, Dorset House, 2000.
[19] O´Reilly, T., Lessons from Open Source Software Development, ACM, 1999.
[20] Balzer R. A 15 Year Perspective on Automatic Programming. IEEE Transactions on Software
Engineering, vol.11, núm.11, páginas 1257-1268, Noviembre 1985.
CUESTIONARIO
¿Qué es un Método?
Un Método se compone de diversos aspectos que nos permitirán conseguir una meta o
lograr un objetivo. Se define más claramente como un conjunto de herramientas, las cuales
utilizadas mediante las técnicas correctas, permiten la ejecución de procesos que nos llevarán a
cumplir los objetivos que buscamos. En pocas palabras y aunque esto lo puedes encontrar como
tal en internet, es un conjunto de herramientas, técnicas y procesos que facilitan la obtención de
un objetivo.
¿Qué es una Metodología?
En el desarrollo de software, una metodología hace cierto énfasis al entorno en el cuál se
plantea y estructura el desarrollo de un sistema. Como lo mencioné al principio, existen una
gran cantidad de metodologías de la programación que se han utilizado desde los tiempos
atrás y que con el paso del tiempo han ido evolucionando. Esto se debe principalmente a que no
todos los sistemas de la información, son compatibles con todas las metodologías, pues el ciclo

LUIS E. VALCARCEL
de vida del software puede ser variable. Por esta razón, es importante que dependiendo del tipo
de software que se vaya a desarrollar, se identifique la metodología para el diseño de
software idónea.
¿En qué consisten las Metodologías de Desarrollo de Software?
Una Metodología de desarrollo de software, consiste principalmente en hacer uso de
diversas herramientas, técnicas, métodos y modelos para el desarrollo. Regularmente este
tipo de metodología, tienen la necesidad de venir documentadas, para que los programadores
que estarán dentro de la planeación del proyecto, comprendan perfectamente la metodología y en
algunos casos el ciclo de vida del software que se pretende seguir.
Aunque actualmente existen mucha variedad en metodologías de programación. La realidad es
que todas están basadas en ciertos enfoques generalistas que se crearon hace muchos años,
algunos tipos de metodologías de desarrollo de software que se utilizaron e inventaron al
principio de nuestra era tecnológica y son las que veremos a continuación.
¿Cuáles son modelos del Ciclo de vida del Software tradicionales?
Como les mencioné hace un momento, regularmente, cada metodología de desarrollo de
software, tiene un enfoque bien marcado, estos enfoques no son para nada nuevos y se
siguen utilizando para la planeación y desarrollo de software aún en nuestros tiempos, así que
vamos a ver cuáles son cada uno de ellos y aprenderemos como funcionan.
Metodología en cascada: Framework lineal.
El modelo de desarrollo de Software en cascada, es una metodología de la
programación muy antigua. Si bien su creador nunca lo menciona como metodología en
cascada, el funcionamiento y lineamiento de los procesos de la planeación, son exactamente
iguales. Básicamente, el estilo del modelo en cascada, es que no podrás avanzar a la siguiente
fase, si la anterior no se encuentra totalmente terminada, pues no tiene porque haber vuelta atrás.
Vamos a ver cuales son las fases de desarrollo de software del modelo en cascada, para que
te puedas dar una idea.
1. Análisis de Requisitos. El primer nivel del modelo cascada, es el análisis de requisitos.
Básicamente lo que se documenta aquí, son los objetivos de lo que el software debe hacer al
terminar el desarrollo, sin entrar en detalles de la parte interna, los cuales se verán durante el
proceso. Sin embargo es importante señalar que una ves avanzado el paso de análisis, no puede

LUIS E. VALCARCEL
haber vuelta atrás, pues la metodología para el diseño de software con la cual se trabaja no lo
permitirá.
2. Diseño del Sistema. Todo lo que conlleva el armado de un diseño para el sistema que vayas a
utilizar, es lo que continua después del análisis de requisitos. Aquí se elaborará lo que es la
estructura del sistema y se determinarán las especificaciones para cada una de las partes del
sistema que se planea desarrollar. Siendo del mismo modo, una fase a la cuál ya no se podrá
volver después de haber bajado al nivel 3.
3. Diseño del Programa. En este punto, aún no ingresamos a lo que es la escritura de código,
sin embargo ya se realizan los algoritmos que se van a utilizar en la programación. Si bien
recuerdas, un algoritmo no necesariamente es código, simplemente tomas una hoja de papel y
escribes el algoritmo que vas a utilizar. Esto es precisamente lo que se realiza en el paso número
3.
4. Codificación. Seguramente como programador, esta es la parte que estabas esperando, pues
ahora es momento de empezar a escribir todo el código que será necesario para el desarrollo del
software. Para este punto, la velocidad y el tiempo que se requiera, dependerá mucho del
lenguaje de programación que vayas a utilizar. Pues algunos lenguajes de programación permiten
utilizar componente, bibliotecas e incluso algunas funciones para reutilizar código, las cuales
podrán acelerar el proceso de codificación en gran manera.
5. Ejecución de Pruebas. La codificación ha terminado y ahora es momento de verificar que
nuestro sistema es realmente funciona, antes de que el cliente empiece a utilizarlo. Este es
precisamente el objetivo de la fase 5 de pruebas. Aquí es recomendable que intentes mover lo
más que se pueda tu software, con el objetivo de dañarlo intencionalmente, de este modo, si
supera las pruebas de daño realizadas por tí, entonces estará listo para el usuario final.
6. Verificación. Después de haber realizado una gran cantidad de pruebas en la Fase 5,
debemos migrar a la verificación. Esta fase consiste en la ejecución del Software por parte del
usuario final. Si la fase cinco se realizó correcta y profundamente, el software no tendrá ningún
tipo de problema y el usuario final quedará satisfecho con el resultado.
7. Mantenimiento. Seguramente te has dado cuenta, de que las aplicaciones o el software
actual, constantemente se está actualizando. Esto se debe principalmente a que se le da
mantenimiento al software, se solucionan errores, se quitan algunos bugs, se añaden
funcionalidades, todo después de que el usuario final ya lo ha probado y utilizado en su fase final.
Esta es posiblemente una de las fases más tediosas del modelo de desarrollo de software,

LUIS E. VALCARCEL
pues debes estar atento a los comentarios de los usuarios, para ver que cosas son las que no
funcionan correctamente y a las cuales hay que darles mantenimiento
¿Cuáles son los Principios básicos del modelo de cascada?
Como puedes ver, el proceso de desarrollo de software con el modelo de cascada es bastante
complejo. Sin embargo uno de sus principios es que cada una de las fases elaboradas, se
encuentre documentada perfectamente, de este modo, si el desarrollo queda suspendido en
alguna fase, cualquier usuario que quiera continuar con el proyecto lo podrá hacer leyendo la
documentación.
Así también, es muy común encontrar metodologías para el desarrollo de softwareen cascada
con fechas de objetivos, tiempos o presupuestos para determinadas fases. Aprovechando el
hecho de que una ves que avanzaste de fase, es muy poco recomendable el volver atrás, aunque
regularmente se tiene un cierto nivel de tolerancia, pero lo correcto en la utilización del modelo de
cascada, es que no puedas ir atrás a realizar modificaciones de ningún tipo.
Método de Prototipos
Esta metodología de la programación todavía sigue siendo la favorita de muchos. Consiste
básicamente en que en base a los requerimientos y necesidades que tiene el cliente, se realiza de
forma rápida un prototipo, este no vendrá completo ni mucho menos terminado, pero si permitirá
contar con las bases necesarias para que cualquier programador pueda seguir trabajando en el
hasta llegar al código final.
Por si no lo sabes aún, un prototipo es una versión no terminada del producto que se le entregará
al cliente o usuario final. Esto nos genera cierta ventaja en el desarrollo de productos similares
con funciones distintas, por ejemplo. Supongamos que vas a desarrollar un proyecto para 3
clientes distintos, ambos con una estructura idéntica pero con funcionalidades muy distintas,
entonces lo que hacemos es crear un prototipo base y entorno a el mostrarlo a nuestros clientes
para que de ahí se empiecen a desarrollar las demás funciones.
Mejor vamos a ver cuales son las etapas de desarrollo de software por las cuales tendrás que
pasar, en caso de utilizar la metodología de prototipos.
1. Planeación. A diferencia de otras metodologías, la planeación debe ser muy rápida, en esta
fase no puedes demorarte mucho, pues recuerda que solamente será un prototipo por el
momento.

LUIS E. VALCARCEL
2. Modelado. Nuevamente, una fase que deberá ser suficientemente rápida como para que nos
nos quite nada de tiempo. Hacer el modelado será simple y te sigo recordando que solamente es
un prototipo, almenos por ahora.
3. Elaboración del Prototipo. Ya que contamos con la planeación de lo que vamos a realizar y el
modelado rápido, entonces es momento de elaborar el prototipo. Para esta instancia, ya no te diré
que lo debes hacer rápido, puesto que te tomará el tiempo que tenga sea necesario elaborarlo,
recuerda que este ya se muestra al cliente, así que ya es una fase importante.
4. Desarrollo. Posterior a contar con el prototipo elaborado y mostrado al cliente, es momento de
comenzar el desarrollo. Este te tomará una gran cantidad de tiempo, dependiendo del tamaño del
proyecto y el lenguaje de programación que se vaya a utilizar.
5. Entrega y Retroalimentación. Una de las cosas con las que cuenta el modelo de prototipos,
es que una ves entregado el proyecto, debemos darle al cliente cierta retroalimentación sobre
como utilizarlo y ciertamente es una fase que se encuentra dentro de las etapas de desarrollo
de software esta metodología.
6. Comunicación con el Cliente. Es importante que una ves entregado el proyecto, tengamos
cierta comunicación con el cliente, básicamente para que nos indique si el proyecto es correcto o
si desea agregarle ciertas funciones, nuestra metodología lo permite. Si fuera en modo cascada,
entonces seria algo realmente imposible de hacer.
7. Entrega del Producto Final. Por último, solamente quedará entregar el sistema elaborado
mediante esta metodología. Aquí tendrás la ventaja de que el código es reutilizable, para que así
con el prototipo ya puedas simplemente empezar de nuevo y con una buena base de código que
te acelerará el proceso.
¿Cuáles son los Principios Básicos del método de prototipos?
Por supuesto, te habrás dado cuenta de que el modelo de prototipos puede llegar a ser un poco
más tedioso, aunque todo dependerá del ámbito en que lo utilices. Sin embargo uno de sus
principios básicos que seguramente habrás notado, es que con el método de prototipos el
proyecto se va dividiendo en partes cada ves mas pequeñas, para evitar el peligro ante los
riesgos frente a los que estamos expuestos.
Además, otros de sus principios básicos fundamentales, es que con la metodología de prototipos,
el cliente final se involucra mucho más en el proyecto que con otras metodologías, haciendo de
esta forma que el producto final llegue rápidamente aunque con un poco más de presión en el

LUIS E. VALCARCEL
proceso. La ventaja es que conforme se van haciendo prototipos pequeños, poco a poco se va
llegando al producto final. Incluso en algún determinado momento podrás llegar a crear un
prototipo que con solo ajustar ciertos detalles, se podría convertir en el producto que el usuario
quiere.
Modelo Incremental o Iterativo y Creciente
El modelo Incremental, es una metodología de la programación muy utilizada hoy en día, pues
su comodidad de desarrollo permite que te obtenga un producto final mucho más completo y
exitoso. Se trata especialmente de la combinación de los modelos lineal e iterativo o bien, modelo
de cascada y prototipos. Básicamente consiste en completar varias iteraciones de lo que es el
modelo de cascada, pero sin completar ninguna, haciendo iteraciones lo que se hace es crear una
evolución en el producto, permitiendo que se agreguen nuevas especificaciones, funcionalidades,
opciones, funciones y lo que el usuario requiera después de cada iteración.
En pocas palabras, el Modelo Incremental repite el modelo de cascada una y otra ves, pero con
pequeñas modificaciones o actualizaciones que se le puedan ir agregando al sistema. De este
modo el usuario final se ve sumamente sumergido en el desarrollo y puedes proporcionarle un
resultado óptimo.
Fases del Modelo Incremental
El modelo iterativo o incremental, cuenta con algunas fases de desarrollo de software que
realmente no tienen mucha complejidad, vamos a verlas:
1. Inicialización. como en todo modelo de desarrollo, debe haber una inicialización, aquí se
puede hablar de dar una idea, de tener algunos requisitos que se buscan en el proyecto y ciertas
especificaciones que se pueden manejar. No es necesario que se haga una lista total de
requerimientos pues recordemos que el proyecto se basa en iteraciones, así que el proyecto
puede ir evolucionando poco a poco.
2. Periodos de Iteración. Durante el desarrollo del proyecto, es cuando damos inicio a las
iteraciones. La primera iteración se realiza con las características iniciales, básicamente al final de
la primer iteración, queda un pequeño prototipo de lo que será el proyecto, pero se puede volver a
inicializar la iteración y realizar modificaciones en los procesos, como el análisis y las
especificaciones o funciones que el usuario final requiere para su sistema.El número de
iteraciones que se realicen son ilimitadas y dependerá tanto del desarrollador como del usuario
final. Si nuestro objetivo es que el cliente o la persona que necesita el trabajo quede

LUIS E. VALCARCEL
completamente satisfecha, entonces nos veremos en la necesidad de hacer la cantidad de
iteraciones que se requieran al final del día.
3. Lista de Control. Es importante que conforme se vaya realizando cada iteración, se vaya
llevando un control del mismo en una lista. Como si fuera un programa que recibe actualizaciones
constantemente. Cada una de las actualizaciones o iteraciones deberá ser documentada y de ser
posible, guardada en sus respectivas versiones, para que sea sencillo volver atrás, en caso de
que una iteración no sea exitosa o el usuario ya no la requiera.
¿Cuáles son los principios básicos del Modelo Incremental?
Es importante definir los siguientes principios fundamentales, pues nos permiten saber con
claridad por donde va la idea de la metodología.
La idea de un modelo incremental, es utilizar una serie de mini modelos de desarrollo de
software en cascada, segmentando requerimientos y permitiendo que el usuario vaya de la
mano con el proyecto durante la realización.
Básicamente las fases de cada iteración, son las mismas que se manejan en el modelo de
cascada, aunque también se pueden agregar algunas, pero su objetivo es completar cada fase
de la iteración, para que esta se vaya complementando poco a poco y no se genere un desarrollo
tedioso y cansado que puede alargar la duración del proyecto en demasía.
Debes saber, que cada iteración te generará un prototipo cada ves mas evolucionado, estos
deberás guardarlos por si en determinado momento deseas volver atrás, pues a diferencia del
modelo de cascada, podemos retroceder cuando se requiera y los prototipos se pueden volver a
utilizar una y otra ves, pues el código fuente es reutilizable.
Modelo en Espiral
El modelo en espiral, fue utilizado y diseñado por primera ves por Barry Boehm en 1986. Se
trata nuevamente de una combinación entre el modelo lineal o de cascada y el modelo iterativo o
basado en prototipos, sin embargo a este sistema lo que debemos añadirle es la gestión de
riesgos, algo que en los modelos anteriores ni siquiera se menciona.
Este modelo, consiste en ciertas fases que se van realizando en modo de espiral, utilizando
procesos de la misma forma en que se utilizan en el modelo de cascada, sin embargo aquí
estos no son obligatorios y no llevan precisamente el orden establecido. Básicamente se trata de
un modelo evolutivo, que conforme avancen los ciclos, irá incrementando el nivel de código fuente

LUIS E. VALCARCEL
desarrollado, un incremento en la gestión de riesgos y por supuesto un incremento en los tiempos
de ejecución y planificación del sistema, esto es lo que tiene el modelo en espiral.
Para que tengas una idea más clara, el modelo en espiral es principalmente utilizado para el
desarrollo de grandes proyectos como la creación de un sistema operativo. Sin embargo
necesitas de ciertos requisitos, como el hecho de contar con personal completamente capacitado
para las funciones que se requieran. Mejor veamos cuales son las las fases o tareas dentro del
modelo de espiral.
1. Determinar Objetivo. Es importante que siempre consideres una planeación inicial, esta solo
se realizará una ves. Sin embargo el proceso de determinar objetivos se hará constantemente
durante cada iteración que se vaya realizando con el modelo espiral. Esto se debe a que poco a
poco se irá incrementando más el tamaño del manual de usuario, los requisitos, las
especificaciones e incluso las restricciones. Todo esto entra en lo que es la tarea de objetivos y
con cada vuelta en el espiral entraremos a esta tarea, la cual como todas las demás, es
fundamental.
2. Análisis de Riesgo. Una etapa donde incluso una lluvia de ideas podría ayudar, el análisis de
riesgos. Aquí deberás tener en cuenta todo aquello que pueda dañar a tu proyecto, ya sea que se
trate de ciertas amenazas o de posibles daños que se puedan ocasionar, teniendo además un
Plan B por así decirlo, para que en caso de que ocurra algo inesperado, tener a la mano la
solución para continuar con el proyecto.En esta fase del modelo espiral, podemos agregar lo que
son la creación de prototipos, pues siempre es bueno tener un respaldo de nuestro código, se
esta forma en caso de que algo malo suceda, volvemos a la versión anterior. Así que cada vez
que vayamos a ingresar a la fase de pruebas e implementación, será necesario contar con un
prototipo que nos respalde.
3. Desarrollar, Validar y Probar. Básicamente en esta fase, la forma en que se estará
desarrollando el proyecto, dependerá del análisis de riesgos, pues siempre se va a ir
desarrollando el proyecto enfocándose en los riesgos que podemos evitar en nuestro software, es
decir, si la situación de riesgo más obvia se encuentra en la interfaz del usuario, entonces hay que
trabajar con prototipos para este enfoque, creando evoluciones proporcionales, para ir evitando
ese tipo de riesgos.Esto no significa que ignoremos el resto del proyecto o del desarrollo, sin
embargo el modelo en espiral si acomoda un poco más las prioridades al momento,
independientemente de todo lo demás. Por lo que siempre en cada vuelta o iteración que se le de
al modelo de espiral, tu avance siempre dependerá del análisis de riesgo, hasta que este sea
mínimo y el desarrollo pueda continuar de forma normal.

LUIS E. VALCARCEL
4. Planificación. Antes de proceder a realizar otra iteración o vuelta al espiral, debemos prestar
atención a lo que sucedió en la vuelta anterior. Debemos analizar detalladamente si los riesgos
encontrados ya tuvieron solución, lo cual debe ser lo ideal, puesto que ahora habría que analizar
más especificaciones y más requisitos del sistema para continuar con el desarrollo.Básicamente
la fase de planificación, nos servirá para determinar el avance de nuestro proyecto y indicar hacia
donde vamos a dirigirnos en la próxima iteración.
¿Cuáles son los Principios básicos del modelo en Espiral?
Está claro que el modelo en espiral, es sumamente distinto a los demás. Encontramos por fuera
cuatro fases bien organizadas, las cuáles siempre deben llevar ese orden que se estipula desde
el principio. Una determinación de objetivos, un análisis de riesgos, el desarrollo y las pruebas,
junto con la planificación, la cual dependerá de los resultados de la iteración para saber como se
actuará en la siguiente vuelta al espiral.
Básicamente, en el modelo de espiral, toda la atención está enfocada hacia el análisis de
riesgos, pues el objetivo primario será reducir los riesgos que se vayan generando, de otra
forma el sistema no llegará a ser seguro jamás.
Algo muy importante que debes ver en el modelo de espiral, es que los interesados deben estar
involucrados prácticamente en cada vuelta que se de al espiral, para crear lo que son los
requisitos antes de realizar una vuelta más y al final en la fase de planificación, se determinan los
logros obtenidos, el avance y lo que se esperará de una siguiente vuelta.
RAD: Desarrollo Rápido de Aplicaciones (Rapid Application Development)
A diferencia de otras metodologías para el desarrollo de software, la metodología RAD o
desarrollo rápido de aplicaciones, no cuenta con una serie de fases ordenadas por así decirlo.
Aunque si está basada en lo que es el modelo de cascada y la creación de prototipos, sin
embargo el proceso es muy independiente a contar con ciertas fases estipuladas como los
modelos que hemos visto anteriormente. Así que vamos a ver los principios del modelo RAD.
¿Cuáles son los principios básicos del Modelo RAD?
Del mismo modos que modelos anteriores, el Modelo RAD, está basado en el uso de las
iteraciones y principalmente en el manejo de prototipos. Sin embargo a diferencia del resto,
la metodología RAD hace uso de las Herramientas CASE, las cuales permitirán acelerar el
proceso considerablemente.

LUIS E. VALCARCEL
Del mismo modo que el modelos espiral y el de prototipos, RAD se subdivide en pequeñas
secciones, las cuales se irán optimizando y de esta forma se irá avanzando mucho más
rápido que con grandes segmentos que pueden volverse difíciles dentro de un proceso acelerado
como lo este este modelo.
Una de las ventajas del RAD, es que el enfoque y las prioridades van hacia la fase de
desarrollo, a diferencia de modelos como el espiral, que se enfoca en que los riesgos al
momento sean mucho menores. Acá con el RAD, se hace lo contrario, si hay riesgos reducimos
los requerimientos para reducir los riesgos, no como en el espiral, que entre más riesgos, más
requisitos aportamos para que se incremente. Acá la idea es reducir tiempos y no riesgos, o si,
talves también, pero la reducción de riesgos es totalmente inversa al modelo espiral.
Por supuesto, como en todos los modelos, vas a requerir de ciertos factores documentados, de
preferencia todo lo que se pueda, para que en caso de que alguien más venga a continuar con
este proyecto, tenga a la mano toda la información que necesita y con unas cuentas lecturas
pueda empezar a desarrollar lo que se había quedado pendiente en un determinado momento.
¿Cuál es tu metodología tradicional preferida?
Si bien hemos visto métodos muy diversos, información muy variada y ciclos de desarrollo de
software con distintos enfoques. La realidad es que al final tu siempre decidirás como trabajar y
con que tipo de metodología te sentirías más a gusto. Obviamente depende de muchos factores,
principalmente del tamaño del proyecto, pues modelos como el espiral, son especialmente para
proyectos grandes y modelos como el RAD, son enfocados en proyectos pequeños, sin tanto
requisito pero manejando siempre cierto nivel de calidad, el cual siempre debes considerar.
A continuación, analizaremos lo que son las metodologías ágiles de desarrollo de software
más importantes, las cuáles a diferencia de las metodologías tradicionales, funcionan mas como
una combinación de estas para lograr un objetivo. Su finalidad siempre será el crear software de
una forma más rapida de lo que se venia logrando con las metodologías de antaño. Así que
vamos a ver un poco de información referente a lo que son las metodologías ágiles, como
funcionan y que se necesita para implementarlas.

LUIS E. VALCARCEL
Metodologías Ágiles
Con el paso del tiempo, estaba claro que las metodologías tradicionales, simplemente no se iban
a acoplar con las nuevas tecnologías, los nuevos lenguajes y sobretodo los programadores
modernos. Es por eso que desde principios del Siglo, se han desarrollado lo que son las
metodologías ágiles. Una metodología ágil, consiste principalmente en trabajar con menos
documentación de la que, como vimos, las metodologías tradicionales utilizan en todo momento.
Existen una gran cantidad de metodologías ágiles de desarrollo de software y todas las vamos
a ver a continuación. Sin embargo antes hay que comprender en que consiste detenidamente la
metodología ágil, para lo cual contamos con el manifiesto ágil. Un documento en el cuál se
resume la filosofía de este enfoque de desarrollo, así seguramente después de leer esos puntos,

LUIS E. VALCARCEL
nos quedará aún mas clara la idea de hacia donde se pretende llegar y principalmente Cómo se
pretende llegar a los objetivos.
Manifiesto Ágil
• Al Individuo y las Interaciones del Equipo. Una de las cosas que sabemos muy bien, es que
las personas son quienes consiguen los éxitos dentro de un proyecto de software. Sin embargo
también está claro que si el equipo de trabajo falla, entonces todo se viene abajo y el enfoque que
habia de éxito se convierte en incertidumbre. A diferencia de si el equipo funciona perfectamente,
se tienen mas cerca los objetivos, aún cuando no exista una lista de procesos establecida como
se hacia con las metodologías de antaño.
Con este primer valor del desarrollo ágil, se pretender hacer ver, que en realidad no importa que
el equipo de trabajo no sean las personas más brillantes del sector. Con que sean personas que
saben hacer bien el trabajo que se les asignará es más que suficiente. En este caso, las
herramientas aunque son importantes para incrementar el rendimiento, también es cierto que si
hay herramientas de más y que no sirven de nada en un principio, lo mejor es dejarlas de lado o
estas nos quitarán valioso tiempo que no tendremos.
Básicamente el enfoque, es que no se intente crear un entorno de trabajo desde un principio,
tratando de que los desarrolladores se adapten a ese entorno que nosotros deseamos, pues este
tipo de proyectos suelen tardar mucho tiempo en desarrollarse, algunos incluso jamás terminan y
se quedan estancados. El enfoque del desarrollo ágil nos dice, que es mejor formar primero un
buen equipo de trabajo y posteriormente entre ellos vayan creando su propio entorno. Este
proceso ayudará mucho más a la metodología ágil y por supuesto, la adaptación será un proceso
fugaz.
• Software funcional en lugar de demasiada documentación. Crear documentación, es una de
las actividades que con las metodologías tradicionales, absorbían una gran cantidad de tiempo. Si
nos acercamos a analizaras las metodologías de antaño, descubriremos que en cada una de
ellas, realizar la documentación era una parte vital. Sin embargo en las metodologías ágiles,
esto ha cambiado, pues existe una regla que dice de la siguientes forma: “No producir
documentación, almenos que sean sumamente necesarios al momento para tomar una decisión”.
Por lo que además se extienda hacia el enfoque de que la documentación debe ser corta y breve,
nada sumamente extenso que requiera de una gran cantidad de tiempo de lectura.
Te preguntarás y entonces, cuando un nuevo programador o desarrollador sea colocado en un
puesto dentro del proyecto, como sabrá hacia donde ir y el enfoque que se está llevando a cabo.
Para lo cual el manifiesto ágil nos dice que, existen dos elementos fundamentales para que un

LUIS E. VALCARCEL
nuevo miembro del equipo se ponga al día. El primero es el código fuente, pues suponiendo que
es una persona conocedora, sabrá hacia donde va el curso del proyecto con tan solo leer el
código. La segunda es que la interacción con el equipo de trabajo, será el complemento ideal
para que se acople al proyecto. De este modo nos olvidamos de la extensa documentación para
un software que al final del día debe estar totalmente funcional.
• Colaboración con el Cliente en lugar de hacer Contrato. Una de las cosas importantes
dentro de las metodologías ágiles. Es que cambia el modo en que se trabajaba con el cliente
anteriormente. Y es que en las metodologías de antaño, el trabajo consistía en tener una reunión
previa con el cliente para analizar los requerimientos del sistema, aquí se analizaban las
limitaciones del proyecto y se establecían los costos. Lo que generaba cierta barrera de bloqueo
entre las posibilidades de desarrollar algo funcional para otras cosas o solo para el objetivo
establecido en la reunión. Esto al final podía ser desastroso y dificultar la llegada al éxito por parte
del proyecto.
Sin embargo, ahora en el manifiesto ágil, se propone que exista una interacción constante entre el
cliente y el equipo de desarrolladores. La idea es que el cliente vaya viendo como va el sistema y
analice nuevas funcionalidades o objetivos, ya que estos no tienen porque plantearse desde el
principio, si el desarrollo nos puede llevar a una infinidad de posibilidades. De esta forma el cliente
al final queda totalmente satisfecho con el producto final y habremos llegado al éxito trabajando
todos en equipo de forma simultanea.
• Posibilidad de Hacer cambios de planes a medio proyecto. Suena mas o menos a lo que
vimos en el punto anterior, pues básicamente la idea es evitar lo que es la planeación extensa
y empezar a crear código que permita expansión. Recordemos que con las metodologías
tradicionales, se acostumbraba a enlistar los requisitos del sistema y el desarrollo iba enfocado
solamente a eso, lo cual ya no permitía que a medio desarrollo hubiera cambios, pues era un
código poco moldeable y si se requerían nuevas cosas, en algunas metodologías lo idea era
volver a empezar.
La idea en las metodologías ágiles, es que durante el desarrollo del software, si el cliente tiene la
idea de incrementar sus objetivos, especificaciones o requerimientos, lo pueda hacer sin ningún
problema. Pues básicamente el sistema debe ser flexible para todo lo que pueda surgir en el
proceso. De este forma, no solamente llegaremos al éxito, si no que el cliente quedará totalmente
satisfecho con el trabajo desarrollado, pues no tuvo que conformarse con lo primero que se le
vino a la mente, si no que se actualizó con las ideas que en la marcha fueron surgiendo.

LUIS E. VALCARCEL
¿Cuáles son las Principales Metodologías Ágiles?
Algo que debes saber antes de dar paso a la descripción de cada una de las metodologías de la
programación ágiles, es que aunque entre sus creadores crearon lo que fue el manifiesto ágil, la
realidad es que cada una de las metodologías cuenta con su propia personalidad y características
únicas, que la diferencian de las demás. Por eso a continuación, veremos cada una de las
metodologías ágiles más populares, para que tengas un conocimiento más solido de lo que son y
hacia donde van cada una de ellas.

LUIS E. VALCARCEL
Metodología Scrum
Para que tengas una idea rápida, para que un proyecto ingrese al marco de lo que es el modelo
Scrum, debe contar con las siguientes características:
• Desarrollo Incremental. Una metodología ágil sin desarrollo incremental, no puede ser
considerada Scrum. Con incremental hago énfasis a olvidarnos de la planeación y de la ejecución

LUIS E. VALCARCEL
de las lineas sin salirnos de lo pre establecido, pues con una metodología Scrum, el desarrollo se
irá incrementando poco a poco, sin importar el orden en el cual se lleven a cabo los procesos.
• Calidad de las personas. Básicamente la calidad de un producto, no será analizada en base a
la calidad de cada uno de los procesos llevados a cabo. Al contrario, la calidad dependerá de las
personas, la auto organización y el conocimiento de los equipos de trabajo.
• Adiós al Secuencial y Cascada. Aquí en el modelo Scrum, hay algo a lo que se le denomina,
solapamiento. Esto consiste en que no importa en que proceso te encuentres, si un proceso
necesita ser trabajado, vuelves a el para realizar lo que tienes que hacer, a diferencia de las
metodologías cascada o secuencial, donde no había vuelta atrás. Acá afortunadamente no hay
ningún problema con eso y la ventaja es que se ahorran tiempos.
• La comunicación es Fundamental. Una de las cosas que se realizan, son los equipos de
trabajo, sin embargo acá la ventaja que tendrás es que podrás estar en constante comunicación
con los otros equipos de trabajo, nadie está envuelto en su propia burbuja y toda la información
que se maneje o lleve a cabo, será comunicada sin problema.
¿Como funcionan los Procesos Scrum?
La metodología Scrum, es bastante amigable y fomenta lo que es el trabajo en equipo en
todo momento, con la finalidad de conseguir los objetivos de una forma rápida. Veamos
ahora cuales son los procesos con los cuales funciona la metodología, empezando por el Product
Backlog, el cual nos permitirá llegar a los Sprints, a continuación te explicaré de que te estoy
hablando.
• Product Backlog. El Product Backlog no es más que una lista de las funcionalidades del
producto a desarrollar. Este debe ser elaborado por el Product Owner, puesto que más adelante
les explicaré. Sin embargo no se trata de una lista cualquiera hecha con escritos y nadamás. El
Product Backlog debe estar ordenado de acuerdo a las prioridades del sistema de mas a menos,
con la idea de que las cosas con mayor prioridad sean las que se realicen antes de cualquier
cosa. De forma concreta, digamos que el objetivo base del Product Owner, es que nos de
respuesta a la pregunta “¿Qué hay que hacer?”.
• Sprint Backlog. Una ves que ya contamos con el Product Backlog terminado, entonces
aparecerá el primer Sprint Backlog. Pero ¿Qué es el Sprint Backlog? Consiste básicamente en
seleccionar algunos de los puntos escritos en el Product Backlog, los cuales procederán a ser
realizados. Sin embargo en este punto el Sprint Backlog tiene como requisito marcar el tiempo en
que se llevará a cabo el Sprint.

LUIS E. VALCARCEL
• Sprint Planning Meeting. Antes de iniciar un Sprint, el cual es la fase de desarrollo, se realiza
lo que es un Sprint Planning Meeting. En este proceso del Scrum, es una reunión que se realiza
para definir plazos y procesos a efectuarse para el proyecto establecido en el Product Backlog.
Algo importante que debes saber, es que cada Sprint, se compone de diversos features, que no
son otra cosa mas que procesos o subprocesos que se deben realizar, puede ser la creación de
un logo, la gestión de contenido, el diseño visual, etc. Todo dependerá del proceso que se desee
llevar a cabo.
• Daily Scrum o Stand-up Meeting. Cuando un Sprint está en proceso, después de haber hecho
la planeación del proyecto mediante plazos y procesos, entonces entramos a lo que son los Daily
Scrum o Stand-up Meeting. Aquí básicamente lo que se hace son reuniones diarias mientras se
está llevando a cabo un Sprint, para responder las siguientes preguntas: ¿Que hice ayer?, ¿Qué
voy a hacer hoy, ¿Qué ayuda necesito?. Aquí entra en función el Scrum Master, un puesto que
igual mas adelante les explicaré. Pero el será el encargado de determinar la solución de los
problemas y cada complicación que suceda.
• Sprint Review. El Sprint Review, es básicamente una reseña de lo que fue el Sprint. Consiste
específicamente en la revisión del Sprint terminado y para este punto ya tendría que haber algo
que mostrarle al cliente, algo realmente visual o tangible para que se pueda analizar un cierto
avance.
• Sprint Retrospective. Para concluir, el Sprint Retrospective, permite al equipo analizar los
objetivos cumplidos, si se cometieron errores, visualizarlos y tratar de no cometerlos nuevamente
mas adelante. Básicamente también sirve este proceso para lo que son la implementación de
mejoras.
Equipos que Componen los Procesos Scrum
Durante el punto anterior, te describí los procesos que se llevan a cabo en la Scrum
Metodología, y en varios puntos mencioné ciertos equipos que son encargados de algunos
aspectos importantes. Por eso a continuación veremos cuales son los equipos que conforman la
metodología Scrum y con los cuales se trabajará arduamente, obvio, cada quien con sus
respectivas responsabilidades.
• Product Owner. Si se trata de tener un líder de proyecto, entonces el Product Owner lo será.
Básicamente son los ojos del cliente, será la persona encargada del proyecto y de visorear que se
lleve a cabo de tal forma que cumpla las expectativas de lo que se espera.

LUIS E. VALCARCEL
• Scrum Master. Ahora bien, para cada reunión realizada, siempre debe estar un líder, en este
caso el Scrum Master será el lider de cada una de las reuniones y ayudará en los problemas que
hayan surgido. Será básicamente como un “facilitador” el cual minimizará obstáculos, sin embargo
no los omitirá. En realidad el Scrum Master debe ser una persona empapada de conocimientos
sobre el lenguaje o lenguajes bajo los cuales se llevará a cabo el proyecto, de lo contrario no
tendría como ayudar a solucionar problemas.
• Scrum Team. Básicamente es el núcleo de la metodología Scrum, pues es el equipo de
desarrollo, encargado de lo que es la codificación del software y de cumplir los objetivos o metas
propuestas por el Product Owner.
• Cliente. Aunque no lo creas, el cliente también forma parte del equipo, hablamos de eso hace
un rato, cuando comenté que no es como en las metodologías tradicionales donde al cliente se le
pedían requerimientos y se le daba un costo total. En la metodología Scrum, el cliente tiene la
capacidad para influir en el proceso, debido a que siempre estará empapado de el, ya sea que
proponga nuevas ideas o bien haciendo algún tipo de comentario.

LUIS E. VALCARCEL
Metodología Kanban
Siguiendo con las metodologías ágiles, nos encontramos con Kanban. Se trata de una
metodología Japonesa, la cual consiste en ir etiquetando con tarjetas cada uno de los
procesos que se deben llevar a cabo, también se le ha denominado como “Un sistema de
producción de alta efectividad y productividad”. De hecho, empresas como la marca de autos
Toyota, fueron una de las primeras en implementarla para acelerar los procesos de producción.
La palabra Kanban, en Japonés significa “tarjetas visuales” y es precisamente lo que se
maneja en ella. Algunos la trabajan con lo que son tarjetas virtuales o bien simulando que se

Separata de metodologia desarrollo software

Separata de metodologia desarrollo software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (11)

Similar a Separata de metodologia desarrollo software

Similar a Separata de metodologia desarrollo software (20)

Último

Último (20)

Separata de metodologia desarrollo software