Beruflich Dokumente
Kultur Dokumente
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)
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
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.
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 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
Ao 2000 en adelante
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, 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.
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.
Representa los procesos, flujos y estructuras de datos, de una manera jerrquica y descendente.
Aunque este desarrollo permite disear un buen proceso y estructura de un programa, tiene inconvenientes
como:
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.
Encapsulacin: En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus
caractersticas esenciales.
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.
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.
Existencia de reglas predefinidas, fases y subfases, tareas, productos intermedios, tcnicas y herramientas tales que
se amolden a cualquier desarrollo.
Verificaciones intermedias.
Planificacin y control.
Comunicacin efectiva.
Fcil formacin.
Herramientas case.
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.
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:
Una metodologa define una estrategia global para enfrentarse con el proyecto. Entre los elementos que forman
parte de una metodologa se pueden destacar:
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:
Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar, entre otros.
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.
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 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.
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 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.
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:
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.
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
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.
Tareas.
Productos de trabajo.
Aseguramiento de la calidad.
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 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.
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 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.
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.
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
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.
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 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.
Construccin de prototipos
Modelos en espiral
Plan rpido.
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.
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.
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.
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.
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.
A medida que se va incrementando el nmero de iteraciones, se producen versiones cada vez mas
completas.
Ventajas:
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.
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).
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 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.
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.
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.
Desventajas:
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:
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:
Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que simplemente no
estarn dispuestos a invertir el tiempo necesario.
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
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 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.
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.
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.
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.
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.
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
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
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.
Iteracin de modelo funcional: produce una serie de prototipos incremntales que demuestran la 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
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.
Puede ser aplicado tericamente a cualquier contexto en donde un grupo de gente necesita trabajar junta para
lograr una meta comn.
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?
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.
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
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 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
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
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.
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.
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.
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.
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
Metodologas convencionales:
Impuestas externamente.
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.
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.
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.
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.
Concurrencia.
Priorizacin de procesos.
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.
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.
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.
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.
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 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.
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
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
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.
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.
10.- 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.
11.- 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
www.eduinnova.es/dic09/Ingenieria_Software.pdf [consulta: 10 de junio de 2012]
en
lnea].
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-desarrolloconcurrente.html [consulta: 6 de julio de 2012]
20. David, F. (2008). Conceptos de Administration Estratgica (Decimoprimera Edicin). Editorial Pearson
Educacin, Mxico.
21. Disponible en la web: www.aprendecomputofacil.blogspot.com/2009_07_01_archive.html [consulta: 10
de julio de 2012]