Carlos Andres Islas Maldonado

METODOLOGIAS 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 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 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

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.

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 software cada 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 función del

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 de personal con alta

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 contiene

+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 abandonar para no

+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 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 analistas (es bastante difícil).

Carlos Andres Islas Maldonado

análisis de riesgo, comenzando por el bucle interior.

calificación. labores de más alto nivel de formalidad.

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álisis Se preocupa mas del flujo de información y la interface con el usuario No suelen considerarse aspectos de calidad No se consideran alternativas de diseño y explotación Se 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 software

+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 de proyecto

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

+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 analistas (es bastante

Carlos Andres Islas Maldonado

OTRAS METODOLOGIAS

definición

características diagrama Tipos de sistemas Ventajas desventajas

Winwin Es 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).

Proceso unificado

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

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 Software

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 organizaciones,

-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 funcionando que se

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 aplica bien desde el

difícil).

Carlos Andres Islas Maldonado

usuario en un sistema de software”. Esta dirigido por casos de uso, centrado en la arquitectura del sistema, y es iterativo e incremental.

Desarrollo iterativo Administración de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software

diferentes niveles de aptitud y diferentes tamaños de proyecto

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

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ía web

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 ModelingLanguage Modelado 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 ellos Modelado de aplicación Web en

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. OOHDM y UWE están

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, despliegue de

Carlos Andres Islas Maldonado

4 fases: Modelo de datos Modelo de hipertexto Modelo de gestión de contenido Modelo de presentación

orientados para aplicaciones más Genéricas.

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 los orientados a

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

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 mecanismo para

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

Carlos Andres Islas Maldonado

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

información empresarial.

formalizar modelos de la realidad. Evita malentendidos de requerimientos entre el cliente y el equipo El 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.

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 tareas Participación de los usuarios Cambio del orden secuencial Reutilización de componentes Realización de diferentes versiones Reducción de las comprobaciones

Simplifica el mantenimiento del sistema Simplifica el costo Menor tiempo Mayor calidad Reutilización del software Simplifica las pruebas

Exige una cierta habilidad en los analistas Se puede perder el primer proyecto Necesita de varios proyectos realizados con éxito Necesita que todo el código sea orientado a objetos