Metodologas para el desarrollo de software

Metodologa de desarrollo de software se describe como el conjunto de herramientas, tcnicas,

procedimientos y soporte documental para el diseo de Sistemas de informacin.
En Ingeniera de software cuando se habla de desarrollo de software se habla de desarrollo de programas y
por lo tanto se considera como una tarea de ingeniera, en el cul se debe ejecutar una serie de fases, etapas
para obtener un programa que funcione de acuerdo con mtodos ya establecidos en otras disciplinas de
ingeniera.
1
Las actividades que los ingenieros de software realizan se encuentran asociadas a un proceso de
software donde intervienen diferentes elementos (fases, actividades, producto, roles, agentes) que permiten
la definicin del software a producir (producto), el desarrollo o el diseo del software, la validacin del
software tanto lo interno(requerimientos especficos)como lo externo(expectativas del cliente), y la
evolucin del software donde se modifica para adaptarlo a los cambios.
2
Por otro lado, Sommerville (2002) define que un mtodo de ingeniera de software es un enfoque
estructurado para el desarrollo de software cuyo propsito es facilitar la produccin de software de alta
calidad de una forma costeable, cabe destacar que para usar este enfoque se debe manejar conceptos
fundamentales tales como; procesos, mtodos, tareas, procedimientos, tcnicas, herramientas, productos,
entre otros.
Particularmente, una metodologa se basa en una combinacin de los modelos de proceso genricos para
obtener como beneficio un software que soluciones un problema. Adicionalmente una metodologa debera
definir con precisin los artefactos, roles y actividades, junto con prcticas, tcnicas recomendadas y guas
de adaptacin de la metodologa al proyecto. Sin embargo, la complejidad del proceso de creacin de
software es netamente dependiente de la naturaleza del proyecto mismo, por lo que el escogimiento de la
metodologa estar acorde al nivel de aporte del proyecto, ya sea pequeo, mediano o de gran nivel.
Contenido
1 Evolucin histrica de las metodologas de desarrollo de software
2 Generaciones de metodologas
2.1 Desarrollo Convencional
2.2 Desarrollo Estructurado
2.3 Desarrollo Orientado a Objetos
3 Caractersticas deseables de una metodologa
4 Metodologas Vs. Ciclo de vida
5 Modelos de procesos en el desarrollo de software
6 Clasificacin de las Metodologas segn el modelo de proceso
6.1 Modelos Convencionales o Prescriptivos de Procesos
6.1.1 Modelo en Cascada
6.1.2 Modelo de Procesos Incrementables
6.1.3 Modelo de desarrollo rpido de aplicaciones (DRA)
1 de 39
6.1.4 Modelos Evolutivos
6.1.4.1 Construccin de Prototipos
6.1.4.2 Modelo en Espiral
6.1.4.3 Modelo de desarrollo concurrente
6.1.5 Modelos iterativos
6.2 Modelos de Desarrollo giles
6.2.1 Programacin Extrema (XP)
6.2.2 Desarrollo Adaptativo del Software (DAS)
6.2.3 Modelo de Desarrollo de Sistemas Dinmicos (MDSD)
6.2.4 Modelo Scrum
6.2.5 Desarrollo conducido por caractersticas (DCC)
6.2.6 Proceso Unificado de Rational (RUP)
6.3 Diferencias entre los modelos de proceso convencionales y giles
7 Clasificacin de las metodologas segn su enfoque
7.1 Metodologas estructuradas
7.1.1 Metodologas orientadas a procesos
7.1.2 Metodologas orientadas a datos
7.2 Metodologas para sistemas de tiempo real
7.3 Metodologas Orientadas a Objetos
8 Que metodologa es conveniente usar?
9 Modelos de procesos utilizados en el desarrollo de software
9.1 Modelado de Negocios
9.2 Modelado de Negocios e Ingeniera de Requisitos
9.3 Cadena de Valor
10 Conclusiones
11 Referencias
Evolucin histrica de las metodologas de
desarrollo de software
Desde que se empez a trabajar sobre el desarrollo de programas, se siguieron ciertos mtodos que permitan
llevar a producir un buen proyecto, estas metodologas aplicadas eran simples, solo se preocupaban por los
procesos mas no por los datos, por lo tanto los mtodos eran desarrollados hacia los procesos. El modelo de
procesos predominaba para los aos 60 y consista en codificar y corregir (Code-and-Fix), si al terminar se
descubra que el diseo era incorrecto, la solucin era desecharlo y volver a empezar
3
, este modelo
implementaba el cdigo y luego se pensaba en los requisitos, diseo, validacin y mantenimiento. los
principales problemas del modelo de procesos son:
Los arreglos se hacen costosos, despus de tantas correcciones el cdigo tenia una mala estructura.
El software no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstruccin es
muy cara.
El cdigo es difcil de reparar por su pobre preparacin para probar y modificar.
En la dcada de los setenta empez a tomar la importancia de los datos, y para solucionar sistemas
complejos empez el anlisis por partes o etapas, se introducen la planeacin y administracin. El modelo
en cascada surge como respuesta al modelo de procesos, este modelo tiene mas disciplina y se basa en el
2 de 39
anlisis, diseo, pruebas y mantenimientos.
4
La dcada de los ochenta es la poca marcada por las metodologas dirigida a datos cuya importancia va
tomando cuerpo en las organizaciones. Se empiezan a estudiar los objetos en s como unidades de
informacin. Para los aos 90 se quiere dar respuesta al entorno siempre cambiante y en rpida evolucin en
que se han de desarrollar los programas informticos, lo cual da lugar a trabajar en ciclos cortos (como
mini-proyectos) que implementan una parte de las funcionalidades, pero sin perder el rumbo general del
proyecto global.
Por otra parte las metodologas de desarrollo comienzan a interesarse no slo en lograr que el proyecto sea
puesto en funcionamiento sino en minimizar costos durante su desarrollo y sobre todo durante su
mantenimiento. Los nuevos mtodos van buscando minimizar riesgos y, puesto que los errores ms
perjudiciales se producen en los primeros pasos, se comienza ya desde la fase ms general del estudio por
analizar los riesgos que significa seguir con las siguientes fases del desarrollo.
Las metodologas ms utilizadas a nivel mundial en orden cronolgico:
13
Dcada de los 70s
Programacin Estructurada Jackson desde 1975
Dcada de los 80s
Structured Systems Analysis and Design Methodology (SSADM) desde 1980
Structured Analysis and Design Technique (SADT) desde 1980
Ingeniera de la Informacin (IE/IEM) desde 1981
Dcada de los 90s
Rapid Application Development (RAD) desde 1991.
Programacin Orientada a Objetos (OOP) a lo largo de la dcada de los 90's
Virtual Finite State Machine (VFSM) desde 1990s
Dynamic Systems Development Method desarrollado en UK desde 1995.
Rational Unified Process (RUP) desde 1999
Ao 2000 en adelante
Extreme Programming (XP) desde 1999
Enterprise Unified Process (EUP) extensiones RUP desde 2002
Constructionist Design Methodology (CDM) desde 2004 por Kristinn R. Thrisson
Agile Unified Process (AUP) desde 2005 por Scott Ambler
La trascendencia de las metodologas se ha hecho notoria, pasando de solo programar, luego a establecer
funciones en etapas o mdulos, continuar en resaltar en la primera etapa el anlisis de los requisitos,
3 de 39
seguido de basarse en objetos, y por ltimo agilizar el desarrollo del software y minimizar los costos. Estos
cambios de paradigma han logrado las mejoras para desarrollar software y aunque principalmente buscar
acortar el tiempo de solucin sin reprochar los recursos disponibles.
Generaciones de metodologas
Las metodologas han ido cambiando con el tiempo, al surgir nuevos paradigmas que rompe con lo
tradicional para abrir paso a nuevas tcnicas de solucin.
5
Han evolucionando a lo largo del tiempo estas
herramientas, inicialmente el periodo de desarrollo convencional (practicas artesanales), luego surge el
Desarrollo estructurada (parte de la programacin estructurada seguido de los mtodo de anlisis y diseo,
cubre todo el ciclo de vida completo). Actualmente aparece el paradigma de la orientacin a objetos.
Desarrollo Convencional
En los aos 50 el desarrollo estaba a cargo de programadores, por lo que se vio la importancia del anlisis y
diseo en el desarrollo de los sistemas. Aparecen los analistas programadores y analistas de sistemas.
6
En esta misma poca, no existan metodologas de desarrollo. Las personas que desarrollaban los sistemas
eran programadores ms enfocados en la tarea de codificar, que en la de recoger y comprender las
necesidades de los usuarios. Estos, a menudo, no quedaban satisfechos con el sistema, porque sus
necesidades no estaban definidas con claridad en una fase de anlisis previo. Ante esta perspectiva se vio la
importancia del anlisis y del diseo en el desarrollo de un sistema. Ahora se empieza a hablar de analistas
programadores y analistas de sistemas.
Hasta hace relativamente poco tiempo cuando se hablaba de desarrollo se aluda nicamente al
crecimiento econmico dando por supuesto que dicho crecimiento se revierte de manera casi automtica en
los otros sectores de la estructura social. Las estrategias de desarrollo se han concentrado fundamentalmente
en estrategias econmicas, que aunque incorporan elementos de otros sectores por ejemplo del sector
social-, buscan como objetivo fundamental el crecimiento econmico. Por otra parte los ndices de
desarrollo social se han centrado nicamente en los niveles de satisfaccin de necesidades relacionadas
como la subsistencia.
El desarrollo convencional tiene serios problemas, como los siguientes:
Los resultados finales son impredecibles, es decir no se sabe cundo debe acabar un proyecto.
No hay forma de controlar lo que est sucediendo en el proyecto, al no existir fases establecidas y
productos intermedios sobre los que realizar verificaciones.
Los cambios organizativos afectan negativamente al proceso de desarrollo, no suele existir
documentacin estandarizada o no se actualizan oportunamente.
En el desarrollo convencional todo el programa est en un solo bloque, con ejecucin secuencial de
instrucciones. Eran los tiempos del ensamblador, las capacidades reducidas y la necesidad de optimizar al
mximo. Se enfoca tanto a las necesidades del cliente y por lo cual, los programas se hacan sin usar una
metodologa concreta,solo los programadores se proponan a construir un cdigo y si contena errores era
muy difcil prever donde se encontraban.
4 de 39
Desarrollo Estructurado
El desarrollo estructurado comenz con la programacin. A mediados de los 60 el enfoque estructurado se
extiende a la fase de diseo que se conoce como diseo estructurado, el cual se basa en definir una
abstraccin ms amplia usando los mdulos de programa como componentes bsicos de construccin. A
mediados de los 70, se empezaron a surgir las tcnicas estructuradas, donde se empez a construir
programas de una forma artesanal con mtodos de ingeniera. El desarrollo estructurado permiti facilitar la
comprensin de programas, normas para la aplicacin de estructuras de datos y de control.
6
En el diseo estructurado se caracteriza por lo siguiente:
Mayor nivel de abstraccin (independencia del lenguaje programacin).
-Elemento bsico de diseo: mdulo.
Modularidad que permite medir la calidad de programas.
Representa los procesos, flujos y estructuras de datos, de una manera jerrquica y descendente.
Ven el sistema como entradas-proceso-salidas.
Se concentran el la parte del proceso.
Se lee de porciones, independientes de las especificaciones.
Aunque este desarrollo permite disear un buen proceso y estructura de un programa, tiene inconvenientes
como:
Leer todas las especificaciones para entender el problema.
Se repeta la misma informacin en partes diferentes del documento.
El enfoque de requisitos se interpretaba diferente por cada usuario.
Cuando se finalizaba el proceso de desarrollo las especificaciones eran obsoletas.
Este enfoque se conoce como anlisis estructurado o anlisis descendente o top - down. Desde su aparicin
se han hecho mejoras como dar menor importancia a la construccin de los modelos fsicos actuales y a los
modelos lgicos actuales, diferenciar ms los modelos fsicos y lgicos. Ampliar las tcnicas de anlisis
estructurado, para modelar sistemas en tiempo real y enfocarse en el modelo de datos.
En el desarrollo estructurado los programas estn divididos en distintos bloques, estos bloques tienen
funciones que se van confeccionado en forma de arriba-abajo, empezando desde las generales hasta las
particulares, hasta llegar a detallar cada uno de los procedimientos y su interaccin. Este desarrollo se
enfoca al diseo del programa y la compresin se hace mas fcil. Se ha hecho evidente que este enfoque aun
est un poco arraigado ya que se tiende a no pasar de un proceso o iteracin a otra, sin culminar con la
anterior, ademas que el ciclo de vida debe recorrerse completo y al manejarse de esta manera, trae como
consecuencias informacin redundante, costos y desperdicio de tiempo.
Desarrollo Orientado a Objetos
5 de 39
El desarrollo del paradigma de Orientado a Objetos (OO) trata los procesos y datos de forma conjunta. Este
comienza a mediados de los 80 con los lenguajes de programacin Orienta a Objetos en los que se daba
nfasis a la abstraccin de datos para los que se adjuntaba un conjunto de operaciones. Por otra parte los
conceptos de tcnicas estructuradas han servido de base para muchas de las metodolgicas OO.
6
La orientacin a objetos empieza con los lenguajes de programacin orientados a objetos; en estos lenguajes
los problemas del mundo real se representan como un conjunto de objetos para los que se adjuntan un
conjunto de operaciones. Ej: C++, Java.
En la metodologa orientada a objetos el sistema se organiza como una coleccin de objetos que interactan
entre s y que contienen tanto estructuras de datos como un comportamiento. Esto se opone a la
programacin convencional, en la cual las estructuras de datos y el comportamiento solamente estn
relacionadas de forma dbil, ya que estos se enfocan principalmente a las funciones.
Los principios del modelo OO son:
7
Abstraccin: Es una descripcin simplificada o especificacin de un sistema que enfatiza
algunos de los detalles o propiedades del sistema, mientras suprime otros.
Encapsulacin: En el proceso de ocultar todos los detalles de un objeto que no contribuyen a
sus caractersticas esenciales.
Modularidad: Es la propiedad de un sistema que ha sido descompuesto en un conjunto de
mdulos coherentes e independientes.
Jerarqua o herencia: Es el orden de las abstracciones organizado por niveles.
Tipificacin: Es la definicin precisa de un objeto de tal forma que objetos de diferentes tipos
no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy
restringida.
Concurrencia: Es la propiedad que distingue un objeto que est activo de uno que no lo est.
Persistencia: Es la propiedad de un objeto a travs de la cual su existencia trasciende el tiempo
(es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o el
espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue
creado).
Booch (1986) dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos,
entonces no es Orientado a Objetos.
El desarrollo orientado a objetos comprende dividir un programa en clases, donde estas clases estarn
estructuradas por propiedades, atributos, variables, pretendiendo simular y describir de manera conceptual
a un objeto, y lo importante de este desarrollo es que al usar el principio de encapsulamiento proporciona
la ventaja de que se evite interferencias extraas entre distintas partes del programa y podemos cambiar la
implementacin concreta de un objeto sin afectar al resto del sistema. Actualmente este desarrollo es el que
esta aflorando mas en los aspectos de desarrollo de software ya que permite crear un modelo parecido a la
realidad y ver las cosas como un objeto, es decir, realmente como son y como se comportan.
Caractersticas deseables de una metodologa
6 de 39
Existencia de reglas predefinidas, fases y subfases, tareas, productos intermedios, tcnicas y
herramientas tales que se amolden a cualquier desarrollo.
Cobertura total del ciclo de desarrollo.
Verificaciones intermedias.
Planificacin y control.
Comunicacin efectiva.
Utilizacin sobre un abanico amplio de proyectos.
Fcil formacin.
Herramientas case.
La metodologa debe contener actividades que mejoren el proceso de desarrollo.
Soporte al mantenimiento. Por ejemplo. Reingeniera.
Soporte de la reutilizacin de software, no solo reutilizacin de cdigo.
Actualmente, se huye de mtodos muy burocrticos o monolticos.
Lo que se quiere de una metodologa es que permita definir las etapas, las salidas, entradas de un proyecto.
Mantener un programa no es fcil pero se puede lograr, por lo tanto, las metodologas deben permitir una
robusta formacin del proyecto que permita utilizar mecanismos de mejora y que se usen los recursos
disponibles con su mayor rendimiento y eficacia.
Metodologas Vs. Ciclo de vida
Una metodologa es un conjunto integrado de tcnicas y mtodos que permite abordar de forma homognea
y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Una definicin estndar
de metodologa puede ser el conjunto de mtodos que se utilizan en una determinada actividad con el fin de
formalizarla y optimizarla. Determina los pasos a seguir y cmo realizarlos para finalizar una tarea.
15
Si esto se aplica a la Ingeniera de software, podemos destacar que una metodologa:
Optimiza el proceso y el producto software.
Es una gua en la planificacin y en el desarrollo del software.
Define qu hacer, cmo y cundo durante todo el desarrollo y mantenimiento de un proyecto.
Una metodologa define una estrategia global para enfrentarse con el proyecto. Entre los elementos que
forman parte de una metodologa se pueden destacar:
Fases: tareas a realizar en cada fase.
Productos: E/S de cada fase, documentos.
7 de 39
Procedimientos y herramientas: apoyo
a la realizacin de cada tarea.
Criterios de evaluacin: del proceso y
del producto. Saber si se han logrado
los objetivos.
El ciclo de vida es el conjunto de fases por
las que pasa el sistema que se est
desarrollando desde que nace la idea inicial
hasta que el software es retirado o
remplazado (muere).
15
Entre las funciones que debe tener un ciclo
de vida se pueden destacar:
Determinar el orden de las fases del
proceso de software.
Establecer los criterios de transicin
para pasar de una fase a la siguiente.
Definir las entradas y salidas de cada
fase.
Describir los estados por los que pasa el producto.
Describir las actividades a realizar para transformar el producto.
Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar, entre otros.
Las etapas de un ciclo de vida de un software son:
Inicio: ste es el nacimiento de la idea. Aqu definimos los objetivos del proyecto y los recursos
necesarios para su ejecucin. Hacia dnde queremos ir, y no cmo queremos ir. Las caractersticas
implcitas o explcitas de cada proyecto hacen necesaria una etapa previa destinada a obtener el
objetivo por el cual se escribirn miles o cientos de miles de lneas de cdigo. Un alto porcentaje del
xito de nuestro proyecto se definir en estas etapas que, al igual que la etapa de debugging, muchos
lderes de proyecto subestiman.
Planificacin: idearemos un planeamiento detallado que gue la gestin del proyecto, temporal y
econmicamente.
Implementacin: acordaremos el conjunto de actividades que componen la realizacin del producto.
Puesta en produccin: nuestro proyecto entra en la etapa de definicin, all donde se lo presentamos
al cliente o usuario final, sabiendo que funciona correctamente y responde a los requerimientos
solicitados en su momento. Esta etapa es muy importante no slo por representar la aceptacin o no
del proyecto por parte del cliente o usuario final sino por las mltiples dificultades que suele presentar
en la prctica, alargndose excesivamente y provocando costos no previstos.
Control en produccin: control del producto, analizando cmo el proceso difiere o no de los
requerimientos originales e iniciando las acciones correctivas si fuesen necesarias. Cuando decimos
que hay que corregir el producto, hacemos referencia a pequeas desviaciones de los requerimientos
8 de 39
originales que puedan llegar a surgir en el ambiente productivo. Si nuestro programa no realiza la
tarea para lo cual fue creada, esta etapa no es la adecuada para el rediseo. Incluimos tambin en esta
etapa el liderazgo, documentacin y capacitacin, proporcionando directivas a los recursos humanos,
para que hagan su trabajo en forma correcta y efectiva.
Objetivos de cada etapa:
Expresin de necesidades:Esta etapa tiene como objetivo el armado de un documento en el cual se
reflejan los requerimientos y funcionalidades que ofrecer al usuario el sistema a implementar (qu, y
no cmo, se va a implementar).
Especificaciones: Formalizamos los requerimientos; el documento obtenido en la etapa anterior se
tomar como punto de partida para esta etapa.
Anlisis: Determinamos los elementos que intervienen en el sistema a desarrollar, su estructura,
relaciones, evolucin temporal, funcionalidades, tendremos una descripcin clara de qu producto
vamos a construir, qu funcionalidades aportar y qu comportamiento tendr.
Diseo: Ya sabemos qu hacer, ahora tenemos que determinar cmo debemos hacerlo (cmo debe ser
construido el sistema en cuestin?); definimos en detalle entidades y relaciones de las bases de datos,
seleccionamos el lenguaje que vamos a utilizar, el Sistema Gestor de Bases de Datos, entre otros).
Implementacin: Empezamos a codificar algoritmos y estructuras de datos, definidos en las etapas
anteriores, en el correspondiente lenguaje de programacin o para un determinado sistema gestor de
bases de datos. En muchos proyectos se pasa directamente a esta etapa; son proyectos muy
arriesgados que adoptan un modelo de ciclo de vida de code & fix (codificar y corregir) donde se
eliminan las etapas de especificaciones, anlisis y diseo con la consiguiente prdida de control sobre
la gestin del proyecto.
Debugging (Depuracin): El objetivo de esta etapa es garantizar que nuestro programa no contiene
errores de diseo o codificacin. En esta etapa no deseamos saber si nuestro programa realiza lo que
solicit el usuario, esa tarea le corresponde a la etapa de implementacin. En sta deseamos encontrar
la mayor cantidad de errores. Todas los programas contienen errores: encontrarlos es cuestin de
tiempo. Lo ideal es encontrar la mayora, si no todos, en esta etapa. Tambin se pueden agregar
pruebas de rendimiento.
Validacin: Esta etapa tiene como objetivo la verificacin de que el sistema desarrollado cumple con
los requerimientos expresados inicialmente por el cliente y que han dado lugar al presente proyecto.
En muchos proyectos las etapas de validacin y debugging se realizan en paralelo por la estrecha
relacin que llevan. Sin embargo, tenemos que evitar la confusin: podemos realizarlos en paralelo,
pero no como una nica etapa.
Evolucin: En la mayora de los proyectos se considera esta etapa como Mantenimiento y evolucin,
y se le asigna, no slo el agregado de nuevas funcionalidades (evolucin); sino la correccin de
errores que surgen (mantenimiento). En la prctica esta denominacin no es del todo errnea, ya que
es posible que aun luego de una etapa de debugging y validacin exhaustiva, se filtren errores.
Una metodologa puede seguir uno o varios modelos de ciclo de vida, adaptndose a cada uno de ellos,
dependiendo de las necesidades dadas en un momento determinado, es decir, el ciclo de vida indica lo que
hay que obtener a lo largo del desarrollo del proyecto pero no da las indicaciones de como obtenerlo. La
metodologa indica los diferentes pasos y fases para obtener los distintos productos parciales y finales. En s
9 de 39
para el desarrollo de software, se necesita aplicar una metodologa o varias metodologas, dentro de un
ciclo de vida, de manera que sepamos que hacer y como hacerlo para conseguir lo que se quiere y cumplir
con las metas planteadas.
Modelos de procesos en el desarrollo de software
Un modelo de proceso para el desarrollo de software es una representacin simplificada de pasos,
representada desde una perspectiva especfica. Por su naturaleza los modelos son simplificados, por lo tanto
un modelo de procesos del software es una abstraccin de un proceso real.
2
Estos modelos tienen
como propsito la
produccin eficaz y
eficiente de un
producto software que
rena los requisitos
del cliente. Este
proceso es
intensamente
intelectual, afectado
por la creatividad y
juicio de las personas
involucradas.La
mayora de los
modelos de procesos
de desarrollo del
software son dirigidos
por el tiempo; cuanto
ms tarde sea, ms
atrs se encontrar en
el proceso de desarrollo. Como todo proceso, estn constituido de pasos o fases que contienen a su vez
actividades, estos modelos de desarrollo de software se basan en un ciclo de vida para desarrollar el mismo,
como lo son:
La necesidad de solucionar un problema (surgimiento de necesidades)
Inicio del proceso (desarrollo), dentro de esta fase se encuentra la definicin del proyecto, el
anlisis del contexto, definicin de requerimientos, diseo del sistema, construccin del sistema,
pruebas e implantacin.
Operacin y mantenimiento, donde realiza ajustes y se buscan fallas.
Renovacin o extincin.
Los procesos de software son complejos debido a que un producto de software es intangible y por lo general
muy abstracto, esto dificulta la definicin del producto y sus requisitos, sobre todo cuando no se tiene
precedentes en productos software similares. En general este producto esta compuesto por hardware y
software. En cuanto al hardware, su produccin se realiza sistemticamente y la base de conocimiento para
el desarrollo de dicha actividad est claramente definida. Respecto del software, su construccin y
resultados han sido histricamente cuestionados debido a los problemas asociados
10 de 39
Los modelos de procesos permiten al analista de sistemas desarrollar un plan de requisitos del software,
permiten establecer un trabajo en forma ordenada, adems que existen muchos modelos que se adaptan a
las exigencias del proyecto, solo debemos saber cual nos conviene, pero lo mas importante, es que estos
modelos nos llevan a presentar los proyectos al cliente de manera que ste vea su diseo y sus funciones y
que la mayora de ellos estn orientados al mantenimiento.
Clasificacin de las Metodologas segn el modelo
de proceso
Modelos Convencionales o Prescriptivos de Procesos
Los modelos convencionales o modelos prescriptivos de procesos permiten llenar el marco de trabajo con
un conjunto de tareas orientadas al desarrollo de un software.
Se les llama "prescriptivos" porque presciben un conjunto de elementos del proceso, tales como:
21
Actividades del Marco de Trabajo.
Acciones de la Ingeniera del software.
Tareas.
Productos de trabajo.
Aseguramiento de la calidad.
Mecanismos de control del cambio para cada proyecto.
Estos modelos son tiles si queremos describir un conjunto nico de actividades dentro de un marco de
trabajo para un proceso de software. cada actividad debe contener un conjunto de acciones de ingeniera del
software, y definir cada accin en cuanto a un conjunto de tareas que identifique el trabajo (y los productos
del trabajo) que deben completarse para alcanzar las metas de desarrollo. Sin importar el modelo del proceso
que se desee usar, los ingenieros de software eligen una manera tradicional para realizar el marco de trabajo
genrico para el proceso, ya que estos modelos se caracterizan por ser en esencia rgidos,estrictos y los mas
utilizados.
En las metodologas
convencionales, el ciclo de
vida de un proyecto, puede
definirse como un ciclo de
vida lineal, ya que imponen
una disciplina de trabajo sobre
el proceso de desarrollo del
software, con el fin de
conseguir un software ms
eficiente. Para ello, se hace nfasis en la planificacin total de todo el trabajo a realizar y una vez que est
todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control
del proceso, mediante una rigurosa definicin de roles, actividades, artefactos, herramientas y notaciones
para el modelado y documentacin detallada. Adems, las metodologas tradicionales no se adaptan
adecuadamente a los cambios, por lo que no son mtodos adecuados cuando se trabaja en un entorno, donde
los requisitos no pueden predecirse o bien pueden variar.
Los modelos prescriptivos de proceso definen un conjunto distinto de actividades, acciones, tareas
fundamentos y productos de trabajo que es requieren para desarrollar software de alta calidad. Los
11 de 39
ingenieros de software y sus gerentes deben adaptar un modelo prescripto de proceso a sus necesidades y
despus lo siguen. Adems, la gente que ha solicitado el software tiene un papel por desempear se ejecuta
el modelo de software. Por qu es importante? Porque proporciona estabilidad, control y organizacin a
una actividad que si no se controla puede volverse catica. Cules son los pasos? El proceso conduce a un
equipo de software a travs de un conjunto de actividades del marco de trabajo que se organizan en un flujo
de proceso. Cul es un obtenido? Desde punto de vista de un ingeniero de software, los productos de
trabajo son los programas, documentos y datos que se producen como consecuencia de las actividades y
tareas que define el proceso.
Modelo en Cascada
El modelo en cascada, algunas veces llamado
el ciclo de vida clsico, sugiere un enfoque
sistemtico, secuencial hacia el desarrollo del
software, que se inicia con la especificacin
de requerimientos del cliente y que contina
con la planeacin, el modelado, la
construccin y el despliegue para culminar en
el soporte del software terminado.
Este modelo es aplicable en donde existen
ocasiones en que los requisitos de un
problema se entienden de una manera
razonable y deben estar bien definidos,
tambin cuando el trabajo fluye desde la
comunicacin a travs del despliegue de una
manera casi lineal, esta situacin se encuentra a veces cuando es necesario hacer adaptaciones o mejoras
bien definidas a un sistema existente.
El modelo en cascada es el paradigma ms antiguo para la ingeniera del software. Sin embargo, en las
dcadas pasadas, las criticas a este modelo de proceso han ocasionado que aun sus ms fervientes
practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el
modelo en cascada estn:
1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el
modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden
mientras el equipo de proyecto acta.
2. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera explcita. El modelo en
cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de
muchos proyectos.
3. El cliente debe tener paciencia. Una versin que funcione de los programas estar disponible cuando el
proyecto est muy avanzado. Un error grave ser desastroso si no se detecta antes de la revisin del
programa.
En un anlisis interesante de proyectos reales, Bradac(1994) concluy que la naturaleza lineal del modelo en
cascada conduce a "estados de bloqueo" en los cuales algunos miembros del equipo del proyecto deben
esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se
aplica en el trabajo productivo. El estado de bloqueo tiende a ser ms comn al principio y al final del
proceso secuencial.
En la actualidad, el trabajo del software est acelerado y sujeto a una cadena infinita de cambios (de
caractersticas, funciones y contenido de la informacin). Con frecuencia, el modelo en cascada no es
12 de 39
apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso til en situaciones
donde los requerimientos estn fijos y donde el trabajo se realiza, hasta su conclusin, de una manera lineal.
Las principales etapas de este modelo segn Sommerville (2005) son:
Anlisis y definicin de requerimientos. Los servicios, restricciones y metas del sistema se
definen a partir de las consultas con los usuarios. Se define una especificacin del sistema.
Diseo del sistema y del software. El proceso de diseo del sistema divide los requerimientos
en sistemas hardware o software. Establece una arquitectura completa del sistema. El diseo del
software identifica y describe las abstracciones fundamentales del sistema software y sus
relaciones.
Implementacin y prueba de unidades. Durante esta etapa, el diseo del software se lleva a
cabo como un conjunto o unidades de programas.
Integracin y prueba del sistema. Los programas o las unidades individuales de programas se
integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos
del software.
Funcionamiento y mantenimiento. 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.
Algunas veces llamado el ciclo de vida clsico, sugiere un enfoque sistemtico, secuencial hacia el
desarrollo del software, que se inicia con la especificacin de requerimiento del cliente y que contina con
la planeacin, el modelo, la construccin, y el despliegue para culminar en el soporte del software. Es un
enfoque pasado de moda pero til cuando los requisitos son fijos.
Modelo de Procesos Incrementables
El modelo incremental combina elementos
del modelo en cascada aplicado en forma
iterativa.El modelo incremental aplica
secuencias lineales de manera escalonada
conforme avanza el tiempo en el calendario.
Cada secuencia lineal produce "incrementos"
del software. Por ejemplo, el software
procesador de texto, desarrollado con el
paradigma incremental en su primer
incremento, podra realizar funciones bsicas
de administracin de archivos, edicin y
produccin de documentos; en el segundo
incremento, ediciones ms sofisticadas, y
tendra funciones ms complejas de
produccin de documentos; en el tercer
incremento, funciones de correccin ortogrfica y gramatical; y en el cuarto, capacidades avanzadas de
configuracin de pgina. Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede
incorporar el paradigma de construccin de prototipos que se expone ms adelante.
A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se
13 de 39
incorporan los requisitos bsicos, pero muchas caractersticas suplementarias (algunas conocidas, otras no)
no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluacin detallada).
Como resultado de la evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta la
modificacin del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la
entrega de caractersticas y funcionalidades adicionales. Este proceso se repite despus de la entrega de cada
incremento mientras no se haya elaborado el producto completo.
El modelo de proceso incremental, al igual que la construccin de prototipos y otros enfoques evolutivos, es
iterativo por naturaleza. Pero a diferencia de la construccin de prototipos, el modelo incremental se enfoca
en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones
incompletas del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma
para evaluarlo.
El desarrollo incremental es til sobre todo cuando el personal necesario para una implementacin completa
no est disponible. Los primeros incrementos se pueden implementar con menos gente. Si el producto
esencial es bien recibido se agrega (si se requiere) ms personal para implementar el incremento siguiente.
Adems, los incrementos se pueden planear para manejar los riesgos tcnicos. Por ejemplo, un sistema
grande podra requerir la disponibilidad de un hardware nuevo que est en desarrollo y cuya fecha de
entrega es incierta. Sera posible planear los primeros incrementos de forma que se evite el uso de este
hardware, lo que permitira la entrega de funcionalidad parcial a los usuarios finales sin retrasos
desordenados.
Combina elementos del modelo en cascada aplicado en forma iterativa. El modelo incremental aplica
secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia
lineal produce incrementos. Produce entregas de software pequeas pero usables (incrementos). Cada parte
se construye sobre partes ya entregadas.
Modelo de desarrollo rpido de aplicaciones (DRA)
El desarrollo rpido de aplicaciones (DRA)
es un modelo de proceso de software
incremental que resalta un ciclo de desarrollo
corto. El modelo DRA es una adaptacin a
"alta velocidad" del modelo en cascada en el
que se logra el desarrollo rpido mediante un
enfoque de construccin basado en
componentes. Si se entienden bien los
requisitos y se limita el mbito del proyecto,
el proceso DRA permite que un equipo de
desarrollo cree un "sistema completamente
funcional" dentro de un periodo muy corto
(por ejemplo, de 60 a 90 das).
Como otros modelos de proceso, el enfoque
DRA cumple con las actividades genricas
del marco de trabajo que ya se han presentado. La comunicacin trabaja para entender el problema de
negocios y las caractersticas de informacin que debe incluir el software. La planeacin es esencial porque
varios equipos de software trabajan en paralelo sobre diferentes funciones del sistema. El modelado incluye
tres grandes fases modelado de negocios, modelado de datos y modelado del proceso y establece
representaciones del diseo que sirven como base para la actividad de construccin del modelo DRA. La
construccin resalta el empleo de componentes de software existente y la aplicacin de la generacin
14 de 39
automtica de cdigo. Por ltimo, el despliegue establece una base para las iteraciones subsecuentes, si stas
son necesarias.
El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que las restricciones de tiempo
impuestas sobre un proyecto DRA exigen un "mbito de escalas". Si una aplicacin de negocios se puede
modular de forma que cada gran funcin pueda completarse en menos de tres meses (mediante la aplicacin
del enfoque ya descrito), sta es una candidata para el DRA. Cada gran funcin se puede abordar mediante
un equipo de DRA por separado, para despus integrarlas y formar un todo.
Como todos los modelos de procesos, el enfoque DRA tiene inconvenientes:
1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos para crear en
nmero correcto de equipos DRA.
2) Si los desarrolladores y clientes no se comprometen con las actividades rpidas necesarias para completar
el sistema en un marco de tiempo muy breve, los proyectos DRA fallarn.
3) Si un sistema no se puede modular en forma apropiada, la construccin de los componentes necesarios
para el DRA ser problemtica.
4) Si el alto rendimiento es un aspecto importante, y se alcanzar al convertir interfaces en componentes del
sistema, el enfoque DRA podra no funcionar.
5) El DRA sera inapropiado cuando los riesgos tcnicos son altos (por ejemplo, cuando una aplicacin
nueva aplica muchas nuevas tecnologas).
Es un modelo de proceso del software incremental que resulta un ciclo de desarrollo corto. El modelo DRA
es una adaptacin a alta velocidad del modelo en cascada en el que se logra el desarrollo rpido mediante un
enfoque de construccin basado en componentes. Hace un uso intensivo de componentes reusables de
software con un ciclo de desarrollo extremadamente corto.
Es importante destacar que los Modelo Prescriptivos proporcionan un conjunto de pautas para el diseo,
uso y reuso de los objetos de aprendizaje, como complemento al proceso de su descripcin, de una manera
iterativa o incremental, desde la concepcin del objeto de aprendizaje hasta su reusabilidad a corto,
mediano y largo plazo. Pero el xito en la creacin de cualquier objeto de aprendizaje depender de la
adecuada aplicacin del proceso de Ingeniera de Software, cuyas etapas facilitan el desarrollo de los
objetos de aprendizaje.
Modelos Evolutivos
Se reconoce que el software al igual que todos los sistemas complejos evoluciona con el tiempo, los
requisitos de gestin y de producto a menudo cambian conforme a que el desarrollo procede haciendo que el
camino que lleva al producto final no sea real. El desarrollo evolutivo consta del desarrollo de una versin
inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por
parte del cliente o del usuario final. Los modelos evolutivos son iterativos, se caracteriza por la forma en que
permiten a los ingenieros en software desarrollar versiones cada vez ms completas del software. A
continuacin se presentan algunos de los modelos que se clasifican en esta categora.
Construccin de prototipos
Modelos en espiral
Modelo de desarrollo concurrente
15 de 39
En los modelos evolutivos se produce un sistema inicial que evoluciona segn las necesidades del cliente
hasta cumplir con los requisitos de este, para luego producir un sistema que satisfaga sus necesidades. Este
enfoque enlaza las actividades de especificacin, desarrollo y validacin.
Construccin de Prototipos
En Ingeniera de software la
construccin de prototipos pertenece
a los modelos de desarrollo evolutivo,
El prototipo debe ser construido en
poco tiempo, usando los programas
adecuados y no se debe utilizar mucho
dinero pues a partir de que este sea
aprobado es que el desarrollador
puede iniciar el verdadero desarrollo
del software.
El diseo rpido se basa en una
representacin de aquellos aspectos
del software que sern visibles para el
cliente o el usuario final (por ejemplo,
la configuracin de la interfaz con el
usuario y el formato de los
despliegues de salida). El diseo
rpido conduce a la construccin de
un prototipo, el cual es evaluado por
el cliente o el usuario para una
retroalimentacin; gracias a sta se
refinan los requisitos del software que
se desarrollar. La iteracin ocurre
cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el
desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.
La construccin de prototipos se puede utilizar como un modelo del proceso independiente. Sin importar la
forma en que ste se aplique, el paradigma de construccin de prototipos ayuda al desarrollador de software
y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn
satisfechos.
Etapas:
Plan rpido.
Modelado, diseo rpido.
Construccin del Prototipo.
Desarrollo, entrega y retroalimentacin.
Comunicacin.
Ventajas:
Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento o salida.
16 de 39
Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est
inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la
forma que debera tomar la interaccin humano-mquina.
Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.
Reduce costos y aumenta la probabilidad de xito.
Exige disponer de las herramientas adecuadas.
Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de
ingeniera.
Desventajas:
El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A
causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos
importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor
parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin. Es frecuente
que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema
final, lo que lo convertira en un prototipo evolutivo, pero partiendo de un estado poco
recomendado.
El desarrollador suele tomar algunas decisiones de implementacin poco convenientes (por
ejemplo, elegir un lenguaje de programacin incorrecto porque proporcione un desarrollo ms
rpido). Con el paso del tiempo, el desarrollador puede olvidarse de la razn que le llev a
tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar
parte del sistema final.
Cuando el cliente define el software que desea que el analista construya, pero no identifica los requisitos
detallados de entrada, procesamiento o salida. El responsable del desarrollo del software est inseguro de
la adaptabilidad del sistema operativo o de la forma que debera tomar la interaccin hombre mquina,
entonces en este caso es cuando se puede emplear la construccin de prototipos. Se crea un diseo rpido
que se centra en una representacin de aquellos aspectos del software que sern visibles para el usuario
final, a su vez el diseo rpido conduce a la construccin de un prototipo. Despus, el prototipo lo evala el
usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollar.
Modelo en Espiral
El modelo en espiral representa en forma de espiral una secuencia de actividades.
2
Este modelo fue
originalmente propuesto por Boehm en 1988, y se diferencia de los dems modelos por considerar el riesgo.
El modelo en espiral para la ingeniera de software es actualmente el enfoque ms realista para el desarrollo
de software y de sistemas a gran escala. Utiliza un enfoque evolutivo, permitiendo al desarrollador y al
cliente entender y reaccionar ante los riesgos en cada nivel evolutivo.
2
El modelo en espiral se divide en un nmero de actividades estructurales, tambin llamadas regiones de
tareas, segn Sommerville (2005) el ciclo de vida del modelo en espiral se divide cuatro sectores:
1. Definicin de objetivos. En esta fase se identifica las restricciones del proceso y le producto, y
dependiendo los riesgos para trazar objetivos y respectivamente panes estratgicos.
17 de 39
2. Evaluacin y reduccin de
riesgos. Se hace un anlisis
detallado para casa riesgo y se
establece los pasos para
reducirlos.
3. Desarrollo y validacin.
Despus de evaluar los
riesgos, se elige un modelo
para el desarrollo del sistema.
4. Planificacin. El proyecto
se revisa y se toma la decisin
de si debe continuar con un
ciclo posterior de la espiral.
Las caractersticas que se pueden indicar del modelo en espiral son:
El software se desarrolla en una serie de versiones incremntales. Durante las primeras
iteraciones.
La versin incremental podra ser un modelo en papel o un prototipo.
A medida que se va incrementando el nmero de iteraciones, se producen versiones cada vez
mas completas.
Ventajas:
Puede adaptarse y aplicarse a lo largo de la vida del software.
Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente
comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
Permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa
de evolucin del producto.
Demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto.
Reduce los riesgos antes de que se conviertan en problemticos.
Desventajas:
Puede resultar difcil convencer la grandes clientes de que el enfoque evolutivo es controlable
(particularmente en situaciones de contrato).
Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas.
Como es un modelo relativamente nuevo no es muy utilizado.
Otros inconvenientes que pueden surgir es convencer al cliente que es un enfoque
controlable,por lo que se requiere de experiencia en la identificacin de riesgos y refinamiento
para su uso generalizado.
Lo caracterstico del modelo es espiral es que incluye un anlisis de riesgo es decir que podemos
18 de 39
analizar si el proyecto puede continuar o mejor lo suspendemos. Este modelo se basa en que antes de hacer
algo debemos analizarlo, tambin debemos buscar varias opciones de resolucin de problemas para de all
escoger la opcin ms conveniente, y adems analizar los riesgos que se pueda tener. Este modelo necesita
de otro mtodos para poder desarrollarse.
Modelo de desarrollo concurrente
Davis Sitaram describe el modelo de
desarrollo concurrente de la siguiente
forma:
18
"Los gestores de proyectos que siguen los
pasos del estado del proyecto en lo que
se refiere a las fases importantes [del
ciclo de vida clsico] no tiene ideal del
estado de sus proyectos. Estos son
ejemplos de un intento por seguir los
pasos extremadamente simples. Tenga en
cuenta que aunque un proyecto [grande]
este en la fase de codificacin, hay
personal de ese proyecto implicado en
actividades asociadas generalmente a
muchas fases de desarrollo
simultneamente. Por ejemplo,...el
personal esta escribiendo requisitos
diseando, codificando, haciendo
pruebas y probando la integracin (todo
al mismo tiempo). Los modelos de
proceso de ingeniera del software de
Humphrey y Kellner han mostrado la
concurrencia que existe para actividades
que ocurren para cualquier fase. El
trabajo ms reciente de Kellner utiliza
diagramas de estado para representar la
relacin concurrente que existe entre
actividades asociadas a un
acontecimiento especifico, pero falla en
capturar la riqueza de la concurrencia
que existe en todas las actividades del desarrollo y de gestin del software en mi proyecto...La mayora de
los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto ms tarde sea, mas
atrs se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las
necesidades del usuario, las decisiones de la gestin y los resultados de las revisiones."
Acorde con la descripcin de Davis podemos decir que el modelo concurrente se define una serie de
acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la
ingeniera del software proporcionando una visin certera del estado actual del proyecto. Se puede
representar en forma de esquema como una serie de actividades tcnicas importantes, tareas y estados
asociados a ellas.
19
Funcionalidad del proceso:
Cada actividad, accin o tarea dentro de la red existe de manera simultnea con otras.
19 de 39
Los sucesos generados dentro de una actividad dada o algn otro lado de la red de actividad
inicia las transiciones entre los estado de una actividad.
El modelo de proceso concurrente se utiliza como paradigma de desarrollo de aplicaciones cliente/servidor.
Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a
cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una divisin de
sistemas y una divisin de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos
actividades: diseo y realizacin.
La concurrencia se logra de dos formas:
1. Las actividades del sistema y de componente ocurren simultneamente y pueden modelarse con el
enfoque orientado a objetos descrito anteriormente. 2. Una aplicacin cliente/servidor tpica se implementa
con muchos componentes, cada uno de los cuales se pueden disear y realizar concurrentemente.
Ventajas:
Excelente para proyectos en los que se conforman grupos de trabajo independientes.
Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas:
Si no se dan las condiciones sealadas no es aplicable.
Si no existen grupos de trabajo no se puede trabajar en este mtodo
Modelos iterativos
Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos
entendidos durante la etapa de recogida de requisitos. Consiste en la iteracin de varios ciclos de vida en
cascada. Al final de cada iteracin se le entrega al cliente una versin mejorada o con mayores
funcionalidades del producto. El cliente es quien despus de cada iteracin evala el producto y lo corrige o
propone mejoras. Estas iteraciones se repetirn hasta obtener un producto que satisfaga las necesidades del
cliente.
15
El modelo iterativo se suele utilizar en proyectos en los que los requisitos no estn claros por parte del
usuario, por lo que se hace necesaria la creacin de distintos prototipos para presentarlos y conseguir la
conformidad del cliente. Cada iteracin es un mini proyecto en cascada auto contenido compuesto de
actividades como anlisis de requerimientos, diseo, programacin y pruebas.
15
Ventajas:
Permite crear cada vez versiones ms completas de software
Resolucin de problemas de alto riesgo en tiempos tempranos del proyecto.
Visin de avance en el desarrollo desde las etapas iniciales del desarrollo.
Menor tasa de fallo del proyecto, mejor productividad del equipo, y menor cantidad de defectos
El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y mejorando las
planificaciones, logrando menores desvos en la duracin total del proyecto.
Desventajas:
20 de 39
Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que
simplemente no estarn dispuestos a invertir el tiempo necesario.
Infunde responsabilidad en el equipo de desarrollo al trabajar directamente con el cliente,
requiriendo de profesionales sobre el promedio.
Una de las grandes ventajas que ofrece este modelo es que los requisitos se pueden ir refinando en cada una
de las iteraciones, es decir cuando no se puede especificar a priori todos los requisitos del software, sino
que este proceso ayudar a ir descubriendo paso a paso los requisitos a partir de cada nueva entrega,
mediante iteraciones las cuales no son mas que mini proyectos en cascada, en este modelo el cliente tiene la
oportunidad de incluir o desechar elementos al final de cada iteracion, buscando cada vez versiones mas
ccompletas hasta que cumpla sus espectativas o se adapte a sus necesidades
Modelos de Desarrollo giles
Las metodologas giles son un conjunto de mtodos de ingeniera del software, que se basan en el
desarrollo iterativo e incremental, teniendo presente los cambios y respondiendo a estos mediante la
colaboracin de un grupo de desarrolladores auto-organizados y multidisciplinares.
En las metodologas giles, los procesos se desarrollan de manera solapada, donde el ciclo de vida del
proyecto, es cclico. La diferencia en el ciclo de vida de un proyecto gil, en comparacin con uno
tradicional, se debe a la forma en la que el agilismo, solapa los procesos de manera iterativa.
La tendencia del control de procesos para
desarrollo de software ha trado como
resultado que proyectos no resulten exitosos
debido al cambiante contexto que existe, por
lo cul las metodologas giles pretende
resolver este inconveniente, construyendo
soluciones a la medida asegurando la calidad.
Los mtodos giles fueron pensados
especialmente para equipos de desarrollo
pequeos, con plazos reducidos, requisitos
voltiles y nuevas tecnologas. La filosofa de
las metodologas giles, pretenden dar mayor
valor al individuo, a la colaboracin con el
cliente y al desarrollo incremental del
software con iteraciones muy cortas. Este
enfoque est mostrando su efectividad en
proyectos con requisitos muy cambiantes y
cuando se exige reducir drsticamente los
tiempos de desarrollo pero manteniendo una
alta calidad.
14
La direccin del enfoque de establecer una metodologa que solventara los cambios drsticos del ambiente,
di origen en febrero de 2001, tras una reunin celebrada en Utah-EEUU, en esta reunin participan un
grupo de 17 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 desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales
(metodologas pesadas), caracterizados por ser rgidos y dirigidos por la documentacin que se genera en
21 de 39
cada una de las actividades desarrolladas.
La fundacin del manifiesto gil, 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, promovi a que los grupos de desarrolladores se enfocarn y estableciern los siguientes valores:
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente
es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo
que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar
que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio
entorno de desarrollo en base a sus necesidades.
Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es
no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin
importante. Estos documentos deben ser cortos y centrarse en lo fundamental.
La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una
interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la
que marque la marcha del proyecto y asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los
cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el
equipo, entre otros) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no
debe ser estricta sino flexible y abierta.
Estos valores inspiraron los doce principios del manifiesto gil:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un
valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja
competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el
menor intervalo de tiempo posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y
confiar en ellos para conseguir finalizar el trabajo.
VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un
equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios
deberan ser capaces de mantener una paz constante.
IX. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos.
22 de 39
Programacion_extrema.JPEG
XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto
ajusta su comportamiento.
En definicin las metodologas giles son un conjunto de mtodos de ingeniera del software, que se basan
en el desarrollo iterativo e incremental, teniendo presente los cambios y respondiendo a estos mediante la
colaboracin de un grupo de desarrolladores auto-organizados y multidisciplinares.
Las caractersticas esenciales del proceso de desarrollo gil para la mayora de los proyectos son las
siguientes:
Busca la satisfaccin del cliente.
Entrega temprana de software incremental.
Utilizan mtodos informales.
Simplicidad general del desarrollo.
La comunicacin entre los desarrolladores y los clientes durante el desarrollo del proyecto debe
ser activa y continua.
La idea es que se mantenga un canal de retroalimentacin con el cliente, a traves de entregas de
prototipos ejecutable o porcin de un sistema operacional, en periodos cortos para que la
adaptabilidad mantenga un buen ritmo con el cambio.
Programacin Extrema (XP)
La programacin extrema (XP, extreme Programming) es un modelo de
proceso de software el fue acuado por Beck el cual toma los principios y
practicas aceptadas y las lleva a niveles extremos. Tiene como objetivo reducir el riesgo en el ciclo de vida
del software mediante grupos de desarrollo pequeos, considera que la mejor manera de tratar la falta de
requisitos estables en un sistemas, es mediante la agilidad de un grupo pequeo de desarrollo
8
. Esta se basa
en la simplicidad, la comunicacin y el reciclado continuo de cdigo. El modelo considera varios aspectos
problemticos del desarrollo de software como lo son los retrasos , proyectos cancelados, cambios en el
negocio y la rotacin del personal. Sus actividades bsicas son : Codificar, hacer pruebas, escuchar y
disear.
Los objetivos de XP son muy simples:
1. La satisfaccin del cliente: trata de dar al cliente el software que l necesita y cuando lo necesita.
2. Potenciar al mximo el trabajo en grupo: Tanto los jefes de proyecto, los clientes y desarrolladores, son
parte del equipo y estn involucrados en el desarrollo del software.
XP define cuatro variables para proyectos de software: coste, tiempo, calidad y mbito. Adems de estas
cuatro variables, Beck propone que slo tres puedan ser establecidas por las fuerzas externas (jefes de
proyecto y clientes), mientras que el valor de la cuarta variable debe ser establecido por los programadores
en funcin de las otras tres.
8
Los valores originales de la programacin extrema son:
4
Simplicidad: XP propone el principio de hacer la cosa ms simple que pueda funcionar, en relacin al
proceso y la codificacin. Esta es la base de la programacin extrema.
23 de 39
Comunicacin: Los programadores se comunican constantemente gracias a la programacin por
parejas y adems la comunicacin con el cliente es fluida ya que el cliente forma parte del equipo de
desarrollo
Retroalimentacin: retroalimentacin concreta y frecuente del cliente, del equipo y de los usuarios
finales da una mayor oportunidad de dirigir el esfuerzo.
Coraje o valenta : La valenta le permite a los desarrolladores que se sientan cmodos con
reconstruir su cdigo cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si
con ello los cambios futuros se implementaran mas fcilmente.
Principios bsicos en la Programacin extrema:
9
Planificacin Incremental: los requerimientos se registran en tarjetas de historias, estas incluyen el
tiempo y la prioridad relativa.
Entregas pequeas: estas entregas son frecuentes e incrementalmente aaden funcionalidad al
primera entrega
Diseo sencillo: solo se lleva a cabo el diseo necesario para cumplir los requerimientos actuales
Desarrollo previamente probado; se utiliza un sistema de pruebas, para escribir pruebas de las
nuevas funcionalidades antes de que estas se implementen.
Refactorizacin: conserva el cdigo sencillo y mantenible.
Programacin en parejas: esta es la mas importante de todos los principios, los desarrolladores
trabajan en parejas, verificando cada uno el trabajo del otro, proporcionando la ayuda para hacer
siempre un buen trabajo
Propiedad colectiva: las parejas trabajan en todas las reas del sistema.
Integracin continua: cuanto acaba el trabajo en una tarea, se integra en el sistema entero.
Ritmo sostenible: No se consideran aceptables grandes cantidades de horas extras, ya que a menudo,
reduce la calidad del codigo y la productividad a medio plazo.
Cliente presente: Debe estar disponible al equipo de XP, un represente de los usuarios finales del
sistema a tiempo completo. En un proceso XP el cliente es parte del equipo de desarrollo
La programacin extrema es uno de los mtodo giles ms conocido y ampliamente utilizados, donde el
usuario o cliente forma parte del equipo de trabajo, engloba en una serie de principios dentro de los ms
importantes se encuentra la programacin en parejas y el desarrollo de pruebas, as como tambin
reulitizacin de los cdigos. Para el uso de XP los requerimientos deben de estar bien definidos, mediante
las historias de usuario. Este modelo se basa en la retroalimentacin continua entre el cliente y el equipo de
desarrollo, especialmente muy utilizada para proyectos con requisitos imprecisos y muy cambiantes,
centrada en potenciar las relaciones interpersonales como clave para el xito en el desarrollo de software,
promoviendo el trabajo en equipo y preocupndose por el aprendizaje de los desarrolladores y la
satisfaccin del cliente
Desarrollo Adaptativo del Software (DAS)
24 de 39
DAS.JPEG
MDSD.jpg
El desarrollo adaptativo de software (DAS) 1998 fue propuestos por Jim Highsmith como una
metodologa para desarrollar el software y sistemas muy complejos. Este se centra en la
colaboracin humana y la organizacin del equipo
2
. El Desarrollo adaptativo del software proporciona un
marco para el desarrollo iterativo de sistemas grandes y complejos, el mismo fomenta el desarrollo iterativo
e incremental con el uso de prototipos.
El ciclo de vida del DAS se conforma de tres fases: Especulacin, colaboracin y aprendizaje
- Fase de especulacin: Es la primera de las fases esta inicia en el desarrollo del proyecto. Se utiliza
informacin como la visin del cliente, las restricciones del proyecto y los requisitos bsicos para definir el
conjunto de ciclos en el que se harn los incrementos del software. En esta fase es donde se lleva a cabo la
planificacin tentativa del proyecto en funcin de las entregas que se iran realizando
- Fase de colaboracin: Se busca que el equipo colabore inmensamente para lograr la funcionalidad
planeada, se comunique o se encuentre completamente integrados, se desea que exista confianza, donde se
puedan realizar crticas constructivas y ayudar si resentimientos, as como tambin comunicar de una forma
oportuna los problemas que se presenten para tomar acciones efectivas y poseer un conjunto de actitudes
que contribuyan al trabajo que se encuentran realizando.
- Fase del aprendizaje: consiste en la revisin de calidad que se realiza al final de cada ciclo, esto permite
mejorar el entendimiento real sobre la tecnologa, los procesos utilizados y el proyecto. El aprendizaje
individual permite al equipo tener mayor posibilidad de xito.
Esta metodologa no proporciona el tipo de prcticas detalladas como lo hace XP, pero proporciona la base
fundamental de por qu el desarrollo adaptable es importante y las consecuencias a los ms profundos
niveles de la organizacin y la gerencia. Los apoyos filosficos del DAS se enfocan en la colaboracin
humana y la organizacin propia del equipo, y es un modelo para la construccin de software y sistemas
complejos, incluye tres fases que son: especulacin, colaboracin y aprendizaje, cada una de estas fases son
fundamental para el desarrollo de la otra. Es adaptativo, se hace uso de la reutilizacin del cdigo para
adaptarlo a lo que se desea
Modelo de Desarrollo de Sistemas Dinmicos (MDSD)
Es un metodo de desarrollo agil de software que apoyado por su continua implicacion del usuario
en un desarrollo iterativo y creciente que sea sensible a los requerimientos cambiantes, para
desarrollar un sistema que reuna las necesiadades de la empresa en tiempo y presuspuesto. Este se
caracteriza por proporcionar un marco de trabajo el cual permita construir y mantener sistemas con
restricciones de tiempo muy estrechas mediante el empleo de la construccin de prototipos incremntales en
un ambiente de proyecto controlado
10
El MDSD comienza con un estudio de viabilidad y de negocio, son las primeras actividades que deben
realizarse
Estudio viabilidad: Se evala si la aplicacin es viable, para el proceso teniendo en cuenta los
requisitos bsicos del negocio y sus restricciones asociadas.
Estudio de negocios: establece los requisitos funcionales y de informacin que permitirn que la
aplicacin proporcione un valor al negocio; tambin define la arquitectura bsica de la aplicacin.
El resto del proceso forma tres ciclos iterativos que son:
Iteracin de modelo funcional: produce una serie de prototipos incremntales que demuestran la
25 de 39
Scrum.png
funcionalidad para el cliente. Su propsito durante este ciclo es recopilar requisitos adicionales y
producir documentacin de anlisis.
Iteracin de construccin y diseo: revisa la construccin de prototipos durante la iteracin del
modelo funcional, en este se disea el sistema para el uso operacional. En algunos casos, la iteracin
del modelo funcional y esta, suceden en forma concurrente.
Implementacin: coloca el incremento de software ms reciente en el ambiente operativo, se ocupa
del despliegue al uso operacional. Puede destacarse que 1) el incremento puede no estar 100 por
ciento completo o 2) se pueden requerir cambios cuando el incremento se coloca en el sitio.
El modelo de desarrollo de sistemas dinmicos tiene como objetivo fundamental la entrega de sistemas
software en tiempo y presupuesto , ajustndose a los cambios de requisitos que puedan surgir durante el
proceso de desarrollo. Para su implementacin se hacen dos estudios principalmente el de negocio y el de
viabilidad, para posteriormente dar inicio a sus 3 ciclos de vida . Al igual que XP el desarrollo es iterativo e
incremental as como tambin basado por la retroalimentacin del usuario, de esa manera logrando
converger la solucin del negocio mas efectiva. Ademas de lo mencionado anteriormente el MDSD incluyen
enttregas frecuentes, equipos autorizados, y pruebas a lo largo de todo su ciclo
Modelo Scrum
Scrum es una metodologa gil de gestin de proyectos cuyo objetivo primordial es elevar al
mximo la productividad de un equipo, fue desarrollado por Jeff Sutherland y elaborado ms
formalmente por Ken Schwaber.
11
. Se enfoca en el hecho de que procesos definidos y repetibles slo
funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos
y repetibles. Y se divide un proyecto en iteraciones (que ellos llaman carreras cortas) de 30 das. La
literatura de Scrum se orienta principalmente en la planeacin iterativa y el seguimiento del proceso
12
Caracteristicas:
Enfatiza valores y prcticas de gestin, sin pronunciarse sobre requerimientos, prcticas de desarrollo,
implementacin y dems cuestiones tcnicas.
Hace uso de Equipos auto-dirigidos y auto-organizados
Puede ser aplicado tericamente a cualquier contexto en donde un grupo de gente necesita trabajar
junta para lograr una meta comn.
Desarrollo de software iterativos incrementales basados en prcticas agiles
Iteraciones de treinta das; aunque se pueden realizar con mas frecuencia, estas iteraciones, conocidas
como Sprint
Dentro de cada Sprint se denomina el Scrum Master al Lder de Proyecto quien llevar a cabo la
gestin de la iteracin
Se convocan diariamente un Scrum Daily Meeting el cual representa una reunin de avance diaria
de no ms de 15 minutos con el propsito de tener realimentacin sobre las tareas de los recursos y los
obstculos que se presentan. En la cual se responden preguntas como: Qu has hecho desde el ultimo
encunetro? Qu obstaculos hay para cumplir la meta? Qu haras antes del proximo encuentro?
Ciclo de Vida de Scrum
En cuanto al ciclo de vida del modelo Scrum es el siguiente
12
:
1. Pre-Juego / Planeamiento: El propsito es establecer la visin, definir expectativas y asegurarse la
26 de 39
DCC.png
financiacin. Las actividades son la escritura de la visin, el presupuesto, el registro de acumulacin o
retraso Metodologas giles (backlog) del producto inicial y los tems estimados, as como la arquitectura de
alto nivel, el diseo exploratorio y los prototipos. El registro de acumulacin es de alto nivel de abstraccin.
2. Pre-Juego / Montaje (Staging): El propsito es identificar ms requerimientos y priorizar las tareas para
la primera iteracin. Las actividades son planificacin, diseo exploratorio y prototipos.
3. Juego / Desarrollo: El propsito es implementar un sistema listo para entrega en una serie de iteraciones
de treinta das llamadas corridas (sprints). Las actividades son un encuentro de planeamiento de corridas
en cada iteracin, la definicin del registro de acumulacin de corridas y los estimados, y encuentros diarios
de Scrum.
4. Pos-Juego/ Liberacin: El propsito es el despliegue operacional. Las actividades, documentacin,
entrenamiento, mercadeo y venta.
Scrum es una metodologa para la gestin y desarrollo de software basada en un proceso iterativo e
incremental, uno de sus principios claves radica en el reconocimiento de que durante un proyecto los
clientes pueden cambiar sus pensamientos sobre lo que quieren y necesitan. En este modelo se hacen
reuniones diarias o tambin denominadas reuniones cortas (15 min aprox) donde se discute lo que se hizo,
lo que se hace, y lo que posteriormente se har . Es una ayuda para organizar a las personas y el flujo de
trabajo, es importante destacar que en este modelo los equipos son auto-organizados (no auto-dirigidos),
con margen de decisin suficiente para tomar las decisiones que consideren oportunas.
Desarrollo conducido por caractersticas (DCC)
El desarrollo conducido por caractersticas (DCC) lo concibieron originalmente Peter Coad como
un modelo de proceso prctico para la ingeniera del software orientada a objetos. Stephen Palmer
y John Felsin han extendido y mejorado el trabajo de Coad, al describir un proceso adaptativo y gil que
puede aplicarse en proyectos de software de tamao moderado y grande. En el contexto del DCC una
caracterstica "es una funcin evaluada por el cliente que puede implementarse en dos semanas o menos.
13
Beneficios que se le concede a la definicin de caractersticas:
13
Las caractersticas se pueden organizar en un agrupamiento jerrquico relacionado con el negocio.
Como las caractersticas son bloques pequeos de funcionalidad entregable, los usuarios las describen
con mayor facilidad, pueden entender cmo stas se relacionan con otras con mayor rapidez, y pueden
revisarlas de mejor manera en bsqueda de ambigedades, errores u omisiones.
Una caracterstica es el incremento de software entregable, el equipo desarrolla caractersticas
operativas cada dos semanas.
Debido a que las caractersticas son pequeas, sus diseos y representaciones de cdigo son ms
fciles de inspeccionar de manera efectiva
El DCC se encuentra dividido en cinco fases o actividades:
13
1. Desarrollar un modelo General 2. Elaborar una lista de caractersticas 3. Plan por caractersticas 4. Diseo
por caractersticas 5. Construccin por caractersticas
El desarrollo de un modelo general: En una fase ya se tiene el dominio, el contexto, y los requerimientos
del sistema a construir. En este momento se posee informacin bsica de las especificaciones funcionales.
27 de 39
referencias
La construccin de la lista de caractersticas los ensayos, modelos de objetos y documentacin de
requerimientos proporcionan la base para construir una amplia lista de caractersticas . Las funciones se
agrupan conforme a diversas actividades en reas de dominio especificas y la lista de caractersticas es
revisada por los usuarios para asegurar su validez y exhaustividad
El diseo y la construccin por caractersticas, se selecciona las caractersticas a desarrollar y los equipos
dispuestos por cada una de ellas. Luego se procede iterativamente hasta que se producen las caractersticas
seleccionadas.
El desarrollo conducido por caractersticas es un modelo de proceso prctico para la ingeniera de software
orientada a objetos debido a que las caractersticas se pueden organizar en un grupos relacionado con el
negocio, y este busca que el equipo de proyecto desarrolle las caractersticas o funciones que son evaluadas
por el cliente, las cuales pueden ser implementadas en un corto tiempo de dos semanas o menos, es un
modelo que se enfoca ms hacia la parte de la direccin y gestin de proyectos
Proceso Unificado de Rational (RUP)
El Proceso Unificado
de Rational es una
metodologa de
desarrollo de
software orientada a
objetos creada por
Rational Software
Corporation.
Es una de las
metodologas ms
extendidas y
conocidas por su
amplia difusin
comercial. Se puede
estudiar como una
metodologa
representativa de tipo
clsico. Fue definido
por los creadores del
UML unificando los
mtodos de Ivar
Jacobson, Grady
Booch y James Rumbaugh. El hecho de que la empresa RATIONAL tambin distribuya herramientas
especficas basadas en el mismo mtodo, que facilitan el desarrollo, ha contribuido a su gran expansin.
16
Este proceso se maneja por casos de uso (correspondientes a los modos uso por los actores o agentes
usuarios) para la extraccin de requisitos y la identificacin de las partes funcionales en las que se divide la
solucin. La arquitectura del proceso se modela con orientacin a objetos.
Estos metodologistas, fueron reunidos por Rational para formar un marco de metodologas unificadas,
cohesivas y comprehensivas de desarrollo de sistemas de software. Su trabajo, que producen durante varios
28 de 39
aos y basados en metodologas probadas, han dado a lugar a importantes normas en la comunidad de
desarrollo,
Como toda metodologa de desarrollo software su finalidad es convertir las especificaciones que da el
cliente en un sistema software. Las caractersticas que tiene el RUP. son:
Est basado en componentes. Estos componentes a su vez estn conectados entre s a travs de
interfaces.
Utiliza el UML como notacin bsica.
Dirigido por casos de uso. El proceso utiliza Casos de Uso para manejar el proceso de desarrollo
desde la Incepcin hasta el Despliegue.
Centrado en la arquitectura. El proceso busca entender los aspectos estticos y dinmicos ms
significativos en trminos de arquitectura de software. La arquitectura se define en funcin de las
necesidades de los usuarios y se determina a partir de los Casos de Uso base del negocio.
Ciclo de vida iterativo e incremental. El proceso reconoce que es prctico dividir grandes proyectos
en proyectos ms pequeos o mini-proyectos. Cada mini-proyecto comprende una iteracin que
resulta en un incremento. Una iteracin puede abarcar la totalidad de los flujos del proceso. Las
iteraciones son planificadas en base a los Casos de Uso.
Proceso de cuatro fases
El proceso Unificado consta de ciclos que puede repetir a lo largo del ciclo de vida de un sistema. Un ciclo
consiste en cuatro fases: Incepcin, Elaboracin, Construccin y Transicin. Un ciclo concluye con una
liberacin, tambien hay versiones dentro de un ciclo.
Esta es una descripcin breve de las fases de un ciclo:
Fase de Incepcin: Durante la fase inicial se concibe la idea central del producto, se arma el
documento de visin. En esta fase, se revisan y confirma nuestro entendimiento sobre los objetivos
centrales del negocio. Queremos entender los argumentos comerciales en favor de porqu el proyecto
debe intentarse. La fase de incepcin establece la viabilidad del producto y delimita el alcance del
proyecto.
Se describe el producto final. Se responde a las preguntas:
Cules son las principales funciones del sistema para sus usuarios ms importantes?. La respuesta est en el
modelo de casos de uso simplificado.
Cmo podra ser la arquitectura del sistema?
Cul es el plan del proyecto y cunto costar desarrollar el producto?
Fase de Elaboracin: Durante la fase de elaboracin la mayora de los Casos de Uso son
especificados en detalle y la arquitectura del sistema es diseada. Esta fase se focaliza en las
-bilidades del proyecto. Se identifican los riesgos significativos y se preparan el calendario, el
equipo de trabajo y el costo del proyecto.
Fase de Construccin: Durante la fase de construccin, el foco del producto se mueve de la
arquitectura de base a un sistema lo suficientemente completo como para llevarlo al usuario. El
baseline de arquitectura crece en complejidad y se convierte en un sistema completo, de la misma
manera, se refina el disea para llevarlo a cdigo fuente.
29 de 39
Se construye el producto, se utilizan la mayor parte de los recursos, y al finalizar se cubren todos los casos
de uso. La pregunta que se realiza es: Cubre el producto las necesidades de los usuarios como para hacer
una primera entrega?
Fase de Transicin: En la fase de transicin el objetivos es garantizar que los requisitos se han
cumplido, con la satisfaccin de las partes interesadas. Esta fase a menudo se inicia con una versin
beta de la aplicacin. Otras actividades incluyen la preparacin del ambiente, se completan, se
identifican y corrigen defectos. La fase de transicin termina con un cierre dedicado al aprendizaje de
lecciones, las cuales quedan para futuros ciclos.El producto existe en versin Beta.
La metodologa de RUP es una forma disciplinada de asignar tareas y responsabilidades en una empresa de
desarrollo (quin hace qu, cundo y cmo), este proceso de RUP estiman tareas y horario del plan
midiendo la velocidad de iteraciones concerniente a sus estimaciones originales. RUP se enfocan
fuertemente sobre la arquitectura del software. para su implementacin se hace a travs de cuatro etapas o
fases y en cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en
reproducir el ciclo de vida en cascada a menor escala, este tiene grandes ventajas con respectos a XP, ya
que se enfoca en los requisitos y el diseo, as como tambin el cliente interacta con el equipo de
desarrollo mediante reunionesa diferencia de la metodologa XP que el cliente es parte del equipo
Diferencias entre los modelos de proceso convencionales y giles
Metodologas giles:
Estn basadas en heurstica provenientes de prcticas de produccin de cdigos.
Estn preparadas para cambios durante el proyecto.
Son impuestas internamente (por el equipo).
Proceso menos controlado.
No existe contrato tradicional.
Son bastante flexibles.
El cliente es parte del equipo de desarrollo.
Grupos pequeos y trabajando en el mismo sitio.
Menos nfasis en la arquitectura del software.
Metodologas convencionales:
Basadas en normas provenientes de estndares.
Presentan cierta resistencia a los cambios.
Impuestas externamente.
Proceso mucho mas controlado, con numerosas polticas.
30 de 39
Existe un contrato prefijado.
Son un poco rgidas.
El cliente interacta con el equipo de desarrollo mediante reuniones.
Grupos grandes y posiblemente distribuidos.
La arquitectura del software es esencial y se expresa mediante modelos.
Clasificacin de las metodologas segn su enfoque
Metodologas estructuradas
Se basan en la forma top-down. Entre estas estn:
Metodologas orientadas a procesos
Se basan en la utilizacin de un mtodo descendente de descomposicin funcional para definir los requisitos
del sistema, dan lugar a un nuevo concepto "la especificacin estructurada" que es un modelo grfico
particionado, descendente y jerrquico de los procesos del sistema.
La metodologa orientada a procesos est compuesta por:
Diagrama de flujo de datos: Estos son diagramas que representan los procesos de datos que deben
llevar acabo un sistema a distintos niveles de abstraccin y los datos que hay entre las funciones.
Diccionario de datos: Es el conjunto de las definiciones de todos los datos que aparecen en el
diagrama de flujos de datos.
Especificaciones de procesos: como se obtienen las salidas del proceso a partir de sus entradas.
Las metodologas orientadas a procesos comprende una fase de anlisis estructurado y los mtodos de
DeMarco, Gene y Sarson, Yourdon, son algunos que permiten lograr esto.
Metodologa de Demarco: se basa en el estudio del sistema fsico actual, derivacin del modelo lgico
actual, derivacin al nuevo modelo lgico y creacin de modelos fsicos alternativos.
Metodologa de Gane y Sarson: Es parecida a la de Demarco, la diferencia es que elimina el primer
paso y crea uno nuevo que es cuando construye el modelo lgico del sistema. Tambin construye un
modelo lgico de datos.
Metodologa de Yourdon: Realiza los DFDs del sistema, a partir de los DFD realiza el diagrama de
estructuras, evaluacin del diseo y preparacin del diseo.
Metodologas orientadas a datos
Son metodologas basadas en la informacin, ya que los datos son ms estables que los procesos. Primero se
definen las estructuras de datos y, a partir de stos, se derivan los componentes procedimentales.
Ejemplos de esta clasificacin son: metodologas de Jackson, Warnier, Warnier-Orr.
Estas metodologas se dividen en jerrquicas y no jerrquicas:
31 de 39
Metodologa orientada a datos jerrquicas:
La estructura de control del programa debe ser jerrquica y se debe derivar de la estructura de datos
del programa.
El proceso de diseo consiste en definir primero las estructuras de los datos de entrada y salida,
mezclarlas todas en una estructura jerrquica de programa y despus ordenar detalladamente la lgica
procedimental para que se ajuste a esta estructura.
El diseo lgico debe preceder y estar separado del diseo fsico.
Metodologa orientada a datos no jerrquicas:
Metodologa Ingeniera de la Informacin.
Planificacin: construir una arquitectura de la Informacin y una estrategia que soporte los objetivos
de la organizacin .
Anlisis: comprender las reas del negocio y determinar los requisitos del sistema.
Diseo: establecer el comportamiento del sistema deseado por el usuario y que sea alcanzable por la
tecnologa.
Construccin: construir sistemas que cumplan los tres niveles anteriores.
Las metodologas estructuradas estn orientadas a procesos y a objetos. Intentan aplicar ingeniera para
solucionar problemas tcnicos de un sistema de informacin, proponen la creacin de modelos, flujos y
estructuras mediante un top-down. La metodologa orientada a procesos est fundamentada en el modelo
entrada-proceso-salida., aplica un proceso interactivo para lograr un refinamiento progresivo.
La metodologa orientada a objetos se divide en jerrquica y no jerrquica, la jerrquica est orientada a las
entradas y salidas, las no jerrquicas definen un sistema a partir de la informacin que este maneja.
Metodologas para sistemas de tiempo real
Las metodologas en tiempo real procesan informacin orientada al control ms que a los datos.
Se caracterizan por:
Concurrencia.
Priorizacin de procesos.
Comunicacin y sincronizacin entre tareas.
Acceso simultneo a datos comunes.
Permiten el manejo de interrupciones.
Gestin de procesos concurrentes
Respuesta oportuna ante eventos externos.
Datos continuos o discretos.
Metodologas Orientadas a Objetos
La orientacin a objetos unifica procesos y datos encapsulndolos en el concepto de objetos. La esencia del
desarrollo orientado a objetos es la identificacin y organizacin de conceptos del dominio de la aplicacin y
32 de 39 09/06/2014 05:22 PM
no tanto de su representacin final en un lenguaje de programacin.
Tiene dos enfoques distintos:
Revolucionario, puro u ortodoxo: Rompen con las metodologas tradicionales. La Orientacin a
objetos se entiende como un cambio profundo de las metodologas estructuradas que se ven como
obsoletas. Ejemplos: metodologas OOD de Booch, CRC/RDD de Wirfs-Brock.
Sintetista o evolutivo:El anlisis y diseo estructurado se considera como la base para el desarrollo
Orientado a objetos.
Ventajas de las metodologas orientadas a objetos:
Reutilizacin. Las clases estn diseadas para que se reutilicen en muchos sistemas. Para maximizar la
reutilizacin, las clases se construyen de manera que se puedan adaptar a los otros sistemas. Un objetivo
fundamental de las tcnicas orientadas a objetos es lograr la reutilizacin masiva al construir el software.
Estabilidad. Las clases diseadas para una reutilizacin repetida se vuelven estables, de la misma manera
que los microprocesadores y otros chips se hacen estables.
El diseador piensa en trminos del comportamiento de objetos y no en detalles de bajo nivel. El
encapsulamiento oculta los detalles y hace que las clases complejas sean fciles de utilizar.
Se construyen clases cada vez ms complejas. Se construyen clases a partir de otras clases, las cuales a su
vez se integran mediante clases. Esto permite construir componentes de software complejos, que a su vez se
convierten en bloques de construccin de software ms complejo.
Calidad. Los diseos suelen tener mayor calidad, puesto que se integran a partir de componentes probados,
que han sido verificados y pulidos varias veces.
Un diseo ms rpido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los
componentes estn construidos de modo que se pueden adaptar para un diseo particular.
Integridad. Las estructuras de datos (los objetos) slo se pueden utilizar con mtodos especficos. Esto tiene
particular importancia en los sistemas cliente-servidor y los sistemas distribuidos, en los que usuarios
desconocidos podran intentar el acceso al sistema.
Mantenimiento ms sencillo. El programador encargado del mantenimiento cambia un mtodo de clase a la
vez. Cada clase efecta sus funciones independientemente de las dems.
Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una interfaz de usuario grfica de modo
que el usuario apunte a iconos o elementos de un men desplegado, relacionados con los objetos. En
determinadas ocasiones, el usuario puede ver un objeto en la pantalla. Ver y apuntar es ms fcil que
recordar y escribir.
Independencia del diseo. Las clases estn diseadas para ser independientes del ambiente de plataformas,
hardware y software. Utilizan solicitudes y respuestas con formato estndar. Esto les permite ser utilizadas
en mltiples sistemas operativos, controladores de bases de datos, controladores de red, interfaces de usuario
grficas, etc. El creador del software no tiene que preocuparse por el ambiente o esperar a que ste se
especifique.
Interaccin. El software de varios proveedores puede funcionar como conjunto. Un proveedor utiliza clases
de otros. Existe una forma estndar de localizar clases e interactuar con ellas. El software desarrollado de
manera independiente en lugares ajenos debe poder funcionar en forma conjunta y aparecer como una sola
unidad ante el usuario.
33 de 39
Computacin Cliente-Servidor. En los sistemas cliente-servidor, las clases en el software cliente deben
enviar solicitudes a las clases en el software servidor y recibir respuestas. Una clase servidor puede ser
utilizada por clientes diferentes. Estos clientes slo pueden tener acceso a los datos del servidor a travs de
los mtodos de la clase. Por lo tanto los datos estn protegidos contra su corrupcin.
Computacin de distribucin masiva. Las redes a nivel mundial utilizarn directorios de software de objetos
accesibles. El diseo orientado a objetos es la clave para la computacin de distribucin masiva. Las clases
de una mquina interactan con las de algn otro lugar sin saber donde residen tales clases. Ellas reciben y
envan mensajes orientados a objetos en formato estndar.
Mayor nivel de automatizacin de las bases de datos. Las estructuras de datos (los objetos) en las bases de
datos orientadas a objetos estn ligadas a mtodos que llevan a cabo acciones automticas. Una base de
datos OO tiene integrada una inteligencia, en forma de mtodos, en tanto que una base de datos relacional
bsica carece de ello.
Las metodologas orientadas a objetos han evolucionado para ayudar a los desarrolladores a explotar el
poder de los lenguajes de programacin basados en objetos y orientados a objetos, utilizando las clases y
objetos como bloques de construccin bsicos. Una orientacin a objetos nos ayuda a hacer frente a la
inherente complejidad de muchos tipos de sistemas.
Que metodologa es conveniente usar?
Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta una idea
interesante. Estas metodologas pueden involucrar prcticas tanto de metodologas giles como de
metodologas tradicionales. De esta manera podramos tener una metodologa para cada proyecto, la
problemtica sera definir cada una de las prcticas, y en el momento preciso definir parmetros para saber
cual usar.Es importante tener en cuenta que el uso de un mtodo gil no es para todos. Sin embargo, una de
las principales ventajas de los mtodos giles es su peso inicialmente ligero y por eso las personas que no
estn acostumbradas a seguir procesos encuentran estas metodologas bastante agradables. Por otro lado, las
metodologas tradicionales o convencionales permiten crear software de manera mas segura ya que estas
entan mas establecidas segn por sus pasos.
Modelos de procesos utilizados en el desarrollo de
software
Modelado de Negocios
Para conseguir sus objetivos, una empresa organiza su actividad por medio de un conjunto de procesos de
negocio. Cada uno de ellos se caracteriza por una coleccin de datos que son producidos y manipulados
mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos)
participan de acuerdo a un flujo de trabajo determinado. Adems, estos procesos se hallan sujetos a un
conjunto de reglas de negocio, que determinan las polticas y la estructura de la informacin de la empresa.
Por tanto, la finalidad del modelado del negocio es describir cada proceso del negocio, especificando sus
datos, actividades (o tareas), roles (o agentes) y reglas de negocio.
Con esta disciplina se pretende llegar a un mejor entendimiento de la organizacin.
Los objetivos especficos del modelado de negocio son:
34 de 39
1. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la
organizacin objetivo.
2. Derivar los requerimientos del sistema necesarios para apoyar a la organizacin objetivo en su mejora.
3. Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras.
4. Entender la estructura y la dinmica de la organizacin para la cual el sistema va a ser desarrollado
(organizacin objetivo).
Para lograr estos objetivos, el modelado de negocio describe como desarrollar una visin de la nueva
organizacin, basado en esta visin se definen procesos, roles y responsabilidades de la organizacin por
medio de un Modelo de Casos de Uso del Negocio. Los artefactos del modelo de negocio sirven como
entrada y referencia para la definicin de los requerimientos del sistema.
La importancia de esta disciplina radica en que sin el panorama completo del alcance del negocio y sin el
entendimiento de sus procesos no podrn identificarse las necesidades inmediatas de mejora y continuidad
relativa a las actividades relacionadas con los sistemas informticos, que son el producto final del desarrollo.
Orientacin del modelado de negocio.
Dominios principales en los que se emplea:
Dominios orientados al negocio
Gerencia
Teora de Organizaciones
E-business, E-commerce
Dominios orientados a la tecnologa
Sistemas de Informacin
Ingeniera de Software
Informtica Industrial
Los dominios definen dos puntos de vista diferentes del Modelado de:
Orientado al valor/cliente
Busca explicar cmo la empresa crea valor para el cliente, que valor le proporciona a sus clientes los
productos o servicios de una empresa, en este caso entenderemos el modelo de negocio como una
herramienta conceptual que tiene un conjunto de objetos, conceptos y relaciones con el objetivo de expresar
la lgica del negocio de una empresa Osterwalde , Pigneur (2005).
Orientado a la actividad/rol
Hace nfasis en el modelado de los procesos y actores de la empresa , en las actividades que realiza la
empresa y quienes participan en ellas, el modelo de negocio se define en este caso como una abstraccin
de cmo una empresa funciona proporciona una vista simplificada de la estructura del negocio que acta
35 de 39
Cadena_d_valor_de_michael_porter_6.png
como la base para la comunicacin, mejoras o innovacin y define los requisitos de los sistemas de
informacin que intervienen en la empresa Erikson y Peker (2000).
Un Modelado del Negocio es una descripcin de los elementos que constituyen una organizacin, o una
parte de ella, as como de las relaciones entre estos elementos. Un Modelo del Negocio es una
conceptualizacin de una empresa u organizacin, es la caracterizacin de los aspectos ms significativos
de la empresa o de una parte de ella, para ello se debe tener claro cul es el fin que se busca con ese
modelo, para as tener claro los elementos del negocio que se deseen representar.
Modelado de Negocios e Ingeniera de Requisitos
El Modelado de Negocios y la Ingeniera de Requisitos son los dos procesos tcnicos iniciales del desarrollo
ingenieril de aplicaciones de software. El Modelado de Negocios se realiza en el espacio del problema; se
encarga de estudiar el dominio de la aplicacin con la finalidad de formular y analizar el problema que da
origen a la aplicacin. La Ingeniera de Requisitos, por su parte, ocurre en el espacio de la solucin; se
encarga, por lo tanto, de caracterizar la aplicacin en base a las necesidades y los requisitos que los usuarios
de la aplicacin tienen.
El proceso de ingeniera de requerimientos se utiliza para definir todas las actividades involucradas en el
descubrimiento, documentacin y mantenimiento de los requerimientos para un producto de software
determinado, donde es muy importante tomar en cuenta la viabilidad de llevar a cabo el software (si es
factible llevarlo a cabo o no), pasando posteriormente por un subproceso de obtencin y anlisis de
requerimientos, su especificacin formal, para finalizar con el subproceso de validacin donde se verifica
que los requerimientos realmente definen el sistema que quiere el cliente.
En el desarrollo de software, el Modelado de Negocios aporta informacin esencial para la Ingeniera de
Requisitos, ya que en el modelado de negocio se ve lo que es el problema y en la ingeniera de requisitos se
define la solucin al problema.
Cadena de Valor
La cadena de valor es esencialmente una forma de anlisis de la
actividad empresarial mediante la cual descomponemos una
empresa en sus partes constitutivas, buscando identificar fuentes de ventaja competitiva en aquellas
actividades generadoras de valor. La cadena de valor representa todas las actividades que se llevan a cabo en
una empresa, en la cual se realiza una separacin entre las actividades de mayor inters (actividades
primarias) y las actividades que le sirven de apoyo con la finalidad de prestar mayor atencin y centrarse en
aquellas actividades que generan mayores ventajas al momento de competir con otras empresas.
20
Como se menciono anteriormente la cadena de valor se divide en actividades primarias y secundarias
Actividades primarias: Conforman la creacin fsica del producto, las actividades relacionadas con
su venta y la asistencia post-venta.
Se dividen en:
Logstica interna
Operaciones
Logstica externa
36 de 39
Ventas y marketing: actividades con las cuales se da a conocer el producto.
Servicios post-venta (mantenimiento): actividades destinadas a mantener o realizar el valor del producto.
Actividades secundarias o de apoyo, estn conformadas por:
Infraestructura de la organizacin
Direccin de recursos humanos: bsqueda, contratacin y motivacin del personal.
Desarrollo de tecnologa (investigacin y desarrollo)
Abastecimiento o compras
La cadena de valor es una herramienta de gran importancia ya que permite determinar cuales son aquellas
actividades de valor de la empresa. Es muy til que las empresas conozcan no solo su cadena de valor si no
tambin la de sus competidores, ya que esta proporciona un mejor anlisis interno de la organizacin, as
como tambin identificar las ventajas competitivas y comprender de una mejor manera el comportamiento
de los costos y las diversas fuentes de diferenciacin con la competencia.
Conclusiones
Una metodologa se basa en una combinacin de los modelos de proceso genricos para obtener como
beneficio un software que soluciones un problema
La trascendencia de las metodologas se ha hecho notoria, pasando de solo programar, establecer
funciones en etapas o mdulos, objetos, y por ltimo agilizar el desarrollo del software y minimizar
los costos.
En el desarrollo convencional todo el programa est en un solo bloque, con ejecucin secuencial de
instrucciones
En el desarrollo estructurado los programas estn divididos en distintos bloques, estos bloques tienen
funciones que se van confeccionado en forma de arriba-abajo, empezando desde las generales hasta
las particulares, hasta llegar a detallar cada uno de los procedimientos y su interaccin.
El desarrollo orientado a objetos comprende dividir un programa en clases, donde estas clases estarn
estructuradas por propiedades, atributos, variables, pretendiendo simular y describir de manera
conceptual a un objeto.
Los mtodos giles fueron pensados especialmente para equipos de desarrollo pequeos, con plazos
reducidos, requisitos voltiles y nuevas tecnologas.
El modelado de negocio describe como desarrollar una visin de la nueva organizacin, basado en
esta visin se definen procesos, roles y responsabilidades de la organizacin por medio de un Modelo
de Casos de Uso del Negocio
Los modelos de procesos permiten al analista de sistemas desarrollar un plan de requisitos del
software, permiten establecer un trabajo en forma ordenada, adems que existen muchos modelos que
se adaptan a las exigencias del proyecto, solo debemos saber cual nos conviene.
37 de 39
Referencias
1. Alonso, F. y Martnez, L. (2005). Introduccin a la ingeniera del software: modelos de desarrollo de
programas (primera edicin). Espaa: Delta Publicaciones. Pg. 75-76
2. Sommerville, I. (2005). Ingeniera del software (Sptima Edicin). Espaa: Pearson Educacin.
3. Hernn, M. (2004). Diseo de una Metodologa gil de Desarrollo de Software. Tesis de Grado de
Ingeniera en Informtica. Universidad de Buenos Aires. Pg. 11-12
4. Sommerville, I. (2006). Ingeniera del software (Sptima Edicin). Madrid. Pg. 62
5. Espinoza, A. Metodologas de desarrollo de software [documento en lnea].Disponible en:
www.slideshare.net/juliopari/4-clase-metodologia-de-desarrolo-de-software [consulta: 11 de junio de
2012]
6. Carballar, D. Ingeniera de software [documento en lnea]. www.eduinnova.es/dic09
/Ingenieria_Software.pdf [consulta: 10 de junio de 2012]
7.Disponible en la web: www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#paradigmaOO
[consulta: 10 de junio de 2012]
8. Kenneth, E. y Kendall, J. (2005). Analisis Y Diseo de Sistemas(Sexta edicin). Mxico.
9. Sols, M. (2003). Una explicacin de la programacin extrema (XP). Madrid. Pg. 103
10. Ordonez (2011). Metodo de Desarrollo de sistemas dinamicos[documento en lnea]. Disponible
en: www.slideshare.net/oscarfico/metodos-dinamicos [consulta: 8 de junio de 2012]
11. Citn, M.(2006). Mtodo gil scrum aplicado al desarrollo de un software de trazabilidad. Argentina.
12. Amaro , S. y Valverde, J. (2007). Metodologas giles. Per:Trujillo.
13. Mendez, E. (2006). Modelo de Evaluacion de Metodologia para el Desarrollo de Software. Trabajo de
Grado, Universidad Catlica Andrs Bello,Caracas,Vzla.
14. Cans J. y Letelier P. (2003, noviembre). Metodologas giles en el desarrollo de software [resumen].
Taller realizado en el marco de las VIII jornadas de Ingeniera del software y bases de datos en la
Universidad politcnica de Valencia, Espaa-Alicante.
15. Laboratorio Nacional de Calidad del Software de INTECO. (2009, Marzo) Ingeniera del software:
metodologas y ciclos de vida. Espaa.
16. Oscar lvarez Imaz. (2008, Abril). "Introduccin a RUP" Versin 0.1
17. Alonso, F. y Martnez, L. (2005). Introduccin a la ingeniera del software: modelos de desarrollo de
programas (primera edicin). Espaa: Delta Publicaciones. Pg. 112-113
18. Disponible en la web: www.laprole431.blogspot.com/2010/12/que-es-un-modelo-de-desarrollo.html
[consulta: 6 de julio de 2012]
19. Disponible en la web: www.ingenieraupoliana.blogspot.com/2010/10/modelo-de-desarrollo-
concurrente.html [consulta: 6 de julio de 2012]
20. David, F. (2008). Conceptos de Administration Estratgica (Decimoprimera Edicin). Editorial Pearson
38 de 39
39 de 39