Instituto Tecnolgico de Quertaro

Unidad Pinal de Amoles

Divisin de Educacin Presencial a Distancia

Materia: Ingeniera de Software

Ingeniera en Sistemas Computacionales.

Actividad: Tarea 1. Metodologas de Desarrollo de Software

Alumno:
Jos Luis Prez Ortega

Asesor: L.I. Juan Jose Garca Alcacio

jjgarcia_depad_qro@hotmail.com

Tutor: L.I. Eucebio Martnez Olvera

emartinez_depad_pin@hotmail.com

Domingo 25-Octubre-2015

Ingeniera de Software 2
Unidad Pinal de Amoles

Metodologa de Desarrollo de Software

Modelos y metodologas para el desarrollo de software
Ingeniera de software
Segn Sommerville (2005), para muchas personas el software son solo programas de
computadora, sin embargo nos comenta que son todos aquellos documentos asociados a la
configuracin de datos que se necesitan para hacer que estos programas operen de manera
adecuada. Estos productos de software se desarrollan para algn cliente en particular o para un
mercado en general. Para el diseo y desarrollo de proyectos de software se aplican metodologas,
modelos y tcnicas que permiten resolver los problemas. En los aos 50 no existan metodologas
de desarrollo, el desarrollo estaba a cargo de los propios programadores. De ah la importancia de
contar con analistas y diseadores que permitieran un anlisis adecuado de las necesidades que se
deberan de implementar.
Aun as los resultados eran impredecibles, no se saba la fecha exacta en que concluira un
proyecto de software, no haba forma de controlar las actividades que se estaban desarrollando.
Tampoco se contaba con documentacin estandarizada. El nacimiento de tcnicas estructuradas
es lo que da origen al desarrollo de aplicaciones a travs de mtodos de ingeniera. La informtica
aporta herramientas y procedimientos que se apoyan en la ingeniera de software con el fin de
mejorar la calidad de los productos de software, aumentar la productividad y trabajo de los
ingenieros desarrolladores de software, facilitar el control del proceso de desarrollo de software y
suministrar a los desarrolladores las bases para construir software de alta calidad en una forma
eficiente, Gacita(2003).
El objetivo principal que busca la ingeniera de software es convertir el desarrollo de software en
un proceso formal, con resultados predecibles, que permitan obtener un producto final de alta
calidad y satisfaga las necesidades y expectativas del cliente. Segn Gacita (2003), la Ingeniera de
Software es un proceso intensivo de conocimiento, que abarca la captura de requerimientos,
diseo, desarrollo, prueba, implantacin y mantenimiento. Generalmente a partir de un complejo
esquema de comunicacin en el que interactan usuarios y desarrolladores, el usuario brinda una
concepcin de la funcionalidad esperada y el desarrollador especifica esta funcionalidad a partir
de esta primera concepcin mediante aproximaciones sucesivas. Este ambiente de interaccin
motiva la bsqueda de estrategias robustas para garantizar que los requisitos del usuario sern
descubiertos con precisin y que adems sern expresados en una forma correcta y sin
ambigedad, que sea verificable, trazable y modificable.
El trmino ingeniera del software empez a usarse a finales de la dcada de los sesenta, para
expresar el rea de conocimiento que se estaba desarrollando en torno a las problemticas que
ofreca el software. En esa poca, el crecimiento espectacular de la demanda de sistemas de
computacin cada vez ms y ms complejos, asociado a la inmadurez del propio sector
informtico (totalmente ligado al electrnico) y a la falta de mtodos y recursos, provoc lo que se
llam la crisis del software. Durante esa poca muchos proyectos importantes superaban con

Jos Luis Prez Ortega

Pgina 2

Ingeniera de Software 3
Unidad Pinal de Amoles
creces los presupuestos y fechas estimados. La crisis del software finaliz pues se comenz a
progresar en los procesos de diseo y metodologas.
Segn Silva (2001) desde 1985 hasta el presente, han ido apareciendo herramientas, metodologas
y tecnologas que se presentaban como la solucin definitiva al problema de la planificacin,
previsin de costos y aseguramiento de la calidad en el desarrollo de software. La dificultad propia
de los nuevos sistemas, y su impacto en las organizaciones, ponen de manifiesto las ventajas, y en
muchos casos la necesidad, de aplicar una metodologa formal para llevar a cabo los proyectos de
este tipo. La ingeniera de software es una tecnologa multicapa en la que, segn Pressman (2005),
se pueden identificar: los mtodos, el proceso (que es el fundamento de la Ingeniera de Software,
es la unin que mantiene juntas las capas de la tecnologa) y las herramientas (soporte automtico
o semiautomtico para el proceso y los mtodos). Como disciplina, establece el proceso de
definicin de requerimientos en una sucesin de actividades mediante las cuales lo que debe
hacerse, se modela y analiza (Choque, 2001).
Una parte importante de la ingeniera de software es el desarrollo de metodologas y modelos. En
la actualidad ha habido muchos esfuerzos que se han encaminado al estudio de los mtodos y
tcnicas para lograr una aplicacin ms eficiente de las metodologas y lograr sistemas ms
eficientes y de mayor calidad con la documentacin necesaria en perfecto orden y en el tiempo
requerido. Gacita (2003), plantea que una metodologa impone un proceso de forma disciplinada
sobre el desarrollo de software con el objetivo de hacerlo ms predecible y eficiente. Una
metodologa define una representacin que permite facilitar la manipulacin de modelos, y la
comunicacin e intercambio de informacin entre todas las partes involucradas en la construccin
de un sistema.
Goncalves (2005) plantea que la experiencia ha demostrado que los proyectos exitosos son
aquellos que son administrados siguiendo una serie de procesos que permiten organizar y luego
controlar el proyecto, considerando vlido destacar que aquellos procesos que no sigan estos
lineamientos corren un alto riesgo de fracasar. Es necesario destacar la importancia de los
mtodos, pero el xito del proyecto depende ms de la comunicacin efectiva con los interesados,
el manejo de las expectativas y las personas que participan en el proyecto.
Existen diferentes modelos y metodologas que han sido en los ltimos aos herramientas de
apoyo para el desarrollo del software. Someerville (2005), menciona que:

Modelo de desarrollo de software: es una representacin simplificada del proceso para el

desarrollo de software, presentada desde una perspectiva especfica.

Metodologa de desarrollo de software: es un enfoque estructurado para el desarrollo de

software que incluye modelos de sistemas, notaciones, reglas, sugerencias de diseo y guas de
procesos.

Jos Luis Prez Ortega

Pgina 3

Ingeniera de Software 4
Unidad Pinal de Amoles

2.11.2 Modelos para el desarrollo de software

Como se explic en el concepto anterior, un modelo para el desarrollo de software es una
representacin abstracta de un proceso. Cada modelo representa un proceso desde una
perspectiva particular y as proporcione informacin parcial sobre el proceso. stos modelos
generales no son descripciones definitivas de los procesos del software ms bien son
abstracciones de los procesos que se pueden utilizar para el desarrollo del software. Puede
pensarse en ellos como marcos de trabajo del proceso y que pueden ser adaptados para crear
procesos ms especficos. Los modelos que mencionaremos en este punto son:
1) El modelo en cascada. Considera las actividades fundamentales del proceso especificacin,
desarrollo, validacin y evolucin. Los representa como fases separadas del proceso, tales como la
especificacin de requerimientos, el diseo del software, la implementacin, las pruebas, etctera.
2) El modelo de desarrollo evolutivo (espiral). Este enfoque entrelaza las actividades
especificacin, desarrollo y validacin. Es decir surge de un sistema inicial que se desarrolla
rpidamente a partir de especificaciones abstractas. Basndose en las peticiones del cliente para
producir un sistema que satisfaga sus necesidades.
3) El modelo de desarrollo basado en componentes. ste enfoque se basa en la existencia de un
nmero significativo de componentes reutilizables. El proceso de desarrollo se enfoca en integrar
estos componentes en el sistema ms que en desarrollarlos desde cero. Estos tres modelos se
utilizan ampliamente en la prctica actual de la ingeniera del software, no se excluyen
mutuamente y a menudo se utilizan juntos especialmente para el desarrollo de grandes sistemas.
A.

El modelo en cascada

Segn Royce (1970), el modelo de cascada se deriv de procesos de sistemas ms generales. ste
modelo se muestra en la figura 2.22 y sus principales etapas se transforman en actividades
fundamentales del desarrollo:
1) Anlisis y definicin de requerimientos. Los servicios restricciones y metas del sistema se
definen a partir de las consultas con los usuarios. Entonces, se definen en detalle y sirven de
manera especfica al sistema.
2) Diseo del sistema y del software. El proceso de diseo del sistema divide los requerimientos en
sistemas ya sea hardware Soto. Establece una arquitectura completa del sistema, el diseo del
software identifique describe los elementos abstractos que son fundamentales para el software y
sus relaciones.
3) Implementaciones prueba de unidades. Durante esta etapa el diseo del software se lleva a
cabo como un conjunto de unidades de programas, la prueba de unidades implica verificar que
cada una cumpla con su funcin especfica.

Jos Luis Prez Ortega

Pgina 4

Ingeniera de Software 5
Unidad Pinal de Amoles
4) Integracin y prueba del sistema. Los programas o las unidades individuales de programas se
integran y se prueban como un sistema completo para as asegurar que se cumplan los
requerimientos del software, despus se entrega al cliente.
5) Funcionamiento y mantenimiento. En esta fase el sistema se instala y se pone en
funcionamiento prctico el mantenimiento implica corregir errores no descubiertos en las etapas
anteriores del ciclo de vida, mejorar la implementacin de las unidades del sistema y resaltar los
servicios del sistema una vez que se descubren en nuevos requerimientos.
B.

El modelo de desarrollo evolutivo (espiral)

El modelo en espiral que Boehm propuso es un modelo de proceso de software evolutivo que
conjuga la naturaleza iterativa de la construccin de prototipos con los aspectos controlados y
sistemticos del modelo en cascada. Cuando se aplica este modelo en espiral, el software se
desarrolla en una serie de entregas evolutivas. Cada una de las actividades del marco de trabajo
representan un segmento de la ruta en espiral.
Este modelo se basa en la idea de desarrollar una implementacin inicial, exponindola a los
comentarios del usuario y refinndola a travs de las diferentes versiones que se generan hasta
que se desarrolle un sistema adecuado.
Las actividades de especificacin, desarrollo y validacin se entrelazan en vez de separarse, con
una rpida retroalimentacin entre estas. Existen dos tipos de desarrollo evolutivo:
1) Desarrollo exploratorio, en este caso el objetivo del proceso es trabajar con el cliente para
explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del
sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos
por el cliente.
2) Prototipos desechables, el objetivo de este proceso de desarrollo evolutivo es comprender los
requerimientos del cliente para as desarrollar una definicin mejorada de los requerimientos para
el sistema. El prototipo se centra en experimentar los requerimientos del cliente que no se
comprenden del todo.
Haciendo referencia a la produccin del software, un enfoque evolutivo suele ser ms efectivo que
el enfoque en cascada, ya que satisface las necesidades inmediatas de los clientes. La ventaja de
un software que se basa en un enfoque evolutivo es que las especificaciones se pueden desarrollar
de forma creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su
problema, esto se puede reflejar en el software. Sin embargo, desde la perspectiva de ingeniera y
de gestin, el enfoque evolutivo tiene dos problemas:
1) El proceso no es visible. Esto significa que los administradores tienen que hacer entregas
regulares para medir el progreso del producto. Si los sistemas se desarrollan rpidamente, no es
rentable producir documentos que reflejen cada versin del sistema.

Jos Luis Prez Ortega

Pgina 5

Ingeniera de Software 6
Unidad Pinal de Amoles
2) A menudo los sistemas tienen una estructura deficiente. Esto hace referencia que los cambios
continuos tienden a corromper la estructura del software. Incorporar cambios en l se convierte
cada vez ms en una tarea difcil y costosa.
Para sistemas pequeos y de tamao medio (hasta 500,000 lneas de cdigo), el enfoque evolutivo
de desarrollo es el mejor. Los problemas del desarrollo evolutivo se hacen particularmente agudos
para sistemas grandes y complejos con un perodo de vida largo, donde diferentes equipos
desarrollan distintas partes del sistema. Es difcil establecer una arquitectura del sistema usando
este enfoque, ya que hace difcil integrar las contribuciones de los equipos. Para sistemas grandes
se recomienda un proceso mixto es decir que incorpore las mejores caractersticas del modelo en
cascada y del desarrollo evolutivo. Esto implica desarrollar un prototipo desechable, utilizando un
enfoque evolutivo para resolver incertidumbres en la especificacin del sistema. Puede entonces
no implementarse utilizando un enfoque ms estructurado.
C.

El modelo de desarrollo basado en componentes

En la mayora de los proyectos de desarrollo de software existe la reutilizacin. Por lo general esto
sucede informalmente cuando las personas conocen diseos o cdigos similares al requerido. Los
buscan, los modifican segn lo creen necesario y los incorporan en un nuevo sistema. El enfoque
evolutivo, la reutilizacin es indispensable para el desarrollo ms gil de un sistema. Esta
reutilizacin es independiente del proceso de desarrollo que se utilice. Sin embargo, en los ltimos
aos ha surgido un enfoque de desarrollo de software denominado " ingeniera de software
basada en componentes", el cual se basa en la reutilizacin. Este enfoque se basa en la
reutilizacin y se compone de una gran base de componentes de software que son reutilizables.
Aunque la etapa de especificacin de requerimientos y la revalidacin son comparables con otros
procesos, las etapas intermedias en el proceso orientado a la reutilizacin son diferentes. Estas
etapas son:
1) Anlisis de componentes. En esta se buscan los componentes para implementar los con base en
su especificacin. Por lo general, no existe una concordancia exacta y los componentes que se
utilizan slo proporcionan parte de la funcionalidad requerida.
2) Modificacin de requerimientos. En esta etapa los requerimientos se analizan utilizando
informacin acerca de los componentes que se han descubierto. Entonces dichos componentes se
modifican para reflejar los componentes disponibles, la actividad de anlisis de componentes se
puede llevar a cabo para buscar soluciones alternativas.
3) Diseo del sistema con reutilizacin. En esta fase los diseadores tienen en cuenta los
componentes que se reutiliza y que se organizan el marco de trabajo para que los satisfaga. Si
dichos componentes no estn disponibles se puede disear nuevos software.

Jos Luis Prez Ortega

Pgina 6

Ingeniera de Software 7
Unidad Pinal de Amoles
4) Desarrollo e integracin. El software que no se puede adquirir externamente se desarrolla y se
integra a los componentes. En este modelo, la integracin del sistema es parte del proceso de
desarrollo, ms que una actividad separada.
El modelo de desarrollo de software basado en componentes creado por Boehm (1988), tiene la
ventaja de reducir la cantidad de software que se debe desarrollar y por ende reduce los costos y
los riesgos. Tambin permite una entrega ms rpida del software. Sin embargo, los compromisos
a los requerimientos son inevitables y esto da lugar a un sistema que no cumpla con las
necesidades reales de los usuarios. Pressman (2006), detecto que:
El software de computadoras moderno se caracteriza por el cambio continuo, los tiempos de
entrega son muy reducidos y una necesidad intensa de satisfacer al cliente/usuario. En muchos
casos, el tiempo de llegada al mercado es el requisito de gestin ms importante. Si se pierde una
ventana del mercado, el mismo proyecto de software puede perder su significado.
2.11.3 Metodologas.
Las metodologas han evolucionado de manera significativa en las ltimas dcadas como se puede
observar en la tabla 2.7 Permitiendo as el xito o el fracaso de muchos de los sistemas
desarrollados para distintas reas.
Algunas de las metodologas tradicionales ms utilizadas para el desarrollo de software han sido,
la denominada proceso personal de software (PSP) y la proceso en equipo para el software
TSP. El TSP toma sus fundamentos en que los ingenieros deben de dar a conocer bien su trabajo y
que puedan implementar un plan para poderlo realizar mejor, cuando el plan se implementa,
pueden ahorrarse tiempo en realizar el trabajo y por ende generar productos de calidad. El TSP
contempla dos componentes principales:
1)

Creacin de equipo

2)

Trabajo en equipo o componente de gestin.

El TSP es una metodologa para dirigir el desarrollo de software adems de establecer un entorno
donde el trabajo efectivo de equipo sea normal y natural. En donde involucra a los ingenieros a
desarrollar un trabajo en equipo. El desarrollo del (TSP) toma sus bases en la estrategia de calidad
que propuso W. Edwards Deming (1982), con las etapas de planear, hacer, verificar y actuar. Y J.M.
Juran (1988). El TSP ofrece un contexto disciplinado para el trabajo de la ingeniera del software.
La motivacin principal es que los ingenieros siguiendo esta metodologa pueden hacer un
excelente trabajo. Los ingenieros deben estar bien capacitados, bien entrenados y deben ser bien
dirigidos por un miembro calificado que entienda bien la metodologa del TSP. El objetivo principal
del TSP es guiar debidamente a sus equipos de ingenieros. El TSP proporciona un proceso
operacional definido para guiar a los ingenieros y administradores a travs de diferentes pasos
para la formacin de equipos de trabajo.

Jos Luis Prez Ortega

Pgina 7

Ingeniera de Software 8
Unidad Pinal de Amoles
Antes de que los miembros del equipo de trabajo participen en el equipo de TSP, deben saber
cmo organizar bien su trabajo. Se requiere que el equipo o el personal se encuentre entrenado
primero con el Personal Software Process (PSP). Esto le permite a los ingenieros obtener el
conocimiento en saber cmo crear un plan detallado, reuniendo y usando procesos de datos,
usando valores obtenidos para seguir un proyecto en donde puedan medir y dirigir la calidad del
producto. El objetivo del PSP es poner a los profesionales de software a cargo de su trabajo y para
que se sientan personalmente responsables de la calidad de los productos que producen. PSP
puede trabajar a la par con los objetivos de la metodologa (TSP) son:
1) Proporcionar un entorno de equipo que apoya el trabajo de la PSP
2) Construir y mantener un equipo autodirigido.
PSP y TSP son potentes herramientas que proporcionan los conocimientos necesarios, la disciplina
y el compromiso necesarios para los proyectos de software exitoso. Se sabe que en nuestro pas
para que se pueda producir software con calidad se debe de adoptar un nivel de madurez de
procesos alto, es decir, que sea equiparable a los niveles internacionales, esto es a travs del
CMMI (Capability Maturity Model Integration), pero es difcil implementarlo en organizaciones
pequeas. En Mxico se cuenta con la norma mexicana basada en MoProsoft (Modelo de Procesos
para la Industria del Software), pero esta se centra en los procesos de las organizaciones pero no
en las personas, que son los ms importantes para que ellas funcionen. En Mxico no solamente
se debe incrementar el nivel de madurez en los procesos de la industria de Software, si no que, se
debe incluir el mejoramiento del elemento bsico que sustente la industria, que son las personas.
Con PSP, los desarrolladores utilizan procesos bien definidos y medibles. Se toma informacin de
tamao, tiempo y defectos al momento de realizar el trabajo. Se utilizan los datos para: planear y
monitorear el trabajo, as como administrar la calidad de los productos que se producen y medir el
desempeo. TSP ha permitido resolver problemas tpicos de negocio: como predecir el costo y
tiempo, mejorar la productividad y establecer ciclos de desarrollo para generar la mejora en la
calidad de los productos. PSP/TSP mejoran el desempeo tanto de equipos como de individuos; es
disciplinado y dirigida en todo su desarrollo a la planeacin; provee beneficios inmediatos y
medibles; acelera las iniciativas de mejora de los procesos organizacionales. Con TSP, los equipos
encuentran y reparan defectos en etapas tempranas del proceso de desarrollo. Esto reduce de
manera importante el tiempo de pruebas.

2.11.3.1 Metodologas para el desarrollo gil del software.

Actualmente los negocios operan en un entorno global que cambia rpidamente. Tienen que
responder a nuevas oportunidades y mercados, condiciones econmicas cambiantes y la aparicin
de productos y servicios competidores. El software es parte de casi todas las operaciones de
negocio, por lo que es fundamental que el software nuevo se desarrolle rpidamente para
aprovechar nuevas oportunidades y responder a la presin competitiva. Actualmente el desarrollo
y entrega de manera rpida son los requerimientos ms crticos de los sistemas. De hecho, muchas

Jos Luis Prez Ortega

Pgina 8

Ingeniera de Software 9
Unidad Pinal de Amoles
organizaciones estn dispuestas a obtener una prdida en la calidad del software y en el
compromiso sobre los requerimientos en favor de una entrega rpida del software.
Los procesos de desarrollo del software basados en una completa especificacin de los
requerimientos, diseo, construccin y pruebas del sistema no se ajustan al desarrollo rpido de
aplicaciones. Cuando los requerimientos cambian o se descubren problemas con ellos, el diseo o
implementacin del sistema se tiene que volver a realizar o probar. Como consecuencia,
normalmente se prolonga en el tiempo un proceso en cascada convencional y el software
definitivo se entrega mucho tiempo despus al cliente con el que inicialmente se pact. En un
entorno de negocios tan cambiante, esto puede causar verdaderos problemas. Para cuando est
disponible el software, la razn original de su adquisicin puede ser que haya cambiado de forma
radical que en realidad ste sea intil. Dicha metodologa combina una filosofa y un conjunto de
directrices de desarrollo. La filosofa busca la satisfaccin del cliente y la entrega temprana de
software incremental, equipos pequeos con alta motivacin, mtodos informales y una
simplicidad general del desarrollo. Los procesos de desarrollo rpido de software estn diseados
para producir software til de forma rpida. Generalmente, son procesos interactivos en los que
se entrelazan la especificacin, el diseo, el desarrollo y las pruebas.
En los aos 80 y principios de los 90, exista una opinin general de que la mejor forma de obtener
un software de calidad era a travs de una planificacin cuidadosa del proyecto y de la utilizacin
de mtodos de anlisis y diseo soportados por herramientas CASE (Computer Aided Software
Engineering). Esta opinin vena fundamentalmente de la comunidad de ingenieros de software
implicado en el desarrollo de grandes sistemas y que normalmente se componan de un gran
nmero de programas individuales. Este software era desarrollado por grandes equipos que
trabajaban para compaas diferentes y que a menudo estaban dispersos geogrficamente y
trabajaban durante largos periodos de tiempo.
Sin embargo, cuando este enfoque era aplicado a sistemas de negocios pequeos y de tamao
medio, el esfuerzo invertido era tan grande que algunas veces dominaba el proceso de desarrollo
del software, es decir, se pasaba ms tiempo pensando en cmo se deba desarrollar el sistema
que en cmo programar el desarrollo y cmo hacer las pruebas pertinentes. El descontento de
esto produjo que varios desarrolladores propusieran nuevos mtodos que eran ms giles.
Aunque estos mtodos se basan principalmente en la nocin del desarrollo y en las entregas
incrementales, proponen procesos diferentes para alcanzar el objetivo.
En una reunin celebrada en febrero de 2001 en Utah-EEUU, nace el trmino "gil" aplicado al
desarrollo de software. En esta reunin participan un grupo de diecisiete expertos de la industria
del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su
objetivo fue esbozar los valores y principios que deberan permitir a los equipos a desarrollar
software rpidamente y respondiendo a los cambios que podran surgir a lo largo de los proyectos.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las
actividades desarrolladas. Varias de las denominadas metodologas giles ya estaban siendo

Jos Luis Prez Ortega

Pgina 9

Ingeniera de Software 10
Unidad Pinal de Amoles
utilizadas con xito en proyectos reales, pero les faltaba una mayor difusin y reconocimiento.
Tras esta reunin se cre The Agile Alliance (2001), una organizacin, sin nimo de lucro,
dedicada a promover los conceptos relacionados con el desarrollo gil de software y ayudar a las
organizaciones para que adopten dichos conceptos.
El punto de partida fue el manifiesto gil, un documento que resume la filosofa "gil". A
continuacin en la tabla 2.8, vamos a enumerar las principales diferencias de una Metodologa gil
respecto a las Metodologas Tradicionales (llamadas peyorativamente no giles o pesadas).
Estas diferencias que no se refieren slo al proceso en s, sino tambin al contexto de equipo y
organizacin que es ms favorable a cada uno de estas filosofas de procesos de desarrollo de
software.
Si bien la idea de participacin del cliente en el proceso de desarrollo es atractiva, el xito
depender de tener un cliente que est dispuesto y lo ms importante pueda pasar tiempo con el
equipo de desarrollo para as presentar a todos los implicados del sistema, los clientes estn
sometidos a otras presiones y no pueden participar plenamente en el desarrollo del software. El
cliente es el punto clave, solicita los requerimientos que se deben de incluir. Los miembros
individuales del equipo puede no tener la personalidad propia para una participacin intensa. Por
lo tanto, es posible que no se relacionen adecuadamente con los otros miembros del equipo.
Priorizar los cambios puede ser extremadamente difcil, especficamente en sistemas en los que
existen muchos implicados.
Mantener la simplicidad requiere un trabajo extra. Cuando se trabaja bajo presin por las agendas
de entregas, los miembros del equipo no pueden tener a tiempo las especificaciones del sistema.
Por consiguiente los mtodos giles tienen que depender de contratos donde el cliente paga por
el tiempo necesario para el desarrollo del sistema en lugar de por el desarrollo de un conjunto de
requerimientos especficos. Siempre y cuando el proyecto vaya caminando en forma, esto
beneficiar tanto al cliente como al desarrollador. Todos los mtodos tienen lmites y los mtodos
giles son apropiados para algunos tipos de desarrollo de sistemas. Son los ms idneos para el
desarrollo de sistemas para pequeos negocios y medianas empresas. No son adecuados para el
desarrollo de sistemas a gran escala con equipos de desarrollo situados en diferentes lugares
geogrficamente hablando ya que puede haber complejas interacciones con otros sistemas o
hardware.
Los mtodos giles no se deben de utilizar para el desarrollo de sistemas crticos en los que es
necesario generar un anlisis detallado de todos los requerimientos del sistema para as
comprender mejor sus implicaciones de seguridad o de proteccin. El crecimiento de los mtodos
giles y su penetracin ocurre a un ritmo pocas veces visto en la industria: en tres o cuatro aos,
segn el Cutter Consortium, el 50% de las empresas define como giles ms de la mitad de los
mtodos empleados en sus proyectos (Charette, 2004). Algunas de las metodologas agiles mas
usadas en la actualidad se describen a continuacin.

Metodologa XP programacin extrema

Jos Luis Prez Ortega

Pgina 10

Ingeniera de Software 11
Unidad Pinal de Amoles
La programacin extrema XP es posiblemente el mtodo gil ms conocido y ampliamente
utilizado. El nombre de XP fue acuado por Beck (2000), debido a que el enfoque fue desarrollado
utilizando las mejores prcticas del desarrollo iterativo y con la participacin extrema del cliente.
La programacin extrema (XP), que algunos consideran una innovacin extraordinaria y otros
creen cnica (Rakitin, 2001). En la metodologa extrema, todos los requerimientos se expresan
como escenarios (llamados historias de usuario), los cuales se implementan directamente como
una serie de tareas. Los programadores trabajan en parejas y desarrollan pruebas para cada tarea
antes de escribir el cdigo. Todas las pruebas se deben ejecutar satisfactoriamente cuando el
cdigo nuevo se integra al sistema. Existe un pequeo espacio de tiempo entre las entregas del
sistema.
El desarrollo incremental se lleva a travs de entregas pequeas y frecuentes del sistema y por
medio de un enfoque que sirve para la descripcin de requerimientos basado en las historias del
clientes o escenarios que pueden ser la base para el proceso de planificacin.
La participacin del cliente se lleva a cabo a travs del compromiso y del tiempo completo del
cliente en el equipo de desarrollo. Los colaboradores directos de los clientes participan en el
desarrollo y son los responsables de definir las pruebas necesarias que servirn para la aceptacin
del sistema. El inters de las personas, en vez de los procesos, se lleva a travs de la programacin
en parejas, la propiedad colectiva del cdigo y un proceso de desarrollo sostenible que no
implique excesivas jornadas de trabajo. El cambio se lleva a cabo a travs de las entregas regulares
del sistema, un desarrollo previamente probado y la integracin continua. El mantenimiento se
lleva a cabo a travs de una recta actualizacin constante para mejorar la calidad del cdigo y la
utilizacin de diseos sencillos que no prevn cambios futuros en el sistema.
En XP, los clientes estn implicados en la especificacin y establecimiento de prioridades de los
requerimientos del sistema. Dichos requerimientos no se especifica como una lista de funciones
requeridas en el sistema. Ms bien, los clientes del sistema son parte fundamental del equipo de
desarrollo esto permite que discutan escenarios con todos los miembros del equipo. Desarrollar
conjuntamente tarjetas de historia (story card) que recogen las necesidades del cliente. Por ende
el equipo de desarrollo intentar implementar esos escenarios en una entrega futura del software.
Un punto fundamental en la ingeniera del soporte tradicional es que se debe de disear para
futuros. Esto es que se deben de prever los cambios futuros y disear ste de forma que tales
cambios se puedan implementar fcilmente. La metodologa XP ha descartado este principio
partiendo del hecho de que disear para el cambio es a menudo un esfuerzo intil. Con frecuencia
los cambios previstos nunca se materializa y realmente se efectan peticiones de cambios
completamente diferentes. La metodologa extrema aborda este problema sugiriendo que se debe
revisar constantemente el software. Esto es, que el equipo de programacin busca posibles
mejoras y las implementa de forma inmediata as lo que se busca es que siempre sea fcil de
entender y cambiar cuando simplemente nuevas historias.

Metodologa SCRUM

Jos Luis Prez Ortega

Pgina 11

Ingeniera de Software 12
Unidad Pinal de Amoles
A pesar de que la metodologa XP recibe la mayor atencin bibliogrfica, las organizaciones estn
enfocando su atencin en la metodologa gil denominada SCRUM (Schwaber & Shuterland, 2011)
(Shuterland, 2012), la cual aplica las mismas premisas conceptuales que XP pero para resolver un
problema ligeramente distinto como es el de desarrollo evolutivo de aplicaciones. SCRUM es una
metodologa gil y flexible que sirve para gestionar el desarrollo de software, cuyo principal
objetivo es maximizar el retorno de la inversin para su empresa. Se basa principalmente en
construir la funcionalidad de mayor valor para el cliente y en los principios de inspeccin continua,
adaptacin, auto-gestin e innovacin.
Con SCRUM el cliente es pieza fundamental en el desarrollo de software, se entusiasma y se
compromete con el proyecto dado que lo ve crecer iteracin a iteracin. Asimismo le permite en
cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que
puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteracin. Esta
forma de trabajo promueve la innovacin, motivacin y el compromiso del equipo que forma
parte del proyecto, por lo que los profesionales encuentran un mbito propicio para desarrollar
sus capacidades. SCRUM genera algunas ventajas a diferencia de otras metodologas agiles entre
ellas:

Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que

aporta a cada requisito / historia del proyecto, el equipo los estima y con esta informacin el
propietario del producto establece su prioridad.

Flexibilidad a cambios: Genera una alta capacidad de reaccin ante los cambios de
requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodologa
est diseada para adaptarse a los cambios de requerimientos que conllevan los proyectos
complejos.

Reduccin del tiempo: El cliente puede empezar a utilizar las funcionalidades ms

importantes del proyecto antes de que est finalizado por completo.

Mayor calidad del software: La forma de trabajo y la necesidad de obtener una versin
funcional despus de cada iteracin, ayuda a la obtencin de un software de calidad superior.

Mayor productividad: Se consigue entre otras razones, gracias a la eliminacin de la

burocracia y a la motivacin del equipo que proporciona el hecho de que sean autnomos para
organizarse.

Maximiza el retorno de la inversin (ROI): Produccin de software nicamente con las

prestaciones que aportan mayor valor de negocio gracias a la priorizacin por retorno de
inversin.

Predicciones de tiempos: Mediante esta metodologa se conoce la velocidad media del

equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar

Jos Luis Prez Ortega

Pgina 12

Ingeniera de Software 13
Unidad Pinal de Amoles
fcilmente para cuando se dispondr de una determinada funcionalidad que todava est
retrasada.

Reduccin de riesgos: El hecho de llevar a cabo las funcionalidades de ms valor en primer

lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos
eficazmente de manera anticipada.

La totalidad de los requerimientos a desarrollar, denominados historias de usuario (user stories)

son divididos en grupos en funcin de su prioridad relativa para luego ser implementados en ciclos
de esfuerzos relativamente cortos llamados sprints; las tareas son organizadas en el equipo de
tal manera que las asignaciones y prioridades se revisan diariamente en una reunin breve
llamada SCRUM que le da su nombre la metodologa. En este enfoque se siguen los principales
criterios del manifiesto generando as liberaciones parciales incrementales del producto que se
esta desarrollando. La evidencia es consistente que al abrazar la hoja de ruta y comprometer las
inversiones necesarias para desplegar formalmente esta metodologa tambin se abordan al
mismo tiempo aspectos clave del despliegue de prcticas maduras de proceso.
En tal sentido SCRUM ha sido exitosamente comparada contra los requisitos a satisfacer para
alcanzar una de evaluacin bajo niveles 2 y 3 del modelo CMMI (Shuterland, et al, 2008), (Turner &
Jain, 2002). Demostrando as que la ejecucin rigurosa satisface a la mayora de los objetivos
necesarios que sirven para obtener estos niveles; las pocas reas del proceso no cubiertas
directamente por no ser requeridos por SCRUM son en la prctica un requisito para el correcto
desempeo de una organizacin dedicada a la construccin de software.

Desarrollo adaptativo de software (DAS)

El desarrollo adaptativo software (DAS) lo propuso Jim Highsmith en 1998 como una tcnica para
construir software y sistemas complejos. Los apoyos filosficos del DAS se enfocan en la
colaboracin humana y la organizacin propia del equipo. Un enfoque de desarrollo gil y
adaptativo basado en la colaboracin es " una fuente de orden en las complejas interacciones
entre disciplina e ingeniera". El define el ciclo de vida del DAS, como se muestra en la figura 2.29
el cual incorpora tres fases principales:
1)
Especulacin; en esta fase se inicia el proyecto y se conduce el ciclo adaptativo de
planeacin. Este ltimo utiliza informacin de inicio del proyecto, es decir, el enunciado de la
misin del cliente, restricciones del proyecto y los requisitos bsicos. Esto permite definir el
conjunto de ciclos de lanzamiento que se requerirn para el proyecto.
2)
Colaboracin; la gente motivada trabaja de una forma que multiplica su talento y sus
salidas creativas ms all de sus nmeros absolutos. Este enfoque de colaboracin es un tema
recurrente en todos los mtodos giles, pero la cooperacin no es fcil. No solamente es la
comunicacin, o que la comunicacin es parte de ella. No slo es un asunto de trabajo en equipo,

Jos Luis Prez Ortega

Pgina 13

Ingeniera de Software 14
Unidad Pinal de Amoles
aunque un equipo cuajado es esencial para la presencia de la colaboracin real. No es un rechazo
al individualismo ya que la creatividad individual representa un papel importante en el
pensamiento de colaboracin. Esto es, por encima de todo, una cuestin de confianza. Las
personas que trabajan juntas deben confiar entre s para:
a) Criticar de forma constructiva
b) Ayudar sin resentimientos
c) Trabajar ms duro de lo que ya lo hace
d) Tener el conjunto de actitudes para contribuir al trabajo curso
e) Comunicar los problemas o preocupaciones en una forma que conduzca a la accin efectiva
3) Aprendizaje; como miembros de un equipo de DAS se comienzan a desarrollar los componentes
integrantes de un ciclo adaptativo, la importancia radica en el aprendizaje y en el progreso a
travs de un ciclo completo. De hecho Highsmith (2002), argumenta que los desarrolladores de
software a menudo sobreestima su comprensin (de la tecnologa, el proceso y el proyecto), y que
el aprendizaje les podr ayudar a mejorar su grado de entendimiento real. Los equipos del DAS
aprenden de tres maneras:
a)
Grupos enfocados. El cliente o los usuarios finales proporcionan retroalimentacin sobre
los incrementos de software que se entregan. Esto indica en forma directa la satisfaccin o la
insatisfaccin de las necesidades del negocio.
b)
Revisiones tcnicas formales. Los miembros del equipo del DAS revisan los componentes
del software desarrollado mientras mejoran su calidad y su aprendizaje.
c)
Post mortem. El equipo de DAS se vuelve introspectivo al vigilar su propio desempeo y
proceso con el propsito de aprender acerca de su enfoque y despus mejorarlo.
Es importante destacar que la filosofa del DAS es meritoria sin importar el modelo del proceso
empleado. La dinmica de la organizacin propia los equipos, la colaboracin interpersonal y el
aprendizaje individual conducen a los grupos de proyectos de software con una mayor posibilidad
de xito.

Metodologas de desarrollo del software

El concepto de metodologa, dentro de la Ingeniera del Software es, sin duda, uno de los ms
oscuros y que ms confusin produce tanto en estudiantes como en profesionales involucrados en
procesos de desarrollo de software.
Tanto es as, que en muchos proyectos de desarrollo (no todos, por supuesto), la aplicacin de una
metodologa brilla por su ausencia, siendo ste un concepto casi desconocido.

Jos Luis Prez Ortega

Pgina 14

Ingeniera de Software 15
Unidad Pinal de Amoles
Adems, la constante innovacin tecnolgica hace que cada vez sea necesara la aplicacin de
nuevas metodologas adaptadas a los nuevos tiempos y, sin embargo, siguen figurando en los
libros de texto viejas metodologas pensadas para viejos problemas... cosa que no sera
necesariamente mala si las nuevas metodologas tuviesen tambin su lugar... pero a menudo no es
as.
Y no es que haya una metodologa claramente superior a las dems. Como ya hemos dicho en ms
de una ocasin, todas las metodologas son, en esencia, bienintencionadas. Obviamente, las ms
modernas responden a problemas y necesidades ms actuales.
Afortunadamente, los tiempos van cambiando (aunque no de la misma manera para todo el
mundo). La informtica va madurando y tanto algunos profesionales de las tecnologas de la
informacin como algunos de sus clientes se van dando cuenta de que se hace necesario seguir
unas ciertas pautas predefinidas en el desarrollo del software de calidad: es decir, llevar un
comportamiento metdico: seguir una metodologa.
En todo este tema slo tengo una cosa clara: la ausencia de metodologa en el desarrollo de un
proyecto de software garantiza con seguridad tambin la ausencia de calidad.

Qu es una metodologa de desarrollo del software?

Bueno... ya decamos que la definicin no es sencilla. Si autores de supuesto renombre se han
dedicado a echarle una pensada durante un montn de aos y todava no han logrado ponerse de
acuerdo, no vamos a ser nosotros los que sentemos ctedra... pero una idea general quiz s
podamos aportar.
Ya comentamos que en el ciclo de vida del software se deban completar una serie de tareas para
obtener un producto de software. A menudo, se dice que los distintos componentes de software
deben pasar por distintas fases o etapas durante el ciclo de vida. (Vase, si procede,)
Pues bien... cada una de esas tareas puede ser abordada y resuelta de mltiples maneras... con
distintas herramientas y utilizando distintas tcnicas. Es necesario saber cundo podemos dar por
concluida una tarea... quin debe realizarla... qu tareas preceden o anteceden a una dada... qu
documentacin utilizaremos para llevar a cabo esa tarea...
Estamos hablando de detalles organizativos... de un "estilo" de hacer las cosas... Pero yendo un
poco ms all que un simple estilo, formalizando ese "estilo" aadiendo algo de rigurosidad y
normas obtenemos una metodologa.
Por ejemplo: en el desarrollo de cualquier software, es necesario pasar por la etapa de "Toma de
requisitos" (es decir, enterarnos de lo que hay que hacer). Por supuesto, tenemos muchas cosas
que hacer para lograrlo: entrevistarnos con clientes, usuarios... tomar notas, escribir informes...
Claro que s!

Jos Luis Prez Ortega

Pgina 15

Ingeniera de Software 16
Unidad Pinal de Amoles
Pero esa descripcin de la tarea es muy vaga. Cuando nos ponemos manos a la obra y hay que
enfrentarse a la toma de requisitos de un proyecto real surgen mil detalles... Cmo se hace?...
Con quin hay que entrevistarse? Qu debo preguntar? Cmo es el informe que debo escribir?
Quin lo va a leer? Qu va a hacer con l? Cunto debo tardar? Cundo s que he
terminado?...
Si soy una persona medianamente desenvuelta podr responderme a esas preguntas yo mismo...
pero entonces, estara haciendo las cosas a mi manera... Eso quiz podra valer para un proyecto
pequeo, en el que el equipo de desarrollo estuviera formado por dos o tres personas... pero en
un proyecto de un tamao razonablemente mediano o grande es absurdo... Todo el mundo hara
las cosas a su manera! Lamentablemente, eso ocurre en proyectos reales todos los das....
generando proyectos fracasados, recursos perdidos y profesionales frustrados...
Volvamos a las metodologas: todos los integrantes de un equipo de desarrollo deben seguir un
criterio comn a la hora de realizar las tareas del ciclo de vida. Ese criterio, esa manera comn es
una metodologa de desarrollo.
A lo largo de los aos se han propuesto numerosas metodologas. Algunas han sido escritas por
autores del mbito acadmico... otras por autores del mbito empresarial de desarrollo del
software... otras por administraciones pblicas...
Algunas metodologas estn escritas en infumables tochos de herica lectura. Otras, se describen
en apenas unas pocas pginas. Algunas metodologas intentan describirlo todo al detalle. Otras
son ms genricas.
Algunas hacen hincapi en los datos... otras en los usuarios... otras en las tareas... otras en la
documentacin... o cualquier aspecto o combinacin de aspectos que puedan darse en el
desarrollo del software.

Qu metodologa debo utilizar?

Tambin es una pregunta de difcil respuesta.
Solo tengo una cosa clara, que voy a exponer con rapidez.
Hay una serie de metodologas que solemos llamar tradicionales, propuestas casi todas ellas con
anterioridad a los aos 90 del siglo XX, y que pretendan ayudar a los profesionales indicando
pautas para realizar y documentar cada una de las tareas del desarrollo del software. Sin embargo,
tienen casi todas ellas un gran lastre: asumen que un proyecto informtico es casi una extensin
de un proyecto burocrtico tradicional. As pues, los pasos que sugieren para llevar a cabo cada
tarea, aunque bienintencionados, estn cargados de burocracia, reiteraciones, ambigedades...
No suelen tener en cuenta cosas como la calidad, la satisfaccin, la competitividad, los beneficios.
Fueron metodologas creadas en los aos 70-80 pensando en los negocios de los aos 50.

Jos Luis Prez Ortega

Pgina 16

Ingeniera de Software 17
Unidad Pinal de Amoles
El mundo va ahora mucho ms rpido: slo los negocios inteligentes sobreviven... slo los
proyectos de software inteligentemente construidos lo hacen tambin. Ahora las comunicaciones
son instantaneas... mundiales. La informacin fluye en tiempo real. Las empresas compiten al
segundo.
El software ya tiene una cierta historia. Hemos aprendido mucho. Utilizamos conceptos abstractos
para construir sistemas que van mucho ms all de los datos y los algoritmos.
La mayor parte de las metodologas tradicionales ya no funcionan. Estn obsoletas desde casi
todos los puntos de vista. Slo algunas metodologas tradicionales han sido revisadas y
adaptadas... y su funcionalidad suele estar limitada a proyectos poco innovadores.
Las metodologas surgidas desde los 90 hasta aqu suelen tener otra mentalidad... una cierta
agilidad. Siendo conscientes de lo cambiante y amplio que es el mundo del software, una
metodologa debe ser lo suficientemente precisa como para que todo el mundo la pueda seguir y
sea de utilidad como pauta comn, pero tambin debe ser lo suficientemente adaptable como
para poder aplicarse en distintos proyectos, y lo suficientemente sencilla como para que no
resulte muy gravosa su utilizacin, pero lo suficientemente completa y compleja como para que la
utilizacin por parte del equipo sea provechosa... En una palabra: agilidad.
Aunque el trmino de agilidad es muy discutible, es indudable que las metodologas "modernas"
responden a otra mentalidad completamente distinta.
As a la pregunta de "Qu metodologa utilizar?"... pues podemos dar una orientacin
dependiendo de tu situacin:
Si formas parte de un equipo de desarrollo en un proyecto grande y te toca decidir qu
metodologa hay que utilizar significa que tienes un puesto de responsabilidad. Escoge una
metodologa moderna, bien definida, que d respuesta a las necesidades del proyecto.
Si ocupas un puesto de decisin en un proyecto grande pero institucional, quiz de una
administracin pblica, o un proyecto estructural de una gran empresa, es decir, uno de esos
proyectos 'pesados' cuyo punto clave es el tratamiento masivo de datos, quiz la metodologa est
previamente escogida. En ese caso, hay que limitarse a seguirla. Esto suele ocurrir en proyectos de
este tipo porque involucran a muchos actores con un perfil no tcnico, y una enorme cantidad de
burocracia. Son proyectos poco competitivos, y la inercia corporativa tiende a fijar una
metodologa para ellos -siempre la misma dentro de la misma institucin- con el fin de uniformizar
el desarrollo.
Si formas parte de un equipo de desarrollo en un proyecto grande y no ocupas un puesto de
responsabilidad, no deberas decidir qu metodologa utilizar: alguien lo decidir por t. Si nadie
toma esa decisin y en el proyecto no se escoge una metodologa, o al menos, se fijan algunas
pautas metodolgicas genenerales, entonces... Mucho nimo!... el proyecto en el que ests

Jos Luis Prez Ortega

Pgina 17

Ingeniera de Software 18
Unidad Pinal de Amoles
involucrado est destinado al fracaso. Intenta vivirlo de la mejor manera posible y trata de
aprender de la experiencia.
Si formas parte de un equipo pequeo en un proyecto pequeo, lo mejor es consensuar la
metodologa a utilizar. Incluso, combinar buenas ideas de ms de una.

Y qu metodologas hay?
Entre las metodologas tradicionales podemos citar:
Desarrollo de sistemas de Jackson (JSD). De los aos 80. (artculo en wikipedia en ingls)
Ingeniera de la informacin. De los 80 tambin (artculo en wikipedia en ingls)
Structured System Analysis and Design Method (SSADM). Tambin de los 80. Muy popular en
Europa, ya que tiene su origen el Reino Unido. (artculo en wikipedia en ingls)
Nuestra querida metodologa METRICA, promovida por el Ministerio de las Administraciones
Pblicas. (Artculo en Wikipedia) (Pgina de la metodologa) Algunas, como las dos primeras
(Jackson, Ingeniera de la informacin), tienen un inters principalmente histrico. Otras, como
SSADM o MTRICA, tienen cierta vigencia, en especial en lo que concierne a proyectos pblicos.
Entre las metodologas modernas -unas ms, otras menos- se puede destacar:
Rapid Application Development (Desarrollo rpido de aplicaciones - RAD). (artculo en wikipedia en
ingls)
Scrum (artculo en wikipedia en ingls)
Extreme programming. (Programacin extrema - XP) (artculo en wikipedia en ingls)
Rational Unified Process. (Proceso Racional Unificado - RUP) (artculo en wikipedia en ingls)
Agile Unified Process. (Proceso gil Unificado - AUP) (artculo en wikipedia en ingls)
Hay muchas ms, pero quiz stas sean las ms populares en el momento de escribir estas lneas.
Personalmente me atrevera a recomendar un cierto conocimiento general de al menos las cuatro
ltimas (Scrum, XP, RUP y AUP)
Por ltimo: Cosas que NO son metodologas de desarrollo del software.
La "Programacin estructurada" o la "Programacin Orientada a Objetos" son paradigmas o
modelos de programacin. Indican pautas de comportamiento en los sistemas de programacin...
no tienen nada que ver con el ciclo de vida del software ni la manera en la que debe realizarse
cada tarea para un proyecto concreto... as pues... NO SON METODOLOGAS.
Los trminos "Ciclo de vida en espiral", "Ciclo de vida incremental", "en Cascada", "con prototipo",
etc... fueron propuestos en los aos 70 y 80 por autores hoy en da clsicos, (como Barry Boehm o

Jos Luis Prez Ortega

Pgina 18

Ingeniera de Software 19
Unidad Pinal de Amoles
Winston W. Royce) Todava aparecen en los libros, y probablemente tienen cierta vigencia dado
que se tratan de ideas muy bsicas, que "no pasan de moda". Son esquemas generales de
organizacin en las tareas del ciclo de vida, unas con respecto a otras y con respecto a otros
aspectos como el tiempo, los requisitos o el riesgo. Actualmente se prefiere la denominacin de
PATRONES del ciclo de vida del software, aunque antao fueron denominados simplemente
distintos "Ciclos de vida". Indican ideas estructurales sencillas en el proceso de desarrollo, y no la
manera en la que debe realizarse cada tarea del ciclo para un proyecto concreto... as pues... NO
SON METODOLOGAS.
El lenguaje UML (Unified Modeling Languaje) es un gran logro de la ingeniera. An con sus
carencias, y puntos criticables es un avance muy significativo: un lenguaje comn para que todos
los profesionales del desarrollo de sistemas -de software o no- expresen sus ideas... pero el UML
no le indica a nadie la manera de realizar las cada tarea en un proyecto concreto: tan solo es una
herramienta para expresar ideas... as pues... NO ES UNA METODOLOGA. Sin embargo, algunas
metodologas de las que hemos comentado, como RUP o METRICA hacen referencia a UML como
herramienta para expresar ideas.

Referencias

Cendejas, Jose Luis (S/F). Modelos y metodologas para el desarrollo de software.

Consultado el 22 de octubre de 2015. Recuperado de: http://www.eumed.net/tesisdoctorales/2014/jlcv/software.htm
Vic (29 de Julio de 2015). Metodologas de desarrollo del software. Consultado el 22 de
octubre de 2015. Recuperado de: http://latecladeescape.com/h/2015/07/metodologiasde-desarrollo-del-software

Jos Luis Prez Ortega

Pgina 19