Metodologas tradicionales de desarrollo de Software

12

NDICE

1.

Metodologas Tradicionales ............................................................................................................. 3 1.1 1.2 1.3 RUP (Rational Unified Process). ........................................................................................... 3 OMT (Object Modeling Technique) ........................................................................................ 4 Metodologa ICONIX.- ........................................................................................................... 6

1. Metodologas Tradicionales Las Metodologas tradicionales en el desarrollo de software son basadas en las metodologas existentes sobre el desarrollo de proyectos en otras reas, bsicamente es dividir el proceso de desarrollo en etapas, de una manera secuencial, son ms un resultado de una urgencia por dotar al desarrollo de software de orden para poder completar los objetivos deseados. Estos mtodos ofrecen una documentacin muy completa, exhaustiva y un plan de proyecto cuidadosamente definido, el desarrollo se basa en un modelo de procesos estrictamente definido. Este tipo de metodologas proveen de un alto grado de ordenamiento, de disciplina pero son resistentes al cambio, los cambios son vistos con recelo y son rechazados, se pierde entre tanta disciplina el objetivo del proyecto, el hacer software til, importan ms los procesos que las personas, el cliente puede llegar a ser relegado. Sobre la documentacin por ejemplo existen artculos que consideran que el modelado UML surgido de la metodologa ms difundida y tradicional, nace ms de la necesidad de un estndar en cuanto a diagramas ya que anteriormente existan cientos de diagramas distintos, que de una evaluacin sincera de si son tiles o no, adems su precisin y consistencia son criticadas y si se pueden interpretar de una manera objetiva o no. Las metodologas tradicionales son insuficientes porque no proveen de una forma de trabajar durante el desarrollo, proveen de una exagerada descripcin del modelo del software pero no indican cmo deben llevarse a cabo las tareas del proyecto, por estar enfocadas en procesos, y no en personas. 1.1 RUP (Rational Unified Process).

Una de las metodologas pesadas ms conocidas y utilizadas es la Metodologa RUP que divide el desarrollo en 4 fases que definen su ciclo de vida: - Inicio: El objetivo es determinar la visin del proyecto y definir lo que se desea realizar. - Elaboracin: Etapa en la que se determina la arquitectura ptima del proyecto. - Construccin: Se obtiene la capacidad operacional inicial. - Transmisin: Obtener el producto acabado y definido. Principios del RUP Adaptacin del proceso: El proceso debe adaptarse a las caractersticas de la organizacin para la que se est desarrollando el software. - Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los inversores del proyecto. - Colaboracin entre equipos: Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.,... - Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma interna, en etapas iteradas. En cada iteracin se evaluar la calidad y estabilidad del producto y analizar la opinin y sugerencias de los inversores.

- Elevar el nivel de abstraccin: Motivar el uso de los conceptos reutilizables. - Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la produccin. Diagrama de esfuerzo

Imagen 1. Diagrama de Esfuerzo Disciplina de soporte RUP. Determina la documentacin que es necesaria realizar durante el proyecto. Configuracin y administracin del cambio: Guardar todas las versiones del proyecto. Administracin del proyecto: Administrar los horarios y recursos que se deben de emplear. Ambiente: Administrar el ambiente de desarrollo del software. Distribucin: Hacer todo lo necesario para la salida del proyecto.

Elementos del RUP. 1.2 Actividades: Procesos que se han de realizar en cada etapa/iteracin. Trabajadores: Personas involucradas en cada actividad del proyecto. Artefactos: Herramientas empleadas para el desarrollo del proyecto. Puede ser un documento, un modelo, un elemento del modelo, etc. OMT (Object Modeling Technique)

El anlisis y diseo orientado a objetos constituye una nueva forma de pensar acerca de problemas empleando modelos que son tiles para comunicarse con expertos en esa aplicacin, modelar empresas, preparar documentacin, disear programas y bases de datos. La esencia del anlisis y diseo orientado a objetos es la identificacin y organizacin de conceptos del dominio de la aplicacin, y no de su presentacin final en un lenguaje de programacin, es decir, es un proceso conceptual independiente de s el lenguaje es orientado a objetos. El uso del anlisis y diseo orientado a objetos puede facilitar mucho la creacin de prototipos, y las tcnicas de desarrollo evolutivo de software. Los objetos son inherentemente reutilizables, y se puede crear un catlogo de objetos que podemos usar en sucesivas aplicaciones. De esta forma, podemos obtener rpidamente un prototipo del sistema, que pueda ser evaluado por el cliente, a partir de objetos analizables, diseados e implementados en aplicaciones anteriores. Y lo que es ms importante, dada la facilidad de reutilizacin de estos objetos, el prototipo puede ir evolucionado hacia convertirse en el sistema final, segn vamos refinado los objetos de acuerdo a un proceso de especificacin incremental. La metodologa OMT consta de cuatro fases. a. Anlisis. - Modelo de Objetos. - Modelo Dinmico. - Modelo Funcional b. Diseo del sistemas. - En esta parte se efecta la toma de decisiones de la estructura general del sistema. c. Diseo de objetos. - En esta parte se manejan a detalle los modelos que son mencionados en la primera etapa, trabajando toda estructura de datos y mtodos. d. Implementacin. - En esta etapa es la de desarrollo de la programacin, utilizando un lenguaje ya determinado. a. Anlisis. - Identificacin del Modelo Objeto.- En este paso se identifica: Los objetos y clases. La asociacin entre objetos. Los atributos. Se agrupa las clases y mdulos. Preparar el diccionario de datos. - Identificacin del modelo dinmico. Definir para cada objeto que eventos tendr. Construir los diagramas de estado para el comportamiento de los objetos. - Identificacin del modelo funcional Manejar la elaboracin de diagramas de flujo de datos para identificar la independencia que existe entre operaciones. Distinguir los valores de entrada y salida. b. Diseo de sistema.

Definir la estructura del sistema. Realizar la divisin del sistema en partes pequeas (subsistemas). Definir subsistemas. Definir el momento que se presenta cada objeto y nmero de veces que se repetir el objeto en el proceso. - Identificar el comportamiento entre el software y hardware para cada proceso. - Definir la estructura de las base de datos, el acceso a cada proceso y el lenguaje que soportara el sistema c. Diseo del objeto. Es una etapa de refinamiento de detalles. - Disear las operaciones de nueva creacin se requiere, plasmndolas a travs de algoritmos. - Asignar la seguridad o restriccin a cada mdulo conservando la integridad de informacin. - Asignar, de forma precisa, el movimiento, orden de aparicin de cada objeto y la relacin si es que existe con otros mdulos u objetos. - Definir que el acceso a cada mdulo sea de forma sencilla y rpida. d. Implementacin. En esta etapa es difcil de manejarla a detalle debido a que depende del criterio del personal informtico involucrado con el sistema. 1.3 Metodologa ICONIX.La metodologa ICONIX consiste en un lenguaje de modelamiento y un proceso, el lenguaje de modelamiento es la notacin grafica (incluye diferentes tipos de diagramas) y el proceso define quien debe hacer qu, cuando y como alcanzar un objetivo. La metodologa ICONIX es un proceso simplificado en comparacin con otros procesos ms tradicionales, que unifica un conjunto de mtodos de orientacin a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto, presenta claramente las actividades de cada etapa y exhibe una secuencia de pasos que deben ser seguidos. Caractersticas de ICONIX. - Iterativo e incremental: varias iteraciones ocurren entre el desarrollo del modelo del dominio y la identificacin de los casos de uso. El modelo estatico es incrementalmente refinado por los modelos dinmicos. - Trazabilidad: cada paso esta referenciado por algn requisito. Se define trazabilidad como la capacidad de seguir una relacin entre los diferentes artefactos de software produciodos. - Dinamica del UML: la metodologa ofrece un uso dinamico del UML por que utiliza algunos diagramas del UML, sin exigir la utilizacin de todos, como en el caso de RUP. Tareas de ICONIX. Anlisis de Requisitos. Modelo de dominio. Prototipacin rpida. Modelo de casos de uso.

Anlisis y Diseo Preliminar. Descripcin de casos de uso Diagrama de robustez. - Diseo. Diagrama de secuencia. - Implementacin. Escribir/Generar Cdigo. a. Anlisis de Requisitos. - Se realiza un relevamiento de todos los requisitos que en un principio deberan ser parte del sistema. - Se debe capturar informacin sobre los que les gusta y lo que les desagrada a los usuarios. Modelo de Dominio. Con los requisitos se construye el diagrama de clases, que representa el modelo esttico del sistema. Prototipacin Rpida. Se usa para simular el diseo del sistema. Se espera que los usuarios lo evalen como si fuera el sistema final. Los cambios al prototipo son planificados con los usuarios antes de llevarlo a cabo. El proceso se repite y finaliza cuando los usuarios y analistas estn de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las caractersticas necesarias o cuando es evidente que no se obtendr mayor beneficio con una iteracin adicional. Modelo de Casos de Uso. El modelo de los casos de uso comprende los actores, el sistema y los propios casos de uso. - Los casos de uso permiten a los usuarios estructurar y articular sus deseos; les obligan a definir la manera como querran interactuar con el sistema, a precisar que informaciones quieren intercambiar y a describir lo que debe para obtener el resultado esperado. b. Anlisis y Diseo Preliminar Descripcin de Casos de Uso. - Los Casos de Uso describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista de un usuario; permiten definir los lmites del sistema y las relaciones entre el sistema y el entorno. c. Diseo. Diagrama de secuencia. - Es el ncleo del modelo dinmico y muestra todos los cursos alternos que pueden tomar los casos de uso. - Especifica el comportamiento. La representacin se concentra sobre la expresin de interacciones.

Se supone de 4 elementos que son: el curso de accin, los objetos, los mensajes y los mtodos. d. Implementacin. Escribir / Generar el cdigo. - La importancia de la interactividad, accesibilidad y navegacin en el software harn que el usuario se sienta seguro y cmodo al poder hacer uso de la aplicacin sin inconvenientes. - Pero adems debemos tener en cuenta factores como: La reusabilidad: que es la posibilidad de hacer uso de los componentes en diferentes aplicaciones. La extensibilidad: que consiste en modificar con facilidad del software. La confiabilidad: realizacin de sistemas descartando las posibilidades de error. Realizar pruebas. Test de casos, datos y resultados. Test de integracin con los usuarios para verificar la aceptacin de los resultados. -