Instituto tecnolgico de Cancn

Ingeniera de Software

Unidad 2Metodologas de Desarrollo

IntegrantesJesus Gudalupe Centeno CentenoRoberto Misael Rubio VazqueManuel Espinosa CetinaDavid Orlando Moguel Balam

NDICE INTRODUCCIN32.1 METODOLOGAS CLSICAS32.1.1 CASCADA42.1.2 INCREMENTAL72.1.3 DESARROLLO EVOLUTIVO102.1.4 DESARROLLO EN ESPIRAL142.1.5 DESARROLLO DEPROTOTIPOS182.1.6 DESARROLLO BASADO EN COMPONENTES212.2 OTRAS METODOLOGAS252.2.1GANAR-GANAR (WIN & WIN)262.2.2 PROCESO UNIFICADO (UP)282.2.3 INGENIERA WEB422.2.4 METODOLOGAS GILES532.2.5 METODOLOGAS EMERGENTES582.2.6REINGENIERIA71Conclusin75Bibliografa76Glosario77

INTRODUCCIN

En esta unidad aprenderemos sobre las metodologas de desarrollo, como es que funcionan cada una de ellas e identificar las principales caracterstica que tienen los diferentes modelos entre los modelos y similitudes Para la creacin y desarrollo de aplicacin o software permitiendo saber sus procesos en la implementacin de sus metodologas. Cada metodologa tiene sus ventajas y desventajas de acuerdo al modelo que se vaya a realizar

2.1 METODOLOGAS CLSICAS

Los modelos de proceso dependen de las opiniones o creencias de las personas involucradas en un proyecto. Por ejemplo, algunas de estas opiniones o creencias implican que es necesario comprender el problema antes de desarrollar una solucin, el proceso para resolver un problema debe dar un resultado predecible (sin importar qu individuo hace el trabajo), es indispensable planear y calcular el proceso con gran precisin, para queproceso tenga xito es importante evaluar y administrar el riesgo y la entrega de etapas intermedias bien definidas aumenta la confianza que se tiene en el resultado final. A continuacin se describen los modelos de procesos clsicos, analizando las creencias en las cuales se basan.

2.1.1 CASCADAEn Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior[.]Un ejemplo de una metodologa de desarrollo en cascada es:Anlisis de requisitos.Diseo del Sistema.Diseo del Programa.Codificacin.Pruebas.Implantacin.Mantenimiento.De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto.Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue siendo el paradigma ms seguido al da de hoy.Fases del modelo.

El "modelo cascada" sin modificar. El progreso fluye de arriba hacia abajo, como una cascada.

Anlisis de requisitosEn esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificacin de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos.Es importante sealar que en esta etapa se debe consensuar todo lo que se requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a mitad del proceso de elaboracin del software.Diseo del SistemaDescompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras.Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para comenzar la implementacin.Diseo del ProgramaEs la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin.CodificacinEs la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregir errores.Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido.PruebasLos elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.VerificacinEs la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.En la creacin de desarrollo de cascada se implementa los cdigos de investigacin y pruebas del mismoMantenimientoUna de las etapas ms crticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.VariantesExisten variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final est libre de fallos.DesventajasEn la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso.El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no est completo no se opera. Esto es la base para que funcione bien.Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo.2.1.2 INCREMENTALEl modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el enfoque incremental de desarrollo como una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Este modelo se conoce tambin bajo las siguientes denominaciones:Mtodo de las comparaciones limitadas sucesivas.Mtodo de atacar el problema por ramas.El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofa interactiva de Construccin de Prototipos. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado ncleo.En una visin genrica, el proceso se divide en 4 partes:AnlisisDiseoCdigoPrueba

Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. Este modelo es particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos.Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final terminar siendo la solucin completa requerida por el cliente, pero stas partes no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este necesitando con ms urgencia, de los puntos ms importantes del proyecto, los requerimientos ms bsicos, difciles y con mayor grado de riesgo, ya que estos se deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versin.De este modo podemos terminar una aplicacin ejecutable (primera versin) que podr ser entregada al cliente para que ste pueda trabajar en ella y el programador pueda considerar las recomendaciones que el cliente efecte para hacer mejoras en el producto. Estas nuevas mejoras debern esperar a ser integradas en la siguiente versin junto con los dems requerimientos que no fueron tomados en cuenta en la versin anterior.El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino nicamente correccin de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo.

Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de requisitos funcionales y ser el cliente quien se encarga de priorizar que funcionalidades son mas importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el sistema entregar. La asignacin de funcionalidades a los incrementos depende de la prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el primer incremento.CaractersticasSe evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.El usuario se involucra ms.Difcilde evaluar el costo total.Difcilde aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.Requiere gestores experimentados.Los errores en los requisitos se detectan tarde.El resultado puede ser positivo.Ventajas Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software. El modelo proporciona todas las ventajas del modelo en Cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.Desventajas: El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto ndice de riesgos. Requiere de mucha planeacin, tanto administrativa como tcnica. Requiere de metas claras para conocer el estado del proyecto.2.1.3 DESARROLLO EVOLUTIVOUn modelo de desarrollo es una representacin abstracta de un proceso de software, cada modelo representa el proceso de desarrollo de software de una manera en particular. A pesar de estar definidos claramente, no representan necesariamente la realidad de cmo se debe desarrollar el software, sino que establece un enfoque comn. Un modelo puede ser modificado y adaptado de acuerdo a las necesidades del software en desarrollo.Desarrollo EvolutivoEl desarrollo evolutivo consta del desarrollo de una versin inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificacin, desarrollo y validacin se entrelazan en vez de separarse.Existen dos tipos de desarrollo evolutivo:1.Desarrollo exploratorio,donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.2.Prototipos desechables,donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definicin mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer ms ventajas en comparacin con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que l mismo entiende mejor sus propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniera y gestin suele tener dos grandes problemas:1.El proceso no es visible.Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rpidamente, no es rentable producir documentos que reflejen cada versin del sistema.2. Amenudo los sistemas tienen una estructura deficiente.Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en l se convierte cada vez ms en una tarea difcil y costosa.Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeos y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo dificultan la estabilidad y la integracin de los avances de los distintos grupos de trabajo que puedan existir. La mayora de las empresas que desarrollan grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.Etapas del modelo evolutivo Basado en Componentes

PLANEACION: En esta etapa evala la funcin y el rendimiento que se asignaron al Software durante la Ingeniera del Sistema de Computadora para establecer un mbito de proyecto que no sea ambiguo, e incomprensible.

ANLISIS DE RIESGOS: en esta etapa l analista se encarga de analizar los riesgos que el software a crear estar expuesto y as encontrar la manera de corregirlos.

CONSTRUCCIN Y ADAPTACIN DE LA INGENIERA: en esta etapa se construye el software, se prueba si no tiene algn problema o para detectar errores, se instala, y luego se le brinda soporte al cliente.

VALUACIN DEL CLIENTE: el cliente tiene la tarea de evaluar el software para verificar si este cumple con los requisitos que este proporciono y est en todo la tarea de aprobar o rechazar el software.

Caractersticas Es evolutivo Posee un enfoque evolutivo para la creacin de software Comienza con la identificacin de las clases ms importantes Examina los datos que se van a manejar Permite la reutilizacin del software El ensamblaje de los componentes reduce el 70 del 100% del tiempo del ciclo del desarrollo del software y un 84 del 100% del costo del proyecto.

Ventajas / Desventajas

VentajasDesventajas

Reutilizacin del software. Simplifica las pruebas; pues estas se le hacen a los componentes antes de probar el conjunto completo de componentes ensamblados. Simplifica el mantenimiento del sistema. Mayor calidad.

Genera mucho tiempo en el desarrollo del sistema. Modelo costoso. Requiere experiencia en la identificacin de riesgos. Genera mucho trabajo adicional.

Ejemplo:

Un procesador de texto que sea desarrollado bajo el paradigma Incremental podra aportar, en principio, funciones bsicas de edicin de archivos y produccin de documentos (algo como un editor simple). En un segundo incremento se le podra agregar edicin ms sofisticada, y de generacin y mezcla de documentos. En un tercer incremento podra considerarse el agregado de funciones de correccin ortogrfica, esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones matemticas. As sucesivamente hasta llegar al procesador final requerido. As, el producto va creciendo, acercndose a su meta final, pero desde la integra del primer incremento ya es til y funcional para el cliente, el cual se observa una respuesta rpida en cuanto a entrega temprana; sin notar que la fecha lmite del proyecto puede no estar acotada ni tan definida, lo que da margen de operacin y alivia presiones al equipo de desarrollo.Conclusin:Este modelo se encarga de poder modificar o cambiar algn software que est en funcionamiento ponindole o diseando mejoras para este con el fin de brindar un satisfaccin en tiempo evolutivo para el cliente y que sea de su agrado 2.1.4 DESARROLLO EN ESPIRALEldesarrollo en espirales unmodelodeciclo de vida del softwaredefinido por primera vez porBarry Boehmen 1986,utilizado generalmente en laingeniera de software. Las actividades de este modelo se conforman en unaespiral, en la que cada bucle oiteracinrepresenta un conjunto de actividades. Las actividades no estn fijadas a ninguna prioridad, sino que las siguientes se eligen en funcin delanlisis de riesgo, comenzando por el bucle interior.Boehm, autor de diversos artculos de ingeniera del software; modelos de estimacin de esfuerzo y tiempo que se consume en hacer productos software; y Modelos de Ciclo de Vida; ide y promulg un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente elriesgoque aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo ms asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorndose con otro nuevo ciclo.Ciclos o Iteraciones:En cada vuelta o iteracin hay que tener en cuenta:Los Objetivos:qu necesidad debe cubrir el producto.Alternativas:las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:1.Caractersticas:experiencia del personal, requisitos a cumplir, etc.2.Formas de gestin del sistema.3.Riesgo asumido con cada alternativa.Desarrollar y Verificar:Programar y probar el software.Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma decaracolay se dice que mantiene dos dimensiones, la radial y la angular:1.Angular:Indica el avance del proyecto del software dentro de un ciclo.2.Radial:Indica el aumento del coste del proyecto, ya que con cada nueva iteracin se pasa ms tiempo desarrollando.Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creacin de un Sistema Operativo.Al ser un modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que uno de los aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.TareasPara cada ciclo habr cuatro actividades:1.Determinar Objetivos.2.Anlisis del riesgo.3.Planificacin.4.Desarrollar y probar.Determinar o fijar objetivosFijar tambin los productos definidos a obtener: requerimientos, especificacin, manual de usuario.Fijar las restricciones.Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos.Hay una cosa que solo se hace una vez: planificacin inicial.Anlisis del riesgoSe lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daos y consecuencias que stas puedan producir.PlanificarRevisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad.Desarrollar, verificar y validar (probar)Tareas de la actividad propia y de prueba.Anlisis de alternativas e identificacin resolucin de riesgos.Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. As si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. Si lo riesgos de proteccin son la principal consideracin, un desarrollo basado en transformaciones formales podra ser el ms apropiado.Mecanismos de controlLa dimensin radial mide el coste.La dimensin angular mide el grado de avance del proyecto.

VentajasEl anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc.Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodologa, ya que este ciclo de vida no es rgido ni esttico.Desventajas Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificacin de riesgosInconvenientesPlanificar un proyecto con esta metodologa es a menudo imposible, debido a la incertidumbre en el nmero de iteraciones que sern necesarias. En este contexto la evaluacin de riesgos es de la mayor importancia y, para grandes proyectos, dicha evaluacin requiere la intervencin de profesionales de gran experiencia.Ejemplo: El Modelo Espiral es particularmente apto para el desarrollo de Sistemas Operativos (complejos); tambin en sistemas de altos riesgos o crticos (Ej. navegadores y controladores aeronuticos) y en todos aquellos en que sea necesaria una fuerte gestin del proyecto y sus riesgos, tcnicos o de gestin.Conclusin:Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteracin representa un conjunto de actividades. Las actividades no estn fijas a ninguna prioridad, sino que las siguientes se eligen en funcin del anlisis de riesgo, comenzando por el bucle interiorConformado por ciclos o interacciones, los objetivos que son las necesidades que deben cubrir los productos. Las alternativas son las diferentes formas de conseguir los objetivos. De igual forma se involucra el desarrollo y la verificacin que se en carga de programar y probar el software, por otro lado Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular.2.1.5 DESARROLLO DEPROTOTIPOSEl Modelo de prototipos, enIngeniera de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final. Este diseo conduce a la construccin de un prototipo, el cual es evaluado por el cliente para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.Etapas Plan rpido Modelado, diseo rpido Construccin del Prototipo Desarrollo, entrega y retroalimentacin ComunicacinVentajas Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-mquina.La construccin de prototipos se puede utilizar como un modelo del proceso independiente, se emplea ms comnmente como una tcnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que ste se aplique, el paradigma de construccin de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente ms profundamente para adquirir el producto.InconvenientesEl usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertira en unprototipo evolutivo, pero partiendo de un estado poco recomendado.En reas de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementacin poco convenientes (por ejemplo, elegir un lenguaje de programacin incorrecto porque proporcione un desarrollo ms rpido). Con el paso del tiempo, el desarrollador puede olvidarse de la razn que le llev a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final...

Ejemplo:

En el Diseador de aplicaciones, el cuadro de herramientas incluye prototipos de aplicaciones predefinidos que puede utilizar para definir las aplicaciones. Un prototipo de aplicacin define una aplicacin pre configurada de un tipo de aplicacin especfico. Por ejemplo, puede comenzar definiendo una aplicacin ASP.NET que expone un servicio Web arrastrando el prototipoASP.NETWebServicedel cuadro de herramientas al diagrama de aplicaciones. Esta accin crea una aplicacin ASP.NET que tiene un extremo del proveedor de servicios Web predeterminada. En los tipos de aplicaciones que admiten la implementacin, Visual Studio genera los proyectos apropiados cuando los implementa para que pueda continuar con la definicin de estas aplicaciones en cdigo. Tambin puede crear prototipos personalizados a partir de aplicaciones y extremos ya configurados en el diagrama de aplicaciones as como expandir el conjunto de tipos y prototipos de aplicaciones que puede utilizar mediante la instalacin de paquetes suministrados por Microsoft o por terceros o crendolos mediante el kit de desarrollo de software (SDK) del modelo de definicin del sistema (SDM).ConclusionesEn este modelo a pesar de que surjan problemas, es muy importante en la construccin de prototipos ya que puede ser un enfoque muy efectivo para la ingeniera del software. La clave es definir las diferentes reglas que rigen para este modelado y enfocarlos desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:Que el prototipo se construya y sirva como unmecanismo para la definicin de requisitos.Que el prototipo sedescarte, al menos en parte.Que despus se desarrolle el software real con un enfoque hacia lacalidad2.1.6 DESARROLLO BASADO EN COMPONENTESIngeniera de Software Basada en Componentes (ISBC)Tradicionalmente los ingenieros del software han seguido un enfoque de desarrollo descendente (top-Down) basado en el ciclo de vida en cascada (anlisis-diseo implementacin) para la construccin de sus sistemas, donde se establecen los requisitos y la arquitectura de la aplicacin y luego se va desarrollando, diseando e implementando cada parte software hasta obtener la aplicacin completa implementada.La ISBC parte de la idea de la integracin de componentes software ya existente(Desarrollo ascendente o bottom-up). Las tecnologas de objetos proporcionan el marco de trabajo tcnico, para la ingeniera de software, para un modelo de proceso basado en componentes. El paradigma orientado a objetos enfatiza la creacin de clases que encapsulan tanto los datos como los algoritmos para manejar esos datos. Si se disean y se implementan adecuadamente, las clasesOrientadas a objetos son reutilizables por diferentes aplicaciones.Es la reutilizacin la que permite a los desarrolladores construir aplicaciones sin partir desde cero, sino acercndose ms al modelo de construccin de otras ingenieras, donde los productos se construyen en base al ensamblaje y adaptacin de distintos componentes desarrollados por terceros (como lo es la industria del hardware para computadoras). Por ello requiere un conjunto de estndares, guas, procesos y prcticas, para que se la considere como una ingeniera tal, y como una sub-disciplina de la Ingeniera de Software.Segn Pressman, La metodologa que propone entonces la Ingeniera de Software Basada en Componentes (ISBC) (Figura 1) incorpora muchas de las caractersticas del Modelo en Espiral. Es evolutivo2 por naturaleza, y por ello exige tambin un enfoque iterativo para la creacin del software.

Fases de Ingeniera y Construccin y Accin de ste modelo por una sola fase de Construccin y adaptacin de la Ingeniera: *Comunicacin con el cliente- las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente.

*Planificacin- las tareas requeridas para definir recursos, el tiempo y otra informacin relacionadas con el proyecto.

*Anlisis de riesgos- las tareas requeridas para evaluar riesgos tcnicos y de gestin.

*Construccin y adaptacin de la Ingeniera

*Evaluacin del cliente- las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin.Evoluciona con el tiempo, se crean versiones cada vez ms completas del producto.

Uncomponente de softwareindividual es un paquete de software, un servicio web, o unmduloqueencapsulaun conjunto de funciones relacionadas (o de datos).Todos los procesos del sistema son colocados en componentes separados de tal manera que todos los datos y funciones dentro de cada componente estnsemnticamente relacionados (justo como con el contenimiento declases). Debido a este principio, con frecuencia se dice que los componentes son modulares y cohesivos.Con respecto a la coordinacin a lo largo del sistema, los componentes se comunican uno con el otro por medio de interfaces. Cuando un componente ofrece servicios al resto del sistema, este adopta una interfaz proporcionada que especifica los servicios que otros componentes pueden utilizar, y cmo pueden hacerlo. Esta interfaz puede ser vista como una firma del componente - el cliente no necesita saber sobre los funcionamientos internos del componente (su implementacin) para hacer uso de ella. Este principio resulta en componentes referidos comoencapsulados. Las ilustracionesUMLde este artculo representan a las interfaces proporcionadas, con un smbolo lollipop unido al borde externo del componente.Sin embargo, cuando un componente necesita usar otro componente para poder funcionar, adopta una interfaz usada que especifica los servicios que necesita. En las ilustraciones de UML en este artculo, las interfaces usadas son representadas por un smbolo de zcalo abierto unido al borde externo del componente.

Un simple ejemplo de varios componentes de software - representados dentro de un hipottico sistema de reservaciones de das de fiesta representado enUML2.0.Otro atributo importante de los componentes es que son sustituibles, as que un componente puede sustituir a otro (entiempo de diseootiempo de ejecucin), si el componente sucesor cumple los requisitos del componente inicial (expresado por medio de las interfaces). Por lo tanto, los componentes pueden ser sustituidos por una versin actualizada o una alternativa sin romper el sistema en el cual operan.Como una regla de oro general para los ingenieros que sustituyen componentes, el componente B puede sustituir inmediatamente al componente A, si el componente B proporciona por lo menos que el componente A provee y no usa ms cosas que las que el componente A usa.Los componentes de software con frecuencia toman la forma deobjetos(no clases) o de colecciones de objetos (de laprogramacin orientada a objetos), en una cierta forma binaria o textual, adhirindose a un ciertolenguaje de descripcin de interfaz(IDL) de modo que el componente pueda existir autnomo de otros componentes en unacomputadora.Cuando un componente debe ser accesado o compartido a travs de contextos de ejecucin o enlaces de red, a menudo son empleados tcnicas tales comoserializacinomarshallingpara enviar el componente a su destino.Lareusabilidades una importante caracterstica de un componente de software de alta calidad. Los programadores deben disear e implementar componentes de software de una manera tal que diversos programas puedan reutilizarlos. Adems, cuando los componentes de software interactan directamente con los usuarios, debe ser considerada la prueba de usabilidad basada en componentes.Toma un significativo esfuerzo y conciencia para escribir un componente de software que sea efectivamente reutilizable. El componente necesita estar: completamente documentado probado a fondo robusto - con una comprensiva comprobacin para la validez de la entrada capaz de devolvermensajes de errorapropiados o cdigos de retorno diseado con conciencia de que ser puesto en usos imprevistosBeneficios del Desarrollo de Software basado en ComponentesEl paradigma de ensamblar componentes y escribir cdigo para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes. El uso de este paradigma posee algunas ventajas:Reutilizacin del software.Nos lleva a alcanzar un mayor nivel de reutilizacin de software.Simplifica las pruebas.Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.Simplifica el mantenimiento del sistema.Cuando existe un dbil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar otras partes del sistema.Mayor calidad.Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organizacin, la calidad de una aplicacin basada en componentes mejorar con el paso del tiempo.Ejemplo: Un simple ejemplo de dos componentes expresado enUML2.0. El componente Checkout (comprobacin), responsable de facilitar los pedidos del cliente, requiereal componente CardProcessing (procesador de tarjetas) para cargar el monto a la tarjeta de crdito/dbito del cliente (funcionalidad que este ltimoprovee).

2.2 OTRAS METODOLOGASMetodologa SCRUM:Es un marco de trabajo para la gestin ydesarrollo de softwarebasada en un procesoiterativo e incremental utilizado comnmente en entornos basados en eldesarrollo gil de software.Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximacin de gestin de programas: Scrum de Scrums.Programacin extremaLaprogramacin extremaoeXtreme Programming(XP) es una metodologa de desarrollo de laingeniera de softwareformulada porKent Beck, autor del primer libro sobre la materia,Extreme Programming Explained: Embrace Change(1999). Es el ms destacado de losprocesos gilesde desarrollo de software.Enel siguiente diagrama nos muestra ciclo de entrega en la programacin extrema.Al igual que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software.Proceso unificado gil Elproceso unificado gildeScott ambleroagile unified process(aup) en ingls es una versin simplificada delproceso unificado de rational(rup). Este describe de una manera simple y fcil de entender la forma de desarrollar aplicaciones de software de negocio usando tcnicas giles y conceptos que an se mantienen vlidos en rup. El aup aplica tcnicas giles incluyendo desarrollo dirigido por pruebas (test driven development - tdd), modelado gil, gestin de cambios gil, y refactorizacin de base de datos para mejorar la productividad.

2.2.1GANAR-GANAR (WIN & WIN)Ganar-ganar: extiende el modelo espiral, haciendo nfasis en la identificacin de las condiciones de ganancia para todas las partes, creando un plan para alcanzar las condiciones ganadoras y los riesgos correspondientes.Se establecen las reglas para definir el proceso de desarrollo del proyecto, tomando en cuenta todas las partes implicadas.El modelo no necesita mucho tiempo de gestin, lo que permite utilizarlo tanto en proyectos pequeos, como mayores.Se consideran cuatro ciclos, compuesto cada uno de cuatro actividades: Elaborar los objetivos, restricciones y alternativas del proceso y producto del sistema y subsistema Evaluar las alternativas con respecto a los objetivos y restricciones. Identificar y resolver las fuentes principales de riesgo en el proceso y el producto. Elaborar la definicin del producto y proceso.

Planear el siguiente ciclo y actualizar el plan de su ciclo de vida, incluyendo la particin del sistema en subsistemas para ser consideradas en ciclos paralelos. Esto puede incluir un plan para terminar el proyecto si es muyriesgosoo no es factible. Asegurar el compromiso de la administracin para continuar segn lo planeado.

Ganar-ganar: Una vez revisadas las actividades, los ciclos definen lneas especficas a seguir: Ciclo 0. Grupos de aplicacin. Se determina la viabilidad de un grupo apropiado de aplicaciones Ciclo 1. Objetivos del ciclo de vida de la aplicacin. Se desarrollan los objetivos del ciclo de vida, incluyendo prototipos, planes y especificaciones de aplicaciones individuales, y se verifica la existencia de al menos una arquitectura viable para cada aplicacin. Ciclo 2. Arquitectura del ciclo de vida de la aplicacin. Se establece una arquitectura del ciclo de vida detallado, se verifica la viabilidad y determina que no existen riesgos mayores en satisfacer los planes y especificaciones. Ciclo 3. Capacidad de operacin inicial. Alcanzar una capacidad operacional inicial para cada etapa crtica del proyecto en el ciclo de vida del software. Ejemplo: La evaporacin de nubes es la tcnica que tiene TOC para solucin de conflictos.

La nube es la metodologa para definir e identificar correctamente los conflictos que es la raz de todos los problemas.

Deldiagramapodemos deducir:La flecha quebrada de la ltima parte simboliza el conflictoLos Quieros no pueden existir simultneamente.La Necesidad es la razn por la cual cada parte insiste en obtener lo que quiere.Para satisfacer la Necesidad es necesario alcanzar el Quiero.El Objetivo Comn es una situacin que ambas partes desean, y para que existaCada parte debe satisfacer su Necesidad.

2.2.2 PROCESO UNIFICADO (UP)El Proceso Unificado es un proceso de software genrico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos.Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una organizacin de desarrollo. Su meta es asegurar la produccin de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.El Proceso Unificado tiene dos dimensiones (Figura1):Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimientoUn eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lgica de acuerdo a su naturaleza.La primera dimensin representa el aspecto dinmico del proceso conforme se va desarrollando, se expresa en trminos de fases, iteraciones e hitosLa segunda dimensin representa el aspecto esttico del proceso: cmo es descrito en trminos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.

Flujo de Trabajo de RUPEn RUP se han agrupado las actividades en grupos lgicos definindose 9 flujos de trabajo principales, los 6 primeros son conocidos como flujos de ingeniera y los tres ltimos como flujos de apoyo. Modelo del Negocio: Describe los procesos de negocio, identificando quines participan y las actividades que requieren automatizacin. Requerimiento: Define qu es lo que el sistema debe hacer, para lo cual se identifican las funcionalidades requeridas y las restricciones que se imponen. Anlisis y Diseo: Describe cmo el sistema ser realizado a partir de la funcionalidad prevista y las restricciones impuestas (requerimientos), por lo que indica con precisin lo que se debe programar.Implementacin: Define cmo se organizan las clases y objetos en componentes, cules nodos se utilizarn y la ubicacin en ellos de los componentes y la estructura de capas de la aplicacin. Prueba (Testeo): Busca los defectos a los largo del ciclo de vida. Instalacin o despliegue: Produce realce del producto y realiza actividades (empaque, instalacin, asistencia a usuarios, etc.) para entregar el software a los usuarios finales. Administracin del proyecto: Involucra actividades con las que se busca producir un producto que satisfaga las necesidades de los clientes. Administracin de configuracin y cambios: Describe cmo controlar los elementos producidos por todos los integrantes del equipo de proyecto en cuanto a: utilizacin/actualizacin concurrente de elementos, control de versiones, etc. Ambiente: Contiene actividades que describen los procesos y herramientas que soportarn el equipo de trabajo del proyecto; as como el procedimiento para implementar el proceso en una organizacin.El Proceso Unificado se basa en componentes (component-based), lo que significa que el sistema en construccin est hecho de componentes de software interconectados por medio de interfaces bien definidas (well-defined interfaces).El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparacin de todos los planos del sistema. De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados a la par.Los aspectos distintivos del Proceso Unificado estn capturados en tres conceptos clave: dirigido por casos de uso (use-case driven), centrado en la arquitectura (architecture-centric), iterativo e incremental. Esto es lo que hace nico al Proceso Unificado.El Proceso Unificado es dirigido por casos de usoUn sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios prospectos.El trmino usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el trmino usuario representa algo o alguien que interacta con el sistema por desarrollar.Uncaso de usoes una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen elmodelo de casos de usoel cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificacin funcional del sistema. Una especificacin funcional tradicional se concentra en responder la pregunta: Qu se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen una implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y no solamente en trminos de las funciones que sera bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas, esto es, dirigen el proceso de desarrollo.An y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la eleccin de los casos de uso. Por lo tanto, la arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida.

El Proceso Unificado est centrado en la arquitecturaEl papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto desempea en la construccin de edificios. El edificio se mira desde diferentes puntos de vista: estructura, servicios, plomera, electricidad, etc. Esto le permite al constructor ver una radiografa completa antes de empezar a construir. Similarmente, la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que est siendo construido.El concepto de arquitectura de software involucra los aspectos estticos y dinmicos ms significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y como estn reflejadas en los casos de uso. Sin embargo, tambin est influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutar, la disponibilidad de componentes reutilizables, consideraciones de instalacin, sistemas legados, requerimientos no funcionales (ej. desempeo, confiabilidad). La arquitectura es la vista del diseo completo con las caractersticas ms importantes hechas ms visibles y dejando los detalles de lado. Ya que lo importante depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad (understandability), flexibilidad en los cambios futuros (resilience) y reso.Cmo se relacionan los casos de uso con la arquitectura? Cada producto tiene funcin y forma. Uno slo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso funcin corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Es un problema del huevo y la gallina. Por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer espacio para la realizacin de todos los casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo.El Proceso Unificado es Iterativo e IncrementalDesarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o aos. Es prctico dividir el trabajo en pequeos pedazos o mini-proyectos. Cada mini-proyecto es una iteracin que finaliza en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el producto. Para ser ms efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada.Los desarrolladores basan su seleccin de qu van a implementar en una iteracin en dos factores. Primero, la iteracin trata con un grupo de casos de uso que en conjunto extienden la usabilidad del producto. Segundo, la iteracin trata con los riesgos ms importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron dejados en la iteracin anterior.En cada iteracin, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseo usando la arquitectura como gua, implementan el diseo en componentes y verifican que los componentes satisfacen los casos de uso. Si una iteracin cumple sus metas y usualmente lo hace el desarrollo contina con la siguiente iteracin. Cuando la iteracin no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.Principales ventajas Coste del riesgo a un solo incremento. Reduce el riesgo de no sacar el producto en el calendario previsto. Acelera el ritmo de desarrollo. Se adapta mejor a las necesidades del cliente.Ejemplo Real:PROCESO UNIFICADO RACIONAL, APLICADO EN DISTRIBUCINCategoraOperacin de Sistemas de PotenciaRESUMENEl objetivo de este trabajo es presentar de forma prctica un ejemplo de caso, al aplicar la metodologa RUP (Proceso Unificado Racional) en la implementacin de un sistema para medir la calidad en distribucin elctrica.PALABRAS CLAVES.Desarrollo de software, calidad del servicio de Distribucin Local, metodologa RUP.

INTRODUCCINLos sistemas de transporte de energa elctrica en Colombia, han sido impactados por los cambios metodolgicos, para determinar la calidad de prestacin del servicio.Desde el 2008, se present la metodologa para reemplazar en los Sistemas de Distribucin Local SDL , los ndices de duracin y frecuencia de eventos (DES y FES), por un indicador trimestral (ITAD), el cual mide la calidad de prestacin del servicio de distribucin.Dentro de la metodologa se estableci que el XM en su calidad de Liquidador y Administrador de Cuentas LAC-, debe determinar el ITAD de forma paralela al clculo que debe realizar cada Operador de Red, quien es responsable de la operacin y de la calidad del servicio en sus redes.La implementacin del sistema informtico para calcular el ITAD, XM realiz un ejercicio prctico, aplicando la metodologa de desarrollo de software RUP (Rational Unified Process).La metodologa RUP, comprende la adaptacin del proceso, el equilibrio de las prioridades, ventajas de dividir el problema en iteraciones, gestin de riesgos, colaboracin entre equipos, elevar el nivel de abstraccin y enfocarse en el control de la calidad del producto.

El objetivo de este trabajo es presentar los resultados encontrados al aplicar la metodologa RUP y documentar la experiencia para que desarrollos informticos futuros, se beneficien con las lecciones aprendidas.El trabajo se divide en cuatro secciones. En la primera parte, se detalla el marco terico de la metodologa RUP. A continuacin se describen el estudio de caso aplicado a la construccin del aplicativo para el clculo del ITAD. En la tercera parte se detalla el proceso iterativo y control de calidad empleado, para garantizar la aplicacin correcta de las regla de negocio. En la ltima parte se presentan los resultados obtenidos, las conclusiones y lecciones aprendidas, en la construccin de software en el mbito del sector elctrico.Tanto las etapas del flujo de trabajo, como las fases de desarrollo, se presentan en la siguiente grfica:

Los elementos anteriores, fueron tenidos en cuenta para el desarrollo informtico, para el clculo de la calidad, en los Sistemas de Distribucin Local SDL-, cuyo anlisis se presenta en la siguiente seccin.ESTUDIO DE CASOBajo la metodologa RUP, se efectu el desarrollo informtico de un sistema, para calcular los ndices de calidad de los SDL.El proyecto se dividi en dos partes: especificacin y desarrollo del sistema.ESPECIFICACIN (ANLISIS)La Resolucin CREG 097 de 2008, establece la metodologa para el clculo del ITAD, ndice Trimestral Agrupado de Discontinuidad, el cual mide la calidad del servicio en los SDL. En cuanto mayor sea su valor, el servicio tiene peor calidad.Dicha resolucin, plantea las ecuaciones y reglas para calcular el ITAD. Bajo esta ptica, se realiz la especificacin de las necesidades, reglas de negocio, requisitos funcionales, validaciones, requisitos no funcionales, tal como se describe a continuacin [1]:Necesidades: Es aquello que requiere ser resuelto en un proceso para cerrar o dar fin a una problemtica que se presenta en la actualidad en el negocio. Esta necesidad igualmente representa lo que el sistema de informacin le permitir hacer a los analistas de negocio para cumplir con los objetivos del proceso respectivo, siendo independiente de la forma (tcnica) como que se va a implementar en el sistema de informacin.Para el caso del clculo del ITAD, las necesidades estaban basadas por ejemplo, en recibir la informacin diaria, de las interrupciones de los transformadores y circuitos, de los Operadores de Red.Se utiliz la metodologa UML - Lenguaje Unificado de Modelado, para modelar las necesidades, los requisitos, y la posterior definicin de los casos de uso del sistema.Reglas de negocio: son aquellos enunciados que definen o restringen algunos aspectos del negocio. Describen las operaciones, las definiciones, y las restricciones que aplican a la organizacin. Dichas reglas pueden aplicar a la gente, a los procesos, al comportamiento corporativo e incluso, a los sistemas de cmputo de la empresa, y se ponen en marcha para ayudar a la organizacin a alcanzar sus metas. En un proceso de requisitos, las reglas de negocio permiten restringir el grado de libertad en el funcionamiento del sistema de informacin en cuestin, reflejando las directrices del proceso.Para el caso del sistema, las reglas de negocio establecieron por ejemplo que la informacin que se maneja de energa, estaba expresada en kWh. Tambin en la especificacin quedaba explcito, reglas relacionadas con el horario de carga de informacin, la estructura de los datos, el manejo de la bitcora para el registro de actividades del sistema entre otras.Validacin: una vez se determina el comportamiento del sistema, y por el gran manejo de volumen de informacin, se incluyeron las normas que debe cumplir el sistema para su correcto funcionamiento.Como ejemplo, se validaba que la informacin cargada estuviera completa, que las fechas de carga fueran correctas, que los clculos de variables especficas no fueran negativos entre otros. Es importante mencionar que para cada validacin, se defini el correspondiente mensaje de alerta, de confirmacin o error segn el caso, esto permite tener un mejor control sobre el sistema.

Grafica 2 - Validaciones del SistemaRequisito funcional general: Se detallan aquellas funcionalidades que son utilizadas de forma transversal en todo el sistema, por ejemplo, requisitos relacionados con la elaboracin de informes, auditoria, impresin, seguridad, autenticacin, etc.Para este caso, por ejemplo los requisitos consistan en las ecuaciones para el clculo del ITAD, partiendo de las expresiones intermedias, hasta llegar a la determinacin de ste ndice.

En la Grfica 3, se ilustra un ejemplo de un requisito, para calcular el ITG, que es una variable intermedia para llegar al ITAD.

Grafica 3 Requisito General FuncionalNtese lo importante de la numeracin del requisito, seguido por una descripcin completa y clara de lo que se requiere.Requisito no funcional general: constituyen las funcionalidades de orden tecnolgico y las caractersticas de calidad del producto final.Dada la gran cantidad de informacin del sistema, por ejemplo se definieron tiempos de respuesta esperados, para evaluar el desempeo del sistema y poder efectuar los clculos y publicaciones, bajo los plazos establecidos en la norma.Requisito de informacin: existe informacin que el usuario puede ver en pantalla, con la cual toma decisiones. Un requisito de este tipo, contiene por ejemplo el listado de datos producto de un clculo, un proceso u operacin.

En la siguiente grfica, se ilustra un requisito de informacin para la informacin diaria de interrupciones:

Grafica 4 Requisitos de informacinCasos de uso: es la forma de agrupar una serie de validaciones, reglas, funcionalidades, interaccin del usuario con el sistema, donde queda de manera organizada, los escenarios donde el usuario realizar alguna actividad, para lograr un objetivo especfico.Un caso de uso, tiene asociado una descripcin general, la cual relata su objetivo, tiene la definicin de los requisitos, tales como precondiciones y poscondiciones, que se deben tener, las restricciones, y el listado de actividades que se realizan en el escenario.En la Grfica 5 se ilustra un ejemplo de cmo quedan conformados los casos de uso, su relacin entre s y entre los actores, que son los encargados de activarlos, segn se requiera.

Grafica 5 Modelo de Casos de UsoCada caso de uso tiene agrupadas distintas funcionalidades, y permite un mejor entendimiento tanto al analista que realiz la especificacin, como al lder tcnico para su monitoreo y control.DESARROLLO DEL SISTEMAUna vez especificado el sistema y teniendo documentadas las reglas de negocio, las validaciones, la totalidad de requisitos etc., se inicia con la construccin del sistema.Para el caso del aplicativo para el clculo del ITAD, se inici la construccin por cada una de las iteraciones conformadas en el numeral 3.A cada una de las iteraciones se les asoci los casos de uso correspondientes.Una vez terminada el diseo, anlisis, codificacin, pruebas, el caso de uso queda listo para su montaje en ambiente de produccin.

Las pruebas fueron realizadas por una firma independiente a la casa de software, encargada de la construccin del sistema, esto permite una mayor verificacin de la calidad del producto, toda vez que es un tercero quien tiene que aprender sobre el sistema y efectuar validaciones estrictas.En este punto es importante mencionar, que al tener una documentacin clara, detallada, el entendimiento del problema y la posterior construccin de los casos de prueba, resulta una tarea ms eficiente, con menor reproceso.CONTROL Y DEFINICIN DE ITERACIONESAl dividir el sistema, se encontr una simplificacin de su complejidad, para efectos del seguimiento. Una forma como se conformaron las iteraciones del sistema fueron:Mdulo administrativo: en el cual el usuario, puede a su voluntad, administrar la informacin bsica necesaria para que el sistema funcione. Ejemplo: la configuracin de horarios de carga de informacin, la asignacin de Operadores de Red que hacen parte del esquema.Mdulo de cargas: para calcular el ITAD, se necesita de la informacin diaria de los eventos en los SDL. Para tal fin se cre un sistema que permite recibir la informacin, su correspondiente validacin en lnea y su posterior descarga.Mdulos de clculos: una vez se cuenta con los insumos, previamente validados, se procede con los clculos intermedios hasta llegar al ITAD.Mdulo de reportes: en este paquete, se encuentran todas las consultas que se requieren del sistema. Algunas pueden ser las fechas de carga, los valores de energa, las interrupciones entre otras.Bajo los cuatro mdulos anteriores, se hizo la jerarqua de iteraciones, en las cuales cada entregable, estaba asociado con los casos de uso de cada mdulo, cada uno previamente verificado y aprobado, por los lderes usuario encargados de la especificacin, y por los lderes tcnicos, encargados de la verificacin del funcionamiento tecnolgico.Al segmentar las entregas, se realiz un control ms detallado y es posible minimizar errores que pueden desencadenar efectos ms grandes, a medida que se va construyendo el sistema.As mismo al dividir en iteraciones, se llev un mejor seguimiento del cronograma de actividades y de los costos del proyecto.

CONCLUSIONES Y RECOMENDACIONESDefinitivamente un factor de xito en la construccin de software, consiste en tener en primera medida un claro entendimiento sobre el problema a resolver.Al mismo nivel, disponer de la especificacin en las distintas herramientas disponibles en el mercado, conformando artefactos auto contenido y claro, para que cualquier casa de software est en capacidad de construirlos.Construir software sin una metodologa clara, puede llevar a mayores reprocesos y costos, sin que la solucin definitiva quede documentada y sin tener la trazabilidad sobre los mdulos del sistema.Adicionalmente una vez se tiene el sistema debidamente documentado, su mantenimiento se facilita. As mismo en caso de cambios regulatorios, es ms fcil identificar el impacto, segn los casos de uso que se ven afectados por la nueva regla de negocio.RECOMENDACIONESAl dividir el problema por iteraciones, se facilita su control y seguimiento.La especificacin debe quedar detallada, clara y se debe validar que todo quede bien documentado.Modelar el proceso, antes de establecer los requisitos, ya que se adquiere una visin integral sobre el problema a resolver, y las soluciones encontradas, pueden ser ms efectivas.2.2.3 INGENIERA WEBLa ingeniera web es una nueva rea de la ingeniera del software que abarca procesos, tcnicas y modelos orientados a los entornos Web. Consiste en la aplicacin de metodologas sistemticas, disciplinadas y cuantificables al desarrollo eficiente, operacin y evolucin de aplicaciones web de alta calidad. Los principales mbitos de la ingeniera web incluyen, entre otros, los siguientes aspectos: Diseo de procesos de negocio para aplicaciones web. Herramientas CASE para aplicaciones web. Generacin de cdigo para aplicaciones web. Desarrollo web colaborativo. Modelado conceptual de aplicaciones web. Diseo de Modelos de datos para sistemas de informacin web. Entornos de desarrollo de aplicaciones web integrados. Herramientas de autor para contenido multimedia. Pruebas de rendimiento de aplicaciones basadas en web. Personalizacin y adaptacin de aplicaciones web. Modelado de procesos para aplicaciones web. Herramientas y mtodos de prototipado. Control de calidad y pruebas de sistemas. Ingeniera de requisitos para aplicaciones web. Aplicaciones para la Web Semntica. Factoras de software para la web. Mtodos, herramientas y automatizacin de pruebas para aplicaciones web. Aplicaciones web mviles y ubcuas. Usabilidad de aplicaciones web. Accesibilidad para la web. Metodologas de diseo web. Diseo de interfaces de usuario. Mtricas para la web, estimacin de costes y medicin. Gestin de proyectos web y gestin de riesgos. Desarrollo y despliegue de servicios web. En los ltimos aos existe una tendencia importante a reconocer que las aplicaciones basadas en el Web deben expresarse a un nivel de abstraccin mayor que aqul que ofrecen las primitivas propias de las plataformas tecnolgicas. OMG en los ltimos aos ha reconocido que el enfoque de modelado es una forma potente de especificar sistemas y as lo demuestra su estrategia Model Driven Architecture (MDA) con la cual se busca ofrecer al diseador la posibilidad de expresar la estructura, comportamiento y funcionalidad del sistema independientemente de los aspectos tecnolgicos y lograr con ello adems la posibilidad de una fcil integracin con otros sistemas. La Ingeniera Web Dirigida por Modelos (MDWE) es la aplicacin de la Arquitectura Dirigida por Modelos al campo del desarrollo de aplicaciones web donde puede resultar especialmente til debido a la evolucin continua de las tecnologas y plataformas web. En esta direccin existen propuestas de modelado de las cuales podemos destacar dos vertientes importantes: - Metodologas orientadas al diseo navegacional cuyo objetivo es construir aplicaciones hipermedia en sistemas estticos. La mayora de estas aproximaciones estn basadas en el Modelo Relacional clsico, o bien en extensiones de ste. Algunos ejemplos destacables de estas iniciativas son OOHDM, WebML, ADM, AutoWeb y RMM. - El otro grupo de aproximaciones se basan en la idea de extender los mtodos de desarrollo orientados a aplicaciones dinmicas tratando de introducir la semntica de la hipermedia como caracterstica inherente a este nuevo tipo de sistemas software. Este tipo de aproximaciones de introducir caractersticas navegacionales al modelo OO. En este grupo podemos encontrar los mtodos UWE, WSDM, EORM, OOW y OO-Method.METODOLOGAS A continuacin se comentan algunas de las metodologas enumeradas en el apartado anterior: UWE (UML-based Web Engineering) sirve para modelar aplicaciones web, y presta una especial atencin a la sistematizacin y personalizacin (sistemas adaptativos). Provee de perfiles UML, metamodelos, un proceso de desarrollo dirigido por modelos, y herramientas de soporte para el diseo sistemtico de aplicaciones web (ArgoUWE y MagicUWE). Utiliza notacin basada en UML 2.0 (OMG): para aplicaciones Web en general y para aplicaciones adaptativas en particular. La metodologa consta de seis modelos: o Modelo de casos de uso para capturar los requisitos del sistema. O Modelo conceptual para el contenido (modelo del dominio). O Modelo de usuario: modelo de navegacin que incluye modelos estticos y dinmicos. O Modelo de estructura de presentacin, modelo de flujo de presentacin. O Modelo abstracto de interfaz de usuario y modelo de ciclo de vida del objeto. O Modelo de adaptacin. Web Services Distributed Management (WSDM, se pronuncia wisdom) es una especificacin basada en servicios web para gestionar y monitorizar el estado de otros servicios. Es un estndar OASIS (Organization for the Advancement of Structured Information Standards), y WSDM consiste en dos especificaciones: o Management Using Web Services (MUWS): define como representar y como acceder a las interfaces de gestin de recursos expuestos como servicios web. Define un conjunto bsico de operaciones de gestin sobre los servicios, tales como identificacin, mtricas, configuracin y relaciones, adems de un formato de eventos estndar. O Management Of Web Services (MOWS): define como manejar servicios web como recursos y como describir y acceder a las capacidades de gestin utilizando MUWS. Esta especificacin permite a las aplicaciones de gestin de servicios web interoperar entre s. WebML (Web Modeling Language): Es una metodologa de modelado visual de aplicaciones web, centrada especialmente en las aplicaciones de uso intensivo de datos, separando el contenido de la informacin en pginas, navegacin y presentacin, que se pueden definir y desarrollar de forma independiente. Permite la especificacin de operaciones de manipulacin de datos para actualizar la aplicacin. Cuenta con cuatro perspectivas: el Modelo Estructural (de los datos de la aplicacin), el Modelo de Hipertexto (para cada hipertexto describe qu pginas lo componen, y cmo navegan), el Modelo de Presentacin (disposicin y apariencia grfica), y el Modelo de Personalizacin (para definir operaciones especficas para usuarios grupos de usuarios, ya que se almacenan como entidades en el Modelo Estructural). Dispone de una herramienta CASE (WebRatio). OOWS: Es una extensin del mtodo OO-Method (ya basado en modelos), al cual se le aaden a las tcnicas de modelado conceptual, capacidades de expresar la hipermedia inherente a las aplicaciones web. Consta de cinco modelos, que se especifican a continuacin: o El Modelo de Objetos define la estructura y las relaciones estticas entre clases identificadas en el dominio del problema. O En el Modelo Dinmico se describen las posibles secuencias de servicios y los aspectos relacionados con la interaccin entre objetos. O El Modelo Funcional captura la semntica asociada a los cambios de estado entre los objetos motivados por la ocurrencia de eventos o servicios. O El Modelo de Navegacin define la semntica navegacional asociada a las clases de los objetos del modelo. Es en este modelo donde se explicita la navegacin permitida en la aplicacin para cada agente del sistema, por lo que se realiza un mapa navegacional por cada uno, en el que se definen nodos (posibles puntos de interaccin con el usuario) y arcos (posibilidad de alcanzar otro nodo). A continuacin se muestra un ejemplo:El Modelo de Presentacin captura los requisitos bsicos de presentacin de informacin. Est fuertemente basado en el modelo de navegacin y permite definir, de una manera abstracta, la estructura lgica de presentacin de los objetos navegacionales en la interfaz de usuario. Esta metodologa tambin cuenta con un entorno de desarrollo para aplicaciones web (OOWS Suite). NDT (Navigational Development Techniques): Es una metodologa orientada a la Ingeniera Dirigida por Modelos (MDE). Aunque en un principio se centraba en las fases de ingeniera de requisitos y anlisis, se ha ido ampliando a otras fases del ciclo de vida. Define un conjunto de metamodelos para las fases de requisitos y anlisis, y una serie de transformaciones y reglas que permiten obtener los modelos de anlisis a partir de ellos. Los metamodelos se representan a partir de MOF (MetaObject Facility), mientras que las transformaciones se definen mediante QVT (Query/View/Transformation). Consta de una herramienta denominada NDT Suite. Todas estas metodologas necesitan transformar los modelos para generar aplicaciones web. Segn el framework MDA, las transformaciones se pueden aplicar para establecer un proceso de desarrollo trazable desde los modelos abstractos (CIM, PIM) a los modelos dependientes de la plataforma, incluso directamente a su implementacin. La mayora de las metodologas utilizan herramientas CASE para realizar estas transformaciones. Estas herramientas se basan en tcnicas de generacin de cdigo para obtener aplicaciones web a partir de un reducido conjunto de modelos conceptuales de diseo. Las transformaciones se pueden dividir en Transformaciones Modelo-a-Modelo, y Transformaciones Modelo-a-Cdigo. Las Transformaciones Modelo-a-Modelo se pueden separar en: Transformaciones verticales que convierten modelos de un mayor nivel de abstraccin en otros de un nivel menor. Transformaciones horizontales que describen el mapeo entre modelos del mismo nivel de abstraccin. Las transformaciones verticales utilizan lenguajes como QVT, ATL AGG. A veces incluso se definen como mecanismos de mezcla para introducir nuevos conceptos como estilos de arquitectura, requisitos de usuario, y medida de la calidad. Las transformaciones horizontales se utilizan para mantener la consistencia de las especificaciones de los modelos, comprobando que estos modelos no imponen requisitos contradictorios en sus elementos comunes. Las transformaciones Modelo-a-Cdigo se llevan realizando ms tiempo, aunque a menudo se han utilizado lenguajes de propsito general (C++, Java Python). Aunque un nuevo estndar del OMG ha establecido las caractersticas propias de los lenguajes de transformacin Modelo-a-Cdigo, y algunas herramientas han sido adaptadas para incluirlas.HERRAMIENTAS Y PLATAFORMAS Las metodologas comentadas anteriormente utilizan distintas herramientas para llevar a cabo diversas operaciones: ArgoUWE: Es una extensin de la herramienta de cdigo abierto ArgoUML a la cual se le han aadido capacidad de modelado, navegacin y estructuras de presentacin. WebTE: Es una herramienta de UML que soporta XMI permitiendo la introduccin de los modelos y transformaciones en un motor de transformacin que los ejecuta y produce una aplicacin web en JavaEE. WebRatio: Es una herramienta comercial que da soporte a la metodologa WebML. Trabaja con metamodelos basados en MOF, modelando los objetos de negocio mediante los estndares UML E/R mientras que el front-end se modela con WebML. A partir de aqu, para esos modelos se genera automticamente la aplicacin en la arquitectura JavaEE y las fuentes de datos SQL/XML. Eclipse Modelling Project (EMP): Proporciona una gran cantidad de facilidades de desarrollo dirigido por modelos de gran calidad, entre otros: o Un framework de modelado comn denominado EMF o Meta-editores como GMF (Graphical Modelling Framework) o Motores de transformacin como ATL o VIATRA, entre otros o Generadores de cdigo como MOFScript NDT Suite: Es un conjunto de herramientas para aplicar la metodologa NDT en entornos prcticos. Consta de las siguientes: o NDT-Profile es un perfil (profile) definido en la herramienta Enterprise Architect. Este perfil aporta diversas herramientas y artefactos propios de NDT. O NDT-Driver permite, a partir de un fichero de NDT-Profile como entrada, ejecutar las transformaciones automticamente, y a partir de los requisitos y los modelos obtiene prototipos HTML automticos. O NDT-Quality toma como entrada un fichero de Enterprise Architect y comprueba que la trazabilidad y las normas de NDT se cumplen. OOWS Suite: Es un entorno de desarrollo que da soporte a la metodologa OOWS. Se integra con la herramienta comercial OlivaNOVA, que implementa el proceso de desarrollo de O-Method. El entorno consta de un editor grfico denominado OOWS Visual Editor, el cual asocia a cada primitiva conceptual su representacin grfica o textual.EJEMPLO A continuacin se muestra el ejemplo del desarrollo de una aplicacin web para la compra de discos por internet: Existen dos tipos de usuarios, los Administradores y los Usuarios Navegantes. Mientras que los primeros se encargan de la gestin de los lbumes a la venta, los segundos son usuarios comunes (compradores). Las compras que realicen los Usuarios Navegantes se debern ir incluyendo, simblicamente, en una cesta de la compra; el usuario podr consultar en cualquier momento el contenido de su cesta y realizar modificaciones sobre su contenido. Esta cesta de la compra se crear en el momento en el que se reciba la peticin de entrada en el sistema y pertenecer al usuario que est navegando en ese momento; todas las operaciones que el usuario realice sobre el sistema se harn de forma annima, de modo que el usuario no deber identificarse (registrarse) hasta que no vaya a confirmar su compra; para comprar un lbum se deber llegar a l a travs del autor o de la categora a la que pertenece; desde la pgina de inicio podremos acceder a un listado de autores o a un listado de categoras y desde ah al listado de los lbumes del autor o de la categora que hayamos seleccionado; cuando seleccionemos un lbum de la lista, se mostrarn todos los datos de ese lbum y se podr comprar. Esto har que el lbum sea incluido en la cesta de la compra de ese usuario y que se muestre su contenido actual; mientras veamos el contenido de la cesta, podremos cambiar el nmero de unidades que se desea adquirir de cada lbum de los comprados hasta el momento o eliminar alguna de las compras de la cesta; cuando se decida confirmar la compra se realizarn dos acciones: la primera consistir en crear una factura (para lo que el comprador debe haberse identificado) y la segunda ser reducir el stock de los lbumes comprados; cuando se haya confirmado una compra, ya no se podr modificar el contenido de la cesta. Los administradores se encargan de gestionar y mantener el catlogo de productos del sistema, as como mantener la lista de autores que poseen discos en la tienda. El primer paso es la fase de la Especificacin del Problema, lo cual genera diagramas de casos de uso a partir de la funcionalidad encontrada en el anlisis de los requisitos. A continuacin se muestra el caso de uso para el agente Usuario Navegante.

En la fase de modelado conceptual se construyen los siguientes modelos: Modelo de Objetos, Modelo Dinmico, Modelo Funcional, Modelo Navegacional y Modelo de Presentacin. A continuacin se muestra el Modelo de Objetos, para realizar el cual se han estudiado los requisitos funcionales del sistema desde un punto de vista OO, asociando la funcionalidad a cada usuario segn los casos de uso mostrados en la fase anterior.

Despus del Modelo de Objetos, se construye el Modelo Dinmico donde se describen las vidas vlidas de los objetos representando el comportamiento de cada clase del sistema. A continuacin se muestra la parte del Modelo Dinmico para la clase Cesta.

El siguiente paso es el Modelo Funcional, el cual captura la semntica asociada a los cambios de estado de los objetos. Cada atributo ve modificado su valor dependiendo de la accin que activ el cambio de estado, de los argumentos del evento, y del estado actual de ese objeto. La siguiente figura muestra una parte del modelo para la clase Lnea, que contiene la evaluacin siguiente:

El Modelo de Navegacin es el siguiente paso, donde se estructura el acceso de cada usuario al sistema. A continuacin se muestra el mapa de navegacin del agente Usuario Navegante, con los contextos de navegacin definidos, y los servicios que se ejecutan al iniciar y finalizar sesin. Los contextos de exploracin (etiquetados como E) son los que tendr disponible siempre, y a partir de estos podra alcanzar los dems navegando por diferentes caminos.

Viendo ms en detalle el contexto Autores, se ve que se recupera la informacin sobre un autor (su nombre), sus lbumes que estn disponibles (ttulo, ao y precio) y el nombre de la categora del lbum. Seleccionando el ttulo de un lbum se puede navegar al contexto lbumes, donde se podrn ver detalles, y aadirlo a la cesta. Tambin se han definido una estructura de acceso que permitir acceder a los autores por su letra inicial, adems de un filtro de tipo aproximado (like) para facilitar la bsqueda por nombre.

Por ltimo, se construye el Modelo de Presentacin donde se definen los requisitos de presentacin de la informacin para cada contexto del Mapa de Navegacin. Por ejemplo, seguidamente se muestra la plantilla de presentacin asociada al contexto Autores.

Despus de la fase de construccin de los modelos, es necesario afrontar la segunda fase, Desarrollo de la Solucin, donde utilizando una estrategia de compilacin de modelos, se obtiene el prototipo software completo de manera automtica. A continuacin se muestra una posible interfaz de usuario que cumple los requisitos de navegabilidad y de interfaz del agente Usuario Navegante.

2.2.4 METODOLOGAS GILESLuego de varias opiniones tanto a favor como en contra de las metodologas tradicionales se generaun nuevo enfoque denominado, mtodosgiles, que nace como respuesta a los problemas detallados anteriormente y se basa en dos aspectos puntuales, el retrasar las decisiones y la planificacin adaptativa; permitiendo potencia anms el desarrollo de software a gran escala.Como resultado de esta nueva teora se crea unManifiesto gilcuyas principales ideas son:Los individuos y las interacciones entre ellos son ms importantes que las herramientas y los procesos empleados.Es ms importante crear un producto software que funcione que escribir documentacin exhaustiva.La colaboracin con el cliente debe prevalecer sobre la negociacin de contratos.La capacidad de respuesta ante un cambio es ms importante que el seguimiento estricto de un plan.Entre los principales mtodos giles tenemos el XP (eXtreme Programming), Scrum, Iconix, Cristal Methods, AUP entre otras.Estas metodologas ponen de relevancia que la capacidad de respuesta a un cambio es ms importante que el seguimiento estricto de un plan. Nos lo proponen porque para muchos clientes esta flexibilidad ser una ventaja competitiva y porque estar preparados para el cambio significar reducir su coste.Retrasar las decisionesy Planificacin AdaptativaEs el eje en cual gira la metodologa gil, el retrasar las decisiones tan como sea posible de manera responsable ser ventajoso tanto para el cliente como para la empresa, lo cual permite siempre mantener una satisfaccin en el cliente y por ende el xito del producto, las principales ventajas de retrasar las decisiones son: Reduce el nmero de decisiones de alta inversin que se toman. Reduce el nmero de cambios necesario en el proyecto. Reduce el coste del cambioLa planificacin adaptativa permite estar preparados para el cambio ya que lo hemos introducido en nuestro proceso de desarrollo, adems hacer una planificacin adaptativa consiste en tomar decisiones a lo largo del proyecto, estaremos transformando el proyecto en un conjunto de proyectos pequeos.Esta planificacin a corto plazo nos permitir tener software disponible para nuestros clientes y adems ir aprendiendo del feedbackpara hacer nuestra planificacin ms sensible, sea ante inconvenientes que aceleren o retrasen nuestro producto. A continuacin se detalla el XP que es el ms aceptado dentro del desarrollo de SW.Extreme---Programming---(XP)Es la ms destacada de los procesos agilesde desarrollo de software formulada por Kent Beck. La programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad.Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.Las caractersticas fundamentales del mtodo son:Desarrollo iterativo e incremental:pequeas mejoras, unas tras otras.Pruebas Unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo priebas de regresion. Se aconseja escribir el cdigo de la prueba antes de la codificacin.Programacin por parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata. Frecuente interaccindel equipo de programacin con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Correccinde todos los erroresantes de aadir nueva funcionalidad. Hacer entregas frecuentes.Refactorizacin:del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha introducido ningn fallo.Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados.Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta que en ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo.La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Mientras ms simple es el sistema, menos tendr que comunicar sobre este, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de programadores.Ventajas Apropiado para entornos voltiles Estar preparados para el cambio, significa reducir su coste. Planificacin ms transparente para nuestros clientes, conocen las fechas de entrega de funcionalidades. Vital para su negocio Permitir definir en cada iteracin cuales son los objetivos de la siguiente Permite tener realimentacin de los usuarios muy til. La presin esta a lo largo de todo el proyecto y no en una entrega final

Desventajas Delimitar el alcance del proyecto con nuestro clientePara mitigar esta desventaja se plantea definir un alcance a alto nivel basado en la experiencia.Ejemplo:Las metodologas giles se han convertido en los ltimos aos en los principales mtodos a seguir por la gran mayora de empresas de desarrollo de software. En 2001, diecisiete prestigiosos ingenieros, convocados por Kent Beck, crearon un manifiesto que dictaba doce principios bsicos sobre las metodologas giles.Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. Aceptamos que los requisitos cambien, incluso en etapas tardas del desarrollo. Los procesos giles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo ms corto posible. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecucin del trabajo. El mtodo ms eficiente y efectivo de comunicar informacin al equipo de desarrollo y entre sus miembros es la conversacin cara a cara. El software funcionando es la medida principal de progreso. Los procesos giles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. La atencin continua a la excelencia tcnica y al buen diseo mejora la Agilidad. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. Las mejores arquitecturas, requisitos y diseos emergen de equipos auto-organizado

A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para a continuacin ajustar y perfeccionar su comportamiento en consecuencia.A partir de estos principios, se definen diferentes metodologas reconocidas como giles basadas en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan mediante la colaboracin de grupos auto-organizados y multidisciplinarios. La forma de dirigir el desarrollo del proyecto cambia en comparacin a la forma tradicional, las etapas estn fraccionadas en unidades de requisitos que avanzan en diferente tiempo, por lo que permite mayor flexibilidad a la hora de seguir el proceso de ingeniera.Figura 1

Comparacin del mtodo tradicional respecto al mtodo gilEntre esta familia de metodologas destacan Scrum, Kanban, o eXtreme Programming. Cada una con sus peculiaridades, sus pros y sus contras. Aunque lo cierto es que como dijo Corey Ladas: El proceso de planificacin del trabajo ideal debera siempre ser proporcionado por el equipo de desarrollo con el mejor propsito para trabajar en lo siguiente, ni ms ni menos.. Por esa misma razn seguir una metodologa depender del equipo y despus del proyecto, pudiendo hibridar las metodologas para el ajuste correcto. En este proyecto se ha tomado como base la metodologa Scrumban y se han adoptado otras caractersticas de otras metodologas giles, hasta conseguir la metodologa de trabajo.

2.2.5 METODOLOGAS EMERGENTESICONIX:El proceso ICONIX se define como un proceso de desarrollo de software prctico. Est entre la complejidad de RUP y la simplicidad y pragmatismo de XP, sin eliminar las tareas de anlisis y diseo que XP no contempla.Es un proceso simplificado en comparacin con otros procesos ms tradicionales, que unifica un conjunto de mtodos de orientacin a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto. ICONIX presenta claramente las actividades de cada fase y exhibe una secuencia de pasos que deben ser seguidos. Adems, est adaptado a patrones y ofrece el soporte UML, dirigido por Casos de Uso y es un proceso iterativo e incremental.Las tres caractersticas fundamentales de ICONIX son: Iterativo e incremental:varias interacciones ocurren entre el modelo del dominio y la identificacin de los casos de uso. El modelo esttico es incrementalmente refinado por los modelos dinmicos. Trazabilidad:cada paso est referenciado por algn requisito. Se define la trazabilidad como la capacidad de seguir una relacin entre los diferentes artefactos producidos Dinmica del UML:la metodologa ofrece un uso dinmico del UML como los diagramas del caso de uso, diagramas de secuencia y de colaboracin.Las tareas que se realizan en la metodologa ICONIX son:

Anlisis de requisitos Anlisis y diseo preliminar Diseo Implementacin

Fundamentos de los procesos Tiene que ser lo suficientemente flexible como para adaptarse a diferentes estilos y tipos de problemas. Hay que apoyar la forma de trabajo del personal (incluidos los prototipos ydesarrollo iterativo / incremental). Sirve como una gua para los menos experimentados Expone los productos anteriores al cdigo de manera estndar y comprensible.Fases de ICONIXRevisin de los requisitos/ Anlisis de Requisitos: Identificar en el mundo real, los objetos y todas las relaciones de agregacin y generalizacin entre ellos. Se deben analizar todos los requisitos formaran parte del sistema y con estos construir el diagrama de clases, que representa las agrupaciones funcionales que estructuraran el sistema en desarrollo.Para esta fase se utilizan 3 herramientasModelo de Dominio: esto se refiere a identificar objetos y cosas del mundo real que intervienen con nuestro sistema. (Esttico)Modelo de Casos de Uso: describe las acciones o el comportamiento que un usuario realiza dentro del sistema. Comprende de actores, casos de uso y el sistema.Prototipo de Interfaz de Usuario: implica la creacin de un modelo o modelos operativos del trabajo de un sistema, en el que analistas y clientes deben estar de acuerdo. (Dinmico/ los usuarios se hacen participantes activos en el desarrollo)Revisin del diseo preliminar /Anlisis y Diseo PreliminarEn esta fase a partir de cada caso de uso se obtendrn una ficha de caso de uso, (la cual no pertenece a UML) , est formada por