Embed Size (px)
DESCRIPTION
Curso: Ingeniería del Software
Citation preview
INGENIERÍA DEL SOFTWARE
C A P Í T U L O 1 : G E S T I Ó N D E
P R O Y E C T O S D E S O F T W A R E
I S T P - K H I P U
W I L B E R T D A L G U E R R E
O R D Ó Ñ E Z
2 0 1 3 - I
SESIÓN NÚMERO 02
EL PROCESO Conocer el significado del proceso dentro de la Ingeniería.
El Proceso
1
Contenido
EL PROCESO ................................................................................................ 3
INGENIERÍA DEL SOFTWARE: UNA TECNOLOGÍA ESTRATIFICADA ....................................... 3
PROCESO, MÉTODOS Y HERRAMIENTAS .............................................................................. 4
UNA VISIÓN GENERAL DE LA INGENIERÍA DEL SOFTWARE .................................................. 5
La fase de definición se centra sobre el qué. ....................................................................... 5
La fase de desarrollo se centra en el cómo. ......................................................................... 6
La fase de mantenimiento .................................................................................................... 6
EL PROCESO DEL SOFTWARE ................................................................................................ 7
Nivel 1: .................................................................................................................................. 8
Nivel 2: .................................................................................................................................. 8
Nivel 3: .................................................................................................................................. 8
Nivel 4: .................................................................................................................................. 8
Nivel 5: .................................................................................................................................. 9
MODELOS DEL PROCESO DE SOFTWARE ............................................................................ 10
1. EL MODELO LINEAL SECUENCIAL .................................................................................... 11
2. EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS ......................................................... 13
3. EL MODELO DRA ............................................................................................................. 15
MODELOS EVOLUTIVOS DE PROCESO DEL SOFTWARE ...................................................... 17
1. El modelo lineal secuencial se diseña para el desarrollo en línea recta. ....................... 18
2. El modelo incremental ................................................................................................... 18
3. El modelo espiral ............................................................................................................ 19
4. El modelo espiral WINWIN ............................................................................................. 22
5. El modelo de desarrollo concurrente ............................................................................. 23
El Proceso
2
DEASARROLLO BASADO EN COMPONENTES ..................................................................... 25
EL MODELO DE MÉTODOS FORMALES ............................................................................... 27
TÉCNICAS DE CUARTA GENERACIÓN .................................................................................. 28
TÉCNOLOGÍAS DE PROCESO ............................................................................................... 31
PRODUCTO Y PROCESO ...................................................................................................... 31
BIBLIOGRAFÍA ................................................................................................................ 34
El Proceso
3
EL PROCESO
Pero, ¿qué es exactamente el
proceso del software
desde un punto de vista
técnico?, definimos un
proceso de software como
un marco de trabajo de las
tareas que se requieren para
construir software de alta
calidad. ¿Es «proceso»
sinónimo de ingeniería del software? La
respuesta es «sí» y «no». Un proceso de software define el
enfoque que se toma cuando el software es tratado por la ingeniería. Pero la
ingeniería del software también comprende las tecnologías que tiene el
proceso (métodos técnicos y herramientas automatizadas). Aún más
importante es que la ingeniería del software la realizan personas creativas,
con conocimiento, que deberían trabajar dentro de un proceso del software
definido y avanzado que es apropiado para los productos que construyen y
para las demandas de su mercado.
INGENIERÍA DEL SOFTWARE: UNA TECNOLOGÍA ESTRATIFICADA
Aunque cientos de autores han desarrollado definiciones personales
de la ingeniería del software, una definición propuesta por Fritz Bauer
en una conferencia de gran influencia sobre estos temas va a servir
como base de estudio: La ingeniería del software es el
establecimiento y uso de principios robustos de la ingeniería a fin de
obtener económicamente software que sea fiable y que funcione
eficientemente sobre máquinas reales.
Casi todos tendrán la tentación de seguir esta definición. No dice
mucho sobre los aspectos técnicos de la calidad del software; no se
enfrenta directamente con la necesidad de la satisfacción del cliente o
de la entrega oportuna del producto; omite la mención de la
importancia de mediciones y métricas; tampoco expresa la
importancia de un proceso avanzado. Y sin embargo, la definición de
Bauer nos proporciona una línea base. ¿Cuáles son los «principios
El Proceso
4
robustos de la ingeniería» aplicables al desarrollo de software de
computadora? ¿Cómo construimos el software «económicamente»
para que sea «fiable»? ¿Qué se necesita para crear programas de
computadora que funcionen «eficientemente» no en una máquina si
no en diferentes «máquinas reales»? Éstas son cuestiones que
siguen siendo un reto para los ingenieros del software.
Existe una definición más completa: Ingeniería del software: La
aplicación de un enfoque sistemático, disciplinado y cuantificable
hacia el desarrollo, operación y mantenimiento del software; es decir,
la aplicación de ingeniería al software.
PROCESO, MÉTODOS Y HERRAMIENTAS
La Ingeniería del software es una tecnología multicapa, cualquier
enfoque de ingeniería (incluida ingeniería del software) debe apoyarse
sobre un compromiso de organización de calidad. El fundamento de la
ingeniería del software es la capa de proceso. El proceso de la
ingeniería del software es la unión que mantiene juntas las capas de
tecnología y que permite un desarrollo racional y oportuno de la
ingeniería del software. El proceso define un marco de trabajo para un
conjunto de Áreas clave de proceso (ACPs) que se deben establecer
para la entrega efectiva de la tecnología de la ingeniería del software.
Las áreas claves del proceso forman la base del control de gestión de
proyectos del software y establecen el contexto en el que se aplican
los métodos técnicos, se obtienen productos del trabajo (modelos,
documentos, datos, informes, formularios, etc.), se establecen hitos,
se asegura la calidad y el cambio se gestiona adecuadamente.
Los métodos de la ingeniería del software indican «cómo» construir
técnicamente el software. Los métodos abarcan una gran gama de
tareas que incluyen análisis de requisitos, diseño, construcción de
programas, pruebas y mantenimiento. Los métodos de la ingeniería
del software dependen de un conjunto de principios básicos que
gobiernan cada área de la tecnología e incluyen actividades de
modelado y otras técnicas descriptivas Las herramientas de la
Ingeniería del software proporcionan un enfoque automático o semi-
automático para el proceso y para los métodos. Cuando se integran
herramientas para que la información creada por una herramienta la
pueda utilizar otra, se establece un sistema de soporte para el
El Proceso
5
desarrollo del software llamado ingeniería del software asistida por
computadora (CASE).
UNA VISIÓN GENERAL DE LA INGENIERÍA DEL SOFTWARE
La ingeniería es el análisis, diseño, construcción, verificación y
gestión de entidades técnicas (o sociales). Con independencia de la
entidad a la que se va a aplicar ingeniería, se deben cuestionar y
responder las siguientes preguntas:
¿Cuál es el problema a resolver? ¿Cuáles son las características de
la entidad que se utiliza para resolver el problema? ¿Cómo se
realizará la entidad (y la solución)? ¿Cómo se construirá la entidad?
¿Qué enfoque se va a utilizar para no contemplar los errores que se
cometieron en el diseño y en la construcción de la entidad? ¿Cómo
se apoyará la entidad cuando usuarios soliciten correcciones,
adaptaciones y mejoras de la entidad?
Nos vamos a centrar en una sola entidad (el software de
computadora). Para construir la ingeniería del software
adecuadamente, se debe definir un proceso de desarrollo de
software. En esta sección se consideran las características genéricas
del proceso de software. Más adelante, se tratarán modelos
específicos de procesos. El trabajo que se asocia a la ingeniería del
software se puede dividir en tres fases genéricas, con independencia
del área de aplicación, tamaño o complejidad del proyecto. Cada fase
se encuentra con una o varias cuestiones de las destacadas
anteriormente.
La fase de definición se centra sobre el qué.
Es decir, durante la definición, el que desarrolla el software intenta
identificar qué información ha de ser procesada, qué función y
rendimiento se desea, qué comportamiento del sistema, qué
interfaces van a ser establecidas, qué restricciones de diseño existen,
y qué criterios de validación se necesitan para definir un sistema
correcto. Por tanto, han de identificarse los requisitos clave del
sistema y del software. Aunque los métodos aplicados durante la fase
de definición variarán dependiendo del paradigma de ingeniería del
El Proceso
6
software (o combinación de paradigmas) que se aplique, de alguna
manera tendrán lugar tres tareas principales: ingeniería de sistemas o
de información, planificación del proyecto del software y análisis de
los requisitos.
La fase de desarrollo se centra en el cómo.
Es decir, durante el desarrollo un ingeniero del software intenta definir
cómo han de diseñarse las estructuras de datos, cómo ha de
implementarse la función dentro de una arquitectura de software,
cómo han de implementarse los detalles procedimentales, cómo han
de caracterizarse interfaces, cómo ha de traducirse el diseño en un
lenguaje de programación (o lenguaje no procedimental) y cómo ha
de realizarse la prueba. Los métodos aplicados durante la fase de
desarrollo variarán, aunque las tres tareas específicas técnicas
deberían ocurrir siempre: diseño del software, generación de código y
prueba del software.
La fase de mantenimiento
Se centra en el cambio que va asociado a la corrección de errores, a
las adaptaciones requeridas a medida que evoluciona el entorno del
software y a cambios debidos a las mejoras producidas por los
requisitos cambiantes del cliente.
Durante la fase de mantenimiento se encuentran cuatro tipos de
cambios:
Corrección. Incluso llevando a cabo las mejores actividades de
garantía de calidad, es muy probable que el cliente descubra los
defectos en el software. El mantenimiento correctivo cambia el
software para corregir los defectos.
Adaptación. Con el paso del tiempo, es probable que cambie el
entorno original (por ejemplo: CPU, el sistema operativo, las reglas de
empresa, las características externas de productos) para el que se
desarrolló el software. El mantenimiento adaptativo produce
modificación en el software para acomodarlo a los cambios de su
entorno externo.
El Proceso
7
Mejora. Conforme se utilice el software, el cliente/ usuario puede
descubrir funciones adicionales que van a producir beneficios. El
mantenimiento perfectivo lleva al software más allá de sus requisitos
funcionales originales.
Prevención. El software de computadora se deteriora debido al
cambio, y por esto el mantenimiento preventivo también llamado
reingeniería del software, se debe conducir a permitir que el software
sirva para las necesidades de los usuarios finales. En esencia, el
mantenimiento preventivo hace cambios en programas de
computadora a fin de que se puedan corregir, adaptar y mejorar más
fácilmente.
EL PROCESO DEL SOFTWARE
Un proceso de software establece un marco común del proceso
definiendo un pequeño número de actividades del marco de trabajo
que son aplicables a todos los proyectos del software, con
independencia de su tamaño o complejidad. Un número de conjuntos
de tareas (cada uno es una colección de tareas de trabajo de
ingeniería del software, hitos de proyectos, productos de trabajo, y
puntos de garantía de calidad) que permiten que las actividades del
marco de trabajo se adapten a las características del proyecto del
software y a los requisitos del equipo del proyecto. Finalmente, las
actividades de protección (tales como garantía de calidad del
software, gestión de configuración del software y medición, abarcan el
modelo de procesos). Las actividades de protección son
independientes de cualquier actividad del marco de trabajo y
aparecen durante todo el proceso. En los Últimos años, se ha hecho
mucho énfasis en la «madurez del proceso>>. El Software Enginierin
Institute (SEI) ha desarrollado un modelo completo que se basa en un
conjunto de funciones de ingeniería del software que deberían estar
presentes conforme organizaciones alcanzan diferentes niveles de
madurez del proceso. Para determinar el estado actual de madurez
del proceso de una organización, el SEI utiliza un cuestionario de
evaluación y un esquema de cinco grados. El esquema de grados
determina la conformidad con un modelo de capacidad de madurez
que define las actividades clave que se requieren en los diferentes
niveles de madurez del proceso.
El Proceso
8
El enfoque del SEI proporciona una medida de la efectividad global de
las prácticas de ingeniería del software de una compañía y establece
cinco niveles de madurez del proceso, que se definen de la forma
siguiente:
Nivel 1:
Inicial. El proceso del software se caracteriza según el caso, y
ocasionalmente incluso de forma caótica. Se definen pocos procesos,
y el éxito depende del esfuerzo individual.
Nivel 2:
Repetible. Se establecen los procesos de gestión del proyecto para
hacer seguimiento del coste, de la planificación y de la funcionalidad.
Para repetir éxitos anteriores en proyectos con aplicaciones similares
se aplica la disciplina necesaria para el proceso.
Nivel 3:
Definido. El proceso del software de las actividades de gestión y de
ingeniería se documenta, se estandariza y se integra dentro de un
proceso de software de toda una organización. Todos los proyectos
utilizan una versión documentada y aprobada del proceso de la
organización para el desarrollo y mantenimiento del software. En este
nivel se incluyen todas las características definidas para el nivel 2.
Nivel 4:
Gestionado. Se recopilan medidas detalladas del proceso del software
y de la calidad del producto. Mediante la utilización de medidas
detalladas, se comprenden y se controlan cuantitativamente tanto los
productos como el proceso del software. En este nivel se incluyen
todas las características definidas para el nivel 3.
El Proceso
9
Nivel 5:
Optimización. Mediante una retroalimentación cuantitativa del
proceso, ideas y tecnologías innovadoras se posibilita una mejora del
proceso. En este nivel se incluyen todas las características definidas
para el nivel 4.
Merece la pena destacar que cada nivel superior es la suma de los
niveles anteriores, por ejemplo, un desarrollador de software en el
nivel 3 tiene que haber alcanzado el estado nivel 2 para poder
disponer de sus procesos en el nivel 3. El nivel 1 representa una
situación sin ningún esfuerzo en la garantía de calidad y gestión del
proyecto, donde cada equipo del proyecto puede
desarrollar software de cualquier forma eligiendo los
métodos, estándares y procedimientos a utilizar que
podrán variar desde lo mejor hasta lo peor. El nivel 2
representa el hecho de que un desarrollador de
software ha definido ciertas actividades tales como el
informe del esfuerzo y del tiempo empleado, y el
informe de las tareas realizadas. El nivel 3 representa
el hecho de que un desarrollador de software ha
definido tanto procesos técnicos como de gestión, por
ejemplo un estándar para la programación ha sido
detallado y se hace cumplir por medio de
procedimientos tales como auditorías. Este nivel es
aquel en el que la mayoría de los desarrolladores de
software, pretenden conseguir con estándares como
el ISO 9001, y existen pocos casos de desarrolladores
de software que superan este nivel. El nivel 4
comprende el concepto de medición y el uso de
métricas. Sin embargo, cabe destacar el concepto de
métrica para comprender la importancia que tiene que
el desarrollador del software alcance el nivel 4 o el nivel 5.
Un ejemplo de métrica es el número de ramas condicionales en una
sección de código de un programa. Esta métrica es significativa en el
sentido de que proporciona alguna indicación del esfuerzo necesario
para probar el código: está directamente relacionado con el número
de caminos de prueba dentro del código.
Una métrica es una
cantidad
insignificante que
puede extraerse de
algún documento o
código dentro de
un proyecto de
software.
El Proceso
10
Una organización del nivel 4 maneja numerosas métricas. Estas
métricas se utilizan entonces para supervisar y controlar un proyecto
de software, por ejemplo: Una métrica de prueba puede usarse para
determinar cuándo finalizar la prueba de un elemento del código. Una
métrica de legibilidad puede usarse para juzgar la legibilidad de algún
documento en lenguaje natural. Una métrica de comprensión del
programa puede utilizarse para proporcionar algún umbral numérico
que los programadores no pueden cruzar. Para que estas métricas
alcancen este nivel es necesario que todos los componentes del nivel
3 CMM, en castellano MCM (Modelo de Capacidad de Madurez),
estén conseguidos, por ejemplo notaciones bien definidas para
actividades como la especificación del diseño de requisitos, por lo que
estas métricas pueden ser fácilmente extraídas de modo automático.
El nivel 5 es el nivel más alto a alcanzar. Hasta ahora, muy pocos
desarrolladores de software han alcanzado esta fase. Representa la
analogía del software con los mecanismos de control de calidad que
existen en otras industrias de mayor madurez. Por ejemplo el
fabricante de un producto industrial como un cojinete de bolas
(rodamiento) puede supervisar y controlar la calidad de los
rodamientos producidos y puede predecir esta calidad basándose en
los procesos y máquinas utilizados para desarrollar los rodamientos.
Del mismo modo que el desarrollador del software en el nivel 5 puede
predecir resultados como el número de errores latentes en un
producto basado en la medición tomada durante la ejecución de un
proyecto. Además, dicho desarrollador puede cuantificar el efecto que
un proceso nuevo o herramienta de manufacturación ha tenido en un
proyecto examinando métricas para ese proyecto y comparándolas
con proyectos anteriores que no utilizaron ese proceso o herramienta
En este orden debe destacarse que para que un desarrollador de
software alcance el nivel 5 tiene que tener cada proceso definido
rigurosamente y seguirlo al pie de la letra; esto es una consecuencia
de estar en el nivel 3. Si el desarrollador del software no tiene
definidos rigurosamente los procesos pueden ocurrir una gran
cantidad de cambios en el proceso de desarrollo y no se podrán
utilizar las estadísticas para estas actividades.
MODELOS DEL PROCESO DE SOFTWARE
El Proceso
11
Para resolver los problemas reales de una industria, un ingeniero del
software o un equipo de ingenieros deben incorporar una estrategia
de desarrollo que acompañe al proceso, métodos y capas de
herramientas y las fases genéricas discutidas en una Sección
anterior. Esta estrategia a menudo se llama modelo de proceso o
paradigma de ingeniería del software. Se selecciona un modelo de
proceso para la ingeniería del software según la naturaleza del
proyecto y de la aplicación, los métodos y las herramientas a
utilizarse, y los controles y entregas que se requieren.
En un documento intrigante sobre la naturaleza
del proceso del software, L.B.S. Raccoon utiliza
fractales como base de estudio de la verdadera
naturaleza del proceso del software.
1. EL MODELO LINEAL SECUENCIAL
Llamado algunas veces «ciclo de vida básico» o
modelo en cascada», el modelo lineal secuencial sugiere un enfoque5
sistemático, secuencial, para el desarrollo del software que comienza
en un nivel de sistemas y progresa con el análisis, diseño,
codificación, pruebas y mantenimiento. La Figura muestra el modelo
lineal secuencial para la ingeniería del software. Modelado según el
ciclo de ingeniería convencional, el modelo lineal secuencial
comprende las siguientes actividades:
Ingeniería y modelado de Sistemas/Información. Como el software
siempre forma parte de un sistema más grande (o empresa), el
trabajo comienza estableciendo requisitos de todos los elementos del
sistema y asignando al software algún subgrupo de estos requisitos.
Esta visión del sistema es esencial cuando el software se debe
interconectar con otros elementos como hardware, personas y bases
de datos. La ingeniería y el análisis de sistemas comprenden los
requisitos que se recogen en el nivel del sistema con una pequeña
parte de análisis y de diseño. La ingeniería de información abarca los
requisitos que se recogen en el nivel de empresa estratégico y en el
nivel del área de negocio.
Un fractal es un
objeto geométrico
cuya estructura
básica, fragmentada o
irregular, se repite a
diferentes escalas.
El Proceso
12
FIGURA. El modelo lineal secuencial.
Análisis de los requisitos del software. El proceso de reunión de
requisitos se intensifica y se centra especialmente en el software.
Para comprender la naturaleza del (los) programa(s) a construirse, el
ingeniero («analista ») del software debe comprender el dominio de
información del software, así como la función requerida,
comportamiento, rendimiento e interconexión.
Diseño. El diseño del software es realmente un proceso de muchos
pasos que se centra en cuatro atributos distintos de programa:
estructura de datos, arquitectura de software, representaciones de
interfaz y detalle procedimental (algoritmo). El proceso del diseño
traduce requisitos en una representación del software donde se pueda
evaluar su calidad antes de que comience la codificación.
Generación de código. El diseño se debe traducir en una forma
legible por la máquina. El paso de generación de código lleva a cabo
esta tarea. Si se lleva a cabo el diseño de una forma detallada, la
generación de código se realiza mecánicamente.
Pruebas. Una vez que se ha generado el código, comienzan las
pruebas del programa. El proceso de pruebas se centra en los
procesos lógicos internos del software, asegurando que todas las
sentencias se han comprobado, y en los procesos externos
funcionales; es decir, realizar las pruebas para la detección de errores
y asegurar que la entrada definida produce resultados reales de
acuerdo con los resultados requeridos.
El Proceso
13
Mantenimiento. El software indudablemente sufrirá cambios después
de ser entregado al cliente (una excepción posible es el software
empotrado). Se producirán cambios porque se han encontrado
errores, porque el software debe adaptarse para acoplarse a los
cambios de su entorno externo (por ejemplo: se requiere un cambio
debido a un sistema operativo o dispositivo periférico nuevo), o
porque el cliente requiere mejoras funcionales o de rendimiento. El
soporte y mantenimiento del software vuelve a aplicar cada una de las
fases precedentes a un programa ya existente y no a uno nuevo. El
modelo lineal secuencial es el paradigma más antiguo y más
extensamente utilizado en la ingeniería del software. Sin embargo, la
crítica del paradigma ha puesto en duda su eficacia.
Entre los problemas que se encuentran algunas veces en el modelo
lineal secuencial se incluyen:
1. ¿Por qué falla algunas veces el modelo lineal?
Los proyectos reales raras veces siguen el modelo secuencial que
propone el modelo. Aunque el modelo lineal puede acoplar
interacción, lo hace indirectamente. Como resultado, los cambios
pueden causar confusión cuando el equipo del proyecto comienza.
2. A menudo es difícil que el cliente exponga explícitamente todos los
requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a
la hora de acomodar la incertidumbre natural al comienzo de muchos
proyectos. El cliente debe tener paciencia. Una versión de trabajo del
(los) programa(s) no estará disponible hasta que el proyecto esté muy
avanzado. Un grave error puede ser desastroso si no se detecta hasta
que se revisa el programa.
2. EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS
El modelo lineal no identifica los requisitos detallados de entrada,
proceso o salida. En otros casos, el responsable del desarrollo del
software puede no estar seguro de la eficacia de un algoritmo, de la
capacidad de adaptación de un sistema operativo, o de la forma en
que debería tomarse la interacción hombre máquina. En estas y en
otras muchas situaciones, un paradigma de construcción de
prototipos puede ofrecer el mejor enfoque. El paradigma de
construcción de prototipos comienza con la recolección de requisitos.
El Proceso
14
El desarrollador y el cliente encuentran y definen los objetivos
globales para el software, identifican los requisitos conocidos y las
áreas del esquema en donde es obligatoria más definición. Entonces
aparece un «diseño rápido». El diseño rápido se centra en una
representación de esos aspectos del software que serán visibles para
el usuario/cliente (por ejemplo: enfoques de entrada y formatos de
salida). El diseño rápido lleva a la construcción de un prototipo. El
prototipo lo evalúa el cliente/usuario y se utiliza para refinar los
requisitos del software a desarrollar. La iteración ocurre cuando el
prototipo se pone a punto para satisfacer las necesidades del cliente,
permitiendo al mismo tiempo que el desarrollador comprenda mejor lo
que se necesita hacer. Lo ideal sería que el prototipo sirviera como un
mecanismo para identificar los requisitos del software. Si se construye
un prototipo de trabajo, el desarrollador intenta hacer uso de los
fragmentos del programa ya existentes o aplica herramientas (por
ejemplo: generadores de informes, gestores de ventanas, etc.) que
permiten generar rápidamente programas de trabajo. Pero ¿qué
hacemos con el prototipo una vez que ha servido para el propósito
descrito anteriormente? Brooks proporciona una respuesta: En la
mayoría de los proyectos, el primer sistema construido apenas se
puede utilizar. Puede ser demasiado lento, demasiado grande o torpe
en su uso, o las tres a la vez. No hay otra alternativa que comenzar
de nuevo, aunque nos duela pero es más inteligente, y construir una
versión rediseñada en la que se resuelvan estos problemas. Cuando
se utiliza un concepto nuevo de sistema o una tecnología nueva, se
tiene que construir un sistema que no sirva y se tenga que tirar,
porque incluso la mejor planificación no es omnisciente como para
que esté perfecta la primera vez. Por lo tanto la pregunta de la gestión
no es si construir un sistema piloto y tirarlo. Tendremos que hacerlo.
La única pregunta es si planificar de antemano construir un
desechable, o prometer entregárselo a los clientes.
El prototipo puede servir como «primer sistema». El que Brooks
recomienda tirar. Aunque esta puede ser una visión idealizada. Es
verdad que a los clientes y a los que desarrollan les gusta el
paradigma de construcción de prototipos. A los usuarios les gusta el
sistema real y a los que desarrollan les gusta construir algo
inmediatamente.
Sin embargo, la construcción de prototipos también puede ser
problemática por las siguientes razones:
El Proceso
15
El cliente ve lo que parece ser una versión de trabajo del software,
sin tener conocimiento de que el prototipo también está junto con
«el chicle y el cable de embalar», sin saber que con la prisa de
hacer que funcione no se ha tenido en cuenta la calidad del
software global o la facilidad de mantenimiento a largo plazo.
Cuando se informa de que el producto se debe construir otra vez
para que se puedan mantener los niveles altos de calidad, el
cliente no lo entiende y pide que se apliquen unos pequeños
ajustes>> para que se pueda hacer del prototipo un producto final.
De forma demasiado frecuente la gestión de desarrollo del
software es muy lenta.
El desarrollador, a menudo, hace compromisos de implementación
para hacer que el prototipo funcione rápidamente. Se puede
utilizar un sistema operativo o lenguaje de programación
inadecuado simplemente porque está disponible y porque es
conocido; un algoritmo eficiente se puede implementar
simplemente para demostrar la capacidad. Después de algún
tiempo, el desarrollador debe familiarizarse con estas selecciones,
y olvidarse de las razones por las que son inadecuadas. La
selección menos ideal ahora es una parte integral del sistema.
Aunque pueden surgir problemas, la construcción de prototipos puede
ser un paradigma efectivo para la ingeniería del software. La clave es
definir las reglas del juego al comienzo; es decir, el cliente y el
desarrollador se deben poner de acuerdo en que el prototipo se
construya para servir como un mecanismo de definición de requisitos.
3. EL MODELO DRA
El Desarrollo Rápido de Aplicaciones (DRA), es un modelo de
proceso del desarrollo del software lineal secuencial que enfatiza un
ciclo de desarrollo extremadamente corto. El modelo DRA es una
adaptación a «alta velocidad» del modelo lineal secuencial en el que
se logra el desarrollo rápido utilizando una construcción basada 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 períodos
cortos de tiempo (por ejemplo: de 60 a 90 días). Cuando se utiliza
El Proceso
16
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
procesa?
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 del 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.
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 para facilitar la
construcción del software.
Pruebas y 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. Obviamente, las limitaciones de tiempo impuestas en un
proyecto DRA demandan «ámbito en escalas». Si una aplicación de
gestión puede modularse de forma que permita completarse cada una
de las funciones principales en menos de tres meses (utilizando el
enfoque descrito anteriormente), es un candidato del DRA. Cada una
de las funciones pueden ser afrontadas por un equipo DRA separado
y ser integradas en un solo conjunto.
El Proceso
17
Al igual que todos los modelos de proceso, el enfoque DRA tiene
inconvenientes:
Para proyectos grandes aunque por escalas, el DRA requiere
recursos humanos suficientes como para crear el número
correcto de equipos DRA. DRA requiere clientes y
desarrolladores comprometidos en las rápidas actividades
necesarias para completar un sistema en un marco de tiempo
abreviado. Si no hay compromiso por ninguna de las partes
constituyentes, los proyectos DRA fracasarán. No todos los
tipos de aplicaciones son apropiados para DRA. Si un sistema
no se puede modularizar adecuadamente, la construcción de
los componentes necesarios para DRA será problemático. Si
está en juego el alto rendimiento, y se va a conseguir el
rendimiento convirtiendo interfaces en componentes de
sistemas, el enfoque DRA puede que no funcione.
DRA no es adecuado cuando los riesgos técnicos son altos.
Esto ocurre cuando una nueva aplicación hace uso de
tecnologías nuevas, o cuando el software nuevo requiere un
alto grado de inter-operatividad con programas de
computadora ya existentes.
MODELOS EVOLUTIVOS DE PROCESO DEL SOFTWARE
Se reconoce que el software, al igual que todos los sistemas
complejos, evoluciona con el tiempo. Los requisitos de gestión y de
productos a menudo cambian conforme a que el desarrollo proceda
haciendo que el camino que lleva al producto final no sea real; las
estrictas fechas tope del mercado hacen que sea imposible finalizar
un producto completo, por lo que se debe introducir una versión
limitada para cumplir la presión competitiva y de gestión; se
comprende perfectamente el conjunto de requisitos de productos
centrales o del sistema, pero todavía se tienen que definir los detalles
de extensiones del producto o sistema. En estas y en otras
situaciones similares, los ingenieros del software necesitan un modelo
de proceso que se ha diseñado explícitamente para acomodarse a un
producto que evolucione con el tiempo.
El Proceso
18
1. El modelo lineal secuencial se diseña para el desarrollo en línea
recta.
En esencia, este enfoque en cascada asume que se va entregar un
sistema completo una vez que la secuencia lineal se haya finalizado.
El modelo de construcción de prototipos se diseña para ayudar al
cliente (o al que desarrolla) a comprender los requisitos. En general,
no se diseña para entregar un sistema de producción. En ninguno de
los paradigmas de ingeniería del software se tiene en cuenta la
naturaleza evolutiva del software.
Los modelos evolutivos son iterativos. Se caracterizan por la forma en
que permiten a los ingenieros del software desarrollar versiones cada
vez más completas del software.
2. El modelo incremental
El modelo incremental combina elementos del modelo lineal
secuencial (aplicados repetidamente) con la filosofía interactiva de
construcción de prototipos. Como muestra la figura en la parte inferior,
el modelo incremental aplica secuencias
lineales de forma escalonada mientras
progresa el tiempo en el calendario. Cada
secuencia lineal produce un «incremento»
del software. Por ejemplo, el software de
tratamiento de textos desarrollado con el
paradigma incremental podría extraer
funciones de gestión de archivos básicos y
de producción de documentos en el primer
incremento; funciones de edición más
sofisticadas y de producción de
documentos en el segundo incremento;
corrección ortográfica y gramatical en el
tercero; y una función avanzada de
esquema de página en el cuarto. Se debería tener en cuenta que el
flujo del proceso de cualquier incremento puede incorporar el
paradigma de construcción de prototipos.
Cuando se utiliza un modelo incremental, el primer incremento a
menudo es un producto esencial. Es decir, se afrontan requisitos
Programación basada en prototipos
es un estilo de programación
orientada a objetos en el cual, las
"clases" no están presentes, y la re-
utilización de procesos (conocida
como herencia en lenguajes
basados en clases) se obtiene a
través de la clonación de objetos ya
existentes, que sirven de
prototipos, extendiendo sus
funcionalidades.
El Proceso
19
básicos, pero muchas funciones suplementarias (algunas conocidas,
otras no) quedan sin extraer. El cliente utiliza el producto central (o
sufre la revisión detallada). Como un resultado de utilización y/o de
evaluación, se desarrolla un plan para el incremento siguiente. El plan
afronta la modificación del producto central a fin de cumplir mejor las
necesidades del cliente y la entrega de funciones, y características
adicionales. Este proceso se repite siguiendo la entrega de cada
incremento, hasta que se elabore el producto completo.
El modelo de proceso incremental, como la construcción de prototipos
y otros enfoques evolutivos, es iterativo por naturaleza. Pero a
diferencia de la construcción de prototipos, el modelo incremental se
centra en la entrega de un producto operacional con cada incremento.
Los primeros incrementos son versiones «incompletas» del producto
final, pero proporcionan al usuario la funcionalidad que precisa y
también una plataforma para la evaluación.
El desarrollo incremental es particularmente útil cuando la dotación de
personal no está disponible para una implementación completa en la
fecha límite que se haya establecido para el proyecto. Los primeros
incrementos se pueden implementar con menos personas.
3. El modelo espiral
El modelo en espiral, propuesto originalmente por Boehm, es un
modelo de proceso de software evolutivo que conjuga la naturaleza
iterativa de construcción de prototipos con los aspectos controlados y
sistemáticos del modelo lineal secuencial. Proporciona el potencial
para el desarrollo rápido de versiones incrementales del software. En
El Proceso
20
el modelo espiral, el software se desarrolla en una serie de versiones
incrementales. Durante las primeras iteracciones, la versión
incremental podría ser un modelo en papel o un prototipo. Durante las
últimas iteraciones, se producen versiones cada vez más completas
del sistema diseñado.
El modelo en espiral se divide en un número de actividades de marco
de trabajo, también llamadas regiones de tareas. Generalmente,
existen entre tres y seis regiones de tareas. La Figura anterior
representa un modelo en espiral que contiene seis regiones de tareas:
comunicación con el cliente- las tareas requeridas para
establecer comunicación entre el desarrollador y el cliente.
planificación- las tareas requeridas para definir recursos, el
tiempo y otra información relacionadas con el proyecto.
análisis de riesgos- las tareas requeridas para evaluar riesgos
técnicos y de gestión.
ingeniería- las tareas requeridas para construir una o más
representaciones de la aplicación.
construcción y acción- las tareas requeridas para construir,
probar, instalar y proporcionar soporte al usuario (por ejemplo:
documentación y práctica)
evaluación del cliente- las tareas requeridas para obtener la
reacción del cliente según la evaluación de las
representaciones del software creadas durante la etapa de
ingeniería e implementada durante la etapa de instalación.
Cada una de las regiones están compuestas por un conjunto de
tareas del trabajo, llamado conjunto de tareas, que se adaptan a las
características del proyecto que va a emprenderse. Para proyectos
pequeños, el número de tareas de trabajo y su formalidad es bajo.
El Proceso
21
Para proyectos mayores y más críticos cada región de tareas contiene
tareas de trabajo que se definen para lograr un nivel más alto de
formalidad. En todos los casos, se aplican las actividades de
protección (por ejemplo: gestión de configuración del software y
garantía de calidad del software). Cuando empieza este proceso
evolutivo, el equipo de ingeniería del software gira alrededor de la
espiral en la dirección de las agujas del reloj, comenzando por el
centro. El primer circuito de la espiral puede producir el desarrollo de
una especificación de productos; los pasos siguientes en la espiral se
podrían utilizar para desarrollar un prototipo y progresivamente
versiones más sofisticadas del software. Cada paso por la región de
planificación produce ajustes en el plan del proyecto. El coste y la
planificación se ajustan con la realimentación ante la evaluación del
cliente. Además, el gestor del proyecto ajusta el número planificado
de iteraciones requeridas para completar el software.
A diferencia del modelo de proceso clásico que termina cuando se
entrega el software, el modelo en espiral puede adaptarse y aplicarse
a lo largo de la vida del software de computadora. Una visión
alternativa del modelo en espiral puede ser considerada examinando
el eje de punto de entrada en el proyecto también reflejado en la
Figura anterior. Cada uno de los cubos situados a lo largo del eje
pueden usarse para representar el punto de arranque para diferentes
tipos de proyectos. Un «proyecto de desarrollo de conceptos»
comienza en el centro de la espiral y continuará (aparecen múltiples
iteraciones a lo largo de la espiral que limita la región sombreada
central) hasta que se completa el desarrollo del concepto. Si el
concepto se va a desarrollar dentro de un producto real, el proceso
continúa a través del cubo siguiente (punto de entrada del proyecto de
desarrollo del producto nuevo) y se inicia un «nuevo proyecto de
desarrollo”. El producto nuevo evolucionará a través de iteraciones
alrededor de la espiral siguiendo el camino que limita la región algo
más brillante que el centro. En esencia, la espiral, cuando se
caracteriza de esta forma, permanece operativa hasta que el
software se retira. Hay veces en que el proceso está inactivo, pero
siempre que se inicie un cambio, el proceso arranca en el punto de
entrada adecuado (por ejemplo: mejora del producto). El modelo en
espiral es un enfoque realista del desarrollo de sistemas y de software
a gran escala. Como el software evoluciona, a medida que progresa
el proceso el desarrollador y el cliente comprenden y reaccionan
mejor ante riesgos en cada uno de los niveles evolutivos. El modelo
en espiral utiliza la construcción de prototipos como mecanismo de
El Proceso
22
reducción de riesgos, pero, lo que es más importante, permite a quien
lo desarrolla aplicar el enfoque de construcción de prototipos en
cualquier etapa de evolución del producto. Mantiene el enfoque
sistemático de los pasos sugeridos por el ciclo de vida clásico, pero lo
incorpora al marco de trabajo iterativo que refleja de forma más
realista el mundo real.
El modelo en espiral demanda una consideración directa de los
riesgos técnicos en todas las etapas del proyecto, y, si se aplica
adecuadamente, debe reducir los riesgos antes de que se conviertan
en problemáticos.
4. El modelo espiral WINWIN
El modelo en espiral sugiere una actividad del marco de trabajo que
aborda la comunicación con el cliente. El objetivo de esta actividad es
mostrar los requisitos del cliente. En un contexto ideal, el
desarrollador simplemente pregunta al cliente lo que se necesita y el
cliente proporciona detalles suficientes para continuar.
Desgraciadamente, esto raramente ocurre. En realidad el cliente y el
desarrollador entran en un proceso de negociación, donde el cliente
puede ser preguntado para sopesar la funcionalidad, rendimiento, y
otros productos o características del sistema frente al coste y al
tiempo de comercialización. Las mejores negociaciones se esfuerzan
en obtener «victoria-victoria». Esto es, el cliente gana obteniendo el
producto o sistema que satisface la mayor parte de sus necesidades
y el desarrollador gana trabajando para conseguir presupuestos y
lograr una fecha de entrega realista. El modelo en espiral WINWIN de
Boehm define un conjunto de actividades de negociación al principio
de cada paso alrededor de la espiral. Más que una simple actividad
de comunicación con el cliente, se definen las siguientes actividades:
Identificación del sistema o subsistemas clave de los
«directivos».
Determinación de las «condiciones de victoria» de los
directivos.
Negociación de las condiciones de «victoria» de los
directivos para reunirlas en un conjunto de condiciones
El Proceso
23
Conseguidos completamente estos pasos iniciales se logra un
resultado «victoria-victoria», que será el criterio clave para continuar
con la definición del sistema y del software. Además del énfasis
realizado en la negociación inicial, el modelo en espiral WINWIN
introduce tres hitos en el proceso, llamados puntos de fijación, que
ayudan a establecer la completitud de un ciclo alrededor de la espiral
y proporcionan hitos de decisión antes de continuar el proyecto de
software.
En esencia, los puntos de fijación representan tres visiones diferentes
del progreso mientras que el proyecto recorre la espiral. El primer
punto de fijación, llamado objetivos del ciclo de vida (OCV), define un
conjunto de objetivos para cada actividad principal de ingeniería del
software. Como ejemplo, de una parte de OCV, un conjunto de
objetivos asociados a la definición de los requisitos del
producto/sistema del nivel más alto. El segundo punto de fijación,
llamado arquitectura del ciclo de vida (ACV), establece los objetivos
que se deben conocer mientras que se define la arquitectura del
software y el sistema. Como ejemplo, de una parte de la ACV, el
equipo del proyecto de software debe demostrar que ha evaluado la
funcionalidad de los componentes del software reutilizables y que ha
considerado su impacto en las decisiones de arquitectura. La
capacidad operativa inicial (COI) es el tercer punto de fijación y
representa un conjunto de objetivos asociados a la preparación del
software para la instalación/distribución, preparación del lugar
previamente a la instalación, y la asistencia precisada de todas las
partes que utilizará o mantendrá el software.
5. El modelo de desarrollo concurrente
Davis y Sitaram han descrito el modelo de desarrollo concurrente,
llamado algunas veces ingeniería concurrente, de la forma siguiente:
Los gestores de proyectos que siguen los pasos del estado del
proyecto en lo que se refiere a las fases importantes [del ciclo de vida
clásico] no tienen idea del estado de sus proyectos. Estos son
ejemplos de un intento por seguir los pasos extremadamente
complejos de actividades mediante modelos demasiado simples.
Tenga en cuenta que aunque un proyecto grande esté en la fase de
codificación, hay personal de ese proyecto implicado en actividades
asociadas generalmente a muchas fases de desarrollo
El Proceso
24
simultáneamente. Por ejemplo, El personal está escribiendo
requisitos, diseñando, codificando, haciendo pruebas y probando la
integración (todo al mismo tiempo). Los modelos de procesos de
ingeniería del software de Humphrey y Kellner han mostrado la
concurrencia que existe para actividades que ocurren durante
cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de
estado [una notación que representa los estados de un proceso] para
representar la relación concurrente que existe entre actividades
asociadas a un acontecimiento específico (por ejemplo: un cambio de
requisitos durante el último desarrollo), pero falla en capturar la
riqueza de la concurrencia que existe en todas las actividades de
desarrollo y de gestión del software en un proyecto. La mayoría de los
modelos de procesos de desarrollo del software son dirigidos por el
tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso
de desarrollo. Un modelo de proceso concurrente está dirigido por las
necesidades del usuario, las decisiones de la gestión y los resultados
de las revisiones.
El modelo de proceso concurrente se puede representar en forma de
esquema como una serie de actividades técnicas importantes, tareas
y estados asociados a ellas. Por ejemplo, la actividad de ingeniería
definida para el modelo en espiral, se lleva a cabo invocando las
tareas siguientes: modelado de construcción de prototipos y/o
análisis, especificación de requisitos y diseño. Todas las actividades
existen concurrentemente, pero residen en estados diferentes. Por
ejemplo, al principio del proyecto la actividad de comunicación con el
cliente (no mostrada en la figura) ha finalizado su primera iteración y
está en el estado de cambios, en espera. La actividad de análisis (que
estaba en el estado ninguno mientras que se iniciaba la comunicación
inicial con el cliente) ahora hace una transición al estado bajo
desarrollo. Sin embargo, si el cliente indica que se deben hacer
cambios en requisitos, la actividad análisis cambia del estado bajo
desarrollo al estado cambios en espera.
El modelo de proceso concurrente define una serie de
acontecimientos que dispararán transiciones de estado a estado para
cada una de las actividades de la ingeniería del software. Por
ejemplo, durante las primeras etapas del diseño, no se contempla una
inconsistencia del modelo de análisis. Esto genera la corrección del
modelo de análisis de sucesos, que disparará la actividad de análisis
del estado hecho al estado cambios en espera.
El Proceso
25
El modelo de proceso concurrente se utiliza a menudo como el
paradigma de desarrollo de aplicaciones cliente/ servidor". Un sistema
cliente/servidor se compone de un conjunto de componentes
funcionales. Cuando se aplica a cliente/servidor, el modelo de
proceso concurrente define actividades en dos dimensiones: una
dimensión de sistemas y una dimensión de componentes. Los
aspectos del nivel de sistemas se afrontan mediante tres actividades:
diseño, ensamblaje y uso.
La dimensión de componentes se afronta con dos actividades: diseño
y realización. La concurrencia se logra de dos formas: (1) las
actividades de sistemas y de componentes ocurren simultáneamente
y pueden modelarse con el enfoque orientado a objetos descrito
anteriormente; (2) una aplicación cliente/servidor típica se implementa
con muchos componentes, cada uno de los cuales se pueden diseñar
y realizar concurrentemente.
En realidad, el modelo de proceso concurrente es aplicable a todo tipo
de desarrollo de software y proporciona una imagen exacta del estado
actual de un proyecto.
DEASARROLLO BASADO EN COMPONENTES
Las tecnologías de objetos proporcionan el marco de trabajo técnico
para un modelo de proceso basado en componentes para la
ingeniería del software. El paradigma orientado a objetos enfatiza la
creación de clases que encapsulan tanto los datos como los
algoritmos que se utilizan para manejar los datos. Si se diseñan y se
implementan adecuadamente, las clases orientadas a objetos son
El Proceso
26
reutilizables por las diferentes aplicaciones y arquitecturas de
sistemas basados en computadora.
El modelo de desarrollo basado en componentes incorpora muchas
de las características del modelo en espiral. Es evolutivo por
naturaleza, y exige un enfoque iterativo para la creación del software.
Sin embargo, el modelo de desarrollo basado en componentes
configura aplicaciones desde componentes preparados de software.
La actividad de la ingeniería comienza con la identificación de clases
candidatas. Esto se lleva a cabo examinando los datos que se van a
manejar por parte de la aplicación y el algoritmo que se va a aplicar
para conseguir el tratamiento. Los datos y los algoritmos
correspondientes se empaquetan en una clase. Las clases creadas
en los proyectos de ingeniería del software anteriores, se almacenan
en una biblioteca de clases o diccionario de datos (repository). Una
vez identificadas las clases candidatas, la biblioteca de clases se
examina para determinar si estas clases ya existen. En caso de que
así fuera, se extraen de la biblioteca y se vuelven a utilizar. Si una
clase candidata no reside en la biblioteca, se aplican los métodos
orientados a objetos. Se compone así la primera iteración de la
aplicación a construirse, mediante las clases extraídas de la biblioteca
y las clases nuevas construidas para cumplir las necesidades Únicas
de la aplicación. El flujo del proceso vuelve a la espiral y volverá a
introducir por último la iteración ensambladora de componentes a
través de la actividad de ingeniería.
El modelo de desarrollo basado en componentes conduce a la
reutilización del software, y la reutilización proporciona beneficios a
los ingenieros de software. Según estudios de reutilización, QSM
El Proceso
27
Associates, Inc. Informa que el ensamblaje de componentes lleva a
una reducción del 70 por 100 de tiempo de ciclo de desarrollo, un 84
por 100 del coste del proyecto y un índice de productividad del 26.2,
comparado con la norma de industria del 16.9. Aunque estos
resultados están en función de la robustez de la biblioteca de
componentes, no hay duda de que el ensamblaje de componentes
proporciona ventajas significativas para los ingenieros de software.
El proceso unificado de desarrollo de software representa un número
de modelos de desarrollo basados en componentes que han sido
propuestos en la industria. Utilizando el Lenguaje de Modelado
Unificado (UML), el proceso unificado define los componentes que se
utilizarán para construir el sistema y las interfaces que conectarán los
componentes. Utilizando una combinación del desarrollo incremental
e iterativo, el proceso unificado define la función del sistema aplicando
un enfoque basado en escenarios (desde el punto de vista de1
usuario). Entonces acopla la función con un marco de trabajo
arquitectónico que identifica la forma que tomará el software.
EL MODELO DE MÉTODOS FORMALES
El modelo de métodos formales comprende un conjunto de
actividades que conducen a la especificación matemática del software
de computadora. Los métodos formales permiten que un ingeniero de
software especifique, desarrolle y verifique un sistema basado en
computadora aplicando una notación rigurosa y matemática. Algunas
organizaciones de desarrollo del software actualmente aplican una
variación de este enfoque, llamado ingeniería del software de sala
limpia
Cuando se utilizan métodos formales durante el desarrollo,
proporcionan un mecanismo para eliminar muchos de los problemas
que son difíciles de superar con paradigmas de la ingeniería del
software. La ambigüedad, lo incompleto y la inconsistencia se
descubren y se corrigen más fácilmente –no mediante una revisión a
propósito para el caso, sino mediante la aplicación del análisis
matemático-. Cuando se utilizan métodos formales durante el diseño,
sirven como base para la verificación de programas y por
consiguiente permiten que el ingeniero del software descubra y corrija
errores que no se pudieron detectar de otra manera.
El Proceso
28
Aunque todavía no hay un enfoque establecido, los modelos de
métodos formales ofrecen la promesa de un software libre de
defectos. Sin embargo, se ha hablado de una gran preocupación
sobre su aplicabilidad en un entorno de gestión:
1. El desarrollo de modelos formales actualmente es bastante
caro y lleva mucho tiempo.
2. Se requiere un estudio detallado porque pocos responsables
del desarrollo de software tienen los antecedentes
necesarios para aplicar métodos formales.
3. Es difícil utilizar los modelos como un mecanismo de
comunicación con clientes que no tienen muchos
conocimientos técnicos.
No obstante es posible que el enfoque a través de métodos formales
tenga más partidarios entre los desarrolladores del software que
deben construir software de mucha seguridad (por ejemplo: los
desarrolladores de aviónica y dispositivos médicos), y entre los
desarrolladores que pasan grandes penurias económicas al aparecer
errores de software.
TÉCNICAS DE CUARTA GENERACIÓN
El término técnicas de cuarta generación (T4G) abarca un amplio
espectro de herramientas de software que tienen algo en común:
todas facilitan al ingeniero del software la especificación de algunas
características del software a alto nivel. Luego, la herramienta genera
automáticamente el código fuente basándose en la especificación del
técnico. Cada vez parece más evidente que cuanto mayor sea el nivel
en el que se especifique el software, más rápido se podrá construir el
programa.
El paradigma T4G para la ingeniería del software se orienta hacia la
posibilidad de especificar el software usando formas de lenguaje
especializado o notaciones gráficas que describa el problema que hay
que resolver en términos que los entienda el cliente. Actualmente, un
entorno para el desarrollo de software que soporte el paradigma T4G
puede incluir todas o algunas de las siguientes herramientas:
lenguajes no procedimentales de consulta a bases de datos,
El Proceso
29
generación de informes, manejo de datos, interacción y definición de
pantallas, generación de códigos, capacidades gráficas de alto nivel y
capacidades de hoja de cálculo, y generación automatizada de HTML
y lenguajes similares utilizados para la creación de sitios web usando
herramientas de software avanzado. Inicialmente, muchas de estas
herramientas estaban disponibles, pero sólo para ámbitos de
aplicación muy específicos, pero actualmente los entornos T4G se
han extendido a todas las categorías de aplicaciones del software.
Al igual que otros paradigmas, T4G comienza con el paso de reunión
de requisitos. Idealmente, el cliente describe los requisitos, que son, a
continuación, traducidos directamente a un prototipo operativo. Sin
embargo, en la práctica no se puede hacer eso. El cliente puede que
no esté seguro de lo que necesita; puede ser ambiguo en la
especificación de hechos que le son conocidos, y puede que no sea
capaz o no esté dispuesto a especificar la información en la forma en
que puede aceptar una herramienta T4G. Por esta razón, el diálogo
cliente- desarrollador descrito por los otros paradigmas sigue siendo
una parte esencial del enfoque T4G.
Para aplicaciones pequeñas, se puede ir directamente desde el paso
de recolección de requisitos al paso de implementación, usando un
lenguaje de cuarta generación no procedimental (L4G) o un modelo
comprimido de red de iconos gráficos. Sin embargo, es necesario un
mayor esfuerzo para desarrollar una estrategia de 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,
mantenimiento pobre, mala aceptación por el cliente) que se
encuentran cuando se desarrolla software mediante los enfoques
convencionales. La implementación mediante L4G permite, al que
desarrolla el software, centrarse en la representación de los
resultados deseados, que es lo que se traduce automáticamente en
un código fuente que produce dichos resultados. Obviamente, debe
existir una estructura de datos con información relevante y a la que el
L4G pueda acceder rápidamente.
Para transformar una implementación T4G en un producto, el que lo
desarrolla debe dirigir una prueba completa, desarrollar con sentido
una documentación y ejecutar el resto de las actividades de
integración que son también requeridas por otros paradigmas de
ingeniería del software. Además, el software desarrollado con T4G
El Proceso
30
debe ser construido de forma que facilite la realización del
mantenimiento de forma expeditiva.
Al igual que todos los paradigmas del software, el modelo T4G tiene
ventajas e inconvenientes. Los defensores aducen reducciones
drásticas en el tiempo de desarrollo del software y una mejora
significativa en la productividad de la gente que construye el software.
Los detractores aducen que las herramientas actuales de T4G no son
más fáciles de utilizar que los lenguajes de programación, que el
código fuente producido por tales herramientas es «ineficiente» y que
el mantenimiento de grandes sistemas de software desarrollados
mediante T4G es cuestionable.
Hay algún mérito en lo que se refiere a indicaciones de ambos lados y
es posible resumir el estado actual de los enfoques de T4G:
1. El uso de T4G es un enfoque viable para muchas de las
diferentes áreas de aplicación. Junto con las herramientas
de ingeniería de software asistida por computadora (CASE)
y los generadores de código, T4G ofrece una solución fiable
a muchos problemas del software.
2. Los datos recogidos en compañías que usan T4G parecen
indicar que el tiempo requerido para producir software se
reduce mucho para aplicaciones pequeñas y de tamaño
medio, y que la cantidad de análisis y diseño para las
aplicaciones pequeñas también se reduce.
3. Sin embargo, el uso de T4G para grandes trabajos de
desarrollo de software exige el mismo o más tiempo de
análisis, diseño y prueba (actividades de ingeniería del
software), para lograr un ahorro sustancial de tiempo que
puede conseguirse mediante la eliminación de la
codificación.
Resumiendo, las técnicas de cuarta generación ya se
han convertido en una parte importante del desarrollo
de software. Cuando se combinan con enfoques de
ensamblaje de componentes.
El paradigma T4G
(Técnicas de Cuarta
Generación) se puede
convertir en el
enfoque dominante
El Proceso
31
TÉCNOLOGÍAS DE PROCESO
Los modelos de procesos tratados en las secciones anteriores se
deben adaptar para utilizarse por el equipo del proyecto del software.
Para conseguirlo, se han desarrollado herramientas de tecnología de
procesos para ayudar a organizaciones de software a analizar los
procesos actuales, organizar tareas de trabajo, controlar y supervisar
el progreso y gestionar la calidad técnica. Las
herramientas de tecnología de procesos
permiten que una organización de software
construya un modelo automatizado del marco
de trabajo común de proceso, conjuntos de
tareas y actividades de protección. El modelo,
presentado normalmente como una red, se
puede analizar para determinar el flujo de
trabajo típico y para examinar estructuras
iterativas de procesos que pudieran llevar a un
tiempo o coste de desarrollo reducidos. Una
vez que se ha creado un proceso aceptable, se
pueden utilizar otras herramientas de
tecnología de procesos para asignar,
supervisar e incluso controlar todas las tareas de ingeniería del
software definidas como parte del modelo de proceso.
Cada uno de los miembros de un equipo de proyecto de software
puede utilizar tales herramientas para desarrollar una lista de control
de tareas de trabajo a realizarse, productos de trabajo a producirse, y
actividades de garantía de calidad a conducirse.
PRODUCTO Y PROCESO
Si el proceso es débil, el producto final va a sufrir indudablemente.
Aunque una dependencia obsesiva en el proceso también es
peligrosa. En un breve ensayo, Margaret Davis comenta la dualidad
producto y proceso:
Cada diez años o cinco aproximadamente, la comunidad del software
vuelve a definir «el problema» cambiando el foco de los aspectos de
producto a los aspectos de proceso. Por consiguiente, se han
abarcado lenguajes de programación estructurados (producto)
La herramienta de
tecnología de proceso
también se puede utilizar
para coordinar el uso de
otras herramientas de
ingeniería del software
asistida por computadora
adecuada para una tarea
de trabajo en particular
hacia el desarrollo del
software.
El Proceso
32
seguidos por métodos de análisis estructurados (proceso) seguidos a
su vez por encapsulación de datos (producto) y después por el
énfasis actual en el Modelo Madurez de Capacidad de Desarrollo del
software del Instituto de ingeniería de software (proceso).
Mientras que la tendencia natural de un péndulo es parar en medio de
dos extremos, el enfoque de la comunidad del software cambia
constantemente porque se aplica una fuerza nueva cuando halla el
último movimiento. Estos movimientos son perjudiciales por sí mismos
y en sí mismos porque confunden al desarrollador del software medio
cambiando radicalmente lo que significa realizar el trabajo, que por sí
mismo lo realiza bien. Los cambios tampoco resuelven «el problema»,
porque están condenados al fracaso siempre que el producto y el
proceso se traten como si formasen una dicotomía en lugar de una
dualidad.
En la comunidad científica hay un precedente que se adelanta a las
nociones de dualidad cuando contradicciones en observaciones no
se pueden explicar completamente con una teoría competitiva u otra.
La naturaleza dual de la luz, que parece ser una partícula y una onda
al mismo tiempo, se ha aceptado desde los años veinte cuando Louis
de Broglie lo propuso. Creo que las observaciones que se hacen
sobre los mecanismos del software y su desarrollo demuestran una
dualidad fundamental entre producto y proceso. Nunca se puede
comprender el mecanismo completo, su contexto, uso, significado y
valor si se observa sólo como un proceso o sólo como un producto.
Toda actividad humana puede ser un proceso, pero cada uno de
nosotros obtiene el sentido de autoestima ante esas actividades que
producen una representación o ejemplo que más de una persona
puede utilizar o apreciar, una u otra vez, o en algún otro contexto no
tenido en cuenta. Es decir, los sentimientos de satisfacción se
obtienen por volver a utilizar nuestros productos por nosotros mismos
o por otros.
Así pues, mientras que la asimilación rápida de los objetivos de
reutilización en el desarrollo del software aumenta potencialmente la
satisfacción que los desarrolladores obtienen de su trabajo, esto
incrementa la urgencia de aceptar la dualidad producto y proceso.
Pensar en un mecanismo reutilizable como el único producto o el
único proceso, bien oscurece el contexto y la forma de utilizarlo, o
El Proceso
33
bien el hecho de que cada utilización elabora el producto que a su vez
se utilizará como entrada en alguna otra actividad de desarrollo del
software. Elegir un método sobre otro reduce enormemente las
oportunidades de reutilización y de aquí que se pierda la oportunidad
de aumentar la satisfacción ante el trabajo.
Las personas obtienen tanta satisfacción (o más) del proceso creativo
que del producto final. Un artista disfruta con las pinceladas de la
misma forma que disfruta del resultado enmarcado. Un escritor
disfruta con la búsqueda de la metáfora adecuada al igual que con el
libro final. Un profesional creativo del software debería también
obtener tanta satisfacción de la programación como del producto final.
El trabajo de los profesionales del software cambiará en los próximos
años. La dualidad de producto y proceso es un elemento importante
para mantener ocupada a la gente creativa hasta que se finalice la
transición de la programación a la ingeniería del software.
El Proceso
34
BIBLIOGRAFÍA
Ingeniería del software – un enfoque práctico. Roger S. Pressman
http://www.google.com.pe/search?num=10&hl=es&site=imghp&tb
m=isch&source=hp&biw=1366&bih=677&q=EL+PRODUCTO&oq=
EL+PRODUCTO&gs_l=img.3..0l10.1430.3454.0.4143.11.9.0.2.2.0
.186.986.4j5.9.0...0.0...1ac.1.Fl7oAV4lIQw#hl=es&tbo=d&site=img
hp&tbm=isch&sa=1&q=software+de+inteligencia+artificial&oq=soft
ware+de+inteligencia+artificial&gs_l=img.3..0j0i24l5.134002.1409
50.6.141169.26.11.0.15.15.1.196.1908.0j11.11.0...0.0...1c.1.9iim2
AMAFfQ&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=ba1326681ff2cb
8&bpcl=38897761&biw=1366&bih=634
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software
http://www.ctic.uni.edu.pe/files/insoft01.pdf
Todos son links o enlaces a diferentes páginas web que se
consultaron para el desarrollo de esta sesión de clases.
