Garantia de la calidad de software

EL enfoque de ingeniería del software descrito en este libro se dirige hacia un solo objetivo:
producir software de alta calidad. Pero a muchos lectores les inquietará la pregunta:
«¿Qué es la calidad del software?»
El problema de la gestión de la calidad no es lo que la gente no sabe sobre ella. El problema es lo que
creen que saben ...
A este respecto, la calidad tiene mucho en común con el sexo. Todo el mundo lo quiere. (Bajo ciertas
condiciones, por supuesto.) Todo el mundo cree que lo conoce. (Incluso aunque no quiera explicarlo.) Todo
el mundo piensa que su ejecución sólo es cuestión de seguir las inclinaciones naturales. (Después de todo,
nos las arreglamos de alguna forma.) Y, por supuesto, la mayoría de la gente piensa que los problemas en
estas áreas están producidos por otra gente. (Como si sólo ellos se tomaran el tiempo para hacer las cosas
bien.)
Algunos desarrolladores de software continúan creyendo que la calidad del software es algo
en lo que empiezan a preocuparse una vez que se ha generado el código. ¡Nada más lejos de la
realidad! La garantía de calidad del software (SQA, Software Quality Assurance GCS, Gestión
de calidad del software) es una actividad de protección (Capítulo 2) que se aplica a lo largo de
todo el proceso del software. La SQA engloba: (1) un enfoque de gestión de calidad; (2) tecnología
de ingeniería del software efectiva (métodos y herramientas); (3) revisiones técnicas
formales que se aplican durante el proceso del software; (4) una estrategia de prueba multiescalada;
(5) el control de la documentación del software y de los cambios realizados; (6) un procedimiento
que asegure un ajuste a los estándares de desarrollo del software (cuando sea posible),
y (7) mecanismos de medición y de generación de informes.
En este capítulo nos centraremos en los aspectos de gestión y en las actividades específicas
del proceso que permitan a una organización de software asegurar que hace «las cosas correctas
en el momento justo y de la forma correcta».
Philip Crosby [CR079], en su famoso libro sobre calidad, expone esta situación:

Conceptos de calidad

Se dice que dos copos de nieve no son iguales. Ciertamente
cuando se observa caer la nieve, es difícil imaginar
que son totalmente diferentes, por no mencionar
que cada copo posee una estructura única. Para observar
las diferencias entre los copos de nieve, debemos
examinar los especímenes muy de cerca, y quizá con
un cristal de aumento. En efecto, cuanto más cerca los
observemos, más diferencias podremos detectar.
Este fenómeno, variación entre muestras, se aplica
a todos los productos del hombre así como a la creación
natural. Por ejemplo, si dos tarjetas de circuito «idénticas
» se examinan muy de cerca, podremos observar que
las líneas de cobre sobre las tarjetas difieren ligeramente
en la geometría, colocación y grosor. Además, la localización
y el diámetro de los orificios de las tarjetas también
varían.

El control de variación es el centro del control de
calidad. Un fabricante quiere reducir la variación entre
los productos que se fabrican, incluso cuando se realiza
algo relativamente sencillo como la duplicación de
disquetes. Seguramente, esto puede no ser un problema
-la duplicación de disquetes es una operación de fabncación
trivial y podemos garantizar que se crean duplicados
exactos de software-.
¿Podemos?. Necesitamos asegurar que las pistas se
sitúen dentro de una tolerancia específica para que la
gran mayoría de las disqueteras puedan leer los disquetes.
Además, necesitamos asegurar que el flujo magnético
para distinguir un cero de un uno sea suficiente
para que los detecten las cabezas de lectura/escritura.
Las máquinas de duplicación de discos aceptan o rechazan
la tolerancia. Por consiguiente, incluso un proceso
«simple», como la duplicación, puede encontrarse con
problemas debidos a la variación entre muestras.
Controlar la variación es la clave de un producto de alta
calidad. En el contexto del software, nos esforzamos
en controlar la variación en el proceso que aplicamos,
recursos que consumimos y los atributos de calidad
del producto final.

¿Cómo se aplica esto al software? ¿Cómo puede
una organización de desarrollo de software necesitar
controlar la variación? De un proyecto a otro, queremos
reducir la diferencia entre los recursos necesarios
planificados para terminar un proyecto y los
recursos reales utilizados, entre los que se incluyen
personal, equipo y tiempo. En general, nos gustaría
asegurarnos de que nuestro programa de pruebas abarca
un porcentaje conocido del software de una entrega
a otra. No sólo queremos reducir el número de
defectos que se extraen para ese campo, sino también
nos gustaría asegurarnos de que los errores ocultos
también se reducen de una entrego a otra. (Es probable
que nuestros clientes se molesten si la tercera
entrega de un producto tiene diez veces más defectos
que la anterior.) Nos gustaría reducir las diferencias
en velocidad y precisión de nuestras respuestas de
soporte a los problemas de los clientes. La lista se
podría ampliar más y más.
8.1.1. Calidad

El American Heritage Dictionary, define la calidad como
«una característica o atributo de algo». Como un atributo
de un elemento, la calidad se refiere a las características
mensurables -cosas que se pueden comparar
con estándares conocidos como longitud, color, propiedades
eléctricas, maleabilidad, etc.-. Sin embargo, el
software en su gran extensión, como entidad intelectual,
es más difícil de caracterizar que los objetos físicos.
No obstante, sí existen las medidas de características
de un programa. Entre estas propiedades se incluyen
complejidad ciclomática, cohesión, número de
puntos de función, líneas de código y muchas otras estudiadas
en los Capítulos 19 y 24. Cuando se examina un
elemento según sus características mensurables, se pueden
encontrar dos tipos de calidad: calidad del diseño
y calidad de concordancia.

La calidad de diseño se refiere a las características
que especifican los ingenieros de software para un elemento.
El grado de materiales, tolerancias y las especificaciones
del rendimiento contribuyen a la calidad del
diseño. Cuando se utilizan materiales de alto grado y se

Analisis y Gestion de Riesgo

ANÁLISIS Y GESTIÓN DEL RIESGO

En su libro sobre análisis y gestión del riesgo, Robert Charette [CHA89] presenta las iguiente definición de riesgo: En primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer están más
allá de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente
con nuestras acciones del pasado. La pregunta es, podemos, por tanto, cambiando nuestras
acciones actuales, crear una oportunidad para una situación diferente y, con suerte, mejor para
nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que puede
venir dado por cambios de opinión, de acciones, de lugares ... [En tercer lugar,] el riesgo
implica elección, y la incertidumbre que entraña la elección. Por tanto, el riesgo, como la muerte
y los impuestos, es una de las pocas cosas inevitables en la vida.

Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares
conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa
-¿qué riesgos podrían hacer que nuestro proyecto fracasara?-. El cambio es nuestra preocupación
¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías de desarrollo,
en las computadoras a las que va dirigido el proyecto y a todas las entidades relacionadas
con él, al cumplimiento de la planificación temporal y al éxito en general?. Para terminar, debemos
enfrentarnos a decisiones -¿qué métodos y herramientas deberíamos emplear, cuánta gente
debería estar implicada, cuánta importancia hay que darle a la calidad?

Tabla de gestion de Riesgo

Principio w5hh

En un excelente documento sobre proyectos y proceso
del software, Bany Boehm [BOE96] afirma: «... se
necesita un principio de organización que haga una
simplificación con el fin de proporcionar planes [de
proyectos] sencillos para proyectos pequeños». Boehm
sugiere un enfoque que trate los objetivos, hitos y planificación,
responsabilidades, enfoque técnico y de
gestión, y los recursos requeridos del proyecto. Bohem
lo llama el principio «WWWWWHH», después de
una serie de preguntas (7 cuestiones) que conducen a
la definición de las características clave del proyecto
y el plan del proyecto resultante:

¿Por qué se desarrolla el sistema? La respuesta a
esta pregunta permite a todas las partes evaluar la validez
de las razones del negocio para el trabajo del software.
Dicho de otra forma, Ljustifica el propósito del
negocio el gasto en personal, tiempo, y dinero?
¿Qué se realizará y cuándo? La respuesta a estas
preguntas ayuda al equipo a establecer la planificación
del proyecto identificando las tareas clave
del proyecto y los hitos requeridos por el cliente.

¿Qué preguntas necesitan ser respondidas para desarrollar un Plan de Proyecto?

¿Quién es el responsable de una función? Antes
en este capítulo, señalamos que el papel y la responsabilidad
de cada miembro del equipo de software
debe estar definida. La respuesta a la pregunta
ayuda a cumplir esto.
2 Dónde están situados organizacionalmente?
No todos los roles y responsabilidades residen en
el equipo de software. El cliente, los usuarios, y
otros directivos también tienen responsabilidades.
Plan de Proyecto de Software
¿Cómo estará realizado el trabajo desde elpunto
de vista técnico y de gestión? Una vez establecido
el ámbito del producto, se debe definir una
estrategia técnica y de gestión para el proyecto.
¿Qué cantidad de cada recurso se necesita? La
respuesta a esta pregunta se deriva de las estimaciones
realizadas  basadas en respuestas
a las preguntas anteriores.

El principio W5HH de Boehm es aplicable sin tener
en cuenta el tamaño o la complejidad del proyecto de
software. Las preguntas señaladas proporcionan un
perfil de planificación al gestor del proyecto y al equipo
de software.

Métricas del software

COCOMO

El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COstMOdel) es un modelo matemático de base empírica utilizado para estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.

Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).

CARACTERÍSTICAS

Pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en líneas de código principalmente.

INCONVENIENTES

• Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizarlas.
• Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el código fuente.
• Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser "vistos" de distinta manera por distintos analistas que usen el método.
• Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la productividad.
• La medición por líneas de código no es válida para orientación a objetos.
• Utilizar este modelo puede resultar un poco complicado, en comparación con otros métodos (que también sólo estiman).

MODELOS DE ESTIMACIÓN

La función básica que utilizan los tres modelos es:
E = a(Kl)^b * m(X) donde:

a y b son constantes con valores definidos en cada submodelo

Kl es la cantidad de líneas de código, en miles.

m(X) Es un multiplicador que depende de 15 atributos.

El resultado se da en unidades salario/mes y horas-hombre.

A la vez, cada submodelo también se divide enmodos que representan el tipo de proyecto, y puede ser:

• modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio). mientras que en los otros dos modos el tamaño varía de pequeño a muy grandes (varios cientos de miles de líneas). En este modo, al igual que en los otros, el coste se incrementa a medida que el tamaño lo hace, y el tiempo de desarrollo se alarga. Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de desarrollo.

• modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.

• modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.

Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el modo orgánico, pero con diferentes constantes.



 Métricas Orientadas al Tamaño
 
Las métricas del software orientadas al tamaño provienen
de la normalización de las medidas de calidad y/o
productividad considerando el «tamaño» del software
que se haya producido. Si una organización de software
mantiene registros sencillos, se puede crear una tabla
de datos orientados al tamaño, como la que muestra la
  La tabla lista cada proyecto de desarrollo de
software de los últimos años y las medidas correspondientes
de cada proyecto. Refiriéndonos a la entrada de
la tabla  del proyecto alfa: se desarrollaron
12.100 líneas de código (LDC) con 24 personas-mes y
con un coste de E168.000. Debe tenerse en cuenta que
el esfuerzo y el coste registrados en la tabla incluyen
todas las actividades de ingeniería del software (análisis,
diseño, codificación y prueba) y no sólo la codificación.
Otra información sobre el proyecto alfa indica
que se desarrollaron 365 páginas de documentación, se
registraron 134 errores antes de que el software se entregara
y se encontraron 29 errores después de entregárselo
al cliente dentro del primer año de utilización.
También sabemos que trabajaron tres personas en el
desarrollo del proyecto alfa.
¿Qué datos deberíamos
reunir para derivar métricas
orientadas al tamaño?


Para desarrollar métricas que se puedan comparar
entre distintos proyectos, se seleccionan las líneas de
código como valor de normalización. Con los rudimentarios
datos contenidos en la tabla se pueden desarrollar
para cada proyecto un conjunto de métricas
simples orientadas al tamaño:
errores por KLDC (miles de líneas de código)
defectos4 por KLDC
E por LDC
páginas de documentación por KLDC
Plontillo de colección de métricos
Además, se pueden calcular otras métricas interesantes:
errores por persona-mes
LDC por persona-mes
E por página de documentación
  Métricas Orientadas a la Función
Las métricas del software orientadas a la función utilizan
una medida de la funcionalidad entregada por la
aplicación como un valor de normalización. Ya que la
«funcionalidad>>n o se puede medir directamente, se
debe derivar indirectamente mediante otras medidas
directas. Las métricas orientadas a la función fueron
propuestas por primera vez por Albretch [ALB79], quien
sugirió una medida llamada punto defunción. Los puntos
de función se derivan con una relación empírica


según las medidas contables (directas) del dominio de
información del software y las evaluaciones de la complejidad
del software.
Referencia 3 Web
Se puede obtener información completo sobre los puntos
de funcibn en: www.ifpug.org
Los puntos de función se calculan [IFP94] completando
la tabla de la  Se determinan cinco
características de dominios de información y se proporcionan
las cuentas en la posición apropiada de la
tabla. Los valores de los dominios de información se
definen de la forma siguiente?
Número de entradas de usuario. Se cuenta cada
entrada de usuario que proporciona diferentes datos
orientados a la aplicación. Las entradas se deberían
diferenciar de las peticiones, las cuales se cuentan de
forma separada.
los puntos de función se derivan de medidas
directas del dominio de la información.
Número de salidas de usuario. Se cuenta cada salida
que proporciona al usuario información orientada a la
aplicación. En este contexto la salida se refiere a informes,
pantallas, mensajes de error, etc. Los elementos
de datos particulares dentro de un informe no se cuentan
de forma separada.
Número de pcticiones de usuario. Una petición se
define como una entrada interactiva que produce la generación
de alguna respuesta del software inmediata en
forma de salida inleractiva. Se cuenta cada petición por
separado.
Número de archivos. Se cuenta cada archivo maestro
lógico (esto es, un grupo lógico de datos que puede
ser una parte de una gran base de datos o un archivo
independiente).
Número de interfaces externas. Se cuentan todas
las interfaces legibles por la máquina (por ejemplo:
archivos de datos de cinta o disco) que se utilizan
para transmitir información a otro sistema.
Una vez que se han recopilado los datos anteriores,
a la cuenta se asocia un valor de complejidad.
Las organizaciones que utilizan métodos de puntos
de función desarrollan criterios para determinar si
una entrada en particular es simple, media o compleja.
No obstante la determinación de la complejidad
es algo subjetiva.
Parámetros de medición Cuenta Número

de entradas de usuario Número de salidas de usuario

Número de peticiones de usuario

ccll Número

de archivos Número de interfaces

externas Factor de ponderación

Simple Medio Complejo

x 3 4 6 =a
x 4 5 7 =a
x 3 4 6 =a
X l 10 15 = a
x 5 7 10 = a
Cuenta total
  Cálculo de puntos de función.
Para calcular puntos de función (PF), se utiliza la
(4.1)
relación siguiente:
PF = cuenta-total x [0,65 + 0,Ol x 6(Fi )]
en donde cuenta-total es la suma de todas las entradas
PF obtenidas de la figura 4.5.
Fi (i = 1 a 14) son «valores de ajuste de la compkjidad
» según las respuestas a las siguientes preguntas
.
¿Requiere el sistema copias de seguridad y de recuperación
fiables?
¿Se requiere comunicación de datos?
¿Existen funciones de procesamiento distribuido?
¿Es crítico el rendimiento?
¿Se ejecutarh el sistema en un entorno operativo
existente y fuertemente utilizado?
i,Requiere el sistema entrada de datos interactiva?
¿Requiere la entrada de datos interactiva que las
transacciones de entrada se lleven a cabo sobre múltiples
pantallas u operaciones?
¿Se actualizan los archivos maestros de forma
interactiva?
¿Son complejas las entradas, las salidas, los archivos
o las peticiones?
¿Es complejo el procesamiento interno?
¿Se ha diseñado el código para ser reutilizable?
¿Están incluidas en el diseño la conversión y la instalación'?
¿Se ha diseñado el sistema para soportar múltiples
instalaciones en diferentes organizaciones?
¿Se ha diseñado la aplicación para facilitar los cambios
y para ser fácilmente utilizada por el usuario?


  Métricas ampliadas de punto de función
La medida de punto de función se diseñó originalmente
para aplicarse a aplicaciones de sistemas de información
de gestión. Para acomodar estas aplicaciones,
se enfatizó la dimensión de datos (los valores de dominios
de información tratados anteriormente) para la
exclusión de dimensiones (control) funcionales y de
comportamiento. Por esta razón, la medida del punto de
función era inadecuada para muchos sistemas de ingeniería
y sistemas empotrados (que enfatizan función y
control). Para remediar esta situación se ha propuesto
un número de extensiones a la métrica del punto de función
básica.
8%
CLAVE
la extensión de los puntos de función se utiliza
en la ingeniería, en las aplicaciones de tiempo real
y en las aplicaciones orientadas al control.
Una extensión del punto de función es la llamada
puntos de características [JON9 11; es una ampliación
de la medida del punto de función que se puede aplicar
a sistemas y aplicaciones de ingeniería del software. La
medida de punto de característica acomoda a aplicaciones
en donde la complejidad del algoritmo es alta.
Las aplicaciones de software de tiempo real, de control
de procesos, y empotradas tienden a tener alta complejidad
de algoritmos y por lo tanto son adecuadas para
el punto de característica.
Para calcular el punto de característica, los valores
de dominio de información se cuentan otra vez y se pesan
de la forma que se describe en la Sección 4.3.2. Además,
la métrica del punto de característica cuenta una característica
nueva del software -los algoritmos-. Un algoritmo
se define como <<unp roblema de cálculo limitado
que se incluye dentro de un programa de computadora
específico» [JON9 11. Invertir una matriz, decodificar
una cadena de bits o manejar una interrupción son ejemplos
de algoritmos.

Boeing ha desarrollado otra extensión de punto de
función para sistemas en tiempo real y productos de
ingeniería. El enfoque de Boeing integra la dimensión
de datos del software con las dimensiones funcionales
y de control para proporcionar una medida orientada
a la función que es adecuada a aplicaciones que
enfatizan las capacidades de control y función. Las
características de las tres dimensiones del software se
«cuentan, cuantifican y transforman» en una medida
que proporciona una indicación de la funcionalidad
entregada por el software6, llamada Punto de Función
30 [WHI95]
La dimensión de datos se evalúa exactamente igual
a como se describe en la Sección 4.3.2. Las cuentas de
datos retenidos (la estructura interna de datos de programas,
p. ej.: archivos) y los datos externos (entradas,
salidas, peticiones y referencias externas) se utilizan a
lo largo de las medidas de la complejidad para derivar
una cuenta de dimensión de datos.

La dimensión funcional se mide considerando «el
número de operaciones internas requeridas para transformar
datos de entrada en datos de salida» [WHI95].


Para calcular puntos de función 3D, se utiliza la rela-
(4.2)
en donde 1, O, Q, F, E, T y R representan valores con
peso de complejidad en los elementos tratados anteriormente:
entradas, salidas, peticiones, estructuras de
datos internas, archivos externos, transformaciones y
transiciones, respectivamente. Cada valor con peso de
complejidad se calcula con la relación siguiente:
valor con peso de complejidad =
ción siguiente:
índice=I + O + Q + F + E + T+ R

en donde Nil , Ni, y Nih representan el número de apariciones
del elemento i (p. ej.: salidas) para cada nivel
de complejidad (bajo, medio, alto), y Wi, , Wia y W,
son los pesos correspondientes. El cálculo global de los
puntos de función 3D se muestran en la Figura 4.6.
Se debería señalar que los puntos de función, los puntos
de característica y los puntos de función 3D representan
lo mismo -«funcionalidad» o «utilidad»
entregada por el software-. En realidad, cada una de
estas medidas producen el mismo valor si sólo se considera
la dimensión de datos de una aplicación. Para sistemas
de tiempo real más complejos, la cuenta de puntos
de característica a menudo se encuentra entre el 20 y el
35 por 100 más que la cuenta determinada sólo con los
puntos de función.
El punto de función (y sus extensiones), como la
medida LDC, es controvertido. Los partidarios afirman
que PF es independiente del lenguaje de programación,
lo cual es ideal para aplicaciones que utilizan lenguajes
convencionales y no procedimentales; esto se basa en
los datos que probablemente se conocen al principio de
la evolución de un proyecto, y así el PF es más atractivo
como enfoque de estimación.
Sentencias
1-5 6-10 11+
1-10 Bajo Bajo Medio
1 1-20 Bajo Medio Alto
Cálculo de los índices de los puntos
de función 30.
Los detractores afirman que el método requiere algún
«juego de manos» en el que el cálculo se base en datos
subjetivos y no objetivos; y afirman que las cuentas del
dominio de información (y otras dimensiones) pueden
ser difíciles de recopilar después de realizado, y por último
que el PF no tiene un significado físico directo -es
simplemente un número-.

Métricas para la calidad de software


El objetivo primordial de la ingeniería del software es producir
un sistema, aplicación o producto de alta calidad.
Para lograr este objetivo, los ingenieros del software deben
aplicar métodos efectivos junto con herramientas modernas
dentro del contexto de un proceso maduro de desarrollo
de software. Además, un buen ingeniero del software
(y buenos gestores de la ingeniería del software) deben
medir si la alta calidad se va a llevar a cabo.
La calidad de un sistema, aplicación o producto es
tan bueno como los requisitos que describen el problema,
el diseño quc modcla la solución, el código que conduce
a un programa ejecutable, y las pruebas que
ejercitan el software para detectar errores. Un buen ingeniero
del software utiliza mediciones que evalúan la
calidad del análisis y los modelos de diseño, el código
fuente, y los casos de prueba que se han creado al aplicar
la ingeniería del software. Para lograr esta evaluación
de la calidad en tiempo real, el ingeniero debe
utilizar medidas técnicas (Capítulos 19 y 24) que evalúan
la calidad con objetividad, no con subjetividad.
Referencia Web/ ’
Se puede encontrar una excelente fuente de informoción
sobre la calidad del software y ternos relacionados
(incluyendo métricas) en: www.quol¡tyworld.com
El gestor de proyectos también debe evaluar la calidad
objetivamente, y no subjetivamente. A medida que
el proyecto progresa el gestor del proyecto también debe
evaluar la calidad. Las métricas privadas recopiladas por
ingenieros del software particulares se asimilan para proporcionar
resultados en los proyectos. Aunque se pueden
recopilar muchas medidas de calidad, el primer objetivo
en el proyecto es medir errores y defectos. Las métricas
que provienen de estas medidas proporcionan una indicación
de la efectividad de las actividades de control y
de la garantía de calidad en grupos o en particulares.
En el capitulo 8 se presento un estudio detallada sobre
las actividades de garantía de calidad del software.
4.5.1. Visión general de los factores que afectan
Hace 25 años, McCall y Cavano [MCC78] definieron un
juego de factores de calidad como los primeros pasos hacia
el desarrollo de métricas de la calidad del software. Estos
factores evalúan el software desde tres puntos de vista distintos:
(1) operación del producto (utilizándolo), (2) revisión
del producto (cambiándolo), y (3) transición del
producto (modificándolo para que funcione en un entorno
diferente, por ejemplo, «portándolo»). Los autores, en
su trabajo, describen la relación entre estos factores de
calidad (lo que llaman un «marco de trabajo») y otros
aspectos del proceso de ingeniería del software:
En primer lugar, el marco de trabajo proporciona un mecanismo
para que el gestor del proyecto identifique lo que considera
importante. Estas cualidades son atributos del software,
además de su corrección y rendimiento funcional, que tiene
implicaciones en el ciclo de vida. En otros factores, como son
facilidad de mantenimiento y portabilidad, se ha demostrado
que tienen un impacto significativo en el coste del ciclo de vida.. .
En segundo lugar, el marco de trabajo proporciona un medio
de evaluar cuantitativamente lo bien que va progresando el desarrollo
en relación con los objetivos de calidad establecidos.. .
En tercer lugar, el marco de trabajo proporciona más interacción
del personal de QA (garantía de calidad) en el esfuerzo
de desarrollo.. .
Por Último,. . . el personal de garantía de calidad puede utilizar
indicaciones de calidad pobre para ayudar a identificar
estándares [mejores] a enfrentar en el futuro.
Un estudio detallado del marco de trabajo de McCall
y Cavano, así como otros factores de calidad, se presentan
en el Capítulo 19. Es interesante destacar que
casi todos los aspectos del cálculo han sufrido cambios
radicales con el paso de los años desde que McCall y

Cavano hicieron su trabajo, con gran influencia, en 1978.
Pero los atributos que proporcionan una indicación de
la calidad del software siguen siendo los mismos.
a sus usuarios finales-. Cuando la proporción de
desperdicios en el coste global del proyecto (para
muchos proyectos) se representa como una función
del tiempo, el gestor puede determinar si la facilidad
total del software producido por una organización de
desarrollo está mejorando. Se pueden emprender
acciones a partir de las conclusiones obtenidas de
esa información.
Integridad. En esta época de «hackers» y direwalls
», la integridad del software ha llegado a tener
mucha importancia. Este atributo mide la capacidad
%&"E
Sorprendentemente, los factores que definían la calidad
del software en el año 1970 san los mismos factores
que continúan definiendo la calidad del software
en la primera década de este siglo.
¿Qué significa esto? Si una organización de software
adopta un juego de factores de calidad como una «lista
de comprobación» para evaluar la calidad del software,
es probable que el software construido hoy siga exhibiendo
la calidad dentro de las primeras décadas de este
siglo. Incluso, cuando las arquitecturas de cálculo sufren
cambios radicales (como seguramente ocurrirá), el software
que exhibe alta calidad en operación, transición y
revisión continuará sirviendo también a sus usuarios.
  Medida de la calidad
Aunque hay muchas medidas de la calidad de software,
la corrección, facilidad de mantenimiento, integridad,
y facilidad de uso proporcionan indicadores Útiles
para el equipo del proyecto. Gilb [GIL881 ha sugerido
definiciones y medidas para cada uno de ellos.
Corrección. Un programa debe operar correctamente
o proporcionará poco valor a sus usuarios. La
corrección es el grado en el que el software lleva a
cabo su función requerida. La medida más común de
corrección es defectos por KLDC, en donde un
defecto se define como una falta verificada de conformidad
con los requisitos.
Facilidad de mantenimiento. El mantenimiento
del software cuenta con más esfuerzo que cualquier
otra actividad de ingeniería del software. La facilidad
de mantenimiento es la facilidad con la que se
puede corregir un programa si se encuentra un error,
se puede adaptar si su entorno cambia, o mejorar si
el cliente desea un cambio de requisitos. No hay
forma de medir directamente la facilidad de mantenimiento;
por consiguiente, se deben utilizar medidas
indirectas. Una simple métrica orientada al
tiempo es el tiempo medio de cambio (TMC), es decir
el tiempo que se tarda en analizar la petición de cambio,
en diseñar una modificación adecuada, en implementar
el cambio, en probarlo y en distribuir el
cambio a todos los usuarios. Como media, los programas
que se pueden mantener tendrán un TMC
más bajo (para tipos equivalentes de cambios) que
los programas que no son más fáciles de mantener.
Hitachi [TAJS 11 ha utilizado una métrica orientada
al coste para la capacidad de mantenimiento llamada
«desperdicios» -e1 coste en corregir defectos
encontrados después de haber distribuido el software
de un sistema para resistir ataques (tanto accidentales
como intencionados) contra su seguridad. El ataque
se puede realizar en cualquiera de los tres componentes
del software: programas, datos y documentos.
Para medir la integridad, se tienen que definir
dos atributos adicionales: amenaza y seguridad.
Amenaza es la probabilidad (que se puede estimar
o deducir de la evidencia empírica) de que un ataque
de un tipo determinado ocurra en un tiempo
determinado. La seguridad es la probabilidad (que
se puede estimar o deducir de la evidencia empírica)
de que se pueda repeler el ataque de un tipo
determinado. La integridad del sistema se puede
definir como:
integridad = C [( 1 - amenaza) x (1 - seguridad)]
donde se suman la amenaza y la seguridad para cada
tipo de ataque.
Facilidad de uso. El calificativo «amigable con el
usuario» se ha convertido en omnipresente en las discusiones
sobre productos de software. Si un programa
no es «amigable con el usuario», frecuentemente está
abocado al fracaso, incluso aunque las funciones que
realice sean valiosas. La facilidad de uso es un intento
de cuantificar «lo amigable que puede ser con el usuario
» y se puede medir en función de cuatro características:
(1) habilidad intelectual y/o física requerida
para aprender el sistema; (2) el tiempo requerido para
llegar a ser moderadamente eficiente en el uso del sistema;
(3) aumento neto en productividad (sobre el
enfoque que el sistema reemplaza) medida cuando
alguien utiliza el sistema moderadamente y eficientemente;
y (4) valoración subjetiva (a veces obtenida
mediante un cuestionario) de la disposición de los
usuarios hacia el sistema. En el Capítulo 15 se estudia
más detalladamente este aspecto.
Los cuatro factores anteriores son sólo un ejemplo
de todos los que se han propuesto como medidas de la
calidad del software. El Capítulo 19 considera este tema
con más detalle.
  Eficacia de la Eliminación de Defectos
Una métrica de la calidad que proporciona beneficios
tanto a nivel del proyecto como del proceso, es la eficacia
de la eliminación de defectos (EED). En esen-




Para propósitos de computación de los puntos de función
3D, se observa una «transformación» como una
serie de pasos de proceso que quedan limitados por sentencias
semánticas. La dimensión de control se mide
contando el número de transiciones entre estados7.
Un estado representa algún modo de comportamiento
externamente observable, y una transición ocurre
como resultado de algún suceso que cambia el
modo de comportamiento del sistema o del software
(esto es, cambia el estado). Por ejemplo, un teléfono
inalámbrico contiene software que soporta funciones
de marcado automático. Para introducir el estado de
marcado automático desde un estado en descanso, el
usuario pulsa una tecla Auto en el teclado numérico.
Este suceso hace que una pantalla LCD pida un código
que indique la parte que se llama. Con la entrada
del código y pulsando la tecla de Marcado (otro suceso),
el software del teléfono inalámbrico hace una
transición al estado de marcado. Cuando se computan
puntos de función 3D, no se asigna un valor de
complejidad a las transiciones.

Metricas para Organizaciones pequeñas
 La amplia mayoría de las organizaciones de desarrollo 
de software tienen menos de 20 personas dedicadas al
software. Es poco razonable, y en la mayoría de los casos
no es realista, esperar que organizaciones como éstas
desarrpllen programas métricos de software extensos.
Sin embargo, si que es razonable sugerir que organizaciones
de software de todos los tamaños midan y después
utilicen las métricas resultantes para ayudar a
mejorar sus procesos de software local y la calidad y
oportunidad de los productos que realizan. Kautz
[KAU99] describe un escenario típico que ocurre cuando
se piensa en programas métricos para organizaciones
pequeñas de software:
Onginalmente, los desarrolladores de software acogían nuestras
actividades con un alto grado de escepticismo, pero al final
las aceptaban debido a que nosotros conseguíamos que nuestras
medidas fueran simples de realizar, adaptadas a cada organización
y se aseguraba que dichas medidas producían una
información válida y útil. Al final, los programas proporcionaba
una base para encargarse de los clientes y para la planificación
y desarrollo de su trabajo futuro.

Lo que Kautz sugiere es una aproximación para la
implementación de cualquier actividad relacionada con
el proceso del software: que sea simple; adaptada a satisfacer
las necesidades locales y que se constate que realmente
añada valor. En los párrafos siguientes examinamos
cómo se relacionan estas líneas generales con las métricas
utilizadas para negocios pequeños.
«Para hacerlo fácil», es una línea de acción que
funciona razonablemente bien en muchas actividades.
Pero jcómo deducimos un conjunto sencillo de métricas
de software que proporcionen valor, y cómo podemos
estar seguros de que estas métricas sencillas
lograran satisfacer las necesidades de una organización
de software particular? Comenzamos sin centrarnos
en la medición, pero sí en los resultados
finales. El grupo de software es interrogado para que
defina un objetivo simple que requiera mejora. Por
ejemplo, «reducir el tiempo para evaluar e implementar
las peticiones de cambio». Una organización
pequeña puede seleccionar el siguiente conjunto de
medidas fácilmente recolectables:
Tiempo (horas o días) que transcurren desde el
momento que es realizada una petición hasta que se
complete su evaluación, tcola.
E.s fuerzo (horas-persona) para desarrollar la evalua- ~ _ _ _
ción, WeVa1.
Tiempo (horas o días) transcurridos desde la terminación
de la evaluación a la asignación de una orden
de cambio al personal, teval.
Esfuerzo (horas-persona) requeridas para realizar el
cambio, Wcambio.
Tiempo requerido (horas o días) para realizar el cam-
Errores descubiertos durante el trabajo para realizar
el cambio, Ecambio.
bio, t,-,bio*
¿Cómo puedo derivar
un conjunto «simple»
de métricas del software?
Una vez que estas medidas han sido recogidas para
un cierto número de peticiones de cambio, es posible calcular
el tiempo total transcurrido desde la petición de
cambio hasta la implementación de dicho cambio y el
porcentaje de tiempo consumido por el proceso de colas
iniciales, la asignación de cambio y evaluación, y la imple,-
mentación del cambio propiamente dicho. De forma similar,
el porcentaje de esfuerzo requerido para la evaluación
y la implementación puede también ser determinado.
Estas métricas pueden ser evaluadas en el contexto de los
datos de calidad, Ecambioy DcanIbioL. os porcentajes proporcionan
un análisis interno para buscar el lugar donde
los procesos de petición de cambio se ralentizan y pueden
conducir a unos pasos de mejoras de proceso para
reducir tco!a ' wevgl i.teva[ ; Wcambioy y/o Ecambio* la eficiencia de eliminacion de defectos (EED) puede ser
calculada de la siguiente manera:
EED = Ecambio ' (Ecambio+Dcamhio)
EED puede compararse con el tiempo transcurrido y el
esfuerzo total para determinar el impacto de las actividades
de aseguramiento de la calidad sobre el tiempo y
el esfuerzo requeridos para realizar un cambio.
Para grupos pequeños, el coste de incorporar medidas
y métricas de cálculo oscila entre el 3 y el 8 por 100
del presupuesto del proyecto durante la fase de aprendizaje
y después cae a menos del 1 por 100 del presupuesto
del proyecto una vez que la ingeniería del
software y la gestión de proyectos se hayan familiarizado
con el programa de métricas [GRA99]. Estos costes
pueden representar una mejora de las inversiones
siempre que el análisis derivado a partir de los datos de
la métrica conduzcan a una mejora de procesos significativa
para la organización del software.


Programa de Metricas
El Instituto de Ingeniería del Software (11s) ha desan-ollado
una guía extensa [PAR961 para establecer un programa
de medición de software dirigido hacia objetivos.
La guía sugiere los siguientes pasos para trabajar:
1. Identificar los objetivos del negocio.
2. Identificar lo que se desea saber o aprender.
3. Identificar los subobjetivos.
4. Identificar las entidades y atributos relativos a esos
5. Formalizar los objetivos de la medición.
subobjetivos.
6. Identificar preguntas que puedan cuantificarse y los
indicadores relacionados que se van a usar para
ayudar a conseguir los objetivos de medición.
7. Identificar los elementos de datos que se van a recoger
para construir los indicadores que ayuden a responder
a las preguntas planteadas.
8. Definir las medidas a usar y hacer que estas definiciones
sean operativas.
9. Identificar las acciones que serán tomadas para
mejorar las medidas indicadas.
10. Preparar un plan para implementar estas medidas.







PLANIFICACIÓN DE PROYECTOS
DE SOFTWARE

La gestión de un proyecto de software comienza con un conjunto de actividades que globalmente
se denominan planificación del proyecto. Antes de que el proyecto comience,
el gestor y el equipo de software deben realizar una estimación del trabajo a realizar, de
ursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su realización.
Siempre que estimamos, estamos mirando hacia el futuro y aceptamos resignados
cierto grado de incertidumbre.

Aunque la estimación es más un arte que una ciencia, es una actividad importante que no
debe llevarse a cabo de forma descuidada. Existen técnicas Útiles para la estimación del esfuerzo
y del tiempo. Las métricas del proyecto y del proceso proporcionan una perspectiva histórica
y una potente introducción para generar estimaciones cuantitativas. La experiencia anterior
(de todas las personas involucradas) puede ayudar en gran medida al desarrollo y revisión de
las estimaciones. Y, dado que la estimación es la base de todas las demás actividades de planificación
del proyecto, y que sirve como guía para una buena ingeniería del software, no es en
absoluto aconsejable embarcarse sin ella.
¿Qué es? La planificación de un proyecto
de software realmente comprende
todas las actividades tratadas en los
Capítulos 5 al 9. Sin embargo, en el
contexto de este capítulo, la planificación
implica la estimación -su intento
por determinar cuánto dinero,
esfuerzo, recursos, y tiempo supondrá
construir un sistema o producto específico
de software-.
&Quién lo hace? Los gestores del software
-utilizando la información solicitada
a los clientes y a los ingenieros
de software y los datos de métricas de
software obtenidos de proyectos anteriores-.
por qué es importante? &Podríac onstruir
una casa sin saber cuanto estaría
dispuesto a gastar?. Por supuesto qve
no, y puesto que la mayoría de los sistemas
y productos basados en computadora
cuestan considerablemente más
que construir una casa grande, podría
sBr razonable desurrollar y estima antes
de empezar a construir el software.
¿Cuáles son los pasos? La estimación
comienza con una descripción del
ámbito del producto. Hasta que no se
ndelimitam el ámbito no es posible realizar
una estimación con sentido. El
problema es entonces descompuesto
en un conjunto de problemas de menor
tamaño y cada uno de éstos se estima
guiándose con datos históricos y con
la experiencia. Es aconsejable realizar
las estimaciones utilizando al menos
dos métodos diferentes (como comprobación).
La complejidad y el riesgo del
problema se considera antes de realizar
una estimación

Conceptos del Espectro de Gestión

La gestión eficaz de un proyecto de software se centra
en las cuatro P’s: personal, producto, proceso y
proyecto. El orden no es arbitrario. El gestor que se
olvida de que el trabajo de ingeniería del software es
un esfuerzo humano intenso nunca tendrá éxito en la
gestión de proyectos. Un gestor que no fomenta una
minuciosa comunicación con el cliente al principio
de la evolución del proyecto se arriesga a construir
una elegante solución para un problema equivocado.
El administrador que presta poca atención al proceso
corre el riesgo de arrojar métodos técnicos y herramientas
eficaces al vacío. El gestor que emprende un
proyecto sin un plan sólido arriesga el éxito del producto.

3.1.1. Personal
La necesidad de contar con personal para el desarrollo
del software altamente preparado y motivado se viene
discutiendo desde los años 60 (por ejemplo, [COUSO,
WíT94, DEM981). De hecho, el «factor humano» es tan
importante que el Instituto de Ingeniería del Software
ha desarrollado un Modelo de madurez de la capacidad
de gestión de personal (MMCGP) «para aumentar la
preparación de organizaciones del software para llevar
a cabo las cada vez más complicadas aplicaciones ayudando
a atraer, aumentar, motivar, desplegar y retener
el talento necesario para mejorar su capacidad de desarrollo
de software» [CUR94].
El modelo de madurez de gestión de personal define
las siguientes áreas clave prácticas para el personal
que desarrolla software: reclutamiento, selección, gestión
de rendimiento, entrenamiento, retribución, desarrollo
de la carrera, diseño de la organización y del
trabajo y desarrollo cultural y de espíritu de equipo.
El MMCGP es compañero del modelo de madurez
de la capacidad software (Capítulo 2), que guía a las
organizaciones en la creación de un proceso de software
maduro. Más adelante en este capítulo se consideran
aspectos asociados a la gestión de personal y estructuras
para proyectos de software.

3.1.2. Producto
Antes de poder planificar un proyecto, se deberían establecer
los objetivos y el ámbito del producto‘, se deberían
considerar soluciones alternativas e identificar las
dificultades técnicas y de gestión. Sin esta información,
es imposible definir unas estimaciones razonables (y
exactas) del coste; una valoración efectiva del riesgo,
una subdivisión realista de las tareas del proyecto o una
planificación del proyecto asequible que proporcione
una indicación fiable del progreso.
En d Capitulo 1 se tmto una taxonomía de las &reas
de aplicociiin que producen los aproductosx de software.
El desarrollador de software y el cliente deben reunirse
para definir los objetivos del producto y su ámbito. En
muchos casos, esta actividad empieza como parte del proceso
de ingeniería del sistema o del negocio (Capítulo 10)
y continúa como el primer paso en el análisis de los requisitos
del software (Capítulo 11). Los objetivos identifican
las metas generales del proyecto sin considerar cómo se
conseguirán (desde el punto de vista del cliente).
El ámbito identifica los datos primarios, funciones y
comportamientos que caracterizan al producto, y, más
importante, intenta abordar estas características de una
manera cuantitativa.
Una vez que se han entendido los objetivos y el ámbito
del producto, se consideran soluciones alternativas.

3.1.3. Proceso
Un proceso de software (Capítulo 2) proporciona la
estructura desde la que se puede establecer un detallado
plan para el desarrollo del software. Un pequeño
número de actividades estructurales se puede aplicar a
todos los proyectos de software, sin tener en cuenta su
tamaño o complejidad. Diferentes conjuntos de tareas
-tareas, hitos, productos del trabajo y puntos de garantía
de calidad- permiten a las actividades estructurales
adaptarse a las características del proyecto de
software y a los requisitos del equipo del proyecto. Finalmente,
las actividades protectoras -tales como garantía
de calidad del software, gestión de la configuración
del software y medición- cubren el modelo de proceso.
Las actividades protectoras son independientes de
las estructurales y tienen lugar a lo largo del proceso.


3.1.4. Proyecto
Dirigimos los proyectos de software planificados y controlados
por una razón principal -es la Única manera
conocida de gestionar la complejidad-. Y todavía
seguimos esforzándonos. En 1998, los datos de la industria
del software indicaron que el 26 por 100 de proyectos
de software fallaron completamente y que el 46
por 100 experimentaron un desbordamiento en la planificación
y en el coste [REE99]. Aunque la proporción
de éxito para los proyectos de software ha mejorado un
poco, nuestra proporción de fracaso de proyecto permanece
más alto del que debería ser2.

Para evitar el fracaso del proyecto, un gestor de proyectos
de software y los ingenieros de software que
construyeron el producto deben eludir un conjunto de
señales de peligro comunes; comprender los factores
del éxito críticos que conducen a la gestión correcta del
proyecto y desarrollar un enfoque de sentido común
para planificar, supervisar y controlar el proyecto. Cada
uno de estos aspectos se trata en la Sección 3.5 y en los
capítulos siguientes.

Personal

En un estudio publicado por el IEEE [CURSS] se les
preguntó a los vicepresidentes ingenieros de tres grandes
compañías tecnológicas sobre el factor más importante
que contribuye al éxito de un proyecto de software.
Respondieron de la siguiente manera:
VP 1: Supongo que si tuviera que elegir lo más importante
de nuestro entorno de trabajo, diría que no son las
herramientas que empleamos, es la gente.
VP 2: El ingrediente más importante que contribuyó al éxito
de este proyecto fue tener gente lista ... pocas cosas
más importan en mi opinión ... Lo más importante
que se puede hacer por un proyecto es seleccionar el
personal ... El éxito de la organización de desarrollo
del software está muy, muy asociado con la habilidad
de reclutar buenos profesionales.
VP 3: La única regla que tengo en cuanto a la gestión
es asegurarme de que tengo buenos profesionales
-gente realmente buena-, de que preparo buena
gente y de que proporciono el entorno en el
que los buenos profesionales puedan producir.
Ciertamente, éste es un testimonio convincente sobre
la importancia del personal en el proceso de ingeniería
del software. Y, sin embargo, todos nosotros, desde los
veteranos vicepresidentes al más modesto profesional
del software, damos este aspecto por descontado. Los
gestores argumentan (como el grupo anterior) que el
personal es algo primario, pero los hechos desmienten
a veces sus palabras.
En esta sección examinamos los participantes que colaboran
en el proceso del software y la manera en que se
organizan para realizar una ingeniería del Software eficaz.
3.2.1. Los participantes
El proceso del software (y todos los proyectos de software)
lo componen participantes que pueden clasificarse
en una de estas cinco categorías:


Gestores superiores, que definen los aspectos de
negocios que a menudo tienen una significativa
influencia en el proyecto.
Gestores (técnicos) del proyecto, que deben planificar,
motivar, organizar y controlar a los profesionales
que realizan el trabajo de software.
Profesionales, que proporcionan las capacidades técnicas
necesarias para la ingeniería de un producto o
aplicación.
Clientes, que especifican los requisitos para la ingeniería
del software y otros elementos que tienen
menor influencia en el resultado.
Usuarios finales, que interaccionan con el software
una vez que se ha entregado para la producción.
Para ser eficaz, el equipo del proyecto debe organizarse
de manera que maximice las habiiidades y capacidades
de cada persona. Y este es el trabajo del jefe del equipo.



3.2.2. Los jefes de equipo
La gestión de un proyecto es una actividad intensamente
humana, y por esta razón, los profesionales competentes
del software a menudo no son buenos jefes de equipo.
Simplemente no tienen la mezcla adecuada de
capacidades del personal. Y sin embargo, como dice
Edgemon: «Desafortunadamente y con demasiada frecuencia,
hay individuos que terminan en la gestión de
proyectos y se convierten en gestores de proyecto accidentales
» [EDG95].

¿En qué nos fijamos cuando
seleccionamos a alguien para
conducir un proyecto de software?
En un excelente libro sobre gestión técnica, Jerry
Weinberg [WEI86] sugiere el modelo de gestión MOI:
Motivación. La habilidad para motivar (con un «tira y afloja
») al personal técnico para que produzca conforme a sus mejores
capacidades.
Organización. La habilidad para amoldar procesos existentes
(o inventar unos nuevos) que permita al concepto inicial
transformarse en un producto hal.
Ideas o innovación. La habilidad para motivar al personal
para crear y sentirse creativos incluso cuando deban de trabajar
dentro de los límites establecidos para un producto o aplicación
de software particular.

Weinberg sugiere que el éxito de los gestores de proyecto
se basa en aplicar un estilo de gestión en la resolución
de problemas. Es decir, un gestor de proyectos de
software debería concentrarse en entender el problema
que hay que resolver, gestionando el flujo de ideas y, al
mismo tiempo, haciendo saber a todos los miembros del
equipo (mediante palabras y, mucho más importante,
con hechos) que la calidad es importante y que no debe
verse comprometida.
Otro punto de vista [EDG95] de las características
que definen a un gestor de proyectos eficiente resalta
cuatro apartados clave:
Resolución del problema. Un gestor eficiente de un proyecto
de software puede diagnosticar los aspectos técnicos y
de organización más relevantes, estructurar una solución sistemáticamente
o motivar apropiadamente a otros profesionales
para que desarrollen la solución, aplicar las lecciones aprendidas
de anteriores proyectos a las nuevas situaciones, mantenerse
lo suficientemente flexible para cambiar la gestión si los
intentos iniciales de resolver el problema no dan resultado.
Dotes de gestión. Un buen gestor de proyectos debe tomar
las riendas. Debe tener confianza para asumir el control cuando
sea necesario y la garantía para permitir que los buenos técnicos
sigan sus instintos.

Incentivos por logros. Para optimizar la productividad de
un equipo de proyecto, un gestor debe recompensar la iniciativa
y los logros, y demostrar a través de sus propias acciones
que no se penalizará si se corren riesgos controlados.
Influencia y construcción de espíritu de equipo. Un gestor
de proyecto eficiente debe ser capaz de «leer» a la gente;
debe ser capaz de entender señales verbales y no verbales y
reaccionar ante las necesidades de las personas que mandan
esas señales. El gestor debe mantener el control en situaciones
de gran estrés.

Un experto de sohore puede no tener temperomento o
deseo de ser jefe de equipo. No fuerce oí experto poro ser
uno de ellos.

3.2.3. El equipo de software
Existen casi tantas estructuras de organización de personal
para el desarrollo de software como organizaciones
que se dedican a ello. Para bien o para mal, el organigrama
no puede cambiarse fácilmente. Las consecuencias
prácticas y políticas de un cambio de organización
no están dentro del alcance de las responsabilidades del
gestor de un proyecto de software. Sin embargo, la organización
del personal directamente involucrado en un
nuevo proyecto de software está dentro del ámbito del
gestor del proyecto.
Las siguientes opciones pueden aplicarse a los recursos
humanos de un proyecto que requiere n personas
trabajando durante k años:


n individuos son asignados a m diferentes tareas funcionales,
tiene lugar relativamente poco trabajo conjunto;
la coordinación es responsabilidad del gestor
del software que puede que tenga otros seis proyectos
de los que preocuparse.
y1 individuos son asignados a m diferentes tareas funcionales
(m<n) de manera que se establecen «equip
o s ~in formales; se puede nombrar un líder al efecto;
la coordinación entre los equipos es responsabilidad
de un gestor del software.
n individuos se organizan en t equipos; a cada equipo
se le asignan una o más tareas funcionales; cada
equipo tiene una estructura específica que se define
para todos los equipos que trabajan en el proyecto;
la coordinación es controlada por el equipo y por el
gestor del proyecto de software.
Aunque es posible encontrar argumentos en pro y en
contra para cada uno de los enfoques anteriores, existe

Producto

El gestor de un proyecto de software se enfrenta a un dilema
al inicio de un proyecto de ingeniería del software.
Se requieren estimaciones cuantitativas y un plan organizado,
pero no se dispone de información sólida. Un
análisis detallado de los requisitos del software proporcionaría
la información necesaria para las estimaciones,
pero el análisis a menudo lleva semanas o meses.
Aún peor, los requisitos pueden ser fluidos, cambiando
regularmente a medida que progresa el proyecto. Y, aún
así, se necesita un plan «¡ya!».

3.3.1. Ámbito del software
La primera actividad de gestión de un proyecto de software
es determinar el ámbito del software. El ámbito se
define respondiendo a las siguientes 'cuestiones:
Si no puede delimitur uno corocterísrico de/ sohure
que intento construib considere /o característica como
un riesgo principo/ de/ proyecto.
Por tanto, debemos examinar el producto y el problema
a resolver justo al inicio del proyecto. Por lo
menos se debe establecer el ámbito del producto y
delimitarlo. do del contexto?

Contexto. ¿Cómo encaja el software a construir
en un sistema, producto o contexto de negocios
mayor y qué limitaciones se imponen como resulta-


Las fases genéricas que caracterizan el proceso de software
definición, desarrollo y soporte- son aplicables
a todo software. El problema es seleccionar el modelo de
proceso apropiado para la ingeniería del software que debe
aplicar el equipo del proyecto. En el Capítulo 2 se estudió
una gran gama de paradigmas de ingeniería del software:
el modelo secuencia1 lineal
* el modelo de prototipo
el modelo DRA .
.
.


el modelo incremental
el modelo en espiral
el modelo en espiral WINWIN
el modelo de desarrollo basado (ensamblaje) en componentes
el modelo de desarrollo concurrente
el modelo de métodos formales
el modelo de técnicas de cuarta generación
INGENIERiA DEL SOFTWARE. UN ENFOQUE PRACTICO

Uno vez eleyido el modelo de proceso, ocompóñelo con

el mínimo conjunto de toreos de trubojo y productos que
desembocaron en un producto de oltu colidud - e v i t e la
cupocidod de destrucción del procese.
El gestor del proyecto debe decidir qué modelo de
proceso es el más adecuado para (1) los clientes que han
solicitado el producto y la gente que realizará el trabajo;
(2) las características del producto en sí, y (3) el entorno
del proyecto en el que trabaja el equipo de software.
Cuando se selecciona un modelo de proceso, el equipo
define entonces un plan de proyecto preliminar basado
en un conjunto de actividades estructurales. Una vez
establecido el plan preliminar, empieza la descomposición
del proceso. Es decir, se debe crear un plan completo
reflejando las tareas requeridas a las personas para
cubrir las actividades estructurales. Exploramos estas
actividades brevemente en las secciones que siguen y
presentamos una visión más detallada .

3.4.1. Maduración del producto y del proceso
La planificación de un proyecto empieza con la maduración
del producto y del proceso. Todas las funciones
que se deben tratar dentro de un proceso de ingeniería
por el equipo de software deben pasar por el conjunto
de actividades estructurales que se han definido para
una organización de software. Asuma que la organización
ha adoptado el siguiente conjunto de actividades
estructurales (Capítulo 2):
Comunicación con el cliente- tareas requeridas para
establecer la obtención de requisitos eficiente entre
el desarrollador y el cliente.
Planificación- tareas requeridas para definir los
recursos, la planificación temporal del proyecto y
cualquier información relativa a él.
Recuerde .... las ocrividaáes estructurales se u p h n
en todos los proyectos- no hoy excepciones.
Análisis del riesgo- tareas requeridas para valorar
los riesgos técnicos y de gestión.
Zngenieriu- tareas requeridas para construir una o
más representaciones de la aplicación.
Construcción y entrega- tareas requeridas para construir,
probar, instalar y proporcionar asistencia al usuario
(por ejemplo: documentación y formación).
Evaluación del cliente- tareas requeridas para obtener
información de la opinión del cliente basadas en
la evaluación de las representaciones de software
creadas durante la fase de ingeniería e implementadas
durante la fase de instalación.

Los miembros del equipo que trabajan en cada función
aplicarán todas las actividades estructurales. En esencia,
se crea una matriz similar a la que se muestra en la Figura

3.2. Cada función principal del problema (la figura contiene
las funciones para el software procesador de textos
comentado anteriormente) se lista en la columna de la
izquierda. Las actividades estructurales se listan en la fila

Resolución caso de estudio 

Objetivo General

Diseñar sistema un automatizado de gestión en Fesamericacentral, utilizando modelo de espiral. para mejoras en el control de la gestión de fondos de la misma.

Objetivos Específicos

Recolectar datos acerca de la forma en que funciona la empresa.

Mejorar el funcionamiento de la empresa Fesamericacentral.

Elaborar documento con diseño de sistema automatizado de Gestión.

Recopilación de requerimientos

Datos del Expositor: Nombre, Apellido, Dirección, Teléfono, Profesión, Asociación, Cargo, Idioma, Nacionalidad, Edad.

Datos de Eventos: Nombre del seminario, enfoque metodológico, duración de eventos, temas, programas, mesas de Trabajo.

Datos de Documentos: Programa, mesa de trabajo, encargado de mesa, medios dinámicos, numero de copias de proyecto.

Datos de servicios y Lugar de eventos: Nombre (Hotel o restaurante), dirección, teléfono, menú(Desayuno, Almuerzo, Cena. costos).

Análisis de riesgo

—

    En el análisis de riesgo tomamos en cuenta muchos factores desde el punto de vista técnico como el punto de vista operativo de las invitaciones.

—

Análisis de riesgo técnico.

     Desde el punto de vista técnico nos hemos dado cuenta de que la  Fundación  FES América utiliza para sus actividades equipos  no muy óptimos para un excelente  desarrollo lo cual es un riesgo para la fundación  debido a que con equipos en esos estados no brindarían una mejor presentación a las personas participantes de dichas actividades, la mejor decisión en ese caso seria invertir en equipos óptimos para garantizar un evento de calidad, ya que en las oficinas tienen equipos muy optimizados. Actualmente constan con 7 computadoras. Lo cual lo hace mas eficiente en la atención al cliente y en sus trabajos operativos dentro de la organización.

Análisis de riesgo operativo de las invitaciones.

     Analizando desde el punto de vista operativo de la fundación, hemos logrado            identificar algunos factores de posibles riesgos, dentro de ellos tenemos los siguientes:

     Invitaciones incorrectas a personas no invitadas para cierta actividad, esto ocasionaría una gran problemática en la organización de los invitados y no invitados, en este caso seria tomar medidas urgentemente para evitar pequeños incidentes como este, una de las medidas podría ser invertir en un sistema con mucha robustez el cual no permita errores de este tipo.

Formulario de datos del Expositor

Formulario de Temas

Formulario de Documentos

Formulario del Bufet

Modelo de desarrollo de software

Modelo cascada

Este, aunque es más comúnmente conocido como modelo en cascada es también llamado "modelo clásico", "modelo tradicional" o "modelo lineal secuencial".

El modelo en cascada puro difícilmente se utilice tal cual, pues esto implicaría un previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de errores; ello sólo podría ser aplicable a escasos y pequeños desarrollos de sistemas. En estas circunstancias, el paso de una etapa a otra de las mencionadas sería sin retorno, por ejemplo pasar del Diseño a la Codificación implicaría un diseño exacto y sin errores ni probable modificación o evolución: "codifique lo diseñado que no habrán en absoluto variantes ni errores". Esto es utópico; ya que intrínsecamente el software es de carácter evolutivo, cambiante y difícilmente libre de errores, tanto durante su desarrollo como durante su vida operativa.⁷

Fig. 2 - Modelo cascada puro o secuencial para el ciclo de vida del software.

Algún cambio durante la ejecución de una cualquiera de las etapas en este modelo secuencial implicaría reiniciar desde el principio todo el ciclo completo, lo cual redundaría en altos costos de tiempo y desarrollo. La figura 2 muestra un posible esquema de el modelo en cuestión.⁷

Sin embargo, el modelo cascada en algunas de sus variantes es uno de los actualmente más utilizados¹⁰ , por su eficacia y simplicidad, más que nada en software de pequeño y algunos de mediano porte; pero nunca (o muy rara vez) se lo usa en su forma pura, como se dijo anteriormente. En lugar de ello, siempre se produce alguna realimentación entre etapas, que no es completamente predecible ni rígida; esto da oportunidad al desarrollo de productos software en los cuales hay ciertas incertezas, cambios o evoluciones durante el ciclo de vida. Así por ejemplo, una vez capturados (elicitados) y especificados los requisitos (primera etapa) se puede pasar al diseño del sistema, pero durante esta última fase lo más probable es que se deban realizar ajustes en los requisitos (aunque sean mínimos), ya sea por fallas detectadas, ambigüedades o bien por que los propios requisitos han cambiado o evolucionado; con lo cual se debe retornar a la primera o previa etapa, hacer los pertinentes reajustes y luego continuar nuevamente con el diseño; esto último se conoce como realimentación. Lo normal en el modelo cascada será entonces la aplicación del mismo con sus etapas realimentadas de alguna forma, permitiendo retroceder de una a la anterior (e incluso poder saltar a varias anteriores) si es requerido.

De esta manera se obtiene un "modelo cascada realimentado", que puede ser esquematizado como lo ilustra la figura 3.

Fig. 3 - Modelo cascada realimentado para el ciclo de vida.

Lo dicho es, a grandes rasgos, la forma y utilización de este modelo, uno de los más usados y populares.⁷ El modelo Cascada Realimentado resulta muy atractivo, hasta ideal, si el proyecto presenta alta rigidéz (pocos o ningún cambio, no evolutivo), los requisitos son muy claros y están correctamente especificados.¹⁰

Hay más variantes similares al modelo: refino de etapas (más etapas, menores y más específicas) o incluso mostrar menos etapas de las indicadas, aunque en tal caso la faltante estará dentro de alguna otra. El orden de esas fases indicadas en el ítem previo es el lógico y adecuado, pero adviértase, como se dijo, que normalmente habrá realimentación hacia atrás.

El modelo lineal o en Cascada es el paradigma más antiguo y extensamente utilizado, sin embargo las críticas a él (ver desventajas) han puesto en duda su eficacia. Pese a todo tiene un lugar muy importante en la Ingeniería de software y continúa siendo el más utilizado; y siempre es mejor que un enfoque al azar.¹⁰

Desventajas del modelo cascada:⁷

• Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande.
• No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difícil de acomodar.¹⁰
• El cliente debe tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, implicando reinicio del proyecto, con altos costos.

Modelos evolutivos

El software evoluciona con el tiempo. Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se debe introducir una versión funcional limitada de alguna forma para aliviar las presiones competitivas.

En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estén diseñados para acomodarse a una evolución temporal o progresiva, donde los requisitos centrales son conocidos de antemano, aunque no estén bien definidos a nivel detalle.

En el modelo Cascada y Cascada Realimentado no se tiene en cuenta la naturaleza evolutiva del software, se plantea como estático con requisitos bien conocidos y definidos desde el inicio.⁷

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de operación.

Los modelos “Iterativo Incremental” y “Espiral” (entre otros) son dos de los más conocidos y utilizados del tipo evolutivo.¹⁰

Modelo iterativo incremental

En términos generales, podemos distinguir, en la figura 4, los pasos generales que sigue el proceso de desarrollo de un producto software. En el modelo de ciclo de vida seleccionado, se identifican claramente dichos pasos. La Descripción del Sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al Producto global y final. Las actividades concurrentes (Especificación, Desarrollo y Validación) sintetizan el desarrollo pormenorizado de los incrementos, que se hará posteriormente.

Fig. 4 - Diagrama genérico del desarrollo evolutivo incremental.

El diagrama 4 nos muestra en forma muy esquemática, el funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final.⁷ Es decir, a medida que cada incremento definido llega a su etapa de operación y mantenimiento. Cada versión emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios.

El incremental es un modelo de tipo evolutivo que está basado en varios ciclos Cascada realimentados aplicados repetidamente, con una filosofía iterativa.¹⁰ En la figura 5 se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener finalmente el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus actividades genéricas asociadas. Aquí se observa claramente cada ciclo cascada que es aplicado para la obtención de un incremento; estos últimos se van integrando para obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por simplicidad, en la figura 5 se muestra como secuencial puro.

Fig. 5 - Modelo iterativo incremental para el ciclo de vida del software,.

Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concurrentemente, así por ejemplo, en la figura, mientras se realiza el diseño detalle del primer incremento ya se está realizando en análisis del segundo. La figura 5 es sólo esquemática, un incremento no necesariamente se iniciará durante la fase de diseño del anterior, puede ser posterior (incluso antes), en cualquier tiempo de la etapa previa. Cada incremento concluye con la actividad de “Operación y Mantenimiento” (indicada "Operación" en la figura), que es donde se produce la entrega del producto parcial al cliente. El momento de inicio de cada incremento es dependiente de varios factores: tipo de sistema; independencia o dependencia entre incrementos (dos de ellos totalmente independientes pueden ser fácilmente iniciados al mismo tiempo si se dispone de personal suficiente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc.

Bajo este modelo se entrega software “por partes funcionales más pequeñas”, pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.⁷

Como se muestra en la figura 5, se aplican secuencias Cascada en forma escalonada, mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer incremento es un sistema básico, con muchas funciones suplementarias (conocidas o no) sin entregar.

El cliente utiliza inicialmente ese sistema básico intertanto, el resultado de su uso y evaluación puede aportar al plan para el desarrollo del/los siguientes incrementos (o versiones). Además también aportan a ese plan otros factores, como lo es la priorización (mayor o menor urgencia en la necesidad de cada incremento) y la dependencia entre incrementos (o independencia).

Luego de cada integración se entrega un producto con mayor funcionalidad que el previo. El proceso se repite hasta alcanzar el software final completo.

Siendo iterativo, con el modelo incremental se entrega un producto parcial pero completamente operacional en cada incremento, y no una parte que sea usada para reajustar los requerimientos (como si ocurre en el modelo de construcción de prototipos).¹⁰

El enfoque incremental resulta muy útil con baja dotación de personal para el desarrollo; también si no hay disponible fecha límite del proyecto por lo que se entregan versiones incompletas pero que proporcionan al usuario funcionalidad básica (y cada vez mayor). También es un modelo útil a los fines de evaluación.

Nota: Puede ser considerado y útil, en cualquier momento o incremento incorporar temporalmente el paradigma MCP como complemento, teniendo así una mixtura de modelos que mejoran el esquema y desarrollo general.

Ejemplo:

Un procesador de texto que sea desarrollado bajo el paradigma Incremental podría aportar, en principio, funciones básicas de edición de archivos y producción de documentos (algo como un editor simple). En un segundo incremento se le podría agregar edición más sofisticada, y de generación y mezcla de documentos. En un tercer incremento podría considerarse el agregado de funciones de corrección ortográfica, esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones matemáticas. Así sucesivamente hasta llegar al procesador final requerido. Así, el producto va creciendo, acercándose a su meta final, pero desde la entrega del primer incremento ya es útil y funcional para el cliente, el cual observa una respuesta rápida en cuanto a entrega temprana; sin notar que la fecha límite del proyecto puede no estar acotada ni tan definida, lo que da margen de operación y alivia presiones al equipo de desarrollo.

Como se dijo, el Iterativo Incremental es un modelo del tipo evolutivo, es decir donde se permiten y esperan probables cambios en los requisitos en tiempo de desarrollo; se admite cierto margen para que el software pueda evolucionar. Aplicable cuando los requisitos son medianamente bien conocidos pero no son completamente estáticos y definidos, cuestión esa que si es indispensable para poder utilizar un modelo Cascada.

El modelo es aconsejable para el desarrollo de software en el cual se observe, en su etapa inicial de análisis, que posee áreas bastante bien definidas a cubrir, con suficiente independencia como para ser desarrolladas en etapas sucesivas. Tales áreas a cubrir suelen tener distintos grados de apremio por lo cual las mismas se deben priorizar en un análisis previo, es decir, definir cual será la primera, la segunda, y así sucesivamente; esto se conoce como “definición de los incrementos” con base en priorización. Pueden no existir prioridades funcionales por parte del cliente, pero el desarrollador debe fijarlas de todos modos y con algún criterio, ya que basándose en ellas se desarrollarán y entregarán los distintos incrementos.

El hecho de que existan incrementos funcionales del software lleva inmediatamente a pensar en un esquema de desarrollo modular, por tanto este modelo facilita tal paradigma de diseño.

En resumen, un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto software denominados “incrementos” del sistema, que son escogidos según prioridades predefinidas de algún modo. El modelo permite una implementación con refinamientos sucesivos (ampliación o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software.

Este modelo brinda cierta flexibilidad para que durante el desarrollo se incluyan cambios en los requisitos por parte del usuario, un cambio de requisitos propuesto y aprobado puede analizarse e implementarse como un nuevo incremento o, eventualmente, podrá constituir una mejora/adecuación de uno ya planeado. Aunque si se produce un cambio de requisitos por parte del cliente que afecte incrementos previos ya terminados (detección/incorporación tardía) se debe evaluar la factibilidad y realizar un acuerdo con el cliente, ya que puede impactar fuertemente en los costos.

La selección de este modelo permite realizar entregas funcionales tempranas al cliente (lo cual es beneficioso tanto para él como para el grupo de desarrollo). Se priorizan las entregas de aquellos módulos o incrementos en que surja la necesidad operativa de hacerlo, por ejemplo para cargas previas de información, indispensable para los incrementos siguientes.¹⁰

El modelo iterativo incremental no obliga a especificar con precisión y detalle absolutamente todo lo que el sistema debe hacer, (y cómo), antes de ser construido (como el caso del cascada, con requisitos congelados). Sólo se hace en el incremento en desarrollo. Esto torna más manejable el proceso y reduce el impacto en los costos. Esto es así, porque en caso de alterar o rehacer los requisitos, solo afecta una parte del sistema. Aunque, lógicamente, esta situación se agrava si se presenta en estado avanzado, es decir en los últimos incrementos. En definitiva, el modelo facilita la incorporación de nuevos requisitos durante el desarrollo.

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa funcionalidad parcial. También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software.

El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.

El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, o de alto índice de riesgos.

Modelo espiral

El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada. Proporciona potencial para desarrollo rápido de versiones incrementales. En el modelo Espiral el software se construye en una serie de versiones incrementales. En las primeras iteraciones la versión incremental podría ser un modelo en papel o bien un prototipo. En las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.^7 10

El modelo se divide en un número de Actividades de marco de trabajo, llamadas "regiones de tareas". En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En la figura 6 se muestra el esquema de un Modelo Espiral con 6 regiones. En este caso se explica una variante del modelo original de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado más reciente.

Fig. 6 - Modelo espiral para el ciclo de vida del software.

Las regiones definidas en el modelo de la figura son:

• Región 1 - Tareas requeridas para establecer la comunicación entre el cliente y el desarrollador.
• Región 2 - Tareas inherentes a la definición de los recursos, tiempo y otra información relacionada con el proyecto.
• Región 3 - Tareas necesarias para evaluar los riesgos técnicos y de gestión del proyecto.
• Región 4 - Tareas para construir una o más representaciones de la aplicación software.
• Región 5 - Tareas para construir la aplicación, instalarla, probarla y proporcionar soporte al usuario o cliente (Ej. documentación y práctica).
• Región 6 - Tareas para obtener la reacción del cliente, según la evaluación de lo creado e instalado en los ciclos anteriores.

Las actividades enunciadas para el marco de trabajo son generales y se aplican a cualquier proyecto, grande, mediano o pequeño, complejo o no. Las regiones que definen esas actividades comprenden un "conjunto de tareas" del trabajo: ese conjunto sí se debe adaptar a las características del proyecto en particular a emprender. Nótese que lo listado en los ítems de 1 a 6 son conjuntos de tareas, algunas de las ellas normalmente dependen del proyecto o desarrollo en si.

Proyectos pequeños requieren baja cantidad de tareas y también de formalidad. En proyectos mayores o críticos cada región de tareas contiene labores de más alto nivel de formalidad. En cualquier caso se aplican actividades de protección (por ejemplo, gestión de configuración del software, garantía de calidad, etc.).

Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniería gira alrededor del espiral (metafóricamente hablando) comenzando por el centro (marcado con ๑ en la figura 6) y en el sentido indicado; el primer circuito de la espiral puede producir el desarrollo de una especificación del producto; los pasos siguientes podrían generar un prototipo y progresivamente versiones más sofisticadas del software.

Cada paso por la región de planificación provoca ajustes en el plan del proyecto; el coste y planificación se realimentan en función de la evaluación del cliente. El gestor de proyectos debe ajustar el número de iteraciones requeridas para completar el desarrollo.

El modelo espiral puede ir adaptándose y aplicarse a lo largo de todo el Ciclo de vida del software (en el modelo clásico, o cascada, el proceso termina a la entrega del software).

Una visión alternativa del modelo puede observarse examinando el "eje de punto de entrada de proyectos". Cada uno de los circulitos (๏) fijados a lo largo del eje representan puntos de arranque de los distintos proyectos (relacionados); a saber:

• Un proyecto de "Desarrollo de Conceptos" comienza al inicio de la espiral, hace múltiples iteraciones hasta que se completa, es la zona marcada con verde.
• Si lo anterior se va a desarrollar como producto real, se incia otro proyecto: "Desarrollo de nuevo Producto". Que evolucionará con iteraciones hasta culminar; es la zona marcada en color azul.
• Eventual y análogamente se generarán proyectos de "Mejoras de Productos" y de "Mantenimiento de productos", con las iteraciones necesarias en cada área (zonas roja y gris, respectivamente).

Cuando la espiral se caracteriza de esta forma, está operativa hasta que el software se retira, eventualmente puede estar inactiva (el proceso), pero cuando se produce un cambio el proceso arranca nuevamente en el punto de entrada apropiado (por ejemplo, en "Mejora del Producto").

El modelo espiral da un enfoque realista, que evoluciona igual que el software; se adapta muy bien para desarrollos a gran escala.

El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la evolución. Mantiene el enfoque clásico (cascada) pero incorpora un marco de trabajo iterativo que refleja mejor la realidad.

Este modelo requiere considerar riesgos técnicos en todas las etapas del proyecto; aplicado adecuadamente debe reducirlos antes de que sean un verdadero problema.

El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de Sistemas Operativos (complejos); también en sistemas de altos riesgos o críticos (Ej. navegadores y controladores aeronáuticos) y en todos aquellos en que sea necesaria una fuerte gestión del proyecto y sus riesgos, técnicos o de gestión.

Desventajas importantes:

• Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto.
• Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo.

Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por lo que no se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difícil de implementar y controlar.

Modelo espiral Win & Win

Una variante interesante del Modelo Espiral previamente visto (Fig. 6) es el "Modelo espiral Win-Win"⁸ (Barry Boehm). El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.

"Es así que la obtención de requisitos requiere una negociación, que tiene éxito cuando ambas partes ganan".

Las mejores negociaciones se fuerzan en obtener "Victoria & Victoria" (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociación.

El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral; se definen las siguientes actividades:

1. Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren).
2. Determinación de "condiciones de victoria" de los directivos (saber qué necesitan y los satisface)
3. Negociación de las condiciones "victoria" de los directivos para obtener condiciones "Victoria & Victoria" (negociar para que ambos ganen).

(*) Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por la organización si tiene éxito o criticado si no.

El modelo Win & Win hace énfasis en la negociación inicial, también introduce 3 hitos en el proceso llamados "puntos de fijación", que ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo del software.

Etapas en el desarrollo del software

Captura, análisis y especificación de requisitos

Al inicio de un desarrollo (no de un proyecto), esta es la primera fase que se realiza, y, según el modelo de proceso adoptado, puede casi terminar para pasar a la próxima etapa (caso de Modelo Cascada Realimentado) o puede hacerse parcialmente para luego retomarla (caso Modelo Iterativo Incremental u otros de carácter evolutivo).

En simple palabras y básicamente, durante esta fase, se adquieren, reúnen y especifican las características funcionales y no funcionales que deberá cumplir el futuro programa o sistema a desarrollar.

Las bondades de las características, tanto del sistema o programa a desarrollar, como de su entorno, parámetros no funcionales y arquitectura dependen enormemente de lo bien lograda que esté esta etapa. Esta es, probablemente, la de mayor importancia y una de las fases más difíciles de lograr certeramente, pues no es automatizable, no es muy técnica y depende en gran medida de la habilidad y experiencia del analista que la realice.

Involucra fuertemente al usuario o cliente del sistema, por tanto tiene matices muy subjetivos y es difícil de modelar con certeza o aplicar una técnica que sea "la más cercana a la adecuada" (de hecho no existe "la estrictamente adecuada"). Si bien se han ideado varias metodologías, incluso software de apoyo, para captura, elicitación y registro de requisitos, no existe una forma infalible o absolutamente confiable, y deben aplicarse conjuntamente buenos criterios y mucho sentido común por parte del o los analistas encargados de la tarea; es fundamental también lograr una fluida y adecuada comunicación y comprensión con el usuario final o cliente del sistema.

El artefacto más importante resultado de la culminación de esta etapa es lo que se conoce como especificación de requisitos software o simplemente documento ERS.

Como se dijo, la habilidad del analista para interactuar con el cliente es fundamental; lo común es que el cliente tenga un objetivo general o problema a resolver, no conoce en absoluto el área (informática), ni su jerga, ni siquiera sabe con precisión qué debería hacer el producto software (qué y cuantas funciones) ni, mucho menos, cómo debe operar. En otros casos menos frecuentes, el cliente "piensa" que sabe precisamente lo que el software tiene que hacer, y generalmente acierta muy parcialmente, pero su empecinamiento entorpece la tarea de elicitación. El analista debe tener la capacidad para lidiar con este tipo de problemas, que incluyen relaciones humanas; tiene que saber ponerse al nivel del usuario para permitir una adecuada comunicación y comprensión.

Escasas son las situaciones en que el cliente sabe con certeza e incluso con completitud lo que requiere de su futuro sistema, este es el caso más sencillo para el analista.

Las tareas relativas a captura, elicitación, modelado y registro de requerimientos, además de ser sumamente importante, puede llegar a ser dificultosa de lograr acertadamente y llevar bastante tiempo relativo al proceso total del desarrollo; al proceso y metodologías para llevar a cabo este conjunto de actividades normalmente se las asume parte propia de la Ingeniería de Software, pero dada la antedicha complejidad, actualmente se habla de una Ingeniería en Requisitos¹¹ , aunque ella aún no existe formalmente.

Hay grupos de estudio e investigación, en todo el mundo, que están exclusivamente abocados a la idear modelos, técnicas y procesos para intentar lograr la correcta captura, análisis y registro de requerimientos. Estos grupos son los que normalmente hablan de la Ingeniería en Requisitos; es decir se plantea ésta como un área o disciplina pero no como una carrera universitaria en si misma.

Algunos requisitos no necesitan la presencia del cliente, para ser capturados o analizados; en ciertos casos los puede proponer el mismo analista o, incluso, adoptar unilateralmente decisiones que considera adecuadas (tanto en requerimientos funcionales como no funcionales). Por citar ejemplos probables: Algunos requisitos sobre la arquitectura del sistema, requisitos no funcionales tales como los relativos al rendimiento, nivel de soporte a errores operativos, plataformas de desarrollo, relaciones internas o ligas entre la información (entre registros o tablas de datos) a almacenar en caso de bases o bancos de datos, etc. Algunos funcionales tales como opciones secundarias o de soporte necesarias para una mejor o más sencilla operatividad; etc.

La obtención de especificaciones a partir del cliente (u otros actores intervinientes) es un proceso humano muy interactivo e iterativo; normalmente a medida que se captura la información, se la analiza y realimenta con el cliente, refinándola, puliéndola y corrigiendo si es necesario; cualquiera sea el método de ERS utilizado. EL analista siempre debe llegar a conocer la temática y el problema a resolver, dominarlo, hasta cierto punto, hasta el ámbito que el futuro sistema a desarrollar lo abarque. Por ello el analista debe tener alta capacidad para comprender problemas de muy diversas áreas o disciplinas de trabajo (que no son específicamente suyas); así por ejemplo, si el sistema a desarrollar será para gestionar información de una aseguradora y sus sucursales remotas, el analista se debe compenetrar en cómo ella trabaja y maneja su información, desde niveles muy bajos e incluso llegando hasta los gerenciales. Dada a gran diversidad de campos a cubrir, los analistas suelen ser asistidos por especialistas, es decir gente que conoce profundamente el área para la cual se desarrollará el software; evidentemente una única persona (el analista) no puede abarcar tan vasta cantidad de áreas del conocimiento. En empresas grandes de desarrollo de productos software, es común tener analistas especializados en ciertas áreas de trabajo.

Contrariamente, no es problema del cliente, es decir él no tiene por qué saber nada de software, ni de diseños, ni otras cosas relacionadas; sólo se debe limitar a aportar objetivos, datos e información (de mano propia o de sus registros, equipos, empleados, etc) al analista, y guiado por él, para que, en primera instancia, defina el "Universo de Discurso", y con posterior trabajo logre confeccionar el adecuado documento ERS.

Es bien conocida la presión que sufren los desarrolladores de sistemas informáticos para comprender y rescatar las necesidades de los clientes/usuarios. Cuanto más complejo es el contexto del problema más difícil es lograrlo, a veces se fuerza a los desarrolladores a tener que convertirse en casi expertos de los dominios que analizan.

Cuando esto no sucede es muy probable que se genere un conjunto de requisitos¹² erróneos o incompletos y por lo tanto un producto de software con alto grado de desaprobación por parte de los clientes/usuarios y un altísimo costo de reingeniería y mantenimiento. Todo aquello que no se detecte, o resulte mal entendido en la etapa inicial provocará un fuerte impacto negativo en los requisitos, propagando esta corriente degradante a lo largo de todo el proceso de desarrollo e incrementando su perjuicio cuanto más tardía sea su detección (Bell y Thayer 1976)(Davis 1993).

Procesos, modelado y formas de elicitación de requisito                                                           Siendo que la captura, elicitación y especificación de requisitos, es una parte crucial en el proceso de desarrollo de software, ya que de esta etapa depende el logro de los objetivos finales previstos, se han ideado modelos y diversas metodologías de trabajo para estos fines. También existen herramientas software que apoyan las tareas relativas realizadas por el ingeniero en requisitos.

El estándar IEEE 830-1998 brinda una normalización de las "Prácticas Recomendadas para la Especificación de Requisitos Software".¹³

A medida que se obtienen los requisitos, normalmente se los va analizando, el resultado de este análisis, con o sin el cliente, se plasma en un documento, conocido como ERS o Especificación de Requisitos Software, cuya estructura puede venir definida por varios estándares, tales como CMM-I.

Un primer paso para realizar el relevamiento de información es el conocimiento y definición acertada lo que se conoce como "Universo de Discurso" del problema, que se define y entiende por:

Universo de Discurso (UdeD): es el contexto general en el cual el software deberá ser desarrollado y deberá operar. El UdeD incluye todas las fuentes de información y todas las personas relacionadas con el software. Esas personas son conocidas también como actores de ese universo. El UdeD es la realidad circunstanciada por el conjunto de objetivos definidos por quienes demandaron el software.

A partir de la extracción y análisis de información en su ámbito se obtienen todas las especificaciones necesarias y tipos de requisitos para el futuro producto software.

El objetivo de la Ingeniería de Requisitos (IR) es sistematizar el proceso de definición de requisitos permitiendo elicitar, modelar y analizar el problema, generando un compromiso entre los Ingenieros de Requisitos y los clientes/usuarios, ya que ambos participan en la generación y definición de los requisitos del sistema. La IR aporta un conjunto de métodos, técnicas y herramientas que asisten a los ingenieros de requisitos (analistas) para obtener requerimientos lo más seguros, veraces, completos y oportunos posibles, permitiendo básicamente:

• Comprender el problema
• Facilitar la obtención de las necesidades del cliente/usuario
• Validar con el cliente/usuario
• Garantizar las especificaciones de requisitos

Si bien existen diversas formas, modelos y metodologías para elicitar, definir y documentar requerimientos, no se puede decir que alguna de ellas sea mejor o peor que la otra, suelen tener muchísimo en común, y todas cumplen el mismo objetivo. Sin embargo, lo que si se puede decir sin dudas es que es indispensable utilizar alguna de ellas para documentar las especificaciones del futuro producto software. Así por ejemplo, hay un grupo de investigación argentino que desde hace varios años ha propuesto y estudia el uso del LEL (Léxico Extendido del Lenguaje) y Escenarios como metodología, aquí¹⁴ se presenta una de las tantas referencias y bibliografía sobre ello. Otra forma, más ortodoxa, de capturar y documentar requisitos se puede obtener en detalle, por ejemplo, en el trabajo de la Universidad de Sevilla sobre "Metodología para el Análisis de Requisitos de Sistemas Software".¹⁵

En la Fig. 7 se muestra un esquema, más o menos riguroso, aunque no detallado, de los pasos y tareas a seguir para realizar la captura, análisis y especificación de requerimientos software. También allí se observa qué artefacto o documento se obtiene en cada etapa del proceso. En el diagrama no se explicita metodología o modelo a utilizar, sencillamente se pautan las tareas que deben cumplirse, de alguna manera.

Fig. 7 - Diagrama de tareas para captura y análisis de requisitos.

Una posible lista, general y ordenada, de tareas recomendadas para obtener la definición de lo que se debe realizar, los productos a obtener y las técnicas a emplear durante la actividad de elicitación de requisitos, en fase de Especificación de Requisitos Software es:

1. Obtener información sobre el dominio del problema y el sistema actual (UdeD).
2. Preparar y realizar las reuniones para elicitación/negociación.
3. Identificar/revisar los objetivos del usuario.
4. Identificar/revisar los objetivos del sistema.
5. Identificar/revisar los requisitos de información.
6. Identificar/revisar los requisitos funcionales.
7. Identificar/revisar los requisitos no funcionales.
8. Priorizar objetivos y requisitos.

Algunos principios básicos a tener en cuenta:

• Presentar y entender cabalmente el dominio de la información del problema.
• Definir correctamente las funciones que debe realizar el Software.
• Representar el comportamiento del software a consecuencias de acontecimientos externos, particulares, incluso inesperados.
• Reconocer requisitos incompletos, ambiguos o contradictorios.
• Dividir claramente los modelos que representan la información, las funciones y comportamiento y características no funcionales.

Clasificación e identificación de requerimientos

Se pueden identificar dos formas de requisitos:

• Requisitos de usuario: Los requisitos de usuario son frases en lenguaje natural junto a diagramas con los servicios que el sistema debe proporcionar, así como las restricciones bajo las que debe operar.
• Requisitos de sistema: Los requisitos de sistema determinan los servicios del sistema y pero con las restricciones en detalle. Sirven como contrato.

Es decir, ambos son lo mismo, pero con distinto nivel de detalle.

Ejemplo de requisito de usuario: El sistema debe hacer préstamos Ejemplo de requisito de sistema: Función préstamo: entrada código socio, código ejemplar; salida: fecha devolución; etc.

Se clasifican en tres los tipos de requisitos de sistema:

• Requisitos funcionales

Los requisitos funcionales describen:

• Los servicios que proporciona el sistema (funciones).
• La respuesta del sistema ante determinadas entradas.
• El comportamiento del sistema en situaciones particulares.

• Requisitos no funcionales

Los requisitos no funcionales son restricciones de los servicios o funciones que ofrece el sistema (ej. cotas de tiempo, proceso de desarrollo, rendimiento, etc.)

Ejemplo 1. La biblioteca Central debe ser capaz de atender simultáneamente a todas las bibliotecas de la Universidad

Ejemplo 2. El tiempo de respuesta a una consulta remota no debe ser superior a 1/2 s

A su vez, hay tres tipos de requisitos no funcionales:

• Requisitos del producto. Especifican el comportamiento del producto (Ej. prestaciones, memoria, tasa de fallos, etc.)
• Requisitos organizativos. Se derivan de las políticas y procedimientos de las organizaciones de los clientes y desarrolladores (Ej. estándares de proceso, lenguajes de programación, etc.)
• Requisitos externos. Se derivan de factores externos al sistema y al proceso de desarrollo (Ej. requisitos legislativos, éticos, etc.)

• Requisitos del dominio.

Los requisitos del dominio se derivan del dominio de la aplicación y reflejan características de dicho dominio.

Pueden ser funcionales o no funcionales.

Ej. El sistema de biblioteca de la Universidad debe ser capaz de exportar datos mediante el Lenguaje de Intercomunicación de Bibliotecas de España (LIBE). Ej. El sistema de biblioteca no podrá acceder a bibliotecas con material censurado.

Modelo de desarrollo rápido de aplicaciones

El desarrollo rápido de aplicaciones o RAD (Rapid Application Development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE.

Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar

También la usabilidad, utilidad y la rapidez de ejecución. El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos

y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos

cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

•Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?

•Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

•Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.

•Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

•Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Métodos

 Formales

¿Qué es un Método Formal?

Definición: "Método formal es cualquier técnica que trate la construcción y/o el análisis de modelos matemáticos que contribuyen a la automatización del desarrollo de sistemas informáticos"

El papel de los métodos formales en la Ingeniería del Software

Los métodos formales se basan en el empleo de técnicas, lenguajes y herramientas definidos matemáticamente para cumplir objetivos tales como facilitar el análisis y construcción de sistemas confiables independientemente de su complejidad, delatando posibles inconsistencias o ambigüedades que de otra forma podrían pasar inadvertidas.

En los últimos años, la idea de que la formalización matemática del SW es el enfoque más apropiado para conseguir mejorar su calidad va adquiriendo cada vez más fuerza. Los partidarios de los métodos formales defienden que su empleo, a lo largo de todo el ciclo de vida, facilita el desarrollo de especificaciones claras, concisas y no ambiguas, permite el análisis funcional de la especificación y posibilita el desarrollo de implementaciones correctas respecto a su especificación. Sin embargo los detractores aseguran que el empleo de métodos formales supone un volumen de trabajo considerable, aumento en los costes y tiempo de desarrollo y que debe quedar supeditado a herramientas que lo automaticen.

Ventajas de los métodos formales

•Se comprende mejor el sistema.

•La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario.

•El sistema se describe de manera más precisa.

•El sistema se asegura matemáticamente que es correcto según las especificaciones.

•Mayor calidad software respecto al cumplimiento de las especificaciones.

•Mayor productividad

Problemática actual de los métodos formales

La falta de madurez en la práctica de los métodos formales es la causa de la imposibilidad de utilizarlos a nivel industrial tal y como se utilizan otros métodos de la Ingeniería del Software. Algunas de estas causas son las siguientes:

•El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios.

•Los investigadores por lo general no conocen la realidad industrial.

•Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático.

•Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo.

Clasificación de los métodos formales

Se pueden encontrar multitud de métodos y técnicas formales con lo que los criterios de clasificación son bastante variados. La clasificación más común se realiza en base al modelo matemático subyacente en cada método, de esta manera podrían clasificarse en:

•Especificaciones basadas en lógica de primer orden y teoría de conjuntos: permiten especificar el sistema mediante un concepto formal de estados y operaciones sobre estados. Los datos y relaciones/funciones se describen en detalle y sus propiedades se expresan en lógica de primer orden. La semántica de los lenguajes está basada en la teoría de conjuntos. Los métodos de este tipo más conocidos son: Z, VDM y B.

•Especificaciones algebraicas: proponen una descripción de estructuras de datos estableciendo tipos y operaciones sobre esos tipos.

Técnicas de  4ta Generación

Las técnicas de cuarta generación son un conjunto muy diverso de métodos y herramientas que tienen por objeto el de facilitar el desarrollo del software, facilitan al que desarrolla el software la propiedad de especificar algunas características del mismo a alto nivel, mas tarde, la herramienta genera automáticamente el código fuente a partir de esta especificación.

Los tipos más comunes de generadores de código curen uno o varios de los siguientes aspectos:

•Acceso a base de datos: utilizando lenguajes de consulta de alto nivel.

•Generadores de códigos: a partir de una especificación de los requisitos se genera automáticamente toda la aplicación

•Generación de pantallas: permitiendo diseñar la pantalla dibujándola directamente, incluyendo además el control del cursor y la gestión de los errores de los datos de entrada.

•Gestión de entornos gráficos.

•Generación de informes.

Los pasos de los paradigmas son: Recolección de requerimientos, Estrategia de Diseño, Implementación usando T4G y Producto.

Como otros paradigmas, T4G comienza con el paso de recolección de requerimientos. Idealmente el cliente debe describir los requerimientos y estos debe traducirse directamente en un prototipo operacional pero este no funciona. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificación de hechos que son conocidos y puede ser incapaz o no desear especificar la información en la forma que una herramienta T4G puede construirla además las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo serán por algún tiempo en este momento el dialogo cliente técnico descrito por los otros paradigmas permanecen como una pequeña parte esencial del enfoque T4G. Para aplicaciones pequeñas puede ser posible ir directamente desde el paso de establecimiento de requerimientos a la implementación, usando un lenguaje de cuarta generación no procedimental (L4G) sin embargo es necesario un mayor esfuerzo para desarrollar una estrategia del diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin diseño para grandes proyectos causará las mismas dificultades (poca calidad, pobre mantenimiento, mala aceptación por el cliente) que se encuentran cuando se desarrolla software usando los métodos convencionales. La implementación usando L4G facilita el que desarrolla al software la descripción de los resultados deseados, los cuales se traducen automáticamente en código fuente para producir dichos resultados. Obviamente debe existir una estructura de datos con información relevante y debe estar rápidamente accesible al L4G. El último paso de la figura anterior contiene la palabra producto para transformar una implementación T4G en un producto, el que lo desarrollo debe dirigir una prueba completa, desarrollar una documentación con sentido y ejecutar todas las otras actividades de transición requeridas en los otros paradigmas de la ingeniería de software. Además del software desarrollado con T4g, debe ser construido de forma que facilite que el mantenimiento y pueda ser ejecutado de una forma expeditiva. Los defensores aducen reducciones dramáticas en el tiempo de desarrollo en el software y una mejora significativa en la productividad de la gente que construye el software. Los retractores de este paradigma aducen que los lenguajes de programación, que el código fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistema de software desarrollado usando T4g está abierto a discusión.

Entre las críticas más habituales están las siguientes:

•No son más fáciles de utilizar que que los lenguajes de tercera generación.

•El código fuente que produce es ineficiente, al estar generado automáticamente no pueden hacer uso de de los trucos habituales para aumentar el rendimiento, que se basan en el buen conocimiento de cada caso en particular.

•Sólo son aplicables al software de gestión, la mayoría de las herramientas de cuarta generación están orientadas a la generación a partir de grandes bases de datos, pero últimamente están surgiendo herramientas que generan esquemas de códigos para aplicaciones de ingeniería y de tiempo real.

Algunos lenguajes de cuarta generación:

Progress 4GL, o Progress Open Edge como se han llamado sus últimas versiones, es un lenguaje muy utilizado pues es portable y muy confiable. Es una plataforma diseñada para ayudar a los desarrolladores en la construcción de aplicaciones empresariales de forma rápida, esto ayuda a recuperar la inversión de manera más rápida. Tiene la facilidad de fácilmente conectarse e integrarse con clientes, con otras aplicaciones y con distintas bases de datos.

SQL (Structured Query Language): SQL (lenguaje de consultas estructurado) es un lenguaje de acceso a bases de datos relacionales con el cual se pueden crear y manipular las mismas.

WinDev: Permite el desarrollo de interfaz gráfica. Se pueden realizar muchos tipos de aplicaciones, entre ellas: Gestión, industriales, médicas. En WinDev la calidad de las aplicaciones dependen menos del equipo de desarrollo que con otras herramientas, esto debido a que trae un conjunto de funciones avanzadas sin la necesidad de que alguien las programe, por ejemplo, puede ser que el entorno detecte que mejoras para aumentar el rendimiento y la velocidad del sistema y este mismo las sugiere y las realiza automáticamente, además, posee una herramienta generadora de reportes automática.

PowerBuilder: Es un entorno gráfico de programación orientado a objetos para el desarrollo de aplicaciones cliente/servidor, distribuidas y web. Incluye herramientas para generar reportes, acceder bases de datos y para crear interfaz gráfica.

Mathematica: En Mathematica se contemplan muchos de los aspectos técnicos de la computación como el manejo numérico, la conversión de datos, la visualización y la creación de interfaces para el usuario. El avance intelectual que hizo posible el desarrollo de un paquete tan completo fue la invención de un lenguaje que fuera capaz de manipular la gran cantidad de objetos que alberga la computaron técnica. Por su completitud es un paquete que a pesar de inicialmente ser usado por técnicos ha pasado a ser un ambiente manejado por gran cantidad de personas que han aprendido desplegar todas las utilidades que el programa ofrece como por ejemplo los estudiantes a los que les permite aprender de manera interactiva.

Conclusión:

La evolución de los lenguajes tiende cada vez más a alejarnos de la maquina o hardware, creando una mayor abstracción de los problemas a resolver, esto es beneficioso pues genera un ahorro significativo de recursos como el tiempo que es tan valioso actualmente.

Los Lenguajes de Cuarta Generación tienden a ser muy compatibles entre sus mismas evoluciones lo que nos permite crear aplicaciones con la confianza de que el trabajo realizado no será desechado más adelante.

Paquetes tan poderosos como Mathematica hacen posible que las técnicas de computación mejoren constantemente pues brindan una mayor facilidad para el análisis y diseño de nuevas herramientas, mientas también ayudan a áreas tan importantes como la educación, todo esto empleando la misma herramienta.

Es importante resaltar que para utilizar un 4GL se debe tener claro que si se desea manipular para sacarle un mayor rendimiento, se debe de hacer cambiando la forma normal de hacer software. Para esto, los programadores deben de volverse analistas, deben dominar técnicas estructuradas, conceptos de diseño de interfaz grafica, conceptos de arquitectura, conceptos de orientación a objetos y de principios de diseño. Y todo esto para poder obtener una mayor productividad, una mayor facilidad al dar mantenimiento y además una mejor apariencia de la aplicación.