Metodologa

Caractersticas Similares

Caractersticas Principales
Es aplicable en donde existen ocasiones en que los requisitos de un problema se entienden de una manera razonable y deben estar bien definidos. Es el ms utilizado. Es una visin del proceso de desarrollo de software como una sucesin de etapas que producen productos intermedios. Para que el proyecto tenga xito deben desarrollarse todas las fases. Las fases continan hasta que los objetivos se han cumplido. Si se cambia el orden de las fases, el producto final ser de inferior calidad.

Etapas
Anlisis y definicin de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Se define una especificacin del sistema. Diseo del sistema y del software. El proceso de diseo del sistema divide los requerimientos en sistemas hardware o software. Establece una arquitectura completa del sistema. El diseo del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones. Implementacin y prueba de unidades. Durante esta etapa, el diseo del software se lleva a cabo como un conjunto o unidades de programas. Integracin y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software. Funcionamiento y mantenimiento. El sistema se instala y se pone en funcionamiento prctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida.

Desventajas
Con frecuencia es difcil para el cliente establecer todos los requisitos de manera explcita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. El cliente debe tener paciencia. Una versin que funcione de los programas estar disponible cuando el proyecto est muy avanzado. Un error grave ser desastroso si no se detecta antes de la revisin del programa. Iteraciones suelen ser muy costosas. Los problemas que se presentan son corregidos posteriormente. Puede que el software no cumpla con los requisitos del usuario o Cliente. Es difcil incorporar nuevas cosas si se quiere actualizar. Es normal detenerse en su desarrollo y seguir con otras fases. Se tarda mucho tiempo en pasar por todo el ciclo Las revisiones de proyectos de gran complejidad son muy difciles

Las caractersticas de ste modelo similares a otras metodologas son las siguientes: Inicia con la especificacin de requerimientos del cliente y contina con la planeacin, el modelado, la construccin y el despliegue para culminar en el soporte del software terminado. Las caractersticas similares de sta metodologa a las otras, se basa prcticamente en el mtodo Modelo en que se usa y el objetivo que se Cascada busca al implementar sta metodologa de Software. Se puede decir que como las dems metodologas tienen un proceso en el cual, primeramente es la entrevista con el usuario para establecer las necesidades y requerimientos, para seguir con el diseo la codificacin y la evaluacin por parte del Cliente, as tambin el Modelo en Cascada. Las caractersticas que hacen similar sta metodologa a las dems son las siguientes: Se puede utilizar como un modelo del proceso independiente. 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. Se plantea con rapidez una iteracin de construccin de prototipos y se presenta el modelado (en forma de un diseo Modelo en rpido). Construccin de Esto se realiza al estar Prototipos escuchando los requerimientos por parte del Usuario o por parte del Cliente

Pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero. El diseo rpido se basa en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final. El diseo rpido conduce a la construccin de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-mquina. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduce costos y aumenta la probabilidad de xito. Exige disponer de las herramientas adecuadas. Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera.

Plan rpido. Modelado, diseo rpido. Construccin del Prototipo. Desarrollo, entrega y retroalimentacin. Comunicacin.

Para la consideracin de las desventajas de sta metodologa se tiene que contemplar que a los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construccin de prototipos se torna problemtica por las siguientes razones: El cliente ve funcionando lo que para el es la primera versin del prototipo que ha sido construido con chicle y cable para embalaje, y puede decepcionarse al indicarle que el sistema aun no ha sido construido. El desarrollador puede caer en la tentacin de aumentar el prototipo para construir el sistema final sin tener en cuenta las obligaciones de calidad y de mantenimiento que tiene con el cliente.

Modelo Incremental

Se entrega software por partes funcionales ms pequeas pero reutilizables, a los cuales se les llama incrementos. El producto esencial queda en manos del cliente (o se somete a una evaluacin detallada). Este proceso se repite despus de la entrega de cada incremento mientras no se haya elaborado el producto completo. Aplica secuencias lineales de manera escalonada. Cada incremento se construye sobre aquel que ya fue entregado. Las caractersticas similares de sta metodologa a las otras es que como en las dems se lleva a cabo un etapa en la que se inicia con entrevistas al cliente o usuario, despus se disea, se implementa y el usuario lo valida haciendo los comentarios y modificaciones pertinentes. Despus de este ciclo se lleva a cabo otro en el cual despus de sta entrega y la valoracin del usuario, se realizan los mismos pasos desde el inicio para hacer una modificacin o reajuste al programa.

Combina elementos del modelo en cascada aplicado en forma iterativa. Cada secuencia lineal produce "incrementos" del software. Al utilizar un modelo incremental el primer incremento es un producto esencial. El modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo. Es til sobre todo cuando el personal necesario para una implementacin completa no est disponible. Es posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que permitira la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados. Se diferencia de los dems modelos por considerar el riesgo. Es actualmente el enfoque ms realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo, permitiendo al desarrollador y al cliente entender y reaccionar ante los riesgos en cada nivel evolutivo. Las caractersticas que se pueden indicar del modelo en espiral son: El software se desarrolla en una serie de versiones incremntales. Durante las primeras iteraciones. La versin incremental podra ser un modelo en papel o un prototipo. A medida que se va incrementando el nmero de iteraciones, se producen versiones cada vez ms completas.

Anlisis-Diseo-Cdigo-Pruebas Entrega de 1er Incremento Anlisis-Diseo-Cdigo-Pruebas Entrega de 2 incremento Anlisis-Diseo-Cdigo-Pruebas Entrega de 3er incremento Anlisis-Diseo-Cdigo-Pruebas Entrega de 4o incremento

Modelo Vida Espiral

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. Se presupone que todos los requisitos se han definido al inicio. Se requiere de una experiencia importante para definir los incrementos de forma de distribuir en ellos las tareas en forma proporcional Si el sistema a desarrollar es de gran magnitud y se cuenta con un nico grupo para construirlo se corre el riesgo que el desarrollo se prolongue demasiado en tiempo En sta metodologa se manejan los ciclos y Resulta difcil convencer a grandes clientes para cada ciclo se manejan cuatro actividades los de que el enfoque evolutivo es controlable. cuales son los siguientes: Debido a su elevada complejidad no se aconseja utilizarlo en pequeos sistemas. Determinar Objetivos. Genera mucho tiempo en el desarrollo del Anlisis del riesgo. sistema Planificacin. Modelo costoso Desarrollar y probar. Requiere experiencia en la identificacin de riesgos. Los modelos en espiral funcionan mejor para los grandes proyectos solamente, donde los costos son mucho ms altos y los requisitos del sistema de pre implica un mayor nivel de complejidad. El modelo de espiral las necesidades de cualificacin en la evaluacin de una amplia incertidumbres o riesgos asociados con el proyecto y su reduccin. Los modelos en espiral trabajar en un protocolo, que debe ser seguido estrictamente para su buen funcionamiento. Algunas veces se vuelve difcil de seguir este protocolo. La evaluacin de los riesgos involucrados en el proyecto puede disparar hasta el costo y puede ser mayor que el costo de la construccin del sistema. No es un requisito para una explicacin ms detallada de los pasos involucrados en el proyecto, como avance, el plan, los puestos de control y el procedimiento estndar.

Las siguientes caractersticas son las que hacen a sta metodologa muy similar a las dems: La arquitectura del proceso se modela con orientacin a objetos. Es un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Y tambin como caracterstica similar a los dems es que sta metodologa es iterativo e incremental ya que despus de cada siclo se le hacen modificaciones al programa.

Proceso Unificado de Desarrollo

es una metodologa orientada a objetos. Es una de las metodologas ms extendidas y conocidas por su amplia difusin comercial. Se puede estudiar como una metodologa representativa de tipo clsico. Este proceso se maneja por casos de uso (correspondientes a los modos uso por los actores o agentes usuarios) para la extraccin de requisitos y la identificacin de las partes funcionales en las que se divide la solucin. Est basado en componentes. Estos componentes a su vez estn conectados entre s a travs de interfaces. Utiliza el UML como notacin bsica. Dirigido por casos de uso. El proceso utiliza Casos de Uso para manejar el proceso de desarrollo desde la Incepcin hasta el Despliegue. Centrado en la arquitectura. El proceso busca entender los aspectos estticos y dinmicos ms significativos en trminos de arquitectura de software. La arquitectura se define en funcin de las necesidades de los usuarios y se determina a partir de los Casos de Uso base del negocio. Ciclo de vida iterativo e incremental. El proceso reconoce que es prctico dividir grandes proyectos en proyectos ms pequeos o mini-proyectos. Cada mini-proyecto comprende una iteracin que resulta en un incremento. Una iteracin puede abarcar la totalidad de los flujos del proceso. Las iteraciones son planificadas en base a los Casos de Uso. Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software

Fase de Incepcin: Durante la fase inicial se concibe la idea central del producto, se arma el documento de visin. En esta fase, se revisan y confirma nuestro entendimiento sobre los objetivos centrales del negocio. Queremos entender los argumentos comerciales en favor de porqu el proyecto debe intentarse. La fase de incepcin establece la viabilidad del producto y delimita el alcance del proyecto. Se describe el producto final. Se responde a las preguntas:

Mtodo pesado Por el grado de complejidad puede ser no muy adecuado. En proyectos pequeos, es posible que no se puedan cubrir los costos de dedicacin del equipo de profesionales necesarios. Tiene las desventajas del modelo espiral debido a las iteraciones en cada ciclo y puede tomar mucho ms tiempo. Por el grado de complejidad puede no resultar muy adecuado.

Cules son las principales funciones del El RUP es generalmente mal aplicado en sistema para sus usuarios ms importantes?. La el estilo cascada. respuesta est en el modelo de casos de uso Requiere conocimientos del proceso y de simplificado. UML. Hay certificaciones RUP. Cmo podra ser la arquitectura del sistema? Cul es el plan del proyecto y cunto costar desarrollar el producto? Fase de Elaboracin: Durante la fase de elaboracin la mayora de los Casos de Uso son especificados en detalle y la arquitectura del sistema es diseada. Esta fase se focaliza en las debilidades del proyecto. Se identifican los riesgos significativos y se preparan el calendario, el equipo de trabajo y el costo del proyecto. Fase de Construccin: Durante la fase de construccin, el foco del producto se mueve de la arquitectura de base a un sistema lo suficientemente completo como para llevarlo al usuario. El baseline de arquitectura crece en complejidad y se convierte en un sistema completo, de la misma manera, se refina el disea para llevarlo a cdigo fuente. Se construye el producto, se utilizan la mayor parte de los recursos, y al finalizar se cubren todos los casos de uso. La pregunta que se realiza es: Cubre el producto las necesidades de los usuarios como para hacer una primera entrega? Fase de Transicin: En la fase de transicin el objetivo es garantizar que los requisitos se han cumplido, con la satisfaccin de las partes interesadas. Esta fase a menudo se inicia con una versin beta de la aplicacin. Otras actividades incluyen la preparacin del ambiente, se completan, se identifican y corrigen defectos. La fase de transicin termina con un cierre dedicado al aprendizaje de lecciones, las cuales quedan para futuros ciclos. El producto existe en versin Beta.

Programacin Extrema X.P

Las caractersticas similares de sta metodologa con algunas de las otras son las siguientes: Para el desarrollo de sta aplicacin se lleva a cabo una planificacin en donde se tiene contacto directo con el cliente, pues este quin desde un principio establece y define los requisitos del Software. Durante la vida del Software se llevan a cabo pasos bien definidos como cualquier otra metodologa de programacin en donde u para la elaboracin de ste existe una organizacin de los desarrolladores.

Toma los principios y practicas aceptadas y las lleva a niveles extremos. Tiene como objetivo reducir el riesgo en el ciclo de vida del software mediante grupos de desarrollo pequeos. Considera que la mejor manera de tratar la falta de requisitos estables en un sistema, es mediante la agilidad de un grupo pequeo de desarrollo. Considera varios aspectos problemticos del desarrollo de software como lo son los retrasos, proyectos cancelados, cambios en el negocio y la rotacin del personal. Pone ms nfasis en la adaptabilidad que en la previsibilidad.

Metodologa SCRUM

sta metodologa se caracteriza con las dems porque durante el desarrollo de Software hay etapas iterativas e incrementales basadas en prcticas giles. Comparte los principios estructurales del desarrollo gil: a partir del concepto o visin de la necesidad del cliente, construye el producto de forma incremental a travs de iteraciones breves que comprenden fases de especulacin exploracin y revisin. Estas iteraciones (en Scrum llamadas sprints) se repiten de forma continua hasta que el cliente da por cerrado el producto. Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores prcticas para trabajar en equipo y obtener el mejor resultado posible de un proyecto. Estas prcticas se apoyan unas a otras y su seleccin tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

Metodologa gil de gestin de proyectos cuyo objetivo primordial es elevar al mximo la productividad de un equipo. Se enfoca en el hecho de que procesos definidos y repetibles slo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles. Enfatiza valores y prcticas de gestin, sin pronunciarse sobre requerimientos, prcticas de desarrollo, implementacin y dems cuestiones tcnicas. Hace uso de Equipos auto-dirigidos y auto-organizados Puede ser aplicado tericamente a cualquier contexto en donde un grupo de gente necesita trabajar junta para lograr una meta comn. Iteraciones de treinta das; aunque se pueden realizar con mas frecuencia, estas iteraciones, conocidas como Sprint Dentro de cada Sprint se denomina el Scrum Master al Lder de Proyecto quien llevar a cabo la gestin de la iteracin Se convocan diariamente un Scrum Daily Meeting el cual representa una reunin de avance diaria de no ms de 15 minutos con el propsito de tener realimentacin sobre las tareas de los recursos y los obstculos que se presentan. En la cual se responden preguntas como: Qu has hecho desde el ltimo encuentro? Qu obstculos hay para cumplir la meta? Qu hars antes del prximo encuentro? Asume que el proceso de desarrollo de software es impredecible, y lo trata como a una caja negra controlada, en vez de manejarlo como un proceso completamente definido. No se basa en el seguimiento de un plan, sino en la adaptacin continua a las circunstancias de la evolucin del proyecto.

Planificacin Incremental: los requerimientos se registran en tarjetas de historias, estas incluyen el tiempo y la prioridad relativa. Entregas pequeas: estas entregas son frecuentes e incrementalmente aaden funcionalidad al primera entrega Diseo sencillo: solo se lleva a cabo el diseo necesario para cumplir los requerimientos actuales Desarrollo previamente probado; se utiliza un sistema de pruebas, para escribir pruebas de las nuevas funcionalidades antes de que estas se implementen. Refactorizacin: conserva el cdigo sencillo y mantenible. Programacin en parejas: esta es la ms importante de todos los principios, los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro, proporcionando la ayuda para hacer siempre un buen trabajo Propiedad colectiva: las parejas trabajan en todas las reas del sistema. Integracin continua: cuanto acaba el trabajo en una tarea, se integra en el sistema entero. Ritmo sostenible: No se consideran aceptables grandes cantidades de horas extras, ya que a menudo, reduce la calidad del cdigo y la productividad a medio plazo. Cliente presente: Debe estar disponible al equipo de XP, un represente de los usuarios finales del sistema a tiempo completo. En un proceso XP el cliente es parte del equipo de desarrollo Pre-Juego / Planeamiento: El propsito es establecer la visin, definir expectativas y asegurarse la financiacin. Las actividades son la escritura de la visin, el presupuesto, el registro de acumulacin o retraso Metodologas giles (backlog) del producto inicial y los tems estimados, as como la arquitectura de alto nivel, el diseo exploratorio y los prototipos. El registro de acumulacin es de alto nivel de abstraccin. Pre-Juego / Montaje (Staging): El propsito es identificar ms requerimientos y priorizar las tareas para la primera iteracin. Las actividades son planificacin, diseo exploratorio y prototipos. Juego / Desarrollo: El propsito es implementar un sistema listo para entrega en una serie de iteraciones de treinta das llamadas corridas (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteracin, la definicin del registro de acumulacin de corridas y los estimados, y encuentros diarios de Scrum. Pos-Juego/ Liberacin: El propsito es el despliegue operacional. Las actividades, documentacin, entrenamiento, mercadeo y venta.

Algunas delas desventajas de la Metodologa Xp es que slo es recomendable emplearlo solo en proyectos a corto plazo, esto debido a los altos costos que esto conlleva si el programa llegara a falla ya que resulta imposible prever todo antes de programar. Otra cosa que resulta una desventaja es que es demasiado costoso e innecesario. Tambin reduce el nmero de participantes en el proyecto. Conseguir su implantacin en un equipo es algo que puede resultar dificultoso. El equipo no est acostumbrado a este tipo de tcnicas.

Scrum est especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovacin, la competitividad y la productividad son fundamentales. Scrum tambin se utiliza para resolver situaciones en que no se est entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reaccin ante la competencia, cuando la moral de los equipos es baja y la rotacin alta, cuando es necesario identificar y solucionar ineficiencias sistemticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

Qu es lo que pudiste observar mediante la tabla respecto a las caractersticas de los modelos?

Mediante la tabla que se ha realizado en lneas arriba lo que pude observar es que las metodologas de desarrollo de Software sin duda es una herramienta indispensable para poder llevar a cabo el desarrollo de una aplicacin, todas y cada una de ella tiene sus principales caractersticas que son los que las hacen diferentes unas de otras, pero tambin tienen caractersticas similares que por lo general stas caractersticas establecen la vida del Software ya que se considera desde que se tiene la idea de crear una aplicacin, hasta que el cliente acepta la aplicacin y se da por concretado el proyecto. Cada metodologa tiene sus particularidades, personalmente me llamo mucho la atencin que hay muchas de ellas que vindolas desde un punto de vista superficial, cualquiera de ellas puede usarse para el desarrollo de una aplicacin pero ci se analizan detalladamente se da cuenta uno de que cada una de ellas tiene sus desventajas y es cuando uno como desarrollador tiene que poner en la balanza cul de todas ellas es la que mas le conviene a uno como programador establecer y seguidamente cul de las metodologas es la que mas se adapta al proyecto en cuestin de trabajo y en cuestin de inversin por parte del Cliente o del Usuario. El modelo en cascada es muy interesante porque desde un principio se tiene contacto con el cliente y se va desarrollando el Software por etapas pero lo que no me gust mucho es que es un enfoque pasado de moda y ya se utiliza muy poco ya que los actuales software requieren de metodologas que soporten programas mas robustos en donde se vean involucrados un grupo de programadores y esto no se plantea en la metodologa en Cascada. El Modelo Construccin de Prototipos no me gust mucho porque en sta metodologa se suele fracasar mucho en un efectivo desarrollo de Software ya que por lo anticipado del prototipo del Software, se pueden perder detalles esenciales al momento de presentarle al Cliente la solucin para su problema, creo que al desarrollar un Software se tiene que cuidar mucho este detalle ya que la primer impresin que un Ingeniero le gener al Cliente vale mucho, de esto depende la autorizacin del proyecto por parte del Cliente. La programacin extrema es una programacin que se plantea muy interesante, esto debido a que durante la programacin se involucra al Cliente o al Usuario y se siente parte del equipo de trabajo y se tiene la informacin a la mano de los requerimientos que deber llevar el Software a desarrollarse. Debido a que este modelo se basa en la retroalimentacin contina entre el cliente y el equipo de desarrollo tener al cliente dentro del equipo de trabajo es algo que te motiva para hacer lo que se tiene que hacer. Y particularmente la metodologa que ms me gust es el uso de la metodologa RUP esto porque la metodologa de RUP es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quin hace qu, cundo y cmo), este proceso de RUP estiman tareas y horario del plan midiendo la velocidad de iteraciones concerniente a sus estimaciones originales, se enfoca fuertemente sobre la arquitectura del software, para su implementacin se hace a travs de cuatro etapas o fases y en cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala, este tiene grandes ventajas con respectos a XP, ya que se enfoca en los requisitos y el diseo, as como tambin el cliente interacta con el equipo de desarrollo mediante reunionesa diferencia de la metodologa XP que el cliente es parte del equipo. Sin duda RUP es una de las metodologas mas completas y satisfactorias que se puede usar para el desarrollo de un Software.