Modelo Cascada

Ingeniera del Software II 1/17/2005Richard Rojas #01-34587

Israel Boucchechter # 97-29307 Ciclos de Vida de Ingeniera del Software

Modelo en Cascada(Bennington 1956):

El ms conocido, esta basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades:

Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algn subconjunto de estos requisitos al software.Anlisis de los requisitos del software: el proceso de recopilacin de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces requeridas.

Diseo: el diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz. El proceso de diseo traduce los requisitos en una representacin del software con la calidad requerida antes de que comience la codificacin.Codificacin: el diseo debe traducirse en una forma legible para la maquina. El paso de codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada la codificacin puede realizarse mecnicamente.Prueba: una vez que se ha generado el cdigo comienza la prueba del programa. La prueba se centra en la lgica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.Mantenimiento: el software sufrir cambios despus de que se entrega al cliente. Los cambios ocurrirn debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos perifricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.

Desventajas: Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicacin del paradigma. Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. El ciclo de vida clsico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos. El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estar disponible una versin operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.

La ventaja de este mtodo radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.Modelo V (Ministerio de Defensa de Alemania, 1992):

El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolucin del mismo.

Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integracin asociado a cada una de las etapas de la mitad anterior.

Se puede identificar una ventaja principal con respecto al Modelo Cascada ms simple, y se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de cascada.

Desventajas: El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptacin al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementacin, lo que puede traer como consecuencia un roll-back de todo un proceso que cost tiempo y dinero. El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir. Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo que disminuye el riesgo.

A pesar de todo lo antes mencionado, definitivamente se trata de un modelo ms robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada.Paradigma incrementar

El modelo incremental combina elementos del modelo en cascada con la filosofa interactiva de construccin de prototipos. Se basa en la filosofa de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software.

Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, slo con los requisitos bsicos. Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y tambin una plataforma para la evaluacin.

VentajasEntre las ventajas que puede proporcionar un modelo de este tipo encontramos las siguientes:

Mediante este modelo se genera software operativo de forma rpida y en etapas tempranas del ciclo de vida del software.

Es un modelo ms flexible, por lo que se reduce el coste en el cambio de alcance y requisitos.

Es ms fcil probar y depurar en una iteracin ms pequea.

Es ms fcil gestionar riesgos.

Cada iteracin es un hito gestionado fcilmente

Paradigma evolutivoModelo evolutivo Basado en Componentes

definicin:Un componente es una pieza de cdigo pre-elaborado que encapsula alguna funcionalidad expuesta a travs de interfaces estndar.

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 esta 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:A manera de ejemplo, pensemos en un equipo de sonido con cada una de sus piezas o componentes; es probable que por separado puedan ser funcionales, pero para que verdaderamente desempeen la funcin que deberan, tienen que estar unidas formando un todo.Paradigma espiralEste modelo, propuesto por Bohem en 1988 [BOE88], es un modelo de proceso de software evolutivo que acompaa la naturaleza evolutiva de con los aspectos controlados y sistemticos del ciclo de vida tradicional. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. En este modelo, el sistema se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones se producen versiones cada vez ms completas de ingeniera del sistema. .

El Modelo en Espiral se divide en un nmero de actividades estructurales, tambin llamadas "regiones de tareas" . Generalmente existen entre tres y seis regiones de tareas:

Comunicacin con el cliente.- Las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente, sea revisar especificaciones, plantear necesidades, etc.

Planificacin.- Las tareas requeridas para definir recursos, tiempos e informacin relacionada con el proyecto.

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

Ingeniera.- Las tareas requeridas para construir una o ms representaciones de la aplicacin

Construccin y adaptacin.- Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.

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

Cada una de las regiones estn pobladas por una serie de tareas que se adaptan a las caractersticas del proyecto que va a emprenderse. Para proyectos pequeos el nmero de tareas y su formalidad es bajo, para proyectos mayores y ms crticos, cada regin contiene tareas que se definen para lograr un nivel ms alto de formalidad.

Paradigma prototipoEscrito por rguerrero334 el 20-10-2007 en General. Comentarios (14)

Este modelo consiste en un procedimiento que permite al equipo de desarrollo disear y analizar una aplicacin que representa el sistema que sera implementado (McCracken y Jackson, 1982). Dicha aplicacin, llamada prototipo, est compuesta por los componentes que se desean evaluar (i.e. las funciones principales). Las etapas del modelo son:- Investigacin preliminar.- Colecta y refinamiento de los requerimientos y proyecto rpido:- Anlisis y especificacin del prototipo.- Diseo y construccin del prototipo.- Evaluacin del prototipo por el cliente.- Renacimiento del prototipo.- Diseo tcnico.- Programacin y test.-- Operacin y mantenimiento.

Para construir un prototipo del software se aplican los siguientes pasos:PASO 1. Evaluar la peticin del software y determinar si el programa a desarrollar es un buen candidato para construir un prototipo.Debido a que el cliente debe interaccionar con el prototipo en los ltimos pasos, es esencial que: 1) el cliente participe en la evaluacin y refinamiento del prototipo, y 2) el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. Finalmente, la naturaleza del proyecto de desarrollo tendr una fuerte influencia en la eficacia del prototipo.PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representacin abreviada de los requerimientos.Antes de que pueda comenzar la construccin de un prototipo, el analista debe representar los dominios funcionales y de informacin del programa y desarrollar un mtodo razonable de particin. La aplicacin de estos principios de anlisis fundamentales, pueden realizarse mediante los mtodos de anlisis de requerimientos.PASO 3. Despus de que se haya revisado la representacin de los requerimientos, se crea un conjunto de especificaciones de diseo abreviadas para el prototipo.El diseo debe ocurrir antes de que comience la construccin del prototipo. Sin embargo, el diseo de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseo de datos, en vez de hacia el diseo procedimental detallado.PASO 4. El software del prototipo se crea, prueba y refinaIdealmente, los bloques de construccin de software preexisten se utilizan para crear el prototipo de una forma rpida. Desafortunadamente, tales bloques construidos raramente existen.Incluso si la implementacin de un prototipo que funcione es impracticable, es escenario de construccin de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interaccin hombre-maquina usando una serie de hojas de historia.PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba" de la aplicacin y sugiere modificaciones.Este paso es el ncleo del mtodo de construccin de prototipo. Es aqu donde el cliente puede examinar una representacin implementada de los requerimientos del programa, sugerir modificaciones que harn al programa cumplir mejor las necesidades reales.PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estn formalizados o hasta que el prototipo haya evolucionado hacia un sistema de produccin.El paradigma de construccin del prototipo puede ser conducido con uno o dos objetivos en mente: 1) el propsito del prototipado es establecer un conjunto de requerimientos formales que pueden luego ser traducidos en la produccin de programas mediante el uso de mtodos y tcnicas de ingeniera de programacin, o 2) el propsito de la construccin del prototipo es suministrar un continuo que pueda conducir al desarrollo evolutivo de la produccin del software. Ambos mtodos tienen sus meritos y ambos crean problemas.Modelo ganar-ganar

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.

2.2.2 proceso unificadoLa metodologa de UP, es un mtodo iterativo de diseo de software que describe cmo desarrollar software de forma eficaz, utilizando tcnicas probadas en la industria.

El Proceso Unificado de Desarrollo de Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, enfocado en el riesgo, y por ser iterativo e incremental.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos.

El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Es una metodologa orientada a conducir el proceso de desarrollo de software en sus aspectos tcnicos; los flujos y productos de trabajo de UP no incluyen la administracin del proyecto.

UP Divide El Trabajo De Desarrollo De Software En Cuatro Fases:

Fase de Inicio en UP:En esta fase corresponde definir el negocio. Es la etapa donde se define la factibilidad del proyecto a realizar, se representa el modelo de negocio, visin y metas del proyecto, se identifican actores, conceptos de dominio y deseos de usuario. Adicionalmente se complementa con la definicin de la arquitectura preliminar, y estimaciones (imprecisas, preliminares) de plazos y costos. Tambin se define la viabilidad del proyecto.

Fase de Elaboracin en UP:En la fase de elaboracin se obtiene la visin refinada del proyecto a realizar, la implementacin iterativa del ncleo central de la aplicacin, la resolucin de los riesgos ms altos, la identificacin de nuevos requisitos y nuevos alcances, y estimaciones ms ajustadas. A esta altura existe la posibilidad de detener el proyecto por complejidad tcnica.

Fase de Construccin en UP:La fase de construccin es la implementacin iterativa del resto de los requisitos de menor riesgo y elementos ms sencillos. Es la evolucin hasta convertirse en un producto listo, incluyendo todos los requisitos (100%), para entregarse al Cliente. Al final de esta fase el sistema contiene todos los casos de uso que el cliente y la direccin del proyecto han acordado. La mayora de los casos de uso que no se desarrollaron en la fase anterior se desarrollan en iteraciones, en grupos de requisitos o casos de uso durante esta fase.

Fase de Transicin en UP:Es el periodo donde el producto es completamente entregado al cliente para ser testeado y desplegado (instalado).

Caractersticas Est dirigido por casos de uso (vase la seccin sobre UML).

Est centrado en la arquitectura (es decir, en una solucin de conjunto.

Tiene un ciclo de vida iterativo incremental (vase ms adelante).

Ventajas: Su uso es libre (como decir barra libre, sin condiciones).

Hay excelentes textos, que explican la aplicacin de este proceso paso a paso, como UML y patrones, de Craig Larman, publicado por Pearson-Prentice Hall (Segunda Edicin, Madrid, 2003).

Desventaja: Es necesario aterrizar los conceptos, lo cual puede resultar un poco difcil para quien no tenga experiencia en el uso de procesos de ingeniera de software.

2.2.3 ingeniera webLa ingeniera de la Web es la aplicacin de metodologas sistemticas, disciplinadas y cuantificables al desarrollo eficiente, operacin y evolucin de aplicaciones de alta calidad en la World Wide Web. En este sentido, la ingeniera de la Web hace referencia a las metodologas, tcnicas y herramientas que se utilizan en el desarrollo de aplicaciones Web complejas y de gran dimensin en las que se apoya la evaluacin, diseo, desarrollo, implementacin y evolucin de dichas aplicaciones.La ingeniera web se debe al crecimiento desenfrenado que est teniendo la Web est ocasionando un impacto en la sociedad y el nuevo manejo que se le est dando a la informacin en las diferentes reas en que se presenta ha hecho que las personas tiendan a realizar todas sus actividades por esta va.

La ingeniera web Es el proceso utilizado para crear, implantar y mantener aplicaciones y sistemas Web de alta calidad

Ingeniera Web ofrece una solucin de comercio electrnico a las empresas que han decidido comercializar y administrar sus productos a travs de Internet mediante una tienda virtual y que adems es la aplicacin de metodologas sistemticas, disciplinadas y cuantificables al desarrollo eficiente, operacin y evolucin de aplicaciones de alta calidad en la World Wide Web.

La Ingeniera de la Web no es un clon o subconjunto de la ingeniera de software aunque ambas incluyen desarrollo de software y programacin, pues a pesar de que la Ingeniera de la Web utiliza principios de ingeniera de software, incluye nuevos enfoques, metodologas, herramientas, tcnicas, guas y patrones para cubrir los requisitos nicos de las aplicaciones web. Adems, existen ciertos aspectos que van ligados a la ingeniera web y que son de mucha utilidad para las aplicaciones que realicen, aqu los ms importantes para m: Diseo de procesos de negocio para aplicaciones web Generacin de cdigo para aplicaciones web Desarrollo web colaborativo Ingeniera web emprica Entornos de desarrollo de aplicaciones web integrados2.2.4 metodologas agilesEl desarrollo gil de software son mtodos de ingeniera del software basado en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboracin de grupos auto organizado y multidisciplinario. Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos desarrollando software en lapsos cortos. El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar de una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener una demo (sin errores) al final de cada iteracin. Al final de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto.Los mtodos giles enfatizan las comunicaciones cara a cara en vez de la documentacin. La mayora de los equipos giles estn localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en ingls). La oficina debe incluir revisores, escritores de documentacin y ayuda, diseadores de iteracin y directores de proyecto. Los mtodos giles tambin enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los mtodos giles son criticados y tratados como "indisciplinados" por la falta de documentacin tcnica.Algunos mtodos giles de desarrollo de software: Adaptive Software Development (ASD). Agile Unified Process (AUP). Crystal_Clear Essential Unified Process (EssUP). Feature Driven Development (FDD). Lean Software Development (LSD). Kanban. Open Unified Process (OpenUP). Programacin Extrema (XP). Mtodo de desarrollo de sistemas dinmicos (DSDM). Scrum. G300.2.3 reingenieraReingeniera de Software es una forma de modernizacin para mejorar las capacidades y/o mantenibilidad de los sistemas de informacin heredados mediante la aplicacin de tecnologas y prcticas modernas. La Reingeniera de Software ofrece una disciplina de preparacin para migrar un sistema de informacin heredado hacia un sistema evolucionable. El proceso aplica principios de ingeniera para un sistema existente para encontrar nuevos requerimientos.La reingeniera cuenta entre sus objetivos con: Proporcionar asistencia automatizada para el mantenimiento. Reducir los errores y costos del mantenimiento Incrementar la intercambialidad del grupo de mantenimiento Hacer sistemas fciles de entender, cambiar y probar. Habilitar la conversin y migracin de sistemas. Reforzar el apego a estndares. Mejorar la respuesta a peticiones de mantenimiento. Mejorar el estado de animo del grupo de mantenimiento. Proteger y extender la vida del sistema. Usar CASE para apoyar sistemas existentes. Re-usar componentes de sistema existentes.Hacer Reingeniera de un sistema de software, segn Ian Sommerville, tiene dos ventajas clave sobre aproximaciones ms radicales a la evolucin del sistema:Riego reducido. Existe un alto riesgo en volver a desarrollar software critico para los negocios. Pueden cometerse errores en la especificacin, o puede haber problemas en el desarrollo. Los retrasos en la introduccin del nuevo software pueden significar perdidas en el negocio e incurrir en costes adicionales. Por ejemplo, en 1999 una gran compaa de comida de EU tuvo retrasos en la introduccin de un nuevo sistema de pedidos, lo que condujo a retrasos en las entregas de productos valoradas en 100 millones de dlares en una estacin de mxima venta.Coste reducido. El coste de hacer reingeniera es significativamente menor que el coste de desarrollar nuevo software. Ulrich cita un ejemplo de un sistema comercial en el que los costes de reimplementacin se estimaron en 50 millones de dlares. Al sistema se le aplico reingeniera con xito por 12 millones de dlares. Se presume que, con la tecnologa moderna del software, el coste relativo de la reimplementacion probablemente sea menor. Pero aun as supera de forma considerable los costes de la reingeniera.Desventaja:La principal desventaja de la reingeniera del software es que existen limites prcticos a la extensin del sistema que puede ser mejorada mediante reingeniera. No es posible. Por ejemplo, convertir un sistema diseado utilizando una aproximacin funcional en un sistema orientado a objetos. Los cambios arquitectnicos mayores o la reorganizacin radical de la gestin de datos del sistema no pueden realizarse de forma automtica, por lo que se incurrir en costes adicionales elevados. Aunque la reingeniera puede mejorar la mantenibilidad, el sistema al que se va a aplicar reingeniera probablemente no ser tan mantenible como un nuevo sistema desarrollado utilizando mtodos modernos de ingeniera de software.Durante la reingeniera del programa, los datos del sistema tambin sufren reingeniera.Las actividades de este proceso de reingeniera son:1. Traduccin del cdigo fuente. El programa es convenido desde un lenguaje de programacin antiguo a una versin ms moderna del mismo lenguaje o a un lenguaje diferente.

2. Ingeniera Inversa. El programa se analiza y se extrae informacin a partir de l. Esto ayuda a documentar su organizacin y funcionalidad.

3. Mejora de la estructura de los programas. La estructura de control del programa se analiza y modifica para hacerla ms fcil de leer y comprender.

4. Popularizacin de los programas. Se agrupan las panes relacionadas del programa y se elimina la redundancia en donde resulta adecuado. En algunos casos. esta etapa puede implicar una transformacin arquitectnica en la que un sistema centralizado pensado para una nica computadora se modifica para ejecutarse sobre una plataforma distribuida.

5. Reingeniera de datos. Los datos procesados por el programa se cambian para reflejar los cambios en l.

Aunque la reingeniera se usa principalmente durante el mantenimiento del software, va mas all de una simple ayuda de mantenimiento. La reingeniera es el puente desde las viejas hacia las nuevas tecnologas que las organizaciones deben usar en la actualidad para responder al cambio de requerimientos del negocio.Mtodos y Procesos en la Metodologa gil

De entre todos los mtodos de desarrollo gil, estos son los 3 que actualmente dominan el panorama:

1. SCRUM

Scrum-Team

El Scrum es un proceso de la Metodologa gil que se usa para minimizar los riesgos durante la realizacin de un proyecto, pero de manera colaborativa.

Entre las ventajas se encuentran la productividad, calidad y que se realiza un seguimiento diario de los avances del proyecto, logrando que los integrantes estn unidos, comunicados y que el cliente vaya viendo los avances. La profundidad de las tareas que se asignan en SCRUM tiende a ser incremental, caso que coincide exactamente con el devenir normal de un desarrollo.

Es perfecto para empresas de desarrollo de software orientadas a varios clientes. Esta por otro lado es la metodologa que se utiliza en I2B.

2. XP o Extreme Programming

La programacin extrema es un proceso de la Metodologa gil que se aplica en equipos con muy pocos programadores quienes llevan muy pocos procesos en paralelo. Consiste entonces en disear, implementar y programar lo ms rpido posible, hasta en casos se recomienda saltar la documentacin y los procedimientos tradicionales. Se fundamenta en la capacidad del equipo para comunicarse entre s y las ganas de aprender de los errores propios inherentes en un programador.

La gran ventaja de XP es su increble capacidad de respuesta ante imprevistos, aunque por diseo es una metodologa que no construye para el largo plazo y para la cual es difcil documentar.

XP es un mtodo estupendo para equipos extremadamente pequeos que se centran en un solo cliente.

3. Desarrollo Ligero o Lean

Tambin conocido como Lean Programming, este es un conjunto de tcnicas que engloban un proceso de la Metodologa gil en desarrollo de software orientado a conseguir exactamente lo que necesita el cliente. Es una evolucin del Mtodo Toyota de Produccin aplicado al desarrollo y que est muy de moda entre los equipos de desarrollo en startups.

Principalmente se identifica por hacer uso de ciclos de evolucin de software incrementales en los que se alejan las decisiones lo ms posible hasta no tener retroalimentacin por parte del cliente y con esto reaccionar de modo ms flexible posible contra sus posibles necesidades. Por esto mismo de provenir de una metodologa Japonesa de trabajo se fundamenta en tener un equipo muy capaz y comprometido al principio del aprendizaje continuo.

El Desarrollo Lean una metodologa fantstica para empresas que estn desarrollando un software B2C orientado a tener xito en el mercado.

Beneficios de aplicar la Metodologa gil

1.RSI superior

Cuando se lidia con proyectos mltiples y no se aplican metodologas gil, lo normal es esperar a que se complete un proceso antes de arrancar con el segundo. Para poder lidiar con este tipo de operacin de proyectos se estila buscar el cmo finalizar entregas lo ms pronto posibles lo cual significa un inmenso riesgo de recorte de funcionalidades o calidad.

El desarrollo con metodologa gil refuerza las entregas mltiples lo cual contra el cliente es un indicador operante y de cierto modo representara un capital en trabajo. Como tal se refuerza ms bien la lista de funcionalidades del acuerdo de entrega y en el promedio implica un enfoque en desarrollar la funcionalidad que se considere ms vital para el proyecto desde el simple inicio.

2.El desarrollo gil aumenta la productividad

La produccin de software que trabaja alrededor de las necesidades de negocio implica ingresar conocimiento multidisciplinario en etapas simultneas. La metodologa gil sirve para enfocar la atencin de los partidos por disciplina en el espacio que se les necesita e inmediatamente liberar el talento para que puedan moverse entre zonas de trabajo.

Aplicar un sistema de tarea discretas contra las personas que las ejecutan simplifican la distribucin de entrega de informacin y consecuentemente del mismo sentido de capacidad de control del mismo empleado lo cual resulta en un deseo inherente de procesar las tareas lo ms simple y rpidamente posible.

3.Simplifica el manejo de la sobrecarga de procesos

Los equipos que trabajan sobre normas y regulaciones han de validar su trabajo constantemente lo cual representa un doble sentido de trabajo. Las metodologas por iteracin simplifican el proceso de entrega versus validacin lo cual adems permite adoptar cambios sobre la marcha del alcance del proyecto.

4.Mejor perfil de productividad

Los equipos giles son ms productivos que aquellos que utilizan mtodos tradicionales a lo largo de todo el ciclo de desarrollo. Si no se aplica un sistema gil se presenta un patrn de desarrollo tipo palo de hockey donde la mayora del trabajo sucede en las primeras etapas y ya que anden los equipos se van haciendo ajustes sobre el trabajo anterior. La realidad es que casi nunca suele suceder que las piezas en equipo terminan trabajando juntos de manera coherente.

Los equipos giles que mantienen un nivel de revisin por unidades discretas de entrega de trabajo con cada iteracin permiten realizar pruebas de rendimiento y sistemas desde el principio. De este modo, defectos crticos como problemas de integracin se descubren antes, la calidad general del producto es mayor y el equipo funciona de manera ms productiva durante todo el ciclo de desarrollo.

5.Una mejor gestin del riesgo

No siempre se logra cumplir con las metas de lanzamiento cuando se trabaja con software, mientras ms lejanas sean las entregas contra cliente o equipo ms se maximiza el riesgo de potencial desviacin de la entrega contra la definicin del proyecto inicial. Las metodologas gil permiten repasar en ciclos continuos progreso in media res de entregables y productos semi-cerrados. Cuando fallan las entregas la metodologa gil permite ajustar el ciclo de trabajo para enfocar el talento en zonas de mayor o menor riesgo a justificacin de defender un proyecto en su totalidad.Bibliografas

http://isw-udistrital.blogspot.mx/2012/09/ingenieria-de-software-i.htmlhhttp://www.sites.upiicsa.ipn.mx/polilibros/portal/polilibros/P_externos/Administracion_informatica_de_las_organizaciones_Ramon_E_Enriquez_Gonzalez/AIO2_Mod_ESPIRAL.htmlttp://gproyectos-s4b.blogspot.mx/2010/09/modelo-evolutivo-basado-en-componentes.htmlhttp://rguerrero334.blogspot.es/1192897080/http://ithuejutlajoseluisvite.blogspot.mx/http://ithuejutlajoseluisvite.blogspot.mx/http://www.i2btech.com/blog-i2b/tech-deployment/5-beneficios-de-aplicar-metodologias-agiles-en-el-desarrollo-de-software/Ingeniera y Anlisis del Sistema

Anlisis de los Requisitos

Diseo

Codificacin

Prueba

Mantenimiento

ANALISIS DE

REQUERIMIENTOS

DISEO DEL

SISTEMA

DISEO

DETALLADO

IMPLEMENTACION

DE PROGRAMAS Y

PRUEBA UNITARIA

PRUEBA DEL

SISTEMA

PRUEBA DE

ACEPTACION

OPERACION

Y MANTENIMIENTO

PRUEBA DE

INTEGRACION

Plan de Pruebas de Integracin

Verificar diseo

Plan de Pruebas del Sistema

Validar requerimientos

Plan de Pruebas de Aceptacin

Los planes de prueba son el nexo entre el desarrollo y la verificacin

Ingeniera del Software: Un enfoque practico, Roger S. Presuman, 3ra Edicin, Pag. 26-30.