C AP Í T UL O 2 MODELOS DEL PROCESO 45

no funcionales de los componentes. Los aspectos comunes y sistémicos incluyen interfaces de usua-
rio, trabajo en colaboración, distribución, persistencia, administración de la memoria, procesamiento
de las transacciones, seguridad, integridad, etc. Los componentes pueden proveer o requerir uno o
más “detalles de aspectos” en relación con un aspecto particular, como un mecanismo de visión, al-
cance extensible y clase de interfaz (aspectos de la interfaz de usuario); generación de eventos, trans-
porte y recepción (aspectos de distribución); almacenamiento, recuperación e indización de datos
(aspectos de persistencia); autenticación, encriptación y derechos de acceso (aspectos de seguridad);
descomposición de las transacciones, control de concurrencia y estrategia de registro (aspectos de las
transacciones), entre otros. Cada detalle del aspecto tiene cierto número de propiedades relacionadas
con las características funcionales o no del detalle del aspecto.

Aún no madura un proceso distinto orientado a aspectos. Sin embargo, es probable que un
proceso así adopte características tanto de los modelos de proceso evolutivo como concurrente.
El modelo evolutivo es apropiado en tanto los aspectos se identifican y después se construyen.
La naturaleza paralela del desarrollo concurrente es esencial porque la ingeniería de aspectos
se hace en forma independiente de los componentes de software localizados; aun así, los as-
pectos tienen un efecto directo sobre éstos. De esta forma, es esencial disponer de comunica-
ción asincrónica entre las actividades de proceso del software aplicadas a la ingeniería, y la
construcción de los aspectos y componentes.
El análisis detallado del desarrollo de software orientado al aspecto se deja a libros especia-
lizados en el tema. Si el lector tiene interés en profundizar, se le invita a consultar [Saf08],
[Cla05], [Jac04] y [Gra03].

H ERRAMIENTAS DE SOFTWARE
Administración del proceso (www.informatik.uni-bremen.de/uniform/gdpa/
home.htm), proporciona una amplia variedad de funciones
Objetivo: Ayudar a la definición, ejecución y administra-
para modelar y administrar procesos.
ción de modelos de proceso prescriptivo.
SpeeDev, desarrollada por SpeeDev Corporation (www.speedev.
Mecánica: Las herramientas de administración del proceso permiten com), incluye un conjunto de herramientas para la definición del
que una organización o equipo de software defina un modelo com- proceso, administración de los requerimientos, resolución de pro-
pleto del proceso (actividades estructurales, acciones, tareas, asegura- blemas, y planeación y seguimiento del proyecto.
miento de la calidad, puntos de revisión, referencias y productos del
ProVision BPMx, desarrollado por Proforma (www.proforma-
trabajo). Además, las herramientas proporcionan un mapa conforme
corp.com), es representativo de muchas herramientas que ayu-
los ingenieros de software realizan el trabajo técnico, y una plantilla
dan a definir el proceso y que automatizan el flujo del trabajo.
para los gerentes que deben dar seguimiento y controlar el proceso
del software. En la dirección www.processwave.net/Links/tool_links.
htm, se encuentra una lista extensa de muchas herramientas dife-
Herramientas representativas: 17
rentes asociadas con el proceso del software.
GDPA, grupo de herramientas de investigación de definición del pro-
ceso, desarrollada por la Universidad de Bremen, en Alemania

2. 5 EL PROCESO UNIFICADO

En su libro fundamental, Unified Process, Ivar Jacobson, Grady Booch y James Rumbaugh [Jac99]
analizan la necesidad de un proceso del software “impulsado por el caso de uso, centrado en la
arquitectura, iterativo e incremental”, con la afirmación siguiente:

17 Las herramientas mencionadas aquí no representan una obligación; sólo son una muestra de las de esta catego-
ría. En la mayoría de casos, los nombres de las herramientas son marcas registradas por sus desarrolladores
respectivos.

www.FreeLibros.me

02Pressman(025-054).indd 45 14/1/10 13:36:51

 46 PAR T E UN O E L PR OCESO DEL SOFT WARE

En la actualidad, la tendencia en el software es hacia sistemas más grandes y complejos. Eso se debe
en parte al hecho de que año tras año las computadoras son más poderosas, lo que hace que los
usuarios esperen más de ellas. Esta tendencia también se ha visto influida por el uso creciente de in-
ternet para intercambiar toda clase de información […] Nuestro apetito por software cada vez más
sofisticado aumenta conforme aprendemos, entre un lanzamiento y otro de un producto, cómo mejo-
rar éste. Queremos software que se adapte mejor a nuestras necesidades, pero eso a su vez lo hace
más complejo. En pocas palabras, queremos más.

En cierto modo, el proceso unificado es un intento por obtener los mejores rasgos y caracterís-
ticas de los modelos tradicionales del proceso del software, pero en forma que implemente
muchos de los mejores principios del desarrollo ágil de software (véase el capítulo 3). El proceso
unificado reconoce la importancia de la comunicación con el cliente y los métodos directos para
describir su punto de vista respecto de un sistema (el caso de uso).18 Hace énfasis en la impor-
tancia de la arquitectura del software y “ayuda a que el arquitecto se centre en las metas correc-
tas, tales como que sea comprensible, permita cambios futuros y la reutilización” [Jac99]: Su-
giere un flujo del proceso iterativo e incremental, lo que da la sensación evolutiva que resulta
esencial en el desarrollo moderno del software.

2.5.1 Breve historia

Al principio de la década de 1990, James Rumbaugh [Rum91], Grady Booch [Boo94] e Ivar Jacob-
son [Jac92] comenzaron a trabajar en un “método unificado” que combinaría lo mejor de cada
uno de sus métodos individuales de análisis y diseño orientado a objetos. El resultado fue un
UML, lenguaje de modelado unificado, que contiene una notación robusta para el modelado y
desarrollo de los sistemas orientados a objetos.
El UML se utiliza en toda la parte 2 del libro para representar tanto los modelos de requeri-
mientos como el diseño. En el apéndice 1 se presenta un método introductorio a la enseñanza
para quienes no están familiarizados con las reglas básicas de notación y modelado con el UML.
El estudio exhaustivo del UML se deja a libros dedicados al tema. En el apéndice 1 se enlistan
los textos recomendables.
El UML brinda la tecnología necesaria para apoyar la práctica de la ingeniería de software
orientada a objetos, pero no da la estructura del proceso que guíe a los equipos del proyecto
cuando aplican la tecnología. En los siguientes años, Jacobson, Rumbaugh y Booch desarrolla-
ron el proceso unificado, estructura para la ingeniería de software orientado a objetos que utiliza
UML. Actualmente, el proceso unificado (PU) y el UML se usan mucho en proyectos de toda clase
orientados a objetos. El modelo iterativo e incremental propuesto por el PU puede y debe adap-
tarse para que satisfaga necesidades específicas del proyecto.

2.5.2 Fases del proceso unificado19

PU Al principio de este capítulo se estudiaron cinco actividades estructurales generales y se dijo que
NT
O podían usarse para describir cualquier modelo de proceso del software. El proceso unificado no
CLAVE es la excepción. La figura 2.9 ilustra las “fases” del PU y las relaciona con las actividades gene-
Las fases del PU tienen un objetivo rales estudiadas en el capítulo 1 y al inicio de éste.
similar al de las actividades
La fase de concepción del PU agrupa actividades tanto de comunicación con el cliente como
estructurales generales definidas en
este libro. de planeación. Al colaborar con los participantes, se identifican los requerimientos del negocio,

18 El caso de uso (véase el capítulo 5) es la narración o plantilla que describe una función o rasgo de un sistema
desde el punto de vista del usuario. Éste escribe un caso en uso que sirve como base para la creación de un
modelo de requerimientos más completos.
19 El proceso unificado en ocasiones recibe el nombre de Proceso Racional Unificado (PRU), acuñado por Rational
Corporation (adquirida posteriormente por IBM), que contribuyó desde el principio al desarrollo y mejora del PU
y a la elaboración de ambientes completos (herramientas y tecnología) que apoyan el proceso.

www.FreeLibros.me

02Pressman(025-054).indd 46 14/1/10 13:36:51

 C AP Í T UL O 2 MODELOS DEL PROCESO 47

FIGURA 2.9
Elaboración
El proceso
unificado
Concepción

ación
plane mode
lado

ión
nicac ucció
n
comu constr

egue Construcción
despli

Lanzamiento Transición
incremento del software

Producción

se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la natura-
leza iterativa e incremental del proyecto en cuestión. Los requerimientos fundamentales del
negocio se describen por medio de un conjunto de casos de uso preliminares (véase el capítulo
5) que detallan las características y funciones que desea cada clase principal de usuarios. En este
punto, la arquitectura no es más que un lineamiento tentativo de subsistemas principales y la
función y rasgos que tienen. La arquitectura se mejorará después y se expandirá en un conjunto
de modelos que representarán distintos puntos de vista del sistema. La planeación identifica los
recursos, evalúa los riesgos principales, define un programa de actividades y establece una base
para las fases que se van a aplicar a medida que avanza el incremento del software.
La fase de elaboración incluye las actividades de comunicación y modelado del modelo gene-
ral del proceso (véase la figura 2.9). La elaboración mejora y amplía los casos de uso prelimina-
res desarrollados como parte de la fase de concepción y aumenta la representación de la arqui-
tectura para incluir cinco puntos de vista distintos del software: los modelos del caso de uso, de
requerimientos, del diseño, de la implementación y del despliegue. En ciertos casos, la elabora-
ción crea una “línea de base de la arquitectura ejecutable” [Arl02] que representa un sistema
ejecutable de “primer corte”.20 La línea de base de la arquitectura demuestra la viabilidad de ésta,
pero no proporciona todas las características y funciones que se requieren para usar el sistema.
Además, al terminar la fase de elaboración se revisa con cuidado el plan a fin de asegurar que
el alcance, riesgos y fechas de entrega siguen siendo razonables. Es frecuente que en este mo-
mento se hagan modificaciones al plan.
WebRef La fase de construcción del PU es idéntica a la actividad de construcción definida para el pro-
En la dirección www.ambysoft. ceso general del software. Con el uso del modelo de arquitectura como entrada, la fase de
com/unifiedprocess/agileUP. construcción desarrolla o adquiere los componentes del software que harán que cada caso
html, se encuentra un análisis
de uso sea operativo para los usuarios finales. Para lograrlo, se completan los modelos de re-
interesante del PU en el contexto del
desarrollo ágil. querimientos y diseño que se comenzaron durante la fase de elaboración, a fin de que reflejen
la versión final del incremento de software. Después se implementan en código fuente todas las
características y funciones necesarias para el incremento de software (por ejemplo, el lanza-
miento). A medida de que se implementan los componentes, se diseñan y efectúan pruebas
unitarias21 para cada uno. Además, se realizan actividades de integración (ensamble de compo-

20 Es importante darse cuenta de que la línea de base de la arquitectura no es un prototipo y que no se desecha. Por
el contrario, es revestida durante la fase siguiente del PU.
21 En los capítulos 17 a 20 se presenta el análisis exhaustivo de las pruebas del software (incluso las pruebas unita-
rias).

www.FreeLibros.me

02Pressman(025-054).indd 47 14/1/10 13:36:51

 48 PAR T E UN O E L PR OCESO DEL SOFT WARE

nentes y pruebas de integración). Se emplean casos de uso para obtener un grupo de pruebas
de aceptación que se ejecutan antes de comenzar la siguiente fase del PU.
La fase de transición del PU incluye las últimas etapas de la actividad general de construcción
y la primera parte de la actividad de despliegue general (entrega y retroalimentación). Se da el
software a los usuarios finales para las pruebas beta, quienes reportan tanto los defectos como
los cambios necesarios. Además, el equipo de software genera la información de apoyo nece-
saria (por ejemplo, manuales de usuario, guías de solución de problemas, procedimientos de
instalación, etc.) que se requiere para el lanzamiento. Al finalizar la fase de transición, el soft-
ware incrementado se convierte en un producto utilizable que se lanza.
La fase de producción del PU coincide con la actividad de despliegue del proceso general.
Durante esta fase, se vigila el uso que se da al software, se brinda apoyo para el ambiente de
operación (infraestructura) y se reportan defectos y solicitudes de cambio para su evaluación.
Es probable que al mismo tiempo que se llevan a cabo las fases de construcción, transición
y producción, comience el trabajo sobre el siguiente incremento del software. Esto significa que
las cinco fases del PU no ocurren en secuencia sino que concurren en forma escalonada.
El flujo de trabajo de la ingeniería de software está distribuido a través de todas las fases del
PU. En el contexto de éste, un flujo de trabajo es análogo al conjunto de tareas (que ya se descri-
bió en este capítulo). Es decir, un flujo de trabajo identifica las tareas necesarias para completar
una acción importante de la ingeniería de software y los productos de trabajo que se generan
como consecuencia de la terminación exitosa de aquéllas. Debe notarse que no toda tarea iden-
tificada para el flujo de trabajo del PU es realizada en todos los proyectos de software. El equipo
adapta el proceso (acciones, tareas, subtareas y productos del trabajo) a fin de que cumpla sus
necesidades.

2. 6 MODELOS DEL PROCESO PERSONAL Y DEL EQUIPO

El mejor proceso del software es el que está cerca de las personas que harán el trabajo. Si un
modelo del proceso del software se ha desarrollado en un nivel corporativo u organizacional,
será eficaz sólo si acepta una adaptación significativa para que cubra las necesidades del equipo
de proyecto que en realidad hace el trabajo de ingeniería de software. En la situación ideal se
Cita: crearía un proceso que se ajustara del mejor modo a los requerimientos, y al mismo tiempo
“La persona que es exitosa tan cubriera las más amplias necesidades del equipo y de la organización. En forma alternativa, el
sólo se ha hecho el hábito de equipo crearía un proceso propio que satisficiera las necesidades más estrechas de los indivi-
hacer las cosas que no hacen las duos y las más generales de la organización. Watts Humphrey ([Hum97] y [Hum00]) afirma que
personas que no tienen éxito.” es posible crear un “proceso personal de software” y/o un “proceso del equipo de software”.
Dexter Yager Ambos requieren trabajo duro, capacitación y coordinación, pero los dos son asequibles.22

2.6.1 Proceso personal del software (PPS)

Todo desarrollador utiliza algún proceso para elaborar software de cómputo. El proceso puede
ser caprichoso o ad hoc; quizá cambie a diario; tal vez no sea eficiente, eficaz o incluso no sirva;
pero sí existe un “proceso”. Watts Humphrey [Hum97] sugiere que a fin de cambiar un proceso
WebRef personal ineficaz, un individuo debe pasar por las cuatro fases, cada una de las cuales requiere
En la dirección www.ipd.uka.de/ capacitación e instrumentación cuidadosa. El proceso personal del software (PPS) pone el énfasis
PSP, se hallan muchos recursos para en la medición personal tanto del producto del trabajo que se genera como de su calidad. Ade-
el PPS.
más, el PPS responsabiliza al profesional acerca de la planeación del proyecto (por ejemplo,

22 Es útil notar que quienes proponen un desarrollo ágil del software (véase el capítulo 3) también plantean que el
proceso debe ser cercano al equipo. Para lograr esto sugieren un método alternativo.

www.FreeLibros.me

02Pressman(025-054).indd 48 14/1/10 13:36:51