tiempo total
M ANTENIMIENTO DE A PLICACIONES
II. D.3.10 M ÉTODOS FORMALES ( INDEPENDIENTES DEL JUICIO EXPERTO )
NOGUEIRA
Nogueira (2000) propone 4 modelos aplicables bajo distintas circunstancias.
Los modelos 1 a 3 pueden ser usados cuando CX≥ 600 LGC y RV≤67%, el modelo 4 puede ser usado en general.
Modelo1: Aplicable cuando la volatilidad de los requisitos es baja
//Algoritmo Modelo1 //Entradas: EF, LGC, t
// t es dado en días, se suponen 22 días laborables al mes //Salida p=P(x t) { if (EF > 2,0) { a=1,95; b=22 * 0,28 * (14 * ln(LGC) - 89); } else { a=2,5; b=22 * 0,76 * (14 * ln(LGC) - 89); }; c=b/5,5; }; -(t-b) c
p=1 - e
;
a ⎛ ⎞ ⎜ ⎟ ⎝ ⎠MODELOS AUTOMATIZABLES DE ESTIMACIÓN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIÓN
II—57
Modelo 2: Este modelo considera los tres factores (EF, RV y CX), pero no toma en cuenta el efecto combinado de EF y RV.
//Algoritmo modelo 2 //Entradas: EF, RV, LGC, t
// t es dado en días, se suponen 22 días laborables al mes //Salida p=P(x t) { if (EF > 2,0) { a=1,95; b=22 * 0,28 * (14 * ln(LGC) - 89); } else { a=2,5; b=22 * 0,76 * (14 * ln(LGC) - 89); }; if (RV > 30) { c=b/5,25; } else { c=b/5,9; }; };
Modelo 3: Este modelo considera los tres factores y el efecto combinado de EF y RV
//Algoritmo modelo 3 //Entradas: EF, RV, LGC, t
// t es dado en días, se suponen 22 días laborables al mes //Salida p=P(x<= t) { if (EF > 2,0) { a=1,95; b=22 * 0,32 * (14 * ln(LGC) - 89); c=b/(5,71 + (RV - 20) * 0,046); } else { a=2,5; b=22 * 0,85 * (14 * ln(LGC) - 89); c=b/(5,47 - (RV - 20) * 0,114); }; }; -(t-b) c p=1 - e ; a ⎛ ⎞ ⎜ ⎟ ⎝ ⎠ -(t-b) c p=1 - e ; a ⎛ ⎞ ⎜ ⎟ ⎝ ⎠
MODELOS AUTOMATIZABLES DE ESTIMACIÓN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIÓN
II—58
Modelo 4: Este modelo puede ser usado para cualquier valor de complejidad y vola- tilidad de los requisitos, considera los tres factores y su efecto combinado. Se basa en las siguientes suposiciones:
(a) un proyecto con LGC=0 va a tomar 0 días. (b) a, b y c > 0
(c) si aumenta RV entonces disminuye p(x<=t). (d) si aumenta CX entonces disminuye p(x<=t). (e) si aumenta EF entonces aumenta p(x<=t).
II.D.4 CONCLUSIONES SOBRE ESTIMACIÓN
Son necesarios métodos que permitan estimar tempranamente con una precisión aceptable.
Existen en el proceso de desarrollo numerosas fuentes de variabilidad que los mode- los de uso más extendido en la industria han tratado de reflejar mediante la introducción de parámetros. De esta forma, la mayor fuente de variabilidad en la estimación se encuentra en la evaluación de estos parámetros mediante juicio experto.
Se debe prescindir del juicio experto, disminuir la variabilidad tanto del proceso de estimación como del de desarrollo, identificar indicadores de complejidad objetivos pre- sentes en etapas muy tempranas del ciclo de vida y desarrollar modelos basados en ellos.
Los modelos de Nogueira no requieren de juicio experto y son aplicables a sistemas de tiempo real desarrollados mediante herramientas de generación de código a partir de especificaciones formales.
Esta tesis extiende este resultado al dominio de sistemas de información desarrolla- dos mediante herramientas de generación de código a partir de especificaciones formales.
// A lg o r itm o M o d e lo 4 // E n tr a d a s E F , R V , L G C , t // S a lid a p = P ( x t) { if ( E F > 2 .0 ) { a = 1 .9 5 ; 4 .5 L G C b = 2 2 * ln 1 + ; 2 8 .5 e ( 1 0 .0 0 4 5 R V ) c ≤ ⎛ ⎞ ⎜ ⎟ ⎜ + ⎟ ⎝ ⎠ b = ; 5 .7 1 } e ls e { a = 2 .5 ; 1 2 L G C b = 2 2 * ln 1 + ; 7 6 e ( 1 0 .0 0 4 5 R V ) b c = ; 5 .7 1 } ; -( t-b ) c p = 1 - e ; } ; a ⎛ ⎞ ⎜ ⎟ ⎜ + ⎟ ⎝ ⎠ ⎛ ⎞ ⎜ ⎟ ⎝ ⎠
MODELOS AUTOMATIZABLES DE ESTIMACIÓN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIÓN
II—59
II.E MODELOS MATEMÁTICOS DE LOS DATOS:DOS APORTES PIONEROS
GERMINALES
En los 70, se produjeron dos aportes que lo cambiarían todo.
II.E.1 EL MODELO RELACIONAL (CODD,1970)
Buscando la simplificación, usabilidad y poder poner el acceso a los datos en manos del usuario final, Codd, se adelanta a su tiempo y, por primera vez, se pregunta si la reali- dad sería realmente tan complicada o eran los observadores quienes apelaban a maneras intrincadas de representarla.
El resultado de esta investigación es el modelo relacional [COD70] que marcaría un hito en el modelado de los datos.
Es una representación simple de los datos basada en tablas con columnas formadas por elementos uniformes y atómicos, que incluye criterios para controlar y/o eliminar la
redundancia (normalización) y reglas y operadores para manipular automáticamente los
datos. Por primera vez existía un modelo matemático para representar y manipular datos (álgebra relacional y cálculo relacional).
Todo estaba comenzando, sin embargo todavía debería andarse mucho camino. Inicialmente este modelo fue recibido, en algunos casos, con indiferencia conside- rando que se trataba de una sofisticación académica sin valor práctico y por el otro con es- nobismo y absoluta prescindencia de consideraciones sobre la eficiencia. A pesar de ello la potencia de apoyarse sobre un modelo matemático daría sus frutos y hoy los optimizadores de consultas lo hacen muy bien y cada vez mejor [GON03].
El avance fue realmente trascendente, pero no colmó las expectativas de Codd. El SQL resultó de muy bajo nivel. En efecto, típicamente una consulta debe indicar de que tablas debe obtenerse la información esto tiene dos consecuencias indeseables: (1) un usua- rio que desee formular una consulta debe conocer el esquema y en que tablas debe buscar los datos; la mayoría de los usuarios no son tan sofisticados y (2) cuando cambia el esque- ma cambian las consultas ya que refieren a las tablas [GON03].
II.E.2 EL DISEÑO DE SISTEMAS BASADO EN LA ESTRUCTURA DE LOS DATOS
(WARNIER,1973)
Son métodos que se basan en un modelo matemático de la estructura de datos y deri- van el diseño de los programas a partir de la estructura de los datos y un conjunto de pro-
cedimientos de transformación basados en la estructura de los datos que pueden ser auto-
matizados.
Cada método define reglas propias para pasar de la estructura de los datos a la estruc- tura del software, pero en general todos ellos (1) evalúan los datos; (2) representan los da- tos por medio de formas elementales como secuencia, selección, repetición y jerarquía; (3) transforman la representación de la estructura de datos en una jerarquía de control para el software; (4) refinan la jerarquía del software y (5) desarrollan la descripción procedimen- tal del software [TOR].
Entre estos métodos se encuentran la Construcción Lógica de Programas (CLP) de Warnier [WAR73, WAR74a, WAR74b, WAR75, WAR76, WAR81], luego refinada por Ken Orr en el Desarrollo de Sistemas Estructurado en Datos (DSED o DSSD) o metodolo- gía de Warnier-Orr [ORR77, ORR82], la Programación Estructurada de Jackson [JAC75], y el Desarrollo de Sistemas de Jackson [JAC83].
MODELOS AUTOMATIZABLES DE ESTIMACIÓN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIÓN
II—60
Lamentablemente, estos modelos no recibieron, inicialmente, la atención que mere- cían. La comunidad eligió mayoritariamente trabajar con enfoques orientados a los proce- sos [GON03].
II.E.3 DIAGRAMAS DE WARNIER-ORR
Son diagramas jerárquicos que se utilizan tanto para representar la estructura de los datos como la de los procedimientos.
Se construyen basándose en seis estructuras básicas: jerarquía, secuencia, repetición, selección, concurrencia y recursión.
La jerarquía consiste de un grupo anidado de conjuntos que se representan mediante llaves anidadas, representando los niveles de la jerarquía.
La secuencia es la estructura más simple. Dentro de un nivel en una jerarquía, los elementos son presentados en el orden en que ocurren.
La repetición significa que el mismo conjunto se repite varias veces. La notación que se utiliza es un par ordenado de números entre paréntesis debajo del grupo repetitivo.
La selección representa un o exclusivo entre los conjuntos. Se representa mediante (+).
La concurrencia se usa cuando el orden no es importante y ocurren ambos conjuntos. Se representa con +.
Finalmente, la recursión es usada cuando un conjunto contiene una versión de sí
mismo y se anota con una doble llave.
II.E.4 METODOLOGÍA DE WARNIER-ORR (DSED)
Esta metodología se describe en detalle en [ORR82]. Aquí presentaremos en forma esquemática los aspectos relacionados con el diseño lógico que consiste en obtener la es- tructura lógica de la salida (ELS) y la estructura lógica del proceso (ELP).
Para obtener la ELS se desarrolla su representación mediante diagramas de Warnier. Para obtener la ELP (1) se retiran todos los átomos del diagrama de Warnier de la ELS; (2) se agregan COMIENZO y FIN a todas las repeticiones; (3) se definen todas las instrucciones o procesos de inicio y terminación asociados a cada uno de ellos; (4) se espe- cifican los procesamientos; (5) se especifican los procesos de salida y (6) se especifican los procesos de entrada.
II.E.5 ELABORACIÓN DEL MODELO DE DATOS
Una alternativa es reconocer que no es posible construir un modelo de datos estable
de la empresa y adoptar un enfoque incremental [GON95, GON03, GON03a]. De hecho, esta situación explica que en muy pocas organizaciones se disponga de sistemas realmente integrados que proporcionen información de apoyo a la toma de decisiones sobre la orga- nización como un todo. En general lo que se observa son aplicativos verticales que cubren áreas de la gestión de la empresa con dificultades en las interfaces entre ellos [GON95, GON03, GON03a, LAT03].
En toda organización existe gran variedad de usuarios, desde el Directorio hasta el empleado en el menor escalón jerárquico. Todos conocen muy bien los datos que manejan. Sin embargo nadie tiene una visión global e integradora de los datos de la empresa.
Entonces, un buen punto de partida para la determinación del modelo de datos son las visiones de datos de los usuarios, sobre las cuales ellos no tienen dudas.
MODELOS AUTOMATIZABLES DE ESTIMACIÓN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIÓN
II—61
Estas visiones de datos de los usuarios se expresan de diferentes formas (pantallas, formularios, listados, etc.) y conforman la interfaz del sistema con el medio ambiente.
Si conociéramos la base de datos, estas visiones deberían poder derivarse de ella. Esto sugiere que, a partir de estas visiones de los usuarios, mediante ingeniería inversa, podría inferirse el modelo de datos.
Puede demostrarse que, dado un conjunto de visiones de datos de usuario, existe siempre una base de datos mínima que las satisface, la cual, además, es única. En este estado, el problema se ha transformado en un problema matemático y, enton- ces, es preciso resolverlo, para hallar esa base de datos. (Gonda y Jodal, 2003a)
Los aportes fundacionales de Codd y Warnier constituyen este modelo matemático. El problema a resolver es la captura, integración y consolidación del conocimiento que contienen las visiones de datos de los usuarios, formando un repositorio.
Este repositorio, debe permitir recuperar tanto los conocimientos depositados en él, como aquellos que puedan inferirse a partir de su contenido. Se trata de más que un diccio- nario de datos; una base de conocimiento.
Alcanzada esta meta, la base de datos y los programas de aplicación pueden ser gene- rados automáticamente a partir de esta base de conocimiento y, además, será posible apo- yar la gestión de los cambios en las visiones de los usuarios (1) determinando su impacto sobre datos y procesos, (2) propagando automáticamente estos cambios y (3) generando los programas de conversión de datos y los programas impactados por ellos.
Las fases de diseño e implementación de la metodología de Warnier-Orr fueron au-
tomatizadas por una herramienta desarrollada por Artech (www.artech.com.uy; Ken Orr,
www.kenorrinst.com).
Una herramienta de estas características, viabiliza un desarrollo incremental y el des- cubrimiento del modelo de datos a partir de las visiones de datos de los usuarios.
De fundamental importancia para nuestra investigación: si la herramienta publica la especificación las métricas se podrán obtener automáticamente.
II.F PROCESOS DE DESARROLLO
II.F.1 PROCESOS DE DESARROLLO ÁGILES VS. CONDUCIDOS POR LA
PLANIFICACIÓN Y DOCUMENTACIÓN INTENSIVAS
Un modelo de proceso de desarrollo de software define el orden en que se cumplen las etapas y el criterio aplicado para pasar de una a otra (criterio de completitud de la actual y entrada a la siguiente) [BOE88a].
En las épocas iniciales, el software se desarrollaba ad-hoc por equipos reducidos
formados por unos pocos pioneros con una metodología de codificar y reparar errores
(code and fix). Esto sólo fue aplicable a los pequeños sistemas de la época aunque el dise- ño se degradaba rápidamente. A medida que la capacidad del hardware y sistemas operati- vos aumentó, también aumentó el tamaño y complejidad de los programas a desarrollar y resultó imposible hacerlo sin una metodología que soportara el proceso.
La experiencia con sistemas de mayor porte llevo al desarrollo de la metodología pa- so a paso (stepwise) [BEN56], que luego fuera formalizada y refinada en la cascada
[ROY70]. El modelo en cascada aportó la formalización de los ciclos de retroalimentación y la incorporación de la prototipación [BOE88]. Fue un avance importante y se convirtió en el estándar para los procesos de adquisición y gestión de contratos.
MODELOS AUTOMATIZABLES DE ESTIMACIÓN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIÓN
II—62
Sin embargo, este modelo hace un énfasis excesivo en disponer de documentos com- pletamente elaborados para requisitos y diseño, lo que, en muchos casos, es difícil si no imposible.
Estas primeras metodologías se basaban en la utopía de los requisitos firmemente
establecidos y congelados y en un desarrollo secuencial. No vale la pena diseñar si no se
tiene requisitos estables. No se puede codificar si no se tiene un diseño estabilizado.
Se caracterizan por que [TOR]:
(a) Las fases se suceden en orden estrictamente secuencial (b) Nada está hecho hasta que todo este terminado
(c) Las fallas más triviales se encuentran al comienzo del período de prueba y las más graves al final
(d) La eliminación de fallas suele ser extremadamente difícil durante las últimas etapas de prueba del sistema
Se propusieron mejoras a este enfoque inicial como el modelo en espiral [BOE86] o el evolutivo [LUQ89].
Pero el ambiente de desarrollo de software está cambiando y estos modelos no se adaptan a los tiempos de la economía basada en la Internet y la Web donde el tiempo de puesta en el mercado puede hacer la diferencia entre el éxito o el fracaso de un proyecto [NOG00, BOE02, BOE04].
A partir de la prototipación rápida y una concepción artesanal de la programación, se produjo una reacción frente a las formas tradicionales de desarrollar software [BOE04] y, en busca de una alternativa a los procesos de desarrollo de software pesados dirigidos por la planificación y documentación intensivas, proliferaron las metodologías ágiles [AGI01].
En la Tabla II-13 se presentan algunos de los métodos más importantes en la actua- lidad y sus principales características. Se les ha asignado un ranking de acuerdo a su mayor o menor agilidad, se califica el grado de restricciones que imponen al implementador, dentro de que ámbitos a nivel organizacional son aplicables, que etapas del ciclo de vida consideran, cuales son las fuentes que originan las restricciones y finalmente referencias.
Del análisis de estos modelos se concluye que existen dos escuelas con característi- cas bien definidas [COE03, BOE04, MOL04d]: procesos conducidos por la planificación y procesos ágiles.