Estudio comparativo sobre las principales metodologias orientadas a objetos en el desarrollo de software

ESTUDIO COMPARATIVO SOBRE LAS
PRINCIPALES METODOLOGÍAS PESADAS Y
ORIENTADAS A OBJETO EN EL
DESARROLLO DE SOFTWARE
Ing. Yunia Reyes González1, Ing. Lisbet M. González Bravo2, Msc. Yadira Ruiz Constanten3
RESUMEN
Para la construcción de cualquier software se hace necesario
el uso de metodologías de desarrollo que guíen el proceso
completo de elaboración del producto. De acuerdo a las
características de las metodologías se han identificado dos
corrientes principales: las que se pueden clasificar como
metodologías ágiles y las metodologías pesadas. En los
proyectos productivos que se desarrollan en la Universidad
de las Ciencias Informáticas (UCI) es común el uso de
ambas tendencias en dependencia de las características del
software y el equipo de desarrollo a cargo del mismo. A
pesar de la diversidad de metodologías representativas de
las clasificaciones anteriormente mencionadas, en los
proyectos de la UCI que se guían por metodologías pesadas,
se emplea generalmente el Proceso Unificado de Rational
(RUP). Este trabajo pretende realizar un estudio sobre las
principales metodologías pesadas y orientadas a objetos
(OO), con el propósito de servir de consulta y ayuda a los
equipos de desarrollo de software, para la elección de la
metodología más adecuada de acuerdo a las características
de cada proyecto. De esta forma se dispondría de un
conocimiento previo y organizado sobre estas metodologías
representativas de la corriente pesada, a fin de tomar la
decisión correcta.
Palabras claves: metodología, orientadas a objeto,
pesadas.
ABSTRACT
For the construction of any software is made necessary by
the use of development methodologies to guide the entire
process of product development. According to the
characteristics of the methodologies have been identified
two main streams: those that can be classified as agile
methodologies and heavy methodologies. In the productive
projects which are developed at the University of
Informatics Science (UCI) is common the use of the two
trends depending on the characteristics of software and
development team in charge of it. Despite the diversity of
methodologies representative of the classifications above, in
the projects of the UCI, which are guided by heavy
methodologies are generally used Rational Unified Process
(RUP). This paper aims to conduct a survey of key heavy
and object-oriented (OO) methodologies, with the aim of
serving as consultation and assistance to the teams of
software development, for choosing the most appropriate
methodology according to the characteristics of each
project. This would have a prior and organized knowledge
about these methodologies representative of the current
heavy, to take the right decision.
Keywords: heavy, methodology, object-oriented.
1. INTRODUCCIÓN
En todo proceso de desarrollo de software y por la urgente
necesidad de obtener productos de alta calidad que
satisfagan a plenitud las demandas de los clientes, se hace
imprescindible el estudio a profundidad de la diversidad de
metodologías de desarrollo de software que son esenciales
para el éxito de los proyectos, permitiendo potenciar los
grupos de desarrollos involucrados en tales temáticas.
En tal sentido, se hace importante la elección de una
metodología adecuada y ajustada al equipo de desarrollo
que permita la flexibilidad necesaria para lograr los
objetivos trazados al concebirse el proyecto, superando
incluso las expectativas iniciales de los clientes.
1
Sin dudas el éxito del producto, depende en gran medida, de
la acogida por el equipo de desarrollo que tenga la
metodología seleccionada.
En la Universidad de Ciencias Informáticas (UCI), se
desarrollan un conjunto de proyectos productivos que, como
en toda buena práctica de software, se rigen por
metodologías de desarrollo. En el caso de los proyectos de
gran dimensión cuyo resultado es a largo plazo y que
requieren una exquisita documentación y planificación se
usan metodologías tradicionales, aunque es generalizado en
estos casos el desarrollo de software guiados por el Proceso
Unificado de Rational (RUP) como metodología pesada y
orientada a objetos.
Actualmente no se cuenta con un material de consulta que
contenga las características de las principales metodologías
de desarrollo de software pesadas y orientadas a objetos que
permitan a un equipo de desarrollo conocer varias
metodologías para seleccionar la que más se adecúa al
proyecto que se debe desarrollar. Esta información se
encuentra disponible en varias fuentes de Internet, pero no
concentrada en una sola guía a la que pueda accederse
rápidamente.
Por tal motivo y por la importancia que reviste el tema de la
selección de la metodología para el desarrollo de software,
es propósito de esta investigación profundizar en el estudio
de las metodologías tradicionales y orientadas a objetos para
establecer un estudio comparativo que permita a todo un
equipo de proyecto determinar cuál es la metodología más
idónea a la hora de desarrollar el software. Por ello se
pretende exponer las características de las metodologías más
representativas de la corriente pesada y por demás orientada
a objetos.
II. DESARROLLO
¿Qué es una metodología de desarrollo de software?
Una metodología de desarrollo de software es un conjunto
de procedimientos, técnicas, herramientas y un soporte
documental que ayuda a los desarrolladores a realizar nuevo
software. La metodología indica cómo hay que obtener los
distintos productos parciales y finales.
Son características deseables de una metodología las
siguientes:
9 Existencia de reglas predefinidas.
9 Cobertura total del ciclo de desarrollo.
9 Verificaciones intermedias.
9 Planificación y control.
9
9
9
9
9
9
9
Comunicación efectiva.
Utilización sobre un abanico amplio de proyectos.
Fácil formación.
Herramientas CASE.
Actividades que mejoren el proceso de desarrollo.
Soporte al mantenimiento.
Soporte de la reutilización de software.
¿Cómo elegir una metodología?
En muchas ocasiones no se sigue una metodología cuando
se trata de proyectos pequeños de poco tiempo de duración,
sin embargo cuando se consideran proyectos de mayor
envergadura se hace imprescindible adoptar una
metodología que se ajuste a las necesidades tanto de los
clientes como del equipo de desarrollo.
Al elegir la metodología para guiar el proceso de desarrollo
que se va a emprender se debe tener en cuenta aspectos
como: el tiempo estimado de duración, la dimensión o el
tamaño del proyecto y la complejidad del mismo.
Clasificación de las metodologías
La comparación y clasificación de las metodologías resulta
una actividad compleja si se tiene en cuenta la diversidad de
propuestas y diferencias en el nivel de detalle, información
disponible y alcance de cada una de ellas.
Siguiendo como criterio de clasificación, las notaciones
empleadas para especificar artefactos producidos en
actividades de análisis y diseño, se pueden clasificar las
metodologías en dos grupos: Metodologías Estructuradas y
Metodologías Orientadas a Objetos.
Si se tiene en cuenta su filosofía de desarrollo, entonces se
pueden definir dos fuertes corrientes de metodologías:
Metodologías Tradicionales, conocidas también como
metodologías pesadas, las cuales ponen especial énfasis en
la planificación y control del proyecto, así como en la
especificación precisa de requisitos y el modelado; y las
denominadas Metodologías Ágiles, dirigidas sobre todo a
equipos de desarrollo pequeños, con mayor fuerza en
aspectos humanos asociados al trabajo en equipo e
involucran al cliente en el proceso como parte activa del
propio equipo de desarrollo y están orientadas sobre todo a
la generación de código con ciclos cortos de desarrollo.
La diferencia más notable entre estos dos grupos es que
mientras los métodos pesados intentan obtener los
resultados apoyándose principalmente en la documentación
ordenada, los métodos ligeros o ágiles tienen como base de
2
sus resultados la comunicación e interacción directa con
todos los usuarios involucrados en el proceso.
Se profundiza a continuación en las especificidades de las
metodologías tradicionales y a su vez, orientadas a objetos
que son el objetivo de esta investigación.
Metodologías tradicionales
Las metodologías tradicionales o clásicas exigen una
abundante y exhaustiva documentación, centrando su
atención en una detallada planificación, desde la fase inicial
del proyecto. De ahí que pueda decirse que imponen una
disciplina de trabajo durante todo el proceso de desarrollo
de software con la intención de obtener un producto más
predecible y eficiente. Se ajustan a proyectos de largo plazo
de duración y a entornos donde los requisitos son
predecibles, por lo que se consideran más predictivas que
adaptativas.
El gran auge de los lenguajes de programación orientados a
objetos y su amplia acogida en el mundo de la producción
de software y servicios informáticos sin lugar a dudas ha
propiciado el impulso de la filosofía de orientación a objetos
y con ello de las metodologías Orientadas a Objetos que
tienen su basamento en el uso de lenguajes de programación
de similar clasificación.
En la UCI el desarrollo de software se basa en lenguajes de
programación orientados a objetos y por ende se precisa de
metodologías con igual filosofía.
Metodologías Orientadas a Objetos
La esencia del desarrollo orientado a objetos es la
identificación y organización de conceptos del dominio de
la aplicación y no tanto de su representación final en un
lenguaje de programación.
Consideraciones sobre las metodologías Orientadas a
Objetos:
9 Se eliminan fronteras entre fases debido a la
naturaleza iterativa del desarrollo orientado al
objeto.
9 Aparece una nueva forma de concebir los
lenguajes de programación y su uso al incorporarse
bibliotecas de clases y otros componentes
reutilizables.
9 Hay un alto grado de iteración y solapamiento, lo
que lleva a una forma de trabajo muy dinámica.
Aspectos positivos de las metodologías orientadas a objetos:
9 Son interactivas e incrementales.
9 Fácil de dividir el sistema en varios subsistemas
independientes.
9 Se fomenta la reutilización de componentes.
Ejemplos comparativos
Se impone, entonces una comparación teniendo en cuenta
las principales características de las metodologías más
representativas guiadas por métodos pesados y orientadas a
objetos.
Técnica de modelado en Objetos (OMT)
La metodología OMT (Object Modeling Technique) fue
creada por James Rumbaugh y Michael Blaha en 1991.
OMT es una de las metodologías de análisis y diseño
orientadas a objetos, más maduras y eficientes que existen
en la actualidad. La gran virtud que aporta esta metodología
es su carácter de abierta (no propietaria), que le permite ser
de dominio público y, en consecuencia, sobrevivir con
enorme vitalidad. Esto facilita su evolución para acoplarse a
todas las necesidades actuales y futuras de la ingeniería de
software.
En ella se destacan 4 fases: Análisis, Diseño del Sistema,
Diseño de Objetos e Implementación y emplea 3 modelos
para describir un sistema: Modelo de objetos, Modelo
dinámico y Modelo funcional.
9 Modelo de Objetos. Se define como un diagrama
de objetos más un diccionario de datos. El
diagrama de objetos muestra clases y sus
relaciones (generalización, agregación, asociación,
instanciación). El diccionario de datos es el detalle
de las clases en el diagrama de objetos.
9 Modelo dinámico. Se define como un conjunto de
diagramas de estado más un diagrama de flujo de
eventos global.
9 Modelo funcional. Es un diagrama de flujo con
restricciones.
Etapas y definición de entregas
Análisis
9 Documento de análisis, que incluye:
•
Descripción del problema
•
Modelo de Objetos
•
Modelo dinámico
• Modelo funcional
1) Diseño del sistema
9 Definición de subsistemas
3
2) Diseño de objetos
9 Documento de diseño, que incluye versiones
detalladas de los modelos de objetos, dinámico y
funcional.
3) Implementación
9 Diseño de bases de datos, si se requieren.
9 Código.
Esta metodología es fuerte en el análisis por la clara
notación de relaciones y estructuras estáticas y débil en el
diseño, de ahí que no sea la más idónea para emplear en
proyectos donde se precisa de gran nivel de detalle en el
modelado del diseño del sistema.
Es muy fácil de aprender ya que para el 90% de casi todos
los proyectos, ocupan casi todo el mismo subconjunto de
notaciones, además debido a su sencillez se ha extendido a
casi todo los niveles de ingeniería de software, pero esta
simplicidad del método hace posible que en algunos casos
(sobre todo de sistemas complejos) no se puedan modelar
con este sistema.
Objectory
ObjectOry, una metodologia basada en el paradigma de
orientación a objetos, fue creada por la compañía Objectory
Systems, fundada en 1987 por Jacobson. Es un proceso
organizado para la construcción industrial de software. Este
proceso de diseño está guiado por casos de uso, una técnica
que centra el entendimiento de un sistema en la forma en la
cual es usado.
En esta metodología se destacan elementos como:
9 Modelo de Casos de Uso: Se basa en la
descripción de elementos o usuarios externos al
sistema (actores) y funcionalidad del sistema
(casos de uso).
9 Modelo de objetos: Representa la estructura
estática de los objetos. Puede contener objetos
entidad, de interfaz y de control, entre otros tipos;
y relaciones de herencia, y de comunicación entre
otras.
9 Diagrama de interacción. Muestran la secuencia
de eventos entre paquetes u objetos necesarios para
realizar un caso de uso.
9 Diagrama de estado. Muestra los estados internos
de un objeto complejo.
Algunos de los conceptos más importantes de esta
metodología son:
9
Objeto Entidad: Representa información del
sistema que debe sobrevivir cierto período de
tiempo. Es un refinamiento y formalización del
modelo de análisis. Su principal objetivo es
adecuar el modelo de análisis al ambiente de
implementación-tiempo, por ejemplo, un caso de
uso.
9 Objeto de Interfaz: Modela información y
comportamiento que es dependiente de la interfaz
actual del sistema.
9 Objeto de Control: modela funcionalidad que no
corresponde a ningún objeto en particular y que se
presenta en algunos casos de uso. Estos objetos
generalmente operan sobre varios objetos entidad,
realizan algún algoritmo y retornan algún resultado
a un objeto de interfaz.
9 Paquete: Módulo que contiene código, traducible
a un módulo en el lenguaje de implementación.
9 Unidad: En pruebas, desde una clase hasta un
subsistema.
Etapas y definición de entregas
Modelo de requerimientos
9 Modelo de Casos de Uso con interfaces de usuario
del sistema.
9 Modelo de objetos del dominio.
4) Modelo de análisis
9 Modelo de objetos con objetos Entidades, de
Interfaz y de Control
5) Modelo de diseño
9 Modelo de paquetes. Definición de módulos en la
implementación y detalle de las clases de diseño en
cada uno de ellos.
6) Implementación
9 Código de las clases, organizado por paquetes.
7) Pruebas
9 Definición de pruebas de unidad
9 Definición de pruebas de protocolo de clases.
Análisis y modelado de rol orientado a objetos
(OORAM):
El Método OORAM se remonta a principios de los años ’70
e introduce el concepto de modelo de roles como principal
mecanismo de abstracción.
4
El modelo de roles describe los objetos que participan en
una actividad y las interacciones entre ellos. El método
OOram se define como “un marco de referencia para una
familia de metodologías orientadas-a-objetos”, tras lo que se
muestran las mejoras que el método introduce en las tres
dimensiones típicas que componen el grueso de
metodologías:
9 Tecnología (conceptos, notación, técnicas y
herramientas): donde se muestran el poderoso
modelado de roles en análisis y su integración
posterior -síntesis en OOram-, junto con los
conceptos básicos (roles, puertos -que anuncian la
visibilidad de un rol respecto de otro-, etc.) y
algunas herramientas. Es interesante resaltar la
referencia de distintos conceptos a abstracciones:
Objeto es “es”, como rol es “por qué”, mientras
que tipo es “qué” y clase es “cómo”.
9 Proceso con Entregables (la secuencia de pasos y
la documentación que los acompaña): OOram
distingue tres distintos procesos: creación del
modelo, desarrollo del sistema y construcción de
piezas reutilizables.
9 Organización (las maneras en que la empresa
acoge lo anterior): aquí se explicitan las
dificultades de diseñar para reutilizar y las ventajas
que supone el uso de cadenas de valor.
El modelo de roles es una abstracción del modelo de objetos
donde se reconoce un patrón de objetos y se describe como
un correspondiente patrón de roles y es que la clase se
apoya en las capacidades (funcionalidad absoluta) de los
objetos, mientras que el rol se apoya en la posición y
responsabilidades de un objeto respecto de una estructura de
otros tantos, que es precisamente lo que percibimos cuando
examinamos un conjunto de entidades/objetos en
colaboración. El modelo de roles no representa la
descripción de la estructura entera de objetos observada,
sino más bien de porciones de la misma, segmentadas
temporalmente, denominadas “áreas de interés”, y que
muestran fenómenos colaborativos de interés. Resulta, así,
que un modelo de roles es un modelo orientado-a-objetos de
una estructura de objetos.
OOram plantea tres distintas perspectivas: contextual,
externa e interna, y provee diferentes “vistas” aplicables
según mejor convenga, siguiendo la acertada idea de que no
hay que usar todos los recursos para describir un modelo, y
que determinadas vistas, reunidas en un subconjunto
concreto, tornan el modelo más comprensible que otras. Así
OOram provee las siguientes vistas:
9
9
9
9
9
9
9
9
9
9
Vista del Área de Interés.
Vista del Estímulo-Respuesta.
Vista de la Lista de Roles.
Vista Semántica.
Vista de Colaboraciones.
Vista de Escenario.
Vista de Interfaces.
Vista de Procesos.
Vista de Diagramas de Estado.
Vista de Especificación de Métodos.
Booch
Booch es una metodología desarrollada por Grady Booch en
1996. Cubre las fases de análisis y diseño de un sistema
orientado a objetos. Se enfoca principalmente al diseño de
estado de un proyecto por la riqueza de su notación
reflejada en las interacciones entre entidades. Soporta el
desarrollo iterativo e incremental de un sistema. En muchas
ocasiones es criticada por el uso de muchos símbolos
distintos.
La metodología de Booch usa los siguientes tipos de
diagramas para describir las decisiones de análisis y diseño,
tácticas y estratégicas, que deben ser hechas en la creación
de un sistema orientado por objetos.
9 Diagrama de Clases. Consiste en un conjunto de
clases y relaciones entre ellas. Puede contener
clases, clases paramétricas, utilidades y metaclases.
Los tipos de relaciones son asociaciones,
contenencia, herencia, uso, instanciación y
metaclase.
9 Especificación de Clases. Es usado para capturar
toda la información importante acerca de una clase
en formato texto.
9 Diagrama de Categorías. Muestra clases
agrupadas lógicamente bajo varias categorías.
9 Diagramas de transición de estados: Muestra el
tránsito de los objetos de uno a otro estado.
9 Diagramas de Objetos. Muestra objetos en el
sistema y su relación lógica. Pueden ser diagramas
de escenario, donde se muestra cómo colaboran los
objetos en cierta operación; o diagramas de
instancia, que muestra la existencia de los objetos y
las relaciones estructurales entre ellos.
5
9
Diagramas de Tiempo. Aumenta un diagrama de
objetos con información acerca de eventos externos
y tiempo de llegada de los mensajes.
9 Diagramas de módulos. Muestra la localización
de objetos y clases en módulos del diseño físico de
un sistema. Un diagrama de módulos representa
parte o la totalidad de la arquitectura de módulos
del sistema.
9 Subsistemas. Un subsistema es una agrupación de
módulos, útil en modelos de gran escala.
9 Diagramas de procesos. Muestra la localización
de los procesos en los distintos procesadores de un
ambiente distribuido.
Etapas y definición de entregas
Análisis de requerimientos
9 Funciones primarias del sistema: Principales
entradas y salidas del sistema, referencias a
políticas, sistemas existentes o procedimientos.
9 Conjunto de mecanismos claves que el sistema
debe proveer: estado de entrada, estado de salida y
estados esperados.
Análisis de Dominio
9 Diagrama de clases con las abstracciones clave,
identificando las clases del dominio claves y sus
relaciones.
9 Especificación de las clases.
9 Vistas de herencia. Diagramas de clases con este
tipo de relaciones.
9 Diagramas de escenarios de objetos.
9 Especificación de objetos, que relacionan objetos y
sus clases.
Diseño
9 Descripción de arquitectura, que describe las
decisiones más importantes de diseño como son el
conjunto de procesos, manejadores de bases de
datos, sistemas operativos, lenguajes.
9 Descripciones de prototipo, que describen las
metas y contenido de las implementaciones
sucesivas de prototipos, su proceso de desarrollo y
la forma de probar requerimientos.
9 Diagramas de Categorías.
9 Diagramas de clases en diseño, detallan las
abstracciones de análisis con características de
implementación.
9
9
9
Diagramas de objetos en diseño, muestran las
operaciones necesarias para desarrollar una
operación.
Nuevas especificaciones.
Especificaciones de clases corregidas, muestra la
especificación completa de los métodos con
algoritmos complicados, la implementación de
relaciones y el tipo de atributos.
Rational Unified Process (RUP)
RUP es un marco de trabajo genérico que puede
especializarse para una gran variedad de sistemas de
software, para diferentes áreas de aplicación, diferentes
tipos de organizaciones, diferentes niveles de aptitud y
diferentes tamaños de proyectos.
RUP divide el proceso de desarrollo en ciclos, teniendo un
producto funcional al final de cada ciclo, cada ciclo se
divide en fases que finalizan con un hito donde se debe
tomar una decisión importante, las cuatro fases que incluye
RUP son:
9 Inicio, el objetivo en esta etapa es determinar la
visión del proyecto.
9 Elaboración, en esta etapa el objetivo es
determinar la arquitectura óptima.
9 Construcción, en esta etapa el objetivo es obtener
la capacidad operacional inicial.
9 Transición, el objetivo es llegar a obtener el
release (versión terminada y estable de una
aplicación informática) del proyecto.
Vale mencionar que el ciclo de vida que se desarrolla por
cada iteración, es llevada bajo dos disciplinas:
Disciplina de Desarrollo
9 Modelamiento del Negocio: Describe los procesos
de negocio, identificando quiénes participan y las
actividades que requieren automatización.
9 Requerimientos: Define qué es lo que el sistema
debe hacer, para lo cual se identifican las
funcionalidades requeridas y las restricciones que
se imponen.
9 Análisis y Diseño: Describe cómo el sistema será
realizado a partir de la funcionalidad prevista y las
restricciones impuestas (requerimientos), por lo
que indica con precisión lo que se debe programar.
9 Implementación: Define cómo se organizan las
clases y objetos en componentes, cuáles nodos se
6
utilizarán y la ubicación en ellos de los
componentes y la estructura de las capas de la
aplicación.
9 Pruebas: Busca los defectos a lo largo del ciclo de
vida.
Disciplina de Soporte
9 Administración de Configuración y Cambios:
Describe cómo controlar los elementos producidos
por todos los integrantes del equipo de proyecto en
cuanto a utilización/actualización concurrente de
elementos, control de versiones.
9 Administración
del
proyecto:
Involucra
actividades con las que se busca producir un
producto que satisfaga las necesidades de los
clientes.
9 Ambiente: Contiene actividades que describen los
procesos y herramientas que soportarán el equipo
de trabajo del proyecto; así como el procedimiento
para implementar el proceso en una organización.
9 Instalación: Produce release del producto y realiza
actividades para entregar el software a los usuarios
finales.
RUP está basado principalmente en tres características
fundamentales:
9 Dirigido por casos de uso: Un caso de uso es un
fragmento de funcionalidad del sistema que
expresa necesidades del usuario y produce un
resultado de valor para este. Todos los modelos
que se obtienen, como resultado de los diferentes
flujos de trabajo por los que transita todo el
proceso de desarrollo del software, representan la
realización de los casos de uso obtenidos cuando se
modelan las funcionalidades del sistema.
9 Centrado en la arquitectura: La arquitectura de
un sistema es la organización o estructura de sus
partes más relevantes. Muestra una visión del
sistema completo, describe los elementos del
modelo que son más importantes para su
construcción. El modelo de arquitectura se
representa a través de vistas en las que se incluyen
los diagramas de UML.
9 Iterativo e Incremental: Para facilitar el trabajo,
el proyecto se realiza mediante iteraciones que
terminan con un incremento. Cada iteración
comprende diferentes disciplinas y de esta resulta
una versión de un producto que irá creciendo en
cada iteración.
Como RUP es un proceso, en su modelación define como
sus principales elementos:
9 Actividades (“cómo”), Es una tarea que tiene un
propósito claro, es realizada por un trabajador y
manipula elementos.
9 Trabajadores
(“quién”),
Definen
el
comportamiento y responsabilidades (rol) de un
individuo, grupo de individuos, que trabajan en
conjunto como un equipo. Ellos realizan las
actividades y son propietarios de elementos.
Vienen a ser las personas o entes involucrados en
cada proceso.
9 Artefactos (”qué”), Un artefacto puede ser un
documento, un modelo, o un elemento de modelo,
o sea productos tangibles que son producidos,
modificados y usados por las actividades.
9 Flujo de actividades (“cuándo”), Secuencia de
actividades realizadas por trabajadores y que
produce un resultado de valor observable.
Una particularidad de esta metodología es que, en cada ciclo
de iteración, se hace exigente el uso de artefactos, siendo
por este motivo, una de las metodologías más importantes
para alcanzar un grado de certificación en el desarrollo del
software.
Ventajas
9 Evaluación en cada fase que permite cambios de
objetivos.
9 Es sencillo, ya que sigue los pasos intuitivos
necesarios a la hora de desarrollar el software.
9 Seguimiento detallado en cada una de las fases.
RUP concibe una disciplina dedicada específicamente a la
Gestión de Proyectos, esto es particularmente importante
para los equipos de desarrollo con una dirección inexperta y
que tiende a ser inestable. Además las características del
software, su complejidad y dimensión exigen de una
planificación y chequeo constantes, que son de las premisas
de RUP.
Se considera de gran importancia el modelado de procesos
del negocio en la fase de inicio. Esta es la base del logro de
un producto que cumpla con las necesidades de los clientes
y para ello define un grupo de artefactos que ayudan a
documentar y comprender lo que debe ser modelado como
parte del sistema.
Por lo general en cada una de las metodologías orientadas a
objetos citadas anteriormente, se le brinda especial interés a
un determinado proceso como puede ser análisis en OMT,
7
diseño si se aplica la de Booch o el modelo de roles
siguiendo OORAM, RUP sin llegar a dedicarle especial
interés a una disciplina en específico, define con exactitud
en cada una de las 9 que propone, los roles involucrados y
los artefactos que deben producir cada uno de los
trabajadores. Se debe entonces estudiar las características
del proyecto que se pretende desarrollar y a partir de ahí
hacer una evaluación sobre qué metodología elegir para
optimizar tiempo, facilitar la comunicación entre todo el
equipo de desarrollo y garantizar la calidad del producto
final.
III. CONCLUSIONES
Con esta investigación se tiene un compendio sobre las
principales metodologías tradicionales orientadas a objetos
que son representativas de esta corriente. Este estudio
servirá de guía de consulta a los futuros equipos de
desarrollo en la toma de decisiones sobre qué metodología
de esta clasificación se debe elegir en dependencia de las
características del proyecto que se desarrolle. Este es un
punto de gran importancia si se tiene en cuenta que la
mayoría de los proyectos requieren de metodologías
orientadas a objetos y guiadas por métodos pesados, por la
complejidad del producto a desarrollar que implica a un
gran número de estudiantes y profesores, en muchas
ocasiones inexpertos y para lo cual necesitan una
metodología que exija una detallada planificación y
abundante documentación.
Garzás, Javier. Revisión del Proceso de Desarrollo de
Software. Disponible en:
http://jgarzas.googlepages.com/Jgarzas_Proceso_Desarrollo
.pdf
Heilmann, Christian. “Beginning JavaScript with DOM
Scripting and Ajax”. 2006
Jacobson, I. , Booch, G. y Rumbaugh, J. “El Proceso
Unificado de Desarrollo de software”. 2000. 2000.
Morales Reyes, Alicia y Rugerio Ramos, Alma Rosa
“Metodologías para generación de Sistemas Orientados
a Objetos”
Universidad Rey Juan Carlos, “Metodologías de
Desarrollo Software”. Disponible en:
http://kybele.escet.urjc.es/documentos/ISG/Estructurado/%5
BISG-2006-07%5DMetodologiasDesarrolloSW.pdf
Universidad Politécnica de Valencia. “Proceso de
desarrollo de software”. Disponible en:
www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionP
rocesoSW.doc
IV. REFERENCIAS
Devis Botella, Ricardo. “Modelo de Roles”. Disponible
en:
http://www.arrakis.es/~devis/OOram.ppt#256,1,OORAM
Chávez Gaona, Víctor Manuel y Olivares Rojas, Juan
Carlos “Metodología OMT (Rumbaugh)” Disponible en:
http://www.monografias.com/trabajos13/metomt/metomt.sh
tml
Figueroa, Pablo, Metodología de desarrollo de software
Orientado por Objetos. Disponible en:
http://www.cs.ualberta.ca/~pfiguero/soo/metod/
Figueroa, Roberth G., Solís, Camilo, J. ,Cabrera, Armando
A. “Metodologías tradicionales vs. metodologías ágiles”,
2008. Disponible en:
http://adonisnet.wordpress.com/2008/06/18/metodologiastradicionales-vs-metodologias-agiles/
8