Ingenieria de Software

TEMA 1

INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE

Dr. José Ignacio Peláez Sánchez

E.T.S.I. Informática de Sistemas. 3er Curso. Año 2004/2005

José Ignacio Peláez SánchezUniversidad de MálagaDepartamento de Lenguajes y Ciencias de la Computación

2 de 87

Visión General

Importancia de la Ingeniería del Software.

Retraso en la llegada de la Ingeniería del Software23 de febrero de 1984 la revista “Bussiness week software: thenew driving force”.

Software un factor que marca diferencias.

Tareas de la Ingeniería del Software.Análisis, Especificación, Planificación, Diseño, Codificación, Prueba y Mantenimiento.


3 de 87

Sistemas Basados en Computadora

Definición de sistema. Conjunto de elementos relacionados entre sí, de manera que todos juntos forman un todo.

Definición de Sistema Basado en Computadora (SBC). Conjunto de elementos organizados para llevar a cabo algún método, procedimiento o control, mediante el procesamiento de la información.

Elementos de los SBC. Software, Hardware, Bases de Datos, Documentación, Gente, Procedimientos.


4 de 87

Concepto de Software

Definición de Software. Conjunto de instrucciones que cuando se ejecutan suministan la función y comportamiento adecuados, un conjunto de estructuras de datos que facilitan la manipulación adecuada de la información, y finalmente, los documentos que describen la operación y uso de los programas.


5 de 87

Evolución del SoftwareDecada de los 50.

Orientación por lotes; Distribución limitada; Software a medida.

Desde 1960 hasta mediado de los años 70.Multiusuario; Tiempo real; Bases de datos; Producción software.

Desde mitad de los años 70 hasta mitad de los 80.Sistemas distribuidos; Inteligencia empotrada; Hardware de bajo coste; Impacto en el consumidor.

Desde mitad de los años 80 hasta nuestros días.Sistemas expertos; Máquinas de I.A; Arquitecturas paralelas.


6 de 87

Evolución y las Mismas Preguntas

Preguntas de las programadores, ya sean programadores solitarios o grupos de programadores.

¿Por qué lleva tanto tiempo terminar los programas?¿Por qué son tan elevados los costes de desarrollo?¿Por qué no podemos encontrar todos los errores antes de entregar el software a nuestros clientes?¿Por qué nos resulta tan difícil constatar el progreso conforme se desarrolla el software?.


7 de 87

Caracteristicas del Software

El software es desarrollado y no fabricado en sentido clásico.El software no se deteriora en sentido hardware.No existen piezas de repuesto.Cada fallo indica un error de diseño o de traducción a código.El software se construye a medida y no ensamblando componentes.


8 de 87




9 de 87


El software no se deteriora en sentido hardware.

CURVA REAL

TIEMPO TIEMPO

CAMBIO

CURVA IDEALIZADA

INCREMENTO DEL ÍNDICE DE FALLOS

POR EFECTOS LATERALES

SE ESTROPEA

MORTALIDAD INFANTIL

ÍND

ICE

DE

FAL L

OS

Í ND

ICE

DE

FAL L

OS

CURVA DE FALLOS HARDWARE CURVAS DE FALLOS REAL E IDEALIZADA DEL SOFTWARE


10 de 87




11 de 87

Aplicaciones del SoftwareSistemas de tiempo real.Sistemas.Gestión.Ingeniería y científico.Empotrado.Inteligencia artificial.Computadores personales.Basado en Web.


12 de 87

Crisis del Software

La crisis del software es una serie de problemas que hacen que el software no alcance las expectativas u objetivos esperados por desarrolladores, gestores, clientes, etc.

Problemas fundamentales.La sofisticación del hardware no esta acompañada de la del software.Demanda creciente.Mantenimiento difícil.


13 de 87

Crisis del Software

SOLUCIÓN

INGENIERÍA DEL SOFTWARE


14 de 87

Crisis del Software

Problemas de los expertos.Planificación y precios imprecisos.La productividad de la gente del software no se corresponde con la demanda.La calidad muchas veces no es la adecuada.

Motivos de estos problemasNo hay tiempo para recoger los datos para el proceso de desarrollo.Falta comunicación con el cliente.Calidad cuestionable.Dificultad en el mantenimiento.


15 de 87

Crisis del Software

SOLUCIÓN

INGENIERÍA DEL SOFTWARE


16 de 87

Mitos del Software

Los mitos del software son frases hechas que propagan información

errónea y confusa, en lugar de sabiduría y buen hacer


17 de 87

Mitos de Gestión

Los gestores con responsabilidad en el software, como los gestores en la mayoría de las disciplinas, están normalmente bajo la presión de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad.

Un gestor de software se agarra frecuentemente a un mito del software, aunque tal creeencia sólo disminuya la presión temporal.


18 de 87

Mitos de Gestión

¿Por qué debemos cambiar nuestra forma de desarrollar software, si estamos haciendo el mismo tipo de programación que hace 10 años?¡Tenemos un libro que esta lleno de estándares y procedimientos para construir software!¡Nuestra gente tiene las mejores máquinas para el desarrollo!Si fallamos en la planificación, añadimos más programadores y adelantamos el tiempo perdido. (Horda Mongoliana).


19 de 87

Mitos del Cliente

Un cliente que solicita un aplicación de software puede ser una persona del despacho de al lado, un grupo técnico de la sala de abajo, el departamento de ventas o una compañía exterior que solicita un software bajo contrato.En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores del software hacen muy poco para corregir la mala información. Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el desarrollo del software.


20 de 87

Mitos del Cliente

Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. Podemos dar los detalles más adelante.

Los requerimientos cambian continuamente, pero los cambios pueden acomodarse fácilmente ya que el software es flexible.

¿Cómo afecta un cambio en las diferentes fases del desarrollo del software?


21 de 87

Mitos del Cliente

Impacto del Cambio.

DEFINICIÓN DESARROLLO DESPUÉS DE LA ENTREGA

IMPACTO DEL CAMBIO

1X

1,5-6X

60 – 100X


22 de 87

Mitos de los Realizadores

Los mitos en los que aún creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática.

Durante los primeros días del desarrollo del software, la programación se veía como un arte.

Las viejas formas y actitudes tardan en morir.


23 de 87

Mitos de los Realizadores

No hay métodos para el análisis, diseño y prueba que funcionen bien, simplemente me voy al terminal y comienzo a codificar.Una vez que hacemos que el programa funcione, nuestro trabajo ha terminado.Hasta que no esté el programa terminado no puedo establecer su calidad.Lo único que se entrega al terminar el proyecto es el programa funcionando.Una vez que el software se está usando, el mantenimiento es mínimo y puede manejarse sobre la base de hacerlo como se pueda.


24 de 87

Reflexión sobre los Mitos

Muchos profesionales del software reconocen la falacia de los mitos descritos anteriormente. Lamentablemente, las actitudes y métodos habituales fomentan una pobre gestión y una mala aplicación de las técnicas, incluso cuando la realidad dicta un método mejor. El reconocimiento de las realidades del software es el primer paso hacia la formulación de soluciones prácticas para su desarrollo.


25 de 87

Ingeniería del Software

Definición de Ingeniería del Software (IS). La IS es una disciplina o área de la Informática o Ciencias de la Computación, que ofrece métodos y técnicas para desarrollar, mantener y documentar software de calidad qué, resuelve problemas de todo tipo, se ejecuta en máquinas reales y satisface las necesidades del cliente.

La IS integra: Métodos, herramientas y procesos para el desarrollo del software bajo un enfoque de calidad.


26 de 87

Métodos

Los métodos indican cómo construir técnicamente el software.

Tareas que componen los métodos.Planificación; Estimación de proyectos.Análisis de requerimientos del software y hardware.Diseño de estructuras de datos, Arquitectura de los programas.Procedimientos algorítmicos.Codificación; Prueba; y Mantenimiento.


27 de 87

Herramientas y Procesos

Las herramietas son un soporte automático o semiautomático para el proceso y los métodos.

Microsoft Project (Planificación).UML (Modelado).RationalRose, visio (Modelado soportan UML).Designer 2000.Erwin (Bases de datos).MAGERIT (Seguridad).

Los procesos son los encargados de integrar los métodos y herramientas, además de definir la secuencia en la que se aplican los métodos, las entregas que requieren, los controles de calidad y las guías para el desarrollo.


28 de 87

Fases Genéricas de la IS

Definición. Tareas que la componen:

Análisis del sistema.Planificación del Proyecto.Análisis de requisitos.

Desarrollo. Tareas que la componen:

Diseño del software.Codificación.Prueba del Software.

Mantenimiento. Tipos de cambios:

Corrección.Adaptación.Mejora.Prevención o Reingeniería.

QUÉ

CÓMO

TIPO


29 de 87

Preguntas que debe Responder la IS

¿cuál es el problema a resolver?¿Cuáles son las características de la entidad (solución) que se utiliza para resolver el problema?¿Cómo se realizará la solución?¿Cómo se construirá la entidad?¿Qué enfoque se va a utilizar para no contemplar los errores que se cometieron en el diseño y en la construcción de la solución?¿Cómo se apoyará la solución cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?.


30 de 87

Proceso del Software

El proceso del software es un marco común para el proceso que define un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos con independencia de su tamaño o complejidad.


31 de 87

Proceso del Software

El proceso del software es un marco común para el proceso que define un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos con independencia de su tamaño o complejidad.

Marco de trabajo común

Actividades del marco de trabajo

Conjunto de trabajo

Tareas

Hitos, entregas

SQA=Puntos de garantía de calidad

Seguridad


32 de 87

Paradigma de la IS

El modelo de proceso o paradigma de la IS es la estrategía que comprenden métodos, herramientas y procesos.El ingeniero debe seleccionar un modelo de proceso para ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos, las herramientas a utilizar, y los controles y entregas que se requieren.Los diferentes paradigmas lo que intentan es ordenar las actividades en el desarrollo del software, de manera que no sean llevadas a cabo de manera caótica.


33 de 87

Paradigmas de la IS

Paradigmas.Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada.Prototipos.Modelo DRA (RAD. Rapid Application Development).

Modelos Evolutivos de ProcesoIncremental.Espiral.Espiral WINWIN.Modelo de desarrollo concurrente.

Modelo basado en componentes.Modelo basado en métodos formales.Técnicas de cuarta generación.Modelos agiles. Programación extrema.


34 de 87

Visión Generalizada de los Paradigmas

DefiniciónDesarrollo

Mantenimiento


35 de 87

Paradigmas de la IS





36 de 87

Modelo Lineal Secuencial

Enfoque sistemático y secuencial

Ingeniería de Sistemas

Análisis Diseño

Codificación Prueba Mantenimiento


37 de 87

Modelo Lineal Secuencial

Ingeniería de sistemas. Se establecen los requerimientos de los elementos del sistema y se realiza la asignación.Análisis de requerimientos. Se establece y documenta el dominio del software. Se revisa con el cliente.Diseño. Se traducen los requerimientos en estructuras.Codificación.Prueba.Mantenimiento.


38 de 87

Problemas del Modelo Sec. Lineal

Raramente los proyectos siguen este ciclo de vida.

El cliente pocas veces establece todos los requerimientos al principio.

El cliente no tiene un producto hasta el final.


39 de 87

Paradigmas de la IS





40 de 87

Ciclo de Vida del Prototipado

Recolección de Requerimientos

Diseño Rápido Construcción del Prototipo

Evaluar y Refinar

los RequerimientosProducto Construido


41 de 87

Modelo de Construcción de Prototipos

¿Por qué se usa este Modelo?

El cliente no puede especificar todos los requerimientos al principio.

Existen dudas de alguna parte del sistema.

Facilita un modelo al programador.


42 de 87

Tipos de Prototipos

Totales.

Parciales.Interfaces.Modelos.Estructuras de datos.


43 de 87

Problemas del Prototipado

El cliente lo quiere, aunque no es un producto software

Módulos ineficientes se convierten en partes del sistema.


44 de 87

Paradigmas de la IS





45 de 87

Modelo DRA

El Modelo DRA consiste en un desarrollo rápido de aplicaciones basado en el modelo lineal secuencial, pero donde se enfatiza un ciclo de desarrollo extremadamente corto.Es una adaptación a alta velocidad del modelo lineal secuencial, donde se puede aumentar la velocidad haciendo uso de componentes.Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional, dentro de periodos cortos de tiempo.


46 de 87

Modelo DRA

MODELADO DE GESTIÓN

MODELADO DE DATOS

MODELADO DE PROCESOS

GENERACIÓN DE APLICACIONES

PRUEBAS Y ENTREGA

EQUIPO Nº 1


MODELADO DE DATOS



PRUEBAS Y ENTREGA

EQUIPO Nº 2


MODELADO DE DATOS



PRUEBAS Y ENTREGA

EQUIPO Nº 3


47 de 87

Problemas del Modelo DRA

Para proyectos grandes necesitamos de recursos suficientes para formar los equipos necesarios.Compromiso de colaboración entre desarrolladores y clientes.No todas las aplicaciones son susceptibles de aplicar este modelo.Cuando los riesgos técnicos son altos DRA no es apropiado.Cuando el grado de interoperatividad con programas ya existentes es alto, no es apropiado.


48 de 87

Paradigmas de la IS





49 de 87

Modelos Anteriores

Modelo Lineal Secuencia. Diseñado para entregar un producto al final.Modelo de Construcción de Prototipos. Diseñado para que los clientes interactúen con los desarrolladores.Ninguno de los modelos anteriores se tiene en cuenta la naturaleza evolutiva del software.

“Las empresas son entes vivos que van evolucionando con el tiempo”


50 de 87

Modelos Evolutivos

Los modelos evolutivos se caracterizan porque permiten a los ingenieros del software, desarrollar de manera iterativa, nuevas versiones del software cada vez más completas.Los modelos que componen este tipo son:

Modelo Incremental.Modelo en Espiral.Modelo en Espiral Victoria-Victoria (WINWIN).Modelo de Desarrollo Concurrente.


51 de 87

Paradigmas de la IS



Modelo basado en componentes.Modelo basado en métodos formales.Técnicas de cuarta generación.Modelos ágiles. Programación extrema.


52 de 87

Modelo Incremental

El modelo Incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos.

ANÁLISIS DISEÑO CÓDIGO PRUEBAENTREGA 1ER

INCREMENTO

INGENIERÍA DE SISTEMAS


INCREMENTO



INCREMENTO



53 de 87

Paradigmas de la IS





54 de 87

Modelo en Espiral

El Modelo en Espiral, propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Ideal para realizar versiones incrementales de manera rápida.El software se desarrolla en una serie de versiones incrementales.


55 de 87

Paradigmas de la IS





56 de 87

Modelo en Espiral Victoria-Victoria

El modelo en espiral visto anteriormente, dispone de una actividad de comunicación con el cliente. Comunicación Ideal. El desarrollador pregunta al cliente y el cliente facilita suficiente información para continuar.Comunicación Real. El cliente y el desarrollador entran en un proceso de negociación, donde el cliente puede ser preguntado para sopesar la funcionalidad, rendimiento, y otras características.Las mejores negociaciones se esfuerzan en obtener <<victoria-victoria>>.Este modelo definido por Boehm, define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral.


57 de 87

Modelo en Espiral Victoria-Victoria


58 de 87

Paradigmas de la IS



Modelo basado en componentes.Modelo basado en métodos formales.Técnicas de cuarta generación.Modelos ágiles. Programación extrema.


59 de 87

Modelo de Desarrollo Concurrente

El Modelo de Desarrollo Concurrente dado por Davis y Sitaram, se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.El modelo Concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la Ingeniería del software.Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor.


60 de 87

Paradigmas de la IS





61 de 87

Modelo Basado en Componentes

La tecnología de objetos proporciona el marco de trabajo técnico para un modelo de proceso basado en componentes para la IS.El paradigma orientado a objetos enfatiza en la creación de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos.Si se diseñan e implementan las clases correctamente, podrían ser reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadores.


62 de 87


El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo en espiral.Es evolutivo por naturaleza y exige un enfoque iterativo para la creación de software.Configura aplicaciones desde componentes preparados de software.El modelo basado en componentes conduce a la reutilización del software, proporcionando beneficios a los ingenieros de software.


63 de 87


La reutilización según estudios:Reduce el ciclo de vida en un 70%.Reduce el coste del proyecto en un 84%.Aumenta la productividad.


64 de 87

Paradigmas de la IS





65 de 87

Modelo de Métodos Formales

El Modelo de Métodos Formales comprende un conjunto de actividades que conducen a la especificación matemática del software de computadora.Los métodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática.Con este modelo se consigue software libre de errores.Es difícil de aplicar, por diferentes motivos, pero para software de alta seguridad es muy adecuado.También se le conoce como Ingeniería del Software de Sala Limpia.


66 de 87

Paradigmas de la IS





67 de 87

Técnicas de 4ª Generación

El término técnicas de cuarta generación abarca un amplio espectro de herramientas de software que tienen algo en común: Todas facilitan al ingeniero del software la especificación de algunas características del software de alto nivel.Las herramientas general el código automáticamente en base a las especificaciones del ingeniero.Herramientas de 4ª Generación.

Lenguajes no procedurales para consultas de BD.Generación de Informes.Manipulación de Datos.Definición de pantallas y código.Gráficos.Hoja de cálculo.


68 de 87

Ciclo de Vida de las Técnicas de 4 Gen.

Recolección de Requerimientos

Estrategias de Diseño

Implementación usando L4G

Producto


69 de 87

Paradigmas de la IS





70 de 87

Modelos Ágiles/Programación Extrema

La idea de la Ingeniería de requisitos es conseguir un cuadro totalmente entendido de los requisitos antes de empezar a construir el software.Conseguir la firma del cliente sobre los requisitos y preparar los procedimientos para limitar los cambios después de la firma.El problema surge cuando se intenta añadir un nuevo requisito porque la estimación del coste es difícil.¿Por qué es difícil esta tarea? Porque la actividad de desarrollo del software es una actividad de Diseño.


71 de 87

Procesos Adaptables o Ágiles

Si bien el desarrollo iterativo tiene sentido en los procesos predictivos, también lo es en los procesos adaptables porque este tipo de proceso necesita poder tratar con los cambios.Este estilo nos lleva a que los planes a largo plazo son adaptables y los únicos planes adaptables son los que se hacen a corto plazo.En un proceso adaptable el cliente tiene mucho control sobre el proceso de desarrollo, ya que en cada iteración puede interactuar como alterar la dirección del mismo.En este tipo de procesos se forma un verdadero equipo entre los desarrolladores y los clientes.


72 de 87


Se consigue un producto que funciona pronto con los beneficios que esto conlleva para el cliente, comprende el sistema y puede introducir mejoras que lo hacen eficaz.Un proyecto es bueno cuando se ajusta al plan. Sin embargo un proyecto ágil tiene que obtener mejores resultados que los que fueron establecidos inicialmente.El problema de los modelos ágiles es que requieren de un equipo eficaz de desarrollo, tanto a nivel individual como de equipo.En los proyectos tradicionales el personal puede ser reemplazado, sin embargo en los modelos ágiles esto varia, los desarrolladores pueden tomar todas las decisiones.


73 de 87


Los equipos ágiles tienen una gran comunicación tanto los desarrolladores como los expertos del negocio (cambios continuos en la tecnología).La Programación Extrema (XP) comienza con cuatro valores: Comunicación, Retroalimentación, Simplicidad y Coraje. La XP agrupas todas las técnicas y pone todo su énfasis en realizar pruebas, donde cada programador escribe sus pruebas conforme desarrolla software.La XP es un desarrollo evolutivo donde en cada iteración de consigue un producto final.


74 de 87

Proceso Unificado de Desarrollo del Software

El Proceso Unificado de Desarrollo del Software (PUDS) es un proceso basado en componentes que ha sido propuesto por la industria.El proceso unificado dispone de un Lenguaje de Modelado Unificado (UML), que es utilizado construir el sistema y las interfaces que conectarán los componentes.El PUDS combina un desarrollo incremental e iterativo, definiendo la función del sistema aplicando un enfoque basado en escenarios.


75 de 87

Proceso Unificado de Desarrollo del Software

El PUDS se puede decir que es un proceso:Dirigido por los casos de uso.

Basándose en el modelo de casos de uso y en su análisis los desarrolladores crean los modelos de diseño e implementación que llevan a cabo los casos de uso.

Centrado en la arquitectura.La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcción.

Iterativo e Incremental.El desarrollo de un proyecto se divide en iteraciones, encargadas de pequeñas partes del trabajo y que dan como resultado un crecimiento del producto, incremento. Estas iteraciones se planifican y se prueban cada vez que terminan.


76 de 87

Proceso UnificadoANÁLISIS DISEÑO CÓDIGO PRUEBA

ENTREGA 1 INCREMENTO

Prototipo Exploratorio

ANÁLISIS DISEÑO CÓDIGO PRUEBAENTREGA 2

INCREMENTO

Línea Base de la Arquitectura


INCREMENTO

Versión Operativa Inicial


INCREMENTO

Entrega del Producto


77 de 87

Métrica 3

La metodología Métrica 3 es un instrumento para la sistematización de las actividades que dan soporte al ciclo de vida del software.Contempla el desarrollo de sistemas de información para las distintas tecnologías que actualmente conviven.En la elaboración de Métrica 3 se han tenido en cuenta los métodos de desarrollo más extendidos, así como los últimos estándares de ingeniería del software y calidad, además de referencias especificas en cuanto a seguridad y gestión de proyectos.


78 de 87

Métrica 3

Cubre el desarrollo estructurado y orientado a objetos.Facilita los procesos de apoyo y de organización a través de interfaces: Gestión de proyectos; Gestión de configuración; Aseguramiento de calidad y seguridad.La automatización de sus actividades es posible ya que existe una amplia variedad de herramientas de ayuda al desarrollo.Existe una herramienta que adapta Métrica 3 a las condiciones especificas de cada proyecto, permitiendo el control y seguimiento desde diferentes perfiles.Posee un curso de formación. www.map.es/csi


79 de 87

¿Por que una Metodología de Desarrollo?

La utilización de una metodología en el desarrollo de sistemas permite:

Disponer de un marco estratégico que permite conseguir los fines de la organización.

Dotar a la organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos.


80 de 87

Metodología de Desarrollo

Mejorar la productividad de los departamentos de sistemas y tecnologías de la información y las comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.

Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.

Facilitar la operación, mantenimiento y uso de los productos software obtenidos.


81 de 87

Metodología DUM

DUM es una metodología evolutiva e incremental de desarrollo del software que ha sido creada en el departamento de Lenguajes y Ciencias de la Computación de la Universidad de Málaga. Basada en un enfoque iterativo incremental esta metodología realiza una especificación exhaustiva de todas las actividades y tareas que se realizan en las diferentes fases, prestado especial atención por alcanzar un nivel superior de madurez según el marco CMMI/CarnegieMellon.Las fases en las que se subdivide la metodología DUM son las siguientes: fase preliminar, fase de Inicio, fase de elaboración, fase de construcción, fase de transición; y finalmente, una fase de mantenimiento.


82 de 87

Metodología DUM

Fase Preliminar

En la Fase Preliminar se llevan a cabo una serie de pasos previos en los que se sientan las bases que permiten comenzar el proyecto. En esta fase el cliente proporciona los dos elementos básicos para comenzar un proyecto: una petición formal del mismo; y una definición del problema al que debe dar respuesta el Sistema a desarrollar. En base a estos dos elementos la organización de desarrollo definirá un primer equipo encargado del inicio del proyecto.


83 de 87

Metodología DUM

Fase de InicioEn la Fase de Inicio se determina si el problema planteado tiene solución, lo cual se hace desde un punto de vista genérico, es decir, no se tienen en cuenta posibles restricciones relacionadas con el cliente como costes económicos o plazos de entrega, sólo se tienen en cuenta restricciones que afecten al problema en sí como pueda ser la legalidad vigente. Si al final de la Fase de Inicio se determina que el problema tiene solución, DUM denominará el Sistema a desarrollar un Sistema Realizable. En fases posteriores se estudiará si el nuevo Sistema puede desarrollarse teniendo en cuenta las restricciones impuestas por el cliente, esto es lo que DUM denomina un Sistema Viable.


84 de 87

Metodología DUM

Fase de Elaboración En la Fase de Elaboración se determina si es posible desarrollar el Sistema teniendo en cuenta las restricciones impuestas por el cliente, y se obtiene un proyecto particular después de aplicarle las restricciones del cliente al proyecto genérico. Puede considerarse que en las Fases de Inicio y Elaboración se realiza un trabajo en base a objetivos similares pero tratados a distinto nivel. Así, en la Fase de Inicio se trabaja con un proyecto basado en un problema genérico y se comprueba que dicho proyecto genérico se puede llevar a cabo, mientras que en la Fase de Elaboración se trabaja con una versión particular del proyecto genérico y se comprueba que dicho proyecto particular se puede llevar a cabo.


85 de 87

Metodología DUM

Fase de ConstrucciónTerminada la Fase de Elaboración se cuenta con un especificación detallada de qué debe hacer el Sistema, de una arquitectura formada por los elementos del Sistema que guiará cómo cumplirá el Sistema con su cometido, y de una versión inicial del Sistema en base a su arquitectura que será la base sobre la que se construirá el resto del Sistema. En la Fase de Construcción se completarán las labores de desarrollos pendientes para los casos de uso no incluidos en la arquitectura del Sistema de modo que al final de la fase se cuente con una versión completa del Sistema. Esta versión deberá satisfacer todos los requisitos indicados por el cliente y los criterios de calidad y seguridad establecidos por la organización de desarrollo, sin embargo, no será la versión definitiva del Sistema, será la denominada versión beta del Sistema.


86 de 87

Metodología DUM

Fase de TransiciónDurante la Fase de Transición se realiza la prueba del Sistema con el fin de adaptar el mismo a un entorno de producción realizándose las modificaciones que se estimen necesarias. Los usuarios encargados de probar el sistema (en adelante usuarios beta) recibirán instrucciones acerca de aquellos aspectos del Sistema en los que deben hacer especial hincapié y sobre el proceso a seguir para la proposición, estudio y resolución de propuestas de modificación. A este respecto será necesario desarrollar la estructura necesaria para facilitar en la medida de lo posible dicho proceso.


87 de 87

Metodología DUM

Fase de MantenimientoTras la finalización del proyecto será necesario establecer un acuerdo respecto al mantenimiento, que puede ser llevado a cabo por la misma organización de desarrollo o por otra distinta.

Documents

Ingenieria de Software