Carlos Andres Islas Maldonado 11200130

METODOLOGIAS definicin CLASICAS Cascada

Sugiere un enfoque sistemtico, secuencial hacia el desarrollo del software, que se inicia con la especificacin de requerimientos del cliente y que continua con la planeacin, el modelado, la construccin y el despliegue para culminar en el soporte del software terminado.

caractersticas
+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.

diagrama

Tipos de sistemas Aplicable para proyectos pequeos y no tan complejos.

Ventajas
La planificacin es sencilla La calidad del producto resultante es alta Permite trabajar con personal poco cualificado Los usuarios lo pueden comprender fcilmente. Sus fases son conocidas por los desarrolladores. No necesita una definicin completa para empezar a funcionar.
+Con un paradigma incremental se reduce el tiempo de desarrollo inicial. +Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes del Software. +El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. +Permite entregar al cliente un producto ms rpido.. +Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.

desventajas
Iteraciones costosas Los problemas que se presentan son corregidos posteriormente Puede que el software no cumpla con los requisitos 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 todo el ciclo Las revisiones de proyectos de gran complejidad son muy difciles

Incremental

El Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de prototipos. En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline, utilizado en muchas otras formas de programacin.

Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. El usuario se involucra ms. Difcil de evaluar el coste total. Difcil de 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.

Se utiliza Cuando se nos es difcil establecer los requisitos iniciales en un Proyecto

El modelo Incremental no es ecomendable 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.

Carlos Andres Islas Maldonado 11200130

Evolutivo Orientada a la creacin de prototipos Un sistema inicial se desarrolla rpidamente a partir de especificaciones abstractas +ideal para sistemas que no tienen bien definidos los requerimientos. +Desde el punto de vista de desarrollo de sistema el enfoque evolutivo +Es difcil de distinguirlo del proceso. +El proceso no es visible. +Si los sistemas se desarrollan rpido.

Espiral
El desarrollo en espiral es un modelo de ciclo de vida del software 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 fijadas a ninguna prioridad, sino que las siguientes se eligen en funcin del anlisis de riesgo, comenzando por el bucle interior.

En cada giro se construye un nuevo modelo del sistema completo. Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada, evolutivo). Mejor modelo para el desarrollo de grandes sistemas. No hay un numero definido de iteraciones, las iteraciones debe decidirlas el equipo de gestin del proyecto. Este es el enfoque mas realista actualmente. El anlisis de riesgo requiere la participacin de personal con alta calificacin.

Se aplican a cualquier proyecto, grande, mediano o pequeo, complejo o no. Proyectos pequeos requieren baja cantidad de tareas y tambin de formalidad. En proyectos mayores o crticos cada regin de tareas contiene labores de ms alto nivel de formalidad.

+El anlisis de riesgo se lo hace de forma explcita y clara. Integra el desarrollo con el mantenimiento de software etc. +Prevenir los errores que se nos pueden presentar en un futuro, lo cual es muy positivo para poder mejorar la calidad del software. +Utiliza los prototipos para disminuir los riegos desde el punto de vista tcnico. +Si nos tardamos mucho tiempo en pasar a otro nivel superior el proyecto se lo puede abandonar para no gastar ni tiempo ni

+La consideracin explicita del riesgo. +Hacer uso de los mejores elementos de los restantes modelos. +Genera mucho tiempo en el desarrollo del sistema +Modelo costoso Requiere experiencia en la identificacin de riesgos Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difcil).

Carlos Andres Islas Maldonado 11200130

dinero en vano. +El desarrollador y el cliente comprenden y reaccin mejor ante riesgos. Prototipos
Un prototipo es una representacin de un sistema, aunque no es un sistema completo, posee las caractersticas del sistema final o parte de ellas. Trata de mantener un continuo contacto con el usuario en la etapa de anlisis Se preocupa mas del flujo de informacin y la interface con el usuario No suelen considerarse aspectos de calidad No se consideran alternativas de diseo y explotacin Se presentan en cualquier etapa del ciclo de desarrollo Sirven para modelar entradas y salidas de un sistema, modela tambin, consumo de recursos, ocupacin, rendimientos, reglas de negocio y datos. - Reduccin de la incertidumbre y del riesgo - Reduccin de tiempo y de costos - Incrementos en la aceptacin del nuevo sistema - Mejoras en la administracin de proyectos - Mejoras en la comunicacin entre desarrolladores y clientes se hacen fuertes inversiones en un producto desechable ya que los prototipos se descartan. Esto puede hacer que aumente el coste de desarrollo del producto. Con este modelo pueden surgir problemas con el cliente que ve funcionando versiones del prototipo pero puede desilusionarse porque el producto final an no ha sido construido. +Genera mucho tiempo en el desarrollo del sistema +Modelo costoso +Requiere experiencia en la identificacin de riesgos +Genera mucho trabajo adicional. +Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difcil).

Desarrollo basado en componentes

Se define como el paradigma de ensamblar componentes y escribir cdigo para hacer que estos componentes funcionen, de una manera coherente y fluida. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software

+El modelo de desarrollo basado en componentes incorpora muchas de las caractersticas del modelo en espiral. +Es evolutivo por naturaleza. +Exige un enfoque iterativo para la creacin del software. +Conduce a la reutilizacin del software.

Esta metodologa es mas utilizada en proyectos de empresas de alto nivel, las cuales cuentan con los recursos suficientes para poder desarrollarla. Cualquier tipo de proyecto

+El 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. +Ahorramos el 70% del ciclo de vida de desarrollo.

Carlos Andres Islas Maldonado 11200130

OTRAS METODOLOGIAS Win win

definicin

caractersticas
+Trata de mejorar los ciclos de vida clsicos y prototipos. +Este modelo puede combinarse con otros modelos de proceso de desarrollo. +En cada giro se construye un nuevo modelo del sistema completo. +El anlisis de riesgo requiere la participacin de personal con alta cualificacin. Incorpora objetivos de calidad y gestin de riesgos. +Permite iteraciones, vuelta atrs y finalizaciones rpidas.

diagrama

Tipos de sistemas
Esta metodologa, dado a que esta basada en la de espiral adquiere la caracterstica de poder ser utilizado en cualquier tipo de proyecto. Sin embargo esta metodologa es mas utilizada en proyectos de empresas de alto nivel, empresas directivas, empresas con un mayor estimulo de ingresos anuales

Ventajas
Permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto. Mantiene el enfoque del ciclo de vida clsico pero lo incorpora al marco de trabajo interactivo que refleja un mundo ms realista de la naturaleza del proyecto. Hace una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto de tal manera que si se aplica adecuadamente reduce los riesgos antes de convertirse en problemticos. -Adaptabilidad del desarrollo a nuevos requisitos o nuevos cambios -Se reducen los riesgos de no obtener el producto deseado

desventajas
Al elaborarlo por partes no tenemos una visin global del problema. Aqu nos dice que los prototipos se van validando, lo cual es muy negativo porque como ya se ha dicho ningn software debe empezar como un prototipo. Como es un modelo relativamente nuevo no es muy utilizado como los paradigmas lineales secuenciales o de construccin de prototipos. Debido a su elevada complejidad no se aconseja utilizarlo en sistemas pequeos (sobre-costo de gestin). El mtodo de PU requiere costos de dedicacin altos por lo que no es conveniente usarlo en procesos de un proyecto pequeo. -Si el proceso no se

Es una adaptacin del modelo de espiral que se hace hincapi explcitamente situados en la participacin del cliente en un proceso de negociacin en la gnesis del desarrollo de productos. Idealmente, el desarrollador simplemente preguntar al cliente lo que se requiere y el cliente proporcionara el suficiente detalle para proceder.

Proceso unificado

Es un proceso de desarrollo de software que describe el conjunto de actividades necesarias para transformar los

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en

Es un marco de trabajo genrico que puede especializarse para una gran variedad de sistemas software, para diferentes reas de aplicacin,

Carlos Andres Islas Maldonado 11200130

requisitos del usuario en un sistema de software. Esta dirigido por casos de uso, centrado en la arquitectura del sistema, y es iterativo e incremental. 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 diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaos de proyecto -En cada momento hay una versin del sistema funcionando que se modifica segn las necesidades y deseos del cliente. -Progreso visible en las primeras etapas -Reducir la redundancia e incrementa la productividad -El proceso es comprensible -La metodologa de PU es ms adaptable para proyectos de largo plazo aplica bien desde el inicio el PU se puede volver muy grande y difcil, tanto para aprender como para administrar -Una cantidad sustancial de tiempo se gasta en tratar de adecuar el PU a cada proyecto. -Es un proceso pesado -Se basa mucho en la documentacin

Ingeniera web

Metodologas agiles