Enfoque producto y proceso Ing. de Soft

1. 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
comprometieron grandes cantidades de dinero, y por Último, las advertencias
bles de catástrofe llegaron a la conciencia del público. El software, al igual que el ahora famoso
error 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 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 interminable. El software es casi ineludible en un mun-
do moderno. A medida que nos adentremos en el siglo será el que nos conduzca a nuevos avances en
todo, desde la educación elemental a la ingeniería genética.
es? El software de computadora es qué e s importante? Porque obtenido?Des-
el producto que 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 obtenidoson los
ca programas que se ejecutan omercio, cuí- programas, documentos y los datos
coti- que configuran el software d e
de el punto de vista de
los usuarios el producto obt
e impresos y datos que combinan información resultante
números y texto y incluyen algún modo mund
representaciones d e información de que
audio, vídeo e imágenes. conduce a un resultado de alta calidad puedo estar de que
lo hace? Los ingenierosde soft- que satisface las necesidades de l a lo he hecho Lee
ware construyen, y virtualmente gente que usará el producto. Debes el resto libro, selecciona aque-
cualquier persona en el mundo indus- aplicar un enfoque d e ingeniería d e llas ideas que al soft-
trialiiado lo utiliza bien directa o software. ware que construyes y aplícalas a tu
trabajo.
Cinco años después de que la cuarta edición de este libro fue escrita, el papel del software
como «alma ha llegado a ser más 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
estimaciones en billones de dólares antes de que éstas 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 -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

2. 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
transmitiendo información que puede ser tan simple cratización del conocimiento». A Yourdon 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 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 de la
y entomos). compañía».A mediados de los años 90, la persistencia de
las computadoras y del una erupción de
libros por (por ejemplo: Resisting the Vir-
tual editadopor James Brook y Ian y The
re not Compute de Stephen Talbot). Estos autores
El es tonto un producto, 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
El papel del software ha sufrido un cam-
bio significativo durante un periodo de tiempo superior
a 50 años. Enormes mejoras en rendimiento del 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 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 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: Aunque
y de su impacto en nuestra cultura. muchos vieron las predicciones de los críticos del Y2K
hablaba de una «nueva revolución Toffler como reacciones, sus populares lecturas devolvieron la
llamó a la llegada de componentes difusión del software a sus vidas. Hoy en día, com-
trónicos la «tercera ola del cambio» en la historia de la putación omnipresente» ha producido una gene-
humanidad, y Naisbitt 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 sugirieronque capa de conexión sobre nuestras casas, oficinas, y
la información y el conocimiento (controlados por com- autopistas» El papel del software continúa su
putadora) serían el foco de poder del siglo veintiuno, y expansión.
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. centradoen una parte de la tecnología requerida para entre-
Al comienzo de los años 90, Toffler 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 basados en computadoras:
4

3. CAPITULO 1 EL PRODUCTO Y EL PROCESO
qué lleva tanto tiempo terminar los programas?
qué son tan elevados los costes de desarrollo?
qué no podemos encontrar todos los errores
antes de entregar el software a nuestros clientes?
qué nos resulta difícil constatar el progreso con-
Estadísticas 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 significaque proyectos de software no se pueden
ba «softwarede 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. lo entien- 2. El software no se «estropea».
den realmente? La Figura 1.1 describe, para el hardware, la proporción
de falloscomo 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
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 más información en el
Capítulo 8). Sin embargo la implicación es clara, el soft-
c VE
ware no se estropea. se deteriora!
El software se desarrolla, no se fabrica.
CLAVE
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 Mortalidad Se estropea
buen diseño, pero la fase de construcción del
al
ware puede problemas de calidad que no
al
existen (o son fácilmente corregibles) en el software.
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

4. DEL 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 curva 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 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 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
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
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
Después de seleccionar cada componente, puede 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
del índice de fallos
c VE
mayoría del 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-
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
base de datos) y producen 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 magnitud de los picos y inclinación da y produce órdenes concretas para la máquina en rápi-
de curva 1.2). da sucesión.
6

5. 1 EL PRODUCTO Y EL PROCESO
Software de gestión. El proceso de la información
l a revolución del se foto en 13. comercial constituye la mayor de las áreas de aplica-
Lo ingenieríade software basada en ción del software. Los discretos (por ejem-
se presento en el Capítulo 27. plo: nóminas, cuentas de
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 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 gestionar la toma de decisiones. Además de las tareas
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
nificativas. Conforme aumenta la complejidad del
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 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
ción de recursos y una sofisticada gestión de procesos;
unas estructuras de datos complejas y múltiples
faces externas.
Software de tiempo real. El software que
sucesos del mundo real conforme Se puede encontrar una de mayores bibliotecas
ocurren, se denomina de tiempo real. Entre los elemen- de en
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 componentede 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.

6. DEL SOFTWARE. UN ENFOQUE
Software basado en Las páginas Web busca- Softwarede 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 complejospara los que no son
o Java), y datos (por ejemplo, hipertexto y una varie- adecuadosel cálculo o el análisis directo. Los sistemasexper-
dad de 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
recurso software casi ilimitado que puede ser accedido 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 nin-
autor) han caracterizado los problemas asociados con el gún 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: en las disciplinas relacionadas con el software.
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: 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 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 ver en mis La palabra 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 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 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 punto decisivo en el curso de algo, momento, Vivimos con esta aflicción desde este día hecho,
etapa o evento decisivo o Sin embargo, en térmi- la industria prospera a pesar de 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 en una conferencia impartida en Ginebra,
Suiza, Abril, 1989.
8

7. 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 ducen a que el cliente se cree una expectativay, final-
res y procedimientos para construir software, 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 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?, completo?, 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 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 cambio
rrollo de software más avanzadas, después de todo, les con detalle en el 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 «conceptode la horda 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 «...añadir gente a un proyecto de software
retrasado lo retrasa aún 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
comunicarsecon 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
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 puede ayudarle nos que requieran recursos adicionales e importantes
a estos y otros mitos. modificaciones del diseño; es decir, coste adicional. Los
9

8. DEL SOFTWARE. UN ENFOQUE PRÁCTICO
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- 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 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
muy duro poro entender lo que tienes que reconocimiento de las realidades del software es el
de empezar. No serías copoz de codo primer paso hacia la formulación de soluciones prác-
detalle; por más que 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 te pones o no tiempoporo
informáticos. El software se compone de programas, disciplino de lo ingeniería del y te preguntas:
datos y documentos. Cada uno de estos elementos com- tiempo poder
Brooks, The Mytical Addison-Wes- Glass, L., Software Prentice Hall,
ley, 1975. 1997.
De Jager, et al, Countdown Business Sur- Glass, there a Software Crisis?»,
for the Year 2000, Wiley, 1998. IEEE vol. 15, 1, Enero 1998, pp. 104-105.
De Marco, T., Software Cost So Much?, Hammer, M., y Champy, Reengineering
Dorset House, 1995, 9. poration, Publisher, 1993.
Feigenbaum, E. A., y Gene- Jones, Software Measurement,
ration, Addison-Wesley, 1983. 1991.
Flowers, Software Failure, Management Karlson, E., y Kolber, A Basic to
lure-Amaicing Stories and Wiley, How the Year 2000 Computer Crisis You?,
1997 Next Era Publications, Inc., 1999.
10

9. 1 EL PRODUCTO Y EL PROCESO
Levy, Luddites Are Newsweek, 12de Stoll, Egg, Doubleday, 1989.
Julio de 1995, 55. Toffler, A., The Third Wave, Morrow Publishers,
Levy, New Digital Newsweek, 1980.
31 de Mayo de 1999, . Toffler, A., Bantam Publishers, 1990.
Lientz, y E. Swanson, Software Maintenance Yourdon, E., The Decline and the
Addison Wesley, 1980. Programmer, Yourdon Press, 1992.
Naisbitt, Megatoends, Warner Books, 1982. Yourdon, E., The Rise and Resurrection the Ame-
Norman, TheInvisible Press, 1998. rican Programmer, Yourdon Press, 1996.
Running Wild-The Next Industrial Yourdon, E., Death March Projects, Prentice-Hall,
Revolution, 1979. 1998.
Putnam, L., y Myers, Industrial Strength Soft- Yourdon, E., y Yourdon, Time 2000,
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 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 en donde el fallo de
computadorapodría hacer un gran daño (económico o humano).
1.2. En los 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. ha afectado esto a las prácticas de desa- 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 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- (The Software Conspiracy: Why Software
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, 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.
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 Los software y el proceso a través del cual se desarrolla.
libros de Norman y Bergman (Information En Intemet están disponibles una gran variedad de fuen-
Appliances Beyond, Academic 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
la difusión de la programación conecten a todos en el mun- man5.com.
11

11. H
OWARD Baetjer, Jr. 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 del software», es el conjunto del software
reunido. denurado v mientras se desarrolla el
es? Cuando trabaja para construir 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 se
tante seguir una serie d e pasos 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- son los pasos? A un nivel deta- definidas por el proceso.
tuno de calidad-. El mapa de carre- llado, el proceso que adoptemos puedo estar seguro de que
teras a seguir es llamado del depende del software que estamos lo he hecho correctamente?Hay
software.. construyendo. Un proceso puede ser una cantidad de mecanismos d e
lo 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 un permiten a las organizaciones deter-
so a sus necesidades y entonces lo proceso diferente por completo puede minar la 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- 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, 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. «proceso» sinónimo de ingeniería del softwa-
re? La respuesta es 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

12. 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 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 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. 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? construimos pruebas y mantenimiento. Los métodos de la ingeniería
el software «económicamente» para que sea «fiable»? del software dependen de un conjuntode principios bási-
se necesita para crear programas de computa- cos que gobiernan cada área de la tecnología e incluyen
dora que funcionen 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.
CLAVE
l a Ingeniería de comprende un proceso,
definimos métodos técnicosy de gestión, y herramientas.
Ingeniería del software?
Las herramientas de la Ingeniería del software pro-
El IEEE 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: 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 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
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

13. 2 EL PROCESO
es el problema a resolver? La fase de desarrollo se centra en el cómo. Es decir,
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
se realizará la entidad (y la solución)? arquitectura de software, cómo han de implementarse
se construirá la entidad? los detalles procedimentales, cómo han de caracteri-
zarse interfaces, cómo ha de traducirse el diseño en un
enfoque se va a utilizar para no contemplar los
lenguaje de programación (o lenguaje no
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
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 gene-
dad? ración de código y prueba del software (Capítulos 16,
17 y 22).
Referencia Web
es un periódico que proporciona y
comentarios prócticos de ingeniería del software. Estón
disponibles temas 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
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ónen 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
de paradigmas) que se aplique, de alguna manera ten-
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 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
ventivo también llamado reingeniería del software, se
debe conducir a permitir que el software sirva para las
necesidades de los usuarios finales. En esencia, el man-
El software crea tres fases distintas que se tenimiento preventivo hace cambios en programas de
centran en definición, desarrollo y mantenimiento. computadora a fin de que se puedan corregir, adaptar y
mejorar más fácilmente.
15

14. DEL SOFTWARE. UN ENFOQUE PRACTICO
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
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
el término «mantenimiento»
reconocemos que es mucho más que una simple
Revisiones técnicas formales
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 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 -talescomo 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 independenciade 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 El Softwate Engineering
puntos de garantía de calidad-que permiten que las acti- 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 utiliza un cues-
Actividades del marco de trabajo tionario de evaluación y un esquema de cinco grados.
Tareas
Seleccioneun de del proceso común que se
producto, personal y proyecto.
El esquema de grados determina la conformidad con
un modelo de capacidad de madurez 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. proporciona una medida de la efectividad global de
término es un eufemismo para sottware 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 de la Cannegie University.
tico para el negocio y debe ser soportado durante algunos años.
16

15. 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 comprenderla 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 documentoo 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óndel programa puede uti-
tación cuantitativadel proceso, ideas y tecnologías lizarse para proporcionar algún umbral numérico que
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
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-
El ofrece un amplio conjunto de información
relacionada con el proceso en www.sei.cmu.edu
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 softwareen 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 para la programa- ceso o herramienta.
17

16. DEL SOFTWARE. U N E N F O Q U E
En este orden debe destacarse que para que un
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 ’-
nivel 3. Si el desarrollador del software no tiene defi- Una tabular del MCM completo del incluyendo
nidos rigurosamente los procesos pueden ocurrir una todos objetivos, comentarios, habilidades y
actividades disponible en
gran cantidad de cambios en el proceso de desarrollo
y no se podrán utilizar las estadísticas para estas acti-
vidades.
Los cinco niveles definidos por el 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 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 esforzarse poro
Gestión de integración del software
lo profundidad del del Sin Programa de formación
lo 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. define a los clave como 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
18

17. 2 EL PROCESO
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
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 etapas de un proceso del -estado
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 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 utiliza 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
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.
en el que se encuentran cuatro etapas distintas: «status
definición de problemas, desarrollo técnico e inte-
Desarrollo
gración de soluciones. Status quo «representa el estado técnico
actual de la definición de proble-
mas identifica el problema específico a resolverse; el
desarrollo técnico resuelve el problema a través de la
aplicaciónde 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 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 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. Fases dentro de las fases
logía». Conforme progresa el trabajo hacia un sistema del bucle de resolución de problemas
19

18. DEL SOFTWARE. UN ENFOQUE PRÁCTICO
2.4
Llamado algunas veces «ciclo de vida básico» o 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
Como el software siempre forma parte de un sistema Aunque el modelo lineal es a menudo
más grande (o empresa), el trabajo comienza estable- tradicional», resulto un enfoque razonable
ciendo requisitos de todos los elementos del sistema y cuando los requisitosse han entendido correctomente.
asignando al software algún 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 Entre los problemas
cialmente en el software. Para comprender la naturaleza que se encuentran algunas veces en el modelo lineal
del (los) a construirse, el ingeniero secuencial se incluyen:
lista») del software debe comprender el dominio de
información del software (descrito en el Capítulo 1 así 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
hacía provisiones para de la gran
mayoría d e las organizaciones que aplican este modelo de proceso
lo hacen como si fuera estrictamente lineal.
20