Modelos, conceptos

y tipos de
metodologías

Análisis de
Sistemas

1
Modelos, conceptos
¿Qué es un modelo y por qué modelamos?
Los proyectos de software que fracasan lo hacen por circunstancias
propias, pero todos los proyectos con éxito se parecen en muchos
aspectos. Entre todos los aspectos que hacen que un proyecto tenga éxito
uno en común es el uso del modelado.

El modelado es una técnica de Ingeniería probada y bien aceptada. Se

construyen modelos arquitectónicos de casas y edificios para ayudar a sus
usuarios a visualizar el producto final antes que el mismo esté construido.
Incluso podemos elaborar modelos matemáticos para analizar los efectos
de vientos o terremotos sobre los edificios.

Un modelo es una simplificación de la realidad. Un modelo proporciona los

planos de un sistema. Pueden ser planos generales, que ofrecen una visión
global del sistema en consideración, así como planos detallados. Un buen
modelo incluye, para un nivel de abstracción dado, los elementos que
tienen gran influencia y omite aquellos menores que no son relevantes.

Todo sistema puede ser caracterizado desde diferentes perspectivas,

utilizando diferentes modelos. Un modelo puede ser estructural resaltando
la organización del sistema o puede ser de comportamiento, destacando su
dinámica.

Se construyen modelos para comprender mejor el sistema que estamos

desarrollando. A través del modelado se persiguen los siguientes objetivos:

Los modelos ayudan a visualizar cómo es, o queremos que

sea un sistema.

Los modelos permiten especificar la estructura o el

comportamiento de un sistema.

Los modelos proporcionan plantillas que sirven de guía en

la construcción de un programa.

Los modelos documentan las decisiones que se han

adoptado.

2
Construimos modelos de sistemas complejos porque es difícil comprender
el sistema en su totalidad. El ser humano tiene una capacidad limitada para
comprender y abordar la complejidad, por ello a través del modelado
podemos reducir el problema que se está estudiando y enfocarnos en un
aspecto a la vez.

En general, aún en el proyecto más simple, los desarrolladores siempre

realizan alguna actividad de modelado como un bosquejo en hoja de papel
o en algún software graficador. Sin embargo, estos modelos informales no
proporcionan frecuentemente un lenguaje común que pueda compartirse
entre todos los desarrolladores y no siempre queda debidamente
documentado.

Así como existe un lenguaje común para realizar planos en la industria de la

construcción, en la Ingeniería Civil, Eléctrica, entre otros, también es
beneficioso para una empresa de software que todos sus desarrolladores
utilicen un lenguaje común para el modelado del software.

Principios básicos de modelado

Como se plantea en el libro “El lenguaje Unificado de Modelado”, la
experiencia en el uso del modelado sugiere los siguientes cuatro principios
básicos (Booch G., Rumbaugh J. y Jacobson I., 1999, págs. 7,8):

“La elección de los modelos a crear tiene mucha influencia sobre cómo se
aborda el problema y cómo de da forma a la solución.”

Esto quiere decir que hay que elegir bien los modelos. Los modelos
adecuados pueden arrojar mucha luz sobre los problemas de desarrollo
más complicados, brindando una comprensión que no podríamos obtener
de otra manera. Ahora bien, si se incurre en la utilización de modelos
erróneos o inadecuados, éstos desorientarán haciendo que uno se centre
en cuestiones irrelevantes.

“Todo modelo puede ser expresado a distintos niveles de precisión.”

Los mejores tipos de modelos son aquellos que permiten elegir el grado de
detalle dependiendo de quién está viendo el sistema y por qué necesita
verlo. Lo que un usuario final espera de un modelo del sistema no es lo
mismo que necesita un diseñador. Un analista o un usuario final se
centrarán en “qué” hace el sistema; un diseñador/desarrollador se

centrará en el “cómo”. Tanto unos como otros querrán visualizar un

sistema a diferentes niveles de detalle en diferentes momentos.

3
“Los mejores modelos son los que están ligados a la realidad.”

Todos los modelos simplifican la realidad; lo importante es que esta

simplificación no enmascare ningún detalle importante. Es mejor tener
modelos que tengan una clara conexión con la realidad y donde esta
conexión sea débil saber concretamente cómo se apartan estos modelos
del mundo real.

“No es suficiente confeccionar un único modelo. Todo sistema no trivial se

aborda mejor a través de un conjunto de modelos casi independientes.”

Si por ejemplo, se estuviera realizando la construcción de una casa, no hay

un único conjunto de planos que indiquen todos sus detalles sino que se
necesitarán planos de planta, de electricidad, de lozas, de agua, entre
otros. Lo mismo se aplica para los sistemas de software. Para comprender
la arquitectura de tales sistemas se necesitan varias vistas
complementarias y entrelazadas. Cuando se habla de modelos “casi
independientes” se refiere a tener modelos que podemos construir y
estudiar separadamente pero que están interrelacionados.

Tipos de metodologías

Concepto de Metodología

En principio podemos definir una metodología como “... un conjunto de

filosofías, fases, procedimientos, reglas, técnicas, herramientas,
documentación y aspectos de formación para los desarrolladores de
sistemas de información”, según lo expresa Piattini (2004, pág. 79)- citando
a Maddison - . De acuerdo a esta definición, una metodología es entonces
un conjunto de componentes que especifican:

Cómo dividir un proyecto en etapas.

Las tareas que se llevan a cabo en cada etapa.

Las salidas que se producen y cuándo se deben producir.

Las restricciones se aplican.
Las herramientas que se van a utilizar.

Cómo se gestiona y controla un proyecto.

Considerando una definición más genérica, podemos decir que una

metodología de desarrollo es un conjunto de procedimientos, técnicas,

4
herramientas y un soporte documental que ayuda a los desarrolladores a
realizar un nuevo software. Normalmente consistirá en una serie de fases
descompuestas en subfases (módulos, etapas, pasos, entre otras formas de
denominación). Esta descomposición del proceso de desarrollo guía a los
desarrolladores en la elección de las técnicas que debe elegir para cada
estado del proyecto, así como facilita la planificación, gestión, control y
evaluación de los proyectos.

Una metodología, por lo tanto, representa el camino para desarrollar software

de manera sistemática.

Se mencionan a continuación algunos conceptos relacionados con las

metodologías:

Métodos: Indican cómo construir técnicamente un sistema. Abarcan un

amplio espectro de tareas que incluyen la comunicación, el análisis de los
requisitos, el modelado de diseño, la construcción de programas, la
realización de pruebas y el soporte. Se basan en un conjunto de principios
básicos que gobiernan cada área de la tecnología e incluyen actividades de
modelado y otras técnicas descriptivas.

Técnica: Es un método estructurado y repetible para lograr una tarea

específica.

Herramientas: Suministran un soporte automatizado o semiautomatizado

para el proceso y los métodos. Cuando se integran herramientas para que
la información creada por una herramienta la pueda utilizar otra, se
establece un sistema de soporte para el desarrollo del software llamada
Ingeniería de Software Asistido por Computadora (CASE).

Objetivos de las Metodologías

Se pueden identificar, de forma general, tres necesidades principales que

se intentan cubrir con una metodología:

Mejores aplicaciones. De todos modos hay que tener en

cuenta que el seguimiento de una metodología no basta
para asegurar la calidad del producto, sino que esto
depende de muchos pequeños factores.

Un mejor proceso de desarrollo que identifica las salidas o

productos intermedios de cada fase, lo que permite
planificar y controlar el proyecto.

5
 Un proceso estándar en la organización, lo que aporta
entre otros beneficios una mayor integración entre los
proyectos de sistemas en marcha y una mayor facilidad en el
cambio de personal de un proyecto a otro.

Entre los objetivos que pueden tener las metodologías, podemos

mencionar:

Registrar los requisitos de un sistema de información de

manera apropiada.

Proporcionar un método sistemático de desarrollo de

forma que se pueda controlar su progreso.

Construir un sistema de información dentro de un tiempo

apropiado y costos aceptables.

Construir un sistema bien documentado y que sea fácil de

mantener.

Ayudar a identificar lo más pronto posible cualquier

cambio que sea necesario a realizar dentro del proceso de
desarrollo.

Proporcionar un sistema que satisfaga a todas las personas

afectadas por el mismo, ya sean clientes, directivos,
auditores, usuarios.

Características deseables en una buena Metodología

Entre las características deseables que debería incluir una metodología se

pueden destacar las siguientes:

Existencia de reglas predefinidas: La metodología debería

indicar formalmente reglas que definan sus fases, las tareas,
productos intermedios, técnicas y herramientas a utilizar.

Cobertura total del ciclo de desarrollo: Debe indicar los

pasos a seguir para cubrir desde el planteamiento de un
sistema hasta su mantenimiento.

6
 Verificaciones intermedias: Debe contemplar la
realización de verificaciones sobre los productos generados
en cada fase para comprobar su corrección.

Enlace con procesos de gestión: Debe proporcionar una

forma de desarrollar software de manera planificada,
controlada y de calidad.

Comunicación efectiva: Debería proporcionar un medio de

comunicación efectiva entre los desarrolladores para
facilitar el trabajo en grupo y con los usuarios.

Utilización sobre un abanico amplio de proyectos: Debe

ser flexible para poder emplearse en proyectos de diverso
tamaño, variedad y entorno.

Fácil formación: La organización debe formar a su

personal en todos los procedimientos y técnicas definidos
por la metodología.

Uso de herramientas CASE: La metodología debe ser

soportada por herramientas automatizadas que mejoren la
productividad del equipo de desarrollo y la calidad de los
productos obtenidos.

Contener actividades que mejoren el proceso de

desarrollo: Es necesario definir mediciones que indiquen la
calidad y el costo asociado a cada etapa del proceso. Estos
datos se utilizarán para analizar y modificar el proceso para
su mejora.

Soporte al mantenimiento: El campo de la evolución del

software debería ser tenido en cuenta por las metodologías
para facilitar las modificaciones sobre los sistemas
existentes.

Soporte de la reutilización de software: Se deberían

incluir procedimientos para la creación, mantenimiento y
recuperación de componentes reutilizables que no se
limiten sólo al código. La aplicación de patrones de software
en las distintas etapas del proceso de desarrollo ayuda a la
reutilización de soluciones de análisis y diseño.

7
Tipos de Modelos de Proceso

Como ya se mencionó anteriormente, una metodología debe cubrir todo el

ciclo de desarrollo de un sistema de software desde su planteamiento
hasta su evolución. Dentro de este ciclo de vida una porción muy
importante lo constituye el desarrollo del sistema de software.

Cualquier organización de ingeniería de software debe describir un

conjunto único de actividades para el proceso de software que adopte para
el desarrollo del sistema. También debe completar cada actividad con un
conjunto de acciones de ingeniería de software y definir cada acción en
cuanto a un conjunto de tareas que identifique el trabajo y los productos
del trabajo que deben completarse para alcanzar las metas de desarrollo.

Después, la organización debe adaptar el modelo de proceso resultante y

ajustarlo a la naturaleza específica de cada proyecto, a las personas que lo
realizarán y el ambiente en el que se ejecutará el trabajo.

Se mencionan a continuación algunos de los modelos prescriptivos de

proceso que consideramos más representativos tal como los presenta
Roger Pressman (2006) en su libro “Ingeniería de Software” (ver
Bibliografía), sin que esta enumeración sea exhaustiva ni la única manera
de clasificar los mismos. Luego en la Unidad 2 se presentará el Proceso
Unificado de Desarrollo.

El ciclo de vida clásico o en cascada

El modelo en cascada, llamado también el ciclo de vida clásico, sugiere un

enfoque sistemático, secuencial hacia el desarrollo de software tal como se
visualiza en la siguiente figura:

Figura 1: El ciclo de vida clásico en cascada

Fuente: Libro “Ingeniería del Software” – Roger Pressman (2006), Pág. 50.

El modelo en cascada es el más antiguo para la Ingeniería de software, sin

embargo las críticas realizadas a este modelo durante las décadas

8
precedentes ocasionaron que aún sus más fervientes seguidores se hayan
cuestionado su eficacia.

Entre los problemas que presenta el modelo en cascada podemos

enunciar:

Los proyectos reales rara vez siguen el flujo secuencial que

propone el modelo.

Frecuentemente es difícil para el cliente definir todos los

requisitos de manera explícita en el inicio del proyecto.

Una versión funcional de los programas sólo estará

disponible cuando el proyecto esté bastante avanzado, por
lo que el cliente deberá tener paciencia.

La naturaleza lineal del modelo en cascada conduce a situaciones en las

cuales algunos miembros del equipo de trabajo deben esperar a otros para
terminar tareas dependientes, lo cual “bloquea” el avance del proyecto. Sin
embargo, este modelo de proceso puede resultar útil en casos donde los
requerimientos están fijos y donde el trabajo se realice en forma lineal
hasta su conclusión.

Modelos de procesos incrementales

Muchas veces los requisitos iniciales del software están bien definidos de
manera razonable, pero el enfoque global del esfuerzo de desarrollo
excluye un proceso puramente lineal. Además, es probable que sea
necesario proporcionar de manera rápida un conjunto limitado de
funcionalidad para el usuario y luego refinarla y expandirla en las entregas
posteriores del software. En estos casos es conveniente elegir un modelo
de proceso diseñado para producir el software de manera incremental.

Se presentan a continuación dos modelos de proceso de este tipo.

a) El modelo incremental

El modelo incremental combina elementos del modelo en cascada aplicado

en forma iterativa. Como se muestra en la siguiente figura, este modelo
aplica secuencias lineales de manera escalonada conforme avanza el
tiempo en el calendario.

9
Figura 2: El modelo incremental

Fuente: Libro “Ingeniería del Software” – Roger Pressman (2006), pág. 52.

Cada secuencia lineal produce incrementos en el software. Con frecuencia,

el primer incremento es un producto esencial, es decir se consideran los
requisitos básicos pero muchas características complementarias aún no se
incorporan. El producto producido se muestra al cliente y como resultado
de la evaluación se desarrolla un plan para el incremento siguiente que
afronta la modificación del producto esencial a fin de satisfacer mejor las
necesidades del cliente e incorporar características y funcionalidades
adicionales.

Este proceso se repite después de la entrega de cada incremento hasta

producir el producto completo.

El desarrollo incremental es útil cuando el personal necesario para una

implementación completa no está disponible; si el producto esencial es
bien recibido se agrega el personal necesario para implementar el
incremento siguiente. Además los incrementos se pueden planear para
manejar los riesgos técnicos; por ejemplo, cierta funcionalidad puede
requerir el uso de un hardware nuevo que aún no está disponible entonces
se planean los primeros incrementos de manera que se evite el uso de este
hardware.

b) El modelo DRA

El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso

incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una
adaptación a “alta velocidad” del modelo en cascada en el que se logra el
desarrollo rápido mediante un enfoque de construcción basado en

10
componentes. Con una buena comprensión de los requisitos y se limita el
ámbito del proyecto, el proceso DRA permite que un equipo de desarrollo

obtenga el producto de software completamente funcional dentro de un

período muy corto, por ejemplo entre 60 y 90 días.

En la siguiente figura se ilustra el proceso DRA:

Figura 3: El proceso DRA

Fuente: Libro “Ingeniería del Software” – Roger Pressman (2006), pág. 54.

Si una aplicación de negocios se puede modular de modo que cada gran

función se pueda completar en menos de tres meses es una candidata para
aplicar DRA. Cada gran función se puede abordar por un equipo separado
aplicando DRA, luego se integran y se forma el todo.

Como todos los modelos de proceso, este enfoque presenta algunos

inconvenientes:

Para proyectos grandes escalables se necesitan suficientes

recursos humanos para crear el número correcto de equipos
DRA.

Los proyectos DRA pueden fracasar si los desarrolladores y

clientes no se comprometen con las actividades rápidas
necesarias para completar el sistema en tiempo breve.

11
 Es problemática la construcción de los componentes
necesarios para el DRA si el sistema no se puede modular en
forma apropiada.

Si el alto rendimiento es un aspecto importante y se

alcanzará al convertir interfaces en componentes del
sistema, este enfoque puede no funcionar.

El modelo DRA no es apropiado cuando los riesgos técnicos son altos, por
ejemplo cuando la nueva aplicación requerirá muchas nuevas tecnologías.

Modelos de procesos evolutivos

Al igual que todos los sistemas complejos, el software evoluciona con el

tiempo. Los requisitos del negocio y productos frecuentemente cambian
durante el proceso de desarrollo; en estos casos una ruta lineal que
conduzca al producto final no será real. En estas situaciones los ingenieros
de software necesitan un modelo de proceso que haya sido diseñado de
manera explícita para incluir un producto que evolucione con el tiempo.

Los modelos evolutivos son iterativos y se caracterizan por la forma en que

permiten que se desarrollen versiones cada vez más completas del
software.

Se presentan a continuación dos modelos de proceso de este tipo:

a) Construcción de prototipos

Frecuentemente los clientes definen un conjunto de objetivos generales

para el software pero no identifican los requisitos detallados de entrada,
proceso o salida. En estos casos y en muchas otras situaciones un modelo
de construcción de prototipos puede ser de utilidad.

En este modelo el proceso se inicia con la comunicación, en la cual el

ingeniero de software y el cliente encuentran y definen los objetivos
globales para el software, identifican los requisitos conocidos y las áreas
del esquema en las que se necesita más definición. Se plantea entonces
con rapidez una iteración de construcción de prototipos y se presenta el
modelado en forma de un diseño rápido. Este diseño rápido se centra en
una representación de los aspectos del software que serán visible para el
usuario final y conduce a la construcción de un prototipo. El cliente/usuario
evalúa el prototipo y con la retroalimentación se refinan los requisitos del
software que se desarrollará. La iteración ocurre cuando el prototipo se
ajusta para satisfacer las necesidades del cliente.

12
Figura 4: El proceso DRA

Fuente: Libro “Ingeniería del Software” – Roger Pressman (2006), pág. 55.

Si bien la construcción de prototipos se puede utilizar como un modelo de

proceso independiente, se emplea más comúnmente como una técnica
que puede implementarse dentro del contexto de cualquiera de los
modelos de proceso expuestos.

La construcción de prototipos también plantea algunos inconvenientes:

El cliente ve lo que parece una versión en funcionamiento

del software sin saber que por la prisa de hacer funcionar el
prototipo no se ha considerado la calidad del software
global o la facilidad de mantenimiento a futuro y le cuesta
comprender que debe construirse otra vez para mantener
los altos niveles de calidad.

Muchas veces el desarrollador establece compromisos de

implementación para lograr que el prototipo funcione con
rapidez y luego se familiariza con las selecciones realizadas y
se olvidan las razones por las que son inapropiadas.

b) El modelo en espiral

El modelo en espiral que fue propuesto originalmente por B. Boehm es un

modelo de proceso de software evolutivo que combina la naturaleza
iterativa de la construcción de prototipos con los aspectos controlados y
sistemáticos del modelo en cascada.

13
Cuando se aplica este modelo el software se desarrolla en una serie de
entregas evolutivas. Durante las primeras iteraciones la entrega tal vez
consista en un documento del modelo del sistema o un prototipo, luego

durante las últimas iteraciones se obtienen versiones cada vez más

completas del producto de software.

El modelo en espiral que se expone a continuación es una variación del

modelo original, presentada en el libro “Ingeniería de Software” de Roger
Pressman (2006) (ver Bibliografía).

Figura 5: Modelo en espiral

Fuente: Libro “Ingeniería del Software” – Roger Pressman (2006), pág. 58.

En el primer circuito del espiral quizá se genere la especificación del

producto y los pasos siguientes alrededor del espiral producirán el
desarrollo de un prototipo y luego progresivamente, versiones más
elaboradas del software. En cada paso sobre la región de planeación se
producen ajustes al plan del proyecto.

A diferencia de otros modelos de proceso que terminan cuando se entrega

el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de
todo el ciclo de vida del producto de software siguiendo la evolución del
mismo.

El modelo en espiral mantiene el enfoque sistemático de los pasos que

sugiere el modelo en cascada pero lo incorpora al marco de trabajo
iterativo que se adapta menor al mundo real. Asimismo, permite a los

14
desarrolladores aplicar la construcción de prototipos como un mecanismo
para reducir riesgos y en general en cualquier etapa evolutiva del producto.

De todos modos este modelo, al igual que otros, no está libre de

inconvenientes. Es difícil convencer a los clientes de que el enfoque
evolutivo es controlable; si un riesgo importante no se descubre y
administra apropiadamente, surgirán problemas.

15
Referencias
Bell Donald, “UML BasicsPart III: TheClassDiagram”, artículo publicado en el sitio
IBM Rational en Noviembre/2003.

Booch Grady, “Análisis y diseño orientado a objetos, con aplicaciones”, EE.UU,

Editorial Addison-Wesley Iberoamericana S.A., (1996). Capítulos: 1, 2, 3

Booch Grady, Rumbaugh James, Jacobson Ivar, (1999), “El lenguaje de

Modelado Unificado”, España, Editorial Addison Wesley Iberoamericana.
Capítulos: 1, 2, 4, 5, 8

Evans Gary, “Getting from Use. Case to code Part 1: Use Case Analysis”,
Artículo publicado en el sitio IBM Rational en Julio/2004.

Jacobson Ivar, Booch Grady, Rumbaugh James, (2000), “El Proceso

Unificado de Desarrollo de Software”, España, Editorial Addison Wesley. Capítulos:
1, 3, 4, 5

Piattini Mario, Calvo-Manzano, Cervera, Fernández, (2004), “Análisis y Diseño de

aplicaciones informáticas de gestión. Una perspectiva de Ingeniería de Software”,
Alfaomega Grupo Editor. Capítulo: 4

Pressman Roger, (2006), “Ingeniería de Software. Un enfoque práctico”

6ta. edición, Ed. McGraw Hill.

16