M1 - M2

Unidad 1: Ingeniera de Software
1.1
Ingeniera de Software
1.1.1 Concepto de Ingeniera de Software

La Ingeniera de software es una disciplina, como expresa su nombre, de Ingeniera, la cual
comprende todos los aspectos de la produccin de software, es decir, desde las etapas iniciales
de la especificacin del sistema, lo que debe hacer, hasta su entrega y mantenimiento. El
mantenimiento del software se realiza despus de haber sido entregado al cliente y ste lo est
utilizando.
Otra definicin que podemos plantear es la de D. L. Parnas (Programming Methodology, 4th
Informatik Symposium, 1974), quien defini a la ingeniera en software como multi-person
construction of multi-version software, su traduccin sera varias personas en la construccin de
multiversin de software.
Es lgico pensar que el software que se produce funciona correctamente y satisface las
necesidades del cliente, para que esto sea as es necesario que se cumplan varias etapas del
desarrollo del mismo y los recursos humanos involucrados deben ser capaces de hacerlo cumplir.
Para ello resulta necesario conocer conceptos fundamentales que hacen a la Ingeniera de
software.
Los ingenieros son los encargados de hacer que los software funcionen, para ello aplican teoras,
mtodos y herramientas de forma selectiva, tratando de descubrir soluciones a los problemas
existentes o futuros, an cuando no existan teoras o mtodos aplicables a la resolucin de dichos
problemas.
Todo proyecto tiene restricciones de tiempo, organizacionales y de presupuesto, por lo que el
ingeniero debe tener en cuenta en la resolucin de los problemas estas restricciones. Son
entonces los encargados de llevar el proyecto adelante y que ste sea con xito, para ello deber
realizar la gestin integral del proyecto, el desarrollo de herramientas, teoras y/o mtodos que
apoyen la produccin de software.
El trabajo del ingeniero debe ser sistmico y organizado, como lo determina la Ingeniera, si quiere
obtener un software de alta calidad, pero a su vez necesita ser flexible a los cambios y tener un
enfoque ms informal y creativo para algunos casos que lo requieran.
Para entender mejor la definicin primero tiene que conocer el concepto de software.
Qu es software?
El software es ms que programas; tiene una caracterstica muy importante que hay que atender:
es un sistema.
Antes de mirar ms profundamente el proceso de creacin de software, ser til explorar algunos
aspectos del software mismo. Como dice el viejo adagio: para derrotar a tu enemigo hay que
conocerlo. (Freeman).
Lo importante es definir qu es software, cmo se piensa en l y qu papel cuenta en un contexto
mayor. Si nuestro concepto de software es slo desde el punto de vista de una computadora, ser
Materia: Ingeniera de Software

Profesora: Lic. Adriana Prez
-1-
slo programas, lneas de cdigo que se producen en un determinado tiempo; esto es un error, ya
que nos llevar a tener montaas de cdigos que no se integrarn como sistema y que no
lograrn satisfacer las necesidades del cliente, aunque tcnicamente sean correctos.
Software es un conjunto de programas que se ejecutan en un ordenador y la documentacin
asociada, de este modo los productos de software pueden desarrollarse para un cliente en
particular o para un mercado particular o general.
Existen tres tipos bsicos de software:
System software
Utilitarios
Software de Aplicacin
Cualquiera sea el tipo de software, requiere de informacin que lo acompae para su correcto
entendimiento y uso para luego mantenerlo, caso contrario lo llevar a tener errores que no
podrn ser salvados en el tiempo.
El software tiene caractersticas que es importante conocer, veamos algunas de ellas.
Su Naturaleza y Cualidades:
El software es fcilmente modificable, lo que implica que el cdigo responde a una lgica y
normalmente es de quien lo construye, por lo que si cambia el actor es muy posible que
cambie el cdigo.
No es tangible, como otros productos. Al ser intangible no es fcil imaginarse el tamao o
la forma del software, muchas veces se cree que realizar una aplicacin o una nueva
funcionalidad es algo simple, pero la mayora de las veces implica un gran trabajo difcil de
visualizar.
Clasificacin de las Cualidades:
Externas versus internas, se pueden considerar como externas la usabilidad del software
por los usuarios, mientras que la interna es tcnica, la ven quienes codifican. Es posible
que un software est muy bien diseado y codificado pero al usuario le resulte difcil de
entender y usar, o totalmente al revs, el usuario solicita algo que mientras lo entienda y
sea fcil de usar no importa si tcnicamente est bien realizado. Lo ptimo es que cumpla
con ambas condiciones.
Cualidades de producto y proceso. El proceso de desarrollo de software dar un producto
final que se espera que sea de calidad y satisfaga las necesidades del cliente, para ello el
proyecto deber ser exitoso y el proceso de software tambin.
Cualidades Representativas:
Correctitud, confiabilidad y robustez
o Correctitud: un programa es funcionalmente correcto si se comporta acorde a la
especificacin de la funcin que debera proveer.
o Confiabilidad: un programa es confiable si el usuario puede depender de l. El
software no debe causar dao fsico o econmico si falla.
o Robustez: un programa es robusto si se comporta razonablemente, an en
situaciones que no fueron anticipadas en los requerimientos.
Performance: afecta la usabilidad de un sistema
Confiabilidad: El software no debera malgastar el uso de los recursos del sistema.
Amigabilidad: esto ocurre si los seres humanos lo encuentran fcil de usar
Verificabilidad: esto ocurre si sus propiedades pueden ser verificadas fcilmente

-2-
Mantenibilidad: se refiere a modificaciones que se le hacen al software despus de su

lanzamiento inicial. Es software debera evolucionar acompaando el cambio que puede
ser:
o Reparativo.
o Evolutivo
Reusabilidad: software o componentes de l que permiten evolucionar a otra versin con
mnimas modificaciones
Portabilidad: si corre en diferentes ambientes, plataformas, entendiendo por plataforma al
hardware y sistema operativo.
Comprensible: si es fcil de entender por otros
Interoperabilidad: si el software es capaz de convivir con otros
Productividad: la eficiencia puesta en el proceso
Entrega en fecha: entregar un producto en el tiempo previsto
Visibilidad: si todos los pasos y su actual estado estn documentados claramente.
Si el software es lo que se entrega al cliente, entonces se puede considerar un producto.

Software como producto
Desde los aos 60 se comenz a separar el concepto de software de hardware, fue entonces que
comenz a constituirse como producto.
El software es tanto un producto como un objeto tcnico, esto es: conocimiento empaquetado.
Software como conocimiento
Si los programas que se entregan al finalizar el proceso de desarrollo contienen conocimiento,
entonces sus primeras versiones tambin contienen conocimiento, que en el punto de vista de
vista de software slo como programas ejecutables lo perdemos. No perder este conocimiento es
uno de los pilares de la caracterstica de reusabilidad del software.
Este conocimiento es de las personas que intervienen en el proyecto, cada uno aporta algo a un
todo, si este conocimiento no queda documentado se pierde en el tiempo, ya sea porque las
personas se van del proyecto o por olvido.
Como el software es maleable y responde a cambios, es importante pensarlo de otra forma, un
cambio en el software atiende a un cambio de diseo ms que de cdigo.
El proceso de produccin de software atiende ms al diseo e implementacin que a la
manufactura del mismo.
Las visiones del producto de software atienden a distintos actores, cada uno espera algo distinto
de l:
Usuario: que sea confiable, eficiente y fcil de usar.
Productor: que sea verificable, mantenible, portable y extensible.
Administrador del proyecto: productivo y fcil de controlar.
Es por ello que el software que se entrega es un producto compuesto por programas ejecutables y
documentacin que lo acompaa.
Veamos las caractersticas que tiene el producto de software:

-3-
Es un software ms sofisticado
Es usado por personas distintas al desarrollador
Es extensivamente testeado antes de ser liberado
Su costo de desarrollo es 3 veces mayor al de un programa
Recordemos tambin el concepto y alguitas caractersticas de sistema:

Grupo de programas que trabajan juntos
Su desarrollo es complicado debido a la complejidad de sus interfaces entre los
componentes
Integracin
Su desarrollo cuesta 3 veces lo que cuesta desarrollar un programa
Si unimos todos los eslabones de esta cadena de conceptos, podemos identificar qu es un
Sistema producto:
Tiene el pulido de un programa
Mltiples partes de un sistema
Su costo de desarrollo cuesta alrededor de 9 veces ms que un simple programa
Otras de las diferencias importantes de entender son las relacionadas con la Ingeniera en
sistemas.
Cual es la diferencia entre Ingeniera en Software y el Profesional en Sistemas?
La Ingeniera en Sistema se ocupa de todos los aspectos del desarrollo de un sistema (aspectos
humanos, de software, de hardware, de procesos, otros), mientras que la Ingeniera en Software
es parte de ese proceso.
As la Ingeniera de software debe cumplir con los siguientes principios, que son indispensables
para lograr un producto final de calidad:
Rigor y formalidad
Separacin de intereses
Modularidad
Abstraccin
Anticipacin al cambio
Generalidad
Incrementabilidad
El Rol del Ingeniero de Software. A veces se confunden los roles con los ingenieros de otras
disciplinas; si bien tienen algunas en comn, es bueno identificar aquellas que hacen
especficamente al rol del Ingeniero en Software:
Buen programador. Es necesario que rena las caractersticas de un buen programador,
no es indispensable que sea en un lenguaje determinado, sino que haya adquirido las
herramientas necesarias para resolver un problema a travs de la programacin.
Enfoques de diseo. Debe ser capaz de realizar buenos diseos de software.
Niveles de abstraccin, haber adquirido un nivel de abstraccin que le permita ver la
solucin de forma intangible.
Saber modelar. Realizar un modelo conceptual es indispensable para luego poder
plasmarlo en el producto concreto.
Habilidades de comunicacin interpersonal. La comunicacin y las buenas relaciones con
los integrantes del equipo son fundamentales para lograr un ambiente de trabajo
productivo.

-4-
Ser capaz de planificar su trabajo y el de otros. Con desorganizacin no se produce

software de calidad, por lo que la planificacin de las actividades es fundamental.
Como en todas las profesiones el Ingeniero de software de tener presente la tica y la
responsabilidad profesional:
Responsabilidades que van ms all de la simple aplicacin de habilidades tcnicas.
Los Ingenieros en Software se deben comportar en forma honesta y ticamente
responsables para ser respetados como profesionales.
La conducta tica es ms que el simple cumplimiento de la ley.
Temas de la responsabilidad profesional:
Confidencialidad
Competencia
Derechos de propiedad Intelectual
Malas practicas
Algunos dilemas ticos que se pueden presentar son:
Desacuerdo con las polticas de la direccin.
Su empleador acta en forma no tica y libera software de caractersticas crticas sin
terminar las fases de testeo.
Participacin en el desarrollo de software militar y armamento nuclear
1.1.2 Problemas de la ingeniera de Software. La crisis de desarrollo

de software
Las economas de TODAS las naciones desarrolladas son dependientes del software, si
atendemos esta afirmacin el software debe garantizar buenos negocios y nunca prdida de
dinero.
La fabricacin industrial, comercial y del sistema financiero est totalmente informatizada, por lo
que producir software costeable es fundamental para el funcionamiento de la economa nacional e
internacional.
Existieron factores que influyeron para que el software no fuese costeable:
La evolucin de la tecnologa.
El proceso de desarrollo
La administracin de proyectos
El mantenimiento del software
La nocin de Ingeniera del software fue introducida en 1968 en una conferencia para discutir lo
que se llam Crisis del software, resultado de la introduccin de nuevas tecnologas en hardware
basadas en circuitos integrados. As, el software que se produca implicaba nuevos conocimientos
y nuevos lenguajes de programacin con software de magnitudes mayores y ms complejos que
los sistemas previos.
Durante aos el desarrollo de Software ha sido un arte, una tarea artesanal basada en el
conocimiento de los desarrolladores de cdigo y del cliente. Se supona que el cliente saba lo que
necesitaba y lo solicitaba, generalmente lo haca directamente a los desarrolladores y en el mejor
de los casos al Gerente del rea de Investigacin y Desarrollo.

-5-
Este tipo de prctica slo llev a vivir La crisis del software, clientes insatisfechos y prdida de
dinero para los dueos de las consultoras.
Esta forma de trabajar tiene un alto riesgo, cuando se carece de profesionalidad y calidad en el
producto final.
Para revertir esta situacin en un principio se incorpor una persona como intermediario entre el
cliente y el desarrollador, el Comercial quien tena la funcin de comunicar el requerimiento del
cliente a desarrollo, pero es evidente que entre lo que el cliente ve, necesita, piensa que ve o
piensa que necesita y lo que recepta el intermediario hay diferencias, de ms est decir que la
diferencia se ampla cuando se transmite, lo que lleva inevitablemente a no cubrir las expectativas
del cliente.
Cunto tiempo y dinero se pierde cada vez que se trata de resolver un error? Se cobra por
desarrollar un software y por mantenerlo pero no para solucionarlo, donde las horas de
recodificacin son a cargo del dueo de la consultora de software.
Por otro lado:
Quin prueba el software? El cliente? La respuesta debera ser no, ya que al cliente le debe
llegar el producto final funcionando correctamente, para lo cual se agrega el rol de Tester interno
en la empresa.
Con estas medidas podramos solucionar en parte los problemas, es comn escuchar expresiones
tales como, El problema es el cdigo, los que no saben son los desarrolladores, pero la verdad
no es sa.
Est comprobado que el mayor problema est en la captura del requerimiento, tarea que requiere
de conocimiento de negocio, de anlisis y diseo de interfaz grfica, porque es la persona
encargada de interpretar correctamente el problema, transmitirlo y documentarlo con la garanta
de que ste responde al requerimiento del cliente. Tan importante es esta tarea que hoy es tratada
como Ingeniera de Requerimiento.
La experiencia previa en la construccin de estos sistemas mostr que un enfoque informal para
el desarrollo del software no era bueno. Los grandes proyectos no se entregaban en trmino con
retrasos de aos, costaban mucho ms que lo presupuestado, totalmente irrealizables, difciles de
mantener y con pobre desempeo.
Mientras el hardware mostraba avances tecnolgicos que lo hacan superior y bajaban los costos,
el software sufra una evolucin totalmente al revs.
Estaba claro que se necesitaba revertir esta situacin y para ello haba que fijar los lineamientos
para que la produccin de software se convirtiera en una Ingeniera, nuevas tcnicas y mtodos
para controlar la complejidad inherente a los grandes sistemas.
Tomamos la definicin de Ingeniera de software de Fairley (Ingeniera de Software, 1987): La
Ingeniera de Software es la disciplina tecnolgica y de administracin que se ocupa de la
produccin y evolucin sistemtica de productos de software que son desarrollados y modificados
dentro de los tiempos y costos estimados.
En estos tiempos donde las empresas necesitan ser competitivas, responder al dinamismo de los
cambios en forma eficiente es sumamente importante, para ello se define un correcto proceso de
software, donde el cliente est al inicio y al final, desde el requerimiento hasta la entrega,

-6-
estableciendo las etapas mnimas que garantizan un producto de calidad y la satisfaccin del
cliente.
Sabemos que no hay un ideal de la Ingeniera de software, debido a la gran diversidad de tipos
de sistemas y organizaciones que los usan, por lo que necesitamos tener diversos enfoques para
el desarrollo de software, no obstante, las nociones fundamentales de procesos y organizacin del
sistema constituyen la base de todas las tcnicas y, a su vez, son la esencia de la Ingeniera de
software.
El desafo es ponerse en movimiento hacia el cambio en post de la mejora continua,
acompaando al crecimiento profesional y econmico de todos.
1.1.3 Diferencias entre Ingeniera de Software y Ciencia de la

Computacin.
Otra diferencia importante a destacar es el concepto de Ciencia de la computacin con el de
ingeniera de software.
La Ciencia de la computacin comprende la teora y fundamentos, mientras que la ingeniera de
software comprende las formas prcticas para desarrollar y entregar un software requerido y til
para el cliente.
La ingeniera de software, al atender el proceso de desarrollo de software, se diferencia de la
ingeniera en sistemas, ya que esta ltima se refiere a todos los aspectos del desarrollo de
sistemas informticos, incluye hardware, software e ingeniera de procesos.
Concepto de sistema
El trmino Sistema es utilizado universalmente, aplicado a todas las disciplinas, en el caso de la
computacin hablamos de Sistemas Operativos, sistemas informticos, sistema educativo,
sistemas contables y financieros, entre otros. Si bien difieren unos de otros, todos entienden que
un sistema es ms que una suma de partes.
Definicin de Sommerville: Un sistema es una coleccin de componentes interrelacionados que
trabajan conjuntamente para cumplir algn objetivo.
Esta definicin es tan amplia que puede incluir a sistemas tan simples como puede ser un velador
o un bolgrafo, hasta los sistemas muy complejos como podra ser un sistema de aviacin o de
seguridad area, entre muchos otros casos posibles que incluyen diversas tecnologas, hardware
y software.
Los sistemas informticos que incluyen software se dividen en dos categoras:
Sistemas tcnicos informticos. Estos sistemas incluyen hardware y software pero no
incluyen procesos ni procedimientos. Como ejemplo de estos sistemas estn los
electrodomsticos como lavarropas automticos, microondas, como tambin los
televisores, los telfonos mviles y las computadoras con sus componentes internos. Los
sistemas como herramientas informticas tales como los procesadores de texto o las
planillas de clculo tambin entran en esta categora.
Sistemas socio-tcnicos. Estos sistemas comprenden uno o ms sistemas tcnicos pero
adems incluyen el conocimiento necesario para su uso para lograr su funcionalidad.

-7-
Significa que estos sistemas incluyen los procesos y procedimientos operativos, las
personas que lo operan, las reglas internas, de negocio, como tambin las reglas externas
que rigen su uso y funcionamiento. Como ejemplo podemos citar un sistema de facturacin
que incluye los procesos necesarios, las reglas impositivas que lo rigen y las reglas
internas de la organizacin.
Entre las caractersticas fundamentales de los sistemas socio-tcnicos encontramos las
siguientes:
Tienen propiedades emergentes, propiedades del sistema como un todo ms que
asociadas con las partes del sistema, que dependen tanto de los componentes como de
las relaciones entre ellos. Estas propiedades pueden ser evaluadas luego de ser
implementado el sistema.
Por lo general no son sistemas determinsticos. No siempre producen la misma salida con
una entrada especfica, ya que el comportamiento del sistema depende de operadores
humanos, de su uso y tratamiento. Adems, se debe contemplar la posibilidad de que el
sistema pueda proporcionar nuevas relaciones entre sus componentes.
El grado de apoyo a los objetivos organizacionales no depende solamente del sistema. La
concrecin de los objetivos dependen de la estabilidad de los mismos, conflictos entre
cmo son planteados e interpretados por las personas, as dependiendo de las personas
un sistema exitoso puede convertirse en un fracaso y no utilizarlo.
Teniendo en cuenta lo expresado anteriormente, las propiedades emergentes de un sistema se
dan en conjunto cuando el sistema ha sido implementado completamente e interactan sus
componentes de forma integral.
Estas propiedades emergentes pueden considerarse como funcionales y no funcionales:
Funcionales, cuando todos los componentes del sistemas trabajan conjuntamente para
lograr un objetivo comn.
No funcionales, se refieren al comportamiento de los sistemas en su entorno operativo.
Entre ellas encontramos, la fiabilidad, el rendimiento, la seguridad y la proteccin.
Entre estas propiedades no funcionales, la fiabilidad es quizs la ms importante ya que se puede
aplicar a los cinco componentes principales de los sistemas socio-tcnicos, fiabilidad del
hardware, del software, de las personas que lo operan, de los procesos definidos y de los datos
utilizados.
Cules son las diferencias entre el proceso de la ingeniera de sistemas y el proceso de
desarrollo de software?
El desarrollo de sistemas tiene un alcance limitado para rehacer el trabajo. Cuando se han
tomado las decisiones en la Ingeniera del sistema se han planteado las etapas y las
acciones de cada una, donde cada etapa verifica con la anterior si el camino es el correcto,
por lo que pensar en cambios a la mitad del proceso traera costos y riesgos muy grandes.
Las etapas que se identifican en el proceso de Ingeniera de sistemas son las siguientes:
o Definicin de requerimientos
o Diseo del sistema
o Desarrollo del subsistema
o Integracin del sistema
o Instalacin del sistema
o Evolucin del sistema
o Desmantelamiento del sistema

-8-
Alcance interdisciplinario. En la Ingeniera de sistemas se conjugan muchas Ingenieras,

como puede ser la electrnica con la mecnica y la de software.
El proceso de desarrollo de software involucra:
procesos de negocio,
procedimientos operativos que se deben tener en cuenta a la hora de disear los procesos
informatizados,
las necesidades del cliente que se traducen en requerimientos funcionales para el
software,
los requerimientos no funcionales, que hacen a la forma de presentacin o performance
del software,
los requerimientos candidatos, que son las funcionalidades que no se informatizarn en
este momento, pero que se tendrn en cuenta para el futuro,
las etapas de captura de requerimiento, anlisis, diseo, codificacin, prueba, instalacin y
mantenimiento.
Las personas, cada una en el rol que se le requiere, tanto las internas como grupo de
trabajo del proceso de desarrollo como las externas como clientes y usuarios.
Los cambios organizacionales, de procesos, de personas, tanto internos como externos.
1.2
Ciclo de Vida
1.2.1 Ciclo de Vida: Conceptos de Proceso de Desarrollo de Software.

Proceso de desarrollo de software
Se entiende por proceso de software al conjunto estructurado de actividades para desarrollar un
sistema de software.
Estas actividades varan dependiendo de la organizacin y el tipo de sistema que debe
desarrollarse.
Debe ser explcitamente modelado si va a ser administrado.
Person
as
Requerimientos
Ideas
Tiempo
Materiales
Energa
Equipamiento
Actividades
Procedimiento
s
Productos y
servicios
Caractersticas del Proceso

Comprensibilidad: Si el proceso est definido y es comprensible.
Visibilidad: Si el progreso del proceso es visible externamente.
Suportabilidad: Puede soportarse con herramientas CASE (Computer Aided Software
Engineering, en castellano Ingeniera de Software Asistida por Computadora)

-9-
Aceptabilidad: Si el proceso es aceptable por los que deben utilizarlo

Confiabilidad: Si los errores del proceso son descubiertos antes que resulten errores del
producto.
Robustez: Puede el proceso continuar frente a problemas inesperados
Mantenibilidad: Puede el proceso evolucionar para alcanzar las necesidades de cambio,
organizacionales.
Rapidez: Cun rpido puede producir el sistema.
Si bien no se puede tratar al proceso de software como una serie de actividades preestablecidas e
inmodificables, ya que cada producto de software final es nico y atiende a caractersticas de
organizacin, cliente, proyecto y factores internos y externos, se identifican 4 actividades
fundamentales para todos los procesos, que son:
Especificacin del software. Se trata de definir las funcionalidades que deber tener el
software y las restricciones en su operacin.
Diseo e implementacin del software. Primero se disea la solucin y luego se produce el
software que cumpla con la especificacin.
Validacin del software. Se valida con el cliente la funcionalidad del software asegurando
que realiza lo que el cliente desea y necesita.
Evolucin del software. Las organizaciones son sistemas dinmicos que se acomodan a
los cambios, el software debe evolucionar para cubrir las necesidades de cambio que
plantea el cliente.
Cada empresa adopta el proceso con las etapas que considera mejor segn el equipo de gente
que dispone, siempre teniendo en cuenta estas 4 actividades fundamentales.
Todo proceso de construccin de software lleva un tiempo desde que es requerido por el cliente
hasta que se finaliza y se entrega el producto final, luego viene el mantenimiento del mismo. Este
tiempo es el Ciclo de Vida.
Como ciclo de vida, tiene un comienzo y puede tener un fin, de acuerdo al lmite que se determine,
en ese tiempo es que se dan las actividades fundamentales que vimos anteriormente.
Como determinamos que no existe un proceso ideal, es que este proceso ha tomado distintas
formas en el tiempo, de acuerdo a la respuesta obtenida y la retroalimentacin que se realiza del
mismo.
Existen modelos de procesos de desarrollo de software que han evolucionado en el tiempo y se
identifican con las caractersticas de la realidad de cada momento.
Dentro de una organizacin pueden existir sistemas que estn funcionando y que quizs no
cumplan con todas las necesidades del cliente, pero que no se pueden dejar de usar. Las nuevas
funcionalidades tendrn que tener en cuenta estos sistemas para su integracin. Estos sistemas
se consideran Sistemas heredados, en algunos casos no se pueden modificar, slo utilizar, en
otros casos se puede modificar, pero si no poseen documentacin es una tarea muy compleja.
Las nuevas funcionalidades o los sistemas completos se pueden desarrollar o adquirir, o sea que
en una organizacin pueden coexistir sistemas heredados, sistemas propios y sistemas
adquiridos; es necesaria la integracin de las partes para alcanzar la funcionalidad, el objetivo y el
trabajo como sistema.

- 10 -
1.2.2 Ciclo de Vida: Modelos

Qu es un modelo de procesos del software?
Comencemos con la definicin de modelo segn la Real Academia Espaola:
Modelo: Esquema terico, generalmente en forma matemtica, de un sistema o de una
realidad compleja, como la evolucin econmica de un pas, que se elabora para facilitar
su comprensin y el estudio de su comportamiento.
Esta definicin puede aplicarse al proceso de desarrollo de software; el modelo se plantea terico,
para facilitar su comprensin y el estudio de su comportamiento.
Definicin de modelo de procesos de software planteado por SOMMERVILLE, IAN (Ingeniera del
Software, pg. 25): Un modelo de procesos es una descripcin simplificada de un proceso del
software que presenta una visin de ese proceso.
Esta definicin la podemos interpretar como: La serie de pasos a travs de los cuales el producto
progresa, teniendo en cuenta las personas involucradas en la ingeniera del software.
Un ciclo de vida de software es una representacin de un proceso. Representa una descripcin
del proceso desde una perspectiva particular.
En todos los casos los modelos especifican:
Las fases de proceso. Por ejemplo: requerimientos, especificacin, diseo.
El orden en el cual se llevan a cabo.
Cul es la importancia de los Modelos de Ciclos de Vida?
La importancia de los modelos de ciclos de vida es amplia, fundamentalmente ayudan al
seguimiento del proceso, organizacin y planificacin. Veamos algunas de ellas:
Proveer una gua para la administracin de proyecto.

o Cules de las tareas deben ser rastreadas?
o Qu tipo de progreso se ha realizado?
o Cules son las actividades que se deben realizar y en qu orden?
o Cundo interactuamos con el cliente?
o Qu tenemos que tener en cuenta?
Cul es la necesidad de modelos de ciclos de vida?

Para tener las ventajas descriptas anteriormente son necesarios los modelos de ciclos de vida, as
como conocerlos para poder elegir cul es ms conveniente utilizar, de acuerdo al caso a resolver
y a la situacin.
La necesidad de modelos de ciclos de vida.

o El carcter del desarrollo de software ha cambiado.
pocas tempranas: los programadores eran los usuarios finales.
Diseos muy modestos, desconocimiento del potencial del software.
o Sistemas ms complejos

- 11 -
Ms funcionalidad, ms sofisticacin
posibilidades de cometer errores.
Usuarios heterogneos.
mayor complejidad, ms
Algunos factores que ayudaron a la necesidad de contar con modelos fueron:

Normalmente, las especificaciones son incompletas y con anomalas.
Muy difusa la distincin entre especificacin, diseo y manufactura.
No hay una realizacin fsica del sistema en las pruebas.
Software no se consume, el mantenimiento no significa reemplazo.
Recordemos que el ciclo de vida de un proyecto comienza cuando el mismo forma parte de una
idea hasta la implementacin en todos los usuarios que utilizarn el sistema y que un modelo de
ciclo de vida define el estado de las fases a travs de las cuales se mueve un proyecto de
desarrollo de software.
Existen muchos modelos, algunos se desprenden de otros, tambin depende de los autores de las
distintas bibliografas. Sommerville Ian (Ingeniera del Software, pg. 25), plantea que la
mayora de los modelos de procesos del software se basan en uno de los tres modelos generales
o paradigmas de desarrollo de software:
Enfoque en cascada. Totalmente secuencial, una etapa despus de terminada la anterior.

Se termina, se firma y se sigue con la siguiente.
Desarrollo iterativo. Entrelaza las actividades de especificacin, desarrollo y validacin.
Parte de especificaciones muy abstractas, se refina de acuerdo a las peticiones del cliente
para finalmente producir un sistema que satisfaga las necesidades de dicho cliente.
Ingeniera del software basado en componentes (CBSE). Supone que las partes del
sistema existen, por lo tanto, el proceso de desarrollo se enfoca en la integracin de las
partes ms que en su desarrollo desde el principio.
1.2.3 Ciclos de vida secuenciales: El modelo en cascada

Modelo en cascada
Fue el primer ciclo de vida de software, definido por Winston Royce a fines del 70.
Es el ms bsico de todos los modelos y sirve como bloque de construccin para los dems
modelos de ciclo de vida, plantea una visin simple basada en el concepto que el desarrollo de
software puede ser a travs de una secuencia simple de fases. Cada fase tiene un conjunto de
metas bien definidas y las actividades dentro de una fase contribuyen a la satisfaccin de metas
de esa fase o quizs a una subsecuencia de metas de la fase. Existen fases discontinuas, las
cuales no se solapan. Este modelo est orientado a la documentacin.
El modelo de ciclo de vida cascada, captura algunos principios bsicos:
Planear un proyecto antes de embarcarse en l.
Definir el comportamiento externo deseado del sistema antes de disear su arquitectura
interna.
Documentar los resultados de cada actividad.
Disear un sistema antes de codificarlo.
Testear un sistema despus de construirlo.

- 12 -
Se realizan relevamientos de los siguientes aspectos:

Tcnicos: equipamiento, capacidad tcnica de recursos
Funcionales: extraccin completa de los Requerimientos, el 100%.
Del Negocio: los sectores involucrados
Su utilizacin es beneficiosa en:
productos bien definidos
con metodologas tcnicas bien entendidas,
una actualizacin de un mantenimiento existente
el traslado de un producto a una nueva plataforma
en un equipo de trabajo sin experiencia
En los primeros aos tuvo mucha aceptacin, luego se fueron realizando modificaciones tratando
de lograr adaptarlo a las necesidades.
Encontramos como ventajas sobresalientes, las siguientes:
Provee informacin a travs del ciclo de vida y la documentacin de cada fase.
Favorece el seguimiento del proceso ordenndolo, con actividades bien comprendidas
pero complejas.
A partir de los 90 ha sido sujeto a numerosas crticas, debido a que es restrictivo y rgido, lo cual
dificulta el desarrollo de proyectos de software moderno.
Algunas de sus desventajas son:
Lleva mucho tiempo finalizarlo por ser tan secuencial
No se puede comenzar hasta tener el total de los requerimientos antes de comenzar con el
diseo.
Es rgido, ya que no permite volver hacia etapas anteriores para corregir errores
No es aconsejable para desarrollos cortos porque posee una excesiva cantidad de
documentacin
Especificacin de
Requerimiento
Definicin
Anlisis
Especific.
Diseo
Diseo
Implementacin y
Unidad de Testeo
Desarrollo
Integracin
Implementacin
Mantenimiento

- 13 -
Debido a las desventajas del modelo, muchos modelos nuevos de ciclo de vida han sido
propuestos, incluyendo modelos que pretenden desarrollar software ms rpidamente, ms
incrementalmente, de una forma ms evolutiva o precediendo el desarrollo a escala total con
algn conjunto de prototipos rpidos.
Desarrollo evolutivo
El desarrollo evolutivo consiste en desarrollar una implementacin inicial, entregada a los usuarios
para sus comentarios y refinndola a travs de la retroalimentacin y las versiones hasta lograr el
sistema adecuado.
Los requerimientos son cuidadosamente examinados y slo aquellos que son bien comprendidos
son seleccionados para el primer incremento. Los desarrolladores construyen una implementacin
parcial del sistema que recibe slo estos requerimientos. El cliente lo usa, basado en la
retroalimentacin y en los nuevos requerimientos se construye la nueva versin, as el proceso se
repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos
(incremental) y comprender que nuevos requerimientos aparecern cuando el sistema sea
desplegado o desarrollado.
Las actividades de especificacin, de desarrollo y validacin se entrelazan en vez de separarse,
con una rpida retroalimentacin entre stas.
Existen 2 tipos de desarrollo evolutivo:
Desarrollo exploratorio, donde se trabaja con el cliente para explorar sus requerimientos y
entregar un sistema final, comenzando siempre por los requerimientos del sistema que se
entienden mejor. El sistema crece, evoluciona con lo que el cliente va proponiendo.
Prototipos desechables, en este caso se centra en los requerimientos que no estn muy
claros, por lo que el objetivo es comprender los requerimientos del cliente para poder
desarrollar una definicin mejorada del sistema.
Visto desde la ingeniera de gestin, el modelo evolutivo tiene los siguientes problemas:
Carencia de Visibilidad del Proceso
Los sistemas frecuentemente son pobremente estructurados
Puede requerirse habilidades Especiales (Ej. En lenguajes de prototipacin rpida)
Es factible su aplicacin:
Para Sistemas interactivos de tamao pequeo o mediano.
Para partes de sistemas grandes (Ej. Interfaces de usuario).
Para sistemas de ciclo de vida corto.
Veamos el modelo representado en el siguiente grfico.

- 14 -
Ingeniera de software basada en componentes

Con los avances de la programacin orientada a objetos, el conocimiento de sistemas que actan
en forma similar se ha incorporado el concepto de componente reusable.
Este enfoque requiere de componentes de software reutilizables (cantidad que va creciendo) y de
un marco de trabajo de integracin de estos. Es posible que estos componentes sean sistemas
por s mismos, subsistemas o mdulos que tienen una funcionalidad especfica.
Veamos la grfica de este modelo.
Especificacin
de Rqs.
Anlisis de
componentes
Modificacin
de Rqs.
Diseo de sistemas
con reutilizacin
Desarrollo e
integracin
Validacin
del sistema
Si bien las etapas de especificacin de requerimientos y la de validacin son similares a otros

procesos, las etapas intermedias son diferentes.
Desarrollemos estas etapas intermedias:
Anlisis de componentes: teniendo la especificacin de requerimientos se buscan los
componentes necesarios que cumplan con toda la funcionalidad o con parte de ella. En este caso
sern modificados, llevndolos al punto ms general posible, para que se constituyan en libreras
de componentes capaces de ser reutilizados en ms de un proyecto sin tener que modificarlos.
Modificacin de requerimientos: si los componentes encontrados para los requerimientos no son
modificables, se pueden buscar soluciones alternativas, modificando en parte el requerimiento, sin
que deje de cumplir con la necesidad del cliente.

- 15 -
Diseo de sistemas con reutilizacin: esta etapa se relaciona con el marco de trabajo, son los
diseadores los que tienen en cuenta los componentes que se reutilizan para organizar el marco
de trabajo que los satisfaga o bien disear nuevos componentes porque no se cuenta con los
necesarios.
Desarrollo e integracin: estas etapas no son independientes, es necesaria su integracin ya que
es parte del desarrollo tener en cuenta los componentes que existen, los que se adquieren
externamente y los que se desarrollan internamente para integrarlos en un todo.
Ventajas de la ingeniera de software basada en componentes:
Reducir la cantidad de software a desarrollar
Reducir costos
Reducir riesgos.
Permite una entrega ms rpida
Riesgos del uso de este modelo:
Si depende totalmente de los componentes a reutilizar puede ser que el producto no
cumpla con las necesidades del cliente.
Las nuevas versiones de los componentes pierden la especificidad de la organizacin, se
plantean generales, por lo que requiere de la necesidad de relevar las reglas de negocio
de cada cliente.
Este modelo tiene mucho en comn con el enfoque que est surgiendo en los ltimos aos para el
desarrollo de sistemas que se basan en la integracin de servicios Web.
Modelo incremental
Si el desarrollo de sistema es complejo y es un proyecto a largo plazo, implica que tiene asociado
demasiados riesgos, como por ejemplo que no se termine, que no cumpla con las necesidades del
cliente que cambiaron desde que lo solicit, que el costo sea muy elevado, entre otros.
Una forma de reducir estos riesgos es construir slo una parte de sistema, organizando por
versiones lo que se incrementa.
En el modelo incremental requiere del 100% de los requerimientos al comienzo del ciclo de vida,
se toman subconjuntos de requerimientos y se desarrollan en versiones siempre incrementando el
producto de software. El documento de requerimientos es escrito al capturar todos los
requerimientos necesarios para el sistema completo, es el que sirve de gua para los incrementos.
Este modelo es compatible con el modelo cascada, no obstante el modelo incremental provee
algunos beneficios significativos para los proyectos:
Construir un sistema pequeo es siempre menos riesgoso que construir un sistema
grande.
Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los
requerimientos planeados para los niveles subsiguientes son correctos.
Si un error importante es realizado, slo la ltima iteracin necesita ser descartada.
Reduciendo el tiempo de desarrollo de un sistema, decrecen las probabilidades que esos
requerimientos de usuarios puedan cambiar durante el desarrollo.
Si un error importante es realizado, el incremento previo puede ser usado.
Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del
comienzo del prximo incremento.

- 16 -
Veamos su grfica de organizacin de etapas:
Requisitos
Diseo
Requisitos
Diseo de
Arquitectura
Diseo
detallado
Desarrollo
Codificacin
y pruebas
unitarias
Pruebas de
integracin
Pruebas de
sistema
Instalacin y
capacitacin
Implementacin
Aceptacin del
cliente
Tanto el modelo de desarrollo incremental como el modelo de desarrollo evolutivo construyen una
serie de grandes versiones sucesivas de un producto. La diferencia radica en el conocimiento de
los requerimientos, mientras que la aproximacin incremental presupone que el conjunto completo
de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no
son completamente conocidos al inicio del proyecto.
Modelos que derivan de los anteriores
Modelo de Prototipado de Requerimientos
El prototipado de requerimientos tiene el propsito explcito de aprender sobre los requerimientos
del sistema, para ello se crea una implementacin parcial del sistema.

- 17 -
Por lo general consiste en la entrega de prototipos de interfaz de usuario, construido de una

manera tan rpida como sea posible. Esto es dado a los usuarios, clientes o representantes de
ellos, quienes sern los que proveen la retroalimentacin sobre lo que a ellos les gust y no les
gust acerca del prototipo proporcionado.
En los 90 fue usado frecuentemente, porque la especificacin de requerimientos para sistemas
complejos tiende a ser relativamente dificultoso de cursar.
A diferencia del modelo evolutivo donde los requerimientos mejor entendidos estn incorporados,
un prototipo generalmente se construye con los requerimientos entendidos ms pobremente.
Veamos su grfica:
Modelo Entrega por etapas

Es utilizado cuando la arquitectura es conocida.
Las ventajas son:
Permite correcciones en el transcurso del proyecto
Permite colocar en produccin las funcionalidades de mayor peso
Obtiene un producto en forma rpida
Las desventajas son:
Se debe trabajar con una planificacin cuidadosa
Permite independizar la administracin del proyecto de la parte tcnica, brindndole al usuario las
funcionalidades ms significativas. Se debe tener mucho cuidado porque para implementar una
fase puede requerir de la finalizacin de otra.

- 18 -
Veamos su grfica:
1.2.4. La naturaleza iterativa de los desarrollos.

Modelo Iterativo
Este modelo tiene como objetivo obtener un protocolo de desarrollo comn para cualquier tipo de
aplicacin de software, minimizando los procesos que tardan mucho tiempo, para entregar
avances o compilados por mdulos acompaados de su documentacin facilitando la
transferencia de conocimientos entre los integrantes del proyecto y del cliente.
Se asemeja al modelo de desarrollo por prototipos, la diferencia es que en el modelo iterativo los
prototipos son entregables y tienen versin.
Veamos su grfica:

- 19 -
Modelo de espiral
Cada proyecto es organizado y explotado en miniproyectos, es conveniente para modelos del ciclo
meta-vida, o sea que transcurren en el tiempo.
Es un modelo incremental con versiones, en cada una se respetan las etapas, se documenta y va
incluyendo a los productos anteriores.
Normalmente es utilizado en:
Sistemas de gran envergadura
Proyectos con un numeroso grupo de integrantes.
Problemas de Performance
Existencia de requerimientos pobres, poco entendibles
Arquitectura pobremente detallada
Una vez entendido el problema, continua como un proyecto en cascada
Algunas de las ventajas son:
Altos costos significan pocos riesgos
Para desarrollos rpidos
Provee ms controles que los sistemas tradicionales
Se pueden mostrar avances del proyecto
Netamente confiable
Las desventajas que se han manifestado son:
La administracin de los riesgos
Ante un proyecto complejo, requiere una administracin rigurosa (concientizada). Se deben
definir hitos de control de pase de una etapa a otra
Difcil de ser construidos con tiempos predeterminados

- 20 -
Veamos su grfica:
Modelo Iterativo e incremental

Se toman las caractersticas de ambos modelos, del iterativo y del incremental para lograr un
modelo con mejores aplicaciones.
Las ventajas, si bien son muchas y variadas, dependen del contexto en que se implemente el
proceso. Algunas de ellas son:
Se divide en fases, workflows centrales e iteraciones.
Resolucin de problemas de alto riesgo en menores tiempos del proyecto.
Visin de avance en el desarrollo desde las primeras etapas del desarrollo.
Obtencin del feedback del usuario lo antes posible, lo que permite orientar el desarrollo al
cumplimiento de sus necesidades y realizar las adaptaciones identificadas y necesarias
para cumplir con los objetivos planteados.
Menor porcentaje de fallo del proyecto, mayor productividad del equipo y menor cantidad
de defectos.
La complejidad del proyecto se maneja por partes.
El aprendizaje y experiencia del equipo se da iteracin tras iteracin, mejora
exponencialmente el trabajo, aumenta la productividad y permite optimizar el proceso a
corto plazo.
El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y mejorando
las planificaciones, logrando menores desvos en la duracin total del proyecto.
Adoptar este modelo no presenta grandes inversiones.
Si bien no se han detectado desventajas en el tiempo que lleva implementndose, es importante
tener en cuenta algunos aspectos:
Su uso no garantiza por si solo el xito del proyecto ni de su uso.

- 21 -
Existen costos ocultos en su implementacin, por la necesidad de la planificacin y la

necesidad de medir el impacto para no fracasar en el intento.
El modelo iterativo e incremental es utilizado por metodologas modernas y es adoptado por UML
(Lenguaje de modelado unificado). Su grfica es la siguiente (fuente: Book Racional Modeler)
El grfico del modelo iterativo e incremental presenta una tabla de dos entradas, las columnas
representan las Fases y las filas representan los Flujos de trabajo.
Las fases son cuatro: Inicio, Elaboracin, Construccin y Transicin.
Los flujos de trabajo representan las actividades y son 7: Requerimientos, Anlisis y Diseo,
Implementacin, Prueba, Administracin de configuracin, Administracin del proyecto y Entorno.
Las tres ltimas etapas se toman como acompaamiento de todo el proceso de desarrollo.
1.2.5. Ventajas y desventajas de c/u de los ciclos de vida

Hemos planteado hasta ahora cada modelo de ciclo de vida del proceso de desarrollo de software
y las ventajas y desventajas de sus usos.
Existen dos temas que son generales a todos los modelos, el costo de tiempo por etapas y los
riesgos.
Costo relativo a las fases
Si bien cada modelo tiene su organizacin y tiempos por fases, hay clculos promedios que se
pueden tener en cuenta para los procesos.
Veamos su representacin grfica:

- 22 -
Integracin
Test de (8%)
Mod.(7%)
C od. De
Mdulos
(5%)
Mantenimiento
(67%)
Diseo (6%)
Especificacin (5%)
Requerimientos
(2%)
Gestin de Riesgos
Tal vez la tarea principal del administrador es minimizar el riesgo
El riesgo inherente en un activad es una medida de la incertidumbre de la salida de esa actividad.
Las actividades de alto riesgo causan excesos en los costos y la planificacin.
El riesgo est relacionado con la calidad y cantidad de informacin disponible.
Mientras menos informacin el riesgo es mayor.
Problemas de riesgos en los modelos
Cascada
Alto riesgo en sistemas nuevos debido a problemas de especificacin y diseo.
Bajo riesgo para desarrollos bien conocidos y utilizando tecnologa familiar.
Evolutivos
Bajo riesgo para nuevas aplicaciones debido a que la especificacin y la programacin
estn muy relacionados
Alto riesgo debido a la carencia de visibilidad para el proceso.
Transformacional
Alto riesgo debido a la necesidad de tecnologa avanzada y habilidades en el personal
Vista integral de los modelos
Trataremos entonces en conjunto los modelos integrando las caractersticas de cada uno para
lograr una visin general y particular de ellos, que ayude a la toma de decisiones a la hora de
tener que elegir uno a implementar en un proyecto.
Ciclo de vida
Trabaja con requerimientos

pobremente entendidos
Trabaja con arquitectura
pobremente entendida
Produce un sistema
altamente confiable
Cascada
Puro
Codificacin y
Arreglo
Espiral
Cascada
Modificado
Prototipacin
Evolutiva
Entrega por
Etapas
Diseo por
Fases
Pobre
Pobre
Excelente
Justo a
excelente
Excelente
Pobre
Pobre a
justo
Pobre
Pobre
Excelente
Justo a
excelente
Pobre a Justo
Pobre
Pobre
Excelente
Pobre
Excelente
Excelente
Justo
Excelente
Justo

- 23 -
Produce sistema con sobre Excelente

crecimiento
Pobre a justo
Excelente
Excelente
Excelente
Excelente
Justo a
excelente
Administracin de riesgos
Pobre
Pobre
Excelente
Justo
Justo
Justo
Justo a
excelente
Justo
Pobre
Justo
Justo
Pobre
Justo
Excelente
Pobre
Excelente
Pobre a
excelente
Justo
Excelente
Justo
Justo
Justo
Justo
Excelente
Pobre
Justo
Pobre a
justo
Pobre
Justo
Excelente
Justo
Excelente
Justo
Justo
Justo
Pobre
Excelente
Justo a
excelente
Justo
Excelente
Excelente
Justo
Excelente
Pobre
Pobre a
Justo
Pobre
Justo
Pobre
Puede ajustarse a un
calendario predefinido
Tiene bajo perfil
Permite correcciones de
medio curso
Provee visibilidad en el
progreso (al cliente)
Provee visibilidad en el
progreso (al administrador)
Requiere poca
administracin o
sofisticacin de desarrollo
Pobre
Resumen:
Los temas tratados en este mdulo tienen que ver directamente con la Ingeniera de software y su
relacin con la Ingeniera de sistemas y la Ciencia de la computacin.
Dentro de los temas de la Ingeniera de software identificamos los conceptos de software,
producto, proceso de desarrollo de software, su ciclo de vida y los distintos modelos de desarrollo
de software y su ciclo de vida.
Tenga en cuenta los puntos clave que remarcamos a continuacin (Sommerville, Ian, captulo 1 y
3):
La Ingeniera en Software es una Ingeniera que abarca todos los aspectos de la
produccin de software.
Los productos de Software consisten en el desarrollo de programas y toda la
documentacin asociada a ellos. Los atributos esenciales son la mantenibilidad,
confiabilidad, eficiencia y usabilidad.
El proceso de software consiste en actividades las cuales involucran el desarrollo de
productos de software. Las actividades bsicas son especificacin, desarrollo, validacin y
evolucin.
Los mtodos son formas organizadas de producir software. Ellos incluyen sugerencias
para el cumplimento del mtodos, la notacin a ser usada, las reglas de validacin de
modelos y guas de diseo.
Las herramientas CASE son sistemas de software los cuales son diseados para auxiliar
en actividades de rutina en el proceso de desarrollo de software. Tales como edicin de
diagramas, verificar la consistencia de diagramas y mantener un registro de los testeos
efectuados.
Los ingenieros en Software tienen responsabilidades para con su profesin y para con la
sociedad. No estn simplemente involucrados en aspectos tcnicos
En cuanto a los sistemas y las Ingenieras puede destacar los siguientes puntos clave
(Sommerville, Ian, captulo 2):

- 24 -
Los sistemas socio-tcnicos incluyen hardware, software, personas y procesos, se

encuentran dentro de las organizaciones y ayudan a cumplir un objetivo.
Las propiedades emergentes de un sistema son las caractersticas que actan como un
todo no por partes o componentes del sistema. Incluyen propiedades como el rendimiento,
fiabilidad, usabilidad, seguridad y proteccin. El xito o fracaso de un sistema socio-tcnico
dependen de las propiedades en la mayora de los casos.
Factores humanos y organizacionales influyen en el funcionamiento de los sistemas sociotcnicos.
Dentro de una organizacin pueden existir ms de un tipo de sistemas, los heredados, los
propios y los adquiridos. Es posible que se planteen conflictos entre el proceso de
adquisicin, el proceso de desarrollo y los procesos operativos internos.
Los sistemas heredados son sistemas socio-tcnicos.
En cuanto al proceso de software puede destacar lo siguiente:
Proceso de Software
o Un conjunto coherente de actividades para especificar, disear, implementar y
testear un sistema de software.
Modelos de Ciclo de Vida
o Cascada demasiado inflexible
Orientado a documentos
o Modelos evolutivos y prototipos
Dependen de las decisiones tomadas antes del entendimiento del problema
o Una buena solucin es integrar protipado rpido y cascada
Puntos clave a tener en cuenta, Sommerville, Ian, (captulo 4 temas 4.1 y 4.2):
Los procesos de software incluyen las actividades relacionadas con la produccin de un

sistema de software. Los modelos del proceso del software son representaciones
abstractas de estos procesos.
Todos los procesos del software incluyen las etapas de especificacin, diseo,
implementacin, validacin y evolucin del software.
Los modelos genricos del proceso describen la organizacin de los procesos del
software, como son el modelo en cascada, los evolutivos y la Ingeniera basada en
componentes.
Los modelos de iteracin presentan el proceso de software como un ciclo de actividades.
El modelo en espiral, es uno de los ms utilizados.
El modelo iterativo e incremental incluye las mejores prcticas del modelo iterativo y del
modelo incremental.

- 25 -
Scientific American, noviembre, 1994

LA CRISIS CRNICA DE LA PROGRAMACIN
W. Wayt Gibbs1
A pesar de 50 aos de progresos, a la industria del software
le faltan aos -quizs dcadas- para convertirse en la
disciplina de ingeniera madura que la sociedad de la
informacin requiere.
El nuevo aeropuerto internacional de Denver, en los EE.UU., iba a ser la maravilla
de la ingeniera moderna, el orgullo de la regin. Su enorme tamao, como diez veces el
londinense Heathrow, permite el aterrizaje simultneo de tres jets, incluso con mal tiempo.
Por colosales que sean sus dimensiones, aun es mas impresionante el sistema subterrneo
de traslado de equipajes con que cuenta. 4.000 telecarros independientes, lanzados a toda
velocidad por 33 kilmetros de va frrea, transportan y distribuyen los equipajes entre lo
mostradores, las puerta de acceso y las reas para retirar de 20 lneas area distintas. Un
sistema nervioso central 100 computadores conectados entre s y a 5.000 ojos elctricos, a
400 receptores de radio y a 56 lectores de cdigo de barras se encarga de orquestar la
llegada segura y a tiempo de cada maleta y de cada bolsa e esqu2.
Eso, al menos, era lo previsto. Este Gulliver ha estado nueve meses prisionero de los
liliputienses, lase, de los errores del software que controla el sistema automtico de
equipajes. El aeropuerto deba despegar el da de Halloween3 del ao pasado, pero su
gran inauguracin hubo de posponerse hasta diciembre, para permitir que los tcnicos de la
empresa BAE Automated Systems exorcizasen de espritus malignos su sistema, que haba
costado 193 millones de dlares. De diciembre hubo que pasar a marzo. Marzo trocse en
mayo. En junio del presente ao, las acciones del aeropuerto se cotizaban al precio del
papel de embalar y el presupuesto de sus promotores sufra una hemorragia de tinta roja que
alcanzaba 1,1 millones de dlares diarios en intereses y gastos operativos, vindose
obligados a admitir que no podan predecir en qu momento el sistema de equipajes
adquirira la estabilidad necesaria para poder abrir el aeropuerto.
Para los desarrolladores de software ms veteranos, lo nico inusual del desastre de
Denver es su notoriedad. Hay estudios que sealan que por cada seis nuevos sistemas de
software de gran tamao que entran en servicio, otros dos quedan cancelados. Los proyectos
de desarrollo de software de tamao medio suelen consumir vez y media el tiempo previsto,
situacin que empeora en los grandes. Y alrededor de tres cuartas partes de todos los
sistemas de gran tamao son fracasos operativos, que no funcionan como se quera o no
se utilizan para nada.
El arte de la programacin ha requerido 50 aos de incesante perfeccionamiento
para alcanzar este estadio. Al cumplir los 25, las dificultades que planteaba la construccin
de software grande cobraron tanta importancia que en el otoo4 de 1968 el Comit de
Ciencias de la OTAN convoc a un grupo de unas 50 personas, formado por programadores
de primera categora, cientficos de la computacin y empresarios, para que trazasen un
rumbo que permitiera salir de lo que se ha dado en denominar la crisis del software.
Aunque no fueron capaces de elaborar una ruta que guiase la nave hacia tierra firme, s
acuaron un nombre para esa lejana meta: ingeniera de software, ahora definida
formalmente como la aplicacin de mtodos sistemticos, disciplinados y cuantificables al
desarrollo, funcionamiento y mantenimiento del software.
Otro cuarto de siglo despus, la ingeniera de software sigue siendo una aspiracin.
La mayor parte del cdigo de computadoras se confecciona a mano por artesanos que
utilizan lenguajes de programacin bastante burdos tcnicas que ni se miden ni pueden
repetirse con consistencia. Para el profesor universitario Brad J. Cox Es algo as como la
fabricacin de arcabuces antes de Eli Whitney5. Dice Brad J. Cox, un profesor de la
Universidad George Mason, Antes de la revolucin industrial no existan mtodos
especializados de manufactura de productos, lo que entraaba un mximo de destreza
artesanal y un mnimo de intercambiabilidad. Si queremos vencer esta crisis del software ha
de acabarse con el secretismo y con los mtodos preindustriales, en los que cada
programador ha de construirlo todo desde cero.
Pero hay esperanzas. La intuicin va cediendo paso lentamente al anlisis y los
programadores comienzan a utilizar medidas cuantitativas de la calidad del software que
producen para mejorar la forma en que los producen. Los fundamentos matemticos de la
programacin se estn consolidando merced a la investigacin de mtodos para la
expresin algebraica de los diseos de programas, lo que ayuda a evitar la comisin de
errores graves. Los acadmicos de ciencias de la computacin empiezan a tratar de remediar
su fracaso en la generacin de profesionales de software competentes. Y, lo que quizs es
ms importante, muchas personas de la industria centran su atencin hacia la invencin de
las tecnolgicas y estructuras mercantiles necesarias para soportar las partes del software
que sean intercambiables y reutilizables.
Lamentablemente, la industria no aplica uniformemente lo que es reconocido como
mejor prctica, lamenta Larry E. Druffel, director de Software Engineering Institute de la
Universidad Carnegie Mellon. De hecho, una innovacin que genera la investigacin
requiere 18 aos en abrirse paso hasta el repertorio de tcnicas standard de programacin.
es posible que la combinacin de esfuerzos de la universidad, las empresas y la
administracin pblica logren elevar el desarrollo de software hasta el nivel de una
disciplina ingenieril propia de la era industrial en este decenio. Si no se consigue, la alocada
carrera de la sociedad hacia la era de la informacin se tornar, en el mejor de los casos,
espasmdica e impredecible.
Arenas movedizas
A lo largo de los prximos aos presenciaremos cambios enormes [en el uso de los
computadores] que en comparacin harn que la revolucin inicial causada por el
ordenador personal resulte insignificante, concluan el pasado mes de abril veintids
especialistas en el desarrollo de software, procedentes de la universidad, de las empresas y
de los laboratorios de investigacin. Estos expertos se reunieron en Hedson Parkn un lugar
cerca de Londres para conmemorar la conferencia de la OTAN y para considerar las
direcciones del software en el futuro. En 1968 sabamos lo que queramos construir, pero
no podamos hacerlo, rememora Cliff Jones, profesor de la universidad de Manchester.
Hoy pisamos arenas movedizas.
Las bases en que se asientan las prcticas tradicionales de programacin son
erosionadas rpidamente conforme los ingenieros de hardware van lanzando equipos cada
vez ms rpidos, ms pequeos y ms baratos. Muchos de los supuestos fundamentales de
los programadores (por ejemplo, su aceptacin de que sus productos siempre tendrn
defectos) deben de cambiar en consecuencia. Como indica la profesora Mary S. Shaw, de
Carnegie Mellon, cuando los interruptores de la luz incorporen computadoras es preciso
que el software funcione la primera vez, porque no habr posibilidades de revisarla.
La cantidad de cdigo instalada en la mayora de los productos de consumo se est
duplicando cada dos aos, segn Remi H. Bourgonjon, director de tecnologa de software
del Philips Research Laboratory, en Eindhoven. Un televisor actual puede incorporar hasta
500 Kb de software y una afeitadora elctrica, 2 Kb. Las transmisiones de los nuevos
automviles de General Motors ejecutan de 30.000 lneas de cdigo de computadora.
Lograr que el software funcione bien la primera vez les resulta difcil incluso a
quienes procurar conseguirlo. El Departamento de Defensa de los Estados Unidos (DoD)
aplica normas de ensayo muy estrictas- y costosas- para garantizar la confiabilidad de
software del que depende una misin. Esos standards fueron las utilizados en la
certificacin de Clementine, un satlite que el DoD junto con la NASA, queran situar en
rbita lunar la primavera pasada. Un aspecto principal de la misin consista en ensayar
software de seleccin de blanco, aptos para ser utilizados algn da en un sistema defensivo
antimisiles, instalado en el espacio. Pero cuando se hizo girar al satlite para que situara a la
Luna en su punto de mira, un bug del programa provoc que, en lugar de lo solicitado, la
nave mantuviera ininterrumpidamente encendidos sus motores de maniobra durante 11
minutos. El satlite, agotado su combustible y girando alocadamente sobre s, mismo no
pudo efectuar el encuentro previsto con el asteroide Geographos.
La deteccin de errores en sistemas de tiempo real, como el Clementine, resulta de
una dificultad diablica porque, lo mismo que pasa con ese ruidito sospechoso del motor de
nuestro coche, slo suelen manifestarse en circunstancias muy determinadas [vase Los
riesgos de la programacin, por Bev Littlewood y Lorenzo Strigini; INVESTIGACIN Y
CIENCIA, enero de 1993]. No est claro que los mtodos utilizados actualmente para la
produccin de software en los que la seguridad tiene importancia decisiva -caso de los
reactores nucleares o de los automviles- evolucionen y se amplen en la medida necesaria
para satisfacer nuestras expectativas futuras, adverta Gilles Kahn, director cientfico del
laboratorio de investigacin INRIA de Francia, en la reunin de Hedson Park. Me parece,
por el contrario, que en el caso de estos sistemas estamos en un punto de quiebre.
La software sufre tambin las presiones de la inexorablemente creciente demanda de
sistemas distribuidos, esto es, programas que operen conjuntamente en muchos
computadores integrados en una red. Las empresas estn volcando recursos a manos llenas
en sistemas de informacin distribuidos, que confan en poder utilizar como armas
estratgicas. La inconstancia del desarrollo del software pueden hacer de tales proyectos
una ruleta rusa.
Son muchas las empresas seducidas por metas de apariencia sencilla. Algunas tratan
de reencarnar en forma distribuida software obsoleto basado en mainframe. Otros desean
conectar entre s los sistemas de que ya disponen, o conectarlos a sistemas nuevos mediante
los que se pueda compartir datos y disponer de una interfaz ms amistosa para el usuario.
En la jerga tcnica, este tipo de interconexin de programas suele denominarse integracin
de sistemas. Pero Brian Randell un cientfico de la computacin de la Universidad de
Newcastle en Tyne, sugiere que hay una palabra ms adecuada que integracin, del slang
de la RAF: nominalmente to graunch, que significa hacer que algo encaje por aplicacin
de una fuerza excesiva.
El asunto es riesgoso, pues aunque el software pueda parecer cosa maleable, la
mayora de los programas son en realidad complicadas redes de estructuras lgicas muy
frgiles, a travs de los cuales solamente pueden pasar datos de naturaleza especfica. Al
igual que los arcabuces hachos a mano, diversos programas pueden realizar funciones
semejantes y ser, sin embargo, de diseo exclusivo. De aqu que sean difciles de modificar
y de reparar, y de aqu tambin que las tentativas de embutirlos unos en otros acaben a
menudo de mala manera.
Por poner un ejemplo. El Departamento de Vehculos Automotor de California
decidi en 1987 hacerles la vida ms fcil a los conductores, para lo que resolvi fundir en
uno los sistemas de permiso de conduccin para el personal y de circulacin de los
vehculos. Tarea sencilla, en apariencia. Los responsables confiaban en que en 1993
tendran en servicio quioscos donde se efectuasen cmodamente las renovaciones en una
sola parada. En vez de ello, lo que vieron era cmo se multiplicaba por 6,5 el costo previsto
y se pospona hasta 1998 la fecha de inauguracin. El pasado diciembre cerraron el grifo y
perdieron la inversin efectuada en los siete aos: 44,3 millones de dlares.
Hay veces que nada es tan catastrfico como el xito. En el decenio de 1970, la
compaa American Airlines construy el SABRE, un sistema de reserva de pasajes de
autentico virtuosismo, que costo 2000 millones de dlares y lleg a formar parte de la
infraestructura de la industria de viajes. SABRE constituy el ejemplo ms luminoso de
sistema estratgico de informacin, porque hizo que American Airlines se convirtiera en la
mayor lnea area del mundo, recuerda Bill Curtis, consultor del Software Engineering
Institute.
Decidida a valerse del software con igual efectividad en este decenio, American
Airlines trat de acoplar sus sistema de reserva de pasajes con los de reserva de hotel y de
alquiler de automviles de Marriott, Hilton y Budget. El proyecto colaps en 1992, en
medio de un montn de pleitos. Fue un fracaso aplastante, dice Curtis. American
Airlines tuvo que pasar a prdidas 165 millones de dlares por esta causa.
Mal puede decirse que la compaa area se encuentre sola en sus sufrimientos. El
Consulting Gropu de IBM hizo pblicos en junio los resultados de un estudio efectuado en
24 compaas lderes que haban desarrollado grandes sistemas distribuidos. Las cifras eras
inquietantes: el 55 por ciento de los proyectos cost ms de lo esperado, el 68 por ciento
incumpli los plazos previstos y el 88 por ciento tuvo que redisearse a fondo.
El informe no mencionaba, empero, un dato estadstico de la mayor importancia: la
confiabilidad del funcionamiento de los programas terminados. Los sistemas informticos
suelen estrellarse o quedarse colgados debido a su incapacidad de enfrentar lo inesperado.
Las redes amplan el problema, Los sistemas distribudos pueden consistir en un conjunto
muy grande de puntos individuales interconectados, en lo que cabe que se produzcan fallas
y muchos de los cuales no estn identificados de antemano, explica Randell. La
complejidad y la fragilidad de estos sistemas plantean un problema de primera magnitud.
El desafo de la complejidad no slo es grande sino que va en aumento. Lo que
recibe uno por cada unidad monetaria invertida en ordenadores se duplica cada 18 meses,
ms o menos. Lo que origina, entre otras cosas, un crecimiento de un orden de magnitud
en el tamao de los sistemas por decenio y, en ciertos sectores, cada cinco aos, segn
Curtis. Para no verse superados por semejante demanda, los programadores tendrn que
cambiar la forma en que trabajan. No se pueden construir rascacielos con carpinteros,
bromea.
Auxilio! !Socorro!
Cuando un sistema se vuelve tan complejo que ningn gerente lo comprende
individualmente por completo, los procesos tradicionales de desarrollo se vienen abajo. La
Administracin Federal de Aviacin estadounidense (FAA, Federal Aviation
Administration) ha tenido que afrontar este problema a lo largo de su intento- que ya dura
diez aos- de sustituir el sistema de control de trfico areo del pas, cada vez ms
anticuado.
En su sustituto, denominado Sistema Avanzado de Automacin (AAS, Advanced
Automation Systems), se combinan todos los problemas de la computacin de nuestro
decenio. El programa, cuyo tamao supera el milln de lneas, est distribuido en cientos de
ordenadores y empotrado en aparatos nuevos y muy complejos. Todo el sistema debe
responder instantneamente a acontecimientos impredecibles durante las veinticuatro horas
del da. Incluso un ligero bug puede constituir una amenaza para la seguridad pblica.
Para llevar a la prctica sus sueo tecnolgico, la FAA seleccion a Federal Systems
Company, de IBM, entidad de muy buena reputacin y lder en el desarrollo de software,
posteriormente adquirida por Loral. Los responsables de la FAA esperaban (aunque no lo
exigieron) que IBM aplicase las ltimas tcnicas disponibles para estimar el costo y la
duracin del proyecto, al igual que dieron por supuesto que revisara cuidadosamente
requerimientos y el diseo del sistema, para detectar los errores cuanto antes, cuando es
posible corregirlos en horas y no en das. Y aceptaron - conservadoramente - que tendran
que pagar unos 500 dlares por lnea de programa producida, unas cinco veces ms que el
costo medio normal para procesos de desarrollo bien gestionados.
Segn un informe sobre el proyecto AAS, publicado en mayo de este ao por el

Centro de Anlisis Naval estadounidense, las estimaciones de costos y el seguimiento del
proceso de desarrollo hechos por IBM se efectuaron con datos inadecuados y se
realizaron de forma inconsistente, y fueron rutinariamente ignoradas por los gerentes del
proyecto. El resultado es que la FAA ha estado pagando la programacin para el sistema
AAS a razn de 700 a 900 dlares por lnea cdigo. Una de las razones de precio tan
exorbitante es que, por trmino medio, cada una de dichas lneas ha de volver a
escribirse, segn se lamentaba un documento de la FAA.
Alarmado por la estratosfrica elevacin de costos y porque los ensayos efectuados
sobre el sistema semiterminado mostraban que no era confiable, David R. Hinson,
administrador de la FAA, decidi en junio pasado cancelar dos de las cuatro grandes partes
del proyecto y reducir la escala de una tercera. Los 144 millones de dlares dilapidados en
estos programas fallidos son slo una gota de agua frente a los 1400 millones invertidos en
la pieza cuarta y central: el nuevo software de las estaciones de trabajo de los controladores
de trfico areo.
Tambin este proyecto va camino de irse a pique. El programa lleva cinco aos de
retraso, ha engullido ms de 1000 millones de dlares sobre lo presupuestado y est lleno
de bugs. Expertos informticos de la Carnegie Mellon y del Instituto de Tecnologa de
Massachusetts (MIT, Massachusetts Institute of Technology) estn tratando de depurarlo y
de averiguar si todava es posible salvarlo o si debe cancelarse sin ms.
Los desastres sern una parte crecientemente comn y disruptiva del desarrollo de
software, a menos que la programacin adopte muchas de las caractersticas de las ramas de
la ingeniera, que estn firmemente entroncadas en la ciencia y en las matemticas (ver el
cuadro Progreso hacia el profesionalismo). Por fortuna, esa tendencia ha comenzado ya.
A lo largo de la ltima dcada, empresas lderes de la industria han comprendido bastante
sobre cmo medir cuantitativa y consistentemente, el caos de sus procesos de desarrollo, la
densidad de errores de sus productos y el estancamiento de la productividad de sus
programadores. Los investigadores estn dando el paso siguiente: encontrar soluciones
prcticas y reproducibles para estos problemas.
Los frutos del proceso
As, por ejemplo, el SEI, un vivero de ideas sobre el tema, financiado por los
militares, revel en 1991 su modelo de capacidad y madurez (CMM, Capability Maturity
Model). El CMM proporciona una visin de la excelencia de la ingeniera de software y de
su gestin, dice David Zubrov, quien dirige un proyecto sobre mtodos empricos en el
Instituto. Al menos el CMM, ha persuadido a muchos programadores de concentrarse en la
medicin del proceso por el que producen software, un requisito previo en cualquier
disciplina de ingeniera industrial.
Sirvindose de entrevistas, de cuestionarios y del CMM como sistema de
comparacin, puede calificarse la capacidad de un equipo de programacin para crear
software predecible y que solucionen las necesidades de sus clientes. El CMM aplica una
escala de cinco niveles, que van desde el caos en el nivel 1, hasta el parangn de una buena
gestin en el nivel 5. Las organizaciones evaluadas hasta ahora son 261.
La aplastante mayora- alrededor del 75 por ciento- siguen todava empantanadas
en el nivel 1, nos cuenta Curtis. Carecen de procesos formales, no miden lo que hacen y
no tienen forma de saber si van por el mal camino o si han descarrilado del todo. (El
Centro de Anlisis Naval concluy que el nivel del proyecto AAS en Federal Systems, de
IBM, como 1 bajo.) El 24 por ciento restante de los proyectos se encuentra entre los
niveles 2 y 3.
Tan slo dos grupos de elite han merecido la mxima puntuacin CMM, el nivel 5.
El equipo de programacin que Motorola tiene en Bangalore, India, ostenta uno de esos
ttulos. El otro ha sido el proyecto de software de a bordo para el transbordador espacial,
realizado por Loral (que antes perteneca a IBM). Tan perfectamente ha aprendido el equipo
de Loral a controlar los errores, que es capaz de pronosticar correctamente cuntos van a
descubrirse en cada nueva versin del software. Se trata de una a hazaa notable, habida
cuenta de que la mayora de los programadores ni siquiera llevan la cuenta de los bugs que
descubren, de acuerdo a Capers Jones, Chairman de Software Productivity Research. Y
entre quienes lo hacen, dice, son pocos quienes detectan ms de la tercera parte de los
existentes.
El director del proyecto de software para el transbordador espacial, Tom Peterson,
atribuye su xito a una cultura que se esfuerza por enmendar no slo los errores del
programa sino tambin las fallas del proceso de comprobacin, que permitieron que los
primeros pasaran desapercibidos. No obstante, siempre se cuela alguno. El primer
lanzamiento del transbordador espacial en 1981 tuvo que interrumpirse y posponerse dos
das debido a que una seal errnea impidi que los cinco ordenadores de a bordo quedaran
debidamente sincronizados. Otro fallo, esta vez en el programa de rendezvous del
transbordador, puso en peligro la misin de rescate del satlite Intelsat-6, en 1992.
Aunque el modelo CMM no es la panacea, la promocin que de l ha realizado el
SEI ha persuadido a algunas de las principales empresas de software de que, a largo plazo,
el control cuantitativo de la calidad puede resultar rentable. As, por ejemplo, la divisin de
equipos de Raytheon elabor en 1988 un iniciativa de ingeniera de software tras haber
fallado en una evaluacin del CMM. Empezaron a invertir un milln de dlares anuales
para refinar las guas de inspeccin y de verificacin rigurosa y para formar a sus 400
programadores para que las siguieran.
En el plazo de tres aos ya haban escalado dos niveles. El mes de junio pasado casi
todos los proyectos, entre ellos complejos sistema de radar y de control de trfico areo, se
estaban concluyendo antes de plazo y a costo inferior del presupuestado. La productividad
se ha duplicado con holgura. Los anlisis de costos de retrabajo han indicado ahorros de
7,80 dlares por cada dlar invertido en la iniciativa. Impresionada por semejantes xitos, la
Fuerza Area de los Estados Unidos ha establecido que quienes desarrollen programas para
ella han de alcanzar el nivel 3 de CMM en 1998. Se tienen noticias de que la NASA piensa
actuar de forma parecida.
Re- creaciones matemticas
En tanto los humanos creen programas, siempre se producirn errores; hasta los
diseos ms cuidados pueden desviarse. No obstante, los bugs detectados en los estadios
iniciales raramente amenazan los plazos y presupuestos de un programa. Los que provocan
efectos devastadores son casi siempre deslices cometidos en el diseo inicial que llegan
intactos hasta el producto definitivo.
Los fabricantes de programas para mercados masivos, que no han de complacer a un
cliente individual, pueden adoptar un enfoque a posteriori y de fuerza bruta para eliminar
los defectos: hacen circular el producto deficiente con el nombre de versin beta y dejan
que multitudes de usuarios se encarguen de descubrir las fallas. Segn Charles Simonyi, un
Arquitecto Jefe de Microsoft, la nueva versin del sistema operativo Windows ser objeto
de tests beta por veinte mil voluntarios. Tal sistema es muy eficaz, pero tambin oneroso,
ineficiente y poco prctico, dado que los productos masivos para computadores personales
slo suponen el diez por ciento del mercado de software en los Estados Unidos, que mueve
92.800 millones de dlares al ao.
En consecuencia, los investigadores formulan diversas para atacar los errores
tempranamente, e incluso para impedir que ocurran. Una ideas consiste en tener en cuenta
que el problema que se supone resuelve el sistema, siempre cambia a medida que se lo va
construyendo. Las planificaciones del aeropuerto de Denver cargaron sobre las espaldas de
BAE modificaciones por valor de 20 millones de dlares en el diseo del sistema de
equipajes mucho despus de haberse iniciado su construccin. IBM sufri de igual manera
las indecisiones de los directivos de la FAA. Ambas empresas haban dado por supuesto,
ingenuamente, que una vez aprobado su diseo, se las dejara en paz para construirlo.
Algunos desarrolladores estn abandonando esa ilusin y repensando al software
como algo que, ms que construirse, se cultiva. En un primer paso, se hilvana rpidamente
un prototipo merced a componentes estndar de interfases grficas. Lo mismo que las
maquetas utilizadas en arquitectura, el prototipo de un sistema puede servir para aclarar
malentendidos entre el programador y su cliente antes de empezar a establecer los cimientos
lgicos.
Pero los prototipos sirven de poco en la deteccin de inconsistencias lgicas del
diseo, pues slo remedan el aspecto externo de su comportamiento. La gran mayora en
software de gran envergadura son errores de omisin, nota Laszlo A. Belady, director de
Mitsubishi Electric Research Laboratory. Y una vez escrito el programa los modelos en
nada facilitan la deteccin de bugs.
Cuando la exigencia de correccin del programa es absoluta, dice Martyn Thomas,
gerente general de Paxis, una compaa britnica de software, los ingenieros recurren a
anlisis matemticos para predecir cul ser el comportamiento de sus creaciones en el

mundo real. Por desdicha, las matemticas tradicionales, aptas para la descripcin de
sistemas fsicos, no son aplicables al universo sinttico binario de un programa de
computador; es la matemtica discreta, una especialidad mucho menos madura, la que
gobierna este campo. Aun as, valindose del instrumental, no muy amplio todava, de la
teora de conjuntos y del clculo de predicados, los cientficos de la computacin se las han
arreglado para traducir especificaciones y programas al lenguaje matemtico, donde pueden
analizarse con los instrumentos tericos denominados mtodos formales.
Praxis ha usado recientemente mtodos formales en un proyecto de control de
trfico areo para el rgano administrativo responsable de la aviacin civil en Gran Bretaa.
Aunque su programa era mucho ms pequeo que el de la FAA, ambos afrontaban un
problema similar: la necesidad de mantener sincronizados sistemas redundantes, de manera
que si uno de ellos fallase, el otro pudiera entrar en servicio instantneamente. Lo difcil
consista en garantizar que los mensajes se entregaran en el orden debido a las dos redes
gemelas, segn Anthony Hall, un consultor principal de Praxis. Tratamos de conseguir
demostraciones matemticas de nuestro enfoque, que fallaron, porque el diseo era errneo.
La deteccin de errores en ese estadio inicial tiene enormes ventajas. El sistema qued
concluido a tiempo y entr en servicio en octubre de 1993.
Praxis slo utiliz notaciones formales solamente en las secciones ms crticas del
software, pero otras firmas de software han aplicado el rigor matemtico a la totalidad del
desarrollo de un sistema. En Pars, GEC Alsthom est utilizando un mtodo formal llamado
B, al tiempo que invierte 350 millones de dlares en perfeccionar los programas de
control de velocidad y de guiado de los 6000 trenes elctricos del sistema nacional de
ferrocarriles francs, la SNCF. El sistema puede ahorrar miles de millones de dlares si
permite aumentar la velocidad de los trenes y su frecuencia, el sistema puede ahorrar miles
de millones de dlares evitando los nuevos tendidos de lneas necesarios de otro modo.
La seguridad es una preocupacin obvia. Por eso lo que los desarrolladores de GEC
escribieron el diseo completo y el programa final en notacin formal y luego usaron
matemticas para demostrar la consistencia de ambos. Los test funcionales siguen siendo
necesarios por dos razones, indica Fernando Meja, director de la seccin de desarrollo
formal de GEC. En primer lugar, a veces los programadores cometen errores en las
demostraciones. En segundo lugar, los mtodos formales solamente pueden garantizar que
el software cumple con su especificacin, no que sean capaces de manejarse con las
sorpresas que depara el mundo real.
No son stos los nicos problemas de los mtodos formales. Ted Ralston, director
de planeamiento estratgico de Odyssey Research Associates, en Ithaca, Nueva York, hace
notar que la lectura de pgina tras pgina de frmulas algebraicas resulta ms soporfera
todava que la revisin de cdigo de compujtadora. Odyssey es una de las empresas que
estn tratando de automatizar los mtodos formales para que les resulten menos onerosos a
los programadores. En Francia, GEC colabora con Digilog para comercializar herramientas
de programacin para el mtodo B. Siete compaas e instituciones, Aerospace entre ellas,
as como el organismo responsable de la energa atmica y el ministerio de defensa

franceses, estn probando la versin beta.
Del otro lado del Atlntico, los mtodos formales por s mismos tienen todava que
abrirse paso. Yo soy escptico que los estadounidenses sean lo suficientemente
disciplinados para aplicar mtodos formales en alguna forma generalizada, dice David A.
Fisher del National Institute of Standards and Technology (NIST). Existen excepciones, no
obstante, sobre todo en el crculo cada vez ms amplio de las empresas que experimentan
una metodologa de programacin denominada enfoque de sala limpia (clean-room
approach).
Este mtodo trata de conjugar las notaciones formales, las demostraciones de
validez y los controles estadsticos de calidad con un enfoque evolutivo del desarrollo de
software. Al igual que la tcnica de fabricacin de circuitos integrados de la que toma su
nombre, el desarrollo de sala limpia trata de aplicar consistentemente tcnicas rigurosas
de ingeniera para fabricar productos que funcionen perfectamente la primera vez. Los
programadores desarrollan el sistema de a una funcin por vez y se aseguran de certificar la
calidad de cada unidad antes de integrarla en el la arquitectura.
Software creciendo en esta forma, requiere toda una nueva metodologa de testeo.
Tradicionalmente, los desarrolladores testean un programa ejecutndolo del modo en que
ellos entienden que debe funcionar, modos que, muchas veces, apenas si guardan leve
parecido con los del mundo exterior. En un proceso de sala limpia, los programadores tratan
de asignar una probabilidad a cada camino de ejecucin -correcto e incorrecto- que los
usuarios puedan tomar. Ellos pueden derivar casos de prueba de estos datos estadsticos, de
forma que las rutas ms frecuentemente utilizadas se analicen ms profundamente. Despus
se hace funcionar el programa en cada una de estos casos de prueba y se cronometra cunto
tarda en fallar. Estos tiempos se le introducen a continuacin a un modelo matemtico, que
calcula la confiabilidad del programa, a la manera ms puramente ingenieril.
Los informes de los que adoptaron inicialmente el enfoque alientan a utilizarlo.
Ericsson Telecom, el gigante europeo de las telecomunicaciones, aplic procesos de sala
limpia en un proyecto de 70 programadores destinado a elaborar un sistema operativo para
computadores de conmutacin telefnica. Sus informes hablan de que los errores se
redujeron a uno por cada 1000 lneas de cdigo de programa, cuando el promedio de la
industria es unas veinticinco veces mayor. Y, lo que puede ser ms importante, se
comprob que la productividad del desarrollo aument un 70 por ciento y la de las pruebas
se duplic.
No hay balas de plata6
En esta profesin se ha odo hablar ya muchas veces de balas de plata
presuntamente capaces de hacer desaparecer los bugss que plagan los proyectos. desde los
aos sesenta se han anunciado docenas de innovaciones tcnicas destinadas a incrementar la
productividad; muchos de sus creadores han presentado incluso proyectos demostrativos
de la veracidad de sus pretensiones. Los partidarios del anlisis y la orientados a objetos,

uno de los comodines verbales del presente, proclaman que su mtodo constituye un
cambio de paradigma capaz de generar una mejora de productividad de 14 a 1, junto con
superior calidad y mantenimiento ms fcil, todo ello a menor costo.
No faltan motivos para el escepticismo. Curtis recuerda que En los aos 70 se
proclam que la programacin estructurada era un cambio de paradigma y otro tanto ocurri
luego con CASE [computer-assisted software engineering, ingeniera de software asistida
por ordenador], repitindose la historia con los lenguajes de tercera, cuarta y quinta
generacin. Nosotros hemos odo grandes promesas tecnolgicas, muchas de las cuales
jams se han cumplido.
Mientras tanto, la productividad en el desarrollo de software se ha rezagado con
respecto a la de disciplinas ms maduras, sobre todo con respecto a la ingeniera de
computadoras. Yo pienso del software como un objeto de culto, dice Cox. Nuestros
principales logros fueron importados desde la cultura extranjera de la ingeniera de
hardware - mquinas cada vez ms rpidas y dotadas de ms memoria. Fisher tiende a
acordar: ajustado por inflacin el valor agregado por trabajador en la industria ha sido de
US$ 40,000 por dos dcadas, asevera. Nosotros no estamos viendo ningn incremento.
Yo no pienso as, replica Richard A. DeMillo, un profesor de la Universidad de
Purdue y principal directivo del Software Engineering Research Consortium. Ha habido
mejoras, pero cada uno usa diferentes definiciones de productividad. Un estudio reciente
publicado por Capers Jones -pero basado necesariamente en datos histricos dudososestablece que los programadores de Estados Unidos de Amrica generan el doble de cdigo
que en 1970.
El hecho es que nadie sabe lo productivos que son quienes desarrollan software, y
ello por tres razones. La primera es que menos del diez por ciento de las compaas
norteamericanas mide de forma coherente y sistemtica la productividad de sus
programadores.
La segunda es que no se ha establecido an una unidad de medida standard y til en
el sector. La mayora de los estudios, incluyendo los publicados en las revistas sujetas a
referato de ciencias de la computacin, expresan la productividad en trminos de lneas de
cdigo por trabajador por mes. Pero los programas estn escritos en una gran variedad de
lenguajes y varan enormemente en la complejidad de su operacin. Comparando el nmero
de lneas escritas por un programador japons usando C con el nmero producido por un
estadounidense usando Ada, es como comparar sus salarios sin convertir de yen a dlares.
En tercer lugar, dice Fisher, usted puede caminar en una empresa tpica y encontrar
a dos personas que comparten la misma oficina, perciben el mismo salario y poseen
calificaciones equivalentes y usted puede detectar, sin embargo, diferencias en un factor
cien en el nmero de instrucciones por da que producen. Tan enormes diferencias
individuales tienden a anular los efectos, mucho menos acusados, de las mejoras
tecnolgicas o de procesos.
Tras veinticinco aos de desengaos, debido a aparentes innovaciones que

resultaron ser no reproducibles o imposibles de adoptar a mayor escala, son muchos los
investigadores que admiten que la ciencia de la computacin requiere una rama
experimental destinada a separar los resultados generales de los meramente accidentales.
Siempre se ha dado por supuesto que, si yo enseo un mtodo, ste es correcto slo porque
yo lo digo, denuncia Vctor R. Basili, un profesor en la Universidad de Maryland. Se
estn produciendo todo genero de cosas y resulta verdaderamente escalofriante lo malas que
son algunas de ellas, dice.
Mary Shaw, de Carnegie Mellon puntualiza que las ingenieras maduras han
codificado en manuales las soluciones bien probadas, de forma que incluso novicios poco
experimentados puedan manejar consistentemente los diseos rutinarios, dejando libres
para los proyectos avanzados a los profesionales de mayor talento. No existen manuales
semejantes para el software, por lo que los errores se repiten ao tras ao, en un proyecto
tras otro.
DeMillo sugiere que el gobierno debera tomar un papel ms activo. La National
Science Foundation debera estar interesada en financiar investigacin orientada a verificar
experimentalmente resultados que ha sido establecidos por otra gente, dice. Actualmente
si no es investigacin hecha por primera vez y de gran creatividad, los administradores de
los programas de la NSF tienden a discontinuar el trabajo. DeMillo conoce de qu habla.
Desde 1989 a 1991 dirigi la divisin de investigacin en computadoras y computacin de
la NSF.
Adems, si la ingeniera de software es una ciencia experimental, esto significa que
necesita ciencia de laboratorio. Dnde estn los laboratorios? pregunta Basili. Puesto que
el esfuerzo de llevar las tecnologas prometedoras a la escala de la proporciones industriales
a menudo falla, los laboratorios pequeos son de utilidad limitada. Necesitamos tener
instalaciones en las que obtener datos y tratar de sacar las cosas, dice DeMillo. La nica
forma de hacer esto es tener una organizacin real de desarrollo de software como socio.
Ha habido slo unos pocas de esas asociaciones. Quizs la ms exitosa es el
Software Engineering Laboratory, un consorcio del Goddard Space Flight Center de la
NASA, Computer Sciences Corporation y la Universidad de Maryland. Basili ayhud a
fundar el laboratorio en 1976. Desde entonces, estudiantes de posgrado y programadores de
la NASA han colaborado en ms de 100 proyectos, dice Basili, la mayora vinculados con
la construccin de software para soporte terrestre para satlites.
Basta echarle agua
Los fabricantes de arcabuces no lograron mejorar su productividad hasta que Eli
Whitney concibi la forma de producir piezas intercambiables, que pudieran ser
ensambladas por cualquier operario hbil. De forma anloga una vez standarizadas, las
partes del software podran reutilizarse en diferentes escalas. Hace decenios que los
programadores vienen utilizando bibliotecas de subrutinas para no tener que escribir una y
otra vez el mismo cdigo. Pero estos componentes dejan de funcionar al ser trasladados a
un lenguaje de programacin diferente, o a una plataforma de hardware o entorno operativo
de distinto tipo. La tragedia es que, al devenir obsoleto el hardware, resulta necesario
volver a escribir lo que era una excelente muestra de un algoritmo de clasificacin
conseguida en los aos sesenta, observa Simonyi de Microsoft.
Fisher ve una tragedia de diferente tipo. El verdadero precio que nosotros pagamos
es que como especialista en cualquier tecnologa de software usted no puede reflejar en un
producto esa peculiar destreza que posee. Y si tal cosa no es posible, tambin es imposible
ser especialista. Y no es que falten quienes lo hayan intentado. Antes de trasladarse a NIST
el ao pasado, Fisher fund y actu de mximo responsable de Incremental Systems. Sin
ninguna duda eramos world-class en tres de las tcnicas que intervienen en los
compiladores, pero no alcanzbamos el mismo nivel de calidad en las otras siete o as,
declara. Y descubrimos que no haba ninguna forma prctica de vender componentes de
compilador; era preciso que vendiramos compiladores completos.
As que ahora est tratando de ponerle remedio a esa situacin. NIST anunci en
abril que estaba preparando un Programa de Tecnologa Avanzada que contribuyera a
generar un mercado para software basado en componentes. En su calidad de director del
programa, Fisher distribuir 150 millones de dlares en subvenciones de investigacin a
compaas de software dispuestas a afrontar los obstculos tcnicos que actualmente hacen
inviable producir partes de software.
El mximo desafo consiste en encontrar formas de romper los lazos que ligan
indisolublemente los programas a computadores especficos y a otros programas. Los
investigadores estn estudiando varios mtodos prometedores, entre ellos un lenguaje
comn que podra servir para describir partes de software; programas capaces de reformar
los componentes, adaptndolos a un ambiente cualquiera; y componentes provistos de
mltiples opciones, que el usuario podra activar o no.
Fisher favorece la idea que las componentes deberan ser sintetizadas en la accin.
Los programadores deberan bsicamente capturar cmo hacer en lugar de hacindolo,
produciendo una reformulacin que cualquier computadora pueda comprender. Luego
cuando usted quiere ensamblar dos componentes, usted podra tomar esta reformulacin y
derivar versiones compatibles aadiendo elementos adicionales a sus interfaces. Todo
podra ser automatizado, explica.
Incluso con un incentivo de 150 US$ millones y presiones del mercado forzando a
las empresas a encontrar caminos ms baratos para producir software, no es inminente una
revolucin industrial en el software. Nosotros esperamos ver solamente ejemplos aislados
de estas tecnologas en cinco a siete aos - y eso en el caso que no fracase todo, se
resguarda Fisher. E incluso cuando la tecnologa est a punto, sern pocos quienes adopten
los componentes a menos que stos puedan producirse a un precio ventajoso. Y el costo de
los mdulos depender menos de la tecnologa utilizada que del tipo de mercado que pueda
surgir para producirlos y consumirlos.
Brad Cox, como Fisher tambin fue director de una compaa de componentes de
programacin y le result difcil sacarla adelante. Cree saber dnde est el problema...y su
solucin. Su empresa trataba de vender componentes de programas de bajo nivel, algo
anlogo a los microcircuitos de los ordenadores. La diferencia entre los circuitos
integrados de silicio y los circuitos integrados para software estriba en que los primeros
estn formados por tomos, y perduran por conservacin de la masa; en consecuencia la
gente sabe como comprarlos y venderlos con seguridad, dice Cox. Pero este proceso de
intercambio, que se encuentra en el corazn de todo el comercio, sencillamente no funciona
para cosas que se pueden copiar en nanosegundos. Cuando trat de vender los mdulos
creados por sus programadores, el precio que los clientes estaban dispuestos a pagar era
demasiado bajo para resarcirle de los costos de desarrollo.
Las razones eran dobles. La primera, que la adaptacin manual de los mdulos a las
necesidades de cada cliente era una operacin que consuma mucho tiempo; NIST confa en
salvar esta barrera con su Programa de Tecnologa Avanzada. El otro factor no era tanto
tcnico como cultural: lo que quieren los compradores es pagar por el componente una vez
y luego hacer copias gratis.
La industria de la msica ha tenido cerca de un siglo de experiencia con este grave
problema, observa Cox. Ellos solan vender objetos tangibles, como partituras y rollos de
pianola, pero llegaron la radio y la televisin y todo aquello se fue al garete. Las
compaas musicales se adaptaron a la radiodifusin estableciendo agencias encargadas de
percibir los derechos de autor cada vez que se emite una meloda y de encauzar esos fondos
hacia los artistas y los productores.
Cox propone que se les pase un cargo a los usuarios cada vez que utilicen un
componente de programacin. De hecho, dice, en el caso del software tal modelo podra
funcionar mejor que con la msica, gracias a las ventajas de infraestructura que
proporcionan los ordenadores y las comunicaciones. Los reproductores de grabaciones no
disponen de enlace a redes de alta velocidad que registren su utilizacin, peor los
ordenadores, si.
O, por lo menos, la tendrn en el futuro. Escudriando en el tiempo en que casi
todas las computadoras estn conectadas, Cox visualiza la distribucin de software de todos
los tipos a travs de redes que vinculen productores de componentes, usuarios finales e
instituciones financieras. Es anlogo a una operacin de tarjeta de crdito pero con
tentculos que penetran en cada PC, dice. Aunque a algunos pueda sonarle ominoso, Cox
argumenta que ahora Internet es ms un depsito de desperdicios que un mercado para
comprar. Necesitamos una gran infraestructura que pueda soportar la distribucin de todo
tipo de productos. Reconociendo la envergadura del cambio cultural que propone, Cox
espera empujar su causa por aos a travs de la Coalition for Electronic Markets, de la que
es presidente.
La combinacin de control industrial de procesos, herramientas tcnicamente
avanzadas y partes intercambiables promete transformar no slo la forma de realizar la
programacin, sino tambin a los encargados de efectuarla. Muchos de los expertos que
convergieron en Hedsor Park acuerdan con Belady que en el futuro, los profesionales de
muchos campos usarn la programacin como una herramienta de trabajo, pero ellos no
querrn llamarse a s mismos programadores ni creern estar dedicando su tiempo a la
programacin. Pensarn, en cambio, estar haciendo arquitectura, o control de trfico, o
pelculas de cine.
Esta posibilidad suscita la pregunta de quines estn capacitados para construir
sistemas importantes. En la actualidad cualquiera puede anunciarse como ingeniero de
software. Pero cuando se tengan cien millones de programadores-usuarios, ser frecuente
que se hagan cosas criticas para la vida, como, por ejemplo, construir programas para
extender recetas mdicas, hace notar Barry W.Boehm , director del Center for Software
Engineering de la Universidad de Southern California. Boehm es uno del creciente nmero
de quienes recomiendan que los ingenieros de software deben certificarse, como se hace en
otros campos de la ingeniera.
Tal certificacin slo servir de algo si los programadores reciben la formacin
adecuada. Actualmente slo 28 universidades ofrecen programas de posgrado en ingeniera
de software; cinco aos atrs haba slo 10. Ninguna ofrece ttulos de grado. Incluso
acadmicos tales como Shaw, DeMillo y Basili acuerdan que en general la curricula de
computer science ofrece por lo general una preparacin deficiente para el desarrollo
industrial de software. Pues aspectos fundamentales, como el diseo de inspecciones del
cdigo, la produccin de documentacin para el usuario y el mantenimiento de los
programas que van quedndose anticuados, no son cubiertos en la academia, se lamenta
Capers Jones.
Los ingenieros, la infantera de toda revolucin industrial, no se generan
espontneamente. Reciben una formacin tendiente a evitar los malos hbitos de los
artesanos que les precedieron. En tanto las lecciones de la ciencia de la computacin no
inculquen no slo el deseo de construir mejores cosas, sino el de construir mejor las cosas,
lo mejor que podemos esperar es que el desarrollo del software vaya pasando por una
evolucin industrial lenta y probablemente dolorosa.
Bibliografa complementaria
Encyclopedia of Software Engineering. Editada por John J. Marciniak. John Wiley & Sons,
1994.
Software 2000: A View of the Future. Editado por Brian Randell, Gill Ringland y Bill
Wulf. ICL y la Comisin de Comunidades Europeas, 1994.
Formal Methods: A Virtual Library. Jonathan Bowen. Disponible en hipertexto en Wide
World Web, con la referencia http://www.comlab.ox.ac.uk/archive/formal-methods.html
Traduccin del Scientific American aparecida en Investigacin y Ciencia, noviembre de 1994. Revisada por
Alejandro Oliveros. En lo que sigue las notas son comentarios de AO a fin de aclarar la traduccin.
2
Denver, Colorado, es un gran centro de esqu invernal de los Estados Unidos de Amrica
3
Da de Brujas, 2 de noviembre
4
Del hemisferio norte
5
El promotor de las piezas de recambio
6
Alude a un artculo clsico de la Ingeniera de Software, de Fred Brooks. El ttulo No silver bullets, recupera
una leyenda segn la cual al hombre lobo slo se lo puede matar con una bala de plata en el medio del
corazn.
Versin traducida por Alejandra Serrano contactar a:

contacto@reparaciondepc.cl
No existen balas de plata: esencias y accidentes de la ingeniera software
Tiene que ser difcil? Dificultades esenciales
No solo ahora no hay balas de plata a la vista, sino que la propia naturaleza del
software hace poco probable su futura existencia; ninguna futura invencin servir
para la productividad del software, confianza, y simplicidad, como lo hicieron
sistemas electrnicos, transistores, y la integracin a larga escala por los hardware
de computadores. No podramos esperar jams ver duplicarse las ganancias cada 2
aos.
En primer lugar, se debe observar que la anomala no es que el progreso del
software sea lento, sino que el progreso de los hardware de computadores es muy
rpido. Ninguna otra tecnologa desde el principio de la civilizacin ha visto seis
veces elevado a la dcima potencia su ganancia en cuanto al precio de presentacin
en los ltimos 30 aos. En ningn otro tipo de tecnologa se puede optar por tomar,
ya sea en la ganancia o la mejora de los resultados en la reduccin de los costos.
Esas ganancias provienen de la transformacin de la fabricacin del computador de
una industria del lenguaje Assembly a una industria de proceso.
En segundo lugar, para ver el nivel de progreso que se puede esperar en la
tecnologa software, permtanos examinar las dificultades de esa tecnologa.
Siguiendo a Aristteles, divido en esencia las dificultades inherentes a la
naturaleza del software, y accidentes a las dificultades que actualmente asisten a
su produccin pero que no son inherentes.
La esencia de una entidad software es el resultado de una construccin de
conceptos entrelazados: conjuntos de datos, relaciones entre los elementos de
datos, algoritmos y de invocaciones de funciones. Esta esencia es abstracta, ya que
tal construccin conceptual es la misma bajo muchas representaciones distintas.
Sin embargo es extremadamente preciso y detallado.
Creo q la parte ms difcil en la creacin de un software es la especificacin, diseo
y prueba de la construccin de esta base conceptual, no el trabajo de representar y
probar la calidad de la representacin. Aun cometemos errores de sintaxis para
asegurarnos, pero no son nada comparados con los errores conceptuales en la
mayora de los sistemas.
Si esto es cierto, crear un software ser siempre difcil. No hay intrnsecamente
ninguna bala de plata.
Consideremos las propiedades inherentes de esta esencia irreducible de los
sistemas modernos de software: complejidad, conformidad, variabilidad e
invisibilidad.
Complejidad: Las entidades software son ms complejas que talvez cualquier otra
construccin humana por su tamao, porque no tiene dos partes iguales (al menos
por encima del nivel del orden). Y si las hay, ponemos las dos partes similares en
una subrutina; abierta o cerrada. En este aspecto, los sistemas software difieren
profundamente de los computadores, edificios o automviles, donde abundan
elementos repetidos.
Los computadores digitales son por si mismos ms complejos que la mayora de las
cosas que las personas crean: tienen un gran nmero de etapas. Esto hace difcil
concebirlos, describirlos y probarlos. Los sistemas software tienen muchsimos ms
estados que los computadores.
Del mismo modo, un aumento de una entidad software no es simplemente una

repeticin de los mismos elementos a una mayor escala, es necesario un aumento
en el nmero de distintos elementos. En la mayora de los casos, los elementos
interactan entre si de una forma no lineal, y la complejidad del todo incrementa
mucho mas que linealmente.
La complejidad del software es una propiedad esencial, no accidental. Por lo tanto,
las descripciones de una identidad software que dejan de lado su complejidad
tambin lo hacen de su esencia. Durante tres siglos, las matemticas y las ciencias
fsicas hicieron grandes avances construyendo modelos simplificados de fenmenos
complejos, derivando propiedades de los modelos y comprobando esas derivaciones
por medio de experimentacin. Este paradigma funcionaba porque las
complejidades ignoradas en esos modelos no eran propiedades esenciales de los
fenmenos. No funciona cuando las complejidades son la esencia.
Muchos de los tpicos problemas de desarrollar productos software provienen de
esta complejidad esencial y su no-linealidad incrementa con el tamao. De la
complejidad proviene la dificultad de comunicacin entre los miembros del equipo,
lo que lleva a fallas de producto, costos excesivos, retrasos en los periodos de
entrega. De la complejidad proviene la dificultad de enumeracin, un an menor
entendimiento y todos los posibles estados del programa; de all viene la poca
fiabilidad. De la complejidad de funcin viene la dificultad de iniciar la funcin, lo
cual hace a los programas difciles de usar. De la complejidad de estructura viene la
dificultad para extender los programas a nuevas funciones sin crear efectos
secundarios. De la complejidad de estructura vienen los estados invisibles, los
cuales constituyen una verdadera trampilla de seguridad.
De la complejidad no solo vienen problemas tcnicos, sino tambin problemas de
manejo. Esto hace difcil una visin general, impidiendo as una integridad
conceptual. Hace difcil encontrar y controlar todos los cabos sueltos. Crea la
tremenda carga de aprender y entender, lo que hace de la renovacin de personal
un desastre.
Conformidad: La gente de software no es la nica en enfrentar complejidad.
Fsicos tratan con objetos extremadamente complejos, incluso al nivel de partculas
fundamentales. Sin embargo, la labor de un fsico es trabajar con la firme
conviccin de estar unificando principios aun no descubiertos, ya sea en quarks o
en teoras del campo unificado. Einstein sostuvo que debe haber explicaciones
simplificadas de la naturaleza, porque Dios no es caprichoso ni arbitrario.
Esta creencia no reconforta al ingeniero de software. Gran parte de la complejidad
que el debe dominar es complejidad arbitraria, forzada sin ton ni son por las
muchas instituciones humanas y sistemas a los cuales sus interfaces deben
conformar. Estos difieren de interfaz a interfaz y de vez en cuando no es por
necesidad, sino solo por que fueron diseados por diferentes personas, en vez de
por Dios.
En muchos casos el software debe ajustarse porque es el mas reciente. Otras veces
debe adaptarse porque es visto como el mas mediocre. Pero en todos los casos,
gran complejidad viene de la conformacin de otras interfaces; esta complejidad no
puede simplificarse por ningn rediseo aislado del software.
Mutabilidad: La entidad software esta constantemente sujeta a presiones de
cambio. Por supuesto tambin lo estn los edificios, autos y computadores. Pero las
cosas fabricadas son cambiadas con poca frecuencia luego de su creacin, son
reemplazadas por modelos nuevos, o se incorporan cambios esenciales en el
numero de serie de copias posteriores al diseo bsico. Retrocesos en automviles
son muy poco frecuentes, e incluso se dan menos en el campo computacional.
Ambos son mucho menos frecuentes que las modificaciones en el terreno de

software.
En parte esto es as porque el software de un sistema abarca su funcin, y la
funcin es la parte que ms siente la presin de cambio. Y esto es en parte es
porque el software puede ser cambiado con mayor facilidad, it is pure thoughtstuff, infinitamente adaptable. Los edificios son cambiados, pero los altos costos de
estos cambios son suficientes para desalentar a quienes quieran cambiarlos.
Todo software exitoso es cambiado. Se trabajan dos procesos. Primero, cuando un
producto software es til, las personas lo prueban llevndolo al lmite o ms all de
su dominio original. La presin para extender las funciones viene principalmente de
usuarios a los que les gustan las funciones bsicas y les inventan nuevos usos.
Segundo, un software exitoso sobrevive mas all de la vida normal de mquina
para la que fue creada. Si no nuevos computadores, al menos vendrn nuevos
discos, pantallas e impresoras, y el software debe ajustarse.
En resumen, el producto software esta incrustado en una matriz cultural de
aplicaciones, usuarios, leyes y mquinas vehculo. Todos estos cambian
continuamente, lo que fuerza implacablemente cambios en el producto software.
Invisibilidad: Software es invisible. Las abstracciones geomtricas son
herramientas poderosas. El primer piso de un edificio ayuda a cliente y arquitecto
a evaluar los espacios, flujos de trafico y vistas. Las contradicciones y omisiones se
vuelven evidentes. Dibujos a escala de partes mecnicas y maquetas, a pesar de
las abstracciones, tienen la misma finalidad. Una realidad geomtrica es capturada
en una abstraccin geomtrica.
La realidad del software no esta intrnsecamente incrustada en el espacio, por lo
tanto, no tiene aun una representacin geomtrica de la forma en que la Tierra
tiene mapas, los chips de silicio tienen diagramas, los computadores tienen
diagramas de conectividad. Tan pronto como intentamos esquematizar la estructura
del software, nos encontramos con que constituye no uno, sino varios grficos
generales superpuestos uno sobre el otro. Los varios grficos pueden representar el
flujo de control, el flujo de datos, los patrones de dependencia, la secuencia de
tiempo y las relaciones nombre-espacio. Estos grficos por lo general no son
siquiera planos, y mucho menos jerrquicos. De hecho, una de las formas de
establecer un control conceptual sobre tal estructura es imponer un corte de la
conexin hasta que uno o mas grficos se convierta en jerrquico.
A pesar del progreso en la limitacin y simplificacin de las estructuras del
software, estas siguen siendo intrnsecamente invisibles y por lo tanto no le
permiten a la mente usar algunas de sus ms poderosas herramientas
conceptuales. Esta carencia no solo le impide el proceso de diseo a una sola
mente, sino que tambin dificulta gravemente la comunicacin entre mentes.
ltimos Avances Resolvieron Dificultades Accidentales
Si analizamos los tres pasos en el desarrollo de la tecnologa software que han sido
ms fructferos en el pasado, descubrimos que cada uno atac a una de las
dificultades principales en la construccin de software, pero que esas dificultades
haban sido accidentales y no esenciales. Tambin podemos ver los lmites
naturales a la extrapolacin de cada uno de dichos ataques.
Lenguajes de alto nivel: Sin duda el golpe ms poderoso para la productividad,
fiabilidad y simplicidad del software ha sido la utilizacin progresiva de lenguajes de
alto nivel para la programacin. La mayora de los observadores le acreditan el
desarrollo de al menos un factor de cinco en cuanto a productividad, y con un

aumento simultneo de la fiabilidad, simplicidad y comprensibilidad.
Qu logra un lenguaje de alto nivel? Libera a un programa de gran parte de su
complejidad accidental. Un programa abstracto esta formado por construcciones
conceptuales: operaciones, tipos de datos, secuencias y comunicacin. El programa
concreto involucra bits, registros, divisiones, canales, discos y demases. En la
medida en que el alto nivel de lenguaje incorpora las construcciones que uno quiera
en el programa abstracto y evite todos los de menor nivel, ste elimina todo un
nivel de complejidad que nunca fue inherente al programa en absoluto.
Lo mximo que un lenguaje de alto nivel puede hacer es presentar todas las
construcciones que el programador imagina en el programa abstracto. Sin duda, el
nivel de nuestras ideas acerca de las estructuras de datos, tipos de datos y
operaciones est creciendo, pero en una tasa siempre decreciente. Y el desarrollo
del lenguaje se acerca cada vez ms a la complejidad de los usuarios.
Tiempo compartido (multiprogramacin): El tiempo compartido significo una
gran mejora en la productividad de los programadores y en la calidad de sus
productos, aunque no tanto as como la que trajo el lenguaje de alto nivel.
El tiempo compartido ataca una dificultad bastante diferente. Este preserva la
inmediatez, y por lo tanto permite que se mantenga una visin general de la
complejidad. La lenta respuesta de los lotes de programacin significa
inevitablemente que uno se olvide de detalles minsculos, si no la propia idea de lo
que se pensaba cuando se detuvo la programacin y se pidi la compilacin y
ejecucin. Esta interrupcin es costosa en tiempo, ya que uno debe refrescarse la
memoria. El efecto mas grave puede ser la dificultad para comprender todo lo que
esta sucediendo en un sistema complejo.
Una lenta rotacin, como las complejidades lenguaje-mquina, es una dificultad
accidental del proceso de software en vez de esencial. Los lmites de la contribucin
potencial de tiempo compartido se derivan directamente. El efecto principal de la
utilizacin compartida es para acortar el tiempo de respuesta del sistema. Cuando
el tiempo de respuesta llega a cero, de alguna forma traspasa el umbral de humano
de lo observable, unos 100 milisegundos. Ms all de ese umbral no se esperan
beneficios.
Entornos de programacin unificados: Unix and Interlisp, el primer entorno
de programacin integrado en volverse masivo parece haber mejorado su
productividad por factores integrales. Por qu?
Ellos atacan las dificultades accidentales que derivan de la utilizacin de programas
individuales juntos, mediante el suministro de bibliotecas integradas, archivos de
formato unificado y de tuberas y filtros.
Como resultado de esto, las estructuras conceptuales que bsicamente podran
siempre llamar, suministrar datos y usarse entre si pueden, de hecho, hacerlo fcil
en la prctica.
Este avance a su vez estmulo el desarrollo de whole toolbenches, ya que cada
nueva herramienta podra aplicarse a cualquier programa que utilice el formato
estndar.
Debido a estos xitos, los entornos son objeto de parte importante de las actuales
investigaciones de ingeniera software. Veremos lo que promete y sus limitaciones
en la siguiente seccin.
Esperanzas de la Plata
Ahora consideremos los desarrollos tcnicos que son considerados como posibles
balas de plata con mas frecuencia. Qu problemas enfrentan, de esencia o de las
dificultades accidentales que permanecen? Ofrecen avances vanguardistas, o en
crecientes?
Ada y otros avances de lenguaje de alto nivel. Uno de los desarrollos recientes
mas anunciados es Ada, un lenguaje de los aos 80 de alto nivel y con propsitos
generales. Ada no solo refleja mejoras evolutivas en conceptos de lenguajes, sino
que de hecho
Tal vez la filosofa de Ada es ms de un anticipo que el lenguaje Ada, ya que es la
filosofa de la modularizacin, de los tipos abstractos de datos, de jerarquizacin.
Ada es excesivamente sustancioso, un resultado natural del proceso por el que se
establecen los requisitos de su diseo. Eso no es fatal, ya que el trabajo d estos
vocabularios subordinados puede resolver el problema de aprendizaje. Los
vocabularios de trabajo pueden resolver el problema de aprendizaje, y los avances
en hardware nos significaran MIPS ms baratos para pagar los costos de
compilacin. Avanzar en la estructuracin de sistemas de software es, en efecto, un
buen aprovechamiento para los incrementados MIPS que nuestros dlares
compraran. Los sistemas operativos, denunciados a toda voz en la dcada del 60
por su memoria y ciclo de sus costos, ha demostrado ser una excelente forma en la
cual usar algunos de los MIPS y bites de memoria baratos, del pasado surgimiento
de hardware.
No obstante, puede que Ada no resulte ser la bala de plata que mata al monstruo
de productividad de software. Es, despus de todo, slo otro lenguaje de alto nivel,
y el mayor rendimiento de estas lenguas provienen de la primera transicin; la
transicin de las complejidades accidentales en la maquina al orden mas abstracto
de las soluciones paso a paso. Una vez que esos accidentes han sido eliminados,
los restantes sern menores, y el costo de su remocin ser menor. Auguro que
dentro de una dcada a partir de ahora, cuando la eficacia de Ada sea evaluada, se
ver que han hecho una diferencia sustancial, pero no por alguna caracterstica
particular del lenguaje, ni siquiera por todas ellas en conjunto. Tampoco los nuevos
entornos de Ada probaran ser la causa de su mejora. La contribucin ms grande
de Ada ser que utilizarlo significara la capacitacin de los programadores a
modernas tcnicas de diseo de software.
Programacin orientada a objetos: Muchos estudiantes de la tcnica tienen mas
expectativas en cuanto a programacin orientada a objetos que cualquier otra
tcnica de moda. Yo estoy entre ellos. Mark Sherman de Darmouth nota en CSnet
News que uno debe ser cuidadoso para poder distinguir dos ideas separadas que
estn bajo el titulo tipos abstractos de datos y tipos jerrquicos. El concepto de
los tipos de dato abstractos se refiere a que un tipo de objeto debe ser definido con
un nombre, un conjunto de valores y un conjunto adecuado de operaciones y no
por su estructura de almacenamiento, la cual debe ser ocultada. Ejemplos de ello
son los paquetes Ada (con clases privadas) y los mdulos de Modula.
Los tipos jerrquicos, como la clase Simula-67, le permite a uno definir interfaces
generales que pueden ser mejoradas mas tarde administrndoles los tipos de
subordinacin. Los dos conceptos son diagonales; uno puede estar jerarquizado sin
disimulo o disimulo sin jerarquizacin. Ambos conceptos representan verdaderos
avances en el arte de crear un software.
Cada uno remueve otra dificultad accidental del proceso, permitindole al diseador
expresar la esencia del diseo sin tener que expresar una gran cantidad de material
sintctico cuyo contenido no aade informacin. Para ambos, tipos abstractos y
jerrquicos, el resultado es la eliminacin de una gran cantidad de dificultades
accidentales y la posibilidad de un gran numero de expresiones de diseo.
No obstante, estos avances no pueden hacer ms que eliminar las dificultades

accidentales de la expresin de diseo. La complejidad del diseo en s es
fundamental, y esos ataques no hacen cambio alguno en eso. Se puede obtener
una enorme ganancia de la programacin orientada a objetos slo si tipo y
especificacin innecesaria en nuestro lenguaje de programacin es de nueve
dcimas del trabajo involucrado en el diseo de un producto de programacin. Lo
dudo.
Inteligencia artificial: Muchas personas esperan el desarrollo en la inteligencia
artificial que proporcione el avance revolucionario que significara enormes
ganancias en cuanto a productividad y calidad del software. Yo no. Para saber por
qu debemos analizar lo que se entiende por inteligencia artificial.
DL. Parnas ha aclarado el caos terminolgico.
Dos definiciones muy distintas de IA son comnmente usadas hoy en da. IA
1: El uso de computadores para resolver problemas que anteriormente
slo podan ser resueltos mediante la aplicacin de la inteligencia humana.
IA 2: El uso de un conjunto especfico de tcnicas de programacin
conocida como heurstica o programacin basada en las normas. En este
enfoque se utilizan humanos expertos para determinar las heursticas o
reglas bsicas que usan para resolver problemas El programa es diseado
para resolver un problema de la forma en que los seres humanos parecen
hacerlo.
Algo puede tener cabida en la definicin de Al - 1 de hoy, pero una vez que
vemos cmo funciona el programa y comprendemos el problema, no vamos
a seguir pensando en l como Al... Lamentablemente no puedo identificar un
contenido tecnolgico que es nico en esta rea La mayor parte del trabajo
es de problemas especficos, y se necesita algo de abstraccin y creatividad
para ver como transferirlos.
Yo concuerdo absolutamente con esta crtica. Las tcnicas empleadas para el
reconocimiento de voz parecen tener poco en comn con las que se utilizan para el
reconocimiento de imagen, y ambas son diferentes de las utilizadas en sistemas
expertos. Me cuesta trabajo ver cmo el reconocimiento de imgenes, por ejemplo,
tendr alguna diferencia notoria en la practica de programacin. El mismo problema
ocurre con el reconocimiento de voz. Lo difcil en cuanto a la creacin de un
software decidir qu se quiere decir, no decirlo. Ninguna forma de facilitacin de
expresiones puede dar mas que ganancias insignificantes.
Los sistemas expertos de tecnologa IA-2 merecen una seccin propia.
Sistemas expertos: La parte mas avanzada y que se aplica ms ampliamente de la
inteligencia artificial es la tecnologa para crear sistemas expertos. Muchos
cientficos de software trabajan duro para aplicar esta tecnologa al entorno de la
creacin de un software. Cul es el concepto y cuales son las perspectivas?
Un sistema experto es un programa que contiene un motor de inferencia
generalizado y una norma de base, toma de entrada de datos y asunciones, explora
las interferencias que derivan de la norma de base, procura conclusiones y
consejos, y ofrece explicar los resultados mostrando su razonamiento al usuario.
Los motores de inferencia normalmente pueden hacer frente a los datos borrosos o
datos probabilsticas y normas, adems de la lgica puramente determinista.
Tales sistemas ofrecen ventajas claras sobre los algoritmos diseados para llegar a
las mismas soluciones de los mismos problemas:
La tecnologa motor de la inferencia es desarrollada en una forma

independiente de aplicaciones, y luego se aplica a muchos usos. Uno puede
justificar un gran esfuerzo en la inferencia de los motores. De hecho, es una
tecnologa muy avanzada.
Las partes variables de los materiales caractersticos de la aplicacin estn
codificados en la norma de base de forma uniforme y se proporcionan
herramientas para el desarrollo, la evolucin, la prueba y la documentacin
de la norma de base. Esto regulariza gran parte de la complejidad de la
aplicacin misma.
El poder de tales sistemas no proviene de mecanismos de inferencia lujosos,

sino ms bien de mecanismos con bases de conocimiento cada vez mas
sustanciosas que reflejan de manera mas precisa el mundo real. Creo que el
avance ms importante ofrecido por la tecnologa es la separacin entre la
complejidad y programa en s.
Cmo puede esta tecnologa ser aplicada a la tarea de ingeniera de software?
De muchas formas: Estos sistemas pueden sugerir normas de interfaz,
asesoramiento sobre estrategias de experimentacin, recordatorios de errores
frecuentes, y ofrecer tambin sugerencias de optimizacin.
Considere la posibilidad de un asesor imaginario de prueba, por ejemplo. En su
forma ms rudimentaria, podramos decir q slo enumera sugerencias en
cuanto a las posibles causas de dificultades. Entre mas estructuras del sistema
consagren la base de normas, y sta tome en cuenta mas sofisticadamente los
problemas sintomticos informados, el consejero de prueba se vuelve ms y
ms preciso en las respuestas que genera y las pruebas que recomienda. Un
sistema as de especializado se diferencia radicalmente de los sistemas
convencionales en que su base de normas debera probablemente ser
jerrquicamente modularizada, como lo son los productos software, para que
mientras que el producto es modularmente modificado, tambin lo sea el
diagnostico de base de normas.
El trabajo necesario para generar las normas de diagnstico es el que habra que
hacer de todos modos al generar el conjunto de casos de prueba para los mdulos
y para el sistema. Si se hace de una manera adecuada, con una estructura
uniforme para las normas y un buen motor de inferencia disponible, puede
realmente reducir el total de la generacin de mano de obra que significan los casos
de prueba, y contribuir as a un mantenimiento de por vida y la modificacin de
pruebas. De la misma manera, uno puede postular otros asesores, probablemente
muchos y de manera simple, para las dems partes de la tarea de construccin de
software.
A quien desarrolla un programa se le presentan muchas dificultades en el camino
por una pronta realizacin de un til sistema consejero experto. Una parte
fundamental de nuestro imaginario escenario es el desarrollo de formas fciles de
obtener desde la especificacin de programas-estructura a la generacin
automtica o semiautomtica de las reglas de diagnstico. An ms difcil e
importante la doble tarea de adquisicin de conocimientos: la bsqueda de
expertos elocuentes, auto analticos, que conozcan la razn por la que hacen las
cosas, desarrollando tcnicas eficientes para la extraccin de lo que saben y
separando en sus componentes las bases de normas. El prerrequisito esencial para
la construccin de un sistema experto es disponer de un experto.
La contribucin ms poderosa de los sistemas expertos, sin duda ser poner al
servicio de programadores novatos la experiencia y la sabidura acumulada de los
mejores programadores. Esta no es una contribucin pequea. La brecha entre las
mejores prcticas de ingeniera de software y las prcticas promedio es inmensa,
talvez la mas grande entre las disciplinas de la ingeniera. Una herramienta que
difunde las buenas prcticas sera importante.
Programacin Automtica: Por casi 40 aos la gente ha estado anticipando y
escribiendo acera de la programacin automtica o sobre la generacin de
programas resolviendo problemas del orden de la especificacin de problemas.
Algunos actualmente escriben como si esperaran que esta tecnologa proporcione el
prximo gran avance.
Parmas sugiere que el trmino es usado para el glamour, no por su contenido
semntico, afirmando:
En resumen, la programacin automtica siempre ha sido un eufemismo de
la programacin con un mayor nivel de lenguaje disponible actualmente para
el programador.
El argumenta, en esencia, que en la mayora de los casos tiene que ser dada la
explicacin del mtodo de solucin y no del problema en s.
Se pueden encontrar excepciones. La tcnica de creacin de los generadores es
muy potente, y es habitualmente utilizada para traer grandes beneficios en la
clasificacin de los programas. Algunos sistemas para la integracin de ecuaciones
diferenciales tambin han permitido la especificacin directa del problema, y los
sistemas han evaluado los parmetros, elegidos de una biblioteca de mtodos de
solucin, y los programas generados.
Estas aplicaciones tienen propiedades muy favorables:
Los problemas son fcilmente caracterizados por un nmero relativamente

reducido de parmetros.
Hay muchos mtodos conocidos de solucin para proporcionar una biblioteca
de alternativas.
Amplio anlisis ha dado lugar a normas explcitas para la seleccin de
tcnicas de solucin, dados los parmetros del problema.
Es difcil ver como tales tcnicas generalizan a un mundo ms amplio el sistema

software comn, donde los casos con propiedades tan impecables son la
excepcin. Es difcil incluso imaginar como este avance en la generalizacin
puede pasar.
Grafica de la programacin: Un tema favorito para la tesis de doctorado en
ingeniera de software es programacin grfica o visual, la aplicacin de desde
grficos de computador a diseo de software. 6,7 Algunas veces la promesa
mantenida por ese enfoque es postulada como una analoga con diseo de circuito
integrado VLSI, en el cual grficos computacionales desempean un papel tan
provechoso. A veces el terico justifica la metodologa teniendo en cuenta los
diagramas de flujo como el ideal programa-diseo y suministrando poderosos
planteles para construirlos.
Nada ha surgido de tales esfuerzos que resulte convincente, mucho menos
emocionante. Estoy convencido de que nada lo har.
En primer lugar, como he argumentado en otra parte, el diagrama de flujo es una
abstraccin muy mala de la estructura software. De hecho, es mejor visto el intento
de Burks, Von Neumann y Goldstine por proporcionar un control de lenguaje de alto
nivel tan necesitado para sus propuestas de computador. De la forma lamentable
en que el diagrama de flujo ha sido elaborado actualmente, ha demostrado que no
sirve como herramienta de diseo, los programadores dibujan diagramas de flujo

despus, y no antes, de describir los programas.
En segundo lugar, las pantallas de hoy en da son demasiado pequeas en pxeles
para mostrar tanto el alcance como la resolucin de cualquier diagrama software
verdaderamente detallado. La llamada "metfora de escritorio" de la actual lugar de
trabajo es una metfora "asiento de avin". Cualquier persona a la que se le hayan
desordenado papeles mientras esta en el asiento del medio de un avin entender,
uno puede ver solo unas pocas cosas a la vez. El verdadero escritorio ofrece una
visin general y el acceso al azar a una gran cantidad de pginas. Adems, cuando
llegan ataques de creatividad, se sabe que ms de un programador o escritor ha
abandonado el escritorio para estar en algn lugar mas espacioso. La tecnologa
hardware tendr que desarrollarse considerablemente antes de que el alcance de
nuestras extensiones sea suficiente para el diseo de escritorio de software.
Esencialmente, como he argumentado antes, el software es muy difcil de
visualizar. Ya sea por los diagramas de control de flujo, referencias variables
cruzadas, flujo de datos, estructuras jerrquicas de datos, o lo que sea, uno siente
tan solo una dimensin del intrincadamente elaborado software. Si uno fuerza
todos los diagramas generados por las muchas visiones relevantes resulta difcil
extraer una visin general. La analoga VLSI es esencialmente engaosa, un diseo
de circuito integrado es una descripcin bidimensional cuya geometra refleja su
realizacin en un espacio tridimensional. Un sistema software no lo es.
Verificacin de programa: Gran parte de los esfuerzos en la programacin
moderna van dirigidos a la prueba y reparacin de fallos. Se podr encontrar
talvez una bala de plata luego de eliminar los errores en el origen o en la fase de
diseo del sistema? Pueden la productividad y la fiabilidad del producto ser
radicalmente mejorados, siguiendo as la estrategia tan opuesta de proveer diseos
sin errores, antes de derrochar el inmenso esfuerzo en implementarlos y probarlos?
No creo que la productividad vaya a encontrar magia aqu. La verificacin de
programa es un concepto muy poderoso y ser muy importante para cosas como
un seguro manejo de ncleos de sistema (o kernels). Sin embargo esta tecnologa
no promete ahorrar mano de obra. Las comprobaciones significan tanto trabajo que
tan solo unos pocos programas importantes han sido verificados alguna vez.
Verificacin de programas no significa que estos sean a prueba de errores.
Tampoco hay magia aqu. Las pruebas matemticas tambin pueden ser fallidas.
As que aunque la verificacin podra reducir la carga de lo que significa probar los
programas, no la puede eliminar.
Mas grave an, incluso la verificacin de programa perfecta solo puede establecer
que un programa cumple su especificacin. La parte ms difcil de la tarea del
software es alcanzar una especificacin completa y consistente, y gran parte de la
esencia de la creacin de un programa de hecho es la depuracin de errores en la
especificacin.
Entornos y herramientas: Cuntas ganancias se pueden esperar de la
explotacin de investigaciones dirigidas hacia mejores entornos de programacin?
La primera reaccin instintiva de uno, es que los grandes problemas de rentabilidad
fueron los primeros en ser atacados y han sido resueltos; sistemas jerrquicos de
archivos, archivos de formato uniforme para hacer posible interfaces uniformes de
programa, y herramientas generales. Los editores inteligentes con lenguaje
especfico son avances que aun no se utilizan masivamente en la prctica, pero lo
mximo que pueden prometer es no tener errores sintcticos ni errores semnticas
simples.
Talvez el mayor logro de los entornos de programacin ser el uso de bases de

datos integradas para seguirles el rastro al gran nmero de detalles que deben ser
recordados con precisin por el programador, y mantenido al da por un grupo de
colaboradores en un solo sistema.
Ciertamente este trabajo vale la pena, y sin duda dar frutos en cuanto a
productividad y confiabilidad, pero por su propia naturaleza los beneficios sern
insignificantes.
Estaciones de trabajo: Qu ganancias puede esperar el material grafico de
software del incremento seguro y veloz de la capacidad de memoria y poder de la
estacin de trabajo individual? Cuntos MIPS pueden ser utilizados
fructferamente? La composicin y edicin de programas y documentos es
totalmente respaldada por todays speeds. Compiling puede significar un aumento,
pero un factor de cada 10 en velocidad de mquina would surely leave thinktime a
la actividad dominante en el da del programador. De hecho parece serlo ahora.
Ciertamente le damos la bienvenida a estaciones de trabajo ms poderosas. No
podemos esperar mejoras mgicas de ellas.
Ataques prometedores en la esencia conceptual

Aunque ningn avance tecnolgico promete una clase de resultados mgicos como
a los que estamos acostumbrados en el rea del hardware, hay una abundancia de
buen trabajo ahora y la promesa de un progreso permanente.
Todos los ataques tecnolgicos a los accidentes del proceso software estn
fundamentalmente limitados por la ecuacin de productividad:
Tiempo de tarea = (frecuencia)i x (tiempo).
Si, como se cree, los componentes conceptuales de la tarea estn tomando la
mayor parte del tiempo, entonces ninguna cantidad de actividad en los
componentes de la tarea, que son solamente la expresin de conceptos, puede
brindar ganancias considerables.
Por lo tanto debemos considerar esos ataques dirigidos a la esencia del problema
software, la formulacin de esas complejas estructuras conceptuales.
Afortunadamente algunos de estos ataques son prometedores.
Comprar versus crear: La solucin ms radical y posible para la construccin de
un software es no construirlo.
Cada da esto es ms fcil, ms y ms vendedores ofrecen ms y mejores
productos software para una variedad de aplicaciones. Mientras que nosotros,
ingenieros software, hemos trabajado en la metodologa de produccin, la
revolucin de los computadores personales ha creado no uno, sino muchos
mercados masivos para software. Cada quiosco trae mensualmente revistas, los
cuales promocionan docenas de productos a precios que van desde unos pocos
dlares a unos cuantos cientos de dlares. Fuentes mas especializadas ofrecen
productos mas poderosos para la estacin de trabajo y otros mercados Unix.
Incluso herramientas software y entornos pueden ser trados listos para su
utilizacin. Yo he propuesto en todas partes un mercado para los mdulos

individuales.
Cualquiera de estos productos es ms barato que construir uno nuevo. Incluso a un
costo de cien mil millones de dlares, un software comprado cuesta solo cerca de lo
que cuesta un programador por un ao. Y la entrega es inmediata! Al menos los
productos que realmente existen, productos cuyo creador puede dirigir a un usuario
feliz. Mas aun, tales productos tienden a ser mucho mejor certificados y de alguna
forma mejor mantenidos que los de creacin personal.
El desarrollo de los mercados masivos es, segn yo, la ms profunda tendencia en
ingeniera software. El costo de software siempre ha sido costo de programacin, y
no de replica. Compartir esos costos entre incluso unos pocos usuarios disminuye
radicalmente los costos por persona. Otra forma de verlo es que el uso de X
cantidad de copias de un sistema software efectivamente multiplica la productividad
de sus creadores X cantidad de veces. Eso es una mejora en la productividad de la
disciplina y de la nacin.
El problema clave es, por supuesto, es la aplicacin. Puedo yo usar un paquete
disponible listo para ser utilizado para hacer mi trabajo? Algo sorprendente ha
pasado aqu. Durante los aos 50 y 60 estudio tras estudio han demostrado que
los usuarios no usaran paquetes listos para utilizarse para planillas, inventarios,
recibos de cuenta, etc. Los requerimientos eran muy especficos, la diferencia entre
casos era muy grande. Durante los 80 encontramos tales paquetes siendo
altamente requeridos y usados masivamente. Qu ha cambiado?
No los paquetes. Puede que actualmente sean ms generalizados y adaptables que
en ese entonces, pero no es mucha la diferencia. Tampoco en las aplicaciones. De
hecho las necesidades tecnolgicas y de negocios actualmente son mas diversas y
complicadas que las de hace 20 aos atrs.
El gran cambio ha sido en el porcentaje de costos de hardware y software. En 1960
el comprador de una maquina de dos millones de dlares senta que poda costear
$250.000 mas por un programa de planilla personalizado, uno que se escabulla
fcilmente en el hostil ambiente social computacional. Hoy en da, el comprador de
una maquina de oficina de $50.000 no puede costear un programa de planilla
personalizado, asi que adapta el procedimiento de planilla a los paquetes
disponibles. Los computadores son tan comunes actualmente que las adaptaciones
son acogidas rpidamente.
Existen impresionantes excepciones a mi argumento de que la generalizacin de
paquetes de software ha cambiado poco con los aos: las hojas de clculo
electrnicas y los sistemas simples de base de datos. Estas poderosas armas se
prestan para muchsimos usos, algunos bastante poco ortodoxos. Hay abundantes
artculos e incluso libros sobre como afrontar tareas inesperadas con la hoja de
clculo. Un gran numero de aplicaciones que actualmente habran sido escritas por
programas habituales como Cobol o Report Program Generador (programa
generador de reportes) son ahora hechos con estas herramientas.
Muchos usuarios operan ahora sus computadores a diario en varias aplicaciones sin
siquiera escribir un programa. De hecho, muchos de esos usuarios no pueden
escribir nuevos programas para sus maquinas, pero sin embargo han logrado
resolver nuevos problemas con ellos.
Yo creo que la estrategia productiva mas poderosa de software para muchas
organizaciones hoy en da es la de equipar el sencillo intelecto computacional de los
trabajadores que estn en la lnea de fuego con computadores personales y un
buenos programas de escritura, dibujo, fichero y hoja de calculo y despus dejarlos
libres. La misma estrategia llevada a cabo con estrategias generalizadas de

matemticas y paquetes estadsticos y algunas capacidades simples de
programacin tambin funcionara para cientos de cientficos de laboratorio.
Requerimientos, refinamiento y rpida creacin de prototipos
La parte ms difcil en la creacin de un sistema software es decidir precisamente
qu construir. Ninguna otra parte del trabajo conceptual es tan difcil como
establecer los detallados requerimientos tcnicos, incluyendo todas las interfaces a
las personas, maquinas y otros sistemas de software. Ninguna otra parte del
trabajo paraliza los resultados del trabajo si se hace mal. Ninguna otra parte es
mas difcil de arreglar despus.
Por lo tanto, la funcin mas importante que el creador de software desempea para
el cliente es la extraccin iterativa y refinamiento de los requerimientos del
producto. La verdad es que el cliente no sabe lo que quiere. El cliente normalmente
no sabe que respuestas deben ser contestadas, y casi nunca piensa en el problema
en el detalle tan importante de la especificacin. Incluso la simple respuesta has
que el nuevo sistema software funcione como nuestro antiguo manual de
informacin y procesos del sistema es de hecho demasiado simple. Uno nunca
quiere exactamente eso. Sistemas software complejos son, adems, cosas que
actan, se mueven, trabajan. La dinmica de esas acciones es difcil de imaginar.
As es que para planear cualquier diseo software es necesario permitir una extensa
iteracin entre el cliente y el diseador como parte de la definicin del sistema.
Ira ms lejos y sostendra que es realmente imposible para un cliente, incluso que
trabaje con ingeniera software, especificar de manera completa, precisa y correcta
los exactos requerimientos de un producto software moderno antes de probar
algunas versiones del producto.
Por lo tanto, uno de los esfuerzos tecnolgicos ms prometedores que ataca la
esencia y no los accidentes del problema software es el desarrollo de
aproximaciones y herramientas para la rpida creacin de prototipos de sistemas
ya que la creacin de prototipos es parte de la iterativa especificacin de
requerimientos.
Un sistema software prototipo es uno que simula las interfaces importantes y
desempea las funciones principales del software deseado, mientras que no es
necesario estar ligado por la misma velocidad, tamao o limitaciones de costo de
hardware. Los prototipos normalmente ejecutan las tareas principales de la
aplicacin, pero no pretenden tratar las tareas excepcionales, respondiendo
correctamente a invlidas entradas de datos o abortar impecablemente. El
propsito del prototipo es hacer real la estructura conceptual especificada, para que
el cliente pueda probar su consistencia y utilidad.
Muchas de los actuales procedimientos software se apoyan en la suposicin de que
uno pueda especificar un sistema satisfactorio por adelantado, ayudando a su
construccin, tenindolo listo e instalndolo.
Grandes diseadores:
Podemos tener buenos diseos si seguimos buenas prcticas. Las prcticas para un
buen diseo pueden ser difciles. Los programadores estn entre la parte mas
inteligente de la poblacin, as que pueden aprender buenas practicas. En EEUU se
esta haciendo un esfuerzo por promulgar las practicas modernas. Nuevos planes de
estudio, nueva literatura, nuevas organizaciones como Software Engineering
Institute, todas con el fin de aumentar el nivel de nuestra prctica.
Sin embargo, no creo que podamos subir un nivel. Ya sea que la diferencia entre
diseos pobres y conceptuales yazca en el mtodo de diseo, la diferencia entre
diseos buenos y excelentes seguramente no. Grandes diseos vienen de grandes
diseadores. La construccin de un software es un proceso creativo. Metodologas
slidas pueden fortalecer y liberar la mente creativa; no puede inspirar el trabajo
duro.
Las diferencias no son menores (son como las diferencias entre Salieri y Mozart).
Estudio tras estudio muestra que los mejores diseadores producen estructuras que
son mas rapidas, mas pequeas, mas simples, mas pulcras y son producidas con
menor esfuerzo. Las diferencias entre el gran diseador y el promedio son
enormes.
Un poco de retrospeccin muestra que aunque muchos software buenos y tiles
han sido diseados por comits y creados como parte de proyectos (multipartes),
esos sistemas software que han entusiasmado fans son el producto de una o pocas
mentes diseadoras. Consideremos Unix, APL, Pascal, Modula, la interfase
Smalltalk, incluso Fortran; y contrastmoslos con Cobol, PL/I, Algol, MVS/370, y
MS-DOS.
Por lo tanto, aunque yo apoyo fuertemente los esfuerzos en el desarrollo en el plan
de estudios que se estan desarrollando actualmente, creo que el esfuerzo mas
importante que podemos (trepar) es el desarrollo de mtodos para aumentar
grandes diseadores.
Ninguna organizacin software puede ignorar este desafi. Buenos gerentes no son
tan escasos como los buenos diseadores. Grandes gerentes y grandes diseadores
son ambos muy escasos. La mayora de las organizaciones hace considerables
esfuerzos por encontrar los prospectos administrativos; no conozco ninguna que
haga el mismo esfuerzo en encontrar grandes diseadores de los que la excelencia
de sus productos depende.
Mi primera propuesta es que cada organizacin software debe determinar y
proclamar que los grandes diseadores son tan importantes para su progreso como
lo son los gerentes, y que deben ser igualmente fomentados y recompensados. No
solo en cuanto al salario, tambin gratificaciones de reconocimiento deben ser
equivalentes: tamao de la oficina, amoblado, equipo tcnico personal, fondos de
viaje, equipo de apoyo.
Como aumentar a los grandes diseadores?
-Identificar sistemticamente a los mejores diseadores lo mas pronto posible. Los
mejores no siempre son los ms experimentados.
-asignar un orientador profesional para que se haga responsable por el desarrollo
del prospecto.
-desarrollar y mantener un plan profesional de desarrollo para cada prospecto
-dar oportunidades de crecimiento a los diseadores, para que interacten y se
estimulen entre si.
Unidad 2: Proceso de Desarrollo Iterativo e

Incremental: Unificado de Desarrollo
2.1 Modelo de proceso
En el mdulo 1 hemos visto el concepto de modelo relacionado con el ciclo de vida de desarrollo
de software. Este modelo es una forma de representar la realidad de una manera simplificada, lo
que permite entender ms fcilmente las actividades que se deben realizar.
Todos los negocios, empresas e instituciones tienen procesos de negocio que son informatizados,
por lo que los responsables de capturar los requerimientos y necesidades del cliente deben
conocer estos procesos, entenderlos y modelarlos.
La importancia de modelar los procesos de negocio es para todas las personas involucradas en el
proceso, al igual que para el cliente que valida si se entendi bien el proceso.
La forma de modelar el proceso es importante ya que tiene que ser simple y a la vez claro, con el
nivel de detalle necesario para que no queden dudas, sin llegar a un nivel de complejidad que
dificulte el entendimiento del mismo.
2.1.1. Concepto de Proceso como una plantilla

Si los procesos tienen que ser conocidos por ms de una persona y tienen que ser claros y
entendibles, se debera pensar en una forma estndar de representacin. Si bien cada empresa
puede adquirir una forma de representacin, la que sea ms adecuada, segn las caractersticas
de los RRHH, el contexto y factores como normas de certificacin en calidad de procesos, esto
puede diferir de un lugar a otro.
Las plantillas de procesos definen aspectos claves que ayudan al equipo que se integra a un
proyecto. La plantilla se personaliza de acuerdo al lugar donde se utilice, las caractersticas del
equipo y las normas de calidad a que responden. Una plantilla de proceso puede definir tanto las
actividades de un proceso de negocio como las opciones de seguridad para controlar su proyecto
y el funcionamiento del equipo.
Veamos algunas caractersticas de seguridad:
Definir las plantillas y que estn disponibles en un portal del proyecto.
Definir y exigir las notas de proteccin del control de cdigo fuente, para que no se pierdan
versiones ni estn almacenadas en lugares que no son accesibles por todos los
integrantes del equipo.
Definir los tipos de elemento de trabajo y las consultas disponibles.
Definir los informes para supervisar el progreso y crear un informe de estado.
Definir las iteraciones y las unidades organizativas que se utilizan.

-1-
Si lo que tenemos que representar es un proceso de negocio que tiene que ver con un
requerimiento funcional del sistema, tenemos que plasmarlo en la plantilla de procesos para que
quede documentado.
Qu diferencias existen entre proceso, procedimiento e instructivo?
No todas las empresas e instituciones tienen definidas las tareas necesarias para realizar una
actividad o ms grave an, no tienen el diseo de los procesos fundamentales. Por ejemplo, una
empresa que se dedica a la comercializacin de productos debera tener definido y diseado al
menos los procesos de compra y el de ventas, que son los centrales de su actividad.
Esto depende de la madurez de la empresa y de los empleados, ya que de ellos depende en gran
parte que se cumpla el proceso tal como est definido. Otras tantas empresas tienen establecidas
algunas formas para realizar el trabajo, desde tareas ligeramente organizadas hasta sistemas
enormemente formalizados. Estos mtodos o formas para realizar el trabajo se denominan
procesos.
Los procesos no pueden ser estticos, se van desarrollando a lo largo del tiempo para satisfacer
las necesidades de las empresas y contribuir a la eficiencia en su funcionamiento.
Un proceso est compuesto por macro actividades, las cuales contienen actividades organizadas,
si las actividades son varias y tienen algn orden lgico de ejecucin, alternativas o controles que
realizar, se pueden explotar en Procedimientos. Un procedimiento entonces es un conjunto de
tareas que nos indica qu debemos realizar para que se cumpla eficientemente la macro tarea del
proceso. Por ejemplo, en el Proceso de Venta de Productos, las actividades centrales las
podramos definir como:
1. Cliente: solicita el producto.
2. Vendedor: ofrece el producto
3. Cliente: define si lo compra.
4. Vendedor: realiza la factura.
5. Cliente: abona
6. Empaque: entrega el producto.
La actividad Ofrecer el producto implica una serie de actividades, como fijarse si hay en stock, el
precio, buscarlo, otros. Estas tareas definen el Procedimiento de Ofrecer el producto.
Si para la actividad de Fijarse si hay en stock, el vendedor debe realizar acciones bien definidas,
como por ejemplo, entrar al sistema, cargar el cdigo del producto, fijarse si hay stock libre o
comprometido o si no hay y tomar la decisin de ofrecer o no, es parte del Instructivo. De este
modo, el Instructivo indica cmo se debe realizar una accin de un procedimiento o proceso,
es la mnima expresin, la que tiene mayor detalle.
Plantillas de procesos
Cuando hablamos de plantillas de procesos no nos referimos slo a una sino a varias plantillas.
Estas plantillas indican cmo se configura el proyecto. Cada una de estas plantillas ofrece un
conjunto predeterminado de elementos de trabajo, segn estos, podremos encontrar las plantillas
de procesos, de procedimientos, de instructivos, de documentos, de informes, entre los ms
usados.

-2-
Cmo diseamos una plantilla de proceso?

Entre todas las plantillas que utiliza una empresa, nos centramos en la plantilla de proceso.
Para disear una plantilla de proceso debemos tener en cuenta qu datos debe contener:
Nombre: Un nombre claro que identifique al proceso.

Cdigo: el cdigo normalmente est compuesto por 3 letras, las mismas para todos los
procesos, por ejemplo, PRC (PROCESO), seguido de la nomenclatura que identifique a
cada uno.
Objetivo: determina el objetivo del proceso.
Alcance: qu reas, procesos y roles involucra en el proceso.
Relaciones: Con qu procesos y procedimientos se relaciona, de entrada y de salida.
Documentos asociados: de entrada y de salida
Desarrollo: identifica las actividades a realizar, el orden y quin es el responsable
o Nmero de paso
o Actividad
o Responsable.
Indicadores: son los parmetros o frmulas que se utilizan para poder medir al proceso.
Anexo: Lo que se agrega que aporta ms informacin o grado de detalle para su mejor
entendimiento.
o Glosario: las palabras que necesitan aclarar su significado.
o Grfico: lo que se detall en el desarrollo en forma de Diagrama de flujo o alguna
otra metodologa que permita visualizar el proceso.
Recuerde que la plantilla es el marco para todos los procesos, donde cada registro llena los
campos con lo especfico del proceso que se est diseando.
Control de cambios
Con el uso de los procesos puede ser que necesite realizar algn cambio en la plantilla o en el
proceso; este cambio debe quedar documentado, para ello se establece una plantilla de Control
de cambio donde se deja asentado el documento en el que se est realizando el cambio, el texto
anterior y el nuevo texto.
Este control de cambio es fundamental para tener versionados los documentos y la trazabilidad de
los mismos.
Datos indispensables de la plantilla de Control de cambio:
Proceso.
Documento.
Razn de cambio.
Texto original.
Nuevo texto.
Pgina donde est el texto.
Estos datos se repiten en un mismo documento de Control de cambio por proceso o por
documento, quedando reflejado el historial de cambios.

-3-
Administrador de plantilla de procesos

Todas las plantillas y documentos generados a partir de ellas deben estar almacenadas de forma
tal que permitan la utilizacin de los integrantes del equipo, para ello es conveniente designar un
responsable de dicha tarea, que ser el encargado de la Administracin de la documentacin y
sus cambios.
Complementos de plantilla de procesos
Los complementos de plantilla de procesos son componentes que se ejecutan cuando se crea un
nuevo proyecto de equipo, pueden estar definidos con anterioridad o con el proyecto. Un
complemento instala los archivos necesarios o configura los datos para su rea. Por ejemplo, el
complemento Seguimiento de elementos de trabajo configura tipos de elemento de trabajo,
consultas y elementos de trabajo iniciales para un nuevo proyecto.
En general podemos encontrar los siguientes datos de los complementos de procesos:
Complemento de
plantilla de procesos
Descripcin
Clasificacin
Define las iteraciones y las reas iniciales de un proyecto y del

equipo.
Grupos y permisos
Define los grupos de seguridad iniciales de los integrantes del

equipo de proyecto y sus permisos.
Herramienta a utilizar
Define las herramientas a utilizar para los complementos

diseados
Seguimiento de
elementos de trabajo
Define los tipos de elemento de trabajo iniciales de un proyecto,

consultas e instancias del elemento de trabajo.
Informes
Define los informes iniciales de un proyecto y configura el lugar de

almacenamiento del informe.
Control de versiones
Define los permisos de seguridad de control de versiones iniciales

de un proyecto y los cambios realizados en los documentos.
Archivos de definicin de procesos

Los archivos de definicin de procesos son un conjunto de archivos que definen un agregado de
tareas que deben ejecutarse para llevar a cabo una funcin especfica. En el caso del proceso de
desarrollo de software, se emplean los archivos de procesos, de procedimientos, de instructivos,
control de cambio y toda aquella documentacin que se defina en cada etapa del proceso.
2.1.2. Concepto de actividades y etapas o flujos de trabajo

Cuando se realiza cualquier trabajo se piensa en las actividades o tareas que se deben realizar
para lograr el objetivo planteado y cmo podemos organizar estas actividades o tareas,

-4-
normalmente en etapas. Pero nos detenemos a pensar previamente, en cul es la diferencia que
existe entre tarea y actividad.
Veamos primero qu nos dice la Real Academia Espaola sobre estos significados.
Actividad:
1. f. Facultad de obrar.
2. f. Diligencia, eficacia.
3. f. Prontitud en el obrar.
4. f. Conjunto de operaciones o tareas propias de una persona o entidad.
Tarea:
1. f. Obra o trabajo.
2. f. Trabajo que debe hacerse en tiempo limitado.
Etapa:
3. f. Fase en el desarrollo de una accin u obra.
Accin:
1. f. Ejercicio de la posibilidad de hacer.
2. f. Resultado de hacer.
Como se puede apreciar, todos los trminos hacen referencia a realizar un trabajo, slo que en
diferentes grado de detalle o generalizacin. No es necesario filosofar sobre los conceptos de
accin y tarea, las dos llevan a la concrecin de una actividad.
De las definiciones de la Real Academia Espaola rescato los siguientes conceptos:
Actividad: Conjunto de operaciones o tareas propias de una persona o entidad, nos indica que
la actividad est compuesta por varias tareas, por ejemplo, la actividad realizar un dibujo,
implicar ver cules son las tareas o acciones que debe realizar para lograr el objetivo.
Tarea: Trabajo que debe hacerse en tiempo limitado. Esta definicin aporta el concepto de tiempo
asociado a la tarea, lo que indica que una tarea no puede disponer de infinito tiempo, nos sugiere
el concepto de eficiencia, tarea realizada en tiempo y forma.
Si la actividad lleva asociada un conjunto de numerosas a tareas, es conveniente organizarla de
forma que se vallan cumpliendo etapas. Estas etapas representan un flujo de trabajo.
Flujo de trabajo es el estudio de los aspectos operacionales de una actividad de trabajo.
Qu es Workflow?
Se define Workflow al flujo de trabajo a seguir para la consecucin de una tarea o trabajo
predeterminado. El flujo de trabajo determina cmo se estructuran las tareas, cmo se realizan,

-5-
cul es su orden correlativo, cmo se sincronizan, cmo fluye la informacin que soporta las
tareas y cmo se le hace seguimiento al cumplimiento de las tareas.
Tambin se puede definir como un sistema de secuencia de tareas de un proceso de negocio.
Su definicin y control puede ser manual, informatizado o mixto. Organiza y controla tareas,
recursos y reglas necesarias para completar el proceso de negocio.
Las nuevas tendencias en la regulacin de las organizaciones, hacen del Workflow una
herramienta clave para lograr mayor agilidad y aumentar la descentralizacin de las actividades
administrativas y comerciales.
La importancia del Workflow consiste en buscar la mxima automatizacin de los procesos de
trabajo y el control total de las diferentes etapas, durante las cuales los documentos, la
informacin o las tareas pasan de un participante a otro, o sea de un rol a otro, segn unas
normas o procedimientos previamente definidos.
En estos ltimos aos, se han ido desarrollando diversas aplicaciones de software, muchas de
ellas han evolucionado a partir de sistemas de gestin, ya sea de imagen, sistemas de gestin de
documentos, sistema de gestin administrativa, gestin comercial, sistemas de correo electrnico
o de bases de datos.
Comparemos ahora los sistemas tradicionales con los sistemas basados en Workflow:
Objetivos Sistemas de Informacin tradicional:
Mejorar la productividad
Aumentar la calidad del trabajo
Reducir costes
El mbito de un Sistema de Informacin tradicional est determinado por:
Modelo de datos
Funciones independientes.
La principal limitacin asociada a los Sistemas de Informacin (S.I.) tradicionales es que, no
contemplan los procedimientos, organizacin y mtodos de trabajo del sistema real.
Cuando las organizaciones no cuentan con el estudio de los procedimientos organizativos se
derivan los siguientes problemas:
Necesidad de adaptar los procedimientos organizativos al sistema de informacin
Posibilidad de conflicto entre los procedimientos organizativos y los mdulos funcionales
Falta de control sobre las actividades de la organizacin como un todo.
Recordemos que una aplicacin de Flujos de Trabajo (Workflow) permite automatizar la
secuencia de acciones, actividades o tareas utilizadas para la ejecucin del proceso, incluyendo el
seguimiento del estado de cada una de sus etapas y la aportacin de las herramientas necesarias
para su gestin.
Los objetivos de un sistema de Workflow son:
Reflejar, automatizar y mecanizar los mtodos y su organizacin en el sistema de
informacin
Establecer los mecanismos de control y de seguimiento de los procedimientos
organizativos

-6-
Independizar el mtodo y flujo de trabajo de las personas que lo ejecutan

Soportar procesos de reingeniera de negocio
Dentro del Workflow se pueden distinguir tres tipos de actividades:

Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio
de datos para obtener un resultado comn.
Actividades cooperativas: Un conjunto de usuarios trabajan sobre su propio conjunto
particular, estableciendo los mecanismos de cooperacin entre ellos. El trabajo individual
es visto desde el punto de vista global del resultado final.
Actividades de coordinacin: se establece cmo ser el trabajo cooperativo entre los
individuos.
Veamos una imagen que representa al Workflow, sus elementos y relaciones:
Para implementar un trabajo basado en Workflow es necesario reconocer sus elementos de

trabajo:
Infraestructura necesaria, para lograr el ambiente colaborativo, para ello es necesario:

o Establecer una comunicacin mediante herramientas de mensajera electrnica
o Un entornos de trabajo con informacin y recursos compartidos
o Una herramienta global que permita la coordinacin de ambos entornos de trabajo
Contar con tecnologas necesarias que faciliten el trabajo:
o Es necesario contar con un contenedor dinmico de objetos
o Modelo de acceso y distribucin de la informacin
o Infraestructura para el desarrollo de aplicaciones y procesos de negocio, que puede
ser una herramienta que integre los recursos externos y las aplicaciones
interempresariales.
Veamos ahora los elementos constitutivos de ambos sistemas.

Elementos S.I. tradicional:
Entidades, Funciones, Flujos de datos, Tablas, Mdulos, Columnas, entre otros.

-7-
Elementos S.I. Workflow:

Procesos, conjunto de actividades organizadas.
Rutas, secuencia de las actividades.
Reglas, tanto de negocio como de los procedimientos o las que se establezcan como
necesarias.
Roles, no como cargos funcionales sino como actor de una actividad
Polticas, que pueden ser de seguridad o del tipo de empresa o institucin.
En la actualidad existen herramientas de software que contemplan el trabajo bajo el modelo de
Workflow. Veamos en una grfica lo que cuentan estas herramientas.
2.1.3. Componentes del proceso

Se entiende por componente al elemento que compone o entra en la composicin de un todo.
Los procesos estn compuestos por elementos, entre los ms importantes identificamos a:
las acciones,
las personas responsables de realizar las acciones,
los materiales,
equipamiento,
procedimientos,
Documentacin.
Todos los componentes del proceso son igualmente importantes, aunque la actividad y quien la
realiza parecen ser fundamentales, sin estos componentes no tenemos proceso alguno.
2.1.4. Procesos especializados

Los procesos definen el funcionamiento interno de una empresa o institucin; dentro de los
procesos de negocio se pueden identificar los procesos centrales, tambin llamados procesos
claves, los procesos estratgicos, los de la alta gerencia y los de apoyo, aquellos que acompaan
a los procesos centrales.

-8-
Por ejemplo, una empresa que se dedica a la comercializacin de productos, tendr como proceso
clave el de ventas, mientras que de apoyo puede ser el proceso de despacho o el administrativo.
Todo proceso tiene un inicio y un fin, puede decirse que el proceso de venta finaliza cuando el
cliente compr el producto solicitado. Pero ya hace unos aos que ha cobrado mucha importancia
el cliente y la relacin con la empresa; si se quiere atender a la calidad de la atencin al cliente es
conveniente ver el lmite del proceso ms all del momento de la facturacin y su partida, cobra
importancia el servicio de post venta, lo que implica un seguimiento considerando que el cliente
queda en relacin con la empresa.
Este tipo de proceso que se especializa puntualmente en algo, es considerado proceso
especializado, como lo es un CRM (Customer Relationship Management o en espaol,
Gerenciamiento Relacionado al Cliente.)
En todas las disciplinas existen Procesos especializados, es muy importante detectarlos y
tratarlos como tal, es decir, ser especialistas en una cosa, esto es lo que no se debe perder.
2.1.5. Cmo se construye un proceso de desarrollo de software?

Un proceso de desarrollo de software se construye a partir de los lineamientos de la teora de
procesos, la cual puede incluir la visin de Workflow.
Recordemos los conceptos que vio en el Mdulo 1, sobre Proceso de desarrollo de software.
Definicin: Conjunto estructurado de actividades para desarrollar un sistema de software. Estas
actividades varan dependiendo de la organizacin y el tipo de sistema que debe desarrollarse.
Debe ser explcitamente modelado si va a ser administrado.
Pilares en el desarrollo de software
PROCESO
PERSONAL
Participante
Plantilla
HERRAMIENTAS
PROYECTO
Automatizacin
Resultado
PRODUCTO
Qu se espera de un proceso de software?

De un proceso de software se espera que sea capaz de evolucionar y que durante su evolucin se
limite por:

-9-
la tecnologa
las herramientas
la gente
los patrones organizacionales
El proceso de software debera comportarse de una manera definida y dinmica, permitiendo:
Utilizarse con una variedad de ciclos de vida.

Seleccionar los artefactos a producir.
Definir actividades y personas participantes.
Modelar conceptos.
Cul es el criterio que se debe tener para definir un proceso de desarrollo de software?
En la definicin de un proceso de desarrollo de software se identifican elementos del proceso que
responden a una pregunta bien definida, veamos algunos de los elementos ms importantes del
proceso:
Propsito,
Por qu se realiz el proceso?
Entrada,
Qu productos de trabajo se utilizan?
Salida,
Qu productos de trabajo se generan?
Rol,
Quin o qu realiza la actividad definida en el proceso?
Actividad,
Qu se hace?
Criterio de entrada, Cundo puede iniciarse el proceso?
Criterio de salida,
Cundo puede considerarse un proceso completo?
Procedimiento,
Cmo son implementadas las actividades?
2.1.6. Cmo se adapta un proceso de desarrollo a un proyecto real?

Todo proyecto que se genera en el mbito profesional responde a una situacin particular, dada
en un contexto y una realidad. Si el proyecto tiene como objetivo obtener un producto de software,
entonces tiene asociado el proceso de desarrollo de software.
Cada proyecto es nico, aunque sea semejante a otro, siempre posee alguna caracterstica o
regla que lo diferencia de otro, no obstante el proceso de desarrollo ya est definido y puede
aplicarse a cualquier proyecto. Para ello tiene que permitir elegir cualquier metodologa
relacionada con los distintos ciclos de vida, por lo cual se basa en las actividades bsicas
definidas en el proceso.
Actividades del proceso de desarrollo de software
Las cuatro actividades o etapas bsicas del proceso se organizan de forma distinta en diferentes
procesos, estas actividades son:
Especificacin
Desarrollo
Validacin y
Evolucin.
En el enfoque en cascada se organizan de forma secuencial, mientras que en el desarrollo
evolutivo se entrelazan, esto depende del tipo de software, de las personas y de la estructura
organizacional implicada, expresa Sommerville, (Ingeniera de Software, Pg. 84)

- 10 -
Etapa de especificacin del software

Esta etapa, por ser la primera, es muy importante, es el proceso de comprensin del problema y
definicin de los servicios que requiere el sistema, como as tambin la identificacin de las
restricciones de funcionamiento y de desarrollo.
En esta etapa no slo se realiza la captura de los requerimientos, sino que tambin se realiza el
anlisis de los mismos.
Los contenidos de esta etapa se profundizarn en el mdulo 3.
Existen 4 fases principales en el proceso de Ingeniera de requerimientos:
1- Estudio de viabilidad, se estima si las necesidades del cliente se pueden satisfacer.
2- Obtencin y anlisis de requerimientos, se utilizan distintas tcnicas de recoleccin de
datos e informacin, que luego es analizada.
3- Especificacin de requerimientos, se describe la lista de requerimientos en un
documento.
4- Validacin del requerimiento, se comprueba si es correcta la lista de requerimientos con
el cliente.
Etapa de diseo e implementacin del software
La etapa de implementacin del software incluye a los procesos de diseo y construccin del
software, ya que es el proceso de convertir una especificacin del sistema en un sistema
ejecutable.
Esta etapa vara segn el enfoque de ciclo de vida adoptado, por ejemplo, en un enfoque en
cascada se implementar un ejecutable que contiene el total de las especificaciones diseadas y
programadas, mientras que en un enfoque evolutivo implicar un refinamiento de las
especificaciones del software.
Diseo
La actividad de diseo involucra a los datos, subsistemas, componentes e interfaces, tanto
internas como externas que requiere la especificacin de los requerimientos.
Las actividades especficas del proceso de diseo son:
1- Diseo arquitectnico, intervienen los subsistemas y componentes que forman el sistema
y sus relaciones, identificndolas y documentndola.
2- Especificacin abstracta, se abstraen los servicios y restricciones bajo las cuales debe
funcionar el sistema.
3- Diseo de interfaz, para cada subsistema se disea y documenta su interfaz con otros
subsistemas. Tambin se disean los prototipos de interfaz con el usuario.
4- Diseo de componentes, se asignan servicios a los componentes y se disean sus
interfaces.
5- Diseo de la estructura de datos, se disea la base de datos a utilizar y la relacin con
las estructuras ya existentes.
6- Diseo de algoritmos, se realiza el diseo detallado de los algoritmos a utilizar.
Esta definicin de actividades vara dependiendo de la metodologa que se est utilizando, en un
modelo muy estructurado aparecern todas, haciendo el proceso muy pesado en cuanto a
tiempos de documentacin, mientras que en metodologas giles, ms livianas, la documentacin

- 11 -
disminuye y las algunas actividades se elimina, como por ejemplo, la especificacin abstracta y el
diseo de algoritmos.
Desarrollo
La actividad de desarrollo sigue naturalmente a la etapa de diseo. El desarrollo del software es el
proceso de codificacin en un lenguaje de computacin, de los requerimientos definidos,
analizados y diseados.
Al programador le llega la documentacin de los requerimientos y es su responsabilidad
transformarlos en un programa ejecutable.
Al finalizar su programacin es necesario que realice la comprobacin de su funcionamiento, es
decir, el chequeo de que su trabajo est bien realizado, que el programa funciona correctamente y
que cumple con las especificaciones, o sea verifica los requerimientos, que no se hayan
efectuados cambios.
Este es el momento en que se pueden encontrar errores, es el mismo programador el que los
depura hasta llegar a una versin confiable.
Las herramientas CASE se pueden utilizar para generar un programa esqueleto a partir del
diseo, esto incluye cdigo para definir e implementar las interfaces, necesitando el programador
solo agregar detalles de cdigo.
Etapa de Validacin del software
La validacin del software es la etapa en la que se realizan comprobaciones. En general se
conoce como V & V, verificacin y validacin, se utiliza para mostrar que el sistema se ajusta a su
especificacin y que cumple las expectativas del cliente.
Esta etapa implica procesos de comprobacin de requerimientos, en el seguimiento de las etapas.
Este proceso se puede realizar al final del proceso de desarrollo o bien despus de cada etapa,
como lo muestra el modelo V.
Las etapas del proceso de prueba son:

1- Prueba de componentes, se prueban los componentes individuales para verificar que
funcionan correctamente.
2- Prueba del sistema, se realiza la prueba del sistema integrando todos los componentes.
Se realizan todos los tipos de pruebas de acuerdo a lo planificado en el proyecto, adems

- 12 -
de la validacin para comprobar que el sistema cumple con los requerimientos funcionales
y no funcionales definidos en la etapa de especificacin.
3- Prueba de aceptacin, parte final del proceso donde se prueba con los datos
proporcionados por el cliente, antes de su aceptacin final.
Etapa de evolucin del software
Una vez entregado el producto de software al cliente se comienza a usar; esta etapa es muy
importante ya que el cliente se dar cuenta si hay algn requerimiento para refinar, agregar o
cambiar, estos sucesos hacen a la evolucin del software.
Si el software informatiza los procesos de negocio y estos son dinmicos es lgico pensar que el
software tambin debe serlo, es por ello que habr cambios en el software.
Es la etapa lleva ms tiempo en el proceso de desarrollo de software, porque se mantiene en el
tiempo. El problema de esta etapa es que muchas veces se confunde mantenimiento de la
evolucin del software con mantenimiento de arreglo de errores del software.
Si el software fue entregado al cliente con errores significa que no cumpli con las etapas del
proceso correctamente, sobre todo la de prueba de software, lo cual lleva a muchos problemas:
Cliente desconforme
Producto que no es de calidad
Tiempo perdido en recodificacin del software
Gasto operativo que se incrementa sin poder medir las prdidas
No se puede cobrar al cliente el costo de la resolucin de errores.
Nuevamente crisis del software.
Hagamos un breve resumen de los contenidos aprendidos hasta aqu.
Los temas tratados en este Mdulo tienen que ver directamente con la Ingeniera de software y su
relacin con los procesos.
Hemos visto el concepto de proceso desde la visin del negocio y del proceso de desarrollo de
software, con un enfoque tradicional y desde el enfoque de Workflow.
Tenga en cuenta los puntos clave que remarcamos a continuacin:
Todos los procesos representan algn flujo de trabajo que implica actividades
organizadas de algn modo con personas responsables de ejecutarlas.
Los flujos de trabajo como Workflow representan mejor la realidad de los procesos, dan
una vista horizontal del mismo, con lo que un actor no es slo responsable de su
actividad, sino que es responsable del proceso, en cuanto que hay otro actor que
depende de que su actividad est resuelta satisfactoriamente.
Los procesos de software son las actividades relacionadas con la produccin de un
sistema de software.
Todos los procesos de software incluyen las etapas fundamentales: especificacin,
implementacin, prueba y evolucin.
La validacin y verificacin de los requerimientos es necesaria para que el producto de
software a entregar cumpla con las expectativas del cliente.

- 13 -
2.2 El Proceso Unificado de Desarrollo de Software

Es un entorno de proceso genrico (Framework) que puede especializarse para una gran variedad
de sistemas de software, en diversas reas de aplicacin, distintos tipos de organizacin y de
tamaos de proyectos.
Proceso Unificado de Desarrollo de Software est asociado con El Proceso Unificado de
Racional (RUP) que es un ejemplo de modelo de proceso moderno que proviene del UML
(Lenguaje de Modelado Unificado).
El Proceso Unificado de Racional

El Proceso Unificado de Racional rene elementos de todos los modelos de procesos genricos,
iteraciones de apoyo y utiliza buenas prcticas en la especificacin y el diseo.
El RUP, a diferencia de los procesos genricos que presentan un solo enfoque, se describe desde
3 perspectivas:
1- Desde una perspectiva dinmica que muestra las fases del modelo en el tiempo.
2- Desde una perspectiva esttica que muestra las actividades del proceso.
3- Desde una perspectiva prctica que sugiere buenas prcticas a utilizar durante el proceso.
El RUP es un modelo en fases que identifica cuatro fases diferentes en el proceso de software
relacionadas con asuntos de negocio:
1. Inicio, su objetivo es establecer un caso de negocio para el sistema, identificando todas
las entidades externas, ya sean personas y/o sistemas, que interactan con el sistema y
determinar cmo se presentan dichas interacciones. Esta fase presenta lo que el sistema
aporta al negocio.
2. Elaboracin, su objetivo es presentar el dominio del sistema, establecer un marco de
trabajo arquitectnico, desarrollar el plan del proyecto e identificar los riesgos. Finalizada la
fase se debe contar con un plan de proyecto, la especificacin de requerimientos, los
casos de uso y una descripcin arquitectnica.
3. Construccin, esta fase comprende el diseo a programacin y las pruebas del sistema,
integrando las partes y obteniendo un sistema de software operativo y su documentacin.
4. Transicin, esta fase comprende la actividad de instalar el sistema en un entorno real
para su uso, es decir que pasa del entorno del programador al del usuario final.
Como no se cuenta con el 100% de los requerimientos, estas fases se presentan de forma
iterativa e incremental.
La vista esttica se centra en las actividades que realizan en la etapa de desarrollo,
denominndose flujos de trabajo, apoyados por los diagramas de UML.
La vista dinmica acompaa a la esttica presentando os flujos de trabajo en el tiempo, haciendo
que ambas no estn asociadas a flujos de trabajo especficos.
Las buenas prcticas que presenta RUP
El RUP recomienda seis buenas prcticas de la Ingeniera del software en el desarrollo de
sistemas:

- 14 -
1. Desarrolle el software de forma iterativa, planificando incrementos del sistema

basados en las prioridades del usuario, desarrollando y entregando las
funcionalidades de mayor prioridad al inicio del proceso de desarrollo.
2. Gestione los requerimientos, documentndolos debidamente, estando al tanto de
los cambios y analizando los impactos que estos cambios tienen en el sistema.
3. Utilice arquitecturas basadas en componentes, identificando aquellos componentes
que puedan ser reusables.
4. Modelo de forma visual el software, para ello utilice los diagramas de UML de la
vista esttica y dinmica.
5. Verifique la calidad del software, en cada etapa verifique que cumpla con las
especificaciones de las etapas anteriores y los estndares de calidad.
6. Controle los cambios del software, manteniendo las versiones, los procedimientos y
la debida gestin de configuracin.
UML y el Proceso Unificado de Desarrollo de Software
Cuando Ivar Jacobson, Grady Booch y James Rumbaugh decidieron unir sus modelos de anlisis
y diseo orientado a objetos determinando el Lenguaje Unificado de Modelado, lo hicieron
pensando que los diagramas apoyaran al proceso de desarrollo de software, es por ello que se
cuenta con dos libros, el de UML y el de El Proceso Unificado de desarrollo de Software, donde
presentan los artefactos de UML y cmo apoyan al proceso.
En esta etapa de la materia haremos referencia a los diagramas de UML, pero no los
desarrollamos ya que usted los conoce, en caso de no recordarlos sugerimos reforzar los
conocimientos con la lectura del libro de UML.
El Proceso Unificado est basado en componentes, por lo que el software est sustentado en
componentes de software interconectados a travs de interfaces.
No hay un proceso universal, el Proceso Unificado est diseado para la flexibilidad y la
extensibilidad dadas por las siguientes caractersticas:
Permite una variedad de ciclos de vida.
Selecciona qu artefactos producir.
Define las actividades y sus actores.
Modela conceptos.
La estructura del proceso se puede representar de la siguiente forma:
Ya hemos presentado las definiciones de proceso, trabajador o rol, Workflow y actividad, slo
resta definir qu es un artefacto.

- 15 -
Un Artefacto, es una pieza de informacin que es producida, modificada o usada por un proceso.
2.2.1 Caractersticas del Proceso de Desarrollo Unificado (Conducido

por Use cases, Centrado en la Arquitectura, Iterativo e Incremental)
El Proceso Unificado presenta aspectos que se deben tener en cuenta a la hora de aplicar su
modelo, ya que marcan el proceso, estos aspectos se resumen en tres fases claves:
Dirigido por casos de uso
Centrado en la arquitectura
Iterativo e incremental.
Dirigido por casos de uso:
Un caso de uso (UC) es un fragmento de funcionalidad del sistema que proporciona al usuario un
resultado importante. Estos casos de uso representan los requisitos funcionales, todos los casos
de uso juntos constituyen el Modelo de casos de uso, el cual describe la funcionalidad total del
sistema.
Una funcionalidad del sistema debe responder a la pregunta qu debe hacer el sistema?, cuando
lo planteamos como caso de uso la pregunta es qu debe hacer el sistema para cada usuario?
Con esta pregunta no slo identificamos la funcionalidad, sino que tambin identificamos el actor
responsable del UC.
Los UC no slo representan las funcionalidades, tambin guan el proceso de desarrollo, ya que
los analistas, abordan las funcionalidades, los diseadores efectan las interfaces y la arquitectura
de datos que la soporte, los programadores lo convierten en cdigo ejecutable, los prueban e
implementan para que los usuarios lo puedan utilizar y comprobar si cumplen con lo especificado,
satisfacen sus necesidades y cubren sus expectativas.
Centrado en la arquitectura
La arquitectura en un sistema de software es anloga a la arquitectura de un edificio, se describe
mediante diferentes vistas del sistema en construccin, incluye los aspectos estticos y dinmicos
del sistema.
La arquitectura surge de la visin del cliente, de sus necesidades y se refleja en los casos de uso,
no obstante existen otros factores que influyen en la arquitectura, entre los ms importantes
podemos citar:
La plataforma donde debe funcionar
Los componentes reutilizables de que se dispone
Sistemas heredados
Requisitos no funcionales
La arquitectura es una vista de diseo completo con las caractersticas ms importantes que deja
los detalles de lado. La actividad de diseo permite al arquitecto centrarse en los objetivos
adecuados, como son:
La comprensibilidad
La capacidad de adaptacin al cambio
La reutilizacin.

- 16 -
La arquitectura no es independiente de los casos de uso, estn interrelacionados, ya que cada

producto consta de una funcin y una forma, donde la funcin corresponde a los casos de uso y la
forma a la arquitectura. Estas dos fuerzas deben equilibrarse para lograr un producto con xito.
La arquitectura debe permitir el desarrollo de todos los casos de uso, pero adems ambos deben
evolucionar en paralelo y permitir que el sistema evolucione y soporte los cambios de
requerimientos.
Se aconseja que el arquitecto trabaje sobre los casos de uso claves, los que representan entre el
5 y el 10% del total de las funcionalidades del sistema, son los ms significativos y complejos,
luego escala hacia el total de los UC.
El proceso es Iterativo e Incremental
Normalmente los proyectos son de magnitud y llevan meses, quizs un ao o ms de trabajo. En
estos casos es conveniente dividir el trabajo en partes ms pequeas o miniproyectos. Cada
miniproyecto es una iteracin que resulta que resulta en un incremento. Las iteraciones hacen
referencia a los pasos del flujo de trabajo y los incrementos, al crecimiento del producto.
Es comn tener el problema del incremento sin medida, por lo que es conveniente tener bien
definidos los alcances de cada miniproyecto, con iteraciones controladas por la planificacin para
obtener una efectividad mxima.
Los desarrolladores basan la seleccin de lo que se implementar en una iteracin, en dos
factores:
Un conjunto de UC que juntos amplan el producto.
Una nueva iteracin se construye sobre los artefactos de desarrollo tal como quedaron en
la iteracin anterior.
En cada iteracin se dan las mismas fases que en el Proceso Unificado, por lo que los
desarrolladores identifican y especifican los UC relevantes, crean un diseo utilizando la
arquitectura seleccionada como gua, implementan el diseo mediante componentes y verifican
que estos componentes verifiquen los casos de uso.
Cuando una iteracin cumple con su objetivo se sigue con la siguiente iteracin. Si la iteracin no
cumple con su objetivo se debe revisar y encontrar el error que, si se realizaron las validaciones
correspondientes, slo podra estar de la ltima etapa. En caso de error los desarrolladores deben
revisar sus decisiones previas y probar con otro enfoque.
Recordemos las fases del proceso iterativo e incremental con la grfica que lo representa:

- 17 -
La grfica del ciclo de vida nos muestra el esfuerzo de cada fase con los flujos de trabajo
relacionados en cada una de ellas. Tambin se tienen en cuenta los flujos de trabajo de soporte,
los cuales acompaan a todas las fases, como son la gestin de cambio y configuracin, la
gestin de proyectos y el entorno de trabajo.
Cmo sabemos que es un ciclo iterativo e incremental?
Para determinar si es un ciclo iterativo e incremental se deben reconocer las caractersticas a
cumplir:
Es planificado y controlado.
Es predicable
Acomoda los cambios a los requerimientos con menos alteraciones.
Est basado en prototipos ejecutables que evolucionan, no en la documentacin.
Involucra a clientes y usuarios a lo largo del proceso.
Es conducido por los riesgos.
2.2.2 Persona, Proyecto, Producto y proceso en el Desarrollo de

Software
El resultado final de un proyecto de software es un producto que va tomando forma durante el
proceso gracias a la intervencin de muchos tipos distintos de personas, cada una tiene su nivel
de esfuerzo y con un flujo de trabajo asociado.
Las cuatro P en el proceso de desarrollo de software son:
Personas, las personas son seres humanos con distintas funciones dentro del proceso.
Los principales actores del proyecto son: los analistas, los arquitectos, los programadores,
los ingenieros de pruebas, los encargados de la gestin de soporte, los clientes y usuarios.

- 18 -
Proyecto, es el elemento organizativo a travs del cual se gestiona el desarrollo de

software que tiene como resultado una versin de un producto.
Producto, son los artefactos que se crean durante la vida del proyecto, el cdigo
ejecutable, los modelos y la documentacin.
Proceso, es la definicin de un conjunto de actividades necesarias para transformar los
requisitos de usuario en producto.
Adems se necesita contar con las herramientas necesarias para automatizar las actividades
definidas en el proceso.
2.2.3 Conceptos bsicos en el proceso unificado y de los workflows

del Proceso
Ya hemos tratado todos los conceptos bsicos necesarios para poder integrar el proceso unificado
con los Workflow, para lograr una visin general y particular del proceso de desarrollo de software.
El proceso unificado produce modelos durante su desarrollo, estos modelos son:
1- Modelo de negocio
2- Modelo de dominio
3- Modelo de casos de uso
4- Modelo de anlisis
5- Modelo de diseo
6- Modelo de proceso
7- Modelo de despliegue
8- Modelo de implementacin
9- Modelo de prueba.
Veamos la relacin que existe entre el Workflow y los modelos a travs de la siguiente grfica:

- 19 -
En la grfica anterior se identifican los Workflow que son parte del proceso unificado:
Modelo de negocio
Requerimientos
Anlisis
Diseo
Implementacin
Prueba.
Cada uno de ellos ha sido definido con anterioridad en este Mdulo.
Si relacionamos estos Workflow con el ciclo de vida, identificamos los flujos de trabajo en detalle
necesarios para cada uno de los planteados en dicho ciclo, como son:
Workflow de captura de requerimientos, tienen como objetivo lograr la lista de

requerimientos, para ello se deben realizar actividades que estn relacionadas con los
modelos o artefactos resultantes:
o Listar los requerimientos necesarios, se obtiene la Lista de Aspectos.
o Comprender el contexto del sistema, se obtiene el modelo de negocio y el modelo
de dominio.
o Capturar requerimientos funcionales, se obtiene el modelo de casos de uso
o Capturar requerimientos no funcionales, se obtienen los requerimientos
complementarios para los UC especficos del sistema.
La captura de requerimientos se realiza en las cuatro fases del proceso unificado, siendo de
mayor cantidad de trabajo en las dos primeras, o sea, en las fases de inicio y elaboracin.
Workflow de anlisis, tiene como objetivo realizar el anlisis de los requerimientos, sus
ventajas son:
o Permite una especificacin ms precisa de los requerimientos.
o Se describe en lenguaje tcnico, del programador.
o Le da estructura a los requerimientos.
o Puede verse como un primer corte de los requerimientos.
El anlisis se realiza en las tres primeras fases del proceso, o sea, inicio, elaboracin y
construccin obteniendo las clases de anlisis y el modelo de anlisis.
Workflow de diseo, su objetivo es obtener el diseo completo del sistema para lograr:
o Una comprensin completa de los requerimientos y sus restricciones.
o Refinar los requerimientos obteniendo clases e interfaces individuales
o Descomponer el trabajo de implementacin en piezas entendibles y manejables
por distintos actores del proceso.
o Capturar las interfaces de relacin entre sistemas.
o Crear una abstraccin de la implementacin del sistema.
El diseo se presenta en las fases de inicio, elaboracin y construccin, incluyendo el anlisis

arquitectnico que proporciona un documento de arquitectura del software, construye el modelo
de diseo y disea la persistencia obteniendo como resultado el modelo de datos y su
persistencia.
Workflow de implementacin, su objetivo es lograr la implementacin de un producto

ejecutable, para ello se realizan las siguientes actividades:

- 20 -
o
o
o
o
o
Se planean las implementaciones de cada iteracin.

Se distribuyen los componentes en los nodos donde se implementan, por ejemplo,
la base de datos en el servidor de datos y las aplicaciones en el servidor de
aplicaciones.
Se implementa el diseo de clases y subsistemas.
Se realiza las primeras pruebas de unidad de componentes.
Se realiza la integracin de los componentes en un ejecutable.
La actividad de implementacin se relaciona con las fases de elaboracin, construccin y

transicin.
Workflow de prueba, su objetivo es probar el producto final garantizando que es de calidad,

para ello realiza las siguientes tareas:
o Realiza la planificacin de las pruebas necesarias para cada iteracin.
o Disea e implementa las pruebas, diseando los casos de uso de prueba.
o Realiza los test necesarios, documentando los resultados.
o Automatiza los test de prueba que puedan ser reutilizados.
Las pruebas se realizan en las cuatro fases, garantizando que cada una de ellas cumple con los
objetivos de calidad y con los requerimientos del cliente.
Para ampliar sobre los contenidos de esta lectura sugerimos recurrir al texto de Jacobson, Booch
y Rumbauch, El Proceso unificado de Desarrollo de Software, parte I y II, captulos 1 al 11
inclusive (bibliografa bsica).

- 21 -
HACIA UNA ONTOLOGA PARA FBRICAS DE SOFTWARE

Kenyer Domnguez1
Mara A. Prez2, Luis E. Mendoza2 y Anna Grimn2
RESUMEN
Actualmente se est retomando el concepto de Fbricas de Software (FS) donde la reutilizacin juega un rol
protagnico. Debido a la existencia de visiones diferentes en el rea y a pesar de que el concepto de FS no es nuevo en
la Ingeniera de Software, an no se cuenta con la madurez conceptual necesaria como para identificar claramente el
tratamiento de ciertas variables dentro del proceso. Por ello, en este artculo se realiza una revisin histrica del
concepto FS y se propone una ontologa basada en las definiciones ms recientes. Este artculo forma parte de una
investigacin en progreso que pretende precisar la calidad sistmica en compaas desarrolladoras de software que
decidan implantar una FS.
Palabras Claves: Fbricas de Software, ontologa, reutilizacin, mejores prcticas.
1. INTRODUCCIN
Dado los exigentes requerimientos en el cumplimiento

de tiempos y presupuestos que las empresas
desarrolladoras de software viven constantemente, la
eficiencia en el proceso de desarrollo se ha constituido
en una necesidad creciente. Sin embargo, sta es una
variable que no necesariamente propicia su
efectividad. 1
Es por ello que la reutilizacin en el proceso de
produccin de software ha sido foco de inters desde
hace algn tiempo, sin obtener xitos reales.
Actualmente, los desarrolladores crean aplicaciones
desde cero por medio del uso de herramientas
genricas, procesos adecuados y arquitecturas
personalizadas; una prctica que consume mucho
tiempo y que da lugar a errores. 2
Consciente de esta realidad, algunas organizaciones
han establecido diversas estrategias de trabajo e
incluso han agrupado las mejores prcticas en esta
materia con el fin de industrializar el desarrollo de
software. Es por ello que actualmente se est
retomando el concepto de Fbricas de Software (FS)
donde la reutilizacin juega un rol protagnico.
Debido a la existencia de visiones diferentes en el rea
1
Decanato de Investigacin y Desarrollo, Universidad Simn

Bolvar. Apartado Postal 89000, Caracas 1080-A. Caracas Venezuela. E-mail: kdoming@usb.ve
2
Laboratorio de Investigacin en Sistemas de Informacin (LISI),
Departamento de Procesos y Sistemas, Universidad Simn
Bolvar. Apartado Postal 89000, Caracas 1080-A. Caracas Venezuela. E-mail: movalles@usb.ve, lmendoza@usb.ve y
agriman@usb.ve.
y a pesar de que el concepto de FS no es nada nuevo en

la Ingeniera de Software; an no se cuenta con la
madurez conceptual necesaria, como para identificar
claramente el tratamiento de ciertas variables dentro del
proceso, una de ellas es la calidad.
En este artculo se pretende establecer una ontologa que
permita entender las diferentes acepciones del concepto
FS, as como las caractersticas, innovaciones e
implicaciones de las visiones ms recientes de FS en el
mbito de la Ingeniera del Software. Este artculo
forma parte de una investigacin en progreso que busca
estimar la calidad sistmica en compaas
desarrolladoras de software que decidan implantar una
FS.
A continuacin se presentan los antecedentes de esta
investigacin, luego se describe la metodologa, para
luego dar una descripcin de cada uno de los conceptos
involucrados a medida que se muestra la representacin
grfica de los elementos resaltantes, finalmente se
muestra el modelo conceptual integrado y se proponen
las conclusiones y recomendaciones.
2. ANTECEDENTES
En la Ingeniera del Software se han hecho muchos

intentos para solventar la ausencia de un proceso de
desarrollo bien definido y bien gerenciado que afecta,
tanto a los desarrolladores como a usuarios y clientes, al
no obtener el producto deseado dentro del tiempo y los
costos estimados. La aplicacin de un modelo de FS es
uno de esos intentos, donde la reutilizacin del cdigo,
la especificacin de procesos y el desarrollo dirigido
por modelos juegan un papel protagnico.
1
No obstante, el trmino FS ya ha sido utilizado en la

Ingeniera de Software. Segn [10], el trmino FS fue
utilizado por primera vez entre 1950 y 1960 en
Estados Unidos y Europa para mejorar la
productividad en el desarrollo de software a travs de
herramientas estndar y reutilizacin de mtodos y de
componentes; luego, entre 1970 y 1980, los
fabricantes de computadores en Japn adoptan de
nuevo el concepto y mejoran considerablemente el
desarrollo de software.
An en la dcada de 1990, segn [10] se reportaron
investigaciones sustanciales en relacin al trmino FS.
Posteriormente, [11] anuncia su visin del concepto
atada a su producto Visual Studio Team System
2005 y a su plataforma Microsoft .NET. Casi en la
misma fecha, [3], presentan las tcnicas que utilizan
para el desarrollo de una FS en Brasil, donde incluso
actualmente se est conformando una Fbrica de
Software basada en Cdigo Abierto [14].
Como antecedentes importantes en el tema de las FS
se tienen las visiones ms recientes encontradas en la
literatura: [3] y [6]. Segn [3], una compaa de
software que no tenga las siguientes caractersticas no
puede ser considerada una FS:
- Produccin de software en masa y en gran escala,
- Estandarizacin de tareas y controles; y
- Divisin de trabajo y automatizacin.
conceptos comunes de cada definicin, as como

tambin los no comunes pero ms importantes; (2) para
restringir el alcance, slo se tomaron en cuenta las
versiones ms recientes de FS; (3) no se encontraron
ontologas en este tema por lo que no hubo reutilizacin
de ontologas existentes; (4) los trminos importantes
son descritos iterativamente a lo largo de este artculo,
especificando la jerarqua entre ellos as como tambin
sus relaciones; (5) a este nivel no se especifican las
propiedades ni se crean las instancias dado que aun no
se aplica a ningn caso de estudio.
4. ONTOLOGA PROPUESTA PARA FS
De acuerdo con [3], una FS debe ser flexible, capaz de

producir varios tipos de productos, implementar
conceptos de ingeniera del software y debe ser capaz
de analizar, proyectar, implementar, desarrollar y
mejorar sistemas. Se observa que el trmino FS no es
nada nuevo pero, en su mayora, las diferentes versiones
del concepto FS coinciden en la produccin en masa de
una Familia de Productos (perteneciente a un
determinado Dominio de Solucin), que cumplen con
determinados requerimientos comunes (pertenecientes a
un determinado Dominio del Problema), que son
establecidos por un conjunto de personas involucradas.
Estos involucrados no necesariamente son los
desarrolladores, sino que tambin contempla a los
clientes, usuarios, proveedores e incluso los arquitectos
de software.
3. METODOLOGA UTILIZADA
En la Figura 1 se presenta un primer nivel de conceptos
en base a los antecedentes reseados.
Se observa que el trmino FS engloba una cantidad de
conceptos que conviene manejarlos ordenadamente y
este es justamente el fin de esta investigacin en
progreso. Segn [12] una ontologa es una descripcin
explcita y formal de conceptos en un dominio de
discurso. Estos autores en su metodologa para crear
ontologas, proponen los siguientes siete pasos:
1. Determinar el dominio y el alcance.
2. Considerar la reutilizacin de ontologas
existentes.
3. Enumerar los trminos importantes.
4. Definir las clases y su jerarqua
5. Definir las propiedades de las clases
6. Definir las relaciones de las clases
7. Crear las instancias
Para efectos de presentacin en este artculo, no se
detallan cada uno de los pasos propuestos; sin
embargo, a continuacin se resaltan las actividades
realizadas en cada uno de ellos: (1) para encontrar los
trminos relevantes se identificaron aquellos
Por su parte, [6] definen el trmino FS como una Lnea

de Productos de Software (LPS) que configura
herramientas, procesos y contenido usando una
plantilla basada en un esquema dado, con el fin de
automatizar el desarrollo y mantenimiento de
variaciones de un producto arquitectnico mediante
adaptaciones, ensamblaje y configuracin de
componentes basados en frameworks soportados por un
ambiente.
La definicin de Greenfield se toma como punto de
referencia para la ontologa que se desea proponer,
posteriormente se ver que la misma, en sus detalles,
contiene las definiciones del resto de los autores
mencionados. Para entender mejor este modelo, se
realiza una segunda iteracin para analizar por separado
los conceptos ms relevantes: Lnea de Productos de
Software (LPS), plantilla, esquema y ambiente.
Figura 1. Elementos que intervienen en la definicin de FS.
4.1. Lnea de Productos de Software
Segn [4], una lnea de productos se puede ver como

un conjunto de productos que estn estrechamente
relacionados (por su funcionalidad), que son vendidos
a los mismos grupos de compradores, que son
comercializados a travs del mismo tipo de
distribucin, o que caen en el mismo rango de precios.
Este concepto tambin tiene su origen en la industria
tradicional, pero es aplicable al desarrollo de software
y su utilizacin no resulta muy novedosa. La conocida
utilizacin del concepto de LPS quiz se deba a su alto
nivel de generalidad, pudindose aplicar tanto en
organizaciones grandes como en pequeas.
La mayora de las organizaciones producen familias de
sistemas similares que se diferencian por ciertas
caractersticas; pero a nivel general, segn [2] se han
detectado tres actividades generales que pueden ser
aplicadas en cualquier situacin. Para estos autores, las
tres actividades estn altamente relacionadas: el
avance en una de las actividades necesariamente
implica el avance en las dems, por lo que en realidad
no se puede decir que exista un orden entre ellas, pero
por razones de espacio cada una ser descrita
individualmente y de forma lineal.
Desarrollo de Activos Centrales (Core Asset
Development) Esta actividad se enfoca en la
produccin de recursos generales para cualquier
producto. Aqu se define el alcance de la lnea de
productos, el plan de produccin, los componentes,
la arquitectura, los requerimientos, as como
tambin las restricciones, los estilos, patrones y
frameworks, entre otros. Se configura tambin el
inventario de activos (assets) preexistentes, lo que
ms tarde FS denomina Biblioteca de Objetos.
Desarrollo del Producto (Product Development):
Esta actividad se encarga de ensamblar los activos
desarrollados o almacenados en la actividad anterior
para crear productos acordes con los requerimientos
del mercado; sin embargo, este proceso raramente es

lineal. La creacin de productos implica una continua
relacin con el alcance, el plan de produccin y los
activos centrales (core assets).
Gestin (Management): La direccin juega un rol
crtico en el xito de la lnea de produccin. Las
actividades deben tener unos recursos asignados,
coordinados y supervisados. La direccin, tanto a
nivel tcnico como organizacional debe estar
fuertemente asociada al esfuerzo de la LPS. Pero la
direccin no slo est dirigida hacia adentro, tambin
se debe tener en cuenta la relacin con los
proveedores y consumidores. Este aspecto
posteriormente es llamado Cadena de Suministro por
FS.
Por su parte, [3], aunque basado en el modelo de FS de
[1], propone un modelo que separa la produccin de
activos centrales o componentes, del proceso de
produccin de software, y el proceso de gestin lo llama
Organizacin del trabajo. Este modelo est compuesto
por dos grandes actividades: Produccin de Software y
Produccin de Componentes.
La concepcin de FS de [6] es un poco ms amplia ya
que abarca el modelado del dominio de aplicaciones. FS
est fielmente basado en LPS y comparte actividades
con el modelo de [3], tales como Anlisis, Diseo e
Implementacin, pero en el modelo de [6]. stas estn
orientadas para una lnea de productos. Los activos en el
modelo de [6] son los que [3] denomina componentes.
Este ltimo modelo tambin contempla la posibilidad de
seleccionar las herramientas ms adecuadas para cada
dominio, con la opcin de personalizarlas.
Es importante resaltar la similitud que posee el modelo
de FS de [3] y la plantilla de FS propuesta por [6] dado
que ambos modelos fueron publicados en fechas
similares pero utilizando referencias bibliogrficas
distintas, lo que refleja el inters actual en mejorar los
procesos de desarrollo para producir sistemas de mayor
calidad. Una vez conocido el trmino LPS y su rol
3
dentro de FS (ver Figura 2), se pueden definir el resto

de los elementos que la conforman: esquema, plantilla
y ambiente.
Figura 2. Conceptos de la Lnea de Productos de Software.
4.2. Esquema, Plantilla y Ambiente
Segn [5] una FS es una LPS que configura

herramientas de desarrollo con guas y paquetes de
contenido, cuidadosamente diseados para construir
tipos especficos de aplicaciones. Estos mismos
autores establecen que una FS contiene tres ideas
claves: un esquema, una plantilla y un ambiente de
desarrollo.
Un esquema se puede pensar como una receta. Es
una lista de ingredientes como proyectos anteriores,
directorios de cdigo fuente, archivos SQL y
archivos de configuracin. Adems, el esquema
explica cmo deben ser combinados estos
ingredientes para crear el producto. El esquema
establece cules lenguajes especficos del dominio
(DSL del ingls Domain Specific Language) deben
ser usados y describe cmo los modelos basados en
esos DSL pueden ser transformados en cdigo o en
otros artefactos. El esquema describe la arquitectura
de la lnea de productos y las relaciones entre
componentes y los frameworks involucrados.
Una plantilla es cmo un paquete o bolsa de
supermercado que contiene todos los ingredientes
listados en el esquema. La plantilla provee los
patrones, guas, ejemplos, herramientas especficas
como editores grficos de DSL, scripts, hojas de
estilo (style sheets) y otros ingredientes necesarios
para construir el producto.
Un ambiente de desarrollo es como la cocina donde es

elaborado el alimento. Herramientas de alto nivel
como Microsoft Visual Studio Team System hacen
posible un ambiente de trabajo adecuado para
construir una familia de productos.
Segn [5], esta analoga puede ser ejemplificada un
poco ms teniendo entonces que los productos son los
platos servidos en un restaurant. Los involucrados
(stakeholders) son como los usuarios que ordenan platos
del men. Una especificacin de producto es como una
orden de un plato con algunos extras.
Los desarrolladores de productos (product developers)
son como los cocineros que preparan los platos descritos
en las rdenes y quienes pueden modificar ciertos
ingredientes. Los desarrolladores de la lnea de
productos (product line developers) son como los chefs
que deciden qu aparecer en el men y qu
ingredientes, procesos y equipos de cocina deben ser
usados.
Estos tres elementos (plantilla, esquema y ambiente) se
muestran en la Figura 3 y conforman las bases
tecnolgicas de una FS segn la concepcin de [6].
El trmino FS no slo est compuesto por aspectos
tecnolgicos, a continuacin se definen ciertos
conceptos de economa aplicados al desarrollo de
software y que tambin deben estar presentes en toda
empresa que decida adoptar esta tendencia.
Figura 3. Elementos tecnolgicos que conforman una FS.
4.3. Conceptos de Economa
El concepto de canales de mercadeo o cadena de

suministro es utilizado por cualquier organizacin que
produzca algn bien o servicio. La industria del
software no escapa de esta realidad pero hasta el
momento se ha limitado a utilizar este concepto slo
para mercadear el producto ya desarrollado, pero no
como parte del proceso de desarrollo. Segn [8], un
canal de mercadeo realiza la labor de llevar los bienes
de los productores a los consumidores, superando las
brechas del tiempo, plaza y posesin. Segn [6], una
FS puede ser segmentada tanto vertical como
horizontalmente para delegar responsabilidades a
proveedores externos, creando de esta forma cadenas
de suministros para el desarrollo de un producto de
software.
Otro concepto utilizado por FS es la economa de
reutilizacin. Segn [7] citado por [6], el hecho de
reutilizar soluciones de un sub-problema comn en un
dominio dado puede reducir el costo total de resolver
mltiples problemas en el mismo dominio. Adems, la
reutilizacin puede reducir el tiempo total de
lanzamiento al mercado (time to market) y mejorar la
calidad del producto. Es importante sealar la nueva
connotacin que se le otorga a este concepto dentro de
una FS, donde se toma en cuenta no slo la reduccin
del tiempo sino del costo del proyecto e incluso se
mejora el retorno de la inversin ya que al invertir en
patrones arquitectnicos, componentes y posibles
eslabones en la cadena de suministro, la reutilizacin
hace posible ver los resultados financieros de forma
ms rpida, favoreciendo las economas de escala y
de alcance.
Segn [6], estos dos conceptos con frecuencia son

confundidos y aunque ambos reducen el tiempo y el
costo del producto y mejoran su calidad produciendo
mltiples productos en lugar de copias individuales,
existen grandes diferencias entre ellos. La economa de
escala establece la posibilidad de realizar mltiples
instancias idnticas partiendo de un diseo simple. Por
su parte, la economa de alcance se plantea cuando
mltiples pero similares diseos y prototipos son
producidos colectivamente ms que individualmente.
La diferencia principal entre la economa de escala y la
economa de alcance, en trminos de FS, est en el
momento en que se produce la reutilizacin. En el
primer tipo de economa, la reutilizacin se produce
despus de tener el producto desarrollado, mientras que
en la economa de alcance, la reutilizacin se produce
durante el desarrollo del producto. La relacin de estos
conceptos se puede ver en la Figura 4.
Tanto la economa de escala como la de alcance, dentro
de la concepcin de Fbrica de Software, aumentan la
eficiencia en el proceso de desarrollo de software dado
que no se limitan al desarrollo de un producto a la vez,
sino que transitan hacia el desarrollo en masa,
sustentado fuertemente por el concepto de Lnea de
Productos de Software. Al mejorar la eficiencia, por
ende, se mejora la calidad en el proceso de desarrollo.
Segn [3], el desarrollo de una FS implica que las
mejores prcticas de la ingeniera del software sean
aplicadas sistemticamente. A continuacin se muestran
brevemente algunas de las mejores prcticas que esta
tendencia ofrece.
Figura 4. Conceptos de Economa en una FS.
4.4. Mejores Prcticas
Segn [6], FS est basado en la convergencia de ideas

claves en desarrollo dirigido por modelos y
reutilizacin sistemtica. Para los autores citados, el
Desarrollo Dirigido por Modelos (MDD del ingls
Model-Driven Development) reduce el problema de la
abstraccin por medio del uso de modelos que
capturan informacin de tal manera que pueda ser
fcilmente procesada, en lugar de crear modelos slo
como documentacin. Esta es una de las principales
prcticas propuestas por FS ya que, segn estos
autores, los modelos deben ser utilizados para
desarrollar, ms que para documentar el producto.
Todos estos esfuerzos van encaminados a pasar, de la
forma tradicional basada en el cdigo fuente, a una
nueva forma de desarrollar productos de software
basada en modelos, donde se reutilicen cada vez ms
los intentos anteriores. Para [13], la Ingeniera del
Software Basada en Componentes (ISBC) lucha por
conseguir un conjunto de componentes de software
preconstruidos y estandarizados para encajar en un
estilo arquitectnico especfico para algn dominio de
aplicacin. Este conjunto de componentes constituye
el Desarrollo de Activos Centrales de LPS.
As como [7] establece que un framework es un grupo
de clases para un tipo especfico de software, se puede
intuir entonces que un framework de procesos es un
grupo de sub-procesos para un determinado tipo de
dominio. De acuerdo con [5] un framework de
procesos es una estructura que organiza los microprocesos usados para construir artefactos que
componen los miembros de la familia de productos.
Desarrollar un framework de procesos para una lnea
de productos de software tiene sentido porque el costo
puede ser efectivamente amortizado con la produccin
de muchos productos.
Estos mismos autores afirman que un framework de

procesos esencialmente descompone un proceso en
micro-procesos adjuntados al desarrollo de varios tipos
de artefactos, incluyendo la descripcin de los
requerimientos necesarios para tal fin. En estas
descripciones se puede enumerar consideraciones tan
variadas como puntos clave de decisiones, anlisis de
trade-off asociados con cada punto de decisin,
actividades opcionales o requeridas y los resultados a
ser producidos en cada actividad.
En este sentido, segn [9], hasta ahora la arquitectura de
un sistema permaneca siempre en una especie de caja
negra siendo un secreto conocido slo por sus autores.
Una buena arquitectura del software fomenta la
reutilizacin y permite obtener y mantener el control
intelectual del desarrollo as como tambin gerenciar su
complejidad y mantener la integridad del sistema,
manejando de forma implcita la calidad en el
desarrollo.
La Figura 5 agrupa los conceptos
involucrados en las mejores prcticas que rene FS.
5. MODELO CON CONCEPTOS COMPARTIDOS
Una vez que se han descrito por separado los aspectos

compartidos en torno a FS, conviene mostrarlos en un
modelo unificado donde estn presentadas nuevas
relaciones no mostradas hasta el momento. Una de las
principales relaciones est basada en que los aspectos
econmicos adaptados por FS al desarrollo de software,
estn soportados por los aspectos tecnolgicos, de esta
forma se tiene que la economa de reutilizacin
fomenta la reutilizacin sistemtica, las economas de
escala y alcance fomentan el Desarrollo Dirigido por
Modelos, y la Cadena de Suministros debe estar
coordinada por la Direccin de la Lnea de Productos de
Software.
Figura 5. Mejores Prcticas en el Desarrollo de Software.
Por otro lado, al presentar todos los modelos de forma

unificada, se destacan aquellos conceptos que se
repiten y que a su vez sirven de integradores entre las
partes involucradas. De esta forma se puede establecer
que en una FS, la Lnea de Productos de Software
desarrolla un conjunto de productos con caractersticas
similares conformando una Familia de Productos.
Para desarrollar estos productos se sigue un esquema
determinado que describe la arquitectura del sistema
y a su vez establece las relaciones entre los
frameworks utilizados y los componentes a
ensamblar. Estos componentes se van registrando en
el inventario de componentes fomentando la
reutilizacin sistemtica.
Como se ha mostrado hasta ahora, el trmino FS,
adems de poseer mltiples definiciones, rene una
gran cantidad de conceptos que conviene identificar
para poder manejar una idea general de su alcance. En
la Figura 6 se muestra una versin unificada del
modelo conceptual propuesto, incluyendo las nuevas
relaciones descritas anteriormente. Los recuadros no
implican ningn tipo de orden ni relevancia entre
conceptos, se utilizan slo para agrupar conceptos
similares y facilitar la lectura del modelo.
Si bien FS no aporta conceptos nuevos en el desarrollo
de productos de software, la innovacin consiste en la
agrupacin de conceptos anteriores (LPS, MDD,
reutilizacin sistemtica y framework de procesos),
pero presentados en conjunto, como un nuevo intento
para pasar de la produccin tradicional a una
automatizada.
6. CONCLUSIONES Y TRABAJOS FUTUROS
FS no slo implica cambios tecnolgicos sino tambin

cambios en la economa; por lo tanto, cualquier
empresa que decida adoptar FS como base para su
forma de producir software, debe tener en cuenta ciertos

conceptos de economa que no estaban involucrados
anteriormente en este sector de produccin. Luego de
desarrollar este trabajo, las conclusiones obtenidas
pueden resumirse en dos aspectos fundamentales:
Se dan los primeros pasos para organizar y
documentar todo el conocimiento que gira en torno al
concepto de Fbricas de Software.
Hasta el momento no existe una forma de precisar la
calidad de una empresa que decida implantar una FS
como tendencia de trabajo.
Como corolario a la primera afirmacin, se tiene que la
reutilizacin y el desarrollo de varios productos en
paralelo, deben ser las caractersticas fundamentales en
una empresa que decida encaminarse hacia una Fbrica
de Software. Otro aspecto de la problemtica, es que el
tema de la calidad de los sistemas no es atacado
profundamente en todas las versiones de FS, aunque
siempre se busca mejorar la eficiencia y mitigar, en la
medida de lo posible, los errores y sus consecuencias,
tratando siempre de medir la calidad del producto.
FS propone ciertos cambios en el proceso de desarrollo
de software pero no establece una forma clara de medir
su calidad. Por lo tanto, el resultado esperado se
encamina a establecer un modelo de especificacin de la
calidad sistmica (calidad del producto y calidad del
proceso) en empresas venezolanas que cumplan con las
caractersticas de FS. Para ello adems, se aplicar esta
primera ontologa a un caso de estudio para validar los
conceptos. Luego se formular el modelo y se har su
validacin aplicando el mtodo DESMET, el cual
permite evaluar mtodos y herramientas usados en el
rea de Ingeniera de Software. Se espera entonces que
el modelo tenga al menos un 75% de aplicabilidad y de
pertinencia.
Figura 6. Modelo conceptual propuesto para Fbricas de Software.
Frameworks y Mecanos. Informe Tcnico,

Departamento de Informtica. Universidad de
Salamanca. 2002.
7. REFERENCIAS BIBLIOGRFICAS
[1]
[2]
[3]
[4]
V. Basili, G. Caldiera y G. Cantone A

Reference Architekcture for the Component
Factory. ACM Transaction on Software
Engineering and Methodology. Vol 1. n 1. pp
53-80. Enero, 1992.
P. Clements y L. Northrop. Software Product
Lines. Practices and Patterns. SEI Series in
Software Engineering.
Addison Wesley.
Segunda Edicin. Boston, USA. pp. 29-31. 2001.
J. Fabri, A. Presende, L. Begosso, A. LErrio, F.
Fujii y M. de Paula. Techniques for the
Development of a Software Factory: Case
CEPEIN-FEMA. 17th International Conference
Software and Systems Engineering and their
Applications. ICSSEA 2004. Paris, Noviembre
30 Diciembre 3. 2004.
F. Garca, J. Barras, M. Laguna y J. Marqus.
Lneas
de
Productos,
Componentes,
[5]
J. Greenfield, y K. Short. Moving to Software

Factories. White Paper, actualizado el 15 de Julio
de 2004, tomado en Enero de 2005 de
http://www.softwarefactories.com/ScreenShots/M
S-WP-04.pdf
[6]
J. Greenfield, K. Short, S. Cook, y S. Kent.

Software Factories. Assembling Applications
with Patterns, Models Frameworks and Tools.
Wiley. Primera Edicin. 2004.
[7]
I. Jacobson, M. Griss y P. Jonsson. Software

Reuse : Architecture, Process and Organization for
Business Success. ACM Press, 1997.
[8]
P. Kotler. Direccin de Marketing. La edicin

del milenio. Prentice Hall. 2001.
[9]
P. Kruchten. The Rational Unified Process. An

Introduction. Third Edition. Addison Wesley
8
Longman, Inc. 2003.

[10] N. Lim, S. James, y F. Pavri. Diffusing
Software-based Technologies with a Software
Factory Approach for Software Development. A
Theoretical Framework. Proceeding of the 22nd
Information Systems Research Seminar in
Scandinavia (IRIS22): Enterprise Architectures
for Virtual Organisations. 7-10 Agosto, Keuruu,
Finland. 1999.
[11] Microsoft Prensa. Microsoft aumenta su
ecosistema de socios alrededor de Visual Studio
2005 Team System. Tomado en Febrero de
2004
de
http://www.microsoft.com/latam/prensa/2004/Oct
ubre/VisualStudio.asp
[12] N. Noy. y D. McGuinness. Ontology
Development 101: A Guide to Creating Your First
Ontology. in Protege Documentation. Stanford
University: Stanford, CA. 2001
[13] R. Pressman. Ingeniera del Software. Un
enfoque prctico. Quinta Edicin. Mc Graw Hill.
2002.
[14] OXE Open Source Software Factory, Open
Experience Environment. Tomado en Julio de
2005 de http://php.cin.ufpe.br/~oxe/
DESARROLLO ITERATIVO E INCREMENTAL
El desarrollo iterativo nicamente se debe utilizar en aquellos proyectos que se quiere

que tengan xito (UML gota a gota de Martn Fowler) [Larman05].
2.1
LA ITERACIN Y EL INCREMENTO
El desarrollo iterativo e incremental es un enfoque para construir software (o cualquier

cosa) en el cual todo el ciclo de vida est compuesto por varias iteraciones. Las
iteraciones son pequeos proyectos compuestos de varias actividades cuyo objetivo es
entregar una parte de un sistema parcialmente completo, probado, integrado y estable.
Todo el software es integrado en cada entrega de cada iteracin hasta obtener el
producto software completo en la ltima iteracin [Larman05].
La definicin de dicho enfoque se enmarca en lo qu es una iteracin, en la

planificacin de la misma y en el concepto generado de incremento, los cuales se
mencionan a continuacin.
2.1.1 La iteracin. Una iteracin es un mini proyecto que tiene como resultado una
versin interna de cada uno de los artefactos que pueden ser generados en un proceso
de desarrollo de software. Se puede visualizar como un flujo de trabajo [JBR00]
compuesto por las actividades fundamentales del proceso (especificacin, anlisis,
diseo, implementacin, etc.) adoptado por un equipo de desarrollo para utilizar y
producir los artefactos en los que se puede dividir una solucin software.
El conjunto total e integrado de las iteraciones representar la versin externa del

software, es decir, el producto final de cara al usuario; para llegar a ello, cada una de
las iteraciones dentro del ciclo de vida del software cumplen diferentes objetivos. Las
primeras iteraciones se centran en la compresin del problema y de la tecnologa, se
preocupan por producir el anlisis del negocio, actividad o proceso que apoyar e
integrar el producto. Luego se orientan las iteraciones a establecer las bases del
diseo (arquitectura) que se robustecer a medida que fluye el ciclo de vida. Las
iteraciones siguientes se concentrarn en la construccin e integracin de los
componentes que se van generando producto de las mismas.
12
Aunque se describe un proceso secuencial de iteraciones no se debe entender un

proceso iterativo como la divisin por partes de cada una de las fases del proceso
cascada; una iteracin incluye su propia planificacin, su especificacin, su anlisis y
otras actividades como diseo, implementacin o validacin (pruebas); puede
entenderse mejor como un proceso compuesto por pequeas cascadas, donde cada
iteracin se concentrar ms en una actividad que en las otras [Larman05].
2.1.2 Planificacin y secuenciacin de las iteraciones. Un ciclo de vida iterativo

requiere ms planificacin y comprensin que un modelo en cascada [JBR00] donde
toda su planificacin se realiza al principio y contiene mayor incertidumbre y falta de
fidelidad para las fases siguientes en el proceso de desarrollo. En contraste, en el
modelo iterativo no se planifica el proyecto durante el inicio, slo se dan los primeros
pasos; no se intenta llevar a cabo la construccin sin establecer las bases de la
planificacin en iteraciones previas. Cada planificacin de una iteracin tiene en cuenta
los resultados de las iteraciones precedentes, la seleccin de la especificacin o
funcionalidades a realizar y el estado actual del ciclo de vida del proceso, y termina con
la preparacin de la versin interna.
La evolucin del software (proceso o producto) no sucede sin un plan que la preceda.
Se pretende con la iteracin en el desarrollo de software, ordenar cada flujo de trabajo
para obtener un camino directo en el cul las primeras iteraciones proporcionan la base
de conocimiento para las siguientes. Estas iteraciones dan como resultado un mayor
conocimiento de los requisitos, los problemas, los riesgos y el dominio de la solucin,
mientras que las siguientes dan como resultado una serie de incrementos aditivos que
conforman finalmente la versin externa, el producto final para el cliente. La secuencia
de iteraciones, que siempre avance, representar el xito de la aplicacin del modelo,
sin tener que volver nunca a los resultados de una iteracin previa para corregir el
modelo debido a algo descubierto en una iteracin posterior.
Las iteraciones pueden solaparse en el tiempo, en el sentido que una est a punto de
terminar cuando otra est comenzando. La planificacin para la siguiente iteracin debe
comenzar a medida que se va terminando y preparando la entrega de la anterior. La
entrega de una iteracin significa que se ha llegado finalmente a una conclusin dentro
del equipo de trabajo, que se ha integrado todo el software de la iteracin y puede
crearse la versin interna.
El objetivo principal de la planificacin de las iteraciones es realizar una secuenciacin

del trabajo de manera que puedan desarrollarse primero las decisiones,
especificaciones y funcionalidades ms importantes.
13
2.1.3 Qu es un incremento. Simplemente, el resultado de una iteracin es un

incremento [JBR00]. Un incremento est representado en la diferencia entre la versin
interna dada por una iteracin y la versin interna obtenida de la siguiente.
En un momento del ciclo iterativo (secuencia de iteraciones) algunos mdulos o

subsistemas estarn terminados e integrados, contendrn toda la funcionalidad
requerida y plasmada en los requisitos, estarn implementados, probados y validados;
otros sistemas estarn parcialmente terminados y otros sin haberse iniciado. Un
incremento se puede ver entonces como la diferencia entre dos momentos
determinados en el ciclo de vida del proceso. Se van construyendo incrementos de
manera iterativa, dando forma a cada unos de los subsistemas que representan el
sistema final que ser visualizado cuando se realice la integracin del ltimo
incremento.
2.1.4 Qu no es una iteracin. Un ciclo de vida iterativo no es un desarrollo aleatorio;

no es algo que slo afecte a los desarrolladores; no es redisear una y otra vez hasta
que los desarrolladores prueben que algo funciona; no es impredecible; no puede ser
una excusa para fracasar en la planificacin y en la gestin [JBR00].
Una iteracin controlada se planifica y es una herramienta que pueden utilizar los
directores de proyecto para controlarlo, y al principio del ciclo de vida, reduce los
riesgos que pueden amenazar el progreso en el desarrollo. Las versiones internas
proporcionadas por cada iteracin posibilitan la retroalimentacin de los usuarios y esto
lleva a una correccin temprana de la trayectoria del proyecto.
2.2
EL PROCESO UNIFICADO DE DESARROLLO RUP
El proceso unificado de desarrollo RUP (Rational Unified Process) es el representante

ms conocido del proceso iterativo e incremental. Su aplicacin, como su enseanza,
es ampliamente difundida por organizaciones, empresas dedicadas al desarrollo de
software, universidades y expertos en prcticas y procesos de ingeniera de software,
entre otros, alrededor del mundo.
14
2.2.1 Orgenes. El antecedente ms importante en la historia de RUP se ubica en

1967 con la Metodologa Ericsson (Ericsson Approach) elaborada por Ivar Jacobson,
una aproximacin del desarrollo basado en componentes, que introdujo el concepto de
Casos de uso. Entre los aos de 1987 a 1995 Jacobson fund la compaa Objectory
AB y lanza el proceso de desarrollo Objectory (abreviacin de Object Factory).
Posteriormente en 1995 la renombrada compaa Rational Software Corporation
adquiere a Objectory AB y entre 1995 y 1997 desarrolla el proceso ROP (Rational
Objectory Process) a partir del Objectory 3.8 y del enfoque metodolgico de Rational
(Rational Approach) adoptando el lenguaje unificado UML [Larman05] como lenguaje
de modelado. Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y
James Rumbaugh, Rational Software desarroll e incorpor diversos elementos para
expandir su ROP, destacndose especialmente el conocido modelado del negocio
[Letelier02]. En junio del 1998 se lanza el RUP-Rational Unified Process, el conocido
Proceso Unificado de Desarrollo propuesto por la Rational Corporation, hoy parte de
IBM.
2.2.2 Caractersticas esenciales. Los autores de RUP destacan que el proceso de

software propuesto por RUP tiene tres caractersticas esenciales: est dirigido por los
Casos de uso, est centrado en la arquitectura, y es iterativo e incremental.
Proceso dirigido por Casos de uso. Los Casos de uso son una tcnica de
modelado para la captura y representacin de requisitos que obliga a pensar en
trminos de importancia para el usuario y no slo en trminos de funciones a
contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema
que proporciona al usuario un valor agregado. Los Casos de uso representan los
requisitos funcionales del sistema.
En RUP los casos de uso no son slo una herramienta para especificar los requisitos
del sistema; tambin guan su diseo, implementacin y prueba. Los casos de uso
constituyen un elemento integrador y una gua de trabajo, que no slo inicia el proceso
de desarrollo sino que tambin proporcionan un hilo conductor, permitiendo establecer
trazabilidad entre los artefactos que son generados en las diferentes actividades del
proceso de desarrollo. Basndose en los casos de uso, se crean los modelos de
anlisis y diseo, luego la implementacin que los lleva a cabo, y se verifica que
efectivamente el producto implemente adecuadamente cada caso de uso, haciendo que
cada modelo est sincronizando con cada uno de ellos.
Proceso centrado en la arquitectura. La arquitectura de un sistema es la
organizacin o estructura de sus partes ms relevantes, lo que permite tener una visin
comn entre todos los involucrados en el proceso (desarrolladores y usuarios) y una
perspectiva ms clara del sistema completo, necesaria para controlar el desarrollo.
15
La arquitectura involucra los aspectos estticos y dinmicos ms significativos del

sistema, est relacionada con la toma de decisiones que indica cmo tiene que ser
construido el sistema y ayuda a determinar en qu orden. Adems la definicin de la
arquitectura debe tomar en consideracin elementos de calidad del sistema,
rendimiento, reutilizacin y capacidad de evolucin, por lo que debe ser flexible durante
todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma
software, el sistema operativo, los gestores de base de datos y protocolos, entre otros
aspectos tcnicos. Muchas de estas restricciones constituyen requisitos no funcionales
del sistema.
En el caso de RUP, adems de utilizar los Casos de uso para guiar el proceso se presta
especial atencin al temprano establecimiento de una buena arquitectura que no se vea
fuertemente impactada ante cambios posteriores presentados durante la construccin y
el mantenimiento. Existe una interaccin entre los Casos de uso y la arquitectura, los
Casos de uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura
debe permitir el desarrollo de todos los Casos de uso requeridos, actualmente y en el
futuro. Esto provoca que tanto arquitectura como Casos de uso deban evolucionar en
paralelo durante todo el proceso de desarrollo de software.
Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el

diseo, por lo que la arquitectura se representa mediante varias vistas que se centran
en aspectos concretos del sistema, abstrayndose de los dems. Para RUP, todas las
vistas juntas forman el llamado modelo 4+1 de la arquitectura, el cual recibe este
nombre porque lo forman las vistas lgica, de implementacin, de proceso y de
despliegue, ms la vista de Casos de uso que es la que da la afinidad a todas.
Un proceso iterativo e incremental. El equilibrio correcto entre los casos de uso y

la arquitectura en el desarrollo slo se consigue con el tiempo. Para esto, la estrategia
que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo
se divide en partes ms pequeas o mini proyectos, permitiendo que dicho equilibrio
entre casos de uso y arquitectura se vaya logrando durante cada mini proyecto, as
durante todo el proceso de desarrollo, cada mini proyecto se puede ver como una
iteracin (un recorrido ms o menos completo a lo largo de todos los flujos de trabajo,
actividades fundamentales o disciplinas) de la cual se obtiene un incremento que
produce un crecimiento en el producto software.
16
Una iteracin puede realizarse por medio de una cascada pasando por los flujos
fundamentales de Requisitos, Anlisis, Diseo, Implementacin y Pruebas, como se
muestra en la figura 2.1. Tambin existe una planeacin de la iteracin, un anlisis de la
iteracin y algunas actividades especficas propias de cada iteracin. Al finalizarla se
realiza una integracin de los resultados con lo obtenido de realizar iteraciones
anteriores [Letelier02].
Figura 2.1. Una iteracin RUP.
[Letelier02]
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada

iteracin aborda una parte de la funcionalidad total, pasando por todos los flujos de
trabajo relevantes y refinando la arquitectura. Cada iteracin se analiza cuando termina;
se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes,
afectando a las iteraciones siguientes. Durante la planificacin de la siguiente iteracin,
el equipo tambin examina cmo afectarn los riesgos que an quedan al trabajo en
curso y toda la retroalimentacin de la iteracin pasada se utiliza para reajustar los
objetivos de las siguientes iteraciones. Se contina con esta dinmica hasta que se
haya finalizado por completo con una versin final del producto software.
2.2.3 Estructura general del proceso RUP. El proceso puede ser descrito en dos
dimensiones o ejes como se ve en la figura 2.2:
17
FIG 2.2. Estructura del proceso RUP.
[Letelier02]
El eje horizontal representa la lnea del tiempo y es considerado el eje de los aspectos
dinmicos del proceso. Indica las caractersticas del ciclo de vida del proceso,
representado en fases (Inicio, Elaboracin, Construccin y Transicin), iteraciones e
hitos.
Eje vertical representa los aspectos estticos del proceso. Describe el proceso en
trminos de componentes de proceso, disciplinas o flujos de trabajo workflows,
artefactos, roles y actividades.
2.2.3.1 Estructura dinmica del proceso. RUP divide el proceso en cuatro fases:
Inicio, Elaboracin, Construccin y Transicin, dentro de las cuales se realizan varias
iteraciones en un nmero variable, segn el proyecto, y en las que se hace un mayor o
menor nfasis en las distintas disciplinas llamadas Workflows - Flujos de Trabajo. En
la Figura 2.2 se muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase
en la que se encuentre el proyecto. Se observa que en cada fase participan todas las
disciplinas, pero que dependiendo de la fase, el esfuerzo dedicado a una disciplina
vara.
18
Las primeras iteraciones de las fases de Inicio y Elaboracin se enfocan hacia la

comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la
eliminacin de los riesgos crticos, y al establecimiento de una lnea base para la
arquitectura. Durante la fase de inicio las iteraciones hacen ponen mayor nfasis en
actividades modelado del negocio y de requisitos.
En la fase de Elaboracin, las iteraciones se orientan a la construccin de la lnea

base de arquitectura, abarcan los flujos de trabajo de requisitos, modelo de negocios
(refinamiento), anlisis, diseo y una parte de implementacin.
La fase de Construccin se lleva a cabo por medio de una serie de iteraciones.

Para cada iteracin se seleccionan algunos casos de uso, se refina su anlisis y
diseo, y se procede a su implementacin y pruebas. Se realiza una pequea
cascada para cada ciclo. Se realizan tantas iteraciones como se requieran, hasta
que se termine la implementacin de una versin del producto.
En la fase de Transicin se pretende garantizar que se tiene un producto preparado

para su entrega a los usuarios.
2.2.3.2 Estructura esttica del proceso. Un proceso de desarrollo de software define

quin hace qu, cmo y cundo. RUP define cuatro elementos: los roles, las
actividades, los productos (artefactos) y los flujos de trabajo o disciplinas que responden
a cada una de estas preguntas.
Roles y Actividades. Una persona puede desempear diversos roles, as como un

mismo rol puede ser representado por varias personas. Las responsabilidades de un rol
son tanto el llevar a cabo un conjunto de actividades como el ser el dueo de un
conjunto de artefactos. Una actividad en concreto es una unidad de trabajo que una
persona desempea.
RUP define grupos de roles, agrupados por participacin en actividades relacionadas.

Estos grupos son:
Analistas: Analista de procesos de negocio, Diseador del negocio, Analista de

sistema y Especificador de requisitos.
19
Desarrolladores: Arquitecto de software, Diseador, Diseador de interfaz de

usuario, Diseador de base de datos, Implementador e Integrador.
Gestores: Jefe de proyecto, Jefe de control de cambios, Jefe de configuracin, Jefe

de pruebas, Jefe de despliegue, Ingeniero de procesos, Revisor de gestin del
proyecto y Gestor de pruebas.
Apoyo: Documentador tcnico, Administrador de sistema, Especialista en

herramientas, Desarrollador de cursos y Artista grfico.
Especialista en pruebas: Especialista en Pruebas (Tester), Analista de pruebas,

Diseador de pruebas.
Otros roles: Stakeholders (participantes), Revisor, Coordinador de revisiones y

Revisor tcnico
Artefactos. Los productos o artefactos son los resultados tangibles del proyecto, las
cosas que se van creando, modificado y usando hasta obtener el producto final durante
el proceso de desarrollo de software. Un artefacto puede ser cualquiera de los
siguientes: un documento, un modelo (como el de casos de uso), un elemento propio
del modelo (una clase o un caso de uso), un subsistema o componente.
Flujos de trabajo (Disciplinas). Con simplemente la enumeracin de roles,
actividades y artefactos no se define un proceso, se necesita contar con una secuencia
de actividades realizadas por los diferentes roles, as como la relacin entre los mismos.
Un flujo de trabajo es una relacin de actividades que producen unos resultados
observables, y en RUP son:
Modelado del negocio. Con esta disciplina se pretende llegar a un mejor

entendimiento de la organizacin donde se va a implantar el producto (software).
Requisitos. Esta es una de las disciplinas ms importantes, porque en l se

establece qu tiene que hacer exactamente el sistema a construir. En esta lnea los
requisitos son el contrato que se debe cumplir, de modo que los usuarios finales
tienen que comprender y aceptar los requisitos que se especifiquen.
20
Anlisis y Diseo. El objetivo de este flujo es traducir los requisitos a una

especificacin que describe cmo implementar el sistema, mediante su
representacin a travs de los diferentes modelos UML definidos para las
actividades de anlisis y diseo.
Implementacin. En ste flujo se implementan las clases y objetos, en cdigo

fuente, binarios y ejecutables. Adems se deben hacer las pruebas de unidad: cada
desarrollador es responsable de probar las unidades que produzca. El resultado final
de este flujo de trabajo es un sistema ejecutable.
Pruebas. Este flujo de trabajo es el encargado de evaluar la calidad del producto

que est siendo desarrollando, pero no para aceptar o rechazar el producto al final
del proceso de desarrollo, sino para ir integrndolo en todo el ciclo de vida.
Despliegue. El objetivo de este flujo de trabajo es producir con xito entregables del
producto y distribuirlos a los usuarios.
Gestin del proyecto. La gestin del proyecto es el arte de lograr un balance al

administrar objetivos, riesgos y restricciones para desarrollar un producto que sea
acorde a los requisitos de los clientes y los usuarios.
Configuracin y control de cambios. El objetivo de sta disciplina es mantener la

integridad de todos los artefactos que se crean en el proceso, as como de mantener
informacin del proceso evolutivo que se ha seguido.
Entorno. La finalidad de ste flujo de trabajo es dar soporte al proyecto con las
adecuadas herramientas, procesos y mtodos. Brinda una especificacin de las
herramientas que se van a necesitar en cada momento, as como definir el instante
concreto del proceso en el que han de ser empleados.
2.2.4 Prcticas. RUP identifica 6 mejores prcticas con las que define una forma
efectiva de trabajar en equipos de desarrollo de software.
Gestin de requisitos. RUP brinda una gua para encontrar, organizar,

documentar, y seguir los cambios de los requisitos funcionales y sus restricciones.
Utiliza la notacin de Caso de Uso y escenarios para representar los requisitos.
21
Desarrollo de software iterativo. Desarrollo del producto mediante iteraciones con

hitos bien definidos, en las cuales se repiten las actividades pero con distinto
nfasis, segn la fase del proyecto.
Desarrollo basado en componentes. La creacin intensiva de sistemas en

software requiere dividir cada sistema en componentes con interfaces bien definidas,
que posteriormente sern ensamblados para generar el sistema. Esta caracterstica
en un proceso de desarrollo permite que el sistema se vaya creando a medida que
se obtienen o se desarrollan sus componentes.
Modelado visual (usando UML). UML es un lenguaje para visualizar, especificar,

construir y documentar los artefactos de un sistema software. Utilizar herramientas
de modelado visual facilita la gestin de dichos modelos, permitiendo ocultar o
exponer detalles cuando sea necesario. El modelado visual tambin ayuda a
mantener la consistencia entre los artefactos del sistema: requisitos, diseos e
implementaciones. El modelado visual ayuda a mejorar la capacidad del equipo para
gestionar la complejidad del software.
Verificacin contina de la calidad. Es importante que la calidad de todos los

artefactos se evale varias veces durante el proceso de desarrollo, especialmente al
final de cada iteracin. En esta verificacin las pruebas juegan un papel fundamental
y se integran a lo largo de todo el proceso. Para todos los artefactos, no
necesariamente ejecutables, las revisiones e inspecciones deben ser continas.
Gestin de los cambios. El cambio es un factor de riesgo crtico en los proyectos

de software. Los artefactos software cambian no slo por acciones de
mantenimiento posteriores a la entrega del producto, sino que durante el proceso de
desarrollo aparecen nuevos cambios en los requisitos. Otro gran desafo que debe
abordarse en la construccin de software es la participacin de mltiples
desarrolladores trabajando a la vez en un mismo incremento y quizs en distintas
plataformas. La ausencia de una disciplina, rpidamente conducira al caos. Las
prcticas de Gestin de Cambios y de Configuracin es la disciplina que RUP
encarga para este aspecto.
22

M1 - M2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

M1 - M2

Uploaded by

Copyright:

Available Formats

Unidad 1: Ingeniera de Software

1.1.1 Concepto de Ingeniera de Software

Materia: Ingeniera de Software

Materia: Ingeniera de Software

Mantenibilidad: se refiere a modificaciones que se le hacen al software despus de su

Si el software es lo que se entrega al cliente, entonces se puede considerar un producto.

Materia: Ingeniera de Software

Recordemos tambin el concepto y alguitas caractersticas de sistema:

Materia: Ingeniera de Software

Ser capaz de planificar su trabajo y el de otros. Con desorganizacin no se produce

1.1.2 Problemas de la ingeniera de Software. La crisis de desarrollo

Materia: Ingeniera de Software

Materia: Ingeniera de Software

1.1.3 Diferencias entre Ingeniera de Software y Ciencia de la

Materia: Ingeniera de Software

Materia: Ingeniera de Software

Alcance interdisciplinario. En la Ingeniera de sistemas se conjugan muchas Ingenieras,

1.2.1 Ciclo de Vida: Conceptos de Proceso de Desarrollo de Software.

Caractersticas del Proceso

Materia: Ingeniera de Software

Aceptabilidad: Si el proceso es aceptable por los que deben utilizarlo

Materia: Ingeniera de Software

1.2.2 Ciclo de Vida: Modelos

Proveer una gua para la administracin de proyecto.

Cul es la necesidad de modelos de ciclos de vida?

La necesidad de modelos de ciclos de vida.

Materia: Ingeniera de Software

Algunos factores que ayudaron a la necesidad de contar con modelos fueron:

Enfoque en cascada. Totalmente secuencial, una etapa despus de terminada la anterior.

1.2.3 Ciclos de vida secuenciales: El modelo en cascada

Materia: Ingeniera de Software

Se realizan relevamientos de los siguientes aspectos:

Materia: Ingeniera de Software

Materia: Ingeniera de Software

Ingeniera de software basada en componentes

Si bien las etapas de especificacin de requerimientos y la de validacin son similares a otros

Materia: Ingeniera de Software

Materia: Ingeniera de Software

Veamos su grfica de organizacin de etapas:

Materia: Ingeniera de Software

Por lo general consiste en la entrega de prototipos de interfaz de usuario, construido de una

Modelo Entrega por etapas

Materia: Ingeniera de Software

1.2.4. La naturaleza iterativa de los desarrollos.

Materia: Ingeniera de Software

Materia: Ingeniera de Software

Modelo Iterativo e incremental

Su uso no garantiza por si solo el xito del proyecto ni de su uso.

Materia: Ingeniera de Software

Existen costos ocultos en su implementacin, por la necesidad de la planificacin y la

1.2.5. Ventajas y desventajas de c/u de los ciclos de vida

Materia: Ingeniera de Software

Trabaja con requerimientos

Materia: Ingeniera de Software

Produce sistema con sobre Excelente

Materia: Ingeniera de Software

Los sistemas socio-tcnicos incluyen hardware, software, personas y procesos, se

Factores humanos y organizacionales influyen en el funcionamiento de los sistemas sociotcnicos.

Los sistemas heredados son sistemas socio-tcnicos.

En cuanto al proceso de software puede destacar lo siguiente:

Los procesos de software incluyen las actividades relacionadas con la produccin de un

Materia: Ingeniera de Software

Scientific American, noviembre, 1994

Segn un informe sobre el proyecto AAS, publicado en mayo de este ao por el