Analisis:y"tliseno te
Aplicaciones
Informaticas de Gestion
Una perspectiva-de-Ingenieria del Software
CLIENTE\. =
Mario G. Piattini.¢.José.A,-Calvo-Manzano
Joaquin Cervera..Luis. Fernandez
mre
PN Canis i oa ee CAPITULO 4
METODOLOGIAS DE DESARROLLO
DE SOFTWARE
41. INTRODUCCION
Como veremos en este capitulo, es necesario establecer un enfoque
disciplinado y sistemético para desarrollar un proyecto de software. Las metodologias
ce desarrollo, que influyen directamente en este proceso de construccién, se elaboran a
patir del marco definido por uno o varios ciclos de vida explicados en el capitulo
terior. Veremos qué caracteristicas debe tener una metodologia de desarrollo de
software, y cémo varfan en funcidn del enfoque de desarrollo, y daremos una visin
hist6rica de la evolucién de las metodologfas comentando las mas representativas.
4.1.1. Conceptos generales
Hay que destacar, ante todo, que no hay un consenso entre los autores sobre el
concepto de metodologia y, por lo tanto, no existe una definicién universalmente
septada, aunque sf hay un acuerdo en considerar a la “metodologia” como un
conjunto de pasos y procedimientos que deben seguirse para el desarrollo de software.
Una primera definicién representativa del concepto podria ser la de
(MADDISON, 1983], que define metodologia como un "conjunto de filosofias, fases,
procedimientos, reglas, técnicas, herramientas, documentacién y aspectos de
formacién para los desarrolladores de sistemas de informacién”. Segiin esto, una
netodologfa es un conjunto de componentes que especifican: BB
80 ANALISIS Y DISENO DE APLICACIONES INFORMATICAS DE GESTION RAMA
(Cémo se debe dividir un proyecto en etapas.
Qué tareas se Hevan a cabo en cada etapa.
Qué salidas se producen y cuando se deben producir.
Qué restricciones se aplican.
Qué herramientas se van a utilizar.
Como se gestiona y controla un proyecto.
‘Atendiendo a una definicién més genérica, podemos considerar una
metodologia de desarrollo como un conjunto de procedimientos, técnicas,
herramientas y un soporte documental que ayuda a los desarrolladores a realizar nueva
software. Normalmente consistird en un conjunto de fases descompuestas en subfases
(médulos, etapas, pasos, etc.). Esta descomposicién del proceso de desarrollo gufaa
los desarrolladores en la eleccién de las técnicas que debe elegir para cada estado del
proyecto, asi como facilita 1a planificacién, gestion, control y evaluacién de los
proyectos. Una metodologfa, por tanto, representa el camino para desarrollar software
de una manera sistematica.
De forma general, podemos identificar tres necesidades principales que s
intentan cubrir con una metodologia:
+ Mejores aplicaciones. Si consideramos "mejores sistemas" a los de mejor
calidad, hay que tener en cuenta que el seguimiento de una metodologia no
basta para asegurar la calidad del producto final. En general, el valor de los
sistemas de informaci6n resultantes dependen de multitud de pequ
factores (véanse los modelos de calidad en el Capitulo 12).
+ Un mejor proceso de desarrollo que identifica las salidas (0 product
intermedios) de cada fase de forma que se pueda planificar y controlar
proyecto. Ast, los sistemas se desarrollan més répidamente y con |
recursos apropiados.
+ Un proceso esténdar en la organizacién, 10 que aporta claros benefi
(por ejemplo, una mayor integracién entre los sistemas y una may
facilidad en el cambio del personal de un proyecto a otro)
Las metodologias 2 menudo tienen distintos objetivos y, por lo tanto, pI
diferir unas de otras. Estos pueden ser:
+ Registrar los requisitos de un sistema de informacién de una f
acertada. RAMA CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE 81
* Proporcionar un método sistematico de desarrollo de forma que se pueda
controlar su progreso.
+ Construir un sistema de informacién dentro de un tiempo apropiado y unos
costes aceptables.
* Construir un sistema que
‘aantener.
6 bien documentado y que sea facil de
+ Ayudar a identificar, lo mas pronto posible, cualquier cambio que sea
necesario realizar dentro del proceso de desarrollo.
* Proporcionar un sistema que satisfaga a todas las personas afectadas por el
mismo, ya sean clientes, directivos, auditores 0 usuarios.
La descomposici6n del proceso se realiza hasta el nivel de sareas o actividades
elementales. Para cada tarea se identifica un procedimiento que define la forma de
ejecutarla, y es el vehiculo de comunicacién entre usuarios y desarrolladores. Como
resultado de seguir un procedimiento, se obtienen uno © mas productos (éstos pueden
ser productos intermedios, si sirven de base para realizar nuevos productos durante el
desarrollo, 0 productos finales). El sistema deseado esté constituido por un conjunto
de productos finales.
Para aplicar un procedimiento se pueden utilizar una o més fécnicas. Estas
suelen ser, con mucha frecuencia, gréficas con apoyos textuales formales, y
determinan el formato de los productos resultantes de cada tarea. Podemos decir que
Jas técnicas se pueden utilizar varias veces dentro de una metodologia o en
metodologias diferentes.
Para la realizacién de una técnica, podemos apoyarnos en las herramientas'
sofiware que automatizan en mayor o menor grado su aplicacién (véase el Capitulo
18). Algunas herramientas se han disefiado para que den soporte especifico a una
metodologia y, por lo tanto, a las técnicas que necesita. Sin embargo, se pueden
encontrar herramientas de propésito mas general que dan soporte a varias
‘metodologfas, por lo que incluyen un conjunto mas amplio de técnicas.
r Veamos un ejemplo para ilustrar estos conceptos. Supongamos una
metodologia en la que hay una tarea que define un procedimiento para construir un
modelo conceptual de datos. Para ello, se puede elegir la técnica de Chen o el
formalismo individual de MERISE (técnicas similares para el modelado de datos).
' Hay veces que se consideran herramientas a técnicas realizadas “en papel” como, por
No, las matrices (que ayudan principalmente a realizar una verificacién entre los datos y los
sos de un sistema, aunque tienen muchas otras aplicaciones). Consideramos que la herramienta es
aplicaciGn software que gestiona la técnica de las matrices permitiendo su realizacién, verificacién y
‘mantenimiento de sus datos. 82__ANALISIS Y DISENO DE APLICACIONES INFORMATICAS DE GESTION RAMA
Ademés se dispone de una herramienta que permite realizar y verificar el diagrama
asi como mantener su informacién de forma consistente. Como resultado, obtengo el
modelo conceptual de datos, que sera un producto intermedio y servird de base para
realizar el modelo l6gico de datos.
Hay que aclarar una confusin existente entre los términos metodologia,
método y ciclo de vida, ya que hay autores que los utilizan indistintamente. Por
ejemplo, [YOURDON, 1993] considera estos términos sindnimos a la metodologia,
aunque se pueden observar las siguientes diferencias:
+ Una metodologia puede seguir uno 0 varios modelos de ciclo de vida, esto
es, el ciclo de vida indica qué es lo que hay que obtener a lo largo del
desarrollo del proyecto, pero no cémo. Esto sf lo deberfa indicar la
metodologfa.
* Una metodologfa es un concepto més amplio que el de método. Asi,
podemos considerarla como un conjunto de métodos. Inicialmente existfan
métodos que se centraban en una fase del ciclo de vida, métodos de
programaci6n estructurada, a los que siguieron los de disefio estructurado
y, después, anélisis estructurado. A partir de aqui se produce un punto de
inflexi6n al establecerse métodos conjuntos de anilisis y disefo
estructurado, enlazando las dos fases. Se ve una tendencia a ir abarcando el
ciclo de vida completo.
4.1.2. Vision historica del desarrollo de metodologias de
desarrollo de sistemas de informacion
Los enfoques metodoldgicos han ido evolucionando a Jo largo del tiempo.
Inicialmente se identifica un perfodo de desarrollo convencional, durante el cual las
pricticas de desarrollo eran totalmente artesanales y no habia metodologias definidas,
Jo que acarreaba multitud de problemas. Se empez6 a ver la necesidad de definir unas
aproximaciones mas sistemiticas en el desarrollo. Posteriormente surge el desarrollo
estructurado, partiendo de la programacién estructurada a los que siguieron los
métodos de andlisis y diseffo estructurados, hasta llegar a metodologias estructuradas
que cubren el ciclo de vida completo. En la actualidad aparece el paradigma de la
orientacién a objetos como un nuevo enfoque en la ingenieria del software.
4.1.2.1, DESARROLLO CONVENCIONAL,
En los afos cincuenta, cuando los sistemas se asociaban principalmente a
aplicaciones de tipo cientifico, no existian metodologfas de desarrollo. La utilizacién
de los primeros ordenadores en entornos de gestién, no fue acompafiada de guias rasta CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE 83
pricticas para la creacién de aplicaciones comerciales. Estas aplicaciones se basaban
en funciones bisicas de proceso de datos, como copias, recuperaciones, ordenaciones,
etc. Las personas que desarrollaban tales sistemas eran programadores, mas enfocados
en la tarea de codificar que en la de recoger y comprender las necesidades de los
usuarios. Estos, a menudo, no quedaban satisfechos con el sistema porque
necesidades no estaban definidas con claridad en una fase de anélisis previo.
Ante esta perspectiva, se vio la importancia del andlisis y el disefio en el
desarrollo de un sistema. Hubo un cambio importante de papeles dentro de las
organizaciones y se comenz6 a hablar de analistas-programadores y de analistas de
sistemas. Se observ6 que habfa més de un papel en el proceso de desarrollo de
sistemas; operadores, programadores y analistas de sistemas. Los analistas se dividfan
en dos tipos: analistas funcionales y analistas técnicos, también denominados analis
orgénicos. Los primeros analizaban las necesidades de la organizacién y se
encargaban de comunicarlas al analista técnico que se preocupaba, principalmente, del
disefio de los sistemas que satisfacfan dichas necesidades. El analista técnico
comunicaba entonces su disefio a los programadores.
‘Aun asi, el enfoque convencional tiene serios problemas, entre los que
destacamos los siguientes
+ Los resultados finales son impredecibles. No se sabe cudndo puede
acabar realmente el proyecto. Esto es problemdtico en la asignacién de
recursos antes y durante el desarrollo y en el compromiso de entrega del
sistema al usuario final a una fecha concreta. Ademés los resultados
pueden ser muy distintos en proyectos similares, ya que el proceso de
desarrollo no depende del método sino de la capacidad y experiencia de los
desarrolladores.
+ No hay forma de controlar lo que esta sucediendo en el proyecto. El
jefe de proyecto, al no existir fases establecidas y productos intermedios
coneretos sobre los que realizar verificaciones, no puede saber cudl es el
estado actual del proyecto, lo que influye en su toma de decisiones. Esto
Teva también a una deteccién tarda de los defectos que se pueden
presentar cuando se est probando el cédigo, o atin peor, cuando el sistema
ya esta en explotacién, con lo que los costes se disparan. Para controlar lo
que esta sucediendo en un proyecto hay que establecer puntos de control
donde se verifique, por medio de revisiones formales o informales, que el
desarrollo avanza de forma adecuada, para confirmar que los defectos
detectados son corregidos y que, en su correccién, no se producen nuevos
defectos,
+ Los cambios organizativos afectan negativamente al proceso de
desarrollo. En una organizacién que desarrolla software de manera 4
84_ANALISIS Y DISENO DE APLICACIONES INFORMATICAS DE GESTION cues
convencional, no suelen existir documentos estandarizados y, si los hay, a
veces no se actualizan adecuadamente. Por tanto, las personas que se
integren en la orgai."zaci6n estan desfasadas respecto a lo que realmente se
est haciendo.
4.1.2.2. DESARROLLO ESTRUCTURADO
El nacimiento de las técnicas estructuradas se puede considerar un punto de
partida en el que se pasa de la construccién de programas de una forma artesanal a una
que sigue unos métodos de ingenierfa, sentando las bases para un desarrollo
automatizado. Estas técnicas estaban dirigidas a aspectos tanto técnicos como de
gestion en la construcci6n de software. El concepto de programacién estructurada se
introdujo en la comunidad académica a finales de los afios sesenta, pasando las
técnicas al entorno industrial a mediados de los setenta.
Programacién estructurada
El enfoque de desarrollo estructurado comenz6 con la programacién, para
determinar cémo se debfa ver un programa tanto de forma estética como dindmica, de
forma que fuera lo més comprensible posible. Se establecieron unas normas para la
aplicaci6n de las estructuras de datos y de control [WARNIER, 1974].
Diseiio estructurado
A mediados de los afios setenta, el enfoque estructurado se extiende a la fase
de disefio. Aparecen las primeras publicaciones sobre el disefio de [MYERS, 1975],
[YOURDON y CONSTANTINE, 1975], y posteriormente [PAGE-JONES, 1980], en
Jos que se define un nivel de abstraccién mas amplio, utilizando el médulo de
Programa como componente basico de construccién. Se refina el concepto de
modularidad, normalizando la estructura de un médulo de programa, restringiendo las
relaciones entre médulos y estableciendo medidas en la calidad de los programas.
Posteriormente, se revisan y mejoran los conceptos de disefio estructurado en [PAGE-
JONES, 1988] y [YOURDON y CONSTANTINE, 1989].
Anilisis estructurado
Hasta la aparici6n de los primeros conceptos sobre el andlisis estructurado, en
Ja gran mayoria de proyectos de desarrollo, se hacfa una especificacin narrativa de
los requisitos, tal y como los percibia el analista. Los primeros autores sobre el andlisis
estructurado, [GANE y SARSON, 1977], [WEINBERG, 1978] y [DEMARCO, 1979]
sefialaron que estas especificaciones estaban afectadas por diversos problemas: —
RAMA
CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE _ 85
itos
+ Eran monoliticas: Habia que leer la especificacién de requi
completamente para poder entenderla.
+ Eran redundantes: Frecuentemente se repetfa la misma informacién en
partes diferentes del documento. Esto implica que si cambia algtin requisito
del usuario, se deberfa modificar en varios lugares del documento para
evitar inconsistencias.
+ Eran ambiguas: Un informe detallado de los requisitos se interpretaba de
forma diferente por usuarios, analistas y disefiadores. En algunos estudios
(por ejemplo, [MARTIN, 1984]), se encontré que el 50% de los errores que
aparecen en el sistema en explotacién se podia atribuir a malas
interpretaciones de la especificaci6n.
+ Imposibles de mantener: Cuando se legaba al final del proceso de
desarrollo, la especificacién funcional era casi obsoleta.
Mientras se debatfan estos problemas, habfa avances en programacién y
disefio estructurado, que prometian mejoras en la construccién de sistemas. En
realidad dichos trabajos eran titiles, pero si el andlisis era erréneo, el problema de
hacer un buen disefio estructurado era "de segundo orden”. Se realizarfa una buena
solucién a un problema equivocado, por falta de un andli
is correcto.
Por ello, ha habido un movimiento gradual hacia las especificaciones
funcionales:
+ Graficas: Compuestas por variedad de diagramas, apoyadas con técnicas
textuales detalladas, que sirven como material de referencia a la
especificacién,
+ Particionadas: De forma que se puedan leer porciones independientes de
Ia especificacién
+ Minimamente redundantes: De forma que los cambios afecten a una
parte de la especificacién (a requisitos especificos, sean funcionales 0 no
funcionales).
Este enfoque, que se conoce como andlisis estructurado (o también anilisis
descendente 0 “top-down"), se utilizaba principalmente en organizaciones de
desarrollo de sistemas de gestién. Desde entonces, se han contemplado diversos
cambios: 86 _ANALISIS Y DISENO DE APLICACIONES INFORMATICAS DE GESTION RAMA
+ Dar menor importancia a la construccién de los modelos fisicos actuales y
modelos légicos actuales *.
* Diferenciar mas los modelos fisicos y modelos légicos, conceptos algo
confusos en el anidlisis estructurado clasico.
+ Ampliar las técnicas de andlisis estructurado para poder modelar sistemas
de tiempo real. El andlisis estructurado clasico no tiene manera de modelar
el comportamiento dependiente del tiempo de un sistema. Para ello,
principalmente se amplia la notacién en la técnica de los Diagramas de
Flujo de Datos (DED) y se affade la técnica de Diagramas de Transicién de
Estados (DTE) (véase el Capitulo 7).
+ Enfocarse en el modelo de datos. El andlisis estructurado se preocupa casi
totalmente en el modelo de las funciones que debe Hevar a cabo un sistema.
El modelado de datos se hacfa de una forma bastante primitiva.
+ Estudio de los eventos. El proceso de anélisis estructurado cambia
afiadiendo Ia lista de eventos, concepto que introdujeron [MCMENAMIN
y PALMER, 1984], y los extendieron [WARD y MELLOR, 1985].
Finalmente, podemos ver a través de la Tabla 4.1, cémo han surgido las
metodologfas mas representativas en la historia de la Ingenierfa del Software
METODOLOGIA
Conceptos sobre la programacién estructurada de DIIKSTRA, WARNIER y
JACKSON
1974 ‘Técnicas de programacién estructurada de WARNIER y JACKSON
1975 Primeros conceptos sobre disefio estructurado de MYERS y YOURDON
1977 Primeros conceptos sobre anilisis estructurado GANE y SARSON
1978 Andlisis estructurado: DEMARCO y WEINBERG
Nace MERISE
1981 SSADM (versi6n inicial)
Information Engineering (versi6n inicial)
Tabla 4.1. Relacion historica de las principales metodologias estructuradas
2 Los modelos fisicos actuales son modelos que representan los diferentes procesos que realize
el sistema actual y que indican detalles de e6mo interactian los usuarios sobre los mismos y dénde se
localizan dentro de la organizacién. Los modelos Iégicos s6lo representan los procesos funcionales a un
nivel abstracto. RAMA, CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE _ 87
METODOLOGIA
Anilisis y Disefio estructurado para sistemas de tiempo real de
WARD y MELLOR
1986 SSADM Version 3
1987 Anilisis y Disefto estructurado para sistemas de tiempo real de HATLEY y
PIRHBAY
1989 METRICA (versi6n inicial)
1990 SSADM Version 4
1993 METRICA Versién 2
1995 METRICA Versién 2.1
2001 METRICA Versién 3
—
Tabla 4.1. Relaci6n histérica de las principales metodologras estructuradas (continuacién)
4.1.2.3, DESARROLLO ORIENTADO AL OBJETO
EI paradigma orientado a objetos, a diferencia del enfoque estructurado, trata
los procesos y los datos de forma conjunta, es decir, modulariza tanto la informacién
como el procesamiento. Al igual que los métodos estructurados (que se iniciaron con
Ja programaci6n), la orientaci6n a objetos empieza con los lenguajes de programacién
orientados a objetos (LOO). Mientras evolucionaban los lenguajes de alto nivel
convencionales, surgidos de la tradicién de FORTRAN y ALGOL, los investigadores
tabajaban en una nueva clase de lenguajes de simulacién y de creaciGn de prototipos
como el SIMULA y Smalltalk. En estos lenguajes se daba énfasis a la abstraccién de
datos y los problemas del mundo real se representaban como un conjunto de objetos
de datos para los que se adjuntaba un conjunto de operaciones. Los primeros trabajos
sentaron las bases de este enfoque al establecer la importancia sobre la abstraccién,
ocultacién de la informacién y modularidad, aspectos derivados del disefio
estructurado. Durante los afios ochenta, la evolucién de lenguajes de programacién
como Smalltalk, C++, y Objetive-C, produjeron un gran interés para la expansién al
disefio orientado a objetos (DOO).
A partir de mediados de dicha década, la orientacién al objeto alcanzé gran
Fesonancia como consecuencia de dos conferencias celebradas en 1986:
‘Object-Oriented Programming Workshop", organizada por IBM en Yorktown
Heights y la "First International Conference on Object-Oriented Programming
Systems, Languages and Applications- OOPSLA", celebrada en Portland, Oregén.
Esta dltima ha venido celebréndose anualmente, convirtiéndose en el evento
internacional més relevante sobre la orientacién al objeto. '88 _ANALISIS Y DISENO DE APLICACIONES INFORMATICAS DE GESTION rasta
Un aspecto que ha influido de manera importante en el desarrollo de
metodologias orientadas al objeto es el Ienguaje ADA, sobre todo por el interés del
Departamento de Defensa (DoD) de los Estados Unidos en definir y/o mejorar las
metodologias basadas en este lenguaje; entre las que destacan [BOOCH, 1983], [1986]
y [1991], GOOD (General Object-Oriented Design) [SEIDEWITZ y STARK, 1986],
[BUHR, 1984] y [BUHR, 1991], [EVB, 1985], HOOD (Hierarchical Object Oriented
Design) [ESA, 1989a] y [ESA, 1989b], etc.
Por otra parte, los conceptos de las técnicas estructuradas (SA/SD) han servido
de base para muchas de las metodologfas orientadas al objeto propuestas hasta la fecha
como, por ejemplo, OOSD (Object Oriented Structured Design) [WASSERMAN et
al., 1990] 0 SYNTHESIS [PAGE-JONES y WEISS, 1989]; al igual que el desarrollo
de los modelos conceptuales (seménticos) como el modelo entidad/interrelacién
(ME/R), por ejemplo [SHLAER y MELLOR, 1988], OMT (Object Modeling
Technique) [RUMBAUGH er al., 1991], etc. Otra metodologia "clésica" como la JSD
de Jackson, también ha influido en algunas metodologfas recientes como MOON y
00-ISD.
Asimismo, algunas técnicas como el "disefio de bloques", utilizado en
telecomunicaciones, y otras de inteligencia artificial e ingenieria del conocimiento
(IM/IC) han marcado algunas de las metodologias orientadas al objeto como
Objectory/OOSE (Object Oriented Software Engineering) [[ACOBSON er al., 1992]
y SOMA (Semantic Object Modeling Approach) [GRAHAM, 1993], respectivamente.
Posteriormente comenzaron a aparecer nuevas metodologias de desarrollo
orientado al objeto, catalogadas como de "segunda generacién”, basadas en las citadas
anteriormente; de las que formarfan parte [SINGER, 1993], FUSION propuesta por
[COLEMAN et al., 1994], OOA/D de [BOOCH, 1994], MOSES de
|[HENDERSON-SELLERS y EDWARDS, 1994], SYNTROPY de [COOK y
DANIELS, 1994] 0 MEDEA [PIATTINI, 1994a]. En esta segunda generacién se
aprovechan las ténicas y los procedimientos de las primeras metodologias,
especialmente las tarjetas de clase de CRC (Class Responsability Collaborator), el
proceso y la notacién de disefio de [BOOCH, 1991], el modelo de clases de OMT y
los escenarios de JACOBSON, con el fin de construir metodologias més completas y
sistemdticas, en las que desempefian también un papel relevante las métricas y los
lenguajes formales, asi como modelos para la mejora del software, como los del SEI
(CMM) 0 ISO (SPICE).
A partir de 1996 incluso se podrfa hablar de una tercera generacién de
métodos OO que se caracteriza por un intento de integrar varios métodos existentes.
Este es del comienzo de la unificacién de los métodos de Booch y Rumbaugh
[RUMBAUGH, 1996] lo que derivarfa, junto con Jacobson, en la aparicién del
Lenguaje de Modelado Unificado (UML’). En enero de 1997 fue presentada la versién
1.0 de UML al Object Management Group (OMG) que lo adopté como estindar a
3 Del inglés, Unified Modeling Language. RAMA CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE _ 89.
finales de 1997 con la versi6n UML 1.1. En 2001 OMG realiza el lanzamiento de la
version 1.4 [OMG, 2001] y actualmente se esté trabajando en la versién 2.0. Surge
también el método OMEGA/OPEN [HENDERSON-SELLERS y GRAHAM, 1996]
que integra los métodos de BON, MOSES y SOMA. El esfuerzo de unificacin se
realiza principalmente sobre las notaciones de las técnicas utilizadas para el modelado
00. Los métodos no especifican el proceso a seguir durante el desarrollo y, por esta
raz6n, son “independientes de la metodologfa”.
Los mismos autores crean la metodologia del Proceso Unificado-Unified
Process, (UP)- JACOBSON et al., 1999], derivada de la metodologia Objectory
ACOBSON et al., 1992], que establece un marco de procesos que guia las
actividades para el desarrollo de sistemas OO de distinto tamafio y complejidad. La
empresa Rational distribuye el proceso de desarrollo empaquetado como un producto
denominado RUP (Rational Unified Process) [KRUCHTEN, 2000}.
En los tiltimos afos estén ganando gran popularidad nuevos métodos de
desarrollo, englobados en lo que los precursores denominan “desarrollo dgil” (Agile
Developmen*) como intento de simplificar la complejidad de las metodologias
existentes, creando nuevas metodologfas que denominan “ligeras” [FOWLER, 2001]
El objetivo de la apaticién de estas metodologfas es la biisqueda de un equilibrio entre
el seguimiento de un proceso de desarrollo que sea excesivo 0 muy “burocratico” y la
inexistencia del mismo.
Dentro de los métodos de desarrollo gil, quiz el que tiene mas popularidad
es el método de Programacién extrema (XP) 0 eXtreme Programming desarrollado por
Kent Beck en 1996 [BECK, 1999]. Podemos encontramos con otros métodos como
Dynamic System Development Method (DSDM) [STAPLETON, 1997], el método de
desarrollo adaptativo de (HIGHSMITH, 1999], Scrum [SCHWABER y BEEDLE,
2001], u otros métodos emergentes como, por ejemplo, Cristal, por Alistair Cockburn
[COCKBURN, 2001]. La metodologia RUP por ejemplo, puede adaptarse al
desarrollo dgil y adaptar las reglas buenas practicas de los métodos de desarrollo
4gil, ya que no son excluyentes.
4.2, CARACTERISTICAS PRINCIPALES DE LAS METODOLOGIAS
En este apartado comentaremos la relaci6n existente entre la metodologia y el
entorno de desarrollo de una organizacién y, posteriormente sefialaremos un conjunto
de caracteristicas que son deseables en una metodologia.
4.2.1. Impacto de la metodologia en el entorno de desarrollo
de software
Todo entorno de desarrollo incluye un conjunto de componentes que
condicionan la construccién de software. Cualquier cambio que se realice dentro del 90 _ANALISIS ¥ DISENO DE APLICACIONES INFORMATICAS DE GESTION RAMA
entorno puede tener un efecto inmediato sobre la productividad del personal de
desarrollo (por ejemplo, cambios en los procedimientos de gestién del proyecto,
sistema operativo, lenguaje de programacién, etc.). La productividad en sf no basta y
debe es‘ar asociada a la calidad de los productos finales. La metodologia de desarrollo
es el coraz6n de este entorno e influye muy directamente en estos dos factores.
ENTORNO DE DESARROLLO DE SOFTWARE
EQUIPO DE DESARROLLO DE SOFTWARE
METODOLOGIA\
DE
DESARROLLO
aap i
ORGANIZACION DE DESARKOLLO DE SOFTWARE
Figura 4.1. Interaccién de la metodologia dentro del entorno de desarrollo de
software [WASSERMAN, 1981]
En la Figura 4.1 se muestra la relaci6n entre la metodologia y el entorno de
desarrollo, Dentro del entorno, la organizacién mantiene a un equipo de desarrollo de
software. Los procedimientos de gestién determinan el tipo de soporte automatizado
tanto hardware como software que se debe proporcionar, especificando las
herramientas necesarias para el desarrollo. Los procedimientos de gestién coordinan y
guian a los desarrolladores en el empleo de las técnicas. A su vez, el soporte
automatizado mejora la productividad automatizando diversas tareas y verificando su
correcta realizaci6n. De cualquier forma, no todos los resultados de las tareas son
susceptibles de ser verificados de forma automatizada, y siempre es necesaria la
realizaci6n de revisiones manuales incluidas en los procedimientos de gestin (véase
el Capitulo 13). Todos los entornos de desarrollo de software, aunque suelen tener —
RAMA CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE 91
objetivos similares, tienen formas de trabajo muy diferentes, Por ello, la organizacién
de desarrollo tiene dos opciones:
* Seleccionar entre un gran mimero de posibilidades y combinaciones de
métodos de gestién, técnicas de desarrollo y soporte automatizado, para
crear y desarrollar la metodologia de desarrollo software més apropiada.
* Analizar y evaluar las metodologias existentes y adoptar en la organizacién
la que mas se ajuste a sus necesidades. En general, esta opcién es la mas
comin,
La metodologia también esta influenciada por consideraciones como el
tamailo y estructura de la organizacién, asf como el tipo de aplicaciones que va a
desarrollar. Por ello, no es razonable pensar que dos organizaciones utilicen la misma
metodologia sin realizar cambios sobre ella, ajustindola a su organizacién y sus
Proyectos, Esta ha “sido ta causa de la existencia de muchas metodologias
(ILONGWOTH , 1985] hizo un estudio en el que identificé 300 metodologias
diferentes). Otros autores, aseguran que hay miles de metodologias ms 0 menos
similares, pero las diferencias entre ellas son triviales [VERYRARD, 1985], bien
Porque se quiere diferenciar comercialmente a las metodologias en el mercado o bien
Por el ajuste necesario de la metodologfa a cada entorno particular de empresa.
4.2.2. Caracteristicas deseables de una metodologia
Una metodologia de desarrollo deberia incluir una serie de caracteristicas
deseables entre las que destacamos las siguientes:
1. Existencia de reglas predefinidas
La metodologia deberfa indicar formalmente unas reglas que definan sus fases,
las tareas, los productos intermedios, las técnicas y herramientas, las ayudas al
desarrollo y los formatos de documentacién estindares,
2. Cobertura total del ciclo de desarrollo
Debe indicar los pasos que hay que realizar desde el planteamiento de un
sistema hasta su mantenimiento, proporcionando mecanismos para integrar los
Resultados de una fase a la siguiente, de forma que pueda referenciar a fases previas y
comprobar el trabajo realizado.
3. Verificaciones intermedias
La metodologia debe contemplar la realizacién de verificaciones sobre los
Productos generados en cada fase para comprobar su correccién. Se tealizan por
medio de revisiones de software, que detectan las inconsistencias, inexactitudes, 0 92_ANALISIS Y DISENO DE APLICACIONES INFORMATICAS DE GESTION Rane
cualquier otro tipo de defecto que se genera durante el proceso de desarrollo, evitando
que salgan a relucir en Ia fase de pruebas, en las pruebas de aceptacién o, atin peor,
durante la fase de mantenimiento, donde las correcciones de los defectos son mucho
mis costosas que en las fases iniciales.
4. Enlace con Procesos de Gestion
La metodologia debe proporcionar una forma de desarrollar software de
manera planificada, controlada y de calidad. Por ello, sin bien no se incluyen procesos
de gestién de proyectos en una metodologia, ésta deberia dar pautas o
recomendaciones para enlazar las actividades de desarrollo del proyecto con
5. Comunicacién efectiva
La metodologfa deberfa proporcionar un medio de comunicacién efectiva
entre los desarrolladores para facilitar el trabajo en grupo y con los usuarios.
6. Utilizacién sobre un abanico amplio de proyectos
La metodologfa debe ser flexible, para que pueda emplearse sobre un amplio
abanico de proyectos, tanto en variedad, tamafio y entorno. Una organizacién no
deberia utilizar metodolog(as diferentes para cada proyecto sino que la metodologfa se
debe poder amoldar a un proyecto concreto.
7. Fécil formacién
La metodologfa la utiliza todo el personal de desarrollo de una organizacién,
por lo que los desarrolladores deben comprender las técnicas y los procedimientos de
gestién, La organizacién debe formar a su personal en todos los procedimientos
definidos por la metodologta.
8. Herramientas CASE
La metodologia debe estar soportada por herramientas automatizadas que
mejoren Ia productividad del equipo de desarrollo y la calidad de los productos
resultantes. Como una metodologia define las técnicas que hay que seguir en cada
tarea, es necesario disponer de una herramienta que soporte, en mayor o menor grado,
la automatizacién de dichas tareas.
9. La metodologia debe contener actividades que mejoren el proceso de desarrollo
Uno de los principios de la ingenierfa del software es el compromiso claro
sobre la mejora del proceso de desarrollo. Para ello, es necesario disponer de datos que onawa CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE 93
muestren a efectividad de la aplicacién del proceso sobre un determinado producto.
Para ello, es necesario definir mediciones que indiquen la calidad y el coste asociado a
cada etapa del proceso, idealmente soportadas por herramientas CASE. Estos datos se
deben utilizar para analizar y modificar el proceso para su mejora.
10. Soporte al mantenimiento
Las metodologias tradicionales se enfocaban en el desarrollo de los sistemas.
Pero una vez Hegado el mantenimiento, no se consideraban técnicas para la evolucién
I6gica del sistema, que se encuentra en un entorno cambiante, debido principalmente a
los cambios tecnoldgicos y a las nuevas necesidades de los usuarios. El campo de la
evolucién del software (véase el Capitulo 15) deberfa ser tomado en cuenta por las
metodologias para facilitar, en el mayor grado posible, las modificaciones sobre los
sistemas existentes.
II. Soporte de la reutilizacién de software
Las metodologias existentes no proporcionan mecanismos para la reutilizacin
de componentes software. Se deberfan incluir procedimientos para la creacién,
mantenimiento y recuperacién de componentes reutilizables que no se limiten s6lo al
cédigo.
4,3. CLASIFICACION DE LAS METODOLOGIAS
Para poder realizar una clasificacién, hay que atender a tres dimensiones 0
puntos de vista, como podemos ver en la Tabla 4.2. Por ejemplo, podemos considerar
la metodologia de andlisis y disefio estructurado de [YOURDON, 1990] como una
metodologia de enfoque estructurado, orientada a procesos para sistemas de gestin y
de tiempo real, que no utiliza métodos formales; otro ejemplo es el de la metodologfa
de andlisis y disefio de sistemas para tiempo real de [WARD y MELLOR, 1985], que
se puede clasificar como una metodologia estructurada (orientada a procesos), de
tiempo real y no formal.
ENFOQUE TIPO DE SISTEMA.
ESTRUCTURADAS, GESTION
* Orientadas a Procesos
* Orientadas a Datos
- Jerdrquic
No jerarq
* Mixtas
ORIENTADAS A OBJETOS
FORMALIDAD
NO FORMAL
GESTION/TIEMPO REAL
FORMAL
Tabla 4.2. Tres dimensiones para la clasificacién de metodologias. Se pueden pensar
metodologtas combinando las dimensiones enfoque, tipo de sistema y formalidad
nA Cc 94 ANAL
Y DISENO DE APLICACIONES INFORMATICAS DE GES
RAMA
4.3.1. Metodologias estructuradas
Las metodologias estructuradas proponen la creacién de modelos del sistema
que representan los procesos, los flujos y la estructura de los datos de una manera
descendente (“top-down”). Se pasa de una visién més general del problema (un nivel
alto de abstraccién mis cercano a las personas) hasta llegar a un nivel de abstraccién
mas sencillo (més cercano al “hardware"). Esta visién, se puede enfocar en las
funciones (0 procesos) del sistema, en la estructura de los datos, o en ambos aspectos,
dando lugar a los siguientes tipos de metodologias:
+ Orientadas a proc
s.
+ Orientadas a datos: podemos considerar dos tipos:
— Orientadas a estructuras de datos jerarquicas.
— Orientadas a estructuras de datos no jerérquicas.
+ Mixtas: Que se enfocan tanto en los procesos como en los datos tomando
también en consideracién el factor “tiempo” con el andlisis de los eventos.
4.3.1.1. METODOLOGIAS ORIENTADAS A PROCESOS
La ingenierfa del software esté fundada sobre el modelo basico de
entrada/proceso/salida de un sistema. Los datos se introducen en el sistema y el
sistema responde ante ellos, transformadndolos para obtener las salidas. Este modelo
basico lo utilizan todas las metodologias estructuradas. Estas metodologias se enfocan
fundamentalmente en la parte del proceso y, por esto, se describen como un enfoque
de desarrollo de software orientado al proceso.
Como ejemplos de metodologias orientadas a procesos, tenemos las
metodologfas de [DEMARCO, 1979], [GANE y SARSON, 1979] y, posteriormente,
[YOURDON, 1989] que se basan en la utilizacién de un método descendente de
descomposicién funcional para definir los requisitos del sistema. Se apoyan en
téenicas gréficas dando lugar a un nuevo concepto que es la especificacién
estructurada.
Una especificacién estructurada es un modelo grifico, particionado,
descendente y jerarquico de los procesos del sistema y de los datos utilizados por los
procesos. Se compone de:
* Diagramas de Flujo de Datos (DFD). Son diagramas que representan los
procesos (funciones) que debe Ilevar a cabo un sistema a distintos niveles
de abstraccién y los datos que fluyen entre las funciones. Los procesos mas
complejos se descomponen en nuevos diagramas hasta llegar a procesos -_
RAMA
CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE _95
sencillos. Es la técnica ms importante del andlisis estructurado, y se
emplea en todas las metodologfas de anilisis y disefio estructurados.
* Diccionario de datos. Es el conjunto de las definiciones de todos los datos
que aparecen en el DFD, tanto almacenados como en los flujos de datos
+ Expecificaciones de proceso. Describen con més detalle lo que ocurre
dentro de un proceso, es decir, definen cémo se obtienen las salidas del
proceso a partir de sus entradas.
A continuacién se presentan las actividades de las principales metodologias
estructuradas.
Metodologia de De Marco
Los pasos de la metodologia de DEMARCO, [1979] son:
1, Estudio del entorno fisico actual
Antes de estudiar las necesidades del usuario, se comienza haciendo un
modelo del sistema actual en el que se muestran los procedimientos
actuales estén 0 no automatizados. El modelo resultante sera verificable
por el usuario. Para ello, se realiza un conjunto de DFD fisicos actuales.
2. Derivacién del correspondiente modelo légico actual
En esta etapa se obtiene un modelo derivado del anterior, pero sin
connotaciones fisicas (como pueden ser, por ejemplo, los lugares de la
empresa donde se realiza un determinado proceso).
3. Derivacién del nuevo modelo légico
En esta etapa se toman en consideracién las nuevas necesidades de los
usuarios, estableciendo un modelo que describe aquello que hay que hacer,
pero no cémo. El resultado es una especificacién estructurada formada,
como se comenté anteriormente, por los DFD, el diccionario de datos y las
especificaciones de procesos del sistema
4. Crear un conjunto de modelos fisicos alternativos
A partir del modelo l6gico se establecen diferentes alternativas de las que
se escogerd posteriormente la mas conveniente. Aqui se analiza el enlace
de los procesos con el usuario, esto es, se vuelven a afiadir connotaciones
fisicas, pero ahora, del nuevo sistema. 96 _ANALISIS Y DISENO DE APLICACIONES INFORMATICAS DE GESTION RAMA
5. Valorar cada opcién
Se estudian los coct#s y los beneficios de los modelos fisicos obtenidos
anteriormente.
6. Seleccionar una opcién.
Se selecciona el modelo fisico a partir de los datos derivados del paso
anterior.
7. Empaquetar la especificacién
Se recopila toda la documentacién en un documento de especifi
Metodologia de Gane y Sarson
La metodologia de desarrollo [GANE y SARSON, 1977] es el resultado de
varios aiios de aplicacién préctica, en cuanto a formacién y consultorfa en métodos de
andlisis y disefio estructurados de sistemas. Fue creada por la empresa MCAUTO/IST
bajo el nombre de STRADIS SDM (STRuctured Analysis Design and Implementation
of information Systems, System Development Methodology).
FASES DEL ANALISIS ESTRUCTURADO
Método de DeMarco Método de Gane y Sarson
~ Construir el modelo fisico actual (DFD
fisico actual).
Construir el modelo Iégico actual (DFD
l6gico actual),
T. Construir el modelo I6gico actual (DFD
I6gico actual).
Construir el modelo légico del nuevo
sistema: elaborar una especificaci6n
estructurada y construir un modelo légico
de datos en tercera forma normal que
exprese el contenido de los almacenes de
datos.
Seleccionar un modelo l6gico.
. Crear un conjunto de modelos fisicos
alternativos.
4, Estimar los costes y tiempos de cada
opcién,
5. Seleccionar un modelo.
._ Empaquetar la especificacién,
Crear el nuevo modelo fisico del sistema,
5. Empaquetar la especificacién.
Tabla 4.3. Diferencias entre las metodologias de DeMarco y Gane/Sarson
En su libro, Gane y Sarson sélo hacen una breve presentaci6n de lo que es la
metodologfa: la mayor parte del libro se dedica a la descripcién de las técnicas que
utiliza, La metodologia en sf es parecida a la de DeMarco. La principal diferencia es RAMA CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE 97
que hay una etapa en la que se definen los contenidos de los almacenes que aparecen
en el DED en tercera forma normal (véase la Tabla 4.3).
Tanto la metodologia de DeMarco como la de Gane y Sarson se fueron
mejorando y refinando, expandiéndose a las fases de disefio e implementacién
Metodologia de Yourdon/Constantine
La metodologia de anilisis y disefio estructurado de [YOURDON y
CONSTANTINE, 1989] consta de las siguientes fases:
1. Realizar los DFD del sistema.
2. Realizar el diagrama de estructuras, obteniéndolo a partir de los DFD,
mediante dos técnicas: el andllisis de transformacién y el andlisis de
transacci6n.
3. Evaluacién del disefio, midiendo la calidad de la estructura resultante
mediante el acoplamiento y la cohesién.
4. Preparaci6n del disefio para la implantaci6n, es decir, dividirlo en unidades
fisicas de implantacién denominadas cuadernos de carga.
43.1.2. Metodologias orientadas a datos jerarquicos
Dentro del modelo basico entrada/proceso/salida de un sistema, éstas
_ mnetodologias se orientan més a las entradas y salidas. Primero se definen las
estructuras de datos y, a partir de éstas, se derivan los componentes procedimentales.
En este enfoque es destacable que:
* La estructura de control del programa debe ser jerdrquica y se debe derivar
de la estructura de datos del programa.
* El proceso de disefio consiste en definir primero las estructuras de los datos
de entrada y salida, mezclarlas todas en una estructura jerérquica de
programa y después ordenar detalladamente la l6gica procedimental para
que se ajuste a esta estructura.
* El disefio 16gico debe preceder y estar separado del disefio fisico.
Como ejemplo de metodologias tenemos los métodos JSP y ISD de Jackson,
(JACKSON, 1975] y [CAMERON, 1989}), la construccién légica de programas
(LCP) de [WARNIER, 1974] y el desarrollo de sistemas estructurados de datos (LCS)
de [WARNIER y ORR, 1981]. Este método de disefio se basa en la identificacin de
i 98__ANALISIS Y DISENO DE APLICACIONES INFORMATICAS DE GESTION RAMA
datos primarios y datos secundarios (calculados). A partir de la construccién de un
diccionario de datos, el método se centra en el conjunto de actualizaciones y
modificaciones necesarias pa- obtener Ia salida. Originalmente, el LCS trabaja con
ficheros como estructuras de datos.
4.3.1.3. METODOLOGIAS ORIENTADAS A DATOS NO JERARQUICOS
Las metodologfas basadas en la informacién se centran en la creencia de que
los datos (tipos de datos) son el coraz6n del sistema de informacién, ya que son més
estables que los procesos que actian sobre ellos. La metodologia que identifique con
éxito la naturaleza de los datos de una organizacién, partird de una base estable para
construir los sistemas de informacién. Los procesos también se estudian en este tipo
de metodologfas, pero vienen derivados de una definicién inicial de los datos, que se
representan por medio de un modelo de los datos utilizados por la organizacion. Este
modelo estaré formado por el conjunto de entidades de datos bisicas y las
interrelaciones entre ellas. Con este enforque, todos los sistemas construidos estén
integrados sobre un mismo modelo de datos.
Un ejemplo de este tipo puede ser la metodologfa Ingenierfa de la Informacién
(Information Engineering (IE)), que parte de una metodologia de modelado de datos
creada en Australia por Clive Finkestein a finales de los setenta, y se publica
posteriormente en colaboracién con James Martin en [MARTIN y FINKELSTEIN,
1981].
La metodologia queda dividida en cuatro etapas, con los siguientes objetivos:
+ Planificacién: Construir una arquitectura de la informacién y una
estrategia que soporte los objetivos de la organizacién.
+ Andlisis: Comprender las areas del negocio y determinar los requisitos del
sistema,
* Disefio: Establecer el comportamiento del
que sea alcanzable por la tecnologfa.
stema deseado por el usuario y
* Construccién: Construir sistemas que cumplan los tres niveles anteriores.
4.3.1.4. METODOLOGIAS MIXTAS
A finales de los afios setenta y principios de los afios ochenta diversos
organismos gubernamentales y de la administracién en distintos paises europeos
plantearon la necesidad de establecer metodologfas de desarrollo con el objeto de
estandarizar los diferentes proyectos de tecnologias de la informacién que estaban OBAMA CAPCTULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE 99)
siendo realizados por los diferentes organismos. Empiezan a surgir metodologias
estructuradas que cubren con més amplitud el proceso de desarrollo y utilizan técnicas
que estudian los sistemas desde varios puntos de vista, tanto en la visin de los
procesos © funciones del sistema, las estructuras de los datos, el estudio de eventos,
etc. Entre las principales metodologias podemos destacar las siguientes:
Metodologia Merise
Las bases de la metodologfa MERISE comenzaron a desarrollarse en el aiio
1972 en el seno de un pequefio equipo universitario de ingenieros en Aix-en-Provence.
Este equipo fue animado desde el principio por Hubert Tardieu, concluyendo una
primera version a finales de 1976.
El proyecto de crear una metodologia parti6 del Centre Technique
Informatique (CTI) del Ministerio de Industria Francés en septiembre de 1977 para
cubrir las necesidades tanto de la administracién como de las empresas. Se realiza con
1a colaboracion de diversas empresas de servicios. Este proyecto finalizé en mayo de
1978 dando lugar a MERISE como metodologfa de Andlisis y Disefio de Sistemas de
Informacién. Inicialmente, se utiliza de manera restrictiva, a la espera del lanzamiento
oficial que se realiza por el CTI, en 1979.
Las mayores aportaciones de la metodologta son:
* Un ciclo de vida més largo que los existentes hasta entonces que se
materializa en un conjunto definido de etapas, con la inclusion de una etapa
de planificacién, previa al desarrollo, denominada esquema director.
¢ Introduccién de dos ciclos complementarios: ciclo de abstraccién y ciclo de
decisi6n. El ciclo de abstraccién se basa en la percepcién de tres niveles de
abstraccién: conceptual, organizativo y fisico u operative (véase la Tabla
44). Se definen dos modelos para cada nivel: un modelo de datos y un
modelo de tratamientos.
Nivel conceptual
Corresponde a las finalidades de la empresa. Se ocupa de definir el "Qué" a
través de un conjunto de reglas de gestidn, objetivos y limitaciones que pesan sobre la
empresa.
Nivel organizativo
Corresponde a la organizacién adecuada que hay que implantar para alcanzar
los objetivos asignados al sistema. Requiere una especificacién de los puestos de
i ~ 100 _ANALISIS Y DISENO DE APLICACIONES INFORMATICAS DE GESTION ORAMA
trabajo, cronologia de las operaciones, la eleccién de la automatizacién, asf como la
distribucidn geografica de datos y de tratamientos.
Nivel fisico
Corresponde a la integracién de los medios técnicos necesarios para el
proyecto. Se expresan en términos de materiales 0 componentes software. Este nivel
es el que estd sujeto a mas cambios como resultado de los progresos tecnolégicos.
TRATAMIENTOS
CONCEPTUAL Modelo Conceptual de Datos Modelo Conceptual de
Tratamientos
ORGANIZATIVO Modelo Légico de Datos Modelo Organizativo de
Tratamientos
FisICcO. ic Modelo Operativo de
Tratamientos
Tabla 4.4. Resultados en los niveles de MERISE
Metodologia SSADM
A principios de la década de los afios ochenta, el gobierno briténico plantea la
necesidad de crear una metodologfa de desarrollo, en un intento de estandarizar los
diferentes proyectos de tecnologfa de la informacién que estaban siendo realizados en
los departamentos gubernamentales. El desarrollo se realiza de forma conjunta entre el
Central Computing and Telecommunications Agency (CCTA) y Learmonth and
Burchett Management Systems (LBMS), dando como resultado la metodologia
SSADM (Structured Systems Analysis and Design Method).
Desde su aparicién, SSADM ha ido evolucionando, en parte, para corregir
debilidades en el método, pero principalmente como una respuesta al cambio
tecnolégico. En 1986 se realiza el lanzamiento de la versién 3, donde el principal
cambio fue la introduccién de una nueva técnica, el diseito del didlogo (técnica
utilizada para disefiar la interfaz de usuario) para afrontar el crecimiento del
procesamiento interactivo.
‘A pesar de que SSADM fue disefiada para el gobierno, el CCTA lo dispuso
como un estindar abierto, para que fuera disponible libremente tanto en entornos,
industriales como académicos. Esto ha resultado muy beneficioso tanto para la
industria como para el método, por la constante aportacién de herramientas que
soportan la metodologfa. -
RAMA CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE _101
El estado actual de SSADM es la versién 4, lanzada en julio de 1990
(MALCOM, 1992], que supuso un cambio importante en la estructura del método,
incorporando nuevas técnicas en el proceso de diseiio.
Los aspectos claves de SSADM son:
+ Enfasis en los usuarios: Sus requisitos y participacién.
+ Definicién del proceso de produccién: Qué hacer, cudndo y cémo.
* Tres puntos de vista: Datos, eventos y procesos.
* Maxima flexibilidad en herramientas y técnicas de implementacién.
SSADM proporciona un conjunto de procedimientos para llevar a cabo el
andlisis y disefio, pero no cubre aspectos como la planificacién estratégica, ni entra en
laconstruccién del cédigo, tal y como se muestra en la Figura 4.2.
Planificacién
Estratégica
Construceisn y Pruebas
Produccién
i
Administracién y Control
Figura 4.2. Cobertura de SSADM al ciclo de vida
Metodologia Métrica
Metodologfa que surge en 1989 con el objeto de crear un marco metodolégico
comin para la planificacién y el desarrollo de Sistemas de Informacién de la
Administracién ptiblica espafiola. En 1993 aparece la segunda versién de la
Metodologia [MAP, 1993], en la cual participan personal de varios ministerios y
organismos de la Administracién Publica espafiola en colaboracién con la empresa
Coopers & Lybrand. Posteriormente se revisa con el lanzamiento de la versién 2.1
[MAP, 1995] 102_ANALISIS Y DIsi
DE APLICACIONES INFORMATICAS DE GESTION oRaMA
En el afio 2001 surge la tercera versin de la metodologfa en la que se amplia
para cubrir los desarrollos orientados a objetos y ademas se establecen las interfaces
entre las actividades de la metodologia con los procesos de gestién asociados al
desarrollo, como son la gestién de proyectos, gestién de configuracién, aseguramiento
de la calidad y seguridad [MAP, 2001]. Esta versién se analiza con detalle en el
Capitulo 8.
4.3.2. Metodologias orientadas a objetos
Para el desarrollo orientado al objeto podemos encontraros, tal y como
sefialamos en el Apartado 4.1.2.3, con diferentes enfoques metodolégicos. En este
apartado analizamos brevemente el enfoque del Proceso Unificado de Rational (RUP).
El proceso RUP [KRUCHTEN, 2000] es un proceso de Ingenierfa del
Software que define un enfoque disciplinado para el desarrollo de software con el
objetivo de asegurar la produccién de software de calidad dentro de unos recursos de
plazo y presupuesto. Es concebido como un producto (de proceso) desarrollado y
mantenido por la empresa Rational.
Las caracterfsticas principales del proceso son las siguientes:
+ Proporciona miltiples gufas al personal de desarrollo para facilitar el
desempefio de su funcién.
* Los modelos creados en las diferentes actividades utilizan de forma general
la notacién de UML. Estos modelos tienen un alto soporte por
herramientas de desarrollo.
+ Bs un proceso configurable, por lo que se puede ajustar a las caracteristicas
especificas de un proyecto en cuanto a tamafo y complejidad.
+ Utiliza un conjunto buenas practicas (pricticas asentadas y validadas en el
desarrollo de software) que describimos brevemente:
= Desarrollo iterativo: En contrapartida con un desarrollo secuencial en
cascada, en un desarrollo iterativo se gana conocimiento del sistema a
través de refinamientos sucesivos. Cada iteraci6n representa un periodo
de tiempo en el que se realizan diferentes actividades de desarrollo con
objeto de disponer al final de la misma de una versi6n ejecutable del
sistema en un momento dado. En las siguientes iteraciones se realizan
refinamientos y ampliaciones llegando al sistema final. RAMA
CAPITULO 4: METODOLOGIAS DE DESARROLLO DE SOFTWARE _103
— Gestin de Requisitos: Define un proceso de gestién de requisitos para
capturar, organizar, documentar y realizar el seguimiento de los
requisitos del sistema y permite su trazabilidad con otros modelos
generados durante el desarrollo.
— Utilizacién de Arquitecturas basadas en componentes: El proceso RUP
se enfoca en el desarrollo inicial de una arquitectura software robusta
antes del desarrollo funcional del sistema.
— Verificacién de la calidad: Se debe revisar la calidad del sistema
respecto de los requisitos de fiabilidad, funcionalidad y rendimiento.
Para ello, RUP da asistencia al proceso de planificacién, disefio,
implementacién, ejecucién y evaluacién de estos tipos de pruebas. En
RUP el aseguramiento de la calidad no la realiza un grupo de personas
aparte como una actividad separada del desarrollo, sino que implica a
todos los participantes, est4 presente en todas las actividades de
desarrollo, y utiliza unos criterios y medidas objetivos.
— Control de cambios del software: El proceso RUP proporciona gufas
para controlar y seguir los cambios durante el desarrollo.
El proceso RUP se puede describir en funcién de dos dimensiones:
Dimensién temporal del proces:
iteraciones e hitos.
: Se expresa en términos de ciclos, fases,
Dimensién estatica del proceso: Se expresa en términos de actividades,
productos intermedios (artifacts), perfiles de trabajo o roles (workers) y
flujos de trabajo (workflows).
DIMENSION TEMPORAL
Atendiendo a la dimensién temporal, el ciclo de vida se divide en ciclos,
entendiendo como tales a perfodos de tiempo en los que se trabaja sobre una version
completa del sistema. Cada ciclo se compone de cuatro fases que se realizan
secuenicialmente (véase la Figura 4.3):
Fase de Comienzo: El objetivo de esta fase es estudiar la viabilidad del
sistema. Para ello se establece el objetivo del sistema y se delimita su
alcance definiendo, ademés, las estimaciones de recursos y un plan de
tiempos general indicando los hitos principales, previsiones financieras, los
riesgos del proyecto y los criterios para el éxito del mismo. Al finalizar
esta fase se decide si continuar o no con el proyecto. 104 ANALISIS Y DISENO DE APLICACIONES INFORMATICAS DE GESTION oRaMa
ee ae Fases =
Inception Elaboration Construction Transition
Comienzo | —| Elaboracién |—+{ Construccién}-+ | Transicion
tine pe er aia eri a
1 =
aa 14 iteracién 2|¢ Iteracion 3
Sat La versién producida en la
ee Proceso
También podría gustarte
- Mod sws310 sls510Documento4 páginasMod sws310 sls510Omar LichtjahreAún no hay calificaciones
- PDX HojadeDatos PDFDocumento4 páginasPDX HojadeDatos PDFOmar LichtjahreAún no hay calificaciones
- Pressman R 2005 .Ingenieri A de Software PDFDocumento9 páginasPressman R 2005 .Ingenieri A de Software PDFOmar LichtjahreAún no hay calificaciones
- Tema 1 - NETDocumento10 páginasTema 1 - NETJuan Carlos Ferrer OrtizAún no hay calificaciones
- EZ320 Manual Spanish PDFDocumento25 páginasEZ320 Manual Spanish PDFOmar LichtjahreAún no hay calificaciones
- Mettler Toledo 8440 Service Manual PDFDocumento315 páginasMettler Toledo 8440 Service Manual PDFOmar LichtjahreAún no hay calificaciones
- Larman C 2006 - UML y PatronesDocumento45 páginasLarman C 2006 - UML y PatronesOmar LichtjahreAún no hay calificaciones
- PDX HojadeDatosDocumento4 páginasPDX HojadeDatosOmar LichtjahreAún no hay calificaciones
- PDX Brochure Es SaDocumento8 páginasPDX Brochure Es SaOmar LichtjahreAún no hay calificaciones
- Manual Tecnico JagxtremeDocumento298 páginasManual Tecnico JagxtremeOmar LichtjahreAún no hay calificaciones
