Metodologas para el desarrollo de software Saltar a navegacin, buscar UNIDAD VI. Asignatura: 071-4 !

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 soft are cuando se habla de desarrollo de soft are se habla de desarrollo de programas y por lo tanto se considera como una tarea de ingeniera, en el cu!l se debe ejecutar una serie de fases, etapas para obtener un programa "ue funcione de acuerdo con mtodos ya establecidos en otras disciplinas de ingeniera.# $as actividades "ue los ingenieros de soft are reali%an se encuentran asociadas a un proceso de soft are donde intervienen diferentes elementos &fases, actividades, producto, roles, agentes' "ue permiten la definicin del soft are a producir &producto', el desarrollo o el diseo del soft are, la validacin del soft are tanto lo interno&re"uerimientos especficos'como lo e(terno&e(pectativas del cliente', y la evolucin del soft are donde se modifica para adaptarlo a los cambios.) *or otro lado, Sommerville &)++)' define "ue ,un mtodo de ingeniera de soft are es un enfo"ue estructurado para el desarrollo de soft are cuyo propsito es facilitar la produccin de soft are de alta calidad de una forma costeable-, cabe destacar "ue para usar este enfo"ue se debe manejar conceptos fundamentales tales como. procesos, mtodos, tareas, procedimientos, tcnicas, herramientas, productos, entre otros. *articularmente, una metodologa se basa en una combinacin de los modelos de proceso genricos para obtener como beneficio un soft are "ue soluciones un problema. /dicionalmente una metodologa debera definir con precisin los artefactos, roles y actividades, junto con pr!cticas, tcnicas recomendadas y guas de adaptacin de la metodologa al proyecto. Sin embargo, la complejidad del proceso de creacin de soft are es netamente dependiente de la naturale%a del proyecto mismo, por lo "ue el escogimiento de la metodologa estar! acorde al nivel de aporte del proyecto, ya sea pe"ueo, mediano o de gran nivel. 0ontenido 1ocultar2 # Evolucin histrica de las metodologas de desarrollo de soft are ) 3eneraciones de metodologas ).# 4esarrollo 0onvencional ).) 4esarrollo Estructurado ).5 4esarrollo 6rientado a 6bjetos 5 0aractersticas deseables de una metodologa 7 8etodologas 9s. 0iclo de vida : 8odelos de procesos en el desarrollo de soft are ; 0lasificacin de las 8etodologas seg<n el modelo de proceso ;.# 8odelos 0onvencionales o *rescriptivos de *rocesos ;.#.# 8odelo en 0ascada ;.#.) 8odelo de *rocesos Incrementables ;.#.5 8odelo de desarrollo r!pido de aplicaciones &4=/' ;.#.7 8odelos Evolutivos ;.#.7.# 0onstruccin de *rototipos ;.#.7.) 8odelo en Espiral ;.#.7.5 8odelo de desarrollo concurrente ;.#.: 8odelos iterativos ;.) 8odelos de 4esarrollo >giles

;.).# *rogramacin E(trema &?*' ;.).) 4esarrollo /daptativo del Soft are &4/S' ;.).5 8odelo de 4esarrollo de Sistemas 4in!micos &84S4' ;.).7 8odelo Scrum ;.).: 4esarrollo conducido por caractersticas &400' ;.).; *roceso @nificado de =ational &=@*' ;.5 4iferencias entre los modelos de proceso convencionales y !giles A 0lasificacin de las metodologas seg<n su enfo"ue A.# 8etodologas estructuradas A.#.# 8etodologas orientadas a procesos A.#.) 8etodologas orientadas a datos A.) 8etodologas para sistemas de tiempo real A.5 8etodologas 6rientadas a 6bjetos B CDue metodologa es conveniente usarE F 8odelos de procesos utili%ados en el desarrollo de soft are F.# 8odelado de Gegocios F.) 8odelado de Gegocios e Ingeniera de =e"uisitos F.5 0adena de 9alor #+ 0onclusiones ## =eferencias "#olu$i%n &ist%ri$a de las 'etodologas de desarrollo de software 4esde "ue se empe% a trabajar sobre el desarrollo de programas, se siguieron ciertos mtodos "ue 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 ;+ y consista en codificar y corregir &0odeHandHIi(', si al terminar se descubra "ue el diseo era incorrecto, la solucin era desecharlo y volver a empe%ar 5, este modelo implementaba el cdigo y luego se pensaba en los re"uisitos, diseo, validacin y mantenimiento. los principales problemas del modelo de procesos sonJ $os arreglos se hacen costosos, despus de tantas correcciones el cdigo tenia una mala estructura. El soft are no se ajusta a las necesidades del usuario, por lo "ue es recha%ado 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 empe% a tomar la importancia de los datos, y para solucionar sistemas complejos empe% el an!lisis 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 an!lisis, diseo, pruebas y mantenimientos. $a dcada de los ochenta es la poca marcada por las metodologas dirigida a datos cuya importancia va tomando cuerpo en las organi%aciones. Se empie%an a estudiar los objetos en s como unidades de informacin. *ara los aos F+ se "uiere dar respuesta al entorno siempre cambiante y en r!pida evolucin en "ue se han de desarrollar los programas inform!ticos, lo cual da lugar a trabajar en ciclos cortos &como miniH proyectos' "ue implementan una parte de las funcionalidades, pero sin perder el rumbo general del proyecto global. *or otra parte las metodologas de desarrollo comien%an a interesarse no slo en lograr "ue el proyecto sea puesto en funcionamiento sino en minimi%ar costos durante su desarrollo y sobre todo durante su mantenimiento. $os nuevos mtodos van buscando minimi%ar riesgos y, puesto "ue los errores m!s perjudiciales se producen en los

primeros pasos, se comien%a ya desde la fase m!s general del estudio por anali%ar los riesgos "ue significa seguir con las siguientes fases del desarrollo. $as metodologas m!s utili%adas a nivel mundial en orden cronolgicoJ#5 D($ada de los 70s *rogramacin Estructurada KacLson desde #FA: D($ada de los )0s Structured Systems /nalysis and 4esign 8ethodology &SS/48' desde #FB+ Structured /nalysis and 4esign Mechni"ue &S/4M' desde #FB+ Ingeniera de la Informacin &IENIE8' desde #FB# D($ada de los *0s =apid /pplication 4evelopment &=/4' desde #FF#. *rogramacin 6rientada a 6bjetos &66*' a lo largo de la dcada de los F+Os 9irtual Iinite State 8achine &9IS8' desde #FF+s 4ynamic Systems 4evelopment 8ethod desarrollado en @P desde #FF:. =ational @nified *rocess &=@*' desde #FFF A+o !000 en adelante E(treme *rogramming &?*' desde #FFF Enterprise @nified *rocess &E@*' e(tensiones =@* desde )++) 0onstructionist 4esign 8ethodology &048' desde )++7 por Pristinn =. Mhrisson /gile @nified *rocess &/@*' desde )++: por Scott /mbler 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. stos cambios de paradigma han logrado las mejoras para desarrollar software y aunque principalmente buscar acortar el tiempo de solucin sin reprochar los recursos disponibles. ,enera$iones de 'etodologas $as metodologas han ido cambiando con el tiempo, al surgir nuevos paradigmas "ue rompe con lo tradicional para abrir paso a nuevas tcnicas de solucin.:Qan evolucionando a lo largo del tiempo estas herramientas, inicialmente el periodo de desarrollo convencional &practicas artesanales', luego surge el 4esarrollo estructurada &parte de la programacin estructurada seguido de los mtodo de an!lisis y diseo, cubre todo el ciclo de vida completo'. /ctualmente aparece el paradigma de la orientacin a objetos. Desarrollo -on#en$ional En los aos :+ el desarrollo estaba a cargo de programadores, por lo "ue se vio la importancia del an!lisis y diseo en el desarrollo de los sistemas. /parecen los analistas programadores y analistas de sistemas.; En esta misma poca, no e(istan metodologas de desarrollo. $as personas "ue desarrollaban los sistemas eran programadores m!s enfocados en la tarea de codificar, "ue en la de recoger y comprender las necesidades de los usuarios. Estos, a menudo, no "uedaban satisfechos con el sistema, por"ue sus necesidades no estaban definidas con claridad en una fase de an!lisis previo. /nte esta perspectiva se vio la importancia del an!lisis y del diseo en el desarrollo de un sistema. /hora se empie%a a hablar de analistas programadores y analistas de sistemas. Qasta hace relativamente poco tiempo cuando se hablaba de ,desarrollo- se aluda <nicamente al crecimiento econmico dando por supuesto "ue dicho crecimiento se revierte de manera casi autom!tica en los otros sectores de la estructura social. $as

estrategias de desarrollo se han concentrado fundamentalmente en estrategias econmicas, "ue aun"ue incorporan elementos de otros sectores Rpor ejemplo del sector socialH, buscan como objetivo fundamental el crecimiento econmico. *or 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 siguientesJ $os resultados finales son impredecibles, es decir no se sabe cu!ndo debe acabar un proyecto. Go hay forma de controlar lo "ue est! sucediendo en el proyecto, al no e(istir fases establecidas y productos intermedios sobre los "ue reali%ar verificaciones. $os cambios organi%ativos afectan negativamente al proceso de desarrollo, no suele e(istir documentacin estandari%ada o no se actuali%an oportunamente. n el desarrollo con!encional todo el programa est en un solo bloque, con ejecucin secuencial de instrucciones. ran los tiempos del ensamblador, las capacidades reducidas y la necesidad de optimizar al m"imo. #e 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 pre!er donde se encontraban. Desarrollo "stru$turado El desarrollo estru$turado comen% con la programacin. / mediados de los ;+ el enfo"ue estructurado se e(tiende a la fase de diseo "ue se conoce como diseo estructurado, el cual se basa en definir una abstraccin m!s amplia usando los mdulos de programa como componentes b!sicos de construccin. / mediados de los A+, se empe%aron a surgir las tcnicas estructuradas, donde se empe% 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. En el diseo estructurado se caracteri%a por lo siguienteJ 8ayor nivel de abstraccin &independencia del lenguaje programacin'. HElemento b!sico de diseoJ mdulo. 8odularidad "ue permite medir la calidad de programas. =epresenta los procesos, flujos y estructuras de datos, de una manera jer!r"uica y descendente. 9en el sistema como entradasHprocesoHsalidas. Se concentran el la parte del proceso. Se lee de porciones, independientes de las especificaciones. /un"ue este desarrollo permite disear un buen proceso y estructura de un programa, tiene inconvenientes comoJ $eer todas las especificaciones para entender el problema. Se repeta la misma informacin en partes diferentes del documento. El enfo"ue de re"uisitos se interpretaba diferente por cada usuario. 0uando se finali%aba el proceso de desarrollo las especificaciones eran obsoletas. Este enfo"ue se conoce como an!lisis estructurado o an!lisis descendente o top - down. 4esde 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 m!s los modelos fsicos y lgicos. /mpliar las tcnicas de an!lisis estructurado, para modelar sistemas en tiempo real y enfocarse en el modelo de datos.

n el desarrollo estructurado los programas estn di!ididos en distintos bloques, estos bloques tienen funciones que se !an 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. ste desarrollo se enfoca al dise%o del programa y la compresin se hace mas fcil. #e ha hecho e!idente 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 !ida debe recorrerse completo y al manejarse de esta manera, trae como consecuencias informacin redundante, costos y desperdicio de tiempo. Desarrollo .rientado a ./0etos El desarrollo del paradigma de 6rientado a 6bjetos &66' trata los procesos y datos de forma conjunta. Este comien%a a mediados de los B+ con los lenguajes de programacin 6rienta a 6bjetos en los "ue se daba nfasis a la abstraccin de datos para los "ue se adjuntaba un conjunto de operaciones. *or otra parte los conceptos de tcnicas estructuradas han servido de base para muchas de las metodolgicas 66.; $a orientacin a objetos empie%a 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 "ue se adjuntan un conjunto de operaciones. EjJ 0SS, Kava. En la metodologa orientada a objetos el sistema se organi%a como una coleccin de objetos "ue interact<an entre s y "ue 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 est!n relacionadas de forma dbil, ya "ue estos se enfocan principalmente a las funciones. $os principios del modelo 66 sonJA A/stra$$i%nJ Es una descripcin simplificada o especificacin de un sistema "ue enfati%a algunos de los detalles o propiedades del sistema, mientras suprime otros. "n$apsula$i%nJ En el proceso de ocultar todos los detalles de un objeto "ue no contribuyen a sus caractersticas esenciales. ModularidadJ Es la propiedad de un sistema "ue ha sido descompuesto en un conjunto de mdulos coherentes e independientes. 1erar2ua o &eren$iaJ Es el orden de las abstracciones organi%ado por niveles. 3ipifi$a$i%nJ Es la definicin precisa de un objeto de tal forma "ue objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida. -on$urren$iaJ Es la propiedad "ue distingue un objeto "ue est! activo de uno "ue no lo est!. 4ersisten$iaJ Es la propiedad de un objeto a travs de la cual su e(istencia trasciende el tiempo &es decir, el objeto continua e(istiendo despus de "ue su creador ha dejado de e(istir' yNo el espacio &es decir, la locali%acin del objeto se mueve del espacio de direccin en "ue fue creado'. Tooch &#FB;' dice "ue ,si un modelo "ue se dice 66 no contiene alguno de los primeros cuatro elementos, entonces no es 6rientado a 6bjetos-. l desarrollo orientado a objetos comprende di!idir un programa en clases, donde estas clases estarn estructuradas por propiedades, atributos, !ariables, 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 !entaja de

que se e!ite interferencias e"tra%as entre distintas partes del programa y podemos cambiar la implementacin concreta de un objeto sin afectar al resto del sistema. &ctualmente 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 !er las cosas como un objeto, es decir, realmente como son y como se comportan. -ara$tersti$as desea/les de una 'etodologa E(istencia de reglas predefinidas, fases y subfases, tareas, productos intermedios, tcnicas y herramientas tales "ue se amolden a cual"uier desarrollo. 0obertura total del ciclo de desarrollo. 9erificaciones intermedias. *lanificacin y control. 0omunicacin efectiva. @tili%acin sobre un abanico amplio de proyectos. I!cil formacin. Qerramientas case. $a metodologa debe contener actividades "ue mejoren el proceso de desarrollo. Soporte al mantenimiento. *or ejemplo. =eingeniera. Soporte de la reutili%acin de soft are, no solo reutili%acin de cdigo. /ctualmente, se huye de mtodos muy burocr!ticos o monolticos. Lo que se quiere de una metodologa es que permita definir las etapas, las salidas, entradas de un proyecto. 'antener 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. -i$lo de #ida

@na 'etodologa es un conjunto integrado de tcnicas y mtodos "ue permite abordar de forma homognea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. @na definicin est!ndar de metodologa puede ser el conjunto de mtodos "ue se utili%an en una determinada actividad con el fin de formali%arla y optimi%arla. 4etermina los pasos a seguir y cmo reali%arlos para finali%ar una tarea.#: Si esto se aplica a la Ingeniera de soft are, podemos destacar "ue una metodologaJ 6ptimi%a el proceso y el producto soft are. Es una gua en la planificacin y en el desarrollo del soft are. 4efine "u hacer, cmo y cu!ndo durante todo el desarrollo y mantenimiento de un proyecto. @na metodologa define una estrategia global para enfrentarse con el proyecto. Entre los elementos "ue forman parte de una metodologa se pueden destacarJ IasesJ tareas a reali%ar en cada fase. *roductosJ ENS de cada fase, documentos. *rocedimientos y herramientasJ apoyo a la reali%acin de cada tarea. 0riterios de evaluacinJ del proceso y del producto. Saber si se han logrado los objetivos. El $i$lo de #ida es el conjunto de fases por las "ue pasa el sistema "ue se est! desarrollando desde "ue nace la idea inicial hasta "ue el soft are es retirado o rempla%ado &muere'. Entre las funciones "ue debe tener un ciclo de vida se pueden destacarJ 4eterminar el orden de las fases del proceso de soft are. Establecer los criterios de transicin para pasar de una fase a la siguiente. 4efinir las entradas y salidas de cada fase. 4escribir los estados por los "ue pasa el producto. 4escribir las actividades a reali%ar para transformar el producto. 4efinir un es"uema "ue sirve como base para planificar, organi%ar, coordinar, desarrollar, entre otros. $as etapas de un $i$lo de #ida de un soft are sonJ Ini$io: ste es el nacimiento de la idea. /"u definimos los objetivos del proyecto y los recursos necesarios para su ejecucin. Qacia dnde "ueremos ir, y no cmo "ueremos ir. $as caractersticas implcitas o e(plcitas de cada proyecto hacen necesaria una etapa previa destinada a obtener el objetivo por el cual se escribir!n miles o cientos de miles de lneas de cdigo. @n alto porcentaje del (ito de nuestro proyecto se definir! en estas etapas "ue, al igual "ue la etapa de debugging, muchos lderes de proyecto subestiman. 4lanifi$a$i%n: idearemos un planeamiento detallado "ue gue la gestin del proyecto, temporal y econmicamente. I'ple'enta$i%n: acordaremos el conjunto de actividades "ue componen la reali%acin del producto. 4uesta en produ$$i%n: nuestro proyecto entra en la etapa de definicin, all donde se lo presentamos al cliente o usuario final, sabiendo "ue funciona correctamente y responde a los re"uerimientos 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 m<ltiples dificultades "ue suele presentar en la pr!ctica, alarg!ndose e(cesivamente y provocando costos no previstos. -ontrol en produ$$i%n: control del producto, anali%ando cmo el proceso difiere o no de los re"uerimientos originales e iniciando las acciones correctivas si fuesen necesarias. 0uando decimos "ue hay "ue corregir el producto, hacemos

referencia a pe"ueas desviaciones de los re"uerimientos originales "ue puedan llegar a surgir en el ambiente productivo. Si nuestro programa no reali%a la tarea para lo cual fue creada, esta etapa no es la adecuada para el rediseo. Incluimos tambin en esta etapa el lidera%go, documentacin y capacitacin, proporcionando directivas a los recursos humanos, para "ue hagan su trabajo en forma correcta y efectiva. ./0eti#os de $ada etapa: "5presi%n de ne$esidadesJEsta etapa tiene como objetivo el armado de un documento en el cual se reflejan los re"uerimientos y funcionalidades "ue ofrecer! al usuario el sistema a implementar &"u, y no cmo, se va a implementar'. "spe$ifi$a$ionesJ Iormali%amos los re"uerimientos. el documento obtenido en la etapa anterior se tomar! como punto de partida para esta etapa. An6lisisJ 4eterminamos los elementos "ue intervienen en el sistema a desarrollar, su estructura, relaciones, evolucin temporal, funcionalidades, tendremos una descripcin clara de "u producto vamos a construir, "u funcionalidades aportar! y "u comportamiento tendr!. Dise+oJ Ua sabemos "u hacer, ahora tenemos "ue determinar cmo debemos hacerlo &Ccmo debe ser construido el sistema en cuestinE'. definimos en detalle entidades y relaciones de las bases de datos, seleccionamos el lenguaje "ue vamos a utili%ar, el Sistema 3estor de Tases de 4atos, entre otros'. I'ple'enta$i%nJ Empe%amos 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 "ue adoptan un modelo de ciclo de vida de code V fi( &codificar y corregir' donde se eliminan las etapas de especificaciones, an!lisis y diseo con la consiguiente prdida de control sobre la gestin del proyecto. De/ugging 7Depura$i%n8J El objetivo de esta etapa es garanti%ar "ue nuestro programa no contiene errores de diseo o codificacin. En esta etapa no deseamos saber si nuestro programa reali%a lo "ue solicit el usuario, esa tarea le corresponde a la etapa de implementacin. En sta deseamos encontrar la mayor cantidad de errores. Modas los programas contienen erroresJ encontrarlos es cuestin de tiempo. $o ideal es encontrar la mayora, si no todos, en esta etapa. Mambin se pueden agregar pruebas de rendimiento. Valida$i%nJ Esta etapa tiene como objetivo la verificacin de "ue el sistema desarrollado cumple con los re"uerimientos e(presados inicialmente por el cliente y "ue han dado lugar al presente proyecto. En muchos proyectos las etapas de validacin y debugging se reali%an en paralelo por la estrecha relacin "ue llevan. Sin embargo, tenemos "ue evitar la confusinJ podemos reali%arlos en paralelo, pero no como una <nica etapa. "#olu$i%nJ En la mayora de los proyectos se considera esta etapa como 8antenimiento y evolucin, y se le asigna, no slo el agregado de nuevas funcionalidades &evolucin'. sino la correccin de errores "ue surgen &mantenimiento'. En la pr!ctica esta denominacin no es del todo errnea, ya "ue es posible "ue aun luego de una etapa de debugging y validacin e(haustiva, se filtren errores. (na metodologa puede seguir uno o !arios modelos de ciclo de !ida, adaptndose a cada uno de ellos, dependiendo de las necesidades dadas en un momento determinado,

es decir, el ciclo de !ida 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. n s para el desarrollo de software, se necesita aplicar una metodologa o !arias metodologas, dentro de un ciclo de !ida, de manera que sepamos que hacer y como hacerlo para conseguir lo que se quiere y cumplir con las metas planteadas. Modelos de pro$esos en el desarrollo de software @n modelo de proceso para el desarrollo de soft are es una representacin simplificada de pasos, representada desde una perspectiva especfica. *or su naturale%a los modelos son simplificados, por lo tanto un modelo de procesos del soft are es una abstraccin de un proceso real.

Estos modelos tienen como propsito la produccin efica% y eficiente de un producto soft are "ue re<na los re"uisitos del cliente. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas.$a mayora de los modelos de procesos de desarrollo del soft are son dirigidos por el tiempo. cuanto m!s tarde sea, m!s atr!s se encontrar! en el proceso de desarrollo. 0omo todo proceso, est!n constituido de pasos o fases "ue contienen a su ve% actividades, estos modelos de desarrollo de soft are se basan en un ciclo de vida para desarrollar el mismo, como lo sonJ $a necesidad de solucionar un problema &surgimiento de necesidades' Inicio del proceso &desarrollo', dentro de esta fase se encuentra la definicin del proyecto, el an!lisis del conte(to, definicin de re"uerimientos, diseo del sistema, construccin del sistema, pruebas e implantacin. 6peracin y mantenimiento, donde reali%a ajustes y se buscan fallas. =enovacin o e(tincin. $os procesos de soft are son complejos debido a "ue un producto de soft are es intangible y por lo general muy abstracto, esto dificulta la definicin del producto y sus re"uisitos, sobre todo cuando no se tiene precedentes en productos soft are similares. En general este producto esta compuesto por hard are y soft are. En cuanto al hard are, su produccin se reali%a sistem!ticamente y la base de conocimiento para el

desarrollo de dicha actividad est! claramente definida. =especto del soft are, 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 e"isten muchos modelos que se adaptan a las e"igencias del proyecto, solo debemos saber cual nos con!iene, pero lo mas importante, es que estos modelos nos lle!an a presentar los proyectos al cliente de manera que )ste !ea su dise%o y sus funciones y que la mayora de ellos estn orientados al mantenimiento. -lasifi$a$i%n de las Metodologas seg9n el 'odelo de pro$eso Modelos -on#en$ionales o 4res$ripti#os de 4ro$esos $os 'odelos $on#en$ionales o modelos prescriptivos de procesos permiten llenar el marco de trabajo con un conjunto de tareas orientadas al desarrollo de un soft are. Se les llama WprescriptivosW por"ue presciben un conjunto de elementos del proceso, tales comoJ /ctividades del 8arco de Mrabajo. /cciones de la Ingeniera del soft are. Mareas. *roductos de trabajo. /seguramiento de la calidad. 8ecanismos de control del cambio para cada proyecto. Estos modelos son <tiles si "ueremos describir un conjunto <nico de actividades dentro de un marco de trabajo para un proceso de soft are. cada actividad debe contener un conjunto de acciones de ingeniera del soft are, y definir cada accin en cuanto a un conjunto de tareas "ue identifi"ue el trabajo &y los productos del trabajo' "ue deben completarse para alcan%ar las metas de desarrollo. Sin importar el modelo del proceso "ue se desee usar, los ingenieros de soft are eligen una manera tradicional para reali%ar el marco de trabajo genrico para el proceso, ya "ue estos modelos se caracteri%an por ser en esencia rgidos,estrictos y los mas utili%ados.

En las metodologas convencionales, el ciclo de vida de un proyecto, puede definirse como un ciclo de vida lineal, ya "ue imponen una disciplina de trabajo sobre el proceso de desarrollo del soft are, con el fin de conseguir un soft are m!s eficiente. *ara ello, se hace nfasis en la planificacin total de todo el trabajo a reali%ar y una ve% "ue est! todo detallado, comien%a el ciclo de desarrollo del producto soft are. 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. /dem!s, las metodologas tradicionales no se adaptan adecuadamente a los cambios, por lo "ue no son mtodos adecuados cuando se trabaja en un entorno, donde los re"uisitos no pueden predecirse o bien pueden variar.

Los modelos prescripti!os de proceso definen un conjunto distinto de acti!idades, 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 despu)s lo siguen. &dems, la gente que ha solicitado el software tiene un papel por desempe%ar se ejecuta el modelo de software. *+or qu) es importante, +orque proporciona estabilidad, control y organizacin a una acti!idad que si no se controla puede !ol!erse catica. *-ules son los pasos, l proceso conduce a un equipo de software a tra!)s de un conjunto de acti!idades del marco de trabajo que se organizan en un flujo de proceso. *-ul es un obtenido, .esde punto de !ista de un ingeniero de software, los productos de trabajo son los programas, documentos y datos que se producen como consecuencia de las acti!idades y tareas que define el proceso. Modelo en -as$ada

El 'odelo en $as$ada, algunas veces llamado el ciclo de vida cl!sico, sugiere un enfo"ue sistem!tico, secuencial hacia el desarrollo del soft are, "ue se inicia con la especificacin de re"uerimientos del cliente y "ue contin<a con la planeacin, el modelado, la construccin y el despliegue para culminar en el soporte del soft are terminado. Este modelo es aplicable en donde e(isten ocasiones en "ue los re"uisitos de un problema se entienden de una manera ra%onable 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 e(istente. El modelo en cascada es el paradigma m!s antiguo para la ingeniera del soft are. Sin embargo, en las dcadas pasadas, las criticas a este modelo de proceso han ocasionado "ue aun sus m!s fervientes practicantes hayan cuestionado su eficacia. Entre los problemas "ue algunas veces se encuentran al aplicar el modelo en cascada est!nJ #. Es muy raro "ue los proyectos reales sigan el flujo secuencial "ue propone el modelo. / pesar de "ue el modelo lineal incluye iteraciones, lo hace de manera indirecta. 0omo resultado, los cambios confunden mientras el e"uipo de proyecto act<a. ). 0on frecuencia es difcil para el cliente establecer todos los re"uisitos de manera e(plcita. El modelo en cascada lo re"uiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. 5. El cliente debe tener paciencia. @na versin "ue funcione de los programas estar! disponible cuando el proyecto est muy avan%ado. @n error grave ser! desastroso si no se detecta antes de la revisin del programa.

En un an!lisis interesante de proyectos reales, Tradac&#FF7' concluy "ue la naturale%a lineal del modelo en cascada conduce a Westados de blo"ueoW en los cuales algunos miembros del e"uipo del proyecto deben esperar a otros para terminar tareas dependientes. 4e hecho, el tiempo de espera puede superar el "ue se aplica en el trabajo productivo. El estado de blo"ueo tiende a ser m!s com<n al principio y al final del proceso secuencial. En la actualidad, el trabajo del soft are est! acelerado y sujeto a una cadena infinita de cambios &de caractersticas, funciones y contenido de la informacin'. 0on 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 re"uerimientos est!n fijos y donde el trabajo se reali%a, hasta su conclusin, de una manera lineal. $as principales etapas de este modelo seg<n Sommerville &)++:' sonJ An6lisis : defini$i%n de re2ueri'ientos. $os servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Se define una especificacin del sistema. Dise+o del siste'a : del software. El proceso de diseo del sistema divide los re"uerimientos en sistemas hard are o soft are. Establece una ar"uitectura completa del sistema. El diseo del soft are identifica y describe las abstracciones fundamentales del sistema soft are y sus relaciones. I'ple'enta$i%n : prue/a de unidades. 4urante esta etapa, el diseo del soft are se lleva a cabo como un conjunto o unidades de programas. Integra$i%n : prue/a del siste'a. $os programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar "ue se cumplan los re"uerimientos del soft are. ;un$iona'iento : 'anteni'iento. El sistema se instala y se pone en funcionamiento pr!ctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida. &lgunas !eces llamado el ciclo de !ida 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. s un enfoque pasado de moda pero til cuando los requisitos son fijos. Modelo de 4ro$esos In$re'enta/les

El 'odelo in$re'ental combina elementos del modelo en cascada aplicado en forma iterativa.El modelo incremental aplica secuencias lineales de manera escalonada conforme avan%a el tiempo en el calendario. 0ada secuencia lineal produce WincrementosW del soft are. *or ejemplo, el soft are procesador de te(to, desarrollado con el paradigma incremental en su primer incremento, podra reali%ar funciones b!sicas de administracin de archivos, edicin y produccin de documentos. en el segundo incremento, ediciones m!s sofisticadas, y tendra funciones m!s complejas de produccin de documentos. en el tercer incremento, funciones de correccin ortogr!fica y gramatical. y en el cuarto, capacidades avan%adas de configuracin de p!gina. Se debe tener en cuenta "ue el flujo del proceso de cual"uier incremento puede incorporar el paradigma de construccin de prototipos "ue se e(pone m!s adelante. / menudo, al utili%ar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los re"uisitos b!sicos, pero muchas caractersticas suplementarias &algunas conocidas, otras no' no se incorporan. El producto esencial "ueda en manos del cliente &o se somete a una evaluacin detallada'. 0omo 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 "ue la construccin de prototipos y otros enfo"ues evolutivos, es iterativo por naturale%a. *ero a diferencia de la construccin de prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. $os primeros incrementos son versiones ,incompletas del producto final, pero proporcionan al usuario la funcionalidad "ue necesita y una plataforma para evaluarlo. El desarrollo incremental es <til sobre todo cuando el personal necesario para una implementacin completa no est! disponible. $os primeros incrementos se pueden implementar con menos gente. Si el producto esencial es bien recibido se agrega &si se re"uiere' m!s personal para implementar el incremento siguiente. /dem!s, los incrementos se pueden planear para manejar los riesgos tcnicos. *or ejemplo, un sistema grande podra re"uerir la disponibilidad de un hard are nuevo "ue est! en desarrollo y cuya fecha de entrega es incierta. Sera posible planear los primeros incrementos de forma "ue se evite el uso de este hard are, lo "ue permitira la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados. -ombina elementos del modelo en cascada aplicado en forma iterati!a. l modelo incremental aplica secuencias lineales de manera escalonada conforme a!anza el tiempo en el calendario. -ada secuencia lineal produce incrementos. +roduce entregas de software peque%as pero usables /incrementos0. -ada parte se construye sobre partes ya entregadas. Modelo de desarrollo r6pido de apli$a$iones 7D<A8

El desarrollo r6pido de apli$a$iones &4=/' es un modelo de proceso de soft are incremental "ue resalta un ciclo de desarrollo corto. El modelo 4=/ es una adaptacin a Walta velocidadW del modelo en cascada en el "ue se logra el desarrollo r!pido mediante un enfo"ue de construccin basado en componentes. Si se entienden bien los re"uisitos y se limita el !mbito del proyecto, el proceso 4=/ permite "ue un e"uipo de desarrollo cree un Wsistema completamente funcionalW dentro de un periodo muy corto &por ejemplo, de ;+ a F+ das'. 0omo otros modelos de proceso, el enfo"ue 4=/ cumple con las actividades genricas del marco de trabajo "ue ya se han presentado. $a comunicacin trabaja para entender el problema de negocios y las caractersticas de informacin "ue debe incluir el soft are. $a planeacin es esencial por"ue varios e"uipos de soft are trabajan en paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases X modelado de negocios, modelado de datos y modelado del proceso X y establece representaciones del diseo "ue sirven como base para la actividad de construccin del modelo 4=/. $a construccin resalta el empleo de componentes de soft are e(istente y la aplicacin de la generacin autom!tica de cdigo. *or <ltimo, el despliegue establece una base para las iteraciones subsecuentes, si stas son necesarias. El modelo de proceso 4=/ se ilustra en la siguiente figura. Es obvio "ue las restricciones de tiempo impuestas sobre un proyecto 4=/ e(igen un W!mbito de escalasW. Si una aplicacin de negocios se puede modular de forma "ue cada gran funcin pueda completarse en menos de tres meses &mediante la aplicacin del enfo"ue ya descrito', sta es una candidata para el 4=/. 0ada gran funcin se puede abordar mediante un e"uipo de 4=/ por separado, para despus integrarlas y formar un todo. 0omo todos los modelos de procesos, el enfo"ue 4=/ tiene inconvenientesJ #' *ara proyectos grandes, pero escalables, el 4=/ necesita suficientes recursos humanos para crear en n<mero correcto de e"uipos 4=/. )' Si los desarrolladores y clientes no se comprometen con las actividades r!pidas necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos 4=/ fallar!n. 5' Si un sistema no se puede modular en forma apropiada, la construccin de los componentes necesarios para el 4=/ ser! problem!tica. 7' Si el alto rendimiento es un aspecto importante, y se alcan%ar! al convertir interfaces en componentes del sistema, el enfo"ue 4=/ podra no funcionar.

:' El 4=/ sera inapropiado cuando los riesgos tcnicos son altos &por ejemplo, cuando una aplicacin nueva aplica muchas nuevas tecnologas'. Es un modelo de proceso del soft are incremental "ue resulta un ciclo de desarrollo corto. El modelo 4=/ es una adaptacin a alta velocidad del modelo en cascada en el "ue se logra el desarrollo r!pido mediante un enfo"ue de construccin basado en componentes. Qace un uso intensivo de componentes reusables de soft are con un ciclo de desarrollo e(tremadamente corto. s importante destacar que los 'odelo +rescripti!os proporcionan un conjunto de pautas para el dise%o, uso y reuso de los objetos de aprendizaje, como complemento al proceso de su descripcin, de una manera iterati!a o incremental, desde la concepcin del objeto de aprendizaje hasta su reusabilidad a corto, mediano y largo plazo. +ero el )"ito en la creacin de cualquier objeto de aprendizaje depender de la adecuada aplicacin del proceso de 1ngeniera de #oftware, cuyas etapas facilitan el desarrollo de los objetos de aprendizaje. Modelos "#oluti#os Se reconoce "ue el soft are al igual "ue todos los sistemas complejos evoluciona con el tiempo, los re"uisitos de gestin y de producto a menudo cambian conforme a "ue el desarrollo procede haciendo "ue el camino "ue lleva al producto final no sea real. El desarrollo evolutivo consta del desarrollo de una versin inicial "ue luego de e(ponerse se va refinando de acuerdo de los comentarios o nuevos re"uerimientos por parte del cliente o del usuario final. $os modelos evolutivos son iterativos, se caracteri%a por la forma en "ue permiten a los ingenieros en soft are desarrollar versiones cada ve% m!s completas del soft are. / continuacin se presentan algunos de los modelos "ue se clasifican en esta categora. 0onstruccin de prototipos 8odelos en espiral 8odelo de desarrollo concurrente n los modelos e!oluti!os se produce un sistema inicial que e!oluciona segn las necesidades del cliente hasta cumplir con los requisitos de este, para luego producir un sistema que satisfaga sus necesidades. ste enfoque enlaza las acti!idades de especificacin, desarrollo y !alidacin. -onstru$$i%n de 4rototipos

En Ingeniera de soft are la $onstru$$i%n 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 utili%ar mucho dinero pues a partir de "ue este sea aprobado es "ue el desarrollador puede iniciar el verdadero desarrollo del soft are. El diseo r!pido se basa en una representacin de a"uellos aspectos del soft are "ue ser!n visibles para el cliente o el usuario final &por ejemplo, la configuracin de la interfa% con el usuario y el formato de los despliegues de salida'. El diseo r!pido 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 re"uisitos del soft are "ue se desarrollar!. $a iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite "ue al mismo tiempo el desarrollador entienda mejor lo "ue se debe hacer y el cliente vea resultados a corto pla%o. $a construccin de prototipos se puede utili%ar como un modelo del proceso independiente. Sin importar la forma en "ue ste se apli"ue, el paradigma de construccin de prototipos ayuda al desarrollador de soft are y al cliente a entender de mejor manera cu!l ser! el resultado de la construccin cuando los re"uisitos estn satisfechos. "tapasJ

*lan r!pido. 8odelado, diseo r!pido. 0onstruccin del *rototipo. 4esarrollo, entrega y retroalimentacin. 0omunicacin. Venta0asJ Este modelo es <til cuando el cliente conoce los objetivos generales para el soft are, pero no identifica los re"uisitos detallados de entrada, procesamiento o salida. Mambin ofrece un mejor enfo"ue cuando el responsable del desarrollo del soft are est! inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma "ue debera tomar la interaccin humanoH m!"uina. =educe el riesgo de construir productos "ue no satisfagan las necesidades de los usuarios. =educe costos y aumenta la probabilidad de (ito. E(ige disponer de las herramientas adecuadas. @na ve% identificados todos los re"uisitos mediante el prototipo, se construye el producto de ingeniera. Des#enta0asJ El usuario tiende a crearse unas e(pectativas cuando ve el prototipo de cara al sistema final. / causa de la intencin de crear un prototipo de forma r!pida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo pla%o, lo "ue obliga en la mayor parte de los casos a reconstruirlo una ve% "ue el prototipo ha cumplido su funcin. Es frecuente "ue el usuario se muestre reacio a ello y pida "ue sobre ese prototipo se construya el sistema final, lo "ue 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 por"ue proporcione un desarrollo m!s r!pido'. 0on el paso del tiempo, el desarrollador puede olvidarse de la ra%n "ue le llev a tomar tales decisiones, con lo "ue se corre el riesgo de "ue dichas elecciones pasen a formar parte del sistema final.

-uando el cliente define el software que desea que el analista construya, pero no identifica los requisitos detallados de entrada, procesamiento o salida. l responsable del desarrollo del software est inseguro de la adaptabilidad del sistema operati!o o de la forma que debera tomar la interaccin hombre 2 mquina, entonces en este caso es cuando se puede emplear la construccin de prototipos. #e crea un dise%o rpido que se centra en una representacin de aquellos aspectos del software que sern !isibles para el usuario final, a su !ez el dise%o rpido conduce a la construccin de un prototipo. .espu)s, el prototipo lo e!ala el usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollar. Modelo en "spiral

El 'odelo en espiral representa en forma de espiral una secuencia de actividades.) Este modelo fue originalmente propuesto por Toehm en #FBB, y se diferencia de los dem!s modelos por considerar el riesgo. El modelo en espiral para la ingeniera de soft are es actualmente el enfo"ue m!s realista para el desarrollo de soft are y de sistemas a gran escala. @tili%a un enfo"ue evolutivo, permitiendo al desarrollador y al cliente entender y reaccionar ante los riesgos en cada nivel evolutivo.) El modelo en espiral se divide en un n<mero de actividades estructurales, tambin llamadas regiones de tareas, seg<n Sommerville &)++:' el ciclo de vida del modelo en espiral se divide cuatro sectoresJ #. Defini$i%n de o/0eti#os. En esta fase se identifica las restricciones del proceso y le producto, y dependiendo los riesgos para tra%ar objetivos y respectivamente panes estratgicos. ). "#alua$i%n : redu$$i%n de riesgos. Se hace un an!lisis detallado para casa riesgo y se establece los pasos para reducirlos. 5. Desarrollo : #alida$i%n. 4espus de evaluar los riesgos, se elige un modelo para el desarrollo del sistema. 7. 4lanifi$a$i%n. El proyecto se revisa y se toma la decisin de si debe continuar con un ciclo posterior de la espiral. $as caractersticas "ue se pueden indicar del modelo en espiral sonJ El soft are se desarrolla en una serie de versiones incremntales. 4urante las primeras iteraciones. $a versin incremental podra ser un modelo en papel o un prototipo. / medida "ue se va incrementando el n<mero de iteraciones, se producen versiones cada ve% mas completas. Venta0as: *uede adaptarse y aplicarse a lo largo de la vida del soft are. 0omo el soft are evoluciona, a medida "ue progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. *ermite a "uien lo desarrolla aplicar el enfo"ue de construccin de prototipos en cual"uier etapa de evolucin del producto. 4emanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto. =educe los riesgos antes de "ue se conviertan en problem!ticos. Des#enta0as:

*uede resultar difcil convencer la grandes clientes de "ue el enfo"ue evolutivo es controlable &particularmente en situaciones de contrato'. Si un riesgo importante no es descubierto y gestionado, indudablemente surgir!n problemas. 0omo es un modelo relativamente nuevo no es muy utili%ado. 6tros inconvenientes "ue pueden surgir es convencer al cliente "ue es un enfo"ue controlable,por lo "ue se re"uiere de e(periencia en la identificacin de riesgos y refinamiento para su uso generali%ado.

Lo caracterstico del modelo es espiral es que incluye un 3anlisis de riesgo4 es decir que podemos analizar si el proyecto puede continuar o mejor lo suspendemos. ste modelo se basa en que antes de hacer algo debemos analizarlo, tambi)n debemos buscar !arias opciones de resolucin de problemas para de all escoger la opcin ms con!eniente, y adems analizar los riesgos que se pueda tener. ste modelo necesita de otro m)todos para poder desarrollarse. Modelo de desarrollo $on$urrente

4avis Sitaram describe el 'odelo de desarrollo $on$urrente de la siguiente formaJ#B

5Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes 6del ciclo de !ida clsico7 no tiene ideal del estado de sus proyectos. stos son ejemplos de un intento por seguir los pasos e"tremadamente simples. 8enga en cuenta que aunque un proyecto 6grande7 este en la fase de codificacin, hay personal de ese proyecto implicado en acti!idades asociadas generalmente a muchas fases de desarrollo simultneamente. +or ejemplo,...el personal esta escribiendo requisitos dise%ando, codificando, haciendo pruebas y probando la integracin /todo al mismo tiempo0. Los modelos de proceso de ingeniera del software de 9umphrey y :ellner han mostrado la concurrencia que e"iste para acti!idades que ocurren para cualquier fase. l trabajo ms reciente de :ellner utiliza diagramas de estado para representar la relacin concurrente que e"iste entre acti!idades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que e"iste en todas las acti!idades 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. /(n modelo de proceso concurrente0 esta dirigido por las necesidades del usuario, las decisiones de la gestin y los resultados de las re!isiones.5 /corde con la descripcin de 4avis podemos decir "ue el modelo concurrente se define una serie de acontecimientos "ue dispararan transiciones de estado a estado para cada una de las actividades de la ingeniera del soft are proporcionando una visin certera del estado actual del proyecto. Se puede representar en forma de es"uema como una serie de actividades tcnicas importantes, tareas y estados asociados a ellas. #F Iuncionalidad del procesoJ 0ada actividad, accin o tarea dentro de la red e(iste de manera simult!nea con otras. $os sucesos generados dentro de una actividad dada o alg<n otro lado de la red de actividad inicia las transiciones entre los estado de una actividad. El modelo de proceso concurrente se utili%a como paradigma de desarrollo de aplicaciones clienteNservidor. @n sistema clienteNservidor se compone de un conjunto de componentes funcionales. 0uando se aplica a clienteNservidor, el modelo de proceso concurrente define actividades en dos dimensionesJ una divisin de sistemas y una divisin de componentes. $os aspectos del nivel de sistemas se afrontan mediante dos actividadesJ diseo y reali%acin. $a concurrencia se logra de dos formasJ #. $as actividades del sistema y de componente ocurren simult!neamente y pueden modelarse con el enfo"ue orientado a objetos descrito anteriormente. ). @na aplicacin clienteNservidor tpica se implementa con muchos componentes, cada uno de los cuales se pueden disear y reali%ar concurrentemente. 9entajasJ E(celente para proyectos en los "ue se conforman grupos de trabajo independientes. *roporciona una imagen e(acta del estado actual de un proyecto. 4esventajasJ Si no se dan las condiciones sealadas no es aplicable. Si no e(isten grupos de trabajo no se puede trabajar en este mtodo Modelos iterati#os Este modelo busca reducir el riesgo "ue surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de re"uisitos. 0onsiste en la iteracin de varios ciclos de vida en cascada. /l final de cada iteracin se le entrega al cliente una versin mejorada o con mayores funcionalidades del producto. El

cliente es "uien despus de cada iteracin eval<a el producto y lo corrige o propone mejoras. Estas iteraciones se repetir!n hasta obtener un producto "ue satisfaga las necesidades del cliente. El modelo iterativo se suele utili%ar en proyectos en los "ue los re"uisitos no est!n claros por parte del usuario, por lo "ue se hace necesaria la creacin de distintos prototipos para presentarlos y conseguir la conformidad del cliente. 0ada iteracin es un mini proyecto en cascada auto contenido compuesto de actividades como an!lisis de re"uerimientos, diseo, programacin y pruebas. Venta0as: *ermite crear cada ve% versiones m!s completas de soft are =esolucin de problemas de alto riesgo en tiempos tempranos del proyecto. 9isin de avance en el desarrollo desde las etapas iniciales del desarrollo. 8enor tasa de fallo del proyecto, mejor productividad del e"uipo, y menor cantidad de defectos El trabajo iterativo deja una e(periencia en el e"uipo "ue permite ir ajustando y mejorando las planificaciones, logrando menores desvos en la duracin total del proyecto. Des#enta0asJ =e"uiere de un cliente involucrado durante todo el curso del proyecto. Qay clientes "ue simplemente no estar!n dispuestos a invertir el tiempo necesario. Infunde responsabilidad en el e"uipo de desarrollo al trabajar directamente con el cliente, re"uiriendo de profesionales sobre el promedio. (na de las grandes !entajas 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 3todos4 los requisitos del software, sino que este proceso ayudar a ir descubriendo paso a paso los requisitos a partir de cada nue!a 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 !ez !ersiones mas ccompletas hasta que cumpla sus espectati!as o se adapte a sus necesidades Modelos de Desarrollo =giles >as 'etodologas 6giles son un conjunto de mtodos de ingeniera del soft are, "ue se basan en el desarrollo iterativo e incremental, teniendo presente los cambios y respondiendo a estos mediante la colaboracin de un grupo de desarrolladores autoH organi%ados y multidisciplinares. En las metodologas !giles, los procesos se desarrollan de manera solapada, donde el ciclo de vida del proyecto, es cclico. $a diferencia en el ciclo de vida de un proyecto !gil, en comparacin con uno tradicional, se debe a la forma en la "ue el agilismo, solapa los procesos de manera iterativa.

$a tendencia del control de procesos para desarrollo de soft are ha trado como resultado "ue proyectos no resulten e(itosos debido al cambiante conte(to "ue e(iste, por lo cu!l las metodologas !giles pretende resolver este inconveniente, construyendo soluciones a la medida asegurando la calidad. $os mtodos !giles fueron pensados especialmente para e"uipos de desarrollo pe"ueos, con pla%os reducidos, re"uisitos vol!tiles y nuevas tecnologas. $a filosofa de las metodologas !giles, pretenden dar mayor valor al individuo, a la colaboracin con el cliente y al desarrollo incremental del soft are con iteraciones muy cortas. Este enfo"ue est! mostrando su efectividad en proyectos con re"uisitos muy cambiantes y cuando se e(ige reducir dr!sticamente los tiempos de desarrollo pero manteniendo una alta calidad. $a direccin del enfo"ue de establecer una metodologa "ue solventara los cambios dr!sticos del ambiente, di origen en febrero de )++#, tras una reunin celebrada en @tahHEE@@, en esta reunin participan un grupo de #A e(pertos de la industria del soft are, incluyendo algunos de los creadores o impulsores de metodologas de soft are. Su objetivo fue esbo%ar los valores y principios "ue deberan permitir a los e"uipos desarrollar soft are r!pidamente y respondiendo a los cambios "ue puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de soft are tradicionales &metodologas pesadas', caracteri%ados por ser rgidos y dirigidos por la documentacin "ue se genera en cada una de las actividades desarrolladas. $a fundacin del 'anifiesto 6gil, una organi%acin, sin !nimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo !gil de soft are y ayudar a las organi%aciones para "ue adopten dichos conceptos, promovi a "ue los grupos de desarrolladores se enfocar!n y establecier!n los siguientes valoresJ /l individuo y las interacciones del e"uipo de desarrollo sobre el proceso y las herramientas. $a gente es el principal factor de (ito de un proyecto soft are. Es m!s importante construir un buen e"uipo "ue construir el entorno. 8uchas veces se comete el error de construir primero el entorno y esperar "ue el e"uipo se adapte autom!ticamente. Es mejor crear el e"uipo y "ue ste configure su propio entorno de desarrollo en base a sus necesidades.

4esarrollar soft are "ue funciona m!s "ue conseguir una buena documentacin. $a regla a seguir es ,no producir documentos a menos "ue sean necesarios de forma inmediata para tomar un decisin importante-. Estos documentos deben ser cortos y centrarse en lo fundamental. $a colaboracin con el cliente m!s "ue la negociacin de un contrato. Se propone "ue e(ista una interaccin constante entre el cliente y el e"uipo de desarrollo. Esta colaboracin entre ambos ser! la "ue mar"ue la marcha del proyecto y asegure su (ito. =esponder a los cambios m!s "ue seguir estrictamente un plan. $a habilidad de responder a los cambios "ue puedan surgir a los largo del proyecto &cambios en los re"uisitos, en la tecnologa, en el e"uipo, entre otros' determina tambin el (ito o fracaso del mismo. *or lo tanto, la planificacin no debe ser estricta sino fle(ible y abierta. Estos valores inspiraron los doce prin$ipios del 'anifiesto 6gilJ I. $a prioridad es satisfacer al cliente mediante tempranas y continuas entregas de soft are "ue le aporte un valor. II. 4ar la bienvenida a los cambios. Se capturan los cambios para "ue el cliente tenga una ventaja competitiva. III. Entregar frecuentemente soft are "ue funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. I9. $a gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 9. 0onstruir el proyecto en torno a individuos motivados. 4arles el entorno y el apoyo "ue necesitan y confiar en ellos para conseguir finali%ar el trabajo. 9I. El di!logo cara a cara es el mtodo m!s eficiente y efectivo para comunicar informacin dentro de un e"uipo de desarrollo. 9II. El soft are "ue funciona es la medida principal de progreso. 9III. $os procesos !giles promueven un desarrollo sostenible. $os promotores, desarrolladores y usuarios deberan ser capaces de mantener una pa% constante. I?. $a atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. ?. $a simplicidad es esencial. ?I. $as mejores ar"uitecturas, re"uisitos y diseos surgen de los e"uipos organi%ados por s mismos. ?II. En intervalos regulares, el e"uipo refle(iona respecto a cmo llegar a ser m!s efectivo, y seg<n esto ajusta su comportamiento. En definicin las 'etodologas 6giles son un conjunto de mtodos de ingeniera del soft are, "ue se basan en el desarrollo iterativo e incremental, teniendo presente los cambios y respondiendo a estos mediante la colaboracin de un grupo de desarrolladores autoHorgani%ados y multidisciplinares. $as caractersticas esenciales del proceso de desarrollo !gil para la mayora de los proyectos son las siguientesJ Tusca la satisfaccin del cliente. Entrega temprana de soft are incremental. @tili%an mtodos informales. Simplicidad general del desarrollo. $a comunicacin entre los desarrolladores y los clientes durante el desarrollo del proyecto debe ser activa y continua. $a idea es "ue 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 "ue la adaptabilidad mantenga un buen ritmo con el cambio. 4rogra'a$i%n "5tre'a 7?48 $a programacin e(trema &?4@ e5tre'e 4rogra''ing' es un modelo de proceso de soft are el fue acuado por TecL el cual toma los principios y practicas aceptadas y las lleva a niveles e(tremos. Miene como objetivo reducir el riesgo en el ciclo de vida del soft are mediante grupos de desarrollo pe"ueos, considera "ue la mejor manera de tratar la falta de re"uisitos estables en un sistemas, es mediante la agilidad de un grupo pe"ueo de desarrollo B . Esta se basa en la simplicidad, la comunicacin y el reciclado continuo de cdigo. El modelo considera varios aspectos problem!ticos del desarrollo de soft are como lo son los retrasos , proyectos cancelados, cambios en el negocio y la rotacin del personal. Sus a$ti#idades /6si$as son J 0odificar, hacer pruebas, escuchar y disear. $os o/0eti#os de ?* son muy simplesJ #. $a satisfaccin del clienteJ trata de dar al cliente el soft are "ue l necesita y cuando lo necesita. ). *otenciar al m!(imo el trabajo en grupoJ Manto los jefes de proyecto, los clientes y desarrolladores, son parte del e"uipo y est!n involucrados en el desarrollo del soft are. ?* define cuatro variables para proyectos de soft areJ coste, tiempo, calidad y !mbito. /dem!s de estas cuatro variables, TecL propone "ue slo tres puedan ser establecidas por las fuer%as e(ternas &jefes de proyecto y clientes', mientras "ue el valor de la cuarta variable debe ser establecido por los programadores en funcin de las otras tres. $os #alores originales de la programacin e(trema sonJ Ai'pli$idadJ ?* propone el principio de hacer la cosa m!s simple "ue pueda funcionar, en relacin al proceso y la codificacin. Esta es la base de la programacin e(trema. -o'uni$a$i%nJ $os programadores se comunican constantemente gracias a la programacin por parejas y adem!s la comunicacin con el cliente es fluida ya "ue el cliente forma parte del e"uipo de desarrollo <etroali'enta$i%nJ retroalimentacin concreta y frecuente del cliente, del e"uipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuer%o. -ora0e o #alenta J $a valenta le permite a los desarrolladores "ue se sientan cmodos con reconstruir su cdigo cuando sea necesario. Esto significa revisar el sistema e(istente y modificarlo si con ello los cambios futuros se implementaran mas f!cilmente. 4rin$ipios /6si$os en la 4rogra'a$i%n e5tre'a: 4lanifi$a$i%n In$re'entalJ los re"uerimientos se registran en tarjetas de historias, estas incluyen el tiempo y la prioridad relativa. "ntregas pe2ue+asJ estas entregas son frecuentes e incrementalmente aaden funcionalidad al primera entrega Dise+o sen$illoJ solo se lleva a cabo el diseo necesario para cumplir los re"uerimientos actuales Desarrollo pre#ia'ente pro/ado. se utili%a un sistema de pruebas, para escribir pruebas de las nuevas funcionalidades antes de "ue estas se implementen. <efa$toriBa$i%nJ conserva el cdigo sencillo y mantenible.

4rogra'a$i%n en pare0asJ 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 4ropiedad $ole$ti#aJ las parejas trabajan en todas las !reas del sistema. Integra$i%n $ontinuaJ cuanto acaba el trabajo en una tarea, se integra en el sistema entero. <it'o sosteni/leJ Go se consideran aceptables grandes cantidades de horas e(tras, ya "ue a menudo, reduce la calidad del codigo y la productividad a medio pla%o. -liente presenteJ 4ebe estar disponible al e"uipo de ?*, un represente de los usuarios finales del sistema a tiempo completo. En un proceso ?* el cliente es parte del e"uipo de desarrollo

La programacin e"trema es uno de los m)todo 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 tambi)n reulitizacin de los cdigos. +ara el uso de <+ los requerimientos deben de estar bien definidos, mediante las historias de usuario. ste 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 cla!e para el )"ito en el desarrollo de software, promo!iendo el trabajo en equipo y preocupndose por el aprendizaje de los desarrolladores y la satisfaccin del cliente Desarrollo Adaptati#o del Aoftware 7DAA8 El desarrollo adaptati#o de software 7DAA8 #FFB fue propuestos por Kim Qighsmith como una metodologa para desarrollar el soft are y sistemas muy complejos. Este se centra en la colaboracin humana y la organi%acin del e"uipo ). El 4esarrollo adaptativo del soft are 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 4/S se conforma de tres fasesJ Especulacin, colaboracin y aprendi%aje H ;ase de espe$ula$i%n: Es la primera de las fases esta inicia en el desarrollo del proyecto. Se utili%a informacin como la visin del cliente, las restricciones del proyecto y los re"uisitos b!sicos para definir el conjunto de ciclos en el "ue se har!n los incrementos del soft are. En esta fase es donde se lleva a cabo la planificacin tentativa del proyecto en funcin de las entregas "ue se iran reali%ando H ;ase de $ola/ora$i%n: Se busca "ue el e"uipo colabore inmensamente para lograr la funcionalidad planeada, se comuni"ue o se encuentre completamente integrados, se desea "ue e(ista confian%a, donde se puedan reali%ar crticas constructivas y ayudar si resentimientos, as como tambin comunicar de una forma oportuna los problemas "ue se presenten para tomar acciones efectivas y poseer un conjunto de actitudes "ue contribuyan al trabajo "ue se encuentran reali%ando. H ;ase del aprendiBa0e: consiste en la revisin de calidad "ue se reali%a al final de cada ciclo, esto permite mejorar el entendimiento real sobre la tecnologa, los procesos utili%ados y el proyecto. El aprendi%aje individual permite al e"uipo tener mayor posibilidad de (ito.

sta metodologa no proporciona el tipo de prcticas detalladas como lo hace <+, pero proporciona la base fundamental de por qu) el desarrollo adaptable es importante y las consecuencias a los ms profundos ni!eles de la organizacin y la gerencia. Los apoyos filosficos del .&# 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. s adaptati!o, se hace uso de la reutilizacin del cdigo para adaptarlo a lo que se desea Modelo de Desarrollo de Aiste'as Din6'i$os 7MDAD8 Es un metodo de desarrollo agil de soft are "ue apoyado por su continua implicacion del usuario en un desarrollo iterativo y creciente "ue sea sensible a los re"uerimientos cambiantes, para desarrollar un sistema "ue reuna las necesiadades de la empresa en tiempo y presuspuesto. Este se caracteri%a 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 El 84S4 comien%a con un estudio de viabilidad y de negocio, son las primeras actividades "ue deben reali%arse "studio #ia/ilidad: Se eval<a si la aplicacin es viable, para el proceso teniendo en cuenta los re"uisitos b!sicos del negocio y sus restricciones asociadas. "studio de nego$iosJ establece los re"uisitos funcionales y de informacin "ue permitir!n "ue la aplicacin proporcione un valor al negocio. tambin define la ar"uitectura b!sica de la aplicacin. El resto del proceso forma tres $i$los iterati#os "ue sonJ Itera$i%n de 'odelo fun$ional: produce una serie de prototipos incremntales "ue demuestran la funcionalidad para el cliente. Su propsito durante este ciclo es recopilar re"uisitos adicionales y producir documentacin de an!lisis. Itera$i%n de $onstru$$i%n : dise+o: 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. I'ple'enta$i%n: coloca el incremento de soft are m!s reciente en el ambiente operativo, se ocupa del despliegue al uso operacional. *uede destacarse "ue #' el incremento puede no estar #++ por ciento completo o )' se pueden re"uerir cambios cuando el incremento se coloca en el sitio. l modelo de desarrollo de sistemas dinmicos tiene como objeti!o fundamental la entrega de sistemas software en tiempo y presupuesto , ajustndose a los cambios de requisitos que puedan surgir durante el proceso de desarrollo. +ara su implementacin se hacen dos estudios principalmente el de negocio y el de !iabilidad, para posteriormente dar inicio a sus > ciclos de !ida . &l igual que <+ el desarrollo es iterati!o e incremental as como tambi)n basado por la retroalimentacin del usuario, de esa manera logrando con!erger la solucin del negocio mas efecti!a. &demas de lo mencionado anteriormente el '.#. incluyen enttregas frecuentes, equipos autorizados, y pruebas a lo largo de todo su ciclo Modelo A$ru'

A$ru' es una metodologa !gil de gestin de proyectos cuyo objetivo primordial es elevar al m!(imo la productividad de un e"uipo, fue desarrollado por Keff Sutherland y elaborado m!s formalmente por Pen Sch aber.. Se enfoca en el hecho de "ue procesos definidos y repetibles slo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles. U se divide un proyecto en iteraciones &"ue ellos llaman carreras cortas' de 5+ das. $a literatura de Scrum se orienta principalmente en la planeacin iterativa y el seguimiento del proceso -ara$teristi$asJ Enfati%a valores y pr!cticas de gestin, sin pronunciarse sobre re"uerimientos, pr!cticas de desarrollo, implementacin y dem!s cuestiones tcnicas. Qace uso de E"uipos autoHdirigidos y autoHorgani%ados *uede ser aplicado tericamente a cual"uier conte(to en donde un grupo de gente necesita trabajar junta para lograr una meta com<n. 4esarrollo de soft are iterativos incrementales basados en pr!cticas agiles Iteraciones de treinta das. aun"ue se pueden reali%ar con mas frecuencia, estas iteraciones, conocidas como Sprint 4entro de cada Sprint se denomina el Scrum 8aster al $der de *royecto "uien llevar! a cabo la gestin de la iteracin Se convocan diariamente un ,Scrum 4aily 8eeting- el cual representa una reunin de avance diaria de no m!s de #: minutos con el propsito de tener realimentacin sobre las tareas de los recursos y los obst!culos "ue se presentan. En la cual se responden preguntas comoJ CDu has hecho desde el ultimo encunetroE CDu obstaculos hay para cumplir la metaE CDu haras antes del pro(imo encuentroE -i$lo de Vida de A$ru' En cuanto al ciclo de vida del modelo Scrum es el siguiente #)J #. 4re-1uego C 4lanea'iento: El propsito es establecer la visin, definir e(pectativas y asegurarse la financiacin. $as actividades son la escritura de la visin, el presupuesto, el registro de acumulacin o retraso 8etodologas >giles &bacLlog' del producto inicial y los tems estimados, as como la ar"uitectura de alto nivel, el diseo e(ploratorio y los prototipos. El registro de acumulacin es de alto nivel de abstraccin. ). 4re-1uego C Monta0e 7Ataging8J El propsito es identificar m!s re"uerimientos y priori%ar las tareas para la primera iteracin. $as actividades son planificacin, diseo e(ploratorio y prototipos. 5. 1uego C Desarrollo: El propsito es implementar un sistema listo para entrega en una serie de iteraciones de treinta das llamadas ,corridas- &sprints'. $as 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. 7. 4os-1uegoC >i/era$i%nJ El propsito es el despliegue operacional. $as actividades, documentacin, entrenamiento, mercadeo y venta. #crum es una metodologa para la gestin y desarrollo de software basada en un proceso iterati!o e incremental, uno de sus principios cla!es radica en el reconocimiento de que durante un proyecto los clientes pueden cambiar sus pensamientos sobre lo que quieren y necesitan. n este modelo se hacen reuniones diarias o tambi)n denominadas reuniones cortas /?@ min apro"0 donde se discute lo que se hizo, lo que se hace, y lo que posteriormente se har . s 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$dirigidos0, con margen de decisin suficiente para tomar las decisiones que consideren oportunas. Desarrollo $ondu$ido por $ara$tersti$as 7D--8 El desarrollo conducido por caractersticas &400' lo concibieron originalmente *eter 0oad como un modelo de proceso pr!ctico para la ingeniera del soft are orientada a objetos. Stephen *almer y Kohn Ielsin han e(tendido y mejorado el trabajo de 0oad, al describir un proceso adaptativo y !gil "ue puede aplicarse en proyectos de soft are de tamao moderado y grande. En el conte(to del 400 una caracterstica Wes una funcin evaluada por el cliente "ue puede implementarse en dos semanas o menosDenefi$ios "ue se le concede a la definicin de caractersticasJ $as caractersticas se pueden organi%ar en un agrupamiento jer!r"uico relacionado con el negocio. 0omo las caractersticas son blo"ues pe"ueos de funcionalidad entregable, los usuarios las describen con mayor facilidad, pueden entender cmo stas se relacionan con otras con mayor rapide%, y pueden revisarlas de mejor manera en b<s"ueda de ambigYedades, errores u omisiones. @na caracterstica es el incremento de soft are entregable, el e"uipo desarrolla caractersticas operativas cada dos semanas. 4ebido a "ue las caractersticas son pe"ueas, sus diseos y representaciones de cdigo son m!s f!ciles de inspeccionar de manera efectiva "l D-- se en$uentra di#idido en $in$o fases o a$ti#idades: #. 4esarrollar un modelo 3eneral ). Elaborar una lista de caractersticas 5. *lan por caractersticas 7. 4iseo por caractersticas :. 0onstruccin por caractersticas El desarrollo de un 'odelo generalJ En una fase ya se tiene el dominio, el conte(to, y los re"uerimientos del sistema a construir. En este momento se posee informacin b!sica de las especificaciones funcionales. referencias $a $onstru$$i%n de la lista de $ara$tersti$as los ensayos, modelos de objetos y documentacin de re"uerimientos proporcionan la base para construir una amplia lista de caractersticas . $as 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 valide% y e(haustividad El dise+o : la $onstru$$i%n por $ara$tersti$as, se selecciona las caractersticas a desarrollar y los e"uipos dispuestos por cada una de ellas. $uego se procede iterativamente hasta "ue se producen las caractersticas seleccionadas. l 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 e!aluadas 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 4ro$eso Unifi$ado de <ational 7<U48

El *roceso @nificado de =ational es una metodologa de desarrollo de soft are orientada a objetos creada por =ational Soft are 0orporation. Es una de las metodologas m!s e(tendidas y conocidas por su amplia difusin comercial. Se puede estudiar como una metodologa representativa de tipo cl!sico. Iue definido por los creadores del @8$ unificando los mtodos de Ivar Kacobson, 3rady Tooch y Kames =umbaugh. El hecho de "ue la empresa =/MI6G/$ tambin distribuya herramientas especficas basadas en el mismo mtodo, "ue facilitan el desarrollo, ha contribuido a su gran e(pansin. se maneja por casos de uso &correspondientes a los modos uso por los actores o agentes usuarios' para la e(traccin de re"uisitos y la identificacin de las partes funcionales en las "ue se divide la solucin. $a ar"uitectura del proceso se modela con orientacin a objetos. Estos metodologistas, fueron reunidos por =ational para formar un marco de metodologas unificadas, cohesivas y comprehensivas de desarrollo de sistemas de soft are. Su trabajo, "ue producen durante varios aos y basados en metodologas probadas, han dado a lugar a importantes normas en la comunidad de desarrollo, 0omo toda metodologa de desarrollo soft are su finalidad es convertir las especificaciones "ue da el cliente en un sistema soft are. $as caractersticas "ue tiene el =@*. sonJ "st6 /asado en $o'ponentes. "stos $o'ponentes a su #eB est6n $one$tados entre s a tra#(s de interfa$es. UtiliBa el UM> $o'o nota$i%n /6si$a. Dirigido por $asos de uso. El proceso utili%a 0asos de @so para manejar el proceso de desarrollo desde la Incepcin hasta el 4espliegue. -entrado en la ar2uite$tura. El proceso busca entender los aspectos est!ticos y din!micos m!s significativos en trminos de ar"uitectura de soft are. $a ar"uitectura se define en funcin de las necesidades de los usuarios y se determina a partir de los 0asos de @so base del negocio.

-i$lo de #ida iterati#o e in$re'ental. El proceso reconoce "ue es pr!ctico dividir grandes proyectos en proyectos m!s pe"ueos o miniHproyectos. 0ada miniHproyecto comprende una iteracin "ue resulta en un incremento. @na iteracin puede abarcar la totalidad de los flujos del proceso. $as iteraciones son planificadas en base a los 0asos de @so. 4ro$eso de $uatro fases El proceso @nificado consta de ciclos "ue puede repetir a lo largo del ciclo de vida de un sistema. @n ciclo consiste en cuatro fasesJ Incepcin, Elaboracin, 0onstruccin y Mransicin. @n ciclo concluye con una liberacin, tambien hay versiones dentro de un ciclo. Esta es una descripcin breve de las fases de un cicloJ ;ase de In$ep$i%n: 4urante 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. Dueremos entender los argumentos comerciales en favor de por"u el proyecto debe intentarse. $a fase de incepcin establece la viabilidad del producto y delimita el alcance del proyecto. Se describe el producto final. Se responde a las preguntasJ C0u!les son las principales funciones del sistema para sus usuarios m!s importantesE. $a respuesta est! en el modelo de casos de uso simplificado. C0mo podra ser la ar"uitectura del sistemaE C0u!l es el plan del proyecto y cu!nto costar! desarrollar el productoE ;ase de "la/ora$i%n: 4urante la fase de elaboracin la mayora de los 0asos de @so son especificados en detalle y la ar"uitectura del sistema es diseada. Esta fase se focali%a en las ,Hbilidades- del proyecto. Se identifican los riesgos significativos y se preparan el calendario, el e"uipo de trabajo y el costo del proyecto. ;ase de -onstru$$i%n: 4urante la fase de construccin, el foco del producto se mueve de la ar"uitectura de base a un sistema lo suficientemente completo como para llevarlo al usuario. El baseline de ar"uitectura 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 utili%an la mayor parte de los recursos, y al finali%ar se cubren todos los casos de uso. $a pregunta "ue se reali%a esJ C 0ubre el producto las necesidades de los usuarios como para hacer una primera entregaE ;ase de 3ransi$i%n: En la fase de transicin el objetivos es garanti%ar "ue los re"uisitos se han cumplido, con la satisfaccin de las partes interesadas. Esta fase a menudo se inicia con una versin beta de la aplicacin. 6tras actividades incluyen la preparacin del ambiente, se completan, se identifican y corrigen defectos. $a fase de transicin termina con un cierre dedicado al aprendi%aje de lecciones, las cuales "uedan para futuros ciclos.El producto e(iste en versin Teta.

La metodologa de A(+ es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo /qui)n hace qu), cundo y cmo0, este proceso de A(+ estiman tareas y horario del plan midiendo la !elocidad de iteraciones concerniente a sus estimaciones originales. A(+ se enfocan fuertemente sobre la arquitectura del software. para su implementacin se hace a tra!)s 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 !ida en cascada a menor escala, este tiene

grandes !entajas con respectos a <+, ya que se enfoca en los requisitos y el dise%o, as como tambi)n el cliente interacta con el equipo de desarrollo mediante reunionesa diferencia de la metodologa <+ que el cliente es parte del equipo Diferen$ias entre los 'odelos de pro$eso $on#en$ionales : 6giles 8etodologas !gilesJ Est!n basadas en heurstica provenientes de pr!cticas de produccin de cdigos. Est!n preparadas para cambios durante el proyecto. Son impuestas internamente &por el e"uipo'. *roceso menos controlado. Go e(iste contrato tradicional. Son bastante fle(ibles. El cliente es parte del e"uipo de desarrollo. 3rupos pe"ueos y trabajando en el mismo sitio. 8enos nfasis en la ar"uitectura del soft are. 8etodologas convencionalesJ Tasadas en normas provenientes de est!ndares. *resentan cierta resistencia a los cambios. Impuestas e(ternamente. *roceso mucho mas controlado, con numerosas polticas. E(iste un contrato prefijado. Son un poco rgidas. El cliente interact<a con el e"uipo de desarrollo mediante reuniones. 3rupos grandes y posiblemente distribuidos. $a ar"uitectura del soft are es esencial y se e(presa mediante modelos. -lasifi$a$i%n de las 'etodologas seg9n su enfo2ue Metodologas estru$turadas Se basan en la forma topHdo n. Entre estas est!nJ Metodologas orientadas a pro$esos Se basan en la utili%acin de un mtodo descendente de descomposicin funcional para definir los re"uisitos del sistema, dan lugar a un nuevo concepto Wla especificacin estructuradaW "ue es un modelo gr!fico particionado, descendente y jer!r"uico de los procesos del sistema. $a metodologa orientada a procesos est! compuesta porJ .iagrama de flujo de datosJ Estos son diagramas "ue representan los procesos de datos "ue deben llevar acabo un sistema a distintos niveles de abstraccin y los datos "ue hay entre las funciones. .iccionario de datosJ Es el conjunto de las definiciones de todos los datos "ue aparecen en el diagrama de flujos de datos. specificaciones de procesosJ como se obtienen las salidas del proceso a partir de sus entradas. $as metodologas orientadas a procesos comprende una fase de an!lisis estructurado y los mtodos de 4e8arco, 3ene y Sarson, Uourdon, son algunos "ue permiten lograr esto. 'etodologa de .emarcoJ 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. 'etodologa de Bane y #arsonJ Es parecida a la de 4emarco, la diferencia es "ue elimina el primer paso y crea uno nuevo "ue es cuando construye el modelo lgico del sistema. Mambin construye un modelo lgico de datos.

'etodologa de CourdonJ =eali%a los 4I4s del sistema, a partir de los 4I4 reali%a el diagrama de estructuras, evaluacin del diseo y preparacin del diseo. Metodologas orientadas a datos Son metodologas basadas en la informacin, ya "ue los datos son m!s estables "ue los procesos. *rimero se definen las estructuras de datos y, a partir de stos, se derivan los componentes procedimentales. Ejemplos de esta clasificacin sonJ metodologas de KacLson, Zarnier, ZarnierH6rr. Estas metodologas se dividen en jer!r"uicas y no jer!r"uicasJ Metodologa orientada a datos 0er6r2ui$asJ $a estructura de control del programa debe ser jer!r"uica 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, me%clarlas todas en una estructura jer!r"uica de programa y despus ordenar detalladamente la lgica procedimental para "ue se ajuste a esta estructura. El diseo lgico debe preceder y estar separado del diseo fsico. Metodologa orientada a datos no 0er6r2ui$asJ 8etodologa Ingeniera de la Informacin. *lanificacinJ construir una ar"uitectura de la Informacin y una estrategia "ue soporte los objetivos de la organi%acin . /n!lisisJ comprender las !reas del negocio y determinar los re"uisitos del sistema. 4iseoJ establecer el comportamiento del sistema deseado por el usuario y "ue sea alcan%able por la tecnologa. 0onstruccinJ construir sistemas "ue cumplan los tres niveles anteriores.

Las metodologas estructuradas estn orientadas a procesos y a objetos. 1ntentan aplicar ingeniera para solucionar problemas t)cnicos de un sistema de informacin, proponen la creacin de modelos, flujos y estructuras mediante un top$down. $a metodologa orientada a procesos est! fundamentada en el modelo entradaHprocesoH salida., aplica un proceso interactivo para lograr un refinamiento progresivo. $a metodologa orientada a objetos se divide en jer!r"uica y no jer!r"uica, la jer!r"uica est! orientada a las entradas y salidas, las no jer!r"uicas definen un sistema a partir de la informacin "ue este maneja. Metodologas para siste'as de tie'po real $as metodologas en tiempo real procesan informacin orientada al control m!s "ue a los datos. Se caracteri%an porJ 0oncurrencia. *riori%acin de procesos. 0omunicacin y sincroni%acin entre tareas. /cceso simult!neo a datos comunes. *ermiten el manejo de interrupciones. 3estin de procesos concurrentes =espuesta oportuna ante eventos e(ternos. 4atos continuos o discretos. Metodologas .rientadas a ./0etos $a orientacin a objetos unifica procesos y datos encapsul!ndolos en el concepto de objetos. $a esencia del desarrollo orientado a objetos es la identificacin y organi%acin

de conceptos del dominio de la aplicacin y no tanto de su representacin final en un lenguaje de programacin. Miene dos enfo"ues distintosJ Ae!olucionario, puro u ortodo"oJ =ompen con las metodologas tradicionales. $a 6rientacin a objetos se entiende como un cambio profundo de las metodologas estructuradas "ue se ven como obsoletas. EjemplosJ metodologas 664 de Tooch, 0=0N=44 de ZirfsHTrocL. #intetista o e!oluti!oJEl an!lisis y diseo estructurado se considera como la base para el desarrollo 6rientado a objetos. Venta0as de las 'etodologas orientadas a o/0etos: Aeutilizacin. $as clases est!n diseadas para "ue se reutilicen en muchos sistemas. *ara ma(imi%ar la reutili%acin, las clases se construyen de manera "ue se puedan adaptar a los otros sistemas. @n objetivo fundamental de las tcnicas orientadas a objetos es lograr la reutili%acin masiva al construir el soft are. stabilidad. $as clases diseadas para una reutili%acin repetida se vuelven estables, de la misma manera "ue los microprocesadores y otros chips se hacen estables. l dise%ador piensa en t)rminos del comportamiento de objetos y no en detalles de bajo ni!el. El encapsulamiento oculta los detalles y hace "ue las clases complejas sean f!ciles de utili%ar. #e construyen clases cada !ez ms complejas. Se construyen clases a partir de otras clases, las cuales a su ve% se integran mediante clases. Esto permite construir componentes de soft are complejos, "ue a su ve% se convierten en blo"ues de construccin de soft are m!s complejo. -alidad. $os diseos suelen tener mayor calidad, puesto "ue se integran a partir de componentes probados, "ue han sido verificados y pulidos varias veces. (n dise%o ms rpido. $as aplicaciones se crean a partir de componentes ya e(istentes. 8uchos de los componentes est!n construidos de modo "ue se pueden adaptar para un diseo particular. 1ntegridad. $as estructuras de datos &los objetos' slo se pueden utili%ar con mtodos especficos. Esto tiene particular importancia en los sistemas clienteHservidor y los sistemas distribuidos, en los "ue usuarios desconocidos podran intentar el acceso al sistema. 'antenimiento ms sencillo. El programador encargado del mantenimiento cambia un mtodo de clase a la ve%. 0ada clase efect<a sus funciones independientemente de las dem!s. (na interfaz de pantalla sugesti!a para el usuario. Qay "ue utili%ar una interfa% de usuario gr!fica de modo "ue 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. 9er y apuntar es m!s f!cil "ue recordar y escribir. 1ndependencia del dise%o. $as clases est!n diseadas para ser independientes del ambiente de plataformas, hard are y soft are. @tili%an solicitudes y respuestas con formato est!ndar. Esto les permite ser utili%adas en m<ltiples sistemas operativos, controladores de bases de datos, controladores de red, interfaces de usuario gr!ficas, etc. El creador del soft are no tiene "ue preocuparse por el ambiente o esperar a "ue ste se especifi"ue. 1nteraccin. El soft are de varios proveedores puede funcionar como conjunto. @n proveedor utili%a clases de otros. E(iste una forma est!ndar de locali%ar clases e interactuar con ellas. El soft are desarrollado de manera independiente en lugares ajenos debe poder funcionar en forma conjunta y aparecer como una sola unidad ante el usuario.

-omputacin -liente$#er!idor. En los sistemas clienteHservidor, las clases en el soft are cliente deben enviar solicitudes a las clases en el soft are servidor y recibir respuestas. @na clase servidor puede ser utili%ada por clientes diferentes. Estos clientes slo pueden tener acceso a los datos del servidor a travs de los mtodos de la clase. *or lo tanto los datos est!n protegidos contra su corrupcin. -omputacin de distribucin masi!a. $as redes a nivel mundial utili%ar!n directorios de soft are de objetos accesibles. El diseo orientado a objetos es la clave para la computacin de distribucin masiva. $as clases de una m!"uina interact<an con las de alg<n otro lugar sin saber donde residen tales clases. Ellas reciben y envan mensajes orientados a objetos en formato est!ndar. 'ayor ni!el de automatizacin de las bases de datos. $as estructuras de datos &los objetos' en las bases de datos orientadas a objetos est!n ligadas a mtodos "ue llevan a cabo acciones autom!ticas. @na base de datos 66 tiene integrada una inteligencia, en forma de mtodos, en tanto "ue una base de datos relacional b!sica carece de ello. Las metodologas orientadas a objetos han e!olucionado para ayudar a los desarrolladores a e"plotar el poder de los lenguajes de programacin basados en objetos y orientados a objetos, utilizando las clases y objetos como bloques de construccin bsicos. (na orientacin a objetos nos ayuda a hacer frente a la inherente complejidad de muchos tipos de sistemas. EFue 'etodologa es $on#eniente usarG Mener metodologas diferentes para aplicar de acuerdo con el proyecto "ue se desarrolle resulta una idea interesante. Estas metodologas pueden involucrar pr!cticas tanto de metodologas !giles como de metodologas tradicionales. 4e esta manera podramos tener una metodologa para cada proyecto, la problem!tica sera definir cada una de las pr!cticas, y en el momento preciso definir par!metros para saber cual usar.Es importante tener en cuenta "ue 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 "ue no estn acostumbradas a seguir procesos encuentran estas metodologas bastante agradables. *or otro lado, las metodologas tradicionales o convencionales permiten crear soft are de manera mas segura ya "ue estas entan mas establecidas seg<n por sus pasos. Modelos de pro$esos utiliBados en el desarrollo de software Modelado de Nego$ios *ara conseguir sus objetivos, una empresa organi%a su actividad por medio de un conjunto de procesos de negocio. 0ada uno de ellos se caracteri%a por una coleccin de datos "ue son producidos y manipulados mediante un conjunto de tareas, en las "ue ciertos agentes &por ejemplo, trabajadores o departamentos' participan de acuerdo a un flujo de trabajo determinado. /dem!s, estos procesos se hallan sujetos a un conjunto de reglas de negocio, "ue determinan las polticas y la estructura de la informacin de la empresa. *or 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. 0on esta disciplina se pretende llegar a un mejor entendimiento de la organi%acin. $os objetivos especficos del modelado de negocio sonJ #. /segurar "ue clientes, usuarios finales y desarrolladores tengan un entendimiento com<n de la organi%acin objetivo. ). 4erivar los re"uerimientos del sistema necesarios para apoyar a la organi%acin objetivo en su mejora.

5. Entender el problema actual en la organi%acin objetivo e identificar potenciales mejoras. 7. Entender la estructura y la din!mica de la organi%acin para la cual el sistema va a ser desarrollado &organi%acin objetivo'. *ara lograr estos objetivos, el modelado de negocio describe como desarrollar una visin de la nueva organi%acin, basado en esta visin se definen procesos, roles y responsabilidades de la organi%acin por medio de un 8odelo de 0asos de @so del Gegocio. $os artefactos del modelo de negocio sirven como entrada y referencia para la definicin de los re"uerimientos del sistema. $a importancia de esta disciplina radica en "ue sin el panorama completo del alcance del negocio y sin el entendimiento de sus procesos no podr!n identificarse las necesidades inmediatas de mejora y continuidad relativa a las actividades relacionadas con los sistemas inform!ticos, "ue son el producto final del desarrollo. .rienta$i%n del 'odelado de nego$io. 4ominios principales en los "ue se empleaJ 4ominios orientados al negocio 3erencia Meora de 6rgani%aciones EHbusiness, EHcommerce 4ominios orientados a la tecnologa Sistemas de Informacin Ingeniera de Soft are Inform!tica Industrial $os dominios definen dos puntos de vista diferentes del 8odelado deJ 6rientado al valorNcliente Tusca e(plicar cmo la empresa crea valor para el cliente, "ue 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 "ue tiene un conjunto de objetos, conceptos y relaciones con el objetivo de e(presar la lgica del negocio de una empresa- 6ster alde , *igneur &)++:'. 6rientado a la actividadNrol Qace nfasis en el modelado de los procesos y actores de la empresa , en las actividades "ue reali%a la empresa y "uienes 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 "ue act<a como la base para la comunicacin, mejoras o innovacin y define los re"uisitos de los sistemas de informacin "ue intervienen en la empresa - EriLson y *eLer &)+++'. (n 'odelado del Degocio es una descripcin de los elementos que constituyen una organizacin, o una parte de ella, as como de las relaciones entre estos elementos. (n 'odelo del Degocio es una conceptualizacin de una empresa u organizacin, es la caracterizacin de los aspectos ms significati!os 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 Nego$ios e Ingeniera de <e2uisitos El 8odelado de Gegocios y la Ingeniera de =e"uisitos son los dos procesos tcnicos iniciales del desarrollo ingenieril de aplicaciones de soft are. El 8odelado de Gegocios

se reali%a en el espacio del problema. se encarga de estudiar el dominio de la aplicacin con la finalidad de formular y anali%ar el problema "ue da origen a la aplicacin. $a Ingeniera de =e"uisitos, por su parte, ocurre en el espacio de la solucin. se encarga, por lo tanto, de caracteri%ar la aplicacin en base a las necesidades y los re"uisitos "ue los usuarios de la aplicacin tienen. El proceso de ingeniera de re"uerimientos se utili%a para definir todas las actividades involucradas en el descubrimiento, documentacin y mantenimiento de los re"uerimientos para un producto de soft are determinado, donde es muy importante tomar en cuenta la viabilidad de llevar a cabo el soft are &si es factible llevarlo a cabo o no', pasando posteriormente por un subproceso de obtencin y an!lisis de re"uerimientos, su especificacin formal, para finali%ar con el subproceso de validacin donde se verifica "ue los re"uerimientos realmente definen el sistema "ue "uiere el cliente. n el desarrollo de software, el 'odelado de Degocios aporta informacin esencial para la 1ngeniera de Aequisitos, ya que en el modelado de negocio se !e lo que es el problema y en la ingeniera de requisitos se define la solucin al problema. -adena de Valor

$a cadena de valor es esencialmente una forma de an!lisis de la actividad empresarial mediante la cual descomponemos una empresa en sus partes constitutivas, buscando identificar fuentes de ventaja competitiva en a"uellas actividades generadoras de valor. $a cadena de valor representa todas las actividades "ue se llevan a cabo en una empresa, en la cual se reali%a una separacin entre las actividades de mayor inters &actividades primarias' y las actividades "ue le sirven de apoyo con la finalidad de prestar mayor atencin y centrarse en a"uellas actividades "ue generan mayores ventajas al momento de competir con otras empresas. 0omo se menciono anteriormente la cadena de valor se divide en actividades primarias y secundarias A$ti#idades pri'arias: 0onforman la creacin fsica del producto, las actividades relacionadas con su venta y la asistencia postHventa. Se dividen enJ \$ogstica interna \6peraciones \$ogstica e(terna \9entas y marLetingJ actividades con las cuales se da a conocer el producto.

\Servicios postHventa &mantenimiento'J actividades destinadas a mantener o reali%ar el valor del producto. A$ti#idades se$undarias o de apo:o, est!n conformadas porJ \ Infraestructura de la organi%acin \ 4ireccin de recursos humanosJ b<s"ueda, contratacin y motivacin del personal. \ 4esarrollo de tecnologa &investigacin y desarrollo' \ /bastecimiento o compras La cadena de !alor es una herramienta de gran importancia ya que permite determinar cuales son aquellas acti!idades de !alor de la empresa. s muy til que las empresas conozcan no solo su cadena de !alor si no tambi)n la de sus competidores, ya que esta proporciona un mejor anlisis interno de la organizacin, as como tambi)n identificar las !entajas competiti!as y comprender de una mejor manera el comportamiento de los costos y las di!ersas fuentes de diferenciacin con la competencia. -on$lusiones @na metodologa se basa en una combinacin de los modelos de proceso genricos para obtener como beneficio un soft are "ue soluciones un problema $a trascendencia de las metodologas se ha hecho notoria, pasando de solo programar, establecer funciones en etapas o mdulos, objetos, y por <ltimo agili%ar el desarrollo del soft are y minimi%ar los costos. En el desarrollo convencional todo el programa est! en un solo blo"ue, con ejecucin secuencial de instrucciones En el desarrollo estructurado los programas est!n divididos en distintos blo"ues, estos blo"ues tienen funciones "ue se van confeccionado en forma de arribaH abajo, empe%ando 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 estar!n estructuradas por propiedades, atributos, variables, pretendiendo simular y describir de manera conceptual a un objeto. $os mtodos !giles fueron pensados especialmente para e"uipos de desarrollo pe"ueos, con pla%os reducidos, re"uisitos vol!tiles y nuevas tecnologas. El modelado de negocio describe como desarrollar una visin de la nueva organi%acin, basado en esta visin se definen procesos, roles y responsabilidades de la organi%acin por medio de un 8odelo de 0asos de @so del Gegocio $os modelos de procesos permiten al analista de sistemas desarrollar un plan de re"uisitos del soft are, permiten establecer un trabajo en forma ordenada, adem!s "ue e(isten muchos modelos "ue se adaptan a las e(igencias del proyecto, solo debemos saber cual nos conviene. <eferen$ias #. /lonso, I. y 8artne%, $. &)++:'. 1ntroduccin a la ingeniera del software= modelos de desarrollo de programas &primera edicin'. EspaaJ 4elta *ublicaciones. *!g. A:HA; ). Sommerville, I. &)++:'. 1ngeniera del software &Sptima Edicin'. EspaaJ *earson Educacin. 5. Qern!n, 8. &)++7'. .ise%o de una 'etodologa Egil de .esarrollo de #oftware. Mesis de 3rado de Ingeniera en Inform!tica. @niversidad de Tuenos /ires. *!g. ##H#) 7. Sommerville, I. &)++;'. 1ngeniera del software &Sptima Edicin'. 8adrid. *!g. ;) :. Espino%a, /. 'etodologas de desarrollo de software 1documento en lnea2.4isponible enJ ] .slideshare.netNjuliopariN7HclaseHmetodologiaHdeHdesarroloH deHsoft are ^ 1consultaJ ## de junio de )+#)2

;. 0arballar, 4. 1ngeniera de software 1documento en lnea2. ] .eduinnova.esNdic+FNIngenieria_Soft are.pdf ^ 1consultaJ #+ de junio de )+#)2 A.4isponible en la ebJ ] .angelfire.comNscifiNj%avalarNapuntesNIngSoft are.html`paradigma66 ^ 1consultaJ #+ de junio de )+#)2 B. Penneth, E. y Pendall, K. &)++:'. &nalisis C .ise%o de #istemas&Se(ta edicin'. 8(ico. F. Sols, 8. &)++5'. (na e"plicacin de la programacin e"trema /<+0. 8adrid. *!g. #+5 #+. 6rdone% &)+##'. 'etodo de .esarrollo de sistemas dinamicos1documento en lnea2. 4isponible enJ] .slideshare.netNoscarficoNmetodosHdinamicos ^ 1consultaJ B de junio de )+#)2 ##. 0itn, 8.&)++;'. ')todo gil scrum aplicado al desarrollo de un software de trazabilidad. /rgentina. #). /maro , S. y 9alverde, K. &)++A'. 'etodologas Egiles. *er<JMrujillo. #5. 8ende%, E. &)++;'. 8odelo de Evaluacion de 8etodologia para el 4esarrollo de Soft are. Mrabajo de 3rado, @niversidad 0atlica /ndrs Tello,0aracas,9%la. #7. 0ans K. y $etelier *. &)++5, noviembre'. 'etodologas giles en el desarrollo de software 1resumen2. Maller reali%ado en el marco de las 9III jornadas de Ingeniera del soft are y bases de datos en la @niversidad politcnica de 9alencia, EspaaH/licante. #:. $aboratorio Gacional de 0alidad del Soft are de IGME06. &)++F, 8ar%o' 1ngeniera del software= metodologas y ciclos de !ida. Espaa. #;. 6scar >lvare% Ima%. &)++B, /bril'. WIntroduccin a =@*W 9ersin +.# #A. /lonso, I. y 8artne%, $. &)++:'. 1ntroduccin a la ingeniera del software= modelos de desarrollo de programas &primera edicin'. EspaaJ 4elta *ublicaciones. *!g. ##)H##5 #B. 4isponible en la ebJ ] .laprole75#.blogspot.comN)+#+N#)N"ueHesHunHmodeloH deHdesarrollo.html ^ 1consultaJ ; de julio de )+#)2 #F. 4isponible en la ebJ ] .ingenieraupoliana.blogspot.comN)+#+N#+NmodeloHdeH desarrolloHconcurrente.html ^ 1consultaJ ; de julio de )+#)2 )+. 4avid, I. &)++B'. -onceptos de &dministration strat)gica &4ecimoprimera Edicin'. Editorial *earson Educacin, 8(ico. )#. 4isponible en la ebJ ] .aprendecomputofacil.blogspot.comN)++F_+A_+#_archive.html ^ 1consultaJ #+ de julio de )+#)2