La Ingeniería de Software surge como la aplicación de modelos y
formas de la ingeniería tradicional a la práctica de construir
productos de software. situación que ha condicionado su accionar
al tener como norte las precisiones y seguridades que en otros ámbitos
tiene la ingeniería. Históricamente han surgido varios enfoques
que buscan abordar de manera sistemática, la planificación, análisis,
diseño e implementación de los proyectos de desarrollo de
software, sean estos de gran escala y pequeñas aplicaciones,
software a la medida o productos de software. Cada uno de estos
enfoques tiene su raíz en las preconcepciones dominantes en su
época y, sobre todo, en la búsqueda incesante de mejoras a los
enfoques precedentes.
Un aspecto central en el análisis, por lo que se desprende del
mismo desarrollo histórico, es la relación del enfoque con el
área problema, ya que es claramente esta relación –en
muchos casos deficiente- la que a nuestro juicio determina la
evolución que aquellos han sufrido. Esta visión está dada,
principalmente, para aquella clase de problemas particulares que
se solucionan mediante una aplicación a la medida, donde hay un
usuario –el experto en el problema- y como contraparte
existe un desarrollador quien es el encargado de modelar el
problema como un software. Independiente que tanto usuario como
desarrollador sean grupos de personas.
Así, para hacer esta revisión el análisis se centrará en los
métodos y se extraerán de ellos las conclusiones que permitan
profundizar una visión sobre las limitaciones que ellos
presentan. Básicamente se expondrá el enfoque de manera
general, como la guía al desarrollo que él pretende ser y no se
profundizará en aspectos técnicos, los cuales serán en su
momento detallados.
El modelo de codificar-y-fijar
El modelo básico usado en los primeros días del desarrollo de
software, tiene dos pasos:
(1) Escribir algún código.
(2) fijar los problemas en el código.
Así, el orden de los pasos era fabricar algún código primero y
pensar sobre los requerimientos, diseño, prueba y mantención a
continuación. Este modelo tiene las dificultades de presentar
una baja estructuración del código luego de alguna cantidad de
fijaciones, pese a que se puede desarrollar un software de
calidad, es posible que éste tenga una correspondencia muy pobre
con las reales necesidades del usuario y, finalmente, si no
existe la conciencia de la necesidad real de pruebas y
modificaciones el costo de las sucesivas fijaciones será muy
alto.
Este método resumen las características de los métodos más
formales desarrollados posteriormente, primero, la desvinculación
con el problema: hay, de partida dos interlocutores, un experto
en la programación o codificación y, por otro lado, un usuario
quien sería el experto en el problema a quien se debe satisfacer
mediante la codificación de la solución, o programa. Lo
anterior nos lleva, también, a la idea de iteración: esta
desvinculación entre el origen del problema y la solución
imprime en los métodos posteriores la idea de
retroalimentaciones que permitan aproximar la distancia entre los
ámbitos. Esta idea de distancia quizá quede más claro en el
siguiente extracto del libro de R.Farley:
En el sentido real, el ingeniero de programación crea modelos de
situaciones físicas en un programa. La
correspondencia entre el modelo y la realidad modelada se ha
considerado como la distancia entre el problema y la solución
computacional del problema. Un principio fundamental de la
ingeniería de programación es diseñar productos que minimicen
la distancia intelectual entre el problema y la solución.
Richard Farley, Ingeniería de Software, p.14.
Y pese a que hay claridad en el problema -minimizar la distancia
intelectual entre el problema y la solución- no existiría aún
un método que permita asegurar aquello, por ejemplo, revisemos
lo que continúa, en el libro de R.Farley:
...empero, la variedad de enfoques en el desarrollo de programas
está limitado únicamente por la creatividad e ingenio del
programador; no siempre se encuentra con claridad el enfoque que
minimice esta distancia, e incluso diferentes enfoques minimizan
distintas dimensiones de la distancia. Richard Farley, Ingeniería
de Software, p.14.
Pero, por otro lado, la primera evolución en relación a los métodos
es el resultado de las deficiencias presentadas por método de
codificar y fijar. Es necesario dividir este ciclo desarrollo en
etapas, lo que permitiría incorporar la idea de proyecto de
desarrollo de software y, sobre todo, elementos de planificación,
coordinación y control. Esto también coincide con el tamaño de
los problemas a resolver, el que se va incrementando debido,
sobre todo, al aumento de las capacidades del hardware.
El modelo de etapas
En 1956, el enfrentarse a un gran sistema de software como el
Semi-Automated Ground Environment (SAGE) hizo que se reconocieran
los problemas inherentes a la codificación y esto llevó al
desarrollo del modelo de etapas, con el objetivo de poder mejorar
estos nuevos problemas. Este modelo estipula que el software será
desarrollado en sucesivas etapas:
Plan operativo. Etapa donde se define el problema a resolver, las
metas del proyecto, las metas de calidad y se identifica
cualquier restricción aplicable al proyecto. Especificación de
requerimientos. Permite entregar una visión de alto nivel sobre
el proyecto, poniendo énfasis en la descripción del problema
desde el punto de vista de los clientes y desarrolladores. También
se considera la posibilidad de una planificación de los recursos
sobre una escala de tiempos. Especificación funcional.
Especifica la información sobre la cual el software a
desarrollar trabajará. Diseño. Permite describir como el
sistema va a satisfacer los requerimientos. Esta etapa a menudo
tiene diferente niveles de detalle. Los niveles más altos de
detalle generalmente describen los componentes o módulos que
formarán el software a ser producido. Los niveles más bajos,
describen, con mucho detalle, cada módulo que contendrá el
sistema. Implementación. Aquí es donde el software a ser
desarrollado se codifica. Dependiendo del tamaño del proyecto,
la programación puede ser distribuida entre distintos
programadores o grupos de programadores. Cada uno se concentrará
en la construcción y prueba de una parte del software, a menudo
un subsistema. Las pruebas, en general, tiene por objetivo
asegurar que todas las funciones están correctamente
implementadas dentro del sistema. Integración. Es la fase donde
todos los subsistema codificados independientemente se juntan.
Cada sección es enlazada con otra y, entonces, probada. Este
proceso se repite hasta que se han agregado todos los módulos y
el sistema se prueba como un todo. Validación y verificación.
Una vez que el sistema ha sido integrado, comienza esta etapa. Es
donde es probado para verificar que el sistema es consistente con
la definición de requerimientos y la especificación funcional.
Por otro lado, la verificación consiste en una serie de
actividades que aseguran que el software implementa correctamente
una funcón específica. Al finalizar esta etapa, el sistema ya
puede ser instalado en ambiente de explotación. Mantención. La
mantención ocurre cuando existe algún problema dentro de un
sistema existente, e involucraría la corrección de errores que
no fueron descubiertos en las fases de prueba, mejoras en la
implementación de las unidades del sistema y cambios para que
responda a los nuevos requerimientos. Las mantenciones se puede
clasificar en: correctiva, adaptativa, perfectiva y preventiva.
El modelo de etapas consideraba que cada una de ellas debería ir
a continuación de la anterior, poniendo énfasis en la
documentación que resulta de cada una y que es la entrada de la
siguiente, formalizando los procedimientos de planificación y de
control. Todo tendiente a conformar una cadena de producción de
software, de manera similar a una cadena de montaje de automóviles
Pero ello no logra que las causas de fondo que hicieron que se
replantease el modelo de codificar y fijar desapareciesen. Todavía
existe la distancia entre el programador (ahora desarrollador) y
el usuario, esta distancia está dada por dominios de acción
distintos, -lo que es válido también para el método de cascada-.
La iteración de aproximación es ahora más factible, pero también
resulta onerosa, es necesario instalar todo el software
nuevamente en la cadena de montaje para su revisión y
reconstrucción.
El modelo de cascada o ciclo de vida clásico
Es un refinamiento altamente influenciado para 1970 del modelo de
etapas. Existe, para este modelo, un reconocimiento de los ciclos
de retroalimentación entre etapas, y una guía para confinar las
retroalimentaciones a las etapas sucesivas con el objetivo de
minimizar el costo del retrabajo involucrado en
retroalimentaciones a través de muchas etapas
Las ventajas que presentan tanto el modelo de etapas y de cascada
tiene relación con la idea de postular un marco de trabajo
claro, que reconoce y define las actividades involucradas en el
desarrollo de software, permitiendo establecer relaciones de
cooperación entre ellas. Corresponden, también, a los métodos
más usados en desarrollo de software y que han sido exitosos
durante décadas tanto en el desarrollo de grandes sistemas como
en el de pequeños.
Tanto el modelo de etapas como el de cascada, presentan algunas
dificultades comunes. Por ejemplo, la especificación de los
problemas. Ambos métodos asumen que el diseñador puede
distinguir entre lo que el sistema debe hacer y como el sistema
lo hará; pero algunos problemas no pueden ser divididos tan fácilmente
para ser atacados desde este prisma.
Por otro lado, generalmente los requerimientos son especificados
al inicio del proyecto y, paradojalmente, cuando se tiene la
claridad suficiente para definir precisamente lo que se quiere es
cuando se está en las últimas etapas del proyecto. Esto es
consecuencia, en general, de que los clientes no están
familiarizados con la tecnología, con lo cual producen
requerimientos muy vagos, que son interpretados arbitrariamente
por los desarrolladores. Otro factor importante es que estos métodos
asumen que una vez que los requerimientos han sido definidos
entonces ellos no cambiarán más. Pero, dependiendo de la
complejidad de el proyecto, la implementación final puede
ocurrir meses o, eventualmente, años después de que los
requerimientos han sido especificados; así, en las últimas
etapas del proyecto, los requerimientos pueden haber cambiado.
Existiría un énfasis en la elaboración de documentos. El
sistema completo es descrito y registrado en papel, cada etapa
produce cierta cantidad de documentos. Esto lleva a que, por
ejemplo, para sistemas complejos las especificaciones de
requerimientos pueden ser de cientos de páginas, explicando
todos u cada uno de los detalles del sistema. Y es difícil poder
visualizar a priori, desde éste volumen de papel, las características
del sistema.
Por último, se ha detectado que el enfoque lineal de estos métodos
no sería el adecuado para reflejar el proceso de desarrollo de
software. Esto explica que se diga que para algunos proyectos el
modelo clásico los lleva a seguir las etapas en orden incorrecto.
Más aún, es posible que todas las etapas del proyecto, estén
comprimidas dentro de cada una.
Como se ha podido observar, la especificación de métodos más
acabados para el desarrollo de software no logra superar el
problema de la distancia entre la visión del usuario y la del
desarrollador, ya que no se ha buscado resolver ese problema,
sino que las soluciones se centraron principalmente en la división
de las tareas con miras al control de las mismas, lo que si bien
soluciona el problema de especificar y luego programar, crea
otros, como el presentado en el párrafo anterior, en que no
todos los problemas podrían ser abordados desde una misma
perspectiva de orden en las etapas.
El desarrollo orientado a prototipos
Si bien algunos autores consideran que esto es parte del ciclo de
vida clásico (Boehm, 1988), es también posible verlo como un método
independiente.
Una definición de un prototipo en software podría ser:
"...es un modelo del comportamiento del sistema que puede
ser usado para entenderlo completamente o ciertos aspectos de él
y así clarificar los requerimientos... Un prototipo es una
representación de un sistema, aunque no es un sistema completo,
posee las caraterísticas del sistema final o parte de ellas"
Las fases que comprende el método de desarrollo orientado a
prototipos serían:
Investigación preliminar. Las metas principales de esta fase son:
determinar el problema y su ámbito, la importancia y sus efectos
potenciales sobre la organización por una parte y, por otro
lado, identificar una idea general de la solución para realizar
un estudio de factibilidad que determine la factibilidad de una
solución software. Definición de los requerimientos del sistema.
El objetivo de esta etapa es registrar todos los requerimientos y
deseos que los usuarios tienen en relación al proyecto bajo
desarrollo. Esta etapa es la más importante de todo el ciclo de
vida, es aquí donde el desarrollador determina los requisitos
mediante la construcción, demostración y retroalimentaciones
del prototipo. Por lo mismo esta etapa será revisada con más
detalle luego de esta descripción. Diseño técnico. Durante la
construcción del prototipo, el desarrollador ha obviado el diseño
detallado. El sistema debe ser entonces rediseñado y documentado
según los estándares de la organización y para ayudar a las
mantenciones futuras. Esta fase de diseño técnico tiene dos
etapas: por un lado, la producción de una documentación de diseño
que especifica y describe la estructura del software, el control
de flujo, las interfaces de usuario y las funciones y, como
segunda etapa, la producción de todo lo requerido para promover
cualquier mantención futura del software. Programación y prueba.
Es donde los cambios identificados en el diseño técnico son
implementados y probados para asegurar la corrección y
completitud de los mismos con respecto a los requerimientos.
Operación y mantención. La instalación del sistema en ambiente
de explotación, en este caso, resulta de menor complejidad, ya
que se supone que los usuarios han trabajado con el sistema al
hacer las pruebas de prototipos. Además, la mantención también
debería ser una fase menos importante, ya que se supone que el
refinamiento del prototipo permitiría una mejor claridad en los
requerimientos, por lo cual las mantenciones perfectivas se
reducirían. Si eventualmente se requiriese una mantención
entonces el proceso de prototipado es repetido y se definirá un
nuevo conjunto de requerimientos.
La fase más importante corresponde a la definición de
requerimientos, la cual correspondería a un proceso que busca
aproximar las visiones del usuario y del desarrollador mediante
sucesivas iteraciones. La definición de requerimientos consiste
de cinco etapas entre dos de las cuales se establece un ciclo
iterativo:
Analisis grueso y especificación. El propósito de esta subfase
es desarrollar un diseño básico para el prototipo inicial. Diseño
y construcción. El objetivo de esta subfase es obtener un
prototipo inicial. El desarrollador debe concentrarse en
construir un sistema con la máxima funcionalidad, poniendo énfasis
en la interface del usuario. Evaluación. Esta etapa tiene dos
propósitos: extraer a los usuarios la especificación de los
requerimientos adicionales del sistema y verificar que el
prototipo desarrollado lo haya sido en concordancia con la
definición de requerimientos del sistema. Si los usuarios
identifican fallas en el prototipo, entonces el desarrollador
simplemente corrige el prototipo antes de la siguiente evaluación.
El prototipo es repetidamente modificado y evaluado hasta que
todos los requerimientos del sistema han sido satisfechos. El
proceso de evaluación puede ser dividido en cuatro pasos
separados: preparación, demostración, uso del prototipo y
discusión de comentarios. En esta fase se decide si el prototipo
es aceptado o modificado. Modificación. Esto ocurre cuando la
definición de requerimientos del sistema es alterada en la sub-fase
de evaluación. El desarrollador entonces debe modificar el
prototipo de acuerdo a los comentarios hechos por los usuarios. Término.
Una vez que se ha desarrollado un prototipo estable y completo,
es necesario ponerse de acuerdo en relación a aspectos de
calidad y de representación de el sistema.
En la siguiente figura se puede ver un esquema en que estas
etapas se realizan, note que la especificación de requerimientos
está claramente diferenciada de las demás. Es en ella donde se
utiliza el prototipado, ya que permite entregar al usuario lo que
sería una visión la solución final en etapas tempranas del
desarrollo, reduciendo tempranamente los costos de
especificaciones erróneas.
Las ventajas de un enfoque de desarrollo orientado a prototipos
están dadas por: reducción de la incertidumbre y del riesgo,
reducción de tiempo y de costos, incrementos en la aceptación
del nuevo sistema, mejoras en la administración de proyectos,
mejoras en la comunicación entre desarrolladores y clientes, etc.
Si bien, el desarrollo orientado a prototipos tiene considerables
ventajas, también presenta desventajas como: la dependencia de
las herramientas de software para el éxito ya que la necesidad
de disminución de incertidumbre depende de las iteraciones del
prototipo, entre más iteraciones existan mejor y esto último se
logra mediante el uso de mejores herramientas lo que hace a este
proceso dependiente de las mismas. También, no es posible
aplicar la metodología a todos los proyectos de software y,
finalmente, la mala interpretación que pueden hacer los usuarios
del prototipo, al cual pueden confundir con el sistema terminado.
No se puede desconocer que la fase de definición de
requerimientos se ha perfeccionado en dos aspectos importantes:
primero se ha aproximado los visiones del usuario y el
desarrollador, lo cual representa el beneficio de establecer una
base común de comunicación; también, el hacer explícita la
posibilidad de iterar sobre estos dominios permitiría que la
convergencia de los mismos sea una posibilidad cierta.
Pero lo anterior no asegura el éxito, por ejemplo, qué certeza
existe en que esta iteración sea en la dirección correcta y
lleve a la convergencia de los dominios; no se puede desconocer
las diferencias que existen entre la prueba de un prototipo de
software en la fase de definición de requerimientos y el uso del
mismo ya como un producto terminado. Para explicar esto, podemos
hablar de dos dominios en el usuario, uno que es el que se
establece cuando se prueba el prototipo y otro, distinto por
cierto, el que ocurre cuando el usuario hace uso del software en
ambiente de explotación.
Por último, el proceso de iteración para que sea efectivo debería
ser infinito, lo que lo hace poco efectivo. Es decir, mediante
este método acercamos la problemática de los usuarios a los
dominios de los desarrolladores y vice versa, pero no sería
posible lograr un pareamiento uno a uno entre estos dominios, lo
que sería el ideal.
El modelo de desarrollo evolutivo
El desarrollo evolutivo es una metodología de desarrollo de
software muy relacionada con, pero claramente distinta de,
desarrollo por prototipos. El énfasis esta puesto sobre la
importancia de obtener un sistema de producción flexible y
expandible. Así, si los requerimientos cambian durante el
desarrollo del sistema, entonces con un mínimo de esfuerzo y
tiempo se puede desarrollar un sistema de trabajo flexible.
La diferencia fundamental entre desarrollo evolutivo y prototipos
de software es que el desarrollo evolutivo busca reemplazar el
viejo sistema con uno nuevo que tendría la propiedad de
satisfacer los nuevos requerimientos lo más rápido posible. En
contraste, prototipos usa un enfoque iterativo solo para
determinar los requerimientos organizacionales. Por lo tanto el
tiempo tomado entre cada iteración es mucho más importante para
el desarrollo evolutivo. En la siguiente figura se puede ver gráficamente
esta diferencia.
El desarrollo evolutivo asume que los requerimientos de un
proyecto están sujetos a cambios continuos, por lo cual es
necesario definir una estrategia de desarrollo que refleje esta
situación. En cambio, el desarrollo orientado a prototipos, así
como los anteriores, asume que los requerimientos "reales"
existen y se vale de las iteraciones del prototipo para
establecerlos y modelarlos.
La idea entonces de la metodología de desarrollo evolutivo es
estar liberando constantemente una nueva versión del sistema que
sea completamente funcional; así, cada sistema producto de las
iteraciones sucesivas del método tendría incorporado los nuevos
requerimientos que ha sido posible identificar y que no estarían
considerados en la anterior versión.
Así, las etapas del desarrollo evolutivo tienen por objetivo
extender los incrementos de un producto de software operacional,
en las direcciones determinadas por la evolución de la
experiencia operacional.
El modelo de desarrollo evolutivo puede ser idealmente asociado a
un lenguaje de aplicación de cuarta generación y mejor aún a
situaciones en que el usuario dice, "yo no puedo hablarte
sobre lo que yo quiero, pero yo lo reconocería si lo viese".
Así, este método entregaría al usuario rápidamente una
capacidad operativa inicial y, además, establecería una base
real operación para determinar las mejoras subsecuentes en el
producto.
Pero, existirían algunas dificultades técnicas que no pueden
dejar de ser mencionadas, por ejemplo:
- No facilita la integración de aplicacionees que han sido
desarrolladas como sistemas independientes.
- Facilita la posibilidad de que existan caasos de "esclerosis
de información", en el sentido que trabajos temporales
alrededor de algunas deficiencias del software se solidifican
como poderes inmodificables a la evolución. Es decir, en la
medida que se evoluciona, esta misma facilidad a la evolución
llevaría a que no sea posible seguir evolucionando.
- Pueden ocurrir que el software nuevo es uun reemplazo
incremental de un subsistema dentro de un gran sistema existente.
Si el sistema existente está pobremente modularizado, entonces
es obvia la dificultad en hacer que la nueva versión se acople
con facilidad al resto.
El método evolutivo tiene la gran ventaja de reconocer la
existencia de una constante de cambios en los requerimientos y,
desde esta premisa, propone una solución, la cual es válida
para la solución de ese problema pero que no resolvería la
inquietud original, esto es que el método no facilita elementos
que permitan reducir la distancia conceptual entre los dominios
del desarrollador y del usuario.
Con la existencia del método evolutivo se configura una nueva
problemática en el desarrollo de sistemas, es decir, la crisis
se expande ahora en el sentido que no sólo se requiere reflejar
lo más fielmente posible las necesidades del usuario, sino que
ahora los ambientes en que el sistema está inserto están
sujetos a cambios y estos cambios inciden en la efectividad del
software desarrollado. Lo anterior fue articulado por Meir M.
Lehman a principio de la década de los ochenta, al definir las
leyes de la evolución del software, en que las dos primeras
leyes tienen directa relación con lo que se describe. Veamos a
Lehman citado por Ian Sommerville, en el libro Ingeniería de
Software:
Lehman propone que la evolución de un sistema de software esta
sujeta a varias leyes. Ha determinado estas leyes a partir de
observaciones experimentales de varios sistemas, como los grandes
sistemas operativos (...). Dice Lehman que hay cinco leyes de la
evolución de los programas: 1. Cambio Continuo. Un programa que
se utiliza en un ambiente del mundo real debe cambiar o será
cada vez menos útil en ese ambiente. 2. Complejidad creciente. A
medida que un programa en evolución cambia, su estructura se
hace más compleja, a menos que se lleven a cabo esfuerzos
activos para evitar este fenómeno. 3. Evolución del programa.
La evolución del programa es un proceso autorregulador, y una
medición de atributos del sistema, como el tamaño, el tiempo
entre versiones, el número de errores advertidos, etc., revela
las tendencias estadísticas significativas y las características
invariantes. 4. Conservación de la estabilidad organizativa.
Durante el tiempo de vida de un programa, su rapidez de
desarrollo es casi constante e independiente de los recursos
dedicados al desarrollo del sistema. 5. Conservación de la
familiaridad. Durante el tiempo de vida de un sistema, la evolución
del cambio del sistema en cada versión es, aproximadamente,
constante. Ian Sommerville, Ingeniería de Software, p.6.
Sommerville considera las "leyes" de Lehman como
elementos positivos en la configuración del ámbito en que se
desarrollan los sistemas, por ejemplo, dice que las dos primeras
hipótesis de Lehman son casi con certeza válidas. Interpretando
la primera como: ...El razonamiento subyacente en la primera ley...
es que cuando un sistema de software (sobre todo uno grande) se
construye para modelar algún ambiente y después se introduce en
él, modificándose así el ambiente original con la presencia
del sistema de software... No puede ser más interesante para los
propósitos de esta revisión la característica planteada por
esta hipótesis, es decir, si se desarrolla software no se podría
pensar desde la perspectiva de estabilidades, todo lo contrario,
necesariamente es el cambio el motor y el configurador de los
sistemas de software. Aquí el punto es la introducción de una
nueva perspectiva al problema del desarrollo de software,
perspectiva que será determinante en el planteamiento de un
modelo que permita reflejarla.
Lo expresado en la primera ley, configura un nuevo problema -como
se habia anticipado- para el desarrollo de software, además de
la distancia conceptual entre desarrollador y usuario, existiría
el problema de la evolución constante de la organizaciones o, más
claramente, la connaturalidad de las organizaciones al cambio
como elemento subyacente en su ser organizacional. Situación que
se había anticipado en el curso de "Ambientes..."
La segunda ley en el análisis de Somerville corresponde al hecho
de que la estructura del programa original se estableció para
aplicarlo a un conjunto de necesidades iniciales. A medida que se
produce el cambio evolutivo de esas necesidades, la estructura
original se degrada y con ello se va haciendo más compleja ya
que al ir incrementándose la distancia conceptual entre el
software y el medio que lo contiene, éste va estando cada vez más
presente en el hacer cotidiano, formulando quiebres constantes
sobre el sistema de trabajo lo que imprime un sello de
complejidad a la utilización del software.
Las siguientes leyes tienen relación con las características de
las organizaciones y de los individuos que participan en el
proceso de desarrollo de software. Lehman afirma que las
organizaciones se esfuerzan por lograr la estabilidad e intentan
evitar cambios drásticos o repentinos. Por tanto, a medida que
se añaden más recursos a un proyecto de software, el efecto
evolutivo de la adición de nuevos recursos se va reduciendo,
hasta que la adición de nuevos recursos no produce ningún
efecto. Si bien, estas últimas leyes no resultan tan obvias como
las primeras y podrían ser cuestionadas, es posible que la última,
que tiene que ver con la conservación de la familiaridad sea la
más útil, como también la de reducción de personal, en el
sentido que cuanta más gente trabaje, menos productivo será
cada miembro del proyecto.
Las proposiciones de Lehman se orientaron a la creación de un método
de desarrollo que considerase estas características.
El modelo de transformación
Desde la perspectiva de la evolución del software y las leyes de
Lehman, se hace una revisión del ciclo de vida del software, el
cual lleva al desarrollo de un método que se podría denominar
el modelo de transformación.
Desde la óptica de Ian Sommerville, este modelo se caracteriza
por que... un concepto de aplicación se transforma de modo
paulatino en una especificación formal de software. Esto implica
la reducción de la cantidad de información bruta en cada etapa
de la transformación, proceso que el denomina abstracción. Una
vez establecida la especificación, se añade la información (a
esto le llama materialización) y el sistema abstracto se
transforma, mediante un conjunto de notaciones formales, en un
programa operacional.
Las bases de una concepción de transformación en el desarrollo
de software, las explica el mismo Lehman (1980). Al considerar
una clasificación de los programas y, mediante ésta, definir un
método sistemático que permita transformar programas de una
clase más compleja en otra de complejidad menor.
La clasificación ...está basada en el reconocimiento de el
hecho que,..., cualquier programa es un modelo de un modelo
dentro de una teoría de un modelo de una abstracción de alguna
porción del mundo o de algún universo del discurso. La
clasificación categoriza a los programas en tres clases, S, P y
E.... ... Programas-S. Los Programa-S son aquellos cuya función
puede ser definida formalmente por y derivable desde, una
especificación.... Las sentencias del problema, el programa y la
solución, cuando es obtenida, puede relacionarse con un mundo
externo. Pero esto es una relación casual y no causal. En
efecto, cuando esto existe somos libres para cambiar nuestro
interés y redefinir el problema. Pero el resultado de esto es un
nuevo programa para esta solución. Puede ser posible y eficiente
derivar el nuevo programa desde el antiguo. Pero es un programa
diferente que define una solución para un problema diferente.
... Programas-P. ...en los Programas-P (solución de problemas
del mundo real)... a despecho de el hecho de que el problema a
ser resuelto pueda ser definido precisamente, la aceptación de
la solución está determinada por el medio ambiente en que está
involucrada. La solución obtenida será evaluada por comparación
con el medio ambiente real... En los Programas-S, el juicio sobre
la corrección, y por lo tanto el valor, del programa está
relacionado con la definición solamente de esta especificación,
las sentencias del problema que debe ser reflejado. En los
Programas-P, el asunto no está centrado en el problema pero si
sobre el valor y la validez de la solución obtenida, esto es
sobre el contexto del mundo-real. ... Programas-E. La tercera
clase, los Programas-E, están inherentemente más inclinados al
cambio. Estos son programas que mecanizan una actividad humana o
social... La instalación de los programas junto con este sistema
asociado -...- cambia la real naturaleza del problema a ser
resuelto, el programa puede hasta convertirse en parte del mundo
que el mismo modela, está embebido en él...No como otros
sistemas artificiales donde,..., el cambio es ocasional, aquí
este aparece continuamente. La presión del cambio está
construida con él.... Los Programas P y E están estrechamente
relacionados, podemos establecer la clase unión de P y E como
Programas-A. Éstos difieren de los Programas-S en el sentido que
representan una aplicación computacional en el mundo real. ....
Los programas-S son siempre probablemente correctos... muchos de
los componentes más importantes de un gran programa son del tipo
S... un Programa-A puede siempre ser particionado y estructurado
de manera que todos sus elementos sean Programas-S. Meir Lehmann,
Program, Life Cycles, and..., ACM Proceeding, 1980, p.
En esta última afirmación esta el trasfondo de la idea de
Lehman en relación a la posibilidad de definir un metalenguaje
que permita reducir programas complejos o "del mundo real"
a especificaciones formales de programas. Así, según Boehm:
...el modelo de transformación asume la existencia de una
capacidad de automáticamente convertir una especificación
formal de un producto de software en un programa que satisfaga la
especificación. Los pasos que son prescritos por el modelo de
transformación son: -una especificación formal de la mejor
comprensión inicial del producto deseado. -transformación automática
de la especificación en código. -un ciclo iterativo, si es
necesario, para mejorar la ejecución de el código resultante
para dar una guía de optimización al sistema de transformación.
-probar el producto resultante, y -un cicloo interactivo externo
para ajustar las especificaciones basadas en el resultado de la
experiencia operacional, y para rederivar, reoptimizar, y probar
el producto de software ajustado. Barry Boehm, A Spiral Model of
Software..., ACM Proceeding, 1988, p.
El modelo de transformación evita las dificultades de tener que
modificar un código que tiene una estructuración muy pobre -debido
a las repetidas optimizaciones-, mediante la posibilidad de que
las modificaciones sean fabricadas a través de las
especificaciones, esto sin intervenir el código, el cual se
reconstruiría cada vez.
Con este modelo se puede aumentar, al menos teóricamente, la
capacidad de dar respuesta rápida a la evolución que
connaturalmente estaría asociada a las organizaciones, pero, al
igual que el modelo espiral -que veremos a continuación-, se ha
alejado del problema central que se ha discutido hasta ahora, que
es cómo acortar la brecha conceptual entre los dominios del
desarrollador y del usuario, si es que es posible.
En relación a este último y central problema, la crítica que
se puede hacer al modelo de transformación es que necesariamente
al transformar un problema del tipo A en problemas-S, se está
aplicando un reduccionismo que, probablemente, limite la expresión
de toda la complejidad del problema original, particularizando la
solución a casos en que sea dable resolver sistemáticamente y
dejando fuera situaciones en que esta formalización no sea
posible. En ese sentido, no sería factible que todos los
problemas-A sean transformables a unidades S. Además, esto no
evita la necesidad de tener que caracterizar un problema del tipo
A, lo que remitiría necesariamente a la cuestión original.
Modelo Espiral
El modelo Espiral de Boehm para Ingeniería de Software agrupa
las mejores características del modelo del ciclo de vida clásico
y de prototipos. Pero también agrega nuevas funciones que no están
incluidas en los otros modelos, como el análisis de riesgo. El
modelo espiral define cuatro actividades principales para el
ciclo de vida.
Planificación - La determinación de los objetivos del proyecto,
alternativas y restricciones. Análisis de Riesgo - El análisis
de alternativas y la identificación y solución de riesgos.
Ingeniería - Desarrollo del producto. Evaluación del cliente -
El asentimiento de los resultados de la ingeniería.
El modelo es representado por una espiral dividida en cuatro
cuadrantes, en que cada uno describe las actividades mencionadas
anteriormente. El modelo espiral utiliza un esquema de desarrollo
iterativo donde la primera iteración comienza en el centro del círculo
e, incrementalmente, se va desplazando hacia afuera. Las
siguientes iteraciones sucesivas son versiones más completas del
software que está siendo construido. Al principio de cada
iteración del ciclo de vida se hace un análisis de riesgo,
mientras, por el otro extremo, la revisión del proyecto se
realiza al final de la iteración. Así, se puede contrarrestar
cualquier riesgo observado mediante las acciones adecuadas en el
tiempo preciso.
El modelo espiral es visto como un enfoque más realista para el
desarrollo de grandes sistemas de software. Usa un método
evolucionario para desarrollo y prototipos como una técnica de
reducción de riesgo (pese a que los prototipos pueden ser usados
en cualquier etapa dentro del ciclo de vida). También utiliza el
enfoque de sistematización y el 'desarrollo en etapas' del ciclo
de vida clásico, pero, con la diferencia que todos están
incorporados dentro del esquema iterativo planteado por el modelo
espiral.
Método de Sistemas "Soft"
Checkland desarrolla la metodología de sistemas "soft"
en respuesta a las fallas de los enfoques más convencionales
para abordar problemas "espinudos", problemas que son
complicados de definir, conocidos como problemas "soft".
Los problemas "soft" son encontrados frecuentemente en
organizaciones y no pueden ser resueltos por las mismas técnicas
usadas en resolver problemas más formales.
Las metodologías tradicionales para análisis de sistemas asumen
que el problema (como ellos lo definen) tiene una solución
definitiva y un numero de metas que pueden ser satisfechas. Es
decir es factible en estas situaciones hacerse la pregunta: ¿Cómo
se resuelve el problema?.
La metodología de sistemas "soft" considera el término
"el problema" como inapropiado, considera que es una
visión errada de la situación. Los sistemas "soft"
reconocen que no existe un problema, pero si muchos problemas, lo
que se describe como una "situación problema". El énfasis
es puesto más sobre la caracterización del problema que sobre
como se resuelve, en este caso es válida la pregunta: ¿cuál es
el problema?. Así, las metas del sistema "soft" son
mucho más complejas que las metas de los sistemas tradicionales
que pueden ser alcanzadas y medidas.
El proceso involucrado en la metodología de sistemas "soft"
es el siguiente:
1. El analista (en adelante el solucionador del problema), con la
ayuda de los administradores y usuarios dentro de la organización
(en adelante el dueño del problema), crean un cuadro de la
situación problema. El cuadro es una percepción subjetiva del
problema en un esquema informal. Incluirá sistemas de la
organización bajo revisión, la gente dentro de ello, las tareas
ejecutadas, etc. Este cuadro es usado como ayuda a las
discusiones con el o los dueños del problema. 2. Los temas
problemas son extraidos desde el cuadro por el solucionador. El
agregará, desde su óptica propia, los conflictos entre el
personal o funciones dentro de la organización, problemas de
comunicación u otro tipo de problemas que detecte. Este cuadro
es utilizado para identificar problemas e informa al dueño de la
situación, antes que se desarrollen posibles soluciones. El uso
de este cuadro es mucho mejor que los métodos tradicionales para
estimular a administradores y usuarios para revelar los problemas
"reales" dentro de la organización. 3. Una vez
completado el cuadro, el solucionador lo usará para crear una
definición raíz. Checkland (1981) define la definición raíz
como:
"... una descripción concisa y ajustada de un sistema de
actividad humana que presenta qué es el sistema."
La definición raíz es creada usando una lista de chequeo
llamada el criterio CATWOE (Clients, Actors, Transformations,
WorldView, Owner, Environment). Que por orden de importancia
debería ser TWECOA. Ellos determinan quién está haciendo qué
para quienes, y a quienes ellos están preguntando. Qué
supuestos están siendo usados y en qué medio ambiente está
sucediendo todo aquello. Una descripción general de cada uno de
estos elementos puede ser la siguiente:
Cliente Todos aquellos beneficiados o afectados por las salidas
del sistema.
Actor El agente de cambio que llevará afuera el proceso de
transformación.
Transformación Los cambios que tienen lugar dentro o por causa
del sistema.
Visión de Mundo Cómo el sistema es percibido desde un punto de
vista particular. Son las presunciones que tienen los miembros
de, dueños o clientes de la organización.
Dueño Es a quien el sistema le pregunta y/o quién puede causar
que deje de existir.
Medio Ambiente El mundo que envuelve e influencia al sistema,
pero que no tiene control sobre él.
Si existen muchas versiones diferentes del cuadro, entonces serán
creadas tantas definiciones raíz como versiones existan.
4. Cuando los dueños y los solucionadores del problema estén
satisfechos en que las definiciones raíz están bien formadas,
se crea un modelo conceptual. Este describe en forma gráfica que
es lo que el sistema hará. El modelo conceptual tomará en
cuenta todas las definiciones raíz consideradas.
5. El modelo conceptual es usado como la base de todos los
cambios hechos por el sistema para eliminar los problemas.
Como esta metodología no considera cualquier procedimiento
preconcebido, el análisis es mucho mejor y permite un mejor
entendimiento del problema.