Guia 1 is

PAIITE

EL PRODUCTO
Y EL PROCESO

a la tecnología de Ingeniería del

asados en com-

ad de un proceso?

Una vez contestad ntas, estará más preparado para com-
s y de gestión de la disciplina de ingeniería a la que

1

CAPÍTULO

EL PRODUCTQ

L
AS alarmas comenzaron más de una década antes del acontecimiento. Con menos de
dos años a la fecha señalada, los medios de comunicación recogieron la historia. Los
oficiales del gobierno expresaron su preocupación, los directores de la industria y de los
negocic3s comprometieron grandes cantidades de dinero, y por Último, las advertencias horri-
bles de catástrofe llegaron a la conciencia del público. El software, al igual que el ahora famoso
error Y2K, podría fallar, y como resultado, detener el mundo como nosotros lo conocimos.
Como vimos durante los últimos meses del año 1999, sin querer, no puedo dejar de pen-
sar en el párrafo profético contenido en la primera página de la cuarta edición de este libro.
Decía:
El software de computadora se ha convertido en el alma mater. Es la máquina que conduce a la toma
de decisiones comerciales. Sirve de base para la investigación científica moderna y de resolución de pro-
blemas de ingeniería. Es el factor clave que diferencia los productos y servicios modernos. Está inmerso en
sistemas de todo tipo: de transportes, médicos, de telecomunicaciones, militares, procesos industriales, entre-
tenimientos, productos de oficina ..., la lista es caki interminable. El software es casi ineludible en un mun-
do moderno. A medida que nos adentremos en el siglo XXI, será el que nos conduzca a nuevos avances en
todo, desde la educación elemental a la ingeniería genética.

&Que es? El software de computadora es ¿Por qué e s importante? Porque &Cu610S dudo obtenido?Des-
el producto que diseiian y construyen afecta muy de cerca a cualquier de el punto de vista de un ingeniero de
a y está muy software, e l producto obtenido son los
ca programas que se ejecutan omercio, cuí- programas, documentos y los datos
vidades coti- que configuran el software d e compu-
de el punto de vista de
os? Construir los usuarios el producto obt
e impresos y datos que combinan ora cons- información resultante
números y texto y tambien incluyen producto =tis- algún modo el mund
representaciones d e información de oceso que usuarios.
audio, vídeo e imágenes. conduce a un resultado de alta calidad ¿Cómo puedo estar u r g e de que
&Quién hace? Los ingenierosde soft-
lo que satisface las necesidades de l a lo he hecho comeatmneate? L e e
ware lo construyen, y virtualmente gente que usará el producto. Debes el resto deeste libro, selecciona aque-
cualquier persona en el mundo indus- aplicar un enfoque d e ingeniería d e llas ideas que son aplicablers al soft-
trialiiado lo utiliza bien directa o indi- software. ware que construyes y aplícalas a tu
rectaniate. trabajo.

Cinco años después de que la cuarta edición de este libro fue escrita, el papel del software
como «alma maten>ha llegado a ser más obvio.Un director de software de Intemet ha produ-
cido su propia economía de 500 billones de Euros. En la euforia creada por la promesa de un
paradigma económico nuevo, los inversores de Wall Street dieron a las pequeñas empresas
«punto-com» estimaciones en billones de dólares antes de que éstas comenzasen a producir un
dólar en ventas. Han surgido nuevas industrias dirigidas por software y las antiguas que no se
han adaptado a esta nueva tendencia están ahora amenazadas de extinción. El gobierno de Esta-
dos Unidos ha mantenido un contencioso frente a la mayor compañía de la industria del soft-
ware, como lo mantuvo hace poco tiempo cuando se movilizó para detener las actividades
monopolísticas en las industrias del acero y del aceite.
El impacto del software en nuestra sociedad y en la cultura continúa siendo profundo. Al
mismo tiempo que crece su importancia, la comunidad del software trata continuamente de
desarrollar tecnologías que hagan más sencillo, rápido y menos costosa la construcción de pro-
gramas de computadora de alta calidad.
Este libro presenta un marco de trabajo que puede ser usado por aquellos que construyen
software informático -aquellos que lo deben hacer bien- La tecnología que comprende un
.
proceso, un juego de métodos y un conjunto de herramientas se llama ingeniería del software.
3

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

Hoy en día el software tiene un doble papel. Es un pro-
ducto y, al mismo tiempo, el vehículo para entregarlo.
Como producto, hace entrega de la potencia informáti-
ca que incorpora el hardware informático o, más amplia-
mente, una red de computadoras que es accesible por
hardware local. Si reside dentro de un teléfono celular
u opera dentro de una computadora central, el softwa-
re es un transformador de información, produciendo,
gestionando, adquiriendo, modificando, mostrando o las computadoras y el software nos llevaran a la edemo-
transmitiendo información que puede ser tan simple cratización del conocimiento». A Yourdon [YOU92] le
como un solo bit, o tan complejo como una presenta- preocupaba que las compañías en Estados Unidos pudie-
ción en multimedia. Como vehículo utilizado para hacer ran perder su competitividad en empresas relativas al
entrega del producto, el software actúa como la base de software y predijo «el declive y la caída del programa-
control de la computadora (sistemas operativos), la dor americano». Hammer y Champy [HAM93] argu-
comunicación de información (redes) y la creación y mentaron que las tecnologías de información iban a
control de otros programas (herramientas de software desempeñar el papel principal en la areingeniería de la
y entomos). compañía».A mediados de los años 90, la persistencia de
las computadoras y del softwaregeneró una erupción de
libros por «neo-Luddites» (por ejemplo: Resisting the Vir-
tual Life, editado por James Brook y Ian Boal, y The Futu-
re Does not Compute de Stephen Talbot). Estos autores
Esoftware es tonto un producto,
l critican enormemente la computadora, haciendo énfasis
como el vehículo poro su entrego en preocupaciones legítimas pero ignorando los profun-
dos beneficios que se han llevado a cabo [LEV95].
El papel del software informático ha sufrido un cam-
bio significativo durante un periodo de tiempo superior
a 50 años. Enormes mejoras en rendimiento del hard- cosas más fáciles,
ware, profundos cambios de arquitecturas informáticas, que facilitan no
grandes aumentos de memoria y capacidad de almace-
namiento y una gran variedad de opciones de entrada y
salida han conducido a sistemas más sofisticados y más
complejos basados en computadora. La sofisticación y Al final de los años 90, Yourdon [YOU96] volvió a
la complejidad pueden producir resultados deslum- evaluar las perspectivas del software profesional y sugi-
brantes cuando un sistema tiene éxito, pero también pue- rió la «resurrección y elevación» del programador ame-
den suponer grandes problemas para aquellos que deben ricano. A medida que internet creció en importancia, su
construir sistemas complejos. cambio de pensamiento demostró ser correcto. Al final
Libros populares publicados durante los años 70 y 80 del siglo veinte, el enfoque cambió una vez más. Aquí
proporcionan una visión histórica útil dentro de la per- tuvo lugar el impacto de la «bomba de relojería» Y2K
cepción cambiante de las computadoras y del software, (por ejemplo: [YOU98b], [DEJ98], [KAR99]). Aunque
y de su impacto en nuestra cultura. Osborne [OSB79] muchos vieron las predicciones de los críticos del Y2K
hablaba de una «nueva revolución industriah. Toffler como reacciones, sus populares lecturas devolvieron la
[TOF80] llamó a la llegada de componentes microelec- difusión del software a sus vidas. Hoy en día, «la com-
trónicos la «tercera ola del cambio» en la historia de la putación omnipresente» [NOR98] ha producido una gene-
humanidad, y Naisbitt "A1821 predijo la transformación ración de aplicaciones de información que tienen
de la sociedad industrial a una «sociedad de informa- conexión en banda ancha a la Web para proporcionar
ción». Feigenbaum y McCorduck [FE1831 sugirieron que «una capa de conexión sobre nuestras casas, oficinas, y
la información y el conocimiento (controlados por com- autopistas» [LEV99]. El papel del software continúa su
putadora) serían el foco de poder del siglo veintiuno, y expansión.
Sto11 [STO891 argumentó que la «comunidad electróni- El programador solitario de antaño ha sido reempla-
ca» creada mediante redes y software es la clave para el zado por un equipo de especialistasdel software, cada uno
intercambio de conocimiento alrededor del mundo. centrado en una parte de la tecnología requerida para entre-
Al comienzo de los años 90, Toffler [TOF90] descri- gar una aplicación concreta. Y de este modo, las cuestio-
bió un «cambio de poder» en el que las viejas estructu- nes que se preguntaba el programador solitario son las
ras de poder (gubernamentales, educativas, industriales, mismas cuestiones que nos preguntamos cuando cons-
económicas y militares) se desintegrarían a medida que truimos sistemas modernos basados en computadoras:
4

CAPITULO 1 EL PRODUCTO Y EL PROCESO

¿Por qué lleva tanto tiempo terminar los programas?
¿Por qué son tan elevados los costes de desarrollo?
¿Por qué no podemos encontrar todos los errores
antes de entregar el software a nuestros clientes?
¿Por qué nos resulta difícil constatar el progreso con-
Estadísticas globoles de software forme se desarrolla el software?

En 1970, menos del uno por ciento de las personas Los costes del software se encuentran en la ingeniería.
podría haber descrito inteligentemente lo que significa- Esto significa que los proyectos de software no se pueden
ba «software de computadora». Hoy, la mayoría de los gestionar como si fueran proyectos de fabricación.
profesionales y muchas personas en general piensan en
su mayoría que comprenden el software. ¿Pero lo entien- 2. El software no se «estropea».
den realmente? La Figura 1.1 describe, para el hardware, la proporción
de fallos como una función del tiempo. Esa relación, deno-
minada frecuentemente «curva de bañera», indica que el
1.2.1. Características del software hardware exhibe relativamente muchos fallos al pnnci-
Para poder comprender lo que es el software (y con- pio de su vida (estos fallos son atribuibles normalmente
secuentemente la ingeniería del software), es impor- a defectos del diseño o de la fabricación); una vez corre-
tante examinar las características del software que lo gidos los defectos, la tasa de fallos cae hasta un nivel esta-
diferencian de otras cosas que los hombres pueden cionario (bastante bajo, con un poco de optimismo) donde
construir. Cuando se construye hardware, el proceso permanece durante un cierto periodo de tiempo. Sin
creativo humano (análisis, diseño, construcción, prue- embargo, conforme pasa el tiempo, el hardware empie-
ba) se traduce finalmente en una forma física. Si cons- za a desgastarse y la tasa de fallos se incrementa.
truimos una nueva computadora, nuestro boceto El software no es susceptible a los males del entor-
inicial, diagramas formales de diseño y prototipo de no que hacen que el hardware se estropee. Por tanto, en
prueba, evolucionan hacia un producto físico (chips, teoría, la curva de fallos para el software tendría la for-
tarjetas de circuitos impresos, fuentes de potencia, ma que muestra la Figura 1.2. Los defectos no detecta-
etc.). dos haran que falle el programa durante las primeras
El software es un elemento del sistema que es etapas de su vida. Sin embargo, una vez que se corri-
lógico, en lugar de físico. Por tanto el software tie- gen (suponiendo que no se introducen nuevos errores)
ne unas características considerablemente distintas la curva se aplana, como se muestra. La curva ideali-
a las del hardware: zada es una gran simplificación de los modelos reales
de fallos del software (vease más información en el
Capítulo 8). Sin embargo la implicación es clara, el soft-
".%
c VE
El software se desarrolla, no se fabrica.
ware no se estropea. ¡Pero se deteriora!

W$
CLAVE
1. El software se desarrolla, El software no se estropea, pero se deteriora.
no se fabrica en un sentido clásico.
Aunque existen similitudes entre el desarrollo del soft-
ware y la construcción del hardware, ambas activida-
des son fundamentalmente diferentes. En ambas
actividades la buena calidad se adquiere mediante un u) Mortalidad Se estropea
-
-
buen diseño, pero la fase de construcción del hard- m
c
al
ware puede introducii problemas de calidad que no D
al
existen (o son fácilmente corregibles) en el software. ._
U
Ambas actividades dependen de las personas, pero la ._
relación entre las personas dedicadas y el trabajo rea-
lizado es completamente diferente para el software
(véase el Capítulo 7). Ambas actividades requieren
Tiempo
la construcción de un «producto» pero los enfoques
son diferentes. FIGURA 1.1. Curva de fallos del hardware.

5

INGENIER~ADEL SOFTWARE. UN ENFOQUE PR A CTICO

Esto que parece una contradicción, puede compren- A medida que la disciplina del software evoluciona, se
derse mejor considerando «la curva actual» mostrada en crea un grupo de componentes de diseño estándar. Torni-
la Figura 1.2. Durante su vida, el software sufre cambios llos estándar y circuitos integradospreparados para la ven-
(mantenimiento). Conforme se hacen los cambios, es ta son solamente los dos mil coinponentes estándar que
bastante probable que se introduzcan nuevos defectos, utilizan ingenieros mecánicos y eléctricos cuando dise-
haciendo que la curva de fallos tenga picos como se ve ñan nuevos sistemas. Los componentes reutilizables se
en la Figura 1.2. Antes de que la curva pueda volver al han creado para que el ingeniero pueda concentrarse en
estado estacionario original, se solicita otro cambio, elementos verdaderamente innovadores de un diseño, por
haciendo que de nuevo se cree otro pico. Lentamente, el ejemplo, las partes del diseño que representan algo nue-
nivel mínimo de fallos comienza a crecer -e1 software vo. En el mundo del hardware, la reutilización de com-
se va deteriorando debido a los cambios-. ponentes es una parte natural del proceso de ingeniería.
Otro aspecto de ese deterioro ilustra la diferencia entre En el mundo del software es algo que sólo ha comenza-
el hardware y el software. Cuando un componente de do a lograrse en una escala amplia.
hardware se estropea se sustituye por una pieza de repues- El componente de software debería diseñarse e
to. No hay piezas de repuesto para el software. Cada fallo implementarse para que pueda volver a ser reutiliza-
en el software indica un error en el diseño o en el proce- do en muchos programas diferentes. En los años 60,
so mediante el que se tradujo el diseño a código máqui- se construyeron bibliotecas de subrutinas científicas
na ejecutable. Por tanto, el mantenimiento del software reutilizables en una amplia serie de aplicaciones cien-
tiene una complejidad considerablemente mayor que la tíficas y de ingeniería. Esas bibliotecas de subrutinas
del mantenimiento del hardware. reutilizaban de forma efectiva algoritmos bien defi-
nidos, pero tenían un dominio de aplicación limita-
3. Aunque la industria tiende a ensamblar componen- do. Hoy en día, hemos extendido nuestra visión de
tes, la mayoría del software se construye a medida. reutilización para abarcar no sólo los algorítmos, sino
Consideremos la forma en la que se diseña y se cons- también estructuras de datos. Los componentes reu-
truye el hardware de control para un producto basa- tilizables modernos encapsulan tanto datos como pro-
do en computadora. El ingeniero de diseño construye cesos que se aplican a los datos, permitiendo al
un sencillo esquema de la circuitería digital, hace ingeniero del software crear nuevas aplicaciones a
algún análisis fundamental para asegurar que se con- partir de las partes reutilizables. Por ejemplo, las
sigue la función adecuada y va al armario donde se interfaces gráficas de usuario de hoy en día se cons-
encuentran los catálogos de componentes digitales. truyen frecuentemente a partir de componentes reu-
Después de seleccionar cada componente, puede soli- tilizables que permiten la creación de ventanas
citarse la compra. gráficas, de menús despleglables y de una amplia
variedad de mecanismos de interacción.
Incremento
f del índice de fallos
c VE
l a mayoría del s o h a r e sigue construyéndose a medida.

1.2.2. Aplicaciones del software
El software puede aplicarse en cualquier situación en la
que se haya definido previamente un conjunto especí-
fico de pasos procedimentales (es decir, un algoritmo)
(excepciones notables a esta regla son el software de
los sistemas expertos y de redes neuronales). El conte-
-Curva idealizada
* nido y el determinismo de la información son factores
Tiempo importantes a considerar para determinar la naturaleza
de una aplicación de software. El contenido se refiere
FIGURA 1.2. Curvas de fallos real e idealizada del software. al significado y a la forma de la información de entra-
da y salida. Por ejemplo, muchas aplicaciones banca-
rias usan unos datos de entrada muy estructurados (una
a$$ base de datos) y producen «informes» con determina-
dos formatos. El software que controla una máquina
CLAVE automática (por ejemplo: un control numérico) acepta
los métodos de ingeniería de software se esfuerzan elementos de datos discretos con una estructura limita-
para reducir la magnitud de los picos y la inclinación da y produce órdenes concretas para la máquina en rápi-
de la curva (Fig. 1.2). da sucesión.

6

CAPÍTULO 1 EL PRODUCTO Y EL PROCESO

Software de gestión. El proceso de la información
l a revolución del software se foto en el Capítvlo 13. comercial constituye la mayor de las áreas de aplica-
Lo ingeniería de software basada en canponentes ción del software. Los «sistemas» discretos (por ejem-
se presento en el Capítulo 27. plo: nóminas, cuentas de haberes-débi.tos, inventarios,
etc.) han evolucionado hacia el software de sistemas de
información de gestión (SIG) que accede a una o más
El determinismo de la información se refiere a la pre- bases de datos que contienen información comercial.
decibilidad del orden y del tiempo de llegada de los Las aplicaciones en esta área reestructuran los datos
datos. Un programa de análisis de ingeniería acepta datos existentes para facilitar las operaciones comerciales o
que están en un orden predefinido, ejecuta el algorit- gestionar la toma de decisiones. Además de las tareas
mo(s) de análisis sin interrupción y produce los datos convencionales de procesamientos de datos, las aplica-
resultantes en un informe o formato gráfico. Se dice que ciones de software de gestión también realizan cálculo
tales aplicaciones son determinadas. Un sistema opera- interactivo (por ejemplo: el procesamiento de transac-
tivo multiusuario, por otra parte, acepta entradas que ciones en puntos de ventas).
tienen un contenido variado y que se producen en ins-
tantes arbitrarios, ejecuta algoritmos que pueden ser Software de ingeniería y científíco. El software
interrumpidos por condiciones externas y produce una de ingeniería y científico está caracterizado por los
salida que depende de una función del entorno y del algoritmos de «manejo de números». Las aplicacio-
tiempo. Las aplicaciones con estas características se dice nes van desde la astronomía a la vulcanología, desde
que son indeterminadas. el análisis de la presión de los automotores a la diná-
mica orbital de las lanzaderas espaciales y desde la
Algunas veces es difícil establecer categorías gené-
biología molecular a la fabricación automática. Sin
ricas para las aplicaciones del software que sean sig- embargo, las nuevas aplicaciones del área de inge-
nificativas. Conforme aumenta la complejidad del
niería/ciencia se han alejado de los algoritmos con-
software, es más difícil establecer compartimentos
vencionales numéricos. El diseño asistido por
nítidamente separados. Las siguientes áreas del soft-
computadora (del inglés CAD), la simulación de sis-
ware indican la amplitud de las aplicaciones poten-
temas y otras aplicaciones interactivas, han comen-
ciales:
zado a coger características del software de tiempo
Software de sistemas. El software de sistemas es real e incluso del software de sistemas.
un conjunto de programas que han sido escritos para Software empotrado. Los productos inteligentes se
servir a otros programas. Algunos programas de siste- han convertido en algo común en casi todos los merca-
mas (por ejemplo: compiladores, editores y utilidades dos de consumo e industriales. El software empotrado
de gestión de archivos) procesan estructuras de infor- reside en memoria de sólo lectura y se utiliza para con-
mación complejas pero determinadas. Otras aplicacio- trolar productos y sistemas de los mercados industria-
nes de sistemas (por ejemplo: ciertos componentes del les y de consumo. El software empotrado puede ejecutar
sistema operativo, utilidades de manejo de periféricos, funciones muy limitadas y curiosas (por ejemplo: el con-
procesadores de telecomunicaciones) procesan datos en trol de las teclas de un horno de microondas) o sumi-
gran medida indeterminados. En cualquier caso, el área nistrar una función significativa y con capacidad de
del software de sistemas se caracteriza por una fuerte control (por ejemplo: funciones digitales en un auto-
interacción con el hardware de la computadora; una gran móvil, tales como control de la gasolina, indicadores en
utilización por múltiples usuarios; una operación con- el salpicadero, sistemas de frenado, etc.).
currente que requiere una planificación, una comparti-
ción de recursos y una sofisticada gestión de procesos;
unas estructuras de datos complejas y múltiples inter-
faces externas.
Software de tiempo real. El software que coor-
dina/analiza/controla sucesos del mundo real conforme Se puede encontrar una de las mayores bibliotecas
ocurren, se denomina de tiempo real. Entre los elemen- de shurewure/freewure en www.shoieware.com
tos del software de tiempo real se incluyen: un compo-
nente de adquisición de datos que recolecta y da formato
a la información recibida del entorno externo, un com- Software de computadoras personales. El mercado
ponente de análisis que transforma la información según del software de computadoras personales ha germinado
lo requiera la aplicación, un componente de controVsalida en las pasadas dos décadas. El procesamiento de tex-
que responda al entorno externo, y un componente de tos, las hojas de cálculo, los gráficos por computadora,
monitorización que coordina todos los demás compo- multimedia, entretenimientos,gestión de bases de datos,
nentes, de forma que pueda mantenerse la repuesta en aplicaciones financieras, de negocios y personales y
tiempo real (típicamente en el rango de un milisegundo redes o acceso a bases de datos externas son algunas de
a un segundo). los cientos de aplicaciones.

7

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

Software basado en Web. Las páginas Web busca- Software de inteligencia artificial.El software de inte-
das por un explorador son software que incorpora ins- ligencia artificial (IA) hace uso de algoritmos no numéri-
trucciones ejecutables (por ejemplo, CGI, HTML, Perl, cos para resolver problemas complejos para los que no son
o Java), y datos (por ejemplo, hipertexto y una varie- adecuados el cálculo o el análisis directo. Los sistemas exper-
dad de formatos de audio y visuales). En esencia, la red tos, también llamados sistemas basados en el conocimiento,
viene a ser una gran computadora que proporciona un reconocimiento de patrones (imágenes y voz), redes neu-
recurso software casi ilimitado que puede ser accedido ronales artificiales, prueba de teoremas, y los juegos son
por cualquiera con un modem. representativos de las aplicaciones de esta categoría.

Muchos observadores de la industria (incluyendo este computadoras, no ha habido ningún «punto crucial», nin-
autor) han caracterizado los problemas asociados con el gún «momento decisivo», solamente un lento cambio evo-
desarrollo del software como una «crisis». Más de unos lutivo, puntualizado por cambios tecnológicos explosivos
cuantos libros (por ejemplo: [GLA97], [FL097], en las disciplinas relacionadas con el software.
[YOU98a]) han recogido el impacto de algunos de los Cualquiera que busque la palabra crisis en el dic-
fallos mas importantes que ocurrieron durante la déca- cionario encontrará otra definición: «el punto decisivo
da pasada. No obstante, los mayores éxitos conseguidos en el curso de una enfermedad, cuando se ve más claro
por la industria del software han llevado a preguntarse si el paciente vivirá o morirá». Esta definición puede
si el término (crisis del software) es aún apropiado. darnos una pista sobre la verdadera naturaleza de los
Robert Glass, autor de varios libros sobre fallos del soft- problemas que han acosado el desarrollo del software.
ware, representa a aquellos que han sufrido un cambio Lo que realmente tenemos es una aflicción crónica'.
de pensamiento. Expone [GLA98]: «Puedo ver en mis La palabra aflicción se define como «algo que causa pena
ensayos históricos de fallos y en mis informes de excep- o desastre». Pero la clave de nuestro argumento es la defi-
ción, fallos importantes en medio de muchos éxitos, una nición del adjetivo crónica: «muy duradero o que reapa-
copa que está [ahora] prácticamente llena.» rece con frecuencia continuando indefinidamente». Es
bastante más preciso describir los problemas que hemos
estado aguantando en el negocio del software como una
aflicción crónica, en vez de como una crisis.
Sin tener en cuenta como lo llamemos, el conjunto
de problemas encontrados en el desarrollo del software
de computadoras no se limitan al software que «no fun-
ciona correctamente». Es más, el mal abarca los pro-
blemas asociados a cómo desarrollar software, cómo
mantener el volumen cada vez mayor de software exis-
tente y cómo poder esperar mantenemos al corriente de
La palabra crisis se define en el diccionario Webster la demanda creciente de software.
como «un punto decisivo en el curso de algo, momento, Vivimos con esta aflicción desde este día - d e hecho,
etapa o evento decisivo o crucial». Sin embargo, en térmi- la industria prospera a pesar de e l l e . Y así, las cosas
nos de calidad del software total y de velocidad con la cual podrán ser mejores si podemos encontrar y aplicar un
son desarrollados los productos y los sistemas basados en remedio.

Muchas de las causas de la crisis del software se pue- confusión. Los mitos del software tienen varios atribu-
den encontrar en una mitología que surge durante los tos que los hacen insidiosos: por ejemplo, aparecieron
primeros años del desarrollo del software. A diferencia como declaraciones razonables de hechos (algunas veces
de los mitos antiguos, que a menudo proporcionaban a conteniendo elementos verdaderos), tuvieron un senti-
los hombres lecciones dignas de tener en cuenta, los do intuitivo y frecuentemente fueron promulgados por
mitos del software propagaron información errónea y expertos que «estaban al día».

*Esta terminología fue sugerida por el profesor Daniel Tiechrow de la
Universidad de Michigan en una conferencia impartida en Ginebra,
Suiza, Abril, 1989.
8

CAPfTULO 1 EL PRODUCTO Y EL PROCESO

Mitos de gestión. Los gestores con responsabilidad Mitos del Cliente. Un cliente que solicita una apli-
sobre el software, como los gestores en la mayoría de cación de software puede ser una persona del despacho
las disciplinas, están normalmente bajo la presión de de al lado, un grupo técnico de la sala de abajo, el depar-
cumplir los presupuestos, hacer que no se retrase el pro- tamento de ventas o una compañía exterior que solicita
yecto y mejorar la calidad. Igual que se agarra al vacío un software bajo contrato. En muchos casos, el cliente
una persona que se ahoga, un gestor de software se aga- cree en los mitos que existen sobre el software, debido a
rra frecuentemente a un mito del software, aunque tal que los gestores y desarrolladores del software hacen muy
creencia sólo disminuya la presión temporalmente. poco para corregir la mala información. Los mitos con-
Mito. Tenemos ya un libro que está lleno de estánda- ducen a que el cliente se cree una falsa expectativa y, final-
res y procedimientos para construir software, ¿no le pro- mente, quede insatisfecho con el que desarrolla el software.
porciona ya a mi gente todo lo que necesita saber? Mito. Una declaración general de los objetivos es sufi-
Realidad. Está muy bien que el libro exista, pero ciente para comenzar a escribir los programas -pode-
jse usa?.¿conocen los trabajadores su existencia?, mos dar los detalles más adelante-.
jrefleja las prácticas modernas de desarrollo de soft- Realidad. Una mala definición inicial es la principal
ware?, ¿es completo?, ¿está diseñado para mejorar el causa del trabajo baldío en software. Es esencial una des-
tiempo de entrega mientras mantiene un enfoque de cripción formal y detallada del ámbito de la información,
calidad? En muchos casos, la respuesta a todas estas funciones, comportamiento, rendimiento, interfaces, liga-
preguntas es «no». duras del diseño y criterios de validación. Estas caracte-
rísticas pueden determinarse sólo después de una
exhaustiva comunicación entre el cliente y el analista.
Mito. Los requisitos del proyecto cambian conti-
nuamente, pero los cambios pueden acomodarse fácil-
mente, ya que el software es flexible.

Mito. Mi gente dispone de las herramientas de desa- l a gestión y control de cambio esm tratada
rrollo de software más avanzadas, después de todo, les con detalle en el Capítulo 9
compramos las computadoras más modernas.
Realidad. Se necesita mucho más que el último
modelo de computadora grande o de PC para hacer desa-
rrollo de software de gran calidad. Las herramientas de
ingeniería del software asistida por computadora
(CASE) son más importantes que el hardware para con-
seguir buena calidad y productividad, aunque la mayo-
ría de los desarrolladores del software todavía no las
utilicen eficazmente.
Mito. Si fallamos en la planificación, podemos añadir
más programadores y adelantar el tiempo perdido (el lla-
mado algunas veces «concepto de la horda Mongoliana»). Definición Desarrollo Después
Realidad. El desarrollo de software no es un proce- de la entrega
so mecánico como la fabricación. En palabras de Bro- FIGURA 1.3. El impacto del cambio.
oks [BR075]: «...añadir gente a un proyecto de software
retrasado lo retrasa aún más». Al principio, esta declara- Realidad. Es verdad que los requisitos del softwa-
ción puede parecer un contrasentido. Sin embargo, cuan- re cambian, pero el impacto del cambio varía según el
do se añaden nuevas personas, la necesidad de aprender y momento en que se introduzca. La Figura 1.3 ilustra el
comunicarse con el equipo puede y hace que se reduzca la impacto de los cambios. Si se pone cuidado al dar la
cantidad de tiempo gastado en el desarrollo productivo. definición inicial, los cambios solicitados al principio
Puede añadirse gente, pero sólo de una manera planifica- pueden acomodarse fácilmente. El cliente puede revi-
da y bien coordinada. sar los requisitos y recomendar las modificaciones con
relativamente poco impacto en el coste. Cuando los cam-
bios se solicitan durante el diseño del software, el impac-
to en el coste crece rápidamente. Ya se han acordado los
recursos a utilizar y se ha establecido un marco de tra-
la red de gestión de proyectos de software bajo del diseño. Los cambios pueden producir trastor-
en www.sprnn.com puede ayudarle nos que requieran recursos adicionales e importantes
a desmitificar estos y otros mitos. modificaciones del diseño; es decir, coste adicional. Los
9


cambios en la función, rendimiento, interfaces u otras Mito. Hasta que no tengo el programa «ejecutándo-
características, durante la implementación (codificación se», realmente no tengo forma de comprobar su calidad.
y prueba) pueden tener un impacto importante sobre el Realidad. Desde el principio del proyecto se puede
coste. Cuando se solicitan al final de un proyecto, los aplicar uno de los mecanismos más efectivos para garan-
cambios pueden producir un orden de magnitud más tizar la calidad del software: la revisión técnica formal.
caro que el mismo cambio pedido al principio. La revisión del software (descrito en el Capítulo 8) es
Mitos de los desarrolladores. Los mitos en los que un «filtro de calidad» que se ha comprobado que es más
aún creen muchos desarrolladores se han ido fomen- efectivo que la prueba, para encontrar ciertas clases de
tando durante 50 años de cultura informática. Durante defectos en el software.
los primeros días del desarrollo del software, la pro-
Mito. Lo único que se entrega al terminar el pro-
gramación se veía como un arte. Las viejas formas y
yecto es el programa funcionando.
actitudes tardan en morir.
Mito. Una vez que escribimos el programa y hace- RealUiad. Un programa que funciona es sólo una par-
mos que funcione, nuestro trabajo ha terminado. te de una configuración del software que incluye muchos
elementos. La documentación proporciona el funda-
Realidad. Alguien dijo una vez: «cuanto más pronto mento para un buen desarrollo y, lo que es más impor-
se comience a escribir código, más se tardará en termi- tante, proporciona guías para la tarea de mantenimiento
narlo». Los datos industriales [LIE80, JON91, PUT971 del software.
indican que entre el 60 y el 80 por ciento de todo el
esfuerzo dedicado a un programa se realizará después Muchos profesionales del software reconocen la
de que se le haya entregado al cliente por primera vez. falacia de los mitos descritos anteriormente. Lamen-
tablemente, las actitudes y métodos habituales fomen-
tan una pobre gestión y malas prácticas técnicas,
incluso cuando la realidad dicta un método mejor. El
kobojo muy duro poro entender lo que tienes que hacer reconocimiento de las realidades del software es el
antes de empezar. No serías copoz de desorrollor codo primer paso hacia la formulación de soluciones prác-
detalle; por más que sepos, tomo el menor riesgo. ticas para su desarrollo.

El software se ha convertido en el elemento clave de ponen una configuración que se crea como parte del
la evolución de los sistemas y productos informáticos. proceso de la ingeniería del software. El intento de la
En los pasados 50 años, el software ha pasado de ser ingeniería del software es proporcionar un marco de
una resolución de problemas especializada y una herra- trabajo para construir software con mayor calidad.
mienta de análisis de información, a ser una industria
por sí misma. Pero la temprana cultura e historia de la
«programación» ha creado un conjunto de problemas
que persisten todavía hoy. El software se ha converti-
do en un factor que limita la evolución de los sistemas Cuando te pones o pensar, no encueniros tiempo poro lo
informáticos. El software se compone de programas, disciplino de lo ingeniería del sohare, y te preguntas:
datos y documentos. Cada uno de estos elementos com- ((2 kndré tiempo para poder hacerlo?))

[BR075] Brooks, F., The Mytical Man-Month, Addison-Wes- [GLA97] Glass, R. L., Software Runaways, Prentice Hall,
ley, 1975. 1997.
[DEJ98] De Jager, P., et al, Countdown Y2K: Business Sur- [GLA98] Glass, R. L.,«Is there Really a Software Crisis?»,
viva1 Planning for the Year 2000, Wiley, 1998. IEEE Sofmare, vol. 15, n." 1, Enero 1998, pp. 104-105.
[DEM95] De Marco, T., Why Does Software Cost So Much?, [HAM93] Hammer, M., y J. Champy, Reengineering rhe Cor-
Dorset House, 1995, p. 9. poration, HarpperCollins Publisher, 1993.
[FE1831Feigenbaum, E. A., y P. McCorduck, The Fith Gene- [-TON911Jones, C.,Applied Software Measurement, McGraw-
ration, Addison-Wesley, 1983. Hill, 1991.
[FL097] Flowers, S., Software Failure, Management Fui- [KAR99] Karlson, E., y J. Kolber, A Basic Introdiiction to
lure-Amaicing Stories and Cautionary Tails, Wiley, Y2K: How the Year 2000 Computer Crisis Affects You?,
1997 (?). Next Era Publications, Inc., 1999.

10

CAPfTULO 1 EL PRODUCTO Y EL PROCESO

[LEV95] Levy, S., «The Luddites Are Pack», Newsweek, 12 de [STO891 Stoll, C., The cuckoos Egg, Doubleday, 1989.
Julio de 1995, p. 55. [TOF80] Toffler, A., The Third Wave, Morrow Publishers,
[LEV99] Levy, S., «The New Digital Galaxy», Newsweek, 1980.
31 de Mayo de 1999, p.57. . [TOF90] Toffler, A., Powershif, Bantam Publishers, 1990.
[LIE80] Lientz, B., y E. Swanson, Software Maintenance [YOU92] Yourdon, E., The Decline and Fa11 of the Americun
Management, Addison Wesley, 1980. Programmer, Yourdon Press, 1992.
“A1821 Naisbitt, J., Megatoends, Warner Books, 1982. [YOU96] Yourdon, E., The Rise and Resurrection of the Ame-
[NOR98]Norman, D., The Invisible Computer,MIT Press, 1998. rican Programmer, Yourdon Press, 1996.
[OSB79] Osborne, A,, Running Wild-The Next Industrial [YOU98a] Yourdon, E., Death March Projects, Prentice-Hall,
Revolution, Osborne/McGraw-Hill, 1979. 1998.
[PUT97] Putnam, L., y W. Myers, Industrial Strength Soft- [YOU98b] Yourdon, E., y J. Yourdon, Time Bomb 2000, Pren-
ware, IEEE Computer Society Press, 1997. tice-Hall, 1998.

1.1. El software es la característica que diferencia a muchos 1.5. A medida que el software se difunde más, los riesgos para
productos y sistemas informáticos. Dé ejemplos de dos o tres el público (debido a programas defectuosos) se convierten en una
productos y de, al menos, un sistema en el que el software, no preocupación cada vez más significativa. Desarrolle un escena-
el hardware, sea el elemento diferenciador. rio realista del juicio final (distinto a Y2K) en donde el fallo de
computadora podría hacer un gran daño (económico o humano).
1.2. En los años cincuenta y sesenta la programación de com-
putadoras era un arte aprendido en un entorno básicamente 1.6. Lea detenidamente el grupo de noticias de Internet
experimental. ¿Cómo ha afectado esto a las prácticas de desa- comp.risk y prepare un resumen de riesgos para las personas
rrollo del software hoy? con las que se hayan tratado Últimamente. Código alternati-
1.3. Muchos autores han tratado el impacto de la «era de la vo: Software Engineering Notes publicado por la ACM.
información».Dé varios ejemplos (positivos y negativos) que 1.7. Escriba un papel que resuma las ventajas recientes en
indiquen el impacto del software en nuestra sociedad. Repa- una de las áreas de aplicaciones de software principales. Entre
se algunas referencias de la Sección 1.1 previas a 1990 e indi- las selecciones potenciales se incluyen: aplicaciones avanza-
que dónde las predicciones del autor fueron correctas y dónde das basadas en Web, realidad virtual, redes neuronales artifi-
no lo fueron. ciales, interfaces humanas avanzadas y agentes inteligentes.
1.4. Seleccione una aplicación específica e indique: (a) la 1.8. Los mitos destacados en la Sección 1.4 se están vinien-
categoría de la aplicación de software (Sección 1.2.2) en la do abajo lentamente a medida que pasan los años. Pero otros
que encaje; (b) el contenido de los datos asociados con la apli- se están haciendo un lugar. Intente añadir un mito o dos mitos
cación; (c) la información determinada de la aplicación. «nuevos» a cada categoría.

Literalmente existen miles de libros escritos sobre software do industrializado y casi todas las aplicaciones a la nueva
de computadora. La gran mayoría tratan los lenguajes de pro- infraestructura de Internet.
gramación o aplicaciones de software, y sólo unos pocos tra- Minasi (The Software Conspiracy: Why Software Com-
tan el software en sí. Pressman y Herron (Software Sock, panies Put Out Faulty Products, How They Can Hurt You,
Dorset House, 1991) presentaron una discusión (dirigida a no and What You Can Do, McGraw-Hill, 2000) argumentó que
profesionales) acerca del software y del modo en que lo cons- el «azote moderno» de los errores del software puede elimi-
truyen los profesionales. narse y sugiere formas para hacerlo. DeMarco (Why Does
El libro, éxito de ventas, de Negroponte (Being Digital, Software Cost So Much?, Dorset House, 1995) ha producido
Alfred A. Knopf, Inc., 1995) proporciona una visión de las una colección de ensayos divertidos e interesantes sobre el
computadoras y de su impacto global en el siglo XXI. Los software y el proceso a través del cual se desarrolla.
libros de Norman [NOR98] y Bergman (Information En Intemet están disponibles una gran variedad de fuen-
Appliances & Beyond, Academic Pres/Morgan Kauffman, tes de información relacionadas con temas de gestión y de
2000) sugieren que el impacto extendido del PC declinará software. Se puede encontrar una lista actualizada con refe-
al mismo tiempo que las aplicaciones de información y rencias a sitios (páginas) web relevantes en http://www.press-
la difusión de la programación conecten a todos en el mun- man5.com.

11

CAPÍTULO

H
OWARD Baetjer, Jr. [BAE98], en un libro fascinante que proporciona un punto d e
vista economicista del software y de la ingeniería del software, comenta sobre el
proceso:
Como el software, al igual que el capital, es el conocimiento incorporado, y puesto que el conocimiento
está inicialmente disperso, el desarrollo del software implícito, latente e incompleto en gran medida, es un
proceso social de aprendizaje. El proceso es un diálogo en el que se reúne el conocimiento y se incluye en
el software para convertirse en software. El proceso proporciona una interacción entre los usuarios y los
diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramien-
tas de desarrollo [tecnología]. Es un proceso interactivo donde la herramienta de desarrollo se usa como
medio de comunicación, con cada iteración del diálogo se obtiene mayor conocimiento de las personas
involucradas.
Realmente, construir software de computadora es un proceso de aprendizaje iterativo, y el
resultado, algo que Baetjer podría llamar «capital del software», es el conjunto del software
reunido. denurado v orpanizado mientras se desarrolla el Droceso.

;Qué es? Cuando trabaja para construir ¿Por qué es importante? Porque pro- software, los productos obtenidos son
un producto o un sistema, es impor- porciona estabilidad, control y organi- programas, documentos y datos gue se
tante seguir una serie d e pasos pre- zación a una actividad que puede, si producen como consecuencia d e l a s
decibles -un mapa de carreteras que no se controla, volverse caótica. actividades de ingeniería del software
le ayude a obtener el resultado opor- ¿Cuáies son los pasos? A un nivel deta- definidas por el proceso.
tuno de calidad-. El mapa de carre- llado, el proceso que adoptemos ¿Cómo puedo estar seguro de que
teras a seguir es llamado .proceso del depende del software que estamos lo he hecho correctamente?Hay
software.. construyendo. Un proceso puede ser una cantidad de mecanismos d e eva-
lo
&Quién hace? Los ingenieros de soft- apropiado para crear software de un luacion del proceso del software que
ware y sus gestores adaptan el proce- sistema de aviación, mientras que un permiten a las organizaciones deter-
so a sus necesidades y entonces lo proceso diferente por completo puede minar la «madurez. de su proceso del
siguen. Además las personas que han ser adecuado para la creación d e un software. Sin embargo, la calidad, opor-
solicitado el software tienen un papel sitio web. tunidad y viabilidad a largo plazo del
a desempeñar en el proceso del soft- &Cuál es el producto obtenido? Des- producto que está construyendo son los
ware. de el punto de vista de un ingeniero d e mejores indicadores de la eficiencia del
proceso que estamos utilizando.

Pero, ¿qué es exactamente el proceso del software desde un punto de vista técnico? Dentro del con-
texto de este libro, 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 softwa-
re? La respuesta es «sí» y «no». Un proceso de software define el enfoque que se toma cuando el soft-
ware 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 conoci-
miento, que deberían trabajar dentro de un proceso del software definido y avanzado que es apropia-
do para los productos que construyen y para las demandas de su mercado. La intención de este capítulo
es proporcionar un estudio del estado actual del proceso del software y puntualizar sobre el estudio
detallado de los temas de gestión y técnicos presentados en este libro.
13

INGENIERfA DEL SOFTWARE. U N E N F O Q U E PR A C TI CO

Aunque cientos de autores han desarrollado definicio-
nes personales de la ingeniería del software, una defi-
nición propuesta por Fritz Bauer [NAU69] en una
conferencia de gran influencia sobre estos temas va a
servir como base de estudio:

FIGURA 2.1. Capas de la ingeniería del software.

El fundamento de la ingeniería del software es la
capa de proceso. El proceso de la ingeniería del soft-
ware es la unión que mantiene juntas las capas de tec-
nología y que permite un desarrollo racional y oportuno
de la ingeniería del software. El proceso define un mar-
[La ingeniería del software] es el establecimiento y uso de prin- co de trabajo para un conjunto de Úreas clave de pro-
cipios robustos de la ingeniería a fin de obtener económicamente
ceso (ACPs) [PAU93] que se deben establecer para la
software que sea fiable y que funcione eficientemente sobre máqui-
nas reales. entrega efectiva de la tecnología de la ingeniería del
software. Las áreas claves del proceso forman la base
Casi todos los lectores tendrán la tentación de del control de gestión de proyectos del software y esta-
seguir esta definición. No dice mucho sobre los aspec- blecen el contexto en el que se aplican los métodos téc-
tos técnicos de la calidad del software; no se enfren- nicos, se obtienen productos del trabajo (modelos,
ta directamente con la necesidad de la satisfacción del documentos, datos, informes, formularios, etc.), se esta-
cliente o de la entrega oportuna del producto; omite blecen hitos, se asegura la calidad y el cambio se ges-
la mención de la importancia de mediciones y métri- tiona adecuadamente.
cas; tampoco expresa la importancia de un proceso Los métodos de la ingeniería del software indican
avanzado. Y sin embargo, la definición de Bauer nos «cómo» construir técnicamente el software. Los méto-
proporciona una línea base. ¿Cuáles son los «princi- dos abarcan una gran gama de tareas que incluyen aná-
pios robustos de la ingeniería» aplicables al desarro- lisis de requisitos, diseño, construcción de programas,
llo de software de computadora? ¿Cómo construimos pruebas y mantenimiento. Los métodos de la ingeniería
el software «económicamente» para que sea «fiable»? del software dependen de un conjunto de principios bási-
¿Qué se necesita para crear programas de computa- cos que gobiernan cada área de la tecnología e incluyen
dora que funcionen «eficientemente» no en una máqui- actividades de modelado y otras técnicas descriptivas.
na si no en diferentes «máquinas reales»? Éstas son
cuestiones que siguen siendo un reto para los inge-
nieros del software.
s
i&
CLAVE
l a Ingeniería de software comprende un proceso,
¿Cómo definimos la métodos técnicos y de gestión, y herramientas.
Ingeniería del software?

Las herramientas de la Ingeniería del software pro-
El IEEE [IEE93] ha desarrollado una definición más porcionan un enfoque automático o semi-automáticopara
completa: el proceso y para los métodos. Cuando se integran herra-
Ingeniería del software: (1) La aplicación de un enfoque sis- mientas para que la información creada por una herra-
temático, disciplinado y cuantificable hacia el desarrollo, opera- mienta la pueda utilizar otra, se establece un sistema de
ción y mantenimiento del software; es decir, la aplicación de soporte para el desarrollo del software llamado ingenie-
ingeniería al software. (2) El estudio de enfoques como en (1). ría del software asistida por computadora (CASE).

2.1.1. Proceso, métodos y herramientas 2.1.2. Una visión general de la ingeniería del
software
La Ingeniería del software es un tecnología multica-
pa. Como muestra la Figura 2.1, cualquier enfoque de La ingeniería es el análisis, diseño, construcción, veri-
ingeniería (incluida ingeniería del software) debe apo- ficación y gestión de entidades técnicas (o sociales).
yarse sobre un compromiso de organización de cali- Con independencia de la entidad a la que se va a apli-
dad. car ingeniería, se deben cuestionar y responder las
siguientes preguntas:

14

CAPfTULO 2 EL PROCESO

¿Cuál es el problema a resolver? La fase de desarrollo se centra en el cómo. Es decir,
¿Cuáles son las características de la entidad que se durante el desarrollo un ingeniero del software intenta
utiliza para resolver el problema? definir cómo han de diseñarse las estructuras de datos,
cómo ha de implementarse la función dentro de una
¿Cómo se realizará la entidad (y la solución)? arquitectura de software, cómo han de implementarse
¿Cómo se construirá la entidad? los detalles procedimentales, cómo han de caracteri-
zarse interfaces, cómo ha de traducirse el diseño en un
¿Qué enfoque se va a utilizar para no contemplar los
lenguaje de programación (o lenguaje no procedimen-
errores que se cometieron en el diseño y en la cons-
tal) y cómo ha de realizarse la prueba. Los métodos apli-
trucción de la entidad?
cados durante la fase de desarrollo variarán, aunque las
¿Cómo se apoyará la entidad cuando usuarios soli- tres tareas específicas técnicas deberían ocurrir siem-
citen correcciones, adaptaciones y mejoras de la enti- pre: diseño del software (Capítulos 14, 15 y 21), gene-
dad? ración de código y prueba del software (Capítulos 16,
17 y 22).

3
Referencia Web
lrosstdk es un periódico que proporciona conseios y
comentarios prócticos de ingeniería del software. Estón
disponibles temas relocionados directamente en:
www.stc.hill.af.mil
A lo largo de este libro, nos vamos a centrar en
una sola entidad -el software de computadora-.
Para construir la ingeniería del software adecuada-
mente, se debe definir un proceso de desarrollo de
software. En esta sección se consideran las caracte- La fase de mantenimiento se centra en el cambio que
rísticas genéricas del proceso de software. Más ade- va asociado a la corrección de errores, a las adaptacio-
lante, en este mismo capítulo, se tratarán modelos nes requeridas a medida que evoluciona el entorno del
específicos de procesos. software y a cambios debidos a las mejoras producidas
El trabajo que se asocia a la ingeniería del software por los requisitos cambiantes del cliente. Durante la fase
se puede dividir en tres fases genéricas, con indepen- de mantenimiento se encuentran cuatro tipos de cam-
dencia del área de aplicación, tamaño o complejidad del bios:
proyecto. Cada fase se encuentra con una o varias cues- Corrección. Incluso llevando a cabo las mejores acti-
tiones de las destacadas anteriormente. vidades de garantía de calidad, es muy probable que el
Lafase de definición se centra sobre el qué. Es decir, cliente descubra los defectos en el software. El mante-
durante la definición, el que desarrolla el software inten- nimiento correctivo cambia el software para corregir los
ta identificar qué información ha de ser procesada, qué defectos.
función y rendimiento se desea, qué comportamiento Adaptación. Con el paso del tiempo, es probable
del sistema, qué interfaces van a ser establecidas, qué que cambie el entorno original (por ejemplo: CPU, el
restricciones de diseño existen, y qué criterios de vali- sistema operativo, las reglas de empresa, las caracte-
dación se necesitan para definir un sistema correcto. Por rísticas externas de productos) para el que se desarro-
tanto, han de identificarse los requisitos clave del siste- lló el software. El mantenimiento adaptativo produce
ma y del software. Aunque los métodos aplicados duran- modificación en el software para acomodarlo a los cam-
te la fase de definición variarán dependiendo del bios de su entorno externo.
paradigma de ingeniería del software (o combinación
Mejora. Conforme se utilice el software, el clien-
de paradigmas) que se aplique, de alguna manera ten-
te/usuario puede descubrir funciones adicionales que
drán lugar tres tareas principales: ingeniería de sistemas
van a producir beneficios. El mantenimiento perfectivo
o de información (Capítulo lo), planificación del pro-
lleva al software más allá de sus requisitos funcionales
yecto del software (Capítulos 3, 5 , 6 y 7) y análisis de
originales.
los requisitos (Capítulos 11, 12 y 21).
Prevención. El software de computadora se dete-
riora debido al cambio, y por esto el mantenimientopre-
ventivo también llamado reingeniería del software, se
?$
¿% debe conducir a permitir que el software sirva para las
CLAVE necesidades de los usuarios finales. En esencia, el man-
El software se crea aplicondo tres fases distintas que se tenimiento preventivo hace cambios en programas de
centran en la definición, desarrollo y mantenimiento. computadora a fin de que se puedan corregir, adaptar y
mejorar más fácilmente.
15


Además de estas actividades de mantenimiento, los
usuarios de software requieren un mantenimiento con-
tinuo. Los asistentes técnicos a distancia, teléfonos de
ayuda y sitios Web de aplicaciones específicas se imple-
mentan frecuentemente como parte de la fase de man-
tenimiento. Actividades de protección
Entre las actividades típicas de esta categoría se incluyen:
Seguimiento y control del proyecto de software
Cuando utilizamos el término «mantenimiento»
reconocemos que es mucho más que una simple
Revisiones técnicas formales
corrección de errores. Garantía de calidad del software
Hoy en día, el aumento de los programas' legales Gestión de configuración del software
está forzando a muchas compañías a seguir estrategias Preparación y producción de documentos
de reingeniería del software (Capítulo 30). En un sen- Gestión de reutilización
tido global, la reingeniería del software se considera a Mediciones
menudo como una parte de la reingeniería de procesos
comerciales [STA95]. Gestión de riesgos
Las fases y los pasos relacionados descritos en nues- Las actividades de protección se aplican a lo largo
tra visión genérica de la ingeniería del software se com- de todo el proceso del software y se tratan en las partes
plementan con un número de actividades protectoras. Segunda y Quinta del libro.

Un proceso de software se puede caracterizar como se del proyecto. Finalmente, las actividades de protección
muestra en la Figura 2.2. Se establece un marco común -tales como garantía de calidad del software, gestión de
del proceso definiendo un pequeño número de activida- configuración del software y medición*-abarcan el
des del marco de trabajo que son aplicables a todos los modelo de procesos. Las actividades de protección son
proyectos del software, con independencia de su tamaño independientes de cualquier actividad del marco de tra-
o complejidad. Un número de conjuntos de tareas - c a d a bajo y aparecen durante todo el proceso.
uno es una colección de tareas de trabajo de ingeniería En los Últimos años, se ha hecho mucho énfasis en
del software, hitos de proyectos, productos de trabajo, y la «madurez del proceso>>. Softwate Engineering Ins-
El
puntos de garantía de calidad-que permiten que las acti- titute (SEI)3 ha desarrollado un modelo completo que
vidades del marco de trabajo se adapten a las caracterís- se basa en un conjunto de funciones de ingeniería del
ticas del proyecto del software y a los requisitos del equipo software que deberían estar presentes conforme orga-
nizaciones alcanzan diferentes niveles de madurez del
proceso. Para determinar el estado actual de madurez
del proceso de una organización, el SE1 utiliza un cues-
Actividades del marco de trabajo tionario de evaluación y un esquema de cinco grados.

Tareas *m li"'
Seleccione un marco de trabajo del proceso común que se
odecue al producto, o1 personal y o1 proyecto.

El esquema de grados determina la conformidad con
un modelo de capacidad de madurez [PAU93] que defi-
ne las actividades clave que se requieren en los dife-
rentes niveles de madurez del proceso. El enfoque del
FIGURA 2.2. El proceso del software. SE1 proporciona una medida de la efectividad global de

El término .programas iegales~~ un eufemismo para el sottware
es Estos temas se tratan con más detalle en capítulos posteriores.
antiguo, a menudo diseñado y documentado pobremente, que es crí- El autor se está refiriendo al SE1 de la Cannegie Mellon University.
tico para el negocio y debe ser soportado durante algunos años.

16

CAPÍTULO 2 EL PROCESO

las prácticas de ingeniería del software de una compa- ción ha sido detallado y se hace cumplir por medio de
ñía y establece cinco niveles de madurez del proceso, procedimientos tales como auditorías. Este nivel es aquel
que se definen de la forma siguiente: en el que la mayoría de los desarrolladores de softwa-
Nivel 1: Inicial. El proceso del software se caracte- re, pretenden conseguir con estándares como el ISO
riza según el caso, y ocasionalmente incluso de forma 9001, y existen pocos casos de desarrolladores de soft-
caótica. Se definen pocos procesos, y el éxito depende ware que superan este nivel.
del esfuerzo individual. El nivel 4 comprende el concepto de medición y el
uso de métricas. El capítulo 4 describe este tema con más
Nivel 2: Repetible. Se establecen los procesos de
detalle. Sin embargo, cabe destacar el concepto de métri-
gestión del proyecto para hacer seguimiento del coste,
ca para comprender la importancia que tiene que el desa-
de la planificación y de la funcionalidad. Para repetir
rrollador del software alcance el nivel 4 o el nivel 5.
éxitos anteriores en proyectos con aplicaciones simila-
Una métrica es una cantidad insignificanteque puede
res se aplica la disciplina necesaria para el proceso.
extraerse de algún documento o código dentro de un pro-
Nivel 3: Definido. El proceso del software de las yecto de software. Un ejemplo de métrica es el número
actividades de gestión y de ingeniería se documenta, se de ramas condicionales en una sección de código de un
estandariza y se integra dentro de un proceso de soft- programa. Esta métrica es significativa en el sentido de
ware de toda una organización. Todos los proyectos uti- que proporciona alguna indicación del esfuerzo necesa-
lizan una versión documentada y aprobada del proceso rio para probar el código: está directamente relacionado
de la organización para el desarrollo y mantenimiento con el número de caminos de prueba dentro del código.
del software. En este nivel se incluyen todas las carac- Una organización del nivel 4 maneja numerosas
terísticas definidas para el nivel 2. métricas. Estas métricas se utilizan entonces para super-
Nivel 4: Gestionado. Se recopilan medidas deta- visar y controlar un proyecto de software, por ejemplo:
lladas del proceso del software y de la calidad del pro- Una métrica de prueba puede usarse para determinar
ducto. Mediante la utilización de medidas detalladas,
cuándo finalizar la prueba de un elemento del código.
se comprenden y se controlan cuantitativamente tan-
to los productos como el proceso del software. En este Una métrica de legilibilidad puede usarse para juz-
nivel se incluyen todas las características definidas gar la legilibilidad de algún documento en lenguaje
para el nivel 3. natural.
Nivel 5: Optimización. Mediante una retroalimen- Una métrica de comprensión del programa puede uti-
tación cuantitativa del proceso, ideas y tecnologías inno- lizarse para proporcionar algún umbral numérico que
vadoras se posibilita una mejora del proceso. En este los programadores no pueden cruzar.
nivel se incluyen todas las características definidas para Para que estas métricas alcancen este nivel es nece-
el nivel 4. sario que todos los componentes del nivel 3 CMM, en

3
Referenciu Web
El llS ofrece un amplio conjunto de información
relacionada con el proceso en www.sei.cmu.edu
castellano MCM (Modelo de Capacidad de Madurez),
estén conseguidos, por ejemplo notaciones bien defini-
das para actividades como la especificación del diseño
de requisitos, por lo que estas métricas pueden ser fácil-
mente extraídas de modo automático.
El nivel 5 es el nivel más alto a alcanzar. Hasta aho-
Merece la pena destacar que cada nivel superior es ra, muy pocos desarrolladores de software han alcan-
la suma de los niveles anteriores, por ejemplo, un desa- zado esta fase. Representa la analogía del software con
rrollador de software en el nivel 3 tiene que haber alcan- los mecanismos de control de calidad que existen en
zado el estado nivel 2 para poder disponer de sus otras industrias de mayor madurez. Por ejemplo el fabri-
procesos en el nivel 3. cante de un producto industrial como un cojinete de
El nivel 1 representa una situación sin ningún esfuer- bolas (rodamiento) puede supervisar y controlar la cali-
zo en la garantía de calidad y gestión del proyecto, don- dad de los rodamientos producidos y puede predecir esta
de cada equipo del proyecto puede desarrollar software calidad basándose en los procesos y máquinas utiliza-
de cualquier forma eligiendo los métodos, estándares y dos para desarrollar los rodamientos. Del mismo modo
procedimientos a utilizar que podrán variar desde lo que el desarrollador del sofware en el nivel 5 puede pre-
mejor hasta lo peor. decir resultados como el número de errores latentes en
El nivel 2 representa el hecho de que un desarrolla- un producto basado en la medición tomada durante la
dor de software ha definido ciertas actividades tales ejecución de un proyecto. Además, dicho desarrollador
como el informe del esfuerzo y del tiempo empleado, y puede cuantificar el efecto que un proceso nuevo o herra-
el informe de las tareas realizadas. mienta de manufacturación ha tenido en un proyecto
El nivel 3 representa el hecho de que un desarrolla- examinando métricas para ese proyecto y comparándo-
dor de software ha definido tanto procesos técnicos como las con proyectos anteriores que no utilizaron ese pro-
de gestión, por ejemplo un estándar para la programa- ceso o herramienta.
17

INGENIERfA DEL SOFTWARE. U N E N F O Q U E PRÁCTICO

En este orden debe destacarse que para que un desa-
rrollador 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
Referencia Web/ ’-
nivel 3. Si el desarrollador del software no tiene defi- Una versi6n tabular del MCM completo del llS, incluyendo
nidos rigurosamente los procesos pueden ocurrir una todos los objetivos, comentarios, habilidades y
actividades estó disponible en
gran cantidad de cambios en el proceso de desarrollo
sepo.nosc.mil/CMMmatrices.html
y no se podrán utilizar las estadísticas para estas acti-
vidades.
Los cinco niveles definidos por el SE1 se obtienen madurez y se distribuyen en niveles diferentes de madu-
como consecuencia de evaluar las respuestas del cues- rez del proceso. Las ACPs se deberían lograr en cada
tionario de evaluación basado en el MCM (Modelo de nivel de madurez de proceso4:
capacidad de madurez). Los resultados del cuestiona- Nivel 2 de Madurez del Proceso
rio se refinan en un único grado numérico que propor- Gestión de configuración del software
ciona una indicación de la madurez del proceso de una
organización. Garantía de calidad del software
El SE1 ha asociado áreas claves del proceso Gestión de subcontratación del software
(ACPs) a cada uno de los niveles de madurez. Las Seguimiento y supervisión del proyecto del software
ACPs describen esas funciones de la ingeniería del
software (por ejemplo: planificación del proyecto de Planificación del proyecto del software
software, gestión de requisitos) que se deben pre- Gestión de requisitos
sentar para satisfacer una buena práctica a un nivel Nivel 3 de Madurez del Proceso
en particular. Cada ACP se describe identificando las
Revisiones periódicas
características siguientes:
Coordinación entre grupos
Ingeniería de productos de software
lodo organización debería esforzarse poro olconzor
Gestión de integración del software
lo profundidad del MíM del IIS. Sin embargo, Programa de formación
lo implementoción de cualquier aspecto del modelo Definición del proceso de la organización
puede eliminarse en su situación.
Enfoque del proceso de la organización
Objetivos- los objetivos globales que debe alcan- Nivel 4 de Madurez del Proceso
zar la ACP Gestión de calidad del software
Compromisos-requisitos (impuestos en la organi- Gestión cuantitativa del proceso
zación) que se deben cumplir para lograr los objeti-
vos y que proporcionan una prueba del intento por Nivel 5 de Madurez del Proceso
ajustarse a los objetivos. Gestión de cambios del proceso
Capacidades-aquellos elementos que deben encon- Gestión de cambios de tecnología
trarse (organizacional y técnicamente) para permitir Prevención de defectos
que la organización cumpla los objetivos.
Actividades- las tareas específicas que se requieren Cada una de las ACPs se definen con un conjunto
para lograr la función ACP. de prácticas clave que contribuyen a cumplir estos obje-
tivos. Las prácticas clave son normas, procedimientos
Métodos para supervisar la implementación-la y actividades que deben ocurrir antes de que se haya
manera en que las actividades son supervisadas con- instituido completamente un área clave de proceso. El
forme se aplican. SE1 define a los indicudores clave como «aquellas prác-
Métodos para verificar la implementución-la forma ticas clave o componentes de prácticas clave que ofre-
en que se puede verificar la práctica adecuada para cen una visión mejor para lograr los objetivos de un
la ACP. área clave de proceso». Las cuestiones de valoración
Se definen dieciocho ACPs (descritas mediante la se diseñan para averiguar la existencia (o falta) de un
estructura destacada anteriormente) en el modelo de indicador clave.

Téngase en cuenta que las ACPs son acumulativas. Por ejemplo, el
nivel 3 de madurez del proceso contiene todas las ACPs del nivel 2
más las destacadas para el nivel 1 .

18


E
2
-. >
P
Para resolver los problemas reales de una industria, un completo, las etapas descritas anteriormente se aplican
ingeniero del software o un equipo de ingenieros debe recursivamente a las necesidades del usuario y a la espe-
incorporar una estrategia de desarrollo que acompañe cificación técnica del desarrollador del software.
al proceso, métodos y capas de herramientas descritos

“*ed
en la Sección 2.1.1 y las fases genéricas discutidas en
la Sección 2.1.2. Esta estrategia a menudo se llama
modelo de proceso o paradigma de ingeniería del soft- c VE
ware. Se selecciona un modelo de proceso para la inge- Todas las etapas de un proceso del software - e s t a d o
niería del software según la naturaleza del proyecto y actual, definición del problema, desarrollo técnico e
de la aplicación, los métodos y las herramientas a utili- integración de la solución- coexisten simultáneamente
zarse, y los controles y entregas que se requieren. En en algún nivel de detalle.
un documento intrigante sobre la naturaleza del proce-
so del software, L.B.S. Raccoon [RAC95] utiliza frac- En las secciones siguientes, se tratan diferentes mode-
tales como base de estudio de la verdadera naturaleza los de procesos para la ingeniería del software. Cada
del proceso del software. una representa un intento de ordenar una actividad inhe-
rentemente caótica. Es importante recordar que cada
uno de los modelos se han caracterizado de forma que
ayuden (con esperanza) al control y a la coordinación
de un proyecto de software real. Y a pesar de eso, en el
fondo, todos los modelos exhiben características del
«Modelo del Caos».

Definición
Todo el desarrollo del software se puede caracteri- de problemas
zar como bucle de resolución de problemas (Fig. 2.3a)
en el que se encuentran cuatro etapas distintas: «status
quo», definición de problemas, desarrollo técnico e inte-
Desarrollo
gración de soluciones. Status quo «representa el estado técnico
actual de sucesos» [RAC95]; la definición de proble-
mas identifica el problema específico a resolverse; el

t
desarrollo técnico resuelve el problema a través de la
aplicación de alguna tecnología y la integración de solu- Integración
ciones ofrece los resultados (por ejemplo: documentos, de soluciones
programas, datos, nueva función comercial, nuevo pro-
ducto) a los que solicitan la solución en primer lugar.
Las fases y los pasos genéricos de ingeniería del soft-
ware definidos en la Sección 2.1.2 se divide fácilmen-
te en estas etapas. >
En realidad, es difícil compartimentar actividades de
manera tan nítida como la Figura 2.3.b da a entender,
porque existen interferencias entre las etapas. Aunque
esta visión simplificada lleva a una idea muy impor-
tante: con independencia del modelo de proceso que se Estado
seleccione para un proyecto de software, todas las eta- actual
pas -status quo, definición de problemas, desarrollo
técnico e integración de soluciones-coexisten simul-
táneamente en algún nivel de detalle. Dada la naturale-
za recursiva de la Figura 2.3b, las cuatro etapas tratadas
anteriormente se aplican igualmente al análisis de una
aplicación completa y a la generación de un pequeño
segmento de código.
Raccoon [RAC95] sugiere un «Modelo del Caos»
que describe el «desarrollodel software como una exten- FIGURA 2.3.a) Las fases de un bucle de resolución de pro-
sión desde el usuario hasta el desarrollador y la tecno- blemas [RAC 951. b) Fases dentro de las fases
logía». Conforme progresa el trabajo hacia un sistema del bucle de resolución de problemas [RAC 951.

19


2.4
Llamado algunas veces «ciclo de vida básico» o cmode- se pueda evaluar su calidad antes de que comience la
lo en cascada», el modelo lineal secuencial sugiere un codificación.
enfoque5 sistemático, secuencial, para el desarrollo del Generación de código. El diseño se debe traducir
software que comienza en un nivel de sistemas y pro- en una forma legible por la máquina. El paso de gene-
gresa con el análisis, diseño, codificación, pruebas y man- ración de código lleva a cabo esta tarea. Si se lleva a
tenimiento. La Figura 2.4 muestra el modelo lineal cabo el diseño de una forma detallada, la generación de
secuencial para la ingeniería del software. Modelado código se realiza mecánicamente.
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 Aunque el modelo lineal es a menudo denominado
más grande (o empresa), el trabajo comienza estable- «modelo tradicional», resulto un enfoque razonable
ciendo requisitos de todos los elementos del sistema y cuando los requisitos se han entendido correctomente.
asignando al software algún subgrupo de estos requisi-
tos. Esta visión del sistema es esencial cuando el soft- Pruebas. Una vez que se ha generado el código,
ware se debe interconectar con otros elementos como comienzan las pruebas del programa. El proceso de prue-
hardware, personas y bases de datos. La ingeniería y el bas se centra en los procesos lógicos internos del soft-
análisis de sistemas comprende los requisitos que se ware, asegurando que todas las sentencias se han
recogen en el nivel del sistema con una pequeña parte comprobado, y en los procesos externos funcionales; es
de análisis y de diseño. La ingeniería de información decir, realizar las pruebas para la detección de errores
abarca los requisitos que se recogen en el nivel de y asegurar que la entrada definida produce resultados
empresa estratégico y en el nivel del área de negocio. reales de acuerdo con los resultados requeridos.
Mantenimiento. El software indudablemente sufrirá
cambios después de ser entregado al cliente (una excep-
ción posible es el software empotrado). Se producirán
cambios porque se han encontrado errores, porque el soft-
ware debe adaptarse para acoplarse a los cambios de su
entorno externo (por ejemplo: se requiere un cambio debi-
do a un sistema operativo o dispositivo periférico nue-
vo), o porque el cliente requiere mejoras funcionales o
de rendimiento. El soporte y mantenimiento del softwa-
re vuelve a aplicar cada una de las fases precedentes a un
programa ya existente y no a uno nuevo.
FIGURA 2.4. El modelo lineal secuencial. El modelo lineal secuencial es el paradigma más anti-
guo y más extensamente utilizado en la ingeniería del
Análisis de los requisitos del software. El proceso software. Sin embargo, la crítica del paradigma ha pues-
de reunión de requisitos se intensifica y se centra espe- to en duda su eficacia [HAN95]. Entre los problemas
cialmente en el software. Para comprender la naturaleza que se encuentran algunas veces en el modelo lineal
del (los) programa(s) a construirse, el ingeniero («aria- secuencial se incluyen:
lista») del software debe comprender el dominio de
información del software (descrito en el Capítulo 1l), así ¿Por qué falla algunas veces
como la función requerida, comportamiento,rendimien- el modelo lineal?
to e interconexión.
Diseño. El diseño del software es realmente un pro-
ceso de muchos pasos que se centra en cuatro atributos 1. Los proyectos reales raras veces siguen el modelo
distintos de programa: estructura de datos, arquitectu- secuencial que propone el modelo. Aunque el modelo
ra de software, representaciones de interfaz y detalle lineal puede acoplar interacción, lo hace indirecta-
procedimental (algoritmo). El proceso del diseño tra- mente. Como resultado, los cambios pueden causar
duce requisitos en una representación del software donde confusión cuando el equipo del proyecto comienza.

Aunque el modelo original en cascada propuesto por Winston Royce
[ROY70] hacía provisiones para ((buclesde realimentación)b, la gran
mayoría d e las organizaciones que aplican este modelo de proceso
lo hacen como si fuera estrictamente lineal.

20


A menudo es difícil que el cliente exponga explíci- Cada uno de estos errores es real. Sin embargo, el
tamente todos los requisitos. El modelo lineal secuen- paradigma del ciclo de vida clásico tiene un lugar defi-
cial lo requiere y tiene dificultades a la hora de nido e importante en el trabajo de la ingeniería del soft-
acomodar la incertidumbre natural al comienzo de ware. Proporciona una plantilla en la que se encuentran
muchos proyectos. métodos para análisis, diseño, codificación, pruebas y
El cliente debe tener paciencia. Una versión de tra- mantenimiento. El ciclo de vida clásico sigue siendo el
bajo del (los) programa(s) no estará disponible hasta modelo de proceso más extensamente utilizado por la
que el proyecto esté muy avanzado. Un grave error ingeniería del software. Pese a tener debilidades, es sig-
puede ser desastroso si no se detecta hasta que se nificativamente mejor que un enfoque hecho al azar para
revisa el programa. el desarrollo del software.

Un cliente, a menudo, define un conjunto de objetivos
generales para el software, pero no identifica los requi-
sitos detallados de entrada, proceso o salida. En otros Escuchar Construir/revisar
casos, el responsable del desarrollo del software puede al cliente
no estar seguro de la eficacia de un algoritmo, de la capa-
cidad de adaptación de un sistema operativo, o de la for-
ma 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 ofre-
cer el mejor enfoque.
El paradigma de construcción de prototipos (Fig. El cliente
prueba
2.5) comienza con la recolección de requisitos. El desa- la maqueta
rrollador y el cliente encuentran y definen los objeti-
vos globales para el software, identifican los requisitos
conocidos y las áreas del esquema en donde es obli-
v 4
FIGURA 2.5. El paradigma de construcción de prototipos.
gatoria más definición. Entonces aparece un «diseño
rápido». El diseño rápido se centra en una representa-
ción de esos aspectos del software que serán visibles Pero ¿qué hacemos con el prototipo una vez que ha
para el usuario/cliente (por ejemplo: enfoques de entra- servido para el propósito descrito anteriormente? Brooks
da y formatos de salida). El diseño rápido lleva a la [BR075] proporciona una respuesta:
construcción de un prototipo. El prototipo lo evalúa el
cliente/usuario y se utiliza para refinar los requisitos En la mayoría de los proyectos, el primer sistema construido
del software a desarrollar. La iteración ocurre cuando apenas se puede utilizar. Puede ser demasiado lento, demasiado
el prototipo se pone a punto para satisfacer las nece- grande o torpe en su uso, o las tres a la vez. No hay otra alterna-
tiva que comenzar de nuevo, aunque nos duela pero es más inte-
sidades del cliente, permitiendo al mismo tiempo que ligente, y construir una versión rediseñada en la que se resuelvan
el desarrollador comprenda mejor lo que se necesita estos problemas ... Cuando se utiliza un concepto nuevo de siste-
hacer. ma 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 pilo-
to y tirarlo. Tendremos que hacerlo. La Única pregunta es si pla-
Cuando el cliente tiene uno necesidad legífimo, nificar de antemano construir un desechable, o prometer
pero esfó desorientado sobre los defulles, entregárselo a los clientes...
el primer poso es desarrollar un prototipo.
El prototipo puede servir como «primer sistema».
El que Brooks recomienda tirar. Aunque esta puede ser
Lo ideal sería que el prototipo sirviera como un meca- una visión idealizada. Es verdad que a los clientes y a
nismo para identificar los requisitos del software. Si se los que desarrollan les gusta el paradigma de cons-
construye un prototipo de trabajo, el desarrollador inten- trucción de prototipos. A los usuarios les gusta el sis-
ta hacer uso de los fragmentos del programa ya exis- tema real y a los que desarrollan les gusta construir algo
tentes o aplica herramientas (por ejemplo: generadores inmediatamente. Sin embargo, la construcción de pro-
de informes, gestores de ventanas, etc.) que permiten totipos también puede ser problemática por las siguien-
generar rápidamente programas de trabajo. tes razones:
21

INGENIERfA DEL SOFTWARE. U N E N F O Q U E PRÁCTICO

1. El cliente ve lo que parece ser una versión de trabajo para demostrar la capacidad. Después de algún
del software, sin tener conocimiento de que el pro- tiempo, el desarrollador debe familiarizarse con estas
totipo también está junto con «el chicle y el cable de selecciones, y olvidarse de las razones por las que
embalar», sin saber que con la prisa de hacer que son inadecuadas. La selección menos ideal ahora es
funcione no se ha tenido en cuenta la calidad del soft- una parte integral del sistema.
ware 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 Resisto lo presión de ofrecer un rnol prototipo en el
pide que se apliquen a n o s pequeños ajustes>> para producto finol. Corno resultado, lo colidod se resiente casi
que se pueda hacer del prototipo un producto final. siempre.
De forma demasiado frecuente la gestión de desa-
rrollo del software es muy lenta. Aunque pueden surgir problemas, la construcción de
2. El desarrollador, a menudo, hace compromisos de prototipos puede ser un paradigma efectivo para la inge-
implementación para hacer que el prototipo funcione niería del software. La clave es definir las reglas del jue-
rápidamente. Se puede utilizar un sistema operativo go al comienzo; es decir, el cliente y el desarrollador se
o lenguaje de programación inadecuado simplemente deben poner de acuerdo en que el prototipo se constru-
porque está disponible y porque es conocido; un algo- ya para servir como un mecanismo de definición de
ritmo eficiente se puede implementar simplemente requisitos.

El Desarrollo Rápido de Aplicaciones (DRA) un mode-
es Generación de aplicaciones. El DRA asume la uti-
lo de proceso del desarrollo del software lineal secuencial lización de técnicas de cuarta generación (Sección 2.10).
que enfatiza un ciclo de desarrollo extremadamente cor- En lugar de crear software con lenguajes de programa-
to. El modelo DRA es una adaptación a «alta velocidad» ción de tercera generación, el proceso DRA trabaja para
del modelo lineal secuencial en el que se logra el desa- volver a utilizar componentes de programas ya exis-
rrollo rápido utilizando una construcción basada en com- tentes (cuando es posible) o a crear componentes reuti-
ponentes. Si se comprenden bien los requisitos y se limita lizables (cuando sea necesario). En todos los casos se
el ámbito del proyecto, el proceso DRA permite al equi- utilizan herramientas para facilitar la construcción del
po de desarrollo crear un «sistema completamente fun- software.
cional» dentro de períodos cortos de tiempo (por ejemplo:
de 60 a 90 días) [MAR91]. Cuando se utiliza principal-
mente para aplicaciones de sistemas de información, el Equipo no 3
enfoque DRA comprende las siguientes fases [KER94]:
Modelado
Modelado de Gestión. El flujo de información entre Equipo no 1 degestión
las funciones de gestión se modela de forma que res-
ponda a las siguientes preguntas: ¿Qué información con- Modelado Modelado
duce el proceso de gestión? ¿Qué información se genera? de gestión de datos

¿Quién la genera? ¿A dónde va la información? ¿Quién
la procesa? El modelado de gestión se describe con más Modelado
de procesos
detalle en el Capítulo 10. Modelado
de datos
Modelado de datos. El flujo de información defini- Generación
1 de
do como parte de la fase de modelado de gestión se refi- aplicaciones
na como un conjunto de objetos de datos necesarios para Modelado
-7

apoyar la empresa. Se definen las características (lla- de procesos
madas atributos) de cada uno de los objetos y las rela-
ciones entre estos objetos. El modelado de datos se trata
Generación
en el Capítulo 12.
Modelado del proceso. Los objetos de datos defi-
nidos en la fase de modelado de datos quedan transfor-
mados para lograr el flujo de información necesario para Pruebas
implementar una función de gestión. Las descripciones y entrega
del proceso se crean para añadir, modificar, suprimir, o
recuperar un objeto de datos. b9
6-0
-0 dd
-í
sa

' En ingles: RAD (Rapid Application Deveiopment) El
FIGURA 2.6. modelo DRA.

22


Pruebas y entrega. Como el proceso DRA enfati- Al igual que todos los modelos de proceso, el enfo-
za la reutilización, ya se han comprobado muchos de que DRA tiene inconvenientes [BUT94]:
los componentes de los programas. Esto reduce tiempo Para proyectos grandes aunque por escalas, el D R A
de pruebas. Sin embargo, se deben probar todos los com- requiere recursos humanos suficientes como para
ponentes nuevos y se deben ejercitar todas las interfa- crear el número correcto de equipos DRA.
ces a fondo. D R A requiere clientes y desarrolladores compro-
metidos en las rápidas actividades necesarias para
completar un sistema en un marco de tiempo abre-
EDRA hace un fuerte uso de tomponentes
l viado. Si no hay compromiso por ninguna de las par-
reutilizobles. Paro mayor informotin sobre el
tes constituyentes, los proyectos DRA fracasarán.
desanollo de componentes, véase el Capítulo 27.
No todos los tipos de aplicaciones son apropiados
para DRA. Si un sistema no se puede modularizar
adecuadamente, la construcción de los componentes
El modelo de proceso DRA se ilustra en la Figura
necesarios para DRA será problemático. S está en
i
2.6. Obviamente, las limitaciones de tiempo impuestas
juego el alto rendimiento, y se va a conseguir el ren-
en un proyecto DRA demandan «ámbito en escalas»
dimiento convirtiendo interfaces en componentes de
[KER94]. Si una aplicación de gestión puede modular-
sistemas, el enfoque DRA puede que no funcione.
se de forma que permita completarse cada una de las
funciones principales en menos de tres meses (utilizando DRA no es adecuado cuando los riesgos técnicos son
el enfoque descrito anteriormente), es un candidato del altos. Esto ocurre cuando una nueva aplicación hace
DRA. Cada una de las funciones pueden ser afrontadas uso de tecnologías nuevas, o cuando el software
por un equipo DRA separado y ser integradas en un solo nuevo requiere un alto grado de interoperatividad
conjunto. con programas de computadora ya existentes.

PROC- SOFTWW
Se reconoce que el software, al igual que todos los sis- 2.7.1. El modelo incremental
temas complejos, evoluciona con el tiempo [GIL88]. El modelo incrernental combina elementos del modelo
Los requisitos de gestión y de productos a menudo cam- lineal secuencial (aplicados repetidamente) con la filo-
bian conforme a que el desarrollo proceda haciendo que sofía interactiva de construcción de prototipos. Como
el camino que lleva al producto final no sea real; las muestra la Figura 2.7, el modelo incremental aplica
estrictas fechas tope del mercado hacen que sea impo- secuencias lineales de forma escalonada mientras pro-
sible finalizar un producto completo, por lo que se debe gresa el tiempo en el calendario. Cada secuencia lineal
introducir una versión limitada para cumplir la presión produce un «incremento» del software [MDE93]. Por
competitiva y de gestión; se comprende perfectamente ejemplo, el software de tratamiento de textos desarro-
el conjunto de requisitos de productos centrales o del llado con el paradigma incremental podría extraer fun-
sistema, pero todavía se tienen que definir los detalles ciones de gestión de archivos básicos y de producción
de extensiones del producto o sistema. En estas y en de documentos en el primer incremento; funciones de
otras situaciones similares, los ingenieros del software edición más sofisticadas y de producción de documen-
necesitan un modelo de proceso que se ha diseñado tos en el segundo incremento; corrección ortográfica y
explícitamente para acomodarse a un producto que evo- gramatical en el tercero; y una función avanzada de
lucione con el tiempo. esquema de página en el cuarto. Se debería tener en cuen-
El modelo lineal secuencial (Sección 2.4) se diseña ta que el flujo del proceso de cualquier incremento pue-
para el desarrollo en línea recta. En esencia, este enfo- de incorporar el paradigma de construcción de prototipos.
que en cascada asume que se va entregar un sistema
completo una vez que la secuencia lineal se haya fina-
lizado. El modelo de construcción de prototipos (Sec-
ción 2.5) se diseña para ayudar al cliente (o al que
%
CLAVE
desarrolla) a comprender los requisitos. En general, no Emodelo incremento1entrega el software en partes
l
se diseña para entregar un sistema de producción. En pequenos, pero utilizables, llamadas ((incrementos).
ninguno de los paradigmas de ingeniería del software En general, cado incremento se construye sobre aquél
se tiene en cuenta la naturaleza evolutiva del software. que ya ho sido entregado.
Los modelos evolutivos son iterativos. Se caracteri-
zan por la forma en que permiten a los ingenieros del Cuando se utiliza un modelo incremental, el primer
software desarrollar versiones cada vez más completas incremento a menudo es un producto esencial. Es decir,
del software. se afrontan requisitos básicos, pero muchas funciones
23


suplementarias (algunas conocidas, otras no) quedan sin El modelo de proceso incremental, como la cons-
extraer. El cliente utiliza el producto central (o sufre la trucción de prototipos (Sección 2.5) y otros enfoques
revisión detallada). Como un resultado de utilización y/o evolutivos, es iterativo por naturaleza. Pero a dife-
de evaluación, se desarrolla un plan para el incremento rencia de la construcción de prototipos, el modelo
siguiente. El plan afronta la modificación del producto incremental se centra en la entrega de un producto
central a fin de cumplir mejor las necesidades del clien- operacional con cada incremento. Los primeros incre-
te y la entrega de funciones, y características adiciona- mentos son versiones «incompletas» del producto
les. Este proceso se repite siguiendo la entrega de cada final, pero proporcionan al usuario la funcionalidad
incremento, hasta que se elabore el producto completo. que precisa y también una plataforma para la eva-
luación.
El desarrollo incremental es particularmente útil
cuando la dotación de personal no está disponible para
Cuando tenga una fecha de entrega imposible una implementación completa en la fecha límite que se
de cambiar, el modela incremental es un buen haya establecido para el proyecto. Los primeros incre-
parodigma a considerar.
mentos se pueden implementar con menos personas.

incremento 1
Sistemas/información

Prueba
Entrega del
l.er
incremento

,
Código + Prueba Entrega del
2." incremento

Diseño + Código

incremento 4 Análisis Prueba Entrega del
4." incremento

Tiempo de calendario

FIGURA 2.7. El modelo incremental.

2.7.2. El modelo espiral
El modelo en espiral, propuesto originalmente por
Boehm [BOE88], es un modelo de proceso de soft-
ware evolutivo que conjuga la naturaleza iterativa de
construcción de prototipos con los aspectos controla- nieria
dos y sistemáticos del modelo lineal secuencial. Pro-
porciona el potencial para el desarrollo rápido de
del cliente
versiones incrementales del software. En el modelo
espiral, el software se desarrolla en una serie de ver- 0Proyecto de mantenimiento de productos.
siones incrementales. Durante las primeras iteraccio- 0Proyecto de mejora de productos.
Proyecto de desarrollo de nuevos productos.
nes, la version incremental podría ser un modelo en Proyecto de desarrollo de conceptos.
papel o un prototipo. Durante las últimas iteraciones,
se producen versiones cada vez más completas del sis-
tema diseñado. FIGURA 2.8. Un modelo espiral típico.
24


El modelo en espiral se divide en un número de acti- más sofisticadas del software. Cada paso por la región
vidades de marco de trabajo, también llamadas regio- de planificación produce ajustes en el plan del proyec-
rzes de tareas6.Generalmente, existen entre tres y seis to. El coste y la planificación se ajustan con la reali-
regiones de tareas. La Figura 2.8 representa un modelo mentacion ante la evaluación del cliente. Además, el
en espiral que contiene seis regiones de tareas: gestor del proyecto ajusta el número planificado de ite-
comunicación con el cliente- las tareas requeridas raciones requeridas para completar el software.
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 eva- Modelo de proceso adaptable.
luar riesgos técnicos y de gestión.
ingeniería- las tareas requeridas para construir una A diferencia del modelo de proceso clásico que ter-
o más representaciones de la aplicación. mina cuando se entrega el software, el modelo en espi-
construcción y acción- las tareas requeridas para ral puede adaptarse y aplicarse a lo largo de la vida del
construir, probar, instalar y proporcionar soporte al software de computadora. Una visión alternativa del
usuario (por ejemplo: documentación y práctica) modelo en espiral puede ser considerada examinando
el eje de punto de entrada en el proyecto también refle-
evaluación del cliente- las tareas requeridas para jado en la Figura 2.8. Cada uno de los cubos situados a
obtener la reacción del cliente según la evaluación lo largo del eje pueden usarse para representar el pun-
de las representaciones del software creadas durante to de arranque para diferentes tipos de proyectos. Un
la etapa de ingeniería e implementada durante la «proyecto de desarrollo de conceptos» comienza en el
etapa de instalación. centro de la espiral y continuará (aparecen múltiples ite-
a$$ raciones a lo largo de la espiral que limita la región som-
breada central) hasta que se completa el desarrollo del
CLAVE concepto. Si el concepto se va a desarrollar dentro de
Las actividades del marco de trabajo se aplican un producto real, el proceso continúa a través del cubo
a cualquier proyecto de software que realice, siguiente (punto de entrada del proyecto de desarrollo
sin tener en cuenta el tamaño ni la complejidad. del producto nuevo) y se inicia un «nuevo proyecto de
desarrollo”. El producto nuevo evolucionará a través de
Cada una de las regiones están compuestas por un con- iteraciones alrededor de la espiral siguiendo el camino
junto de tareas del trabajo, llamado conjunto de tareas, que limita la región algo más brillante que el centro.En
que se adaptan a las características del proyecto que va esencia, la espiral, cuando se caracteriza de esta forma,
a emprenderse. Para proyectos pequeños, el número de permanece operativa hasta que el software se retira. Hay
tareas de trabajo y su formalidad es bajo. Para proyectos veces en que el proceso está inactivo, pero siempre que
mayores y más críticos cada región de tareas contiene se inicie un cambio, el proceso arranca en el punto de
tareas de trabajo que se definen para lograr un nivel más entrada adecuado (por ejemplo: mejora del producto).
alto de formalidad. Enitodos los casos, se aplican las acti- El modelo en espiral es un enfoque realista del desa-
vidades de protección (por ejemplo: gestión de configu- rrollo de sistemas y de software a gran escala. Como el
ración del software y garantía de calidad del software) software evoluciona, a medida que progresa el proceso
mencionadas en la Sección 2.2. el desarrollador y el cliente comprenden y reaccionan
mejor ante riesgos en cada uno de los niveles evoluti-
¿Qué es un conjunto de
vos. El modelo en espiral utiliza la construcción de pro-
tareas?
totipos como mecanismo de reducción de riesgos, pero,
Cuando empieza este proceso evolutivo, el equipo lo que es más importante, permite a quien lo desarrolla
de ingeniería del software gira alrededor de la espiral aplicar el enfoque de construcción de prototipos en cual-
en la dirección de las agujas del reloj, comenzando por quier etapa de evolución del producto. Mantiene el enfo-
el centro. El primer circuito de la espiral puede produ- que sistemático de los pasos sugeridos por el ciclo de
cir el desarrollo de una especificación de productos; los vida clásico, pero lo incorpora al marco de trabajo ite-
pasos siguientes en la espiral se podrían utilizar para rativo que refleja de forma más realista el mundo real.
desarrollar un prototipo y progresivamente versiones El modelo en espiral demanda una consideración direc-

El modelo en espiral de esta sección es una variante sobre el modelo
propuesto por Boehm. Para más información sobre el modelo en espi-
ral original, consulte [BOE88]. Un tratado más reciente del modelo
en espiral puede encontrarse en [BOE98].

25


ta de los riesgos técnicos en todas las etapas del pro- El modelo en espiral WINWIN de Boehm [BOE98]
yecto, y, si se aplica adecuadamente, debe reducir los define un conjunto de actividades de negociación al prin-
riesgos antes de que se conviertan en problemáticos. cipio de cada paso alrededor de la espiral. Más que una
simple actividad de comunicación con el cliente, se defi-
nen las siguientes actividades:
1. Identificación del sistema o subsistemas clave de los
«directivos»8.
la Parte cuarto.
2. Determinación de las «condiciones de victoria» de
los directivos.
Pero al igual que otros paradigmas, el modelo en 3. Negociación de las condiciones de «victoria» de los
espiral no es la panacea. Puede resultar difícil conven- directivos para reunirlas en un conjunto de condi-
cer a grandes clientes (particularmente en situaciones ciones «victoria-victoria» para todos los afectados
bajo contrato) de que el enfoque evolutivo es controla- (incluyendo el equipo del proyecto de software).
ble. Requiere una considerable habilidad para la eva-
luación del riesgo, y cuenta con esta habilidad para el
éxito. Si un riesgo importante no es descubierto y ges-
tionado, indudablemente surgirán problemas. Final-
mente, el modelo no se ha utilizado tanto como los
paradigmas lineales secuenciales o de construcción de
Habilidades de negociación
prototipos. Todavía tendrán que pasar muchos años antes
de que se determine con absoluta certeza la eficacia de
este nuevo e importante paradigma. Conseguidos completamente estos pasos iniciales se
logra un resultado «victoria-victoria», que será el crite-
rio clave para continuar con la definición del sistema y
2.7.3. El modelo espiral WINWIN del software. El modelo en espiral WINWIN se ilustra
(Victoria&Victoria) en la Figura 2.9.
El modelo en espiral tratado en la Seccion 2.7.2 sugie-
re una actividad del marco de trabajo que aborda la 2. Identificar las
condiciones 3a. Reunir las condiciones
comunicación con el cliente. El objetivo de esta activi- de victoria de victoria.
dad es mostrar los requisitos del cliente. En un contex-
to ideal, el desarrollador simplemente pregunta al cliente
lo que se necesita y el cliente proporciona detalles sufi-
cientes para continuar. Desgraciadamente, esto rara-
mente 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,ren- y comentarios. ~

5. Definir el siguiente nivel
dimiento, y otros productos o características del siste- 6. Validar las del producto y del proceso,
ma frente al coste y al tiempo de comercialización. definiciones incluyendo particiones.
del producto
y del proceso.

FIGURA 2.9. El modelo en espiral WINWIN IBOE981.
l a obtención de requisitos del software requiere una
negociación. Tiene éxito cuando ambas partes «ganan». Además del énfasis realizado en la negociación ini-
cial, el modelo en espiral WINWIN introduce tres hitos
Las mejores negociaciones se esfuerzan en obtener' en el proceso, llamados puntos de fijación [BOE96],
«victoria-victoria». Esto es, el cliente gana obteniendo que ayudan a establecer la completitud de un ciclo alre-
el producto o sistema que satisface la mayor parte de dedor de la espiral y proporcionan hitos de decisión
sus necesidadesy el desarrollador gana trabajando para antes de continuar el proyecto de software.
conseguir presupuestos y lograr una fecha de entrega En esencia, los puntos de fijación representan tres
realista. visiones diferentes del progreso mientras que el pro-

Hay docenas de libros escritos sobre habilidades en la negocia- Un directivo e s alguien e n la organización que tiene un interés
ción [p. ej., [FiC91], [DON96], [FAR97]].Es una de las cosas mas directo, por el negocio, en el sistema o producto a construir y puede
importantes que un ingeniero o gestor joven (o viejo) puede apren- ser premiado por un resultado con éxito o criticado si el esfuerzo
der. Lea uno. falla.

26


yecto recorre la espiral. El primer punto de fijación, des del usuario, las decisiones de la gestión y los resultados de
llamado objetivos del ciclo de vida (OCV), define un las revisiones.
conjunto de objetivos para cada actividad principal El modelo de proceso concurrente se puede repre-
de ingeniería del software. Como ejemplo, de una par- sentar en forma de esquema como una serie de acti-
te de OCV, un conjunto de objetivos asociados a la vidades técnicas importantes, tareas y estados
definición de los requisitos del producto/sistema del asociados a ellas. Por ejemplo, la actividad de inge-
nivel más alto. El segundo punto de fijación, llama- niería definida para el modelo en espiral (Sección
do arquitectura del ciclo de vida (ACV), establece los 2.7.2), se lleva a cabo invocando las tareas siguien-
objetivos que se deben conocer mientras que se defi- tes: modelado de construcción de prototipos y/o aná-
ne la arquitectura del software y el sistema. Como lisis, especificación de requisitos y diseño'.
ejemplo, de una parte de la ACV, el equipo del pro- La Figura 2.10 proporciona una representación esque-
yecto de software debe demostrar que ha evaluado la mática de una actividad dentro del modelo de proceso
funcionalidad de los componentes del software reuti-
concurrente. La actividad -análisis-se puede encon-
lizables y que ha considerado su impacto en las deci- trar en uno de los estados'" destacados anteriormente en
siones de arquitectura. La capacidad operativa inicial
cualquier momento dado. De forma similar, otras acti-
(COI) es el tercer punto de fijación y representa un
vidades (por ejemplo: diseño o comunicación con el
conjunto de objetivos asociados a la preparación del
cliente) se puede representar de una forma análoga.
software para la instalación/distribución,preparación Todas las actividades existen concurrentemente, pero
del lugar previamente a la instalación, y la asistencia
residen en estados diferentes. Por ejemplo, al principio
precisada de todas las partes que utilizará o manten-
del proyecto la actividad de comunicación con el clien-
drá el software.
te (no mostrada en la figura) ha finalizado su primera
2.7.4. El modelo de desarrollo concurrente iteración y está en el estado de cambios,en espera. La
actividad de análisis (que estaba en el estado ninguno
Davis y Sitaram [DAV94] han descrito el modelo de mientras que se iniciaba la comunicación inicial con el
desarrollo concurrente, llamado algunas veces inge- cliente) ahora hace una transición al estado bajo desa-
niería concurrente, de la forma siguiente: rrollo. Sin embargo, si el cliente indica que se deben
Los gestores de proyectos que siguen los pasos del estado hacer cambios en requisitos, la actividad análisis cam-
del proyecto en lo que se refiere a las fases importantes [del
bia del estado bajo desarrollo al estado cambios en
ciclo de vida clásico] no tienen idea del estado de sus proyec-
tos. Estos son ejemplos de un intento por seguir los pasos extre- espera.
madamente complejos de actividades mediante modelos El modelo de proceso concurrente define una serie
demasiado simples. Tenga en cuenta que aunque un proyecto de acontecimientos que dispararán transiciones de
[grande] esté en la fase de codificación, hay personal de ese pro- estado a estado para cada una de las actividades de la
yecto implicado en actividades asociadas generalmente a muchas
fases de desarrollo simultáneamente. Por ejemplo, ... El perso-
ingeniería del software. Por ejemplo, durante las pri-
nal está escribiendo requisitos, diseñando, codificando, hacien- meras etapas del diseño, no se contempla una incon-
do pruebas y probando la integración [todo al mismo tiempo]. sistencia del modelo de análisis. Esto genera la
Los modelos de procesos de ingeniería del software de Humph- corrección del modelo de análisis de sucesos, que dis-
rey y Kellner [HUM89, KEL891 han mostrado la concurrencia parará la actividad de análisis del estado hecho al
que existe para actividades que ocurren durante cualquier fase. estado cambios en espera.
El trabajo más reciente de Kellner [KEL91] utiliza diagramas
de estado [una notación que representa los estados de un pro- El modelo de proceso concurrente se utiliza a menu-
ceso] para representar la relación concurrente que existe entre do como el paradigma de desarrollo de aplicaciones clien-
actividades asociadas a un acontecimiento específico (por ejem- te/servidor" (Capítulo 28). Un sistema cliente/servidor
plo: un cambio de requisitos durante el último desarrollo), pero se compone de un conjunto de componentes funciona-
falla en capturar la riqueza de la concurrencia que existe en todas les. Cuando se aplica a cliente/servidor,el modelo de pro-
las actividades de desarrollo y de gestión del software en un
proyecto. .. La mayoría de los modelos de procesos de desarro-
ceso concurrente define actividades en dos dimensiones
llo del software son dirigidos por el tiempo; cuanto más tarde [SHE94]: una dimensión de sistemas y una dimensión de
sea, más atrás se encontrará en el proceso de desarrollo. [Un componentes. Los aspectos del nivel de sistemas se afron-
modelo de proceso concurrente] está dirigido por las necesida- tan mediante tres actividades: diseño, ensamblaje y uso.

9 Se debería destacar que el análisis JI el diseño son tareas comple- l 1 En apiicaciones cliente/servidor, la funcionalidad del Software se
jas que requieren un estudio sustancial. LX Partes III y IV del libro divide entre clientes (normalmente P W Y un servidor (una compu-
consideran estos temas con más detalle. tadora más potente) que generalmente mantiene una base de datos
centralizada.
l o U estado es algún modo externamente observable del compor-
n
tamiento.

27

INGENIERfA DEL SOFTWARE. UN ENFOQUE PR A CTICO

La dimensión de componentes se afronta con dos activi-
dades: diseño y realización. La concurrencia se logra de
dos formas: (1) las actividades de sistemas y de compo-
nentes 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 mode-
lo de proceso concurrente es aplicable a todo tipo de desa- O
Reperesenia un estado de
rrollo de software y proporciona una imagen exacta del una actividad de ingenieria
del software.
estado actual de un proyecto.
FIGURA 2.10. Un elemento del modelo de proceso concurrente.

Las tecnologías de objetos (4.g Parte de este libro) pro- La actividad de la ingeniería comienza con la iden-
porcionan el marco de trabajo técnico para un modelo tificación de clases candidatas. Esto se lleva a cabo exa-
de proceso basado en componentes para la ingeniería minando los datos que se van a manejar por parte de la
del software. El paradigma orientado a objetos enfati- aplicación y el algoritmo que se va a aplicar para con-
za la creación de clases que encapsulan tanto los datos seguir el tratamientoI2.Los datos y los algoritmos corres-
como los algoritmos que se utilizan para manejar los pondientes se empaquetan en una clase.
datos. Si se diseñan y se implementan adecuadamente, Las clases creadas en los proyectos de ingeniería del
las clases orientadas a objetos son reutilizables por las software anteriores, se almacenan en una biblioteca de
diferentes aplicaciones y arquitecturas de sistemas basa- clases o diccionario de datos (repository) (Capítulo 3 1).
dos en computadora. 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 biblio-
teca y se vuelven a utilizar. Si una clase candidata no resi-
de en la biblioteca, se aplican los métobos orientados B
objetos (Capítulos 2 1-23). Se compone así la primera ite-
ració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 introdu-
cir por último la iteración ensambladora de componen-
tes a través de la actividad de ingeniería.
El modelo de desarrollo basado en componentes con-
FIGURA 2.1 1. Desarrollo basado en componentes. duce a la reutilización del software, y la reutilización pro-
porciona beneficios a los ingenieros de software. Según
El modelo de desarrollo basado en componentes (Fig. estudios de reutilización, QSM Associates, Inc. informa
2.11) incorpora muchas de las características del mode- que el ensamblaje de componentes lleva a una reducción
lo en espiral. Es evolutivo por naturaleza [NIE92], y exi- del 70 por 100 de tiempo de ciclo de desarrollo, un 84
ge un enfoque iterativo para la creación del software. por 100 del coste del proyecto y un índice de producti-
Sin embargo, el modelo de desarrollo basado en com- vidad del 26.2, comparado con la norma de industria del
ponentes configura aplicaciones desde componentes pre- 16.9 [YOU94]. Aunque estos resultados están en función
parados de software (llamados «clases» en la Fig. 2.11). de la robustez de la biblioteca de componentes, no hay
duda de que el ensamblaje de componentes proporciona
troto en lo Porte ventajas significativas para los ingenieros de software.
El proceso unificado de desarrollo de software
esento un estudio más detallado [JAC99] representa un número de modelos de desarro-
llo basados en componentes que han sido propuestos en

Esta es una descripción simplificada de definición de clase. Para
un estudio más detallado, consulte el Capítulo 20.

28

CApfTULO 2 EL PROCESO

la industria. Utilizando el Lenguaje de Modelado Uni- to de vista de1 usuario). Entonces acopla la función con
jcado (UML), el proceso unificado define los compo- un marco de trabajo arquitectónico que identifica la for-
nentes que se utilizarán para construir el sistema y las ma que tomará el software.
interfaces que conectarán los componentes. Utilizando
una combinacion del desarrollo incremental e iterativo,
el proceso unificado define la función del sistema apli- En los Capítulos 21 y 22 se trata UMl con más detalle.
cando un enfoque basado en escenarios (desde el pun-

El modelo de métodos formales comprende un conjun- consiguiente permiten que el ingeniero del software des-
to de actividades que conducen a la especificación mate- cubra y corrija errores que no se pudieron detectar de
mática del software de computadora. Los métodos otra manera.
formales permiten que un ingeniero de software espe- Aunque todavía no hay un enfoque establecido, los
cifique, desarrolle y verifique un sistema basado en com- modelos de métodos formales ofrecen la promesa de un
putadora aplicando una notación rigurosa y matemática. software libre de defectos. Sin embargo, se ha hablado
Algunas organizaciones de desarrollo del software de una gran preocupación sobre su aplicabilidad en un
actualmente aplican una variación de este enfoque, lla- entorno de gestión:
mado ingeniería del software de sala limpia [MIL87, 1. El desarrollo de modelos formales actualmente es
DYE921. bastante caro y lleva mucho tiempo.
2. Se requiere un estudio detallado porque pocos res-
los métodos formales se tratan en los Capítulos 25 y 26. ponsables del desarrollo de software tienen los ante-
cedentes necesarios para aplicar métodos formales.
Cuando se utilizan métodos formales (Capítulos 25 3. Es difícil utilizar los modelos como un mecanismo
y 26) durante el desarrollo, proporcionan un mecanis- de comunicación con clientes que no tienen muchos
mo para eliminar muchos de los problemas que son difí- conocimientos técnicos.
ciles de superar con paradigmas de la ingeniería del No obstante es posible que el enfoque a través de
software. La ambigüedad, lo incompleto y la inconsis- métodos formales tenga más partidarios entre los desa-
tencia se descubren y se corrigen más fácilmente - no rrolladores del software que deben construir software
mediante un revisión a propósito para el caso, sino de mucha seguridad (por ejemplo: los desarrolladores
mediante la aplicación del análisis matemático-. Cuan- de aviónica y dispositivos médicos), y entre los desa-
do se utilizan métodos formales durante el diseño, sir- rrolladores que pasan grandes penurias económicas al
ven como base'para la verificación de programas y por aparecer errores de software.

El término técnicas de cuarta generación (T4G) abarca siguientes herramientas: lenguajes no procedimentales
un amplio espectro de herramientas de software que tie- de consulta a bases de datos, generación de informes,
nen algo en común: todas facilitan al ingeniero del soft- manejo de datos, interacción y definición de pantallas,
ware la especificación de algunas características del generación de códigos, capacidades gráficas de alto nivel
software a alto nivel. Luego, la herramienta genera auto- y capacidades de hoja de cálculo, y generación auto-
máticamente el código fuente basándose en la especifi- matizada de HTML y lenguajes similares utilizados para
cación del técnico. Cada vez parece más evidente que la creación de sitios web usando herramientas de soft-
cuanto mayor sea el nivel en el que se especifique el ware avanzado. Inicialmente, muchas de estas herra-
software, más rápido se podrá construir el programa. El mientas estaban disponibles, pero sólo para ámbitos de
paradigma T4G para la ingeniería del software se orien- aplicación muy específicos, pero actualmente los entor-
ta hacia la posibilidad de especificar el software usan- nos T4G se han extendido a todas las categorías de apli-
do formas de lenguaje especializado o notaciones caciones del software.
gráficas que describa el problema que hay que resolver Al igual que otros paradigmas, T4G comienza con
en términos que los entienda el cliente. Actualmente, el paso de reunión de requisitos. Idealmente, el cliente
un entorno para el desarrollo de software que soporte describe los requisitos, que son, a continuación, tradu-
el paradigma T4G puede incluir todas o algunas de las cidos directamente a un prototipo operativo. Sin embar-

29

INGENIERfA DEL SOFTWARE. U N ENFOQUE PRACTiCO

go, en la práctica no se puede hacer eso. El cliente pue- que facilite la realización del mantenimiento de forma
de que no esté seguro de lo que necesita; puede ser ambi- expeditiva.
guo en la especificación de hechos que le son conocidos, Al igual que todos los paradigmas del software, el
y puede que no sea capaz o no esté dispuesto a especi- modelo T4G tiene ventajas e inconvenientes. Los defen-
ficar la información en la forma en que puede aceptar sores aducen reducciones drásticas en el tiempo de desa-
una herramienta T4G. Por esta razón, el diálogo clien- rrollo del software y una mejora significativa en la
te-desarrollador descrito por los otros paradigmas sigue productividad de la gente que construye el software.
siendo una parte esencial del enfoque T4G. 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 manteni-
lncluso cuundo utilice unu 14G, tiene que destocar miento de grandes sistemas de software desarrollados
durumente /u inyenieríu del sohore huciendo e/ an6/isis, mediante T4G es cuestionable.
el diseño y /os pruebus. Hay algún mérito en lo que se refiere a indicaciones
de ambos lados y es posible resumir el estado actual de
Para aplicaciones pequeñas, se puede ir directamen- los enfoques de T4G:
te desde el paso de recolección de requisitos al paso de 1 . El uso de T4G es un enfoque viable para muchas de
implementación, usando un lenguaje de cuarta genera- las diferentes áreas de aplicación. Junto con las herra-
ción no procedimental (L4G) o un modelo comprimi- mientas de ingeniería de software asistida por com-
do de red de iconos gráficos. Sin embargo, es necesario putadora (CASE) y los generadores de código, T4G
un mayor esfuerzo para desarrollar una estrategia de ofrece una solución fiable a muchos problemas del
diseño para el sistema, incluso si se utiliza un L4G. El software.
uso de T4G sin diseño (para grandes proyectos) causa- 2. Los datos recogidos en compañías que usan T4G
rá las mismas dificultades (poca calidad, mantenimien- parecen indicar que el tiempo requerido para produ-
to pobre, mala aceptación por el cliente) que se cir software se reduce mucho para aplicaciones
encuentran cuando se desarrolla software mediante los pequeñas y de tamaño medio, y que la cantidad de
enfoques convencionales. análisis y diseño para las aplicaciones pequeñas tam-
La implementación mediante L4G permite, al que bién se reduce.
desarrolla el software, centrarse en la representación de
los resultados deseados, que es lo que se traduce auto- 3. Sin embargo, el uso de T4G para grandes trabajos de
máticamente en un código fuente que produce dichos desarrollo de software exige el mismo o más tiempo
resultados. Obviamente, debe existir una estructura de de análisis, diseño y prueba (actividades de ingenie-
datos con información relevante y a la que el L4G pue- ría del software), para lograr un ahorro sustancial de
da acceder rápidamente. tiempo que puede conseguirse mediante la elimina-
Para transformar una implementación T4G en un ción de la codificación.
producto, el que lo desarrolla debe dirigir una prueba Resumiendo, las técnicas de cuarta generación ya se
completa, desarrollar con sentido una documentación han convertido en una parte importante del desarrollo
y ejecutar el resto de las actividades de integración que de software. Cuando se combinan con enfoques de
son también requeridas requeridas por otros paradig- ensamblaje de componentes (Sección 2.8), el paradig-
mas de ingeniería del software. Además, el software ma T4G se puede convertir en el enfoque dominante
desarrollado con T4G debe ser construido de forma hacia el desarrollo del software.

O

Los modelos de procesos tratados en las secciones ante- ción tratadas en la Sección 2.3. El modelo, presentado
riores se deben adaptar para utilizarse por el equipo del normalmente como una red, se puede analizar para deter-
proyecto del software. Para conseguirlo, se han desarro- minar el flujo de trabajo típico y para examinar estruc-
llado herramientas de tecnología de procesos para ayudar turas alternativas de procesos que pudieran llevar a un
a organizaciones de software a analizar los procesos actua- tiempo o coste de desarrollo reducidos.
les, organizar tareas de trabajo, controlar y supervisar el Una vez que se ha creado un proceso aceptable, se
progreso y gestionar la calidad técnica [BAN95]. pueden utilizar otras herramientas de tecnología de pro-
Las herramientas de tecnología de procesos permi- cesos para asignar, supervisar e incluso controlar todas
ten que una organización de software construya un las tareas de ingeniería del software definidas como par-
modelo automatizado del marco de trabajo común de te del modelo de proceso. Cada uno de los miembros
proceso, conjuntos de tareas y actividades de protec- de un equipo de proyecto de software puede utilizar tales

30

z
CAP~TULO E L P R OC E S O

herramientas para desarrollar una lista de control de se puede utilizar para coordinar el uso de otras herra-
tareas de trabajo a realizarse, productos de trabajo a pro- mientas de ingeniería del software asistida por compu-
ducirse, y actividades de garantía de calidad a condu- tadora (Capítulo 3 1) adecuadas para una tarea de trabajo
cirse. La herramienta de tecnología de proceso también en particular.

O D U O Y PR-O . .

Si el proceso es débil, el producto final va a sufrir indu- Toda actividad humana puede ser un proceso, pero ca'da uno de
dablemente. Aunque una dependencia obsesiva en el nosotros obtiene el sentido de autoestima ante esas actividades que
producen una representación o ejemplo que más de una persona
proceso también es peligrosa. En un breve ensayo, Mar- puede utilizar o apreciar, una u otra vez, o en algún otro contexto
garet Davis [DAV95] comenta la dualidad producto y no tenido en cuenta. Es decir, los sentimientos de satisfacción se
proceso: obtienen por volver a utilizar nuestros productos por nosotros mis-
Cada diez años o cinco aproximadamente,la comunidad del soft- mos o por otros.
ware vuelve a definir «el problema» cambiando el foco de los aspec- Así pues, mientras que la asimilación rápida de los objetivos
tos de producto a los aspectos de proceso. Por consiguiente, se han de reutilización en el desarrollo del software aumenta potencial-
abarcado lenguajes de programación estructurados (producto) segui- mente la satisfacción que los desarrolladores obtienen de su tra-
dos por métodos de análisis estructurados (proceso) seguidos a su bajo, esto incrementa la urgencia de aceptar la dualidad producto
vez por encapsulación de datos (producto) y después por el énfasis y proceso. Pensar en un mecanismo reutilizable como el único
actual en el Modelo Madurez de Capacidad de Desarrollo del soft- producto o el único proceso, bien oscurece el contexto y la forma
ware del Instituto de ingeniería de software (proceso). de utilizarlo, o bien el hecho de que cada utilización elabora el
Mientras que la tendencia natural de un péndulo es parar en medio producto que a su vez se utilizará como entrada en alguna otra
de dos extremos, el enfoque de la comunidad del software cambia actividad de desarrollo del software. Elegir un método sobre otro
constantemente porque se aplica una fuerza nueva cuando falla el reduce enormemente las oportunidades de reutilización y de aquí
último movimiento. Estos movimientos son perjudicialespor sí mis- que se pierda la oportunidad de aumentar la satisfacción ante el
mos y en sí mismos porque confunden al desarrollador del softwa- trabajo.
re 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.

se aplica
puede convertirse] en
Las personas obtienen tanta satisfacción (o más) del
proceso creativo que del producto final. Un artista dis-
fruta con las pinceladas de la misma forma que disfru-
ta del resultado enmarcado. Un escritor disfruta con la
En la comunidad científica hay un precedente que se adelanta a búsqueda de la metáfora adecuada al igual que con el
las nociones de dualidad cuando contradicciones en observaciones
no se pueden explicar completamente con una teoría competitiva u
libro final. Un profesional creativo del software debe-
otra. La naturaleza dual de la luz, que parece ser una partícula y una ría también obtener tanta satisfacción de la programa-
onda al mismo tiempo, se ha aceptado desde los años veinte cuan- ción como del producto final.
do Louis de Broglie lo propuso. Creo que las observaciones que se El trabajo de los profesionales del software cambia-
hacen sobre los mecanismos del software y su desarrollo demues- rá en los próximos años. La dualidad de producto y pro-
tran una dualidad fundamental entre producto y proceso. Nunca se ceso es un elemento importante para mantener ocupada
puede comprender el mecanismo completo, su contexto, uso, signi-
ficado y valor si se observa sólo como un proceso o sólo como un a la gente creativa hasta que se finalice la transición de
producto.. . la programación a la ingeniería del software.

La ingeniería del software es una disciplina que inte- venientes, pero todos tienen una serie de fases gené-
gra procesos, métodos y herramientas para el desa- ricas en común. En el resto de este libro se consideran
rrollo del software de computadora. Se han propuesto los principios, conceptos y métodos que permiten lle-
varios modelos de procesos para la ingeniería del soft- var a cabo el proceso que se llama ingeniería del soft-
ware diferentes, cada uno exhibiendo ventajas e incon- ware.
31

INGENIERfA DEL SOFTWARE. U N ENFOQUE PRÁCTICO

[BAE98] Baetjer, H., Jr., Software as Capital, IEEE Compu- Ilth Intl. Conference on Software Engineering, IEEE Com-
ter Society Press, 1998, p. 85. puter Society Press, pp. 331-342.
[BAN95] Bandinelli, S. et al, «Modeling and Improving an [IEE93] IEEE Standards Collection: Softvtzare Engineering,
Industrial Software Process», IEEE Truns. Software Engi- IEEE Standard 610.12-1990, IEEE, 1993.
neering, vol. 2 1, nO 5 , Mayo 1995, pp. 440-454.
. [JAC99] Jacobson, I., G. Booch y J. Rumbaugh, The Unified
[BRA94] Bradac, M., D. Peny y L. Votta, «Prototyping a Pro- Software Developement Proccess, Addison-Wesley, 1999.
cess Monitoring Experiment", IEEE Trans. Software Engi-
[KEL89] Kellner, M., Software Process Modeling: Vulue and
neering, vol. 20, n." 10, Octubre 1994, pp. 774-784.
Experience, SE1 Technical Review- 1989, SEI, Pittsburgh,
[BOE88] Boehm, B., «A Spiral Model for Software Develo- PA, 1989.
pement and Enhancement", Computer, vol. 21, n.Q5 , Mayo
[KEL9 11 Kellner, M., «Software Process Modeling Support
1988, pp. 61-72.
for Management Planning and Control», Proc. 1st Intl.
[BOE96] Boehm, B., «Anchoringthe Software Pocess», IEEE Conf, On the Sofhvare Process, IEEE Computer Society
Software, vol. 13, n." 4, Julio 1996, pp.73-82. Press, 1991, pp. 8-28.
[BOE98] Boehm, B., «Using the WINWIN Spiral Model: A [KER94]Kerr, J., y R. Hunter, InsideRAD, McGraw-Hill, 1994.
Case Study», Computer, vol. 31, n." 7, Julio 1998, pp. 33-
44. [MAR9 11 Martin, J., Rapid Aplication Developement, Pren-
tice-Hall, 1991.
[BR075] Brooks, F., The Mytical Man-Month, Addison-Wes-
ley, 1975. [MDE93] McDermid, J. y P. Rook, «Software Developement
Process Modelw, en Softilwe IngineerS Reference Book,
[BUT94] Butler, J., «Rapid Aplication Developement in CRC Press, 1993, pp. 15/26-15/28.
Action», Managing System Developement, Applied Com-
puter Research, vol. 14, n." 5 , Mayo 1995, pp. 6-8. [MIL871 Mills, H.D., M. Dyer y R. Linger, «Clearoom Soft-
ware Engineeringn, IEEE Software, Septiembre 1987, pp.
[DAV94] Davis, A., y P. Sitaram, «A Concurrent Process 19-25.
Model for Software Developement», Software Enginee-
ring Notes, ACM Press, vol. 19, n." 2, Abril 1994, pp. 38- [NAU69] Naur, P., y B. Randa11 (eds.), Softwure Engineering:
51. A Report on a Conference sponsored by the NATO Scien-
ce Committee, NATO, 1969.
[DAV95] Davis, M.J., «Process and Product: Dichotomy or
Duality», Software Engineering Notes, ACM Press, vol. [NIE92] Nierstrasz, Komponent-Oriented Software Deve-
20, n.Q2, Abril 1995, pp. 17-18. lopement», CACM, vol. 35, n.Q9, Septiembre 1992, pp.
160-165.
[DON961 Donaldson, M.C., y M. Donaldson, Negotiating for
Dummies, IDB Books Worldwide, 1996. [PAU93] Paulk, M., et al., «Capability Maturity Model for
[DYE92] Dyer, M., The Cleanroom Approach to Quality Sof- Software», Software Engineering Institute, Carnegie
ware Developement, Wiley, 1992. Mellon University, Pittsburgh, PA, 1993.
[FAR97] Farber, D.C., Common Sense Negotiation: The Art [RAC95] Raccoon, L.B.S, «The Chaos Model and the Chaos
of Winning Gracefully, Bay Press, 1997. Life Cycle», ACM Software Engineering Notes, vol. 20,
n." 1, Enero 1995, pp. 55-66.
[FIS91] Fisher, R., W. Ury y Bruce Patton, Getting to Yes:
Negotiating Agreement Without Giving In, 2." ed., Penguin [ROY70] Royce, W.W., «Managing the Developement of Large
USA, 1991. Software Systems: Concepts and Techniquew, Proc. WES-
CON, Agosto 1970.
[GIL881 Gilb, T., Principles of Software Engineering Muna-
gement, Addison-Wesley, 1988. [SHE94] Sheleg, W., «Concurrent Engineering: A New Para-
dign for C/S Developement», Application Developement
[HAN951 Hanna, M., «Farewell to Waterfallm, Software Trends, vol. 1, n." 6, Junio 1994, pp. 28-33.
Magazine, Mayo 1995, pp.38-46.
[YOU94] Yourdon, E., «Software Reuse», Application Deve-
[HUM89] Humphrey, W., y M. Kellner, «Software Process Iopement Strategies, vol. VI, n." 12, Diciembre 1994, pp.
Modeling: Principles of Entity Process Models», Proc. 1-16.

YPUNTQSACONSIL)EBAR
2.1. La Figura 2.1 sitúa las tres capas de ingeniería del soft- 2.2. ¿Hay algún caso en que no se apliquen fases genéricas
ware encima de la capa titulada «enfoque de calidad». Esto del proceso de ingeniería del software? Si es así, descríbalo.
implica un programa de calidad tal como Gestión de Cali- 2.3. El Modelo Avanzado de Capacidad del SE1 es un docu-
dad Total. Investigue y desarrolle un esquema de los prin- mento en evolución. Investigue y determine si se han aña-
cipios clave de un programa de Gestión de Calidad Total. dido algunas ACP nuevas desde la publicación de este libro.

32


2.4. El modelo del caos sugiere que un bucle de resolución de 2.8. Proponga un proyecto específico de software que sea ade-
problemas se pueda aplicar en cualquier grado de resolución. cuado para el modelo incremental. Presente un escenario para
Estudie la forma en que se aplicaría el bucle (1) para com- aplicar el modelo al software.
prender los requisitos de un producto de tratamiento de texto; 2.9. A medida que vaya hacia afuera por el modelo en espiral,
(2) para desarrollar un componente de corrección ortográfica ¿qué puede decir del software que se está desarrollando o man-
y gramática avanzado para el procesador de texto; (3) para teniendo?
generar el código para un módulo de programa que determi-
ne el sujeto, predicado y objeto de una oración en inglés. 2.10. Muchas personas creen que la Única forma en la que se
van a lograr mejoras de magnitud en la calidad del software y
2.5. ¿Qué paradigmas de ingeniería del software de los presen- en su productividad es a través del desarrollo basado en com-
tados en este capítulo piensa que sería el más eficaz? ¿Por qué? ponentes. Encuentre tres o cuatro artículos recientes sobre el
2.6. Proporcione cinco ejemplos de proyectos de desarrollo asunto y resúmalos para la clase.
del software que sean adecuados para construir prototipos. 2.11. Describa el modelo de desarrollo concurrente con sus
Nombre dos o tres aplicaciones que fueran más difíciles para
propias palabras.
construir prototipos.
2.12. Proporcione tres ejemplos de técnicas de cuarta genera-
2.7. El modelo DRA a menudo se une a herramientas CASE.
ción.
Investigue la literatura y proporcione un resumen de una herra-
mienta típica CASE que soporte DRA. 2.13. ¿Qué es más importante, el producto o el proceso?

El estado actual del arte en la ingeniería del software se puede controvertidos y amenos sobre el software y el proceso de la
determinar mejor a partir de publicaciones mensuales tales como ingeniería del software. Pressman y Herron (Software Shock,
IEEE Software, Computer e IEEE Transactions on Software Dorset House, 1991) consideran el software y su impacto
Engineering. Periódicos sobre la industria tales como Applica- sobre particulares, empresas y el gobierno.
tion Developement Trends, Cutter IT Journal y Software Deve- El Instituto de ingeniería del software (11s localizado en
lopement a menudo contienen artículos sobre temas de ingeniería la Universidad de Carnegie-Mellon) ha sido creado con la
del software. La disciplina se «resume» cada año en el Proce- responsabilidad de promocionar series monográficas sobre
eding o the International Conference on Software Engineering,
f la ingeniería del software. Los profesionales académicos,
promocionado por el IEEE y ACM y tratado en profundidad en en la industria y el gobierno están contribuyendo con nue-
periódicos como ACM Transactions on Software Engineering vos trabajos importantes. El Consorcio de Productividad del
and Methodology, ACM Software Engineering Notes y Annals Software dirige una investigación adicional de ingeniería
of Software Engineering. de software.
Se han publicado muchos libros de ingeniería del softwa- En la última década se ha publicado una gran variedad de
re en los últimos años. Algunos presentan una visión general estándares y procedimientos de ingeniería del software. El IEEE
del proceso entero mientras que otros se dedican a unos pocos Software Engineering Standards contiene muchos estándares
temas importantes para la exclusión de otros. Las siguientes diferentes que abarcan casi todos los aspectos importantes de
son tres antologías que abarcan algunos temas importantes la tecnología. Las directrices ISO 9000-3 proporcionan una
de ingeniería del software: guía para las organizaciones de software que requieren un regis-
Keyes, J. (ed.), Sofmare Engineering Productivity Hand- tro en el estándar de calidad ISO 9001. Otros estándares de
book, McGraw-Hill, 1993. ingeniería del software se pueden obtener desde el MOD, la
McDermid, J. (ed.), Software Engineer’s Reference Book, Autoridad Civil de Aviación y otras agencias del gobierno y
CRC Press, 1993. sin ánimo de lucro. Fairclough (Software Engineering Guides,
Marchiniak, J.J. (ed.), Encyclopedia o Software Engine-
f Prentice-Hall, 1996) proporciona una referencia detallada de
ering, Wiley, 1994. los estándares de ingeniería del software producidos por Euro-
Gautier (Distributed Engineering o Software, Prentice-
f pean Space Agency (ESA).
Hall, 1996) proporciona sugerencias y directrices para orga- En internet se dispone de una gran variedad de fuentes de
nizaciones que deban desarrollar software en lugares información sobre la ingeniería del software y del proceso de
geográficamente distantes. software. Se puede encontrar una lista actualizada con refe-
En la parte más brillante del libro de Robert Glass (Soft- rencias a sitios (páginas) web que son relevantes para el pro-
ware Conflict, Yourdon Press, 1991) se presentan ensayos ceso del software en http://www.pressman5.com.

33

Guia 1 is

Más contenido relacionado

La actualidad más candente (17)

Destacado (9)

Similar a Guia 1 is (20)

Más de Emiliy02 (20)

Guia 1 is