Metodologias todas

13
Carlos Andres Islas Maldonado METODOLOG IAS CLASICAS definición características diagrama Tipos de sistemas Ventajas desventajas Cascada Sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificació n de requerimiento s del cliente y que continua con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. +Es el más utilizado +Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios +Para que el proyecto tenga éxito deben desarrollarse todas las fases +Las fases continúan hasta que los objetivos se han cumplido. Aplicable para proyectos pequeños y no tan complejos. La planificación es sencilla La calidad del producto resultante es alta Permite trabajar con personal poco cualificado Los usuarios lo pueden comprender fácilmente. Sus fases son conocidas por los desarrolladores. No necesita una definición completa para empezar a funcionar. Iteraciones costosas Los problemas que se presentan son corregidos posteriormente Puede que el software no cumpla con los requisitos Es difícil 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 difíciles Increment al Es un proceso de desarrollo de software, creado en respuesta a Permite construir el proyecto en etapas incrementales en donde cada etapa Este modelo es aplicable cuando es difícil La solución se va mejorando en forma progresiva a través de las múltiples Requiere de mucha planeación, tanto administrativa

description

 

Transcript of Metodologias todas

Page 1: Metodologias todas

Carlos Andres Islas Maldonado METODOLOGIAS CLASICAS

definición características diagrama Tipos de sistemas

Ventajas desventajas

CascadaSugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continua con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado.

+Es el más utilizado+Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios+Para que el proyecto tenga éxito deben desarrollarse todas las fases+Las fases continúan hasta que los objetivos se han cumplido.

Aplicable para proyectos pequeños y no tan complejos.

La planificación es sencillaLa calidad del producto resultante es altaPermite trabajar con personal poco cualificadoLos usuarios lo pueden comprender fácilmente.Sus fases son conocidas por los desarrolladores.No necesita una definición completa para empezar a funcionar.

Iteraciones costosasLos problemas que se presentan son corregidos posteriormentePuede que el software no cumpla con los requisitosEs difícil incorporar nuevas cosas si se quiere actualizarEs normal detenerse en su desarrollo y seguir con otras fasesSe tarda mucho tiempo en pasar todo el cicloLas revisiones de proyectos de gran complejidad son muy difíciles

Incremental Es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada.Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro.

Permite construir el proyecto en etapas incrementales en donde cada etapa agrega funcionalidad.Cada etapa consiste de requerimientos, diseño, codificación, pruebas, y entrega.Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.Provee visibilidad sobre el progreso a través de sus nuevas versiones.Provee retroalimentación a través de la funcionalidad mostrada.

Este modelo es aplicable cuando es difícil establecer los requisitos iniciales de un proyecto y es mas apropiado para proyectos pequeños. Las nuevas versiones pueden ser planeadas de modo que los requisitos

La solución se va mejorando en forma progresiva a través de las múltiples iteraciones.Incrementa el entendimiento del problema y de la solución por medio de los refinamientos sucesivos.

Requiere de mucha planeación, tanto administrativa como técnica.Requiere de metas claras para conocer el estado del proyecto.

Page 2: Metodologias todas

Carlos Andres Islas Maldonado Permite atacar los mayores riesgos desde el inicio.

técnicos puedan ser administrados.

Evolutivo

El desarrollo evolutivo se basa en la idea de desarrollar una implementación inicial e ir refinándola a través de diferentes versiones hasta desarrollar un sistema software que satisfaga todos los requerimientos del cliente.

• Gestionan bien la naturaleza evolutiva del software• Son iterativos: construyen versiones de softwarecada vez más completas

Se adaptan bien:• Los cambios de requisitos del producto• Fechas de entrega estrictas poco realistas• Especificaciones parciales del producto

Este modelo es apropiado en proyectos donde se desea realizar mejoras para ampliar el alcance del mismo.

•Nos permite hacer validaciones deforma creciente•Retroalimentación rápida a lo largo del proceso•El sistema evoluciona agregando nuevos atributos de acuerdo a las propuestas del cliente

•El proceso no es visible•Sistema con estructura deficiente•Se requieren herramientas y técnicas especiales

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 iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen

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 gestión del proyecto.Este es el enfoque mas realista actualmente.El análisis de riesgo requiere la participación

Se aplican a cualquier proyecto, grande, mediano o pequeño, complejo o no.Proyectos pequeños requieren baja cantidad de tareas y también de formalidad. En proyectos mayores o críticos cada región de tareas

+El análisis de riesgo se lo hace de forma explícita 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 técnico.+Si nos tardamos mucho tiempo en pasar a otro nivel superior el proyecto se lo puede

+La consideración explicita del riesgo.+Hacer uso de los mejores elementos de los restantes modelos.+Genera mucho tiempo en el desarrollo del sistema+Modelo costosoRequiere experiencia en la identificación de riesgosGenera 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 difícil).

Page 3: Metodologias todas

Carlos Andres Islas Maldonado en función del análisis de riesgo, comenzando por el bucle interior.

de personal con alta calificación.

contiene labores de más alto nivel de formalidad.

abandonar para no gastar ni tiempo ni dinero en vano.+El desarrollador y el cliente comprenden y reacción mejor ante riesgos.

Prototipos Un prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas.

Trata de mantener un continuo contacto con el usuario en la etapa de análisisSe preocupa mas del flujo de información y la interface con el usuarioNo suelen considerarse aspectos de calidadNo se consideran alternativas de diseño y explotaciónSe presentan en cualquier etapa del ciclo de desarrollo

Sirven para modelar entradas y salidas de un sistema, modela también, consumo de recursos, ocupación, rendimientos, reglas de negocio y datos.

- Reducción de la incertidumbre y del riesgo- Reducción de tiempo y de costos- Incrementos en la aceptación del nuevo sistema- Mejoras en la administración de proyectos- Mejoras en la comunicación 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 aún no ha sido construido.

Desarrollo basado en componentes

Se define como el paradigma de ensamblar componentes y escribir código 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

+El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo en espiral.+Es evolutivo por naturaleza.+Exige un enfoque iterativo para la creación del software.+Conduce a la reutilización del software.

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

+El análisis del riesgo se hace de forma explícita 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

+Genera mucho tiempo en el desarrollo del sistema+Modelo costoso+Requiere experiencia en la identificación 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

Page 4: Metodologias todas

Carlos Andres Islas Maldonado software de proyecto desarrollo. analistas (es bastante

difícil).

OTRAS METODOLOGIAS

definición características diagrama Tipos de sistemas Ventajas desventajas

Win winEs una adaptación del modelo de espiral que se hace hincapié explícitamente situados en la participación del cliente en un proceso de negociación en la génesis del desarrollo de productos. Idealmente, el desarrollador simplemente preguntar al cliente lo que se requiere y el cliente proporcionaría el suficiente detalle para proceder.

+Trata de mejorar los ciclos de vida clásicos 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 análisis de riesgo requiere la participación de personal con alta cualificación.Incorpora objetivos de calidad y gestión de riesgos.+Permite iteraciones, vuelta atrás y finalizaciones rápidas.

Esta metodología, dado a que esta basada en la de espiral adquiere la característica de poder ser utilizado en cualquier tipo de proyecto.

Sin embargo esta metodología es mas utilizada en proyectos de empresas de alto nivel, empresas directivas, empresas con un mayor estimulo de ingresos anuales

Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.Mantiene el enfoque del ciclo de vida clásico pero lo incorpora al marco de trabajo interactivo que refleja un mundo más realista de la naturaleza del proyecto.Hace una consideración directa de los riesgos técnicos en todas las etapas del proyecto de tal manera que si se aplica adecuadamente reduce los riesgos antes de convertirse en problemáticos.

Al elaborarlo por partes no tenemos una visión global del problema.Aquí nos dice que los prototipos se van validando, lo cual es muy negativo porque como ya se ha dicho ningún software debe empezar como un prototipo.Como es un modelo relativamente nuevo no es muy utilizado como los paradigmas lineales secuenciales o de construcción de prototipos.Debido a su elevada complejidad no se aconseja utilizarlo en sistemas pequeños (sobre-costo de gestión).

Procesounificado Es un proceso de

desarrollo de software que describe “el conjunto de actividades necesarias para transformar los

Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)Pretende implementar las mejores prácticas en Ingeniería de

Es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de

-Adaptabilidad del desarrollo a nuevos requisitos o nuevos cambios-Se reducen los riesgos de no obtener el producto deseado-En cada momento hay una versión del sistema

El método de PU requiere costos de dedicación altos por lo que no es conveniente usarlo en procesos de un proyecto pequeño.-Si el proceso no se

Page 5: Metodologias todas

Carlos Andres Islas Maldonado 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.

SoftwareDesarrollo iterativoAdministración de requisitosUso de arquitectura basada en componentesControl de cambiosModelado visual del softwareVerificación de la calidad del software

organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto

funcionando que se modifica según las necesidades y deseos del cliente.-Progreso visible en las primeras etapas-Reducir la redundancia e incrementa la productividad-El proceso es comprensible-La metodología de PU es más adaptable para proyectos de largo plazo

aplica bien desde el inicio el PU se puede volver muy grande y difícil, 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 documentación

Ingenieríaweb

Las aplicaciones Web es un tipo particular de software, por ello se puede modelar con diagramas UML.●Muchas aplicaciones telemáticas son un caso particular de aplicaciones Web.WebML: Web Modeling LanguageModelado orientado a aplicaciones con un uso intensivo de datos, donde hay gran cantidad de datos, con estructura compleja y las aplicaciones tienen que acceder a ellosModelado de

Para una misma aplicación Web se pueden utilizar varios modelados. Dependiendo del tipo de aplicación, será más adecuado uno u otro.WSDM está orientado para aplicaciones que requiren diferentes audiencias.WebML está orientado para aplicaciones que tienen una alta interacción con datos.WA-UML está orientado para aplicaciones adaptativas.OO-H está orientado para aplicaciones con énfasis en el interfaz.

La ingeniería de la Web es multidisciplinar y aglutina contribuciones de diferentes áreas: arquitectura de la información, ingeniería de hipermedia/hipertexto, ingeniería de requisitos, diseño de interfaz de usuario, usabilidad diseño grafico y de presentación, diseño y análisis de sistemas, ingeniería de software, ingeniería de datos, indexado y recuperación de información, testeo, modelado y simulación,

Page 6: Metodologias todas

Carlos Andres Islas Maldonado aplicación Web en 4 fases:Modelo de datosModelo de hipertextoModelo de gestión de contenidoModelo de presentación

OOHDM y UWE están orientados para aplicaciones más Genéricas.

despliegue de aplicaciones, operación de sistemas y gestión de proyectos.

Metodologías agiles Consiste en

desarrollar una pequeña parte del software que se desea construir. De esta forma, el cliente nos indica si vamos por el buen camino, estableciendo aquellas partes que le son más relevantes y así juntos, nos aseguramos de que construimos una aplicación que añadirá valor a su negocio.

La mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo.Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo.Entrega continua y en plazos breves de software funcional.Trabajo conjunto entre el cliente y el equipo de desarrollo.Importancia de la simplicidad, eliminado el trabajo innecesario.Atención continua a la excelencia técnica y al buen diseño.Mejora continua de los procesos y el equipo de desarrollo

Las metodologías ágiles de desarrollo están especialmente indicadas en proyectos con requisitos poco definidos o cambiantes.

Programación organizada.

Menor taza de errores.

Satisfacción del programador.

Es recomendable emplearlo solo en proyectos a corto plazo.

Altas comisiones en caso de fallar.

METODOLOGIA EMERGENTE

Una metodología es emergente si permite adaptar la forma de trabajo a las condiciones del proyecto.

El uso del modelo orientado a objetos ayuda a explotar el poder expresivo de todos los lenguajes de programación basados en objetos y

Se utiliza mayoritariamente en desarrollo de productos con innovaciones importantes, y para

Las metodologías emergentes motivan más a los equipos de trabajo.El principal beneficio del diseño orientado a objetos es que proporciona un

Problemas derivados de la comunicación oral. Este tipo de comunicación resulta difícil de preservar cuando pasa el tiempo y está sujeta

Page 7: Metodologias todas

Carlos Andres Islas Maldonado los orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada y Java.Incertidumbre: la dirección indica la necesidad estratégica que se desea cubrir, ofreciendo máxima libertad al equipo de trabajo.Difusión y transferencia del conocimiento: alta rotación de los miembros de los equipos entre diferentes proyectos. Por otra parte, potenciar el acceso libre a la información y documentación

sistemas de información empresarial.

mecanismo para formalizar modelos de la realidad.Evita malentendidos de requerimientos entre el cliente y el equipoEl uso del modelo orientado a objetos alienta la reutilización no solo del software, sino de diseños completos.Proporcionan mejores resultados en los proyectos de alto riesgo.

a muchas ambigüedades.Falta de calidad. Probar el código de forma constante no genera productos de calidad, sólo revela falta de análisis y diseño.

REINGENIERIA Una reingeniería buscará el porqué el como de lo que ya existe. Los cambios en el diseño deberán ser radicales (desde la raíz y no superficiales). Las mejoras esperadas deben ser dramáticas (no de unos pocos porcentajes).Los cambios se deben enfocarse para no modificar el fin del software.

Unificación de tareasParticipación de los usuariosCambio del orden secuencialReutilización de componentesRealización de diferentes versionesReducción de las comprobaciones

Simplifica el mantenimiento del sistemaSimplifica el costoMenor tiempoMayor calidadReutilización del softwareSimplifica las pruebas

Exige una cierta habilidad en los analistas

Se puede perder el primer proyectoNecesita de varios proyectos realizados con éxitoNecesita que todo el código sea orientado a objetos

Page 8: Metodologias todas

Carlos Andres Islas Maldonado