APUNTES DE CLASES

ICB-6xx - INGENIERIA DE SOFTWARE BIOMEDICO

Unidad 1 : Modelos de Desarrollo de Software.






FACULTAD DE INGENIERIA
ESCUELA DE INGENIERA BIOMDICA

(1er. Semestre 2014)



1
1.1. PROCESO DE DESARROLLO DE SOFTWARE.

1.1.1. EL CONCEPTO DEL SOFTWARE.

Software, un trmino plenamente incorporado al vocabulario de muchas personas,
cuyo significado literal enfatiza su caracterstica blanda o intangible, en comparacin con el
hardware (o incluso con el peopleware: los recursos humanos). La mayora entiende que
software significa un conjunto de programas computacionales que cumplen con una
determinada funcin [Press-1993A]. Y algunos tienen claro que existen diferentes clases de
software; y que hoy en da, el hacer software es una actividad econmica del hombre, como
muchas; tiene costos y beneficios, tanto en el orden financiero como en el social.

Y todo el mundo realiza software persiguiendo distintos objetivos. Se hace software
porque hay demanda del mismo. Por ejemplo, se construye software para que las empresas
y organizaciones ganen en eficiencia y eficacia administrativa. Se hace software para que
los procesos industriales se automaticen, reemplazando as a otros sistemas de trabajo; y en
general, a la resolucin de problemas donde la cantidad de variables supera nuestra
capacidad, o ante la imposibilidad de realizar las tareas de otra forma que no sea bajo el
control de un computador. Se construye software para que la ciencia y la tcnica progresen
(con las simulaciones y los clculos numricos). Tambin se hace software para que el
hardware existente sea accesible a los usuarios: por ejemplo, sistemas operativos que
faciliten el compartir recursos, compiladores e intrpretes que faciliten escribir programas
ejecutables, herramientas de cuarta generacin, administradores de bases de datos que
faciliten el acceso y el procesamiento de los datos almacenados, aplicaciones en electro-
medicina, sistemas computacionales que faciliten la documentacin, mejores y ms
amigables interfaces grficas, y aplicaciones multimedia; y actualmente procesadores de
texto que se activan por voz humana.

Ahora bien, para cualquier persona que haya intentado hacer un sistema de varios
programas de regular tamao, es claro que hacer software no es trivial. Frente a la
pregunta qu significa hacer software?, muchas veces se piensa en hacer software como
en el hacer programas, y entonces suena rimbombante hablar de una ingeniera de
software.


2
Se habla de hacer software como en el hacer uno o ms programas, y se piensa en
un crecimiento lineal de la complejidad: si en hacer un programa tardo A, en hacer n
programas tardar n por A . Pero este pensamiento esconde dos falacias, que muchos
gerentes o ejecutivos deben reconocer: La primera, es que hacer software es hacer
programas. Algunos autores especializados [Boria-1988] sealan que un sistema de
software es diferente de un programa-producto en el cual se deben cumplir requisitos de
interfaz hombre-mquina, mantenibilidad, documentacin y seguridad entre otros. La
segunda, un sistema no es un simple agregado de programas, y su complejidad crece ms
que linealmente con la cantidad de programas que contiene. Encarada como una actividad
industrial, la confeccin de software requiere de un enfoque disciplinado, al cual se le
denomina ingeniera de software [Sommer-1991] [Press-1993A].

Se desea insistir en que el concepto de software es mucho ms que programas; para
los profesionales informticos y de ingeniera, es informacin que existe en dos
componentes bsicos, pero importantes:
a) Los componentes ejecutables, que corresponden a los programas escritos en algn
lenguaje de programacin formal (como Cobol, C, Visual-Basic, PHP, JAVA), y el cdigo de
mquina ejecutable que se obtiene de la compilacin o interpretacin de estos lenguajes;
incluso, en los casos de productos de 4GL generadores de cdigos.
b) Los componentes no-ejecutables, que se refieren principalmente a la documentacin
existente para acompaar a los programas, que deberan incluir (por ejemplo): una
especificacin de los requerimientos, una representacin del diseo (con la estructura de los
datos y de los mdulos), y un buen manual del usuario.

Existe un problema fundamental que va ms all de la estrategia que un profesional
decida implementar para asegurar una buena relacin con el personal de usuarios que le
rodea. Se trata de un aspecto netamente cultural asociado al proceso de compra de
software; en efecto, tanto disponer de software regalado como argumento de venta para
los equipos (o simplemente copiado en forma ilegal), ha llevado a que el usuario tpico no
considere el costo del software, o a lo ms implique un costo marginal del total de su
adquisicin. La pregunta del milln: cunto vale el software? [Bartle-1991] .



3
El software se desarrolla, no se fabrica en un sentido clsico; el software no se
estropea [Press-1993A] [Press-1993B] . El desafo para todos los profesionales
informticos y desarrolladores de software, queda planteado entonces en trminos
educacionales; se tiene que convencer a los usuarios-clientes de que hacer software no es
barato ni fcil. Adems, la industria del software es nica por el hecho que su producto es
intangible. El cliente no puede ver o tocar un programa. A lo ms, l puede ser testigo de
las acciones que ejecuta y produce el sistema de software en el computador. Debido al
creciente tamao y complejidad del software en la actualidad, la verificacin de su calidad se
ha hecho muy difcil.

Muchos especialistas incluso planteaban una crisis del software. Es necesario
explicar un poco sobre esta crisis o afliccin crnica. [Boria-1988] [Press-1993A]. Esta
crisis es un estado permanente de insatisfaccin, tanto en usuarios como profesionales, que
preocupa por igual a los sectores industriales y a los acadmicos. Permanentemente, los
gerentes de Informtica debaten los problemas del control de los proyectos de software (cmo
dejar de superar siempre los presupuestos y plazos de entrega de los sistemas). O bien,
siempre esperan un producto de "ltima generacin" que les permita controlar mejor sus
proyectos y concretarlos con xito. En los ltimos aos, con la incorporacin de los PC's, se
ha producido una masificacin de su uso y la liberacin del usuario. El nuevo marco de
colaboracin entre los usuarios y las reas de Informtica no est resultando ideal en todos
los casos. Suelen presentarse quejas entre los ejecutivos informticos en cuanto a que el
mayor conocimiento que los usuarios tienen respecto a los requisitos y recursos de la
informtica centralizada, no siempre se ve acompaado al mismo ritmo con los
conocimientos que existen respecto a procedimientos y aplicaciones a nivel de PCs. El
apetito insaciable de los usuarios por ms novedosos y mejores equipos y aplicaciones en
algunos casos puede afectar al personal de informtica, cuyo trabajo consiste en soportar la
compatibilidad e interconectividad.
La mayora de las veces, la prdida del control de un proyecto es principalmente un
problema de administracin. Es la combinacin de una cuidadosa planificacin y un "know-
how" sobre el diseo (- no slo la fuerza tcnica -) lo que conduce a un resultado exitoso.
Las organizaciones desarrolladoras de software, debido a esta crisis , no realizan una
administracin adecuada del proyecto, saltndose etapas para tratar de cumplir con los
plazos estipulados. Se debe reconocer que la administracin de proyectos de software
resulta diferente de otras administraciones de proyectos, por varias razones [Antima-1997] .

4

Se debe entender el proceso de software, como un proceso que puede ser
controlado, medido y modificado. Cuando el Director General de una empresa le solicita al
Jefe Informtico, que cuantifique los beneficios sobre la inversin en tecnologas de
informacin (software especfico), no basta simplemente describir los cambios en la
productividad del personal de sistemas y los niveles de servicio; lo que realmente desea ver,
es el beneficio expresado en trminos de mejoras a la actividad (negocio) de la empresa.

Sin duda alguna la Informtica es un ingrediente y parte fundamental en todo tipo de
organizaciones. Las empresas lderes del mundo reconocen en ella a uno de los factores
crticos de xito [Guerre-1994] . Por ende, su definicin y aplicacin deben ser apropiadas
para entender las continuas demandas de mejoras que formulen sus usuarios. Uno de sus
pilares bsicos son los sistemas de informacin, en particular aquellos relacionados con las
actividades del negocio de cada organizacin. Sin embargo, las opiniones respecto de sus
bondades estn divididas o difieren, dependiendo de quin emita los comentarios.

Los ingenieros informticos o personal de sistemas, por lo general manifiestan
preocupacin por aspectos relacionados con el uso de recursos y otros parmetros de
eficiencia tcnica. As mismo, auditores, contralores o personal administrativo, indicarn
problemas de control interno y/o debilidades por falta de integridad de los datos o por errores
de clculo u otros problemas similares. Los usuarios, dependiendo de su nivel jerrquico,
tendrn sus propios puntos de vista y sus "dardos", eventualmente, estarn dirigidos: (1) a la
cantidad de trabajo que les demanden mantenerlos en produccin (obtener/generar los
datos, alimentar el sistema, controlar su funcionamiento, retroalimentar para corregir, usar
las salidas para generar informacin que no entregan en forma automtica, etc.); (2) a que
no apoyan el proceso de posicionamiento de la empresa en el mercado; y (3), a otros
factores importantes para ellos (como que se les "cae" eventualmente el sistema). Los
clientes, por su parte, mencionarn, entre otros, problemas como mantener 24 horas de
funcionamiento, y los 365 das del ao. Finalmente, y desde el punto de vista de la
Gerencia, nunca un sistema de software est completamente terminado: siempre hay
"detalles que solucionar", lo que motiva que los plazos se extiendan, y que los costos
asociados aumenten.





5

Existen estadsticas a nivel mundial que muestran que cerca del 75 % de los recursos
informticos se destinan a realizar mantenciones de los sistemas en explotacin, y cerca del
80 % de ese esfuerzo est destinado a la correccin de problemas y fallas que pudieron
haber sido previstos, mediante el uso de tcnicas adecuadas [Guerre-1994] . El prestigioso
Instituto de Ingeniera de Software de la Universidad de Carnegie Mellon (en EE.UU.), ha
evaluado la calidad del proceso de desarrollo de software de ms de 250 empresas de dicho
pas, encontrando que el 80 % de ellas se encuentran en el estado ms primario de su
evolucin, lo cual se caracteriza por producir ms problemas que soluciones.
Una valiosa investigacin realizada a nivel nacional [Antima-1997], respecto al grado
de madurez existente en los procesos de documentacin y calidad del software en la industria
chilena, arroj que el 86 % se encontraba en el nivel mnimo, y que el 14 % slo se ubicada en
el nivel siguiente.
Quin tiene la razn? Como puede suponerse, las inquietudes tienen su base,
fundamento o motivo. Por ende, es necesario atenderlas desde los inicios de los proyectos;
idealmente durante la gnesis de los sistemas. Es decir, durante su diseo y desarrollo, y
de esta forma reducir los riesgos y costos de mantenimiento, asegurar los retornos
esperados y prever un nivel de servicio o satisfaccin apropiado para cada uno de los
grupos de opinin o en conflicto de intereses.

Dados los incalculables miles de millones de dlares que los pases industrializados
han invertido en la tecnologa informtica durante la ltima dcada, se han obtenido los
beneficios que se esperaban?, los productores de software han llegado realmente a ser ms
productivos?. Por ejemplo: durante los aos 80, los negocios realizados en Estados Unidos
invirtieron una cifra de US$ trilln en tecnologa informtica [Keyes-1995]. Slo en 1988, las
compaas norteamericanas invirtieron unos US$ 51 billones en hardware, unos US$ 20
billones en software comprado, y ms de US$ 44 billones en servicios computacionales. El
desafo de la calidad es necesariamente inseparable del de la productividad, si una empresa va
a hacer sistemas de software correctos, exactos y confiables.
Para los profesionales y los acadmicos, esta crisis slo admite un desafo y respuesta:
nuevas y mejores tecnologas y metodologas de produccin de software dentro de las
organizaciones. Hay tres caminos posibles para enfrentar el problema: incrementar la
productividad individual; mejorar la organizacin del equipo y el control del proyecto; y comprar
el software hecho. En este ltimo caso, las tcnicas y mtodos son la responsabilidad del
proveedor; l slo tiene dos de los tres caminos.

6

1.1.2. PROCESOS DE SOFTWARE.

Administrando Proyectos de Software.

La mayora de los gerentes de proyectos de software probablemente concuerden en
que la entrega a tiempo y al costo adecuado de productos de alta calidad a los clientes, es el
objetivo ms importante en la administracin de un proyecto de produccin de software. La
industria de software est tapada con una gran cantidad de proyectos que no pudieron
cumplir con los criterios de tiempo, costo y/o calidad. Otros gerentes tambin le pueden
agregar objetivos adicionales: satisfaccin de los trabajadores en la tarea, mejoramiento a
largo plazo de la competencia global de la organizacin en el desarrollo del producto, y un
buen retorno de la inversin del negocio. Ahora bien, dados estos objetivos, cmo pueden
lograr los gerentes de software ( TICs) que sto suceda? cules son las herramientas y
factores principales que pudieran usar para alcanzar estos ambiciosos objetivos?

Previamente, se puede mencionar que a travs del estudio de varias publicaciones,
algunos autores [Yeh-1993] [Press-1993B] plantean diferentes enfoques en cuanto a estilos
de administracin. En la vida real, el enfoque suele ser una mezcla de los tipos puros,
dependiendo del temperamento del administrador y de la gente, la tecnologa y los recursos
disponibles.

* El enfoque de menor rendimiento. Un enfoque es no ser demasiado ambicioso, y
establecer objetivos limitados. Si se promete poco, es improbable que se fracase
[Jenner95]. Incluso se puede entregar ms de lo prometido y verse bien en el papel. Pero,
en realidad, finalmente se pierde en el comercio competitivo, debido a que los productos de
calidad no se pueden entregar en forma rpida y con un bajo costo.

* Un enfoque de estrellas. Otro enfoque consiste en usar slo la mejor gente, lo que es
indicado por la experiencia, registros curriculares, y/o post-grados. La explicacin es la
siguiente: escribir software es una actividad compleja, y cada producto es, en ciertos
sentidos, diferente del anterior. De modo que la produccin de buen software es en realidad
un arte, que se adquiere mejor a travs de la prctica. Si se puede conseguir a la mejor
gente y usarla como un equipo de elite, este equipo fcilmente aventajar a un equipo
promedio, tanto en productividad como en calidad.


7


* El enfoque de tecnologa de punta. Quizs debido a que el software representa un
enfoque altamente tcnico para resolver problemas en la sociedad moderna, algunos
gerentes de software favorecen un enfoque tcnico para los problemas de produccin de
software. Esto se puede denominar como el enfoque robtica, para usar una analoga con
la automatizacin de una fbrica. Este enfoque incluye ideas tales como herramientas para
mejorar la calidad y los ambientes de desarrollo y pruebas, herramientas CASE, y el uso de
generadores de programas, entre otros.

* El enfoque de proceso. Este enfoque trata la produccin de software, como
consistiendo en una serie de procesos individuales diferentes, similares a la produccin de
hardware. Cun bien opere la fbrica depender en gran medida de cun bien se hayan
afiatados los procesos productivos de la fbrica. Aunque las personas y las herramientas
son importantes elementos de los procesos de software, se deben buscar modos de reducir
la variabilidad del proceso (hacer ms predecible la produccin de software) y mejorar las
capacidades del proceso. En la actualidad, este enfoque tiene muchos partidarios en la
industria del software [Guerre-1995]. Tal como lo demuestra la siguiente seccin, no es
difcil entender el por qu.

Definiendo el proceso de Software.

Los estndares ISO 9000 estn basados en comprender que todo trabajo est
acompaado de un proceso. Cada proceso tiene insumos. Los productos son los
resultados de un proceso; y los productos son tangibles o intangibles. El proceso mismo es
una transformacin que agrega valor. Un producto puede ser, por ejemplo, una factura, un
software computacional, un combustible lquido, un dispositivo clnico, un servicio bancario o
un producto final o intermedio de cualquier categora genrica. Deber existir oportunidades
para hacer mediciones sobre los insumos en varias instancias del proceso, as como tambin
sobre los productos [INN90-1995] .

El desarrollo de software puede ser tremendamente complejo y a menudo existen
diversas formas de realizar las distintas tareas involucradas. Un proceso bien definido
puede ayudar a ejecutarlo adecuadamente, y permite enfocarlo en realizar tareas asignadas
y establece un marco de trabajo apropiado.


8

Un proceso es un mtodo particular de hacer algo; generalmente involucra
numerosos pasos y operaciones, incluyendo procedimientos, instrucciones de trabajo y
estndares [Jenner-1995]. Algunos ejemplos adecuados a esta definicin son libros de
recetas culinarias, instrucciones de ensamblaje hgalo usted mismo, procedimientos para
desmontar un aparato elctrico, lneas de ensamblaje para fabricacin de tableros de
circuitos o de autos, y definicin de etapas para construir un producto de software. Un
proceso necesita ser repetible, pero puede ser o no repetible, o frecuentemente usado.
Algunos procesos pueden usarse muy rara vez o no del todo, tal como el procedimiento de
evacuacin de emergencia para una ciudad bajo ataque nuclear. Un proceso puede no ser
visible o bien documentado. A veces, lo que se practica puede diferir de los procedimientos
escritos. Si las cosas estn hechas para un propsito determinado (ad hoc), no de acuerdo
a algn procedimiento, por lo general no es repetible, y entonces ya no merecera ser
llamado un proceso. Pero la ingeniera de software no es una actividad rutinaria que puede
ser estructurada y reglamentaria como un proceso de manufactura repetitivo; es un proceso
intelectual que debe ajustarse dinmicamente a las necesidades creativas de las personas y
sus tareas.

Adems, se puede definir proceso una serie de actividades relacionadas entre s, que
convierten insumos en resultados (cambiando el estado de las entidades) .

Tambin para describir un proceso, puede ser til dibujar un diagrama de flujo, que
capture los pasos o tareas del proceso y la relacin interna y secuencias de estos pasos
[Yeh-1993]. Tambin puede ser til para capturar las entradas y salidas de cada uno de los
pasos del proceso a conocer, qu variables podran afectar el resultado y dnde se guarda
el conocimiento detallado del proceso. Se hace notar que no todas las variables son
controlables; por ejemplo, la complejidad del problema puede estar ms all del control del
proceso del software del proyectista. Si se mira en el diagrama de flujo, se puede tener una
nueva perspectiva del proceso, reconocer variables importantes, e identificar pasos
innecesarios o etapas perdidas. El diagrama puede servir como punto de partida para el
proceso de la trayectoria del flujo, mejoramiento, o re-proyeccin.




9

Frecuentemente todo el ciclo de vida del desarrollo de software se divide en unas
etapas de proceso. Sin embargo, los procesos grandes tienden a estar afectados por
muchas variables y no son tan fciles de comprender. Cada proceso grande, por lo general,
consta de muchos procesos pequeos y distintos. Por ejemplo, el proceso inicial de
requerimientos puede contener los siguientes subprocesos: estudio de mercado, encuesta al
cliente, anlisis competitivo, prototipo, estudio de factibilidad, caractersticas prioritarias
(mediante el despliegue de la funcin de calidad) y el estudio del factor humano, entre otros.
Mientras ms se puede tomar aparte un proceso grande, y trazar un problema hacia un
proceso pequeo especfico, ms probable ser el ser capaz de comprender el problema y
hacer algo con respecto a l, mediante el proceso de mejoramiento. Como estos procesos
individuales son especficos, estn ms sujetos a experimentaciones y control. Algunos de
ellos, pueden que normalmente, no se reconozcan como procesos de software en el modelo
de ciclo de vida o metodologa de software.

El hecho que un proceso exista no significa necesariamente que sea el proceso
correcto. Con frecuencia, los procesos pueden simplificarse, perfeccionarse, o mejorarse de
otro modo para satisfacer las necesidades del proyecto. Debera considerarse un diseo del
proceso o re-ingeniera para ver si el proceso es o no ad-hoc en llenar las necesidades de la
lnea de produccin de software.

Por qu basado en proceso?

Se mencionarn algunos de los problemas que plantean los tres primeros
enfoques administrativos: el enfoque de menor rendimiento, el enfoque de estrellas y el
enfoque de tecnologa de punta, antes de conocer los beneficios del enfoque basado en
proceso [Yeh-1993] .

El enfoque de menor rendimiento corresponde a una posicin poco competitiva que
conducir al fracaso y ser derrotado en el mercado. El enfoque de slo estrellas no es
prctico. Existe una escasez de buenos profesionales de software. No se puede detener la
produccin de software slo porque no se pueda conseguir la gente que se gustara utilizar
en el proyecto. Adems, existe un problema que es cada vez mayor. El enfoque de slo
estrellas funcionara bien para un proyecto ms bien pequeo. Pero cuando se necesita
producir muchos cientos de miles de lneas de cdigos o ms, y hacerlo dentro de un
perodo de tiempo razonable, este enfoque se quiebra. Todos los equipos de elite (equipos
10
quirrgicos en el hospital, comandos militares, pilotos del servicio de vuelo) son
relativamente pequeos. La comunicacin y el trabajo en equipo adquieren una importancia
crucial cuando se logra un equipo de ms de una docena de personas. El enfoque de
robtica tambin es limitado porque no se puede automatizar a las personas. En la medida
que las personas sigan desempeando roles claves en la produccin de software, un
enfoque que dependa slo de la automatizacin y de las herramientas, tendr nicamente
un impacto limitado. Esto tambin se mantiene para la fabricacin, aunque las tareas de
fabricacin son ms proclives a la automatizacin. Varios estudios de casos han sugerido
que las fbricas que hicieron grandes inversiones en robtica, pero que descuidaron la
dimensin personas, aparte de lo caro que es construirlas, no necesariamente sern ms
productivas que las fbricas tradicionales. Los procesos de produccin de software son ms
difciles de automatizar, debido a la amplia variedad de problemas y a la complejidad
encontrada.

Por contraste, el enfoque basado en proceso pretende reducir las variaciones de
produccin de software y mejorar las capacidades de produccin de software a travs de la
caracterizacin y mejoramiento del proceso. El proceso abarca el mtodo, la gente y la
tecnologa, pero no se limita a estos componentes. El enfoque basado en proceso trata de
mover a la administracin de produccin de software desde una forma de arte a una
disciplina de ingeniera [Guerre-1995] . Al descifrar las lecciones de la ciencia de la
computacin, sociologa, tecnologa de informacin, integracin de sistemas, ingeniera de
software y muchas otras disciplinas, y acumulando estudios y experiencias de casos de la
vida real, se puede comprender mejor cada proceso individual de produccin de software y
sus factores claves, y as ser ms capaz de controlar y predecir el comportamiento.

Esto es precisamente lo que se discute en el marco de calidad del proceso de
software y las aplicaciones que plantea este Captulo. Tal como se puede explicar y
demostrar, se puede obtener mejores ganancias en calidad y productividad con una
inversin relativamente pequea en automatizacin, y sin tener que cambiar el personal por
un elenco de personas estrellas.

Sin embargo, sto no debe sugerir que todos concuerdan con un enfoque basado
en proceso. Estn aquellos que creen que las personas son nicas y diferentes, y que es
contraproductivo tratar de mecanizar el proceso de produccin de software o de estandarizar
los procedimientos [Guerre-1995].

11

Actividades del Proceso de Software

Un proceso del software es un conjunto de actividades que conducen a la creacin de
un producto software. Estas actividades pueden consistir en el desarrollo de software desde
cero en un lenguaje de programacin estndar como Java o C. Sin embargo, cada vez ms,
se desarrolla nuevo software ampliando y modificando los sistemas existentes y
configurando e integrando software comercial o componentes del sistema.
Los procesos del software son complejos y, como todos los procesos intelectuales y
creativos, dependen de las personas que toman decisiones y juicios. Debido a la necesidad
de juzgar y crear, los intentos para automatizar estos procesos han tenido un xito limitado.
Existe una inmensa diversidad de procesos del software. No existe un proceso ideal, y
muchas organizaciones han desarrollado su propio enfoque para el desarrollo del software.
Los procesos han evolucionado para explotar las capacidades de las personas de una
organizacin, as como las caractersticas especficas de los sistemas que se estn
desarrollando. Para algunos sistemas, como los sistemas crticos, se requiere un proceso de
desarrollo muy estructurado. Para sistemas de negocio, con requerimientos rpidamente
cambiantes, un proceso flexible y gil probablemente sea ms efectivo.

Aunque existen muchos procesos diferentes de software, y cada organizacin pueda
tener establecidos sus propios y diferentes procesos, algunas actividades fundamentales
son comunes para todos ellos [Sommer-2005] :
1. Especificacin del software. Se debe definir la funcionalidad del software y las
restricciones en su operacin.
2. Diseo e implementacin del software. Se debe producir software que cumpla su
especificacin.
3. Validacin del software. Se debe validar el software para asegurar que hace lo que el
cliente (o usuario) desea.
4. Evolucin del software. El software debe evolucionar para cubrir las necesidades
cambiantes del cliente.

Aunque no existe un proceso del software ideal, en las organizaciones existen
enfoques para mejorarlos. Los procesos pueden incluir tcnicas anticuadas, y no
aprovecharse de las mejores prcticas en la ingeniera del software industrial. De hecho,
muchas organizaciones an no aprovechan los mtodos de la ingeniera del software en el
desarrollo de su software.
12

Los procesos del software se pueden mejorar por la estandarizacin del proceso; esto
conduce a mejorar la comunicacin y a una reduccin del tiempo de formacin, y hace la
ayuda al proceso automatizado ms econmica. La estandarizacin tambin es un primer
paso importante para introducir nuevos mtodos, tcnicas y buenas prcticas de ingeniera
del software [Sommer-2005] .

No hay una forma correcta o incorrecta de organizar estas actividades, y el objetivo de
este Captulo es simplemente proporcionar al alumno una introduccin de cmo se pueden
organizar. Las cuatro actividades bsicas y fundamentales del proceso son: especificacin,
desarrollo, validacin y evolucin, y se pueden organizar de forma distinta en diferentes
procesos del desarrollo. En el enfoque en cascada, estn organizadas en secuencia,
mientras que en el desarrollo evolutivo se entrelazan. Cmo se llevan a cabo estas
actividades depende del tipo de software, de las personas y de la estructura organizacional
implicada.


Especificacin del software

La especificacin del software o ingeniera de requerimientos es el proceso de
comprensin y definicin de qu servicios (o funcionalidades) se requieren del sistema, y de
la identificacin de las restricciones de funcionamiento y desarrollo del mismo. La ingeniera
de requerimientos es una etapa particularmente crtica en el proceso del software ya que los
errores en esta etapa originan inevitablemente problemas posteriores en el diseo e
implementacin del sistema.

En la Figura 1.1. se muestra el proceso de ingeniera de requerimientos. ste
conduce a la generacin de un documento de especificacin de requerimientos, que
bsicamente es la especificacin del sistema. Normalmente en este documento los
requerimientos se presentan en dos niveles de detalle. Los usuarios finales y los clientes
necesitan una declaracin de alto nivel de los requerimientos, mientras que los
desarrolladores del sistema necesitan una especificacin ms detallada de ste [Sommer-
2005] .


13

Existen cuatro fases principales en el proceso de ingeniera de requerimientos:

1. Estudio de viabilidad. Se estima si las necesidades del usuario se pueden satisfacer con
las tecnologas actuales de software y de hardware. El estudio analiza si el sistema
propuesto ser rentable desde un punto de vista del negocio, y si se puede desarrollar
dentro de las restricciones de presupuesto existentes. Este estudio debe ser relativamente
econmico y rpido de elaborar. El resultado debe informar si se va a continuar con un
anlisis ms detallado.

2. Obtencin y anlisis de requerimientos. Es el proceso de obtener los requerimientos
del sistema por medio de la observacin de los sistemas existentes, levantamiento de los
procesos actuales, discusiones con los dueos de los procesos, los usuarios potenciales y
proveedores, el anlisis de procedimientos y tareas, etc. Esto puede implicar el desarrollo de
uno o ms modelos y prototipos del sistema que ayudan a los profesionales (analistas) a
comprender el sistema a especificar.

3. Especificacin de requerimientos. Es la actividad de traducir la informacin recopilada
durante la actividad de anlisis en un documento que define un conjunto de requerimientos.
En este documento se pueden incluir dos tipos de requerimientos: los requerimientos de los
usuarios, que son declaraciones abstractas de los requerimientos del cliente y del usuario
final del sistema, y los requerimientos del sistema, que son una descripcin ms detallada (y
tcnica) de la funcionalidad a proporcionar.

4. Validacin de requerimientos. Esta actividad comprueba la veracidad, consistencia y
completitud de los requerimientos. Durante este proceso, inevitablemente se descubren
errores en el documento de requerimientos. Se debe modificar entonces para corregir estos
problemas. Es necesario obtener la visacin del dueo del proceso.

Por supuesto, las actividades en el proceso de requerimientos no se llevan a cabo de
forma estrictamente secuencial. El anlisis de requerimientos contina durante la definicin y
especificacin, y a lo largo del proceso pueden surgir nuevos requerimientos. Por lo tanto,
las actividades de anlisis, definicin y especificacin se entrelazan. En los mtodos giles,
los requerimientos de desarrollan de forma incremental conforme a las prioridades del
usuario, y la obtencin de requerimientos viene de los usuarios que forman parte del equipo
de desarrollo.

14


Figura 1.1: Especificacin de Requerimientos.


Diseo e implementacin del software

La etapa de implementacin del desarrollo de software es el proceso de convertir las
especificaciones del sistema en un sistema ejecutable. Siempre implica los procesos de
diseo y desarrollo del software, pero, si se utiliza un enfoque evolutivo de desarrollo,
tambin puede implicar un refinamiento de la especificacin del software.
Un diseo de software es una descripcin de la estructura del software que se va a
implementar, los datos que son parte del sistema, las interfaces entre los componentes del
sistema, los procesos y/o los algoritmos utilizados (o reglas del negocio). Los diseadores
no llegan inmediatamente a un diseo detallado, sino que lo pueden desarrollar de manera
iterativa a travs de diversas versiones [Sommer-2005] .
El proceso de diseo puede implicar el desarrollo de varios modelos del sistema con
diferentes niveles de abstraccin. Mientras se descompone un diseo, se pueden descubrir
errores y omisiones de las etapas previas. Esta retroalimentacin permite mejorar los
modelos de diseo previos. La Figura 1.2. es un modelo de este proceso que muestra las
descripciones de diseo que pueden producirse en varias etapas del diseo. Este diagrama
sugiere que las etapas son secuenciales; aunque en realidad, las actividades del proceso de
diseo se entrelazan. La retroalimentacin entre etapas y la consecuente repeticin del
trabajo es inevitable en todos los procesos de diseo.


15



Figura 1.2.; Diseo e Implementacin de Software.


La salida de cada actividad de diseo es una especificacin para la siguiente etapa.
Esta especificacin puede ser abstracta y formal, realizada para clarificar los requerimientos,
o puede ser una especificacin para determinar qu parte del sistema se va a construir.
Durante todo el proceso de diseo, se detalla cada vez ms esta especificacin. El resultado
final del proceso son especificaciones precisas de los algoritmos y estructuras de datos a
implementarse.

Las actividades que se pueden distinguir del proceso de diseo son:

1. Diseo arquitectnico. Los subsistemas que forman el sistema y sus relaciones se
identifican y documentan.
2. Especificacin abstracta. Para cada subsistema se produce una especificacin
abstracta de sus servicios y las restricciones bajo las cuales debe funcionar.
3. Diseo de la interfaz. Para cada subsistema se disea y documenta su interfaz con otros
posibles subsistemas. Esta especificacin de la interfaz debe ser inequvoca ya que permite
que el subsistema se utilice sin conocimiento de su funcionamiento. En esta etapa pueden
utilizarse los mtodos de especificacin formal [Sommer-2005].
4. Diseo de componentes. Se asignan servicios a los componentes y se disean sus
interfaces (y el caso de los procedimientos almacenados).


16

5. Diseo de la estructura de datos. Se disea en detalle y especifica la estructura de
datos utilizada en la implementacin del sistema (Tablas del Sistema, con los datos
necesarios).
6. Diseo de algoritmos. Se disean en detalle y especifican los posibles algoritmos (o
reglas del negocio) utilizados para proporcionar los servicios.

ste es un modelo general del proceso de diseo, y los procesos reales y prcticos
pueden adaptarlo de diversas maneras [Sommer-2005] .

En la prctica, los mtodos estructurados son realmente notaciones estndar que
comprenden prcticas aceptables. Si se siguen estos mtodos y se aplican las pautas,
puede obtenerse un diseo razonable. La creatividad del diseador an se requiere para
decidir la descomposicin del sistema y asegurar que el diseo capte de forma adecuada la
especificacin del mismo.

La programacin es una actividad personal y no existe un proceso general que se
siga comnmente. Algunos programadores empiezan con los componentes que
comprenden, los desarrollan y despus continan con los que comprenden menos. Otros
toman el enfoque opuesto, dejando los componentes que son ms familiares hasta el final
debido a que saben cmo desarrollarlos. Algunos desarrolladores prefieren definir los datos
al inicio del proceso y los utilizan para conducir el desarrollo del programa; otros dejan los
datos sin especificar tanto como sea posible. Esta tema se podr analizar ms adelante
(con algunos Anexos y literatura complementaria).

Normalmente, los programadores llevan a cabo algunas pruebas del cdigo que han
desarrollado. A menudo esto muestra defectos en el programa que se deben eliminar del
mismo. Esto se denomina depuracin. Las pruebas y la depuracin de defectos son
procesos diferentes. Las pruebas establecen la existencia de defectos. La depuracin
comprende la localizacin y correccin de estos defectos. Los defectos en el cdigo se
localizan y el programa se modifica para cumplir los requerimientos. Las pruebas se deben
entonces repetir para asegurar que los cambios se han efectuado correctamente. As, el
proceso de depuracin es parte tanto del desarrollo como de las pruebas del software.


17

Validacin del software

La validacin del software o, de una forma ms general, la verificacin y validacin
(V & V, para algunos especialistas) [Sommer-2005] se utiliza para mostrar que el sistema se
ajusta a su especificacin y que cumple las expectativas del usuario que lo comprar o
utilizar. Implica procesos de comprobacin, como las inspecciones y revisiones, en cada
etapa del proceso del software, desde la definicin de requerimientos hasta el desarrollo del
programa. Sin embargo, la mayora de los costos de validacin aparecen despus de la
implementacin, cuando se prueba el funcionamiento del sistema.

Bsicamente, un proceso de pruebas consta de tres etapas, en las cuales se prueban
los componentes del sistema, la integracin del sistema y, finalmente, el sistema con los
datos del cliente. En el mejor de los casos, los defectos se descubren en las etapas iniciales
del proceso y los problemas con la interfaz, cuando el sistema se integra. Sin embargo,
cuando se descubren defectos, el programa debe depurarse y esto puede requerir la
repeticin de otras etapas del proceso de pruebas. Los errores en los componentes del
programa pueden descubrirse durante las pruebas del sistema. Por lo tanto, el proceso es
iterativo y se retroalimenta tanto de las ltimas etapas como de la primera parte del proceso.

Las tpicas etapas del proceso de pruebas son:

1. Prueba de componentes (o unidades). Se prueban los componentes individuales para
asegurarse de que funcionan correctamente. Cada uno se prueba de forma independiente,
sin los otros componentes del sistema. Los componentes pueden ser entidades simples
como funciones o clases de objetos, o pueden ser agrupaciones coherentes de estas
entidades.

2. Prueba del sistema. Los componentes se integran para formar el sistema. Este proceso
comprende encontrar errores que son el resultado de interacciones (o condiciones) no
previstas entre los componentes y su interfaz. Tambin comprende validar que el sistema
cumpla sus requerimientos funcionales y no funcionales. Para sistemas grandes, esto puede
ser un proceso gradual en el cual los componentes se integran para formar subsistemas que
son probados individualmente antes de que ellos mismos se integren para formar el sistema
final.


18

3. Prueba de aceptacin. Es la etapa final en el proceso de pruebas antes de que se
acepte que el sistema se ponga en funcionamiento. Este se prueba con los datos reales
proporcionados por el cliente ms que con datos de prueba simulados. Debido a la
diferencia existente entre los datos reales y los de prueba, la prueba de aceptacin puede
revelar errores y omisiones en la definicin de requerimientos del sistema. Tambin puede
revelar problemas en los requerimientos donde los recursos del sistema no cumplen las
necesidades del usuario o donde el desempeo del sistema es inaceptable.

Las ltimas etapas de prueba consisten en integrar el trabajo de los programadores y
deben planificarse por adelantado. Un equipo independiente de probadores debe trabajar a
partir de planes de prueba que se desarrollan desde de la especificacin y diseo del
sistema. Este es un tema y tarea muy importante, y que generalmente no se hace.
La Figura 1.3. ilustra cmo los planes de prueba son el vnculo entre las actividades
de prueba y de desarrollo [Sommer-2005] .




Figura 1.3.: Planes de Pruebas.


En el lenguaje informtico, la prueba de aceptacin algunas veces se denomina
prueba alfa. Los sistemas personalizados se desarrollan para un nico cliente. El proceso de
prueba alfa contina hasta que el desarrollador del sistema y el cliente acuerdan que el
sistema que se va a entregar es una implementacin aceptable de los requerimientos del
sistema. Cuando un sistema se va a comercializar (masivamente) como un producto de
19
software, a menudo se utiliza un proceso de prueba denominado prueba beta. sta
comprende la entrega de un sistema a un nmero potencial de clientes que acuerdan
utilizarlo, los cuales informan de los problemas a los desarrolladores del sistema. Esto
expone el producto a un uso real y detecta los errores no identificados por los constructores
del sistema. Despus de esta retroalimentacin, el sistema se modifica y se entrega ya sea
para una prueba beta adicional o para la venta.


Evolucin (o mantencin) del software

La flexibilidad de los sistemas de software es una de las principales razones por la
que ms y ms software se incorpora a los sistemas grandes y complejos. Se destaca que
una vez que se decide adquirir un hardware, es muy costoso hacer cambios en su diseo.
Sin embargo, se pueden pedir y hacer cambios al software en cualquier momento durante o
despus del desarrollo del sistema. Y casi siempre, con la puesta en marcha del sistema,
comenzarn a solicitarse nuevos requerimientos adicionales [Sommer-2005] .

Histricamente, siempre ha existido una separacin entre el proceso de desarrollo y
el proceso de evolucin del software (o mantenimiento del software). La mayora de las
personas considera el desarrollo de software como una actividad creativa en la cual un
sistema de software se desarrolla desde un concepto inicial hasta que se pone en
funcionamiento. Sin embargo, a veces consideran el mantenimiento del software como algo
aburrido y sin inters (o simplemente, no lo consideran). Aunque los costos de mantencin
son a menudo mayores que los costos iniciales de desarrollo, el proceso de mantenimiento
se considera a veces menos problemtico que el desarrollo del software original (siempre y
cuando se haya desarrollado bajo un proceso documentado y controlado).

Esta distincin entre el desarrollo y el mantenimiento es cada vez menos relevante.
Hoy en da, pocos sistemas de software son completamente nuevos, lo que implica que tiene
ms sentido ver el desarrollo y el mantenimiento como actividades continuas. Ms que dos
procesos separados, es ms realista considerar a la ingeniera del software como un
proceso evolutivo (Figura 1.4.) en el cual el software se cambia continuamente durante su
periodo de vida como respuesta a los requerimientos cambiantes y necesidades del cliente-
usuario.


20

Actualmente, en todas las bases tcnicas de las licitaciones pblicas, las
especificaciones establecen condiciones acerca de un perodo de marcha blanca, en el cual
se incluyen las mantenciones, las que pueden ser debido a errores detectados, o a
perfecciones que se requieran por condiciones normativas y/o regulatorias.



Figura 1.4.: Mantenimiento del Software.


El tema del mantenimiento del software se encuentra plenamente incorporado al
concepto de ciclo de vida de un sistema de software, el que se analiza en el siguiente
Captulo.








21

1.2. INGENIERIA DE SOFTWARE Y CICLO DE VIDA.

1.2.1. LA INGENIERIA DEL SOFTWARE.

El desarrollo de aplicaciones de software requiere diversas habilidades y pasos para el
reconocimiento y la solucin del problema; sin embargo, puede ser logrado usando un conjunto
de tcnicas que son independientes de las aplicaciones. Estas tcnicas forman precisamente,
la base de una metodologa de ingeniera de software.

La ingeniera de software pretende desarrollar y aplicar tcnicas de ingeniera en la
produccin de software, para obtener productos confiables, eficientes y de bajo costo
[Press93-B] . Entre sus objetivos principales se puede reconocer:
- Poseer una metodologa bien definida, que direccione el ciclo de vida del software, en sus fases
de planeacin, desarrollo y mantencin.
- Establecer un conjunto de componentes de software que documenten cada etapa en el ciclo
de vida del software, y muestre el seguimiento paso a paso.
- Acordar un conjunto de puntos de revisin predecibles que puedan ser revisados a intervalos
regulares en el ciclo de vida del software.

Una definicin tcnica es: La aplicacin de una sistemtica, disciplinada y cuantificable
aproximacin, al desarrollo, operacin y mantenimiento de software [Press-1993A]; es decir, la
aplicacin de la ingeniera al software.
Un ingeniero de software es una persona que aplica principios de ingeniera al
desarrollo o produccin de sistemas, donde el software es la intrnsica o principal parte de un
sistema. Sin entrar en profundizar el tema, junto con este ingeniero, hay otros roles
(profesionales y/o tcnicos) que participan ayudando al proceso de ingeniera: un analista
(analiza requerimientos), un programador (escribe el cdigo que implementa el diseo) y el
probador (desarrolla y conduce un conjunto de pruebas para el producto de software) [Press-
1993B] .

Un interesante aporte para conocer el desarrollo histrico de la ingeniera de software,
lo constituyen ciertas publicaciones especializadas [Press-1993A] [Parra-1995] .


22

En la prctica, las fases genricas del desarrollo de software se manifiestan como un
paradigma de ingeniera de software. Un paradigma es una plantilla, modelo, o marco de
referencia que define el proceso a travs del cual se crea el software [Press-1993B].
Establece el contexto de procedimientos para un proyecto de software, lo que implica puntos
importantes y productos que se crean, las actividades de aseguramiento de calidad que se van
a imponer, y la visin de la administracin que se va a requerir. Secuencialmente, la iteracin
y el paralelismo son caractersticas importantes de un paradigma de ingeniera de software.
Se ejecutan paso a paso ciertas actividades de definicin y desarrollo. La salida de una
actividad se convierte en la entrada de la siguiente y el software se desarrolla en una
secuencia de pasos predecibles. Por ejemplo, el software puede derivarse de una declaracin
de requerimientos del cliente, usando una secuencia de pasos tcnicos que se denominan:
anlisis, diseo, codificacin y prueba. Una vez que el software ha sido entregado al cliente,
comienzan las actividades de soporte y mantenimiento.

Por lo tanto, se puede definir a la ingeniera de software como la rama de la ingeniera
que crea y mantiene las aplicaciones de software aplicando tecnologas y prcticas de las
ciencias computacionales, manejo de proyectos, ingeniera, el mbito de la aplicacin, y
otros campos. Otros especialistas la definen como: Es un proceso definido paso a paso,
que facilita la especificacin, el diseo, la implementacin y las pruebas de una solucin de
software, para un conjunto de requisitos explcitos, de modo eficiente y eficaz

Se destacan dos aspectos:

En primer lugar, se puede recordar por la experiencia, que la administracin inteligente
de un proyecto no deja de utilizar todos los recursos a su disposicin. Estos son de dos
categoras: los recursos humanos y los recursos tecnolgicos. Los recursos tecnolgicos se
agrupan, a su vez, en dos categoras: los recursos administrativos (metodologas y tcnicas) y
los recursos automticos (herramientas). En este contexto, una Tcnica es un procedimiento
destinado a realizar ordenadamente una tarea; una Herramienta es un programa de
computador que apoya la realizacin de una tarea, y una Metodologa es un sistema de
tcnicas supuestamente coherente, consistente y completo, para llevar adelante el proyecto.



23

En segundo lugar, se habla mucho del "ciclo de vida de un software"; y este aspecto
cuesta mucho hacerlo entender a los ejecutivos de una organizacin que se encuentra
desarrollando un plan o proyecto informtico normal. Y se debe reconocer que todo software
debe evolucionar con el tiempo. Una ley de la ingeniera de software establece que sin
importar en qu momento del ciclo de vida del sistema se encuentre, el sistema cambiar, y el
deseo de cambiarlo persistir a lo largo de todo el ciclo [Press-1993B] . Un ejemplo claro:
todo utilitario o software de aplicacin aparece con nuevas versiones actualizadas en el
mercado. En el caso de un desarrollo interno en las organizaciones, muchas veces, ante
continuas mantenciones o "parches" a un sistema en explotacin, es mejor desarrollar un
nuevo sistema en forma completa. Es indudable que la experiencia acumulada ayudar a
reducir el tiempo de desarrollo (en comparacin con la versin original). Por esto se
recomienda disear los sistemas ( mdulos), sabiendo que requerirn alguna mantencin en
el futuro, y que tendrn un perodo de vida til limitado. De este tema se profundizar en el
siguiente punto.

1.2.2. MODELOS DEL PROCESO DE SOFTWARE Y CICLO DE VIDA.

Como se ha explicado precedentemente, un proceso de software es un conjunto de
actividades que conducen a la creacin de un producto de software; y un modelo de
software es una representacin abstracta de un proceso de software. Cada modelo
representa un proceso desde una perspectiva particular.

Estos modelos generales no son descripciones definitivas de los procesos del
software. Ms bien, son abstracciones de los procesos que se pueden utilizar para explicar
diferentes enfoques para el desarrollo de software. Puede pensarse en ellos como marcos
de trabajo del proceso que pueden ser extendidos y adaptados para crear procesos ms
especficos de ingeniera del software. Adems, los conceptos (o alcances) de los modelos
de procesos, y del ciclo de vida del software, tambin pueden varias entre los especialistas
(de autor en autor).

En el rea del desarrollo de software, las actividades del ciclo de vida son las
concernientes a la transformacin de una necesidad de un cliente, en un producto de
software que satisface dicha necesidad.

24

El ciclo de vida de un software comienza cuando ste es concebido, y termina cuando
no se encuentra ms disponible para su uso [Sander-1994]. Para facilitar la administracin,
ste ciclo generalmente se divide en etapas o fases, cada una con objetivos bien precisos, y
con productos (o salidas) a entregar por cada una de las fases. Cada una de las actividades y
productos de cada fase, tienen asociados un conjunto de normas y prcticas basadas en
estndares internacionales vigentes de una buena prctica ingenieril del software.

El alumno debe comprender que los modelos de procesos genricos se utilizan
ampliamente en la prctica actual de la ingeniera del software. No se excluyen mutuamente
y a menudo se utilizan juntos, especialmente para el desarrollo de sistemas grandes. De
hecho, el Proceso Unificado de Racional (RUP) que se trata en el siguiente Captulo
combina elementos de todos estos modelos. Los subsistemas dentro de un sistema ms
grande pueden ser desarrollados utilizando enfoques diferentes. Por lo tanto, aunque es
conveniente estudiar estos modelos separadamente, debe entenderse que, en la prctica, a
menudo se combinan.

Modelar el ciclo total de vida de produccin de software ha sido un rea muy activa
de investigacin. Existe bastante literatura en que se presentan distintos modelos y puntos
de vistas al respecto [Yeh-1993] [Press-1993A] [IPL-1996] [Macas-1997] . Algunos
representan nuevas maneras o paradigmas de la produccin de software. Debido al gran
nmero de variables en un ciclo de vida, es difcil llegar a un modelo de ciclo-vida que sea a
la vez de uso prctico y razonablemente preciso.

No se desea profundizar dicho tema, pero se hace necesario conocer bsicamente,
las distintas fases en la que se ve envuelto el desarrollo de un producto de software. A
continuacin, se sintetizarn varios de tales modelos y algunos de otros procesos
alternativos, que son tambin importantes en el desarrollo de software [Parra-1995]
[Sommer-2005] . Tambin se cuenta con literatura complementaria que el alumno puede
acceder.

25
Modelo de Cascada (Waterfall).

Este modelo clsico exige un enfoque sistemtico y secuencial del desarrollo de
software, que comienza y se propaga a travs de las conocidas fases separadas de anlisis
de requerimientos, diseo, implementacin o codificacin, pruebas y mantenimiento; y con
lazos de retroalimentacin entre las fases adyacentes. Segn los puntos de vista estudiados,
el modelo de cascada de produccin de software, se produce secuencialmente en fases
genricas. Versiones diferentes del modelo pueden subdividir las etapas/fases en algo
diferente; pero todas ellas tienen tareas similares. Vase la Figura 1.5.

Analizar y Especificar. Comprender y desarrollar los requerimientos o las especificaciones
tcnicas del producto para que ste tenga xito en el mercado y satisfaga las necesidades
de los clientes.

Disear e Implementar. Esto se hace generalmente por medio de la descomposicin top-
down (de arriba-abajo) en cuatro fases:
1. Arquitectura. Llegar a una clara comprensin del dominio de la aplicacin y desarrollar
bloques funcionales y programas ejecutorios que apoyen fcil y efecti-vamente las
caractersticas del dominio de aplicacin, para que la arquitectura sea robusta y fcil de
mejorar y mantener en el futuro.
2. Diseo Global. Desarrollar los mdulos y estructuras de datos necesarios para cada
programa ejecutable.
3. Diseo Detallado. Traducir los requerimientos en una representacin de software;
desarrollando el algoritmo y estructura de datos que se necesitan para implementar en cada
mdulo.
4. Codificacin. Construir el algoritmo y estructura de datos en el lenguaje de programacin
elegido, forma legible para la mquina (hardware).

Verificar. Esto se hace mediante el montaje y las pruebas bottom-up (de abajo-arriba),
tambin en fases, tales como:
1. Prueba de la unidad. Esto verifica que un mdulo o programa trabaje correctamente.
2. Prueba de construccin e integracin. La prueba de integracin es, por lo comn, la
etapa cuando se ejecuta el control de configuracin del producto total. La prueba de
integracin, verifica que todos los programas trabajen juntos correctamente de acuerdo a las
especificaciones de interfaz entre programas.

26

3. Prueba de sistema. Esto asegura la calidad y confiabilidad del producto segn criterios
del cliente a travs de pruebas en un ambiente que emula el ambiente activo del cliente.
4. Prueba in-situ (marcha blanca). El producto se prueba con datos de la vida real, y la
prueba verifica que todos los otros aspectos de la versin liberada del producto, pudiendo
incluir la instalacin, conversin de base de datos, y procedimientos de aprovisionamiento de
antecedentes del cliente, trabajen correctamente.

Liberar o entregar. Esto incluye el progresivo soporte y mantencin del producto.
Generalmente, es la fase ms larga del ciclo de vida.




Figura 1.5.: Esquematizacin del Modelo en Cascada.


Algunos paradigmas alternativos.

El modelo de cascada se ha criticado por tomar demasiado tiempo (entre la definicin
de requerimientos y la entrega del producto), tiende a enfocar la atencin internamente en
vez de hacerlo con los clientes (usuarios finales), y guiarse por una excesiva documentacin.
Se han propuesto o tratado otras alternativas para desarrollar software [Sommer-1991]
[Press-1993B] [Sander-1994] [Macas-1997] .

Algunas de las alternativas ms destacadas (como un vistazo general para el alumno),
son:

27

Modelo Incremental o Prototipos.
Consiste en construir rpidamente, prototipos casi-desechables para estudiar la factibilidad y
aprender lecciones de diseo. En un proceso de desarrollo incremental, los clientes
identifican, a grandes rasgos, las funcionalidades o los servicios que proporcionar el
sistema. Identifican qu servicios son ms importantes y cules menos. Este planteamiento
es, con frecuencia, usado para permitir que los clientes avalen la interfaz de usuario del
producto en una etapa temprana del desarrollo.
Algunos prototipos pueden convertirse en productos, o luego, en partes claves del producto.
As la prototipificacin introduce reiteracin rpida como una manera de aprender antes de
construir el producto final (y pueden experimentar con el Sistema). Esto puede proveer
una rpida realimentacin al desarrollo, y ayudar a acortar el tiempo entre los requerimientos
y la implementacin.
Este modelo tiene varias ventajas [Cabre-2013] , sin embargo, demanda una mayor
organizacin y puede ser una seleccin costosa. Permite superar algunas dificultades del
modelo cascada, mediante la entrega del software en etapas. En algunos casos, no es
posible liberar partes que utilizan el resto del sistema. Adems, si los incrementos son muy
pequeos (entre versin y versin), las repetidas pruebas pueden incrementar el costo del
proyecto.

Modelo en Espiral.
Fue desarrollado por Boehm [Press-2001], para cubrir las mejores caractersticas del modelo
clsico como de la creacin de prototipos, y se agreg un nuevo elemento: el anlisis de
riesgo. Difiere del modelo incremental en todas las fases (incluyendo las fases de
requerimientos y diseo, que se repiten). Esto es utilizado cuando los requerimientos iniciales
son pobremente entendidos o inestables. En este caso, la planificacin es muy importante, en
asegurar que la evolucin converge hacia la solucin deseada (que cada cambio pueda ser
acomodado).
El modelo, que se representa mediante una espiral, define cuatro actividades: planificacin y
definicin, anlisis de riesgo, ingeniera y evaluacin del cliente. Cada ciclo en la espiral
representa una fase del proceso de software. Con cada iteracin alrededor de la espiral
(comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del
software, cada vez ms completas.

28




Figura 1.6.: Esquematizacin del Modelo basado en Prototipos.





Figura 1.7.: Esquematizacin del Modelo en Espiral.


29

Modelo basado en componentes.
Este enfoque se basa en la existencia de un nmero significativo de componentes
reutilizables. El proceso de desarrollo del sistema se enfoca en integrar estos componentes
en el sistema ms que en desarrollarlos desde cero [Press-2001] [Sommer-2005] .
Este modelo consiste en construir sistemas genricos reusables y permitir a los clientes
aprovisionar, personalizar, o cambiar el producto para favorecer sus cambiantes
necesidades mediante tablas, archivos configurables, plantillas, y lenguajes para
personalizar (ampliables por el cliente), entre otros. Los generadores de aplicaciones y de
programas, son ejemplos de esta categora. Algunas veces estos componentes son
sistemas por s mismos (sistemas comerciales) que se pueden utilizar para proporcionar una
funcionalidad especfica, como dar formato al texto o efectuar clculos numricos.

La ingeniera del software basada en componentes tiene la ventaja obvia de reducir la
cantidad de software a desarrollarse y as reduce los costos y los riesgos. Por lo general,
tambin permite una entrega ms rpida del software. Sin embargo, los compromisos en los
requerimientos son inevitables, y esto puede dar lugar a un sistema que no cumpla con
todas las necesidades del cliente/usuario. En el proceso se pueden identificar algunas
etapas intermedias (ver Figura 1.8.), tales como: anlisis de componentes, modificacin de
los requerimientos, diseo del sistema con reutilizacin, y desarrollo e integracin

Modelo Orientado a Objetos.
Un modelo iterativo por naturaleza, e incorpora el enfoque que supone que el nuevo
software se puede construir a partir de una biblioteca de componentes de software re-
usables. Este modelo comienza con una fase de definicin similar a los otros modelos. El
desarrollador y el cliente se renen y definen los objetivos generales para el software;
identifican los requerimientos funcionales, conductuales y de datos que se conocen; y
describen reas donde se requiere ms elaboracin. El anlisis orientado al objeto (OOA),
es una actividad donde se hace un intento para identificar las clases y los objetos claves que
forman parte del dominio del problema. El diseo orientado al objeto (OOD) crea un modelo
de cada componente de programa (objeto) y los mecanismos de comunicacin entre los
objetos [Press-2001] . Basado en el modelo en espiral, las fases OOA y OOD se producen
iterativamente hasta que se haya desarrollado un modelo de diseo razonable para el sistema
[Sommer-2005] . Vase el esquema de la Figura 1.9.


30



Figura 1.8.: Esquema del Modelo basado en Componentes.



Figura 1.9.: Esquematizacin del Modelo Orientado a Objetos.

31

Modelo CleanRoom (sala limpia o libre de errores).
Es un modelo en el cual se han combinado la especificacin y verificacin formal de
programas, y el aseguramiento de calidad (SQA) estadstico, para el desarrollo de software
de alta calidad con fiabilidad certificada. Desarrollado inicialmente por IBM [Press-2001],
consiste en traducir los requerimientos del cliente a una especificacin matemtica
(lenguaje), de los datos del problema, funcin y comportamiento; se evala entonces la
representacin matemtica de requerimientos, para comprobar que est completa y que sea
consistente. Una vez que se han validado los requerimientos contra las necesidades del
cliente, el modelo formal se traduce en una representacin de lenguaje de programacin
apropiado. Debido a que existe el modelo formal, el cdigo fuente resultante puede ser
"probado" para que corresponda con el modelo de requerimientos. De esta manera, el
software implementado se puede validar en forma directa contra los requerimientos del sistema
que en s han sido formalmente especificados usando un enfoque matemtico.

En el proceso de sala limpia, cada incremento del software se especifica formalmente, y esta
especificacin se transforma en una implementacin. La correccin del software se
demuestra utilizando un enfoque formal. Focaliza la atencin en la prevencin en lugar de la
correccin de errores, y la certificacin de la fiabilidad del software para el entorno de uso
para cual fue planeado. En lugar de realizar pruebas de unidades y mdulos, se especifican
formalmente componentes de software los cuales son verificados matemticamente en
cuanto son construidos. El modelo se muestra en la Figura 1.10. El modelo de sala limpia
es particularmente apropiado para el desarrollo de sistemas que tienen estrictos
requerimientos de seguridad, fiabilidad o proteccin.

Otros Modelos.
Si el alumno investiga en la literatura especializada, podr encontrar otros modelos para el
proceso de software.

Existe el MSF (Microsoft Solucion Framework). La metodologa MSF es flexible e
interrelacionada con una serie de conceptos, modelos y prcticas de uso, y guas para
disear y desarrollar soluciones empresariales de una manera que asegura que todos los
elementos del proyecto, tales como gente, procesos y herramientas, puedan ser
exitosamente conducidos.


32
El MSF, que est compuesto por seis fases [Cabre-2013] no slo es aplicable al desarrollo
de proyectos de desarrollo, tambin es aplicable a otros proyectos de TI, como el despliegue
o proyectos de infraestructura o redes. MSF no fuerza al desarrollador a utilizar una
metodologa especfica (Cascada, gil), pero les permite decidir qu mtodo utilizar.

Existe un Modelo de Desarrollo gil, que se origin a mediados de los aos 1990, extrado
del modelo de desarrollo en cascada, pues ste ltimo era visto como burocrtico, lento,
degradante e inconsistente por lo exigente y muy estructurado en sus formas de desarrollo
de software, que sin embargo realizaban un trabajo eficiente.
En el ao 2001, miembros prominentes de la comunidad de la industria del software se
reunieron en Sonwbird, Utah, y adoptaron el nombre de "Metodologas giles". El modelo de
desarrollo gil es un paradigma de Desarrollo de Software que utiliza procesos giles
(pequeas y frecuentes entregas con ciclos rpidos) enfocados en la gente y resultados.
Las metodologas ms conocidas son: XP, Scrum, y RAD [Press-2001] [Cabre-2013] .

Figura 1.10.: Esquema del Modelo Clean-Room.
33

1.2.3 LA EVOLUCION DE LOS ESTANDARES.

La importancia del software es una parte integral y necesaria de muchos productos
y sistemas, requiere un marco comn internacional, para especificar las mejores prcticas
de los procesos de software, actividades y tareas. Debido al crecimiento de los estndares
en los ltimos aos, es importante que los ingenieros de software entiendan qu es lo que
proporciona el estndar ISO 12.207, y cmo se relaciona con otros estndares que tratan con
los procesos de ciclo de vida. Esta norma no fomenta o especifica ningn modelo concreto de
ciclo de vida, gestin del software o mtodo de ingeniera, ni prescribe cmo realizar ninguna
actividad. La ISO 12.207 presenta un marco de referencia para el proceso del ciclo de vida
del software [Lopez-2012] .

Histricamente, el Departamento de la Defensa (DoD) de los EE.UU. fue el pionero en
definir los ciclos de vida del desarrollo de software, y en las ltimas dcadas emprendi un
esfuerzo para unificar la DoD-STD-2167A (usada por la comunidad de misin crtica) y la MIL-
STD-7935 (usada por la comunidad de sistemas de informacin) para crear un estndar de
ciclo de vida: la MIL-STD-498. Posteriormente, el DoD cambi sus polticas de adquisicin
hacia ms confiabilidad en los estndares comerciales. Entonces, la IEEE y la Asociacin de
Industria Electrnica (EIA) iniciaron un proyecto conjunto para un reemplazo comercial de la
STD-498. Este esfuerzo produjo un estndar con dos nombres: un Estndar de Uso de
Pruebas IEEE (la 1498) y un Estndar Provisional EIA. Dado que IEEE y EIA produjeron el
estndar, el Instituto de Estndares Nacional Norteamericano (ANSI) design el documento
como un Estndar Conjunto J-016 ANSI. Mientras tanto, la ISO 12.207 se encontraba en
desarrollo.

En la Figura 1.11. se muestra cmo han ido evolucionando los distintos estndares
acerca del ciclo de vida del software [Moore96]; y lo ms importante, es como se estableci
un consenso en este tema. En 1987, en una sesin plenaria de la ISO, la delegacin
norteamericana solicit al International Software Engineering Standards Group el desarrollo
de una norma relativa al proceso del ciclo de vida del software. En 1989, se constituy el
Grupo de Trabajo 7 para iniciar el proyecto.




34

MIL 1679 DoD 2167
MIL 7935
DoD
2167-A
IEEE
1074
MIL 498
ISO
12207
Rev ISO
12207
Rev IEEE
1074
IEEE 1496
EIA 640
ANSI J-016
Adap.EEUU
de 12207
Implementacin
EEUU de 12207
ESTANDARES DoD
ESTANDARES IEEE
COMERCIALIZACION IEEE/EIA
de ESTANDARES DoD
ESTANDARES EE.UU.
ESTANDARES I.S.O.
Vigente
a 1996
EVOLUCION:
Basado en
Influenciado por
Idntico a


Fig.1.11. Estndares del Ciclo de Vida.



La ISO 12.207 es una de las normas internacionales ms interesantes para la
ingeniera del software (titulada Software Life-Cycle Processes); y proporciona una
estructura de procesos que utiliza una terminologa mutuamente aceptada, ms que imponer
un modelo de ciclo de vida en particular o un mtodo de desarrollo de software. Dado que es
un documento de un nivel ms bien alto, este estndar no especifica los detalles de cmo
efectuar las actividades y tareas que comprenden los procesos. Tampoco prescribe el
nombre, formato o contenido de la documentacin. Por lo tanto, las organizaciones que
buscan aplicar la 12.207 pudieran desear usar estndares o procedimientos adicionales que
especifiquen dichos detalles. La normativa ISO/IEC se encuentra en la actualidad
desarrollando tales guas y procedimientos de evaluacin constantemente, y la ltima versin
corresponde a la 12207:2004.



ISO/IEC
12207:2004
35

Este estndar ofrece un marco de referencia para los procesos de ciclo de vida del
software desde el momento de su concepcin hasta su retiro del servicio. Es, en especial,
apropiado para adquisiciones debido a que reconoce los diferentes roles del comprador y del
proveedor [EstPia-1995] . De hecho, el estndar tiene como fin ser usado por dos partes,
donde un contrato o acuerdo define el desarrollo, mantenimiento u operacin de un sistema de
software. No es aplicable a la compra de productos de software tipo paquetes (o envasado).

En la mayora de los casos, la 12.207 usa el lenguaje convencional de estndares:
"shall" para indicar provisiones obligatorias, "should" para recomendaciones y "may" para
acciones permitidas. Puesto que el estndar se aplica tanto al comprador como al proveedor,
se podra esperar que imponga requerimientos obligatorios a ambas partes. Sin embargo, su
lenguaje hace una distincin sutil, aquellas provisiones que se aplican al comprador usan, en
forma tpica, "will", denotando una "declaracin de propsito o intencin por una de las partes",
y no un requerimiento.

En forma bsica y original, la ISO 12207 describa cinco "procesos primarios":
adquisicin, suministro, desarrollo, mantenimiento y operacin. Divide los cinco procesos en
"actividades", y las actividades en "tareas", mientras impone requerimientos en su ejecucin.
Tambin especifica ocho "procesos de apoyo": documentacin, administracin de la
configuracin, aseguramiento de la calidad, verificacin, validacin, revisin conjunta, auditora
y solucin de problemas; como tambin cuatro "procesos organizacionales": administracin,
infraestructura, mejoramiento y recursos humanos (entrenamiento) [EstPia-1995] [Lopez-
2012] . Vase la Figura 1.12. Ms detalles actualizados, se pueden encontrar en la literatura
especializada.

El estndar ISO pretende que las organizaciones adecen estos diecisiete procesos
para que alcancen el objetivo final de sus proyectos particulares, eliminando todas las
actividades no aplicables; y define el acatamiento de la 12.207 como la ejecucin de esos
procesos, actividades y tareas seleccionadas por un ajuste a la medida.
Como los estndares estn sometidos continuamente a revisiones y mejoras, la ltima
versin de la ISO/IEC 12207:2004, contempla diez procesos de soporte, y siete procesos
organizacionales.



36



Figura 1.12.: Procesos de la Norma ISO/IEC 12.207


El estndar es independiente de tecnologas y de metodologas de desarrollo y son
tiles para cualquier forma de modelo de ciclo de vida, por ejemplo, cascada, incremental,
espiral, etc. De hecho, una de las responsabilidades del proveedor del servicio es la de
seleccionar un modelo de ciclo de vida y mapear los requerimientos del estndar 12207 a ese
ciclo de vida en particular, por lo que sus actividades pueden ser llevadas a cabo de forma
secuencial, repetida y combinndolas acorde a la seleccin del proyecto del modelo del ciclo
de vida.

Finalmente, el estndar 12207 se relaciona con normas de calidad, especialmente la
ISO 9001: Sistemas de calidad modelos para la garanta de calidad en la concepcin,
desarrollo, produccin, instalacin y prestacin de servicios. Adems, tiene una gran relacin
con la segunda parte de la norma ISO/IEC 15504: Tecnologas de la informacin - Evaluacin
de los procesos de software.


37
1.3. EL PROCESO UNIFICADO DE RATIONAL (RUP).

1.3.1. INTRODUCCION.

En la actualidad, la utilizacin de ciertas metodologas para el desarrollo de
aplicaciones de software es casi imposible omitirla, debido a la gran necesidad de controlar
el conjunto de variables que conlleva todo el proceso de desarrollo, y de estar en
competitividad en todo momento. Como se ha planteado en esta Unidad, es de suma
importancia conocer el modo como se interrelacionan metodologas con estndares y
herramientas siguiendo un nico objetivo, el cual consiste en la elaboracin de aplicaciones
de software de manera eficiente, ordenada y con el menor nmero de defectos.

Las metodologas y estndares utilizados en un desarrollo de software nos
proporcionan las guas para poder conocer todo el camino a recorrer desde antes de
empezar la implementacin, con lo cual se asegura la calidad del producto final, as como
tambin el cumplimiento en la entrega del mismo en un tiempo estipulado.
Una metodologa conocida como RUP nos proporciona disciplinas (o flujos de trabajo)
en las cuales se encuentran productos entregables, con lo cual se podr contar con guas
para poder documentar e implementar de una manera fcil y eficiente, todas las fases para
un buen desarrollo. Es de suma importancia elegir la metodologa adecuada, as como las
herramientas de implementacin adecuadas, es por ello que la metodologa RUP basada en
UML nos proporciona todas las bases para llevar al xito la elaboracin del software.

Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de
Rational). Es un producto del proceso de ingeniera de software que proporciona un
enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin de
desarrollo de software. Es un ejemplo de un modelo de proceso moderno; y se le considera
hbrido, pues rene varios elementos; y su meta es asegurar la produccin del software de
alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo
establecidos. Esta metodologa RUP (marca registrada por IBM), se fue desarrollando y
refinando con el tiempo, basado en numerosos proyectos desde los aos 1970 a 1980;
mejorando finalmente con la incorporacin del concepto del modelado del negocio, y
adoptando a UML como lenguaje de modelado. Una visin resumida de su historia se
muestra en la Figura 1.13. [Palen-2011].


38



Figura 1.13.: Evolucin de la Metodologa RUP.



La metodologa RUP persigue una forma disciplinada de asignar tareas y
responsabilidades (quin hace qu, cundo y cmo). Adems:
Pretende implementar las mejores prcticas en Ingeniera de Software;
Fomenta el desarrollo iterativo;
Sistematiza la administracin de los requisitos;
Persigue el uso de arquitectura basada en componentes;
Asegura un adecuado control de cambios;
Establece la verificacin de la calidad del software.

Se basa en ciertos Principios de Desarrollo, los que pueden conocerse en detalle, en
la literatura especializada [Palen-2011] [Limach-2012] :
Adaptar el proceso
Equilibrar prioridades
Demostrar valor iterativamente
Colaboracin entre equipos
Elevar el nivel de abstraccin
Enfocarse en la calidad




39

1.3.2. CICLO DE VIDA.

El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una
nueva versin del producto; cada ciclo est compuesto por fases y cada una de estas fases
est compuesta por un nmero de iteraciones.
El RUP tiene tres dimensiones (o perspectivas):

El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del
proceso; representa el aspecto dinmico del proceso, y se expresa en trminos de fases, de
iteraciones, y la finalizacin de las fases.
El eje vertical representa las disciplinas, que agrupan actividades definidas
lgicamente por la naturaleza; representa el aspecto esttico del proceso, y se describe en
trminos de componentes de proceso, las disciplinas, las actividades, los flujos de trabajo,
los entregables, y los roles.
Y una perspectiva prctica, que sugiere un conjunto de buenas prcticas a utilizar
durante el proceso de software.






Figura 1.14.: Dimensiones de la Metodologa RUP.

40

En la Fig. 1.14. se ensea cmo vara el nfasis de cada disciplina en un cierto plazo
en el tiempo, y durante cada una de las fases. Por ejemplo, en iteraciones tempranas, se
pasa ms tiempo en requerimientos, y en las ltimas iteraciones se pasa ms tiempo en
poner en prctica la realizacin del proyecto en si (implementacin y pruebas).

El ciclo de vida del software, segn la metodologa RUP se descompone en cuatro
fases secuenciales dentro de las cuales se realizan varias iteraciones en nmero variable
segn el proyecto y en las que se hace un mayor o menor hincapi en las distintas
actividades. Las primeras iteraciones (en 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 base de inicio.
Las fases son:

FASE DE INICIO
Se define el mbito y los objetivos del proyecto; se define la funcionalidad y las capacidades
del producto a obtener.
Durante esta fase de inicio las iteraciones se centran con mayor nfasis en las actividades
de modelamiento de la empresa (negocio) y en sus requerimientos.

FASE DE ELABORACIN
Tanto la funcionalidad como el dominio del problema se estudian en profundidad. Se define
una arquitectura bsica, y se planifica el proyecto considerando los recursos disponibles.
Durante esta fase de elaboracin, las iteraciones se centran en el desarrollo de la base del
diseo, acotan ms los flujos de trabajo de los requerimientos, el modelo de la organizacin,
y el anlisis, diseo y una parte de implementacin orientada como base de la construccin.

FASE DE CONSTRUCCIN
El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de
anlisis, diseo e implementacin. Las fases de estudio y anlisis slo generaron una
arquitectura bsica, que es refinada aqu de manera incremental conforme se construye (se
permiten cambios en la estructura). Gran parte del trabajo es programacin y pruebas.
Esta fase proporciona un producto construido junto con la documentacin. Se documenta
tanto el sistema construido como el manejo (operacin) del mismo.

41
Durante esta fase de construccin, se lleva a cabo la construccin del producto por medio de
una serie de iteraciones, en las cuales se seleccionan algunos Casos de Uso, se redefine su
anlisis y diseo, y se procede a su implantacin y pruebas. En esta fase se realiza una
pequea cascada para cada ciclo, se realizan tantas iteraciones hasta que se termine una
nueva implementacin del producto.

FASE DE TRANSICIN
Se libera el producto y se entrega al usuario para un uso real. Se incluyen tareas de
marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, y
mantenimiento. Los manuales de usuario se completan y se refinan con la informacin
anterior; estas tareas se realizan tambin en iteraciones
Durante esta fase de transicin se busca garantizar que se tiene un producto preparado para
su entrega final al usuario.


El RUP es un producto de Rational (empresa de IBM). Se caracteriza por ser iterativo
e incremental, est centrado en la arquitectura y guiado por los casos de uso (como se
explica ms adelante). Incluye entregables (que son los productos tangibles del proceso
como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que
desempea una persona en un determinado momento; una persona puede desempear
distintos roles a lo largo del proceso).

Como se aprecia en la Figura 1.14., el RUP comprende 2 aspectos importantes por
los cuales se establecen las disciplinas (o flujos de trabajo):
Proceso: Las etapas consideradas en esta seccin son:
Modelado de negocio
Requisitos
Anlisis y Diseo
Implementacin
Pruebas
Despliegue
Soporte: En esta parte se consideran las siguientes etapas:
Gestin del cambio y configuraciones
Gestin del proyecto
Entorno

42

La metodologa RUP es ms apropiada para proyectos grandes (aunque tambin
pueden se menores, dado que requiere un equipo de trabajo capaz de administrar un
proceso complejo en varias etapas. En proyectos pequeos, es posible que no se puedan
cubrir los costos de dedicacin del equipo de todos los profesionales necesarios.

El RUP define, para el xito de los proyectos, una gran cantidad de roles:

Analistas: tales como: Analista de procesos de negocio; Diseador del negocio; Analista de
sistema; y/o Especificador de requisitos.
Desarrolladores: tales como: Arquitecto de software; Diseador (de mdulos; de interfaz de
usuario; de base de datos); Implementador y/o Integrador.
Gestores: tales como: 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/o Gestor de pruebas.
Apoyo: tales como: Documentador tcnico; Administrador de sistema; Especialista en
herramientas; Desarrollador de cursos; y/o Diseador grfico.
Especialista en pruebas:
Especialista en Pruebas (tester)
Analista de pruebas
Diseador de pruebas.
Otros roles:
Stakeholders.
Revisores ; Coordinador de revisiones
Revisor tcnico

Como se mencion, el RUP, junto con describirse desde una perspectiva dinmica
(que muestra las fases del modelo sobre el tiempo), y una perspectiva esttica (que muestra
las actividades del proceso que se representan), tambin se incluye una perspectiva
prctica, que sugiere buenas prcticas a utilizar durante el proceso.

La perspectiva prctica en el RUP describe buenas prcticas de la ingeniera del
software que son aconsejables en el desarrollo de sistemas. Se recomiendan seis buenas
prcticas fundamentales [Limach-2012] :


43
1. Desarrolle el software de forma iterativa. Planifique incrementos del sistema basado en
las prioridades del usuario y del desarrollo, y entregue las caractersticas del sistema de ms
alta prioridad al inicio del proceso de desarrollo.
2. Gestione los requerimientos. Documente explcitamente los requerimientos del cliente y
mantngase al tanto de los cambios de estos requerimientos. Analice el impacto de los
cambios en el sistema antes de aceptarlos.
3. Utilice arquitecturas basadas en componentes. Estructure la arquitectura del sistema
en componentes existentes y reutilizables, que facilitan el desarrollo rpido.
4. Modele el software visualmente. Utilice modelos grficos UML para presentar vistas
estticas y dinmicas del software.
5. Verifique la calidad del software. Asegure que el software cumple los estndares de
calidad organizacionales (propios, o externos).
6. Controle los cambios del software. Gestione los cambios del software usando un
sistema de gestin de cambios y procedimientos y herramientas de gestin de
configuraciones (incluya el rol del SCM).

El RUP no es un proceso apropiado para todos los tipos de desarrollo sino que representa
una nueva generacin de procesos genricos. Las innovaciones ms importantes son la
separacin de fases y los flujos de trabajo, y el reconocimiento de que la utilizacin del
software en un entorno del usuario es parte del proceso. Las fases son dinmicas y tienen
objetivos. Los flujos de trabajo son estticos y son actividades tcnicas que no estn
asociadas con fases nicas sino que pueden utilizarse durante el desarrollo para alcanzar
los objetivos de cada fase.


1.3.3. CARACTERSTICAS ESENCIALES QUE DEFINEN AL RUP

Proceso Dirigido por los Casos de Uso.

Segn algunos especialistas [Palen-2011] [Limach-2012] , los Casos de Uso son una tcnica
de captura de requisitos que fuerza a pensar en trminos de importancia para el usuario, y
no slo en trminos de funciones que debe contemplar el Sistema. . Los Casos de Uso
representan los requisitos funcionales del sistema; y se pueden definir como un fragmento
de funcionalidad del sistema que proporciona al usuario un valor agregado.


44
En RUP, los Casos de Uso no son slo una herramienta para especificar los requisitos del
sistema. Tambin guan su diseo, la implementacin y las pruebas. Los Casos de Uso
constituyen un elemento integrador y una gua del trabajo; vase la Figura 1.15.

Los Casos de Uso no slo inician el proceso de desarrollo sino que proporcionan un hilo
conductor, permitiendo establecer trazabilidad entre los productos entregables que son
generados en las diferentes actividades del proceso de desarrollo.




Figura 1.15.: Casos de Uso en el Modelo RUP.


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 (ingenieros,
desarrolladores y usuarios), y una perspectiva clara del sistema completo, necesaria para
controlar todo el proceso de desarrollo. La arquitectura involucra los aspectos estticos y
dinmicos ms significativos del sistema; est relacionada con la toma de decisiones que
indican 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 de
software, el sistema operativo, el gestor de bases de datos, los protocolos, y otras
consideraciones de desarrollo como los sistemas heredados (antiguos).


45
Proceso Iterativo e Incremental.

El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al
equilibrio que debe existir entre la forma y la funcin en el desarrollo del producto, lo cual 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 el equilibrio entre los casos de Uso y la 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 fundamentales), del cual se obtiene un incremento que produce un
crecimiento en el producto. Una iteracin puede realizarse por medio de una cascada, como
se muestra en la Figura 1.16. Se pasa por los flujos fundamentales (Requisitos, Anlisis,
Diseo, Implementacin y Pruebas). Tambin existe una planificacin de la iteracin, un
anlisis de la iteracin y algunas actividades especficas de la iteracin; y al finalizar se
realiza una integracin de los resultados con lo obtenido de las iteraciones anteriores.
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; determinando si han
aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones
siguientes.



Figura 1.16.: El RUP es un proceso iterativo e incremental.



46
En resumen, la metodologa RUP divide el proceso en cuatro fases, 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 hincapi en los distintas actividades. El esfuerzo humano
asociado a las disciplinas (flujos), va variando segn la fase en la que se encuentre el
proyecto.

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; y se realizan tantas iteraciones hasta que se termine la implementacin de la
nueva versin del producto.

Finalmente, el alumno deber comprender que, existen varios modelos para el
proceso de desarrollo de software, y que estos modelos se van perfeccionando
constantemente; y adems, complementndose entre ellos. Lo importante, es que para
desarrollar un buen software, se hace necesario contar con un modelo y una metodologa
para desarrollarlo.













47
REFERENCIAS



[ANTIMA-1997] = Antimn, Patricio: Mejoramiento de los Procesos de Documentacin y
Calidad del Software en la Industria Chilena; Memoria Ttulo Ingeniero Civil Informtico,
Depto.de Informtica; U.T.F.S.M.; Valparaso, 1997.

[BARTLE-1991] = Bartley, Steven: Cuanto vale el Software; Suplemento Computacin
N 131; Diario Estrategia; Santiago, Junio 1991.

[BORIA-1988] = Boria, Jorge: INGENIERIA DE SOFTWARE; Editorial Kapelutz; Buenos
Aires, 1988.

[CABRE-2013] = Cabrera, Armando et. al.: Procesos de Ingeniera de Software;
Publicacin de la Universidad de Ecuador.
Extrado el 15.01.2013 de: www.slideshare.net/rfsolano/procesos-de-ingenieria-del-software

[DAVIS-1995] = Davis, Alan M.: 201 PRINCIPLES OF SOFTWARE DEVELOPMENT;
McGraw-Hill, Inc., New York, 1995 .

[ESTPIA-1995] = Esteban, Jos & Piattini, Mario: Procesos del Ciclo de Vida del Software,
Revista Novtica, N 118 ; Barcelona, Noviembre/Diciembre 1995 . Pgs. 39-44.

[GUERRE-1994] = Guerrero, Jos; Calidad del Proceso de Desarrollo de Software; XVII
Taller de Ingeniera de Sistemas, Universidad de Chile; Santiago, Julio 1994.

[GUERRE-1995] = Guerrero, Luciano: Procesos de Calidad en la Ingeniera de Software;
Seminario, XVIII Taller de Ingeniera de Sistemas, Universidad de Chile; Santiago, 1995.

[INN90-1995] = Instituto Nacional de Normalizacin: Norma NCh-ISO 9000-1, Parte 1: Gua
para la Seleccin y Uso; I.N.N.; Santiago, 1995 .

[IPL-1996] = Staff Editorial: Software Testing and Software Development Life-Cycles; Serie
Software Testing WhitePapers, Information Processing Ltd.; Bath, Gran Bretaa; Septiembre
1996.

[ISOIEC-1995] = International Standards Organization - Internat. Electrothecnical Comis-sion;
Standard 12207: Software Lyfe-Cycle Processes; ISO/IEC Press; Ginebra 1995.

[JENNER-1995] = Jenner, Michael; SOFTWARE QUALITY MANAGEMENT AND ISO 9001;
John Wiley, Inc.; New York, 1995 .

[KEYES-1995] = Keyes, Jessica; SOLVING THE PRODUCTIVITY PARADOX; Editorial
McGraw-Hill; New York, 1995. Capits. 1, 13 y 14 .

[LIMACH-2012] = Limachi, Bernando: Metodologa RUP; Material del Curso Anlisis de
Sistemas II; Extrado el 15.01.2013 de:
www.slideshare.net/bernardolimachi/metodologia-rup-14288208

[LOPEZ-2012] = Lopez, Marcos: Ciclo de Vida del Software; Tema 2; Material del Curso
Ingeniera de Software I; Universidad Rey Juan Carlos; Madrid.
Extrado el 15.01.2013 de: http://www.kybele.etsii.urjc.es/docencia/IS4/
48

[MACIAS-1997] = Macas, Santiago: Rediseo del Proceso de Software en un Entorno de
Produccin Automtico y Formal Basado en Objetos; Tesis de Magister en Ingeniera
Informtica, Depto.de Informtica; U.T.F.S.M.; Valparaso, Enero 1997.

[NTP-2006] = Staff : NTPISO/IEC 12207; Comisin de Reglamentos Tcnicos y
Comerciales Lima, Per; 2006. Extrado el 15.01.2013 de:
www.bvindecopi.gob.pe/normas/isoiec12207.pdf

[PALEN-2011] = Palencia, Johanna, et. al.: RUP: Rational Unified Process; Material Curso
de Ingeniera de Software.
Extrado el 15.01.2013 de: www.slideshare.net/angel2365/exposrup

[PARRA-1995] = Parra, Claudio: SPM : Modelamiento del Proceso de Software; Memoria
Ttulo Ingeniero Civil Informtico, Depto.de Informtica; U.T.F.S.M.; Valparaso, 1995.

[PRESS-1993A] = Pressman, Roger: INGENIERIA DEL SOFTWARE; 3ra. edicin; Editorial
McGraw-Hill; New York, 1993. Capits. 1 y 10.

[PRESS-1993B] = Pressman, Roger: A MANAGERS GUIDE FOR SOFTWARE
MANAGER; Editorial McGraw-Hill; New York, 1993. Capts. 1 y 2 .

[PRESS-2001] = Pressman, Roger: INGENIERIA DEL SOFTWARE, UN ENFOQUE
PRACTICO; 5ta. edicin; Editorial McGraw-Hill; Madrid, 2001. Capits. 1, 2 y Parte 5ta.

[SANDER-1994] = Sanders, Joc & Curran, Eugene: SOFTWARE QUALITY; Addison-Wesley
Co.; Gran Bretaa, 1994 .

[SOMMER-1991] = Somerville, Ian: SOFTWARE ENGINEERING; 3ra.edicin, Addison-
Wesley Co.; Massachusetts; 1991. Capit. 1.

[SOMMER-2005] = Somerville, Ian: INGENIERIA DE SOFTWARE; 7ma.edicin, Editorial
Parson; Madrid; 2005. Parte I.

[YEH-1993] = Yeh, Hsiong-Tao: SOFTWARE PROCESS QUALITY ; Editorial McGraw-Hill;
New York, 1993. Capit. 1 .