CAPÍTULO CA P Í T UL O 2 M O D E LO S D E L P R OC E SO 27

2 M ODELOS
DEL PROCESO
2. 1 UN MODELO GENERAL DE PROCESO

En el capítulo 1 se definió un proceso como la colección de actividades de trabajo, acciones y

tareas que se realizan cuando va a crearse algún producto terminado. Cada una de las activida-
des, acciones y tareas se encuentra dentro de una estructura o modelo que define su relación

E
tanto con el proceso como entre sí.
CONCEPTOS CLAVE n un libro fascinante que expone el punto de vista de un economista sobre el software
En la figura 2.1 se representa el proceso del software de manera esquemática. En dicha fi-
conjunto de tareas. . . . . . . . . 29 y su ingeniería, Howard Baetjer, Jr. [Bae98] comenta acerca del proceso del software.
gura, cada actividad estructural está formada por un conjunto de acciones de ingeniería de
desarrollo basado
software y cada una de éstas se encuentra definida por un conjunto de tareas que identifica las
en componentes . . . . . . . . . . 43
Debido a que el software, como todo capital, es conocimiento incorporado y a que el conocimiento PU tareas del trabajo que deben realizarse, los productos del trabajo que se producirán, los puntos
modelo de métodos NT
originalmente se halla disperso, tácito, latente e incompleto en gran medida, el desarrollo de software O
formales. . . . . . . . . . . . . . . . 44 de aseguramiento de la calidad que se requieren y los puntos de referencia que se utilizarán para
es un proceso de aprendizaje social. El proceso es un diálogo en el que el conocimiento que debe CLAVE evaluar el avance.
modelo general de proceso. . . 27
convertirse en software se reúne e incorpora en éste. El proceso genera interacción entre usuarios y La jerarquía del trabajo técnico
modelos concurrentes . . . . . . 40 Como se dijo en el capítulo 1, una estructura general para la ingeniería de software define
diseñadores, entre usuarios y herramientas cambiantes, y entre diseñadores y herramientas en evolu- dentro del proceso del software es:
modelos de proceso actividades, acciones que contiene y cinco actividades estructurales: comunicación, planeación, modelado, construcción y
ción [tecnología]. Es un proceso que se repite y en el que la herramienta que evoluciona sirve por sí
evolutivo . . . . . . . . . . . . . . . 36 tareas constituyentes. despliegue. Además, a lo largo de todo el proceso se aplica un conjunto de actividades som-
misma como medio para la comunicación: con cada nueva ronda del diálogo se genera más cono-
modelos de proceso
cimiento útil a partir de las personas involucradas.
incremental. . . . . . . . . . . . . . 35
modelos de proceso En realidad, la elaboración de software de computadora es un proceso reiterativo de apren-
prescriptivo . . . . . . . . . . . . . 33
dizaje social, y el resultado, algo que Baetjer llamaría “capital de software”, es la reunión de FIGURA 2.1
patrones del proceso . . . . . . . 29
conocimiento recabado, depurado y organizado a medida que se realiza el proceso. Estructura de un
Proceso del software
proceso del equipo proceso del
Pero desde el punto de vista técnico, ¿qué es exactamente un proceso del software? En el
de software . . . . . . . . . . . . . 49
contexto de este libro, se define proceso del software como una estructura para las actividades, software Estructura del proceso
proceso personal
del software. . . . . . . . . . . . . 48 acciones y tareas que se requieren a fin de construir software de alta calidad. ¿“Proceso” es si-
proceso unificado . . . . . . . . . 45 nónimo de “ingeniería de software”? La respuesta es “sí y no”. Un proceso del software define Actividades sombrilla
el enfoque adoptado mientras se hace ingeniería sobre el software. Pero la ingeniería de soft-
actividad estructural # 1
ware también incluye tecnologías que pueblan el proceso: métodos técnicos y herramientas
acción de ingeniería de software # 1.1
automatizadas.
tareas del trabajo
Más importante aún, la ingeniería de software es llevada a cabo por personas creativas y productos del trabajo
Conjuntos
preparadas que deben adaptar un proceso maduro de software a fin de que resulte apropiado de tareas
puntos de aseguramiento de la calidad
puntos de referencia del proyecto
para los productos que construyen y para las demandas de su mercado.

acción de ingeniería de software # 1.k

tareas del trabajo
UNA Conjuntos productos del trabajo
puntos de aseguramiento de la calidad
MIRADA ¿Qué es? Cuando se trabaja en la construc- ¿Cuáles son los pasos? En un nivel detallado, el proceso de tareas puntos de referencia del proyecto

RÁPIDA
ción de un producto o sistema, es importante que se adopte depende del software que se esté elaboran-
ejecutar una serie de pasos predecibles —el do. Un proceso puede ser apropiado para crear software
mapa de carreteras que lo ayuda a obtener a destinado a un sistema de control electrónico de un aero-
tiempo un resultado de alta calidad—. El mapa que se plano, mientras que para la creación de un sitio web será
sigue se llama “proceso del software”. necesario un proceso completamente distinto.
¿Quién lo hace? Los ingenieros de software y sus geren- ¿Cuál es el producto final? Desde el punto de vista de actividad estructural # n
tes adaptan el proceso a sus necesidades y luego lo un ingeniero de software, los productos del trabajo son los acción de ingeniería de software # n.1
siguen. Además, las personas que solicitaron el software programas, documentos y datos que se producen como tareas del trabajo
tienen un papel en el proceso de definición, elaboración y consecuencia de las actividades y tareas definidas por el Conjuntos productos del trabajo
puntos de aseguramiento de la calidad
prueba. proceso. de tareas puntos de referencia del proyecto
¿Por qué es importante? Porque da estabilidad, control ¿Cómo me aseguro de que lo hice bien? Hay cierto
y organización a una actividad que puede volverse caótica número de mecanismos de evaluación del proceso del
acción de ingeniería de software # n.m
si se descontrola. Sin embargo, un enfoque moderno de software que permiten que las organizaciones determinen
ingeniería de software debe ser “ágil”. Debe incluir sólo la “madurez” de su proceso. Sin embargo, la calidad, tareas del trabajo
productos del trabajo
aquellas actividades, controles y productos del trabajo que oportunidad y viabilidad a largo plazo del producto que Conjuntos
puntos de aseguramiento de la calidad
sean apropiados para el equipo del proyecto y para el se elabora son los mejores indicadores de la eficacia del de tareas puntos de referencia del proyecto
producto que se busca obtener. proceso que se utiliza.

26
28 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E L O S D E L PR O CE S O 29

brilla: seguimiento y control del proyecto, administración de riesgos, aseguramiento de la cali- paralelo con otras (por ejemplo, el modelado de un aspecto del software tal vez se ejecute
dad, administración de la configuración, revisiones técnicas, entre otras. en paralelo con la construcción de otro aspecto del software).
El lector debe observar que aún no se menciona un aspecto importante del proceso del soft-
Cita: ware. En la figura 2.2 se ilustra dicho aspecto —llamado flujo del proceso— y se describe la 2.1.1 Definición de actividad estructural
“Pensamos que los desarrolla- manera en que están organizadas las actividades estructurales y las acciones y tareas que ocu-
Aunque en el capítulo 1 se describieron cinco actividades estructurales y se dio una definición
dores de software pierden de rren dentro de cada una con respecto de la secuencia y el tiempo.
básica de cada una, un equipo de software necesitará mucha más información antes de poder
vista una verdad fundamental: Un flujo de proceso lineal ejecuta cada una de las cinco actividades estructurales en secuencia,
la mayor parte de organizacio- ejecutar de manera apropiada cualquiera de ellas como parte del proceso del software. Por
comenzando por la comunicación y terminando con el despliegue (véase la figura 2.2a). Un flujo
nes no saben lo que hacen. tanto, surge una pregunta clave: ¿qué acciones son apropiadas para una actividad estructural,
de proceso iterativo repite una o más de las actividades antes de pasar a la siguiente (véase la
Piensan que lo saben, pero no dados la naturaleza del problema por resolver, las características de las personas que hacen el tra-
es así.” figura 2.2b). Un flujo de proceso evolutivo realiza las actividades en forma “circular”. A través de
bajo y los participantes que patrocinan el proyecto?
las cinco actividades, cada circuito lleva a una versión más completa del software (véase la fi-
Para un proyecto de software pequeño solicitado por una persona (en una ubicación remota)
Tom DeMarco
gura 2.2c). Un flujo de proceso paralelo (véase la figura 2.2d) ejecuta una o más actividades en ? ¿Cómo se transforma
una actividad con requerimientos sencillos y directos, la actividad de comunicación tal vez no incluya algo
estructural cuando más que una llamada telefónica con el participante apropiado. Entonces, la única acción nece-
cambia la naturaleza saria es una conversación telefónica, y las tareas del trabajo (el conjunto de tareas) que engloba
del proyecto?
son las siguientes:
FIGURA 2.2 Flujo del proceso
1. Hacer contacto con el participante por vía telefónica.

Comunicación Planeación Modelado Construcción Despliegue 2. Analizar los requerimientos y tomar notas.
3. Organizar las notas por escrito en una formulación breve de los requerimientos.
a) Flujo de proceso lineal 4. Enviar correo electrónico al participante para que revise y apruebe.

Si el proyecto fuera considerablemente más complejo, con muchos participantes y cada uno
Comunicación Planeación Modelado Construcción Despliegue con un distinto conjunto de requerimientos (a veces en conflicto), la actividad de comunicación
puede tener seis acciones distintas (descritas en el capítulo 5): concepción, indagación, elabora-
PU ción, negociación, especificación y validación. Cada una de estas acciones de la ingeniería del
NT
O software tendrá muchas tareas de trabajo y un número grande de diferentes productos finales.
b) Flujo de proceso iterativo CLAVE
Diferentes proyectos demandan 2.1.2 Identificación de un conjunto de tareas
diferentes conjuntos de tareas. El
equipo de software elige el conjunto En relación con la figura 2.1, cada acción de la ingeniería de software (por ejemplo, obtención,
Planeación
Modelado de tareas con base en las asociada a la actividad de comunicación) se representa por cierto número de distintos conjuntos
características del problema y el de tareas, cada uno de los cuales es una colección de tareas de trabajo de la ingeniería de soft-
proyecto. ware, relacionadas con productos del trabajo, puntos de aseguramiento de la calidad y puntos
Comunicación
de referencia del proyecto. Debe escogerse el conjunto de tareas que se adapte mejor a las ne-
cesidades del proyecto y a las características del equipo. Esto implica que una acción de la in-
Incremento geniería de software puede adaptarse a las necesidades específicas del proyecto de software y
Despliegue Construcción
obtenido a las características del equipo del proyecto.

c) Flujo de proceso evolutivo 2.1.3 Patrones del proceso

Cada equipo de software se enfrenta a problemas conforme avanza en el proceso del software.
Comunicación Planeación ? ¿Qué es un patrón del
proceso? Si se demostrara que existen soluciones fáciles para dichos problemas, sería útil para el equipo
abordarlos y resolverlos rápidamente. Un patrón del proceso1 describe un problema relacionado
con el proceso que se encuentra durante el trabajo de ingeniería de software, identifica el am-
biente en el que surge el problema y sugiere una o más soluciones para el mismo. Dicho de
Modelado Tiempo
manera general, un patrón de proceso da un formato [Amb98]: un método consistente para
describir soluciones del problema en el contexto del proceso del software. Al combinar patro-
nes, un equipo de software resuelve problemas y construye el proceso que mejor satisfaga las

Construcción Despliegue
necesidades de un proyecto.

d) Flujo de proceso paralelo 1 En el capítulo 12 se hace el análisis detallado de los patrones.

30 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E L O S D E L PR O CE S O 31

I NFOR MACIÓN 3. Patrón de fase: define la secuencia de las actividades estructurales que ocurren dentro
del proceso, aun cuando el flujo general de las actividades sea de naturaleza iterativa.
Conjunto de tareas 3. Formar la lista preliminar de las funciones y características con
base en las aportaciones del participante. Un ejemplo de patrón de fase es ModeloEspiral o Prototipos.3
Un conjunto de tareas define el trabajo real por efectuar a
fin de cumplir los objetivos de una acción de ingeniería de 4. Programar una serie de reuniones para facilitar la elaboración Contexto inicial. Describe las condiciones en las que se aplica el patrón. Antes de iniciar
software. Por ejemplo, la indagación (mejor conocida como “recabar de las especificaciones de la aplicación.
el patrón: 1) ¿Qué actividades organizacionales o relacionadas con el equipo han ocurrido?
los requerimientos”) es una acción importante de la ingeniería de soft- 5. Celebrar las reuniones.
2) ¿Cuál es el estado de entrada para el proceso? 3) ¿Qué información de ingeniería de soft-
ware que ocurre durante la actividad de comunicación. La meta al 6. Producir en cada reunión escenarios informales de usuario.
7. Afinar los escenarios del usuario con base en la retroalimenta- ware o del proyecto ya existe?
recabar los requerimientos es entender lo que los distintos participan-
tes desean del software que se va a elaborar. ción de los participantes. Por ejemplo, el patrón Planeación (patrón de etapa) requiere que: 1) los clientes y los
Para un proyecto pequeño y relativamente sencillo, el conjunto de 8. Formar una lista revisada de los requerimientos de los partici- ingenieros de software hayan establecido una comunicación colaboradora; 2) haya termi-
tareas para la indagación de requerimientos tendrá un aspecto pare- pantes. nado con éxito cierto número de patrones de tarea [especificado] para el patrón Comuni-
cido al siguiente: 9. Usar técnicas de despliegue de la función de calidad para asig-
cación; y 3) se conozcan el alcance del proyecto, los requerimientos básicos del negocio y
nar prioridades a los requerimientos.
1. Elaborar la lista de participantes del proyecto. 10. Agrupar los requerimientos de modo que puedan entregarse en las restricciones del proyecto.
2. Invitar a todos los participantes a una reunión informal. forma paulatina y creciente. Problema. El problema específico que debe resolver el patrón.
3. Pedir a cada participante que haga una relación de las caracte- 11. Resaltar las limitantes y restricciones que se introducirán al sis-
rísticas y funciones que requiere. Solución. Describe cómo implementar con éxito el patrón. Esta sección describe la forma
tema.
4. Analizar los requerimientos y construir la lista definitiva. 12. Analizar métodos para validar el sistema. en la que se modifica el estado inicial del proceso (que existe antes de implementar el pa-
5. Ordenar los requerimientos según su prioridad. trón) como consecuencia de la iniciación del patrón. También describe cómo se transforma
6. Identificar las áreas de incertidumbre. Los dos conjuntos de tareas mencionados sirven para “recabar los
la información sobre la ingeniería de software o sobre el proyecto, disponible antes de que
requerimientos”, pero son muy distintos en profundidad y formalidad.
Para un proyecto de software más grande y complejo se requerirá inicie el patrón, como consecuencia de la ejecución exitosa del patrón.
El equipo de software elige el conjunto de tareas que le permita
de un conjunto de tareas diferente que quizá esté constituido por las
alcanzar la meta de cada acción con calidad y agilidad. Contexto resultante. Describe las condiciones que resultarán una vez que se haya im-
siguientes tareas de trabajo:
plementado con éxito el patrón: 1) ¿Qué actividades organizacionales o relacionadas con el
1. Hacer la lista de participantes del proyecto.
equipo deben haber ocurrido? 2) ¿Cuál es el estado de salida del proceso? 3) ¿Qué informa-
2. Entrevistar a cada participante por separado a fin de determi-
nar los deseos y necesidades generales. ción sobre la ingeniería de software o sobre el proyecto se ha desarrollado?
Patrones relacionados. Proporciona una lista de todos los patrones de proceso directa-
mente relacionados con éste. Puede representarse como una jerarquía o en alguna forma
Los patrones se definen en cualquier nivel de abstracción.2 En ciertos casos, un patrón puede de diagrama. Por ejemplo, el patrón de etapa Comunicación incluye los patrones de tarea:
Cita: usarse para describir un problema (y su solución) asociado con un modelo completo del proceso EquipoDelProyecto, LineamientosDeColaboración, DefiniciónDeAlcances, Reca-
(por ejemplo, hacer prototipos). En otras situaciones, los patrones se utilizan para describir un barRequerimientos, DescripciónDeRestricciones y CreaciónDeEscenarios.
“La repetición de patrones es
algo muy diferente de la repeti- problema (y su solución) asociado con una actividad estructural (por ejemplo, planeación) o
Usos y ejemplos conocidos. Indica las instancias específicas en las que es aplicable el
ción de las partes. En realidad, una acción dentro de una actividad estructural (estimación de proyectos).
patrón. Por ejemplo, Comunicación es obligatoria al principio de todo proyecto de soft-
las distintas partes serán únicas Ambler [Amb98] ha propuesto un formato para describir un patrón del proceso:
porque los patrones son los mis- ware, es recomendable a lo largo del proyecto y de nuevo obligatoria una vez alcanzada la
mos.” Nombre del patrón. El patrón recibe un nombre significativo que lo describe en el con- actividad de despliegue.
texto del proceso del software (por ejemplo, RevisionesTécnicas).
Christopher Alexander Los patrones de proceso dan un mecanismo efectivo para enfrentar problemas asociados con
Fuerzas. El ambiente en el que se encuentra el patrón y los aspectos que hacen visible el WebRef cualquier proceso del software. Los patrones permiten desarrollar una descripción jerárquica
problema y afectan su solución. En la dirección www.ambysoft. del proceso, que comienza en un nivel alto de abstracción (un patrón de fase). Después se me-
Tipo. Se especifica el tipo de patrón. Ambler [Amb98] sugiere tres tipos: com/processPatternsPage.html jora la descripción como un conjunto de patrones de etapa que describe las actividades estruc-
PU se encuentran recursos amplios sobre
N TO turales y se mejora aún más en forma jerárquica en patrones de tarea más detallados para cada
1. Patrón de etapa: define un problema asociado con una actividad estructural para el los patrones de proceso.
CLAVE proceso. Como una actividad estructural incluye múltiples acciones y tareas del tra- patrón de etapa. Una vez desarrollados los patrones de proceso, pueden reutilizarse para la
Un formato de patrón proporciona un bajo, un patrón de la etapa incorpora múltiples patrones de la tarea (véase a conti- definición de variantes del proceso, es decir, un equipo de software puede definir un modelo de
medio consistente para describir al proceso específico con el empleo de los patrones como bloques constituyentes del modelo
nuación) que son relevantes para la etapa (actividad estructural). Un ejemplo de pa-
patrón. del proceso.
trón de etapa sería EstablecerComunicación. Este patrón incorporaría el patrón de
tarea RecabarRequerimientos y otros más.
2. Patrón de tarea: define un problema asociado con una acción o tarea de trabajo de la
2.2 EVALUACIÓN Y MEJORA DEL PROCESO
ingeniería de software y que es relevante para el éxito de la práctica de ingeniería de
software (por ejemplo, RecabarRequerimientos es un patrón de tarea). La existencia de un proceso del software no es garantía de que el software se entregue a tiempo,
que satisfaga las necesidades de los consumidores o que tenga las características técnicas que

2 Los patrones son aplicables a muchas actividades de la ingeniería de software. El análisis, el diseño y la prueba
de patrones se estudian en los capítulos 7, 9, 10, 12 y 14. Los patrones y “antipatrones” para las actividades de
administración de proyectos se analizan en la parte 4 del libro. 3 Estos patrones de fase se estudian en la sección 2.3.3.
32 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E L O S D E L PR O CE S O 33

I NFOR MACIÓN 2. 3 MODELOS DE PROCESO PRESCRIPTIVO

Ejemplo de patrón de proceso debe hacerse con una solución de software. Los participantes no están
seguros de lo que quieren, es decir, no pueden describir con detalle Los modelos de proceso prescriptivo fueron propuestos originalmente para poner orden en el
El siguiente patrón de proceso abreviado describe un
enfoque aplicable en el caso en el que los participantes los requerimientos del software. caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado
tienen una idea general de lo que debe hacerse, pero no están segu- Solución. Aquí se presentaría una descripción del proceso prototi- cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonable-
ros de los requerimientos específicos de software. po, que se describirá más adelante, en la sección 2.3.3. mente eficaz para los equipos de software. Sin embargo, el trabajo de ingeniería de software y
Nombre del patrón. RequerimientosPocoClaros Contexto resultante. Los participantes aprueban un prototipo de el producto que genera siguen “al borde del caos”.
Intención. Este patrón describe un enfoque para construir un mode- software que identifica los requerimientos básicos (por ejemplo, En un artículo intrigante sobre la extraña relación entre el orden y el caos en el mundo del
lo (un prototipo) que los participantes pueden evaluar en forma itera- modos de interacción, características computacionales, funciones de Cita: software, Nogueira y sus colegas [Nog00] afirman lo siguiente:
tiva, en un esfuerzo por identificar o solidificar los requerimientos de procesamiento). Después de esto, 1) el prototipo quizá evolucione a
través de una serie de incrementos para convertirse en el software de
“Si el proceso está bien, los El borde del caos se define como “el estado natural entre el orden y el caos, un compromiso grande
software.
producción, o 2) tal vez se descarte el prototipo y el software de pro-
resultados cuidarán de sí mis- entre la estructura y la sorpresa” [Kau95]. El borde del caos se visualiza como un estado inestable y
Tipo. Patrón de fase. mos.”
ducción se elabore con el empleo de otro proceso de patrón. parcialmente estructurado […] Es inestable debido a que se ve atraído constantemente hacia el caos
Contexto inicial. Antes de iniciar este patrón deben cumplirse las Takashi Osada o hacia el orden absoluto.
Patrones relacionados. Los patrones siguientes están relaciona-
siguientes condiciones: 1) se ha identificado a los participantes; 2) se
dos con este patrón: ComunicaciónConClientes, DiseñoItera- Tenemos la tendencia de pensar que el orden es el estado ideal de la naturaleza. Esto podría ser
ha establecido un modo de comunicación entre los participantes y el
tivo, DesarrolloIterativo, EvaluaciónDelCliente, Obten-
equipo de software; 3) los participantes han identificado el problema un error […] las investigaciones apoyan la teoría de que la operación que se aleja del equilibrio genera
ciónDeRequerimientos.
general de software que se va a resolver; 4) se ha obtenido el enten- creatividad, procesos autoorganizados y rendimientos crecientes [Roo96]. El orden absoluto significa
dimiento inicial del alcance del proyecto, los requerimientos básicos Usos y ejemplos conocidos. Cuando los requerimientos sean ausencia de variabilidad, que podría ser una ventaja en los ambientes impredecibles. El cambio ocurre
del negocio y las restricciones del proyecto. inciertos, es recomendable hacer prototipos.
cuando hay cierta estructura que permita que el cambio pueda organizarse, pero que no sea tan rígi-
Problema. Los requerimientos son confusos o inexistentes, pero hay da como para que no pueda suceder. Por otro lado, demasiado caos hace imposible la coordinación y
un reconocimiento claro de que existe un problema por resolver y que la coherencia. La falta de estructura no siempre significa desorden.

PU Las implicaciones filosóficas de este argumento son significativas para la ingeniería de software.
NT
O Si los modelos de proceso prescriptivo5 buscan generar estructura y orden, ¿son inapropiados
PU conducirán a características de calidad de largo plazo (véanse los capítulos 14 y 16). Los patro- CLAVE
N para el mundo del software, que se basa en el cambio? Pero si rechazamos los modelos de pro-
TO nes de proceso deben acoplarse con una práctica sólida de ingeniería de software (véase la parte Los modelos de proceso prescriptivo ceso tradicional (y el orden que implican) y los reemplazamos con algo menos estructurado,
CLAVE 2 del libro). Además, el proceso en sí puede evaluarse para garantizar que cumple con ciertos definen un conjunto prescrito de
¿hacemos imposible la coordinación y coherencia en el trabajo de software?
La evaluación busca entender el criterios de proceso básicos que se haya demostrado que son esenciales para el éxito de la in- elementos del proceso y un flujo
estado actual del proceso del predecible para el trabajo del No hay respuestas fáciles para estas preguntas, pero existen alternativas disponibles para los
geniería de software.4
software con el objeto de mejorarlo. proceso. ingenieros de software. En las secciones que siguen se estudia el enfoque de proceso prescrip-
En las últimas décadas se han propuesto numerosos enfoques para la evaluación y mejora
tivo en el que los temas dominantes son el orden y la consistencia del proyecto. El autor los
de un proceso del software:
llama “prescriptivos” porque prescriben un conjunto de elementos del proceso: actividades es-
Método de evaluación del estándar CMMI para el proceso de mejora (SCAMPI, por tructurales, acciones de ingeniería de software, tareas, productos del trabajo, aseguramiento de
? ¿De qué técnicas
formales se dispone sus siglas en inglés): proporciona un modelo de cinco fases para evaluar el proceso: inicio, la calidad y mecanismos de control del cambio para cada proyecto. Cada modelo del proceso
para evaluar el proceso diagnóstico, establecimiento, actuación y aprendizaje. El método SCAMPI emplea el SEI también prescribe un flujo del proceso (también llamado flujo de trabajo), es decir, la manera en
del software? CMMI como la base de la evaluación [SEI00]. la que los elementos del proceso se relacionan entre sí.
Evaluación basada en CMM para la mejora del proceso interno (CBA IPI, por sus si- Todos los modelos del proceso del software pueden incluir las actividades estructurales ge-
Cita: glas en inglés): proporciona una técnica de diagnóstico para evaluar la madurez relativa de nerales descritas en el capítulo 1, pero cada una pone distinto énfasis en ellas y define en forma
una organización de software; usa el SEI CMM como la base de la evaluación [Dun01]. diferente el flujo de proceso que invoca cada actividad estructural (así como acciones y tareas
“Las organizaciones de software de ingeniería de software).
tienen deficiencias significativas SPICE (ISO/IEC 15504): estándar que define un conjunto de requerimientos para la eva-
en su capacidad de capitalizar luación del proceso del software. El objetivo del estándar es ayudar a las organizaciones a
las experiencias obtenidas de los 2.3.1 Modelo de la cascada
desarrollar una evaluación objetiva de cualquier proceso del software definido [ISO08].
proyectos terminados.” Hay veces en las que los requerimientos para cierto problema se comprenden bien: cuando el
ISO9001:2000 para software: estándar genérico que se aplica a cualquier organización
NASA trabajo desde la comunicación hasta el despliegue fluye en forma razonablemente lineal. Esta
que desee mejorar la calidad general de los productos, sistemas o servicios que propor-
situación se encuentra en ocasiones cuando deben hacerse adaptaciones o mejoras bien defi-
ciona. Por tanto, el estándar es directamente aplicable a las organizaciones y compañías de
nidas a un sistema ya existente (por ejemplo, una adaptación para software de contabilidad que
software [Ant06].
es obligatorio hacer debido a cambios en las regulaciones gubernamentales). También ocurre
En el capítulo 30 se presenta un análisis detallado de los métodos de evaluación del software en cierto número limitado de nuevos esfuerzos de desarrollo, pero sólo cuando los requerimien-
y del proceso de mejora. tos están bien definidos y tienen una estabilidad razonable.

4 En la publicación CMMI [CMM07] del SEI, se describen con muchos detalles las características de un proceso del
software y los criterios para un proceso exitoso. 5 Los modelos de proceso prescriptivo en ocasiones son denominados modelos de proceso “tradicional”.
34 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E L O S D E L PR O CE S O 35

FIGURA 2.3 Modelo de la cascada FIGURA 2.4

El modelo en V
Comunicación
inicio del proyecto Planeación
estimación Modelado
recabar los requerimientos análisis Construcción
programación
código Despliegue
seguimiento diseño entrega
Modelado de los Pruebas de
pruebas requerimientos aceptación
asistencia
retroalimentación

Diseño de la Pruebas
El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque sistemático arquitectura del sistema
y secuencial para el desarrollo del software, que comienza con la especificación de los reque-
6

rimientos por parte del cliente y avanza a través de planeación, modelado, construcción y des-
pliegue, para concluir con el apoyo del software terminado (véase la figura 2.3). Diseño de los Pruebas de
PU componentes integración
N Una variante de la representación del modelo de la cascada se denomina modelo en V. En la
TO
figura 2.4 se ilustra el modelo en V [Buc99], donde se aprecia la relación entre las acciones para
CLAVE el aseguramiento de la calidad y aquellas asociadas con la comunicación, modelado y construc-
El modelo en V ilustra la forma en la Generación Pruebas
que se asocian las acciones de ción temprana. A medida que el equipo de software avanza hacia abajo desde el lado izquierdo
de código unitarias
verificación y validación con las de la V, los requerimientos básicos del problema mejoran hacia representaciones técnicas cada
primeras acciones de ingeniería. vez más detalladas del problema y de su solución. Una vez que se ha generado el código, el
equipo sube por el lado derecho de la V, y en esencia ejecuta una serie de pruebas (acciones para
asegurar la calidad) que validan cada uno de los modelos creados cuando el equipo fue hacia
abajo por el lado izquierdo.7 En realidad, no hay diferencias fundamentales entre el ciclo de vida
clásico y el modelo en V. Este último proporciona una forma de visualizar el modo de aplicación Software
de las acciones de verificación y validación al trabajo de ingeniería inicial. ejecutable
El modelo de la cascada es el paradigma más antiguo de la ingeniería de software. Sin em-
bargo, en las últimas tres décadas, las críticas hechas al modelo han ocasionado que incluso sus inapropiado para ese tipo de labor. No obstante, sirve como un modelo de proceso útil en situa-
defensores más obstinados cuestionen su eficacia [Han95]. Entre los problemas que en ocasio- ciones en las que los requerimientos son fijos y el trabajo avanza en forma lineal hacia el final.
nes surgen al aplicar el modelo de la cascada se encuentran los siguientes:
2.3.2 Modelos de proceso incremental
1. Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aun-
? ¿Por qué a veces falla
el modelo de la que el modelo lineal acepta repeticiones, lo hace en forma indirecta. Como resultado, PU
NT
Hay muchas situaciones en las que los requerimientos iniciales del software están razonable-
cascada? los cambios generan confusión conforme el equipo del proyecto avanza. O mente bien definidos, pero el alcance general del esfuerzo de desarrollo imposibilita un proceso
2. A menudo, es difícil para el cliente enunciar en forma explícita todos los requerimien-
CLAVE lineal. Además, tal vez haya una necesidad imperiosa de dar rápidamente cierta funcionalidad
El modelo incremental ejecuta una limitada de software a los usuarios y aumentarla en las entregas posteriores de software. En
tos. El modelo de la cascada necesita que se haga y tiene dificultades para aceptar la in-
serie de avances, llamados
certidumbre natural que existe al principio de muchos proyectos. tales casos, se elige un modelo de proceso diseñado para producir el software en incrementos.
incrementos, que en forma
progresiva dan más funcionalidad al El modelo incremental combina elementos de los flujos de proceso lineal y paralelo estudia-
3. El cliente debe tener paciencia. No se dispondrá de una versión funcional del(de los)
cliente conforme se le entrega cada dos en la sección 2.1. En relación con la figura 2.5, el modelo incremental aplica secuencias li-
programa(s) hasta que el proyecto esté muy avanzado. Un error grande sería desastroso
incremento. neales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia
Cita: si se detectara hasta revisar el programa en funcionamiento.
lineal produce “incrementos” de software susceptibles de entregarse [McD93] de manera pare-
“Con demasiada frecuencia, el En un análisis interesante de proyectos reales, Bradac [Bra94] encontró que la naturaleza cida a los incrementos producidos en un flujo de proceso evolutivo (sección 2.3.3).
trabajo de software sigue la pri- lineal del ciclo de vida clásico llega a “estados de bloqueo” en los que ciertos miembros del Por ejemplo, un software para procesar textos que se elabore con el paradigma incremental
mera ley del ciclismo: no equipo de proyecto deben esperar a otros a fin de terminar tareas interdependientes. En reali- quizá entregue en el primer incremento las funciones básicas de administración de archivos,
importa hacia dónde te dirijas,
dad, ¡el tiempo de espera llega a superar al dedicado al trabajo productivo! Los estados de edición y producción del documento; en el segundo dará herramientas más sofisticadas de edi-
vas hacia arriba y contra el
bloqueo tienden a ocurrir más al principio y al final de un proceso secuencial lineal. ción y producción de documentos; en el tercero habrá separación de palabras y revisión de la
viento.”
Hoy en día, el trabajo de software es acelerado y está sujeto a una corriente sin fin de cambios CONSEJO ortografía; y en el cuarto se proporcionará la capacidad para dar formato avanzado a las pági-
Anónimo (en las características, funciones y contenido de información). El modelo de la cascada suele ser Su cliente solicita la entrega para nas. Debe observarse que el flujo de proceso para cualquier incremento puede incorporar el
una fecha que es imposible de paradigma del prototipo.
cumplir. Sugiera entregar uno o más Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea el pro-
6 Aunque el modelo de la cascada propuesto originalmente por Winston Royce [Roy70] prevé los “bucles de retroa- incrementos en la fecha que pide, y
ducto fundamental. Es decir, se abordan los requerimientos básicos, pero no se proporcionan
limentación”, la gran mayoría de organizaciones que aplican este modelo de proceso lo tratan como si fuera el resto del software (incrementos
estrictamente lineal. adicionales) en un momento muchas características suplementarias (algunas conocidas y otras no). El cliente usa el producto
7 En la parte 3 del libro se estudian con detalle las acciones de aseguramiento de la calidad. posterior. fundamental (o lo somete a una evaluación detallada). Como resultado del uso y/o evaluación,
36 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E L O S D E L PR O CE S O 37

Hacer prototipos. Es frecuente que un cliente defina un conjunto de objetivos generales para
FIGURA 2.5
Comunicación
Cita: el software, pero que no identifique los requerimientos detallados para las funciones y caracte-
El modelo
rísticas. En otros casos, el desarrollador tal vez no esté seguro de la eficiencia de un algoritmo,
incremental Funcionalidad y características del software Planeación “Planee para lanzar uno. De
Modelado (análisis, diseño) todos modos hará eso. Su única de la adaptabilidad de un sistema operativo o de la forma que debe adoptar la interacción entre
incremento # n
elección es si tratará de vender el humano y la máquina. En estas situaciones, y muchas otras, el paradigma de hacer prototipos
Construcción (código, prueba)
a sus clientes lo que lanzó.” tal vez ofrezca el mejor enfoque.
Despliegue (entrega, retroalimentación)
Frederick P. Brooks Aunque es posible hacer prototipos como un modelo de proceso aislado, es más común
entrega del n-ésimo
incremento # 2 incremento usarlo como una técnica que puede implementarse en el contexto de cualquiera de los modelos
de proceso descritos en este capítulo. Sin importar la manera en la que se aplique, el paradigma
entrega del segundo de hacer prototipos le ayudará a usted y a otros participantes a mejorar la comprensión de lo
incremento # 1 incremento
que hay que elaborar cuando los requerimientos no están claros.
El paradigma de hacer prototipos (véase la figura 2.6) comienza con comunicación. Usted se
entrega del primer
incremento CONSEJO reúne con otros participantes para definir los objetivos generales del software, identifica cuales-
Cuando su cliente tiene una quiera requerimientos que conozca y detecta las áreas en las que es imprescindible una mayor
Calendario del proyecto necesidad legítima, pero ignora los definición. Se planea rápidamente una iteración para hacer el prototipo, y se lleva a cabo el
detalles, como primer paso desarrolle modelado (en forma de un “diseño rápido”). Éste se centra en la representación de aquellos
un prototipo.
aspectos del software que serán visibles para los usuarios finales (por ejemplo, disposición de
se desarrolla un plan para el incremento que sigue. El plan incluye la modificación del producto
la interfaz humana o formatos de la pantalla de salida). El diseño rápido lleva a la construcción
fundamental para cumplir mejor las necesidades del cliente, así como la entrega de caracterís-
de un prototipo. Éste se entrega y es evaluado por los participantes, que dan retroalimenta-
ticas adicionales y más funcionalidad. Este proceso se repite después de entregar cada incre-
ción para mejorar los requerimientos. La iteración ocurre a medida de que el prototipo es afi-
mento, hasta terminar el producto final.
nado para satisfacer las necesidades de distintos participantes, y al mismo tiempo le permite a
El modelo de proceso incremental se centra en que en cada incremento se entrega un pro-
usted entender mejor lo que se necesita hacer.
ducto que ya opera. Los primeros incrementos son versiones desnudas del producto final, pero
El ideal es que el prototipo sirva como mecanismo para identificar los requerimientos del
proporcionan capacidad que sirve al usuario y también le dan una plataforma de evaluación.8
software. Si va a construirse un prototipo, pueden utilizarse fragmentos de programas existen-
El desarrollo incremental es útil en particular cuando no se dispone de personal para la im-
tes o aplicar herramientas (por ejemplo, generadores de reportes y administradores de venta-
plementación completa del proyecto en el plazo establecido por el negocio. Los primeros incre-
nas) que permitan generar rápidamente programas que funcionen.
mentos se desarrollan con pocos trabajadores. Si el producto básico es bien recibido, entonces
Pero, ¿qué hacer con el prototipo cuando ya sirvió para el propósito descrito? Brooks [Bro95]
se agrega más personal (si se requiere) para que labore en el siguiente incremento. Además, los
da una respuesta:
incrementos se planean para administrar riesgos técnicos. Por ejemplo, un sistema grande tal
vez requiera que se disponga de hardware nuevo que se encuentre en desarrollo y cuya fecha En la mayoría de proyectos es raro que el primer sistema elaborado sea utilizable. Tal vez sea muy
de entrega sea incierta. En este caso, tal vez sea posible planear los primeros incrementos de lento, muy grande, difícil de usar o todo a la vez. No hay más alternativa que comenzar de nuevo, con
forma que eviten el uso de dicho hardware, y así proporcionar una funcionalidad parcial a los más inteligencia, y construir una versión rediseñada en la que se resuelvan los problemas.
usuarios finales sin un retraso importante.

2.3.3 Modelos de proceso evolutivo

FIGURA 2.6
PU El software, como todos los sistemas complejos, evoluciona en el tiempo. Es frecuente que los
N TO El paradigma de
requerimientos del negocio y del producto cambien conforme avanza el desarrollo, lo que hace
hacer prototipos
CLAVE que no sea realista trazar una trayectoria rectilínea hacia el producto final; los plazos apretados
Plan rápido
El modelo del proceso evolutivo
del mercado hacen que sea imposible la terminación de un software perfecto, pero debe lan- Comunicación
genera en cada iteración una versión
zarse una versión limitada a fin de aliviar la presión de la competencia o del negocio; se com-
final cada vez más completa del Modelado
software. prende bien el conjunto de requerimientos o el producto básico, pero los detalles del producto Diseño rápido
o extensiones del sistema aún están por definirse. En estas situaciones y otras parecidas se
necesita un modelo de proceso diseñado explícitamente para adaptarse a un producto que evo-
luciona con el tiempo.
Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten
Despliegue
desarrollar versiones cada vez más completas del software. En los párrafos que siguen se pre- Entrega y
Construcción
Retroalimentación
sentan dos modelos comunes de proceso evolutivo. del
prototipo

8 Es importante observar que para todos los modelos de proceso “ágiles” que se estudian en el capítulo 3 también
se usa la filosofía incremental.
38 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E L O S D E L PR O CE S O 39

El prototipo sirve como “el primer sistema”. Lo que Brooks recomienda es desecharlo. Pero
esto quizá sea un punto de vista idealizado. Aunque algunos prototipos se construyen para ser Vinod: Sí, y parece demasiado orientado a las tecnologías de Vinod: Eso es un problema. Me preocupa que no nos dé suficiente
“desechables”, otros son evolutivos; es decir, poco a poco se transforman en el sistema real. información… tal vez sea bueno para hacer un sistema de control de estructura.
inventarios o algo así, pero no parece bueno para CasaSegura. Doug: No te preocupes. Tenemos muchas opciones más, y quisiera
Tanto a los participantes como a los ingenieros de software les gusta el paradigma de hacer
prototipos. Los usuarios adquieren la sensación del sistema real, y los desarrolladores logran Doug: Estoy de acuerdo. que ustedes, muchachos, elijan la que sea mejor para el equipo y
Ed: Ese enfoque de hacer prototipos parece bueno. En todo caso, se para el proyecto.
construir algo de inmediato. No obstante, hacer prototipos llega a ser problemático por las si-
asemeja mucho a lo que hacemos aquí.
guientes razones:

1. Los participantes ven lo que parece ser una versión funcional del software, sin darse
CONSEJO cuenta de que el prototipo se obtuvo de manera caprichosa; no perciben que en la prisa
El modelo espiral. Propuesto en primer lugar por Barry Boehm [Boe88], el modelo espiral es
Resista la presión para convertir un por hacer que funcionara, usted no consideró la calidad general del software o la facili-
un modelo evolutivo del proceso del software y se acopla con la naturaleza iterativa de hacer
prototipo burdo en un producto dad de darle mantenimiento a largo plazo. Cuando se les informa que el producto debe
terminado. Como resultado de ello, prototipos con los aspectos controlados y sistémicos del modelo de cascada. Tiene el potencial
rehacerse a fin de obtener altos niveles de calidad, los participantes gritan que es usted
casi siempre disminuye la calidad. para hacer un desarrollo rápido de versiones cada vez más completas. Boehm [Boe01a] describe
un tonto y piden “unos cuantos arreglos” para hacer del prototipo un producto funcio-
el modelo del modo siguiente:
nal. Con demasiada frecuencia, el gerente de desarrollo del software cede.
El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el riesgo, que se
2. Como ingeniero de software, es frecuente que llegue a compromisos respecto de la im-
usa para guiar la ingeniería concurrente con participantes múltiples de sistemas intensivos en soft-
plementación a fin de hacer que el prototipo funcione rápido. Quizá utilice un sistema
ware. Tiene dos características distintivas principales. La primera es el enfoque cíclico para el creci-
operativo inapropiado, o un lenguaje de programación tan sólo porque cuenta con él y
miento incremental del grado de definición de un sistema y su implementación, mientras que dismi-
lo conoce; tal vez implementó un algoritmo ineficiente sólo para demostrar capacidad.
nuye su grado de riesgo. La otra es un conjunto de puntos de referencia de anclaje puntual para
Después de un tiempo, quizá se sienta cómodo con esas elecciones y olvide todas las
asegurar el compromiso del participante con soluciones factibles y mutuamente satisfactorias.
razones por las que eran inadecuadas. La elección de algo menos que lo ideal ahora ha
pasado a formar parte del sistema. Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas.
PU Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las
Aunque puede haber problemas, hacer prototipos es un paradigma eficaz para la ingeniería NT
O iteraciones posteriores se producen versiones cada vez más completas del sistema cuya inge-
de software. La clave es definir desde el principio las reglas del juego; es decir, todos los parti- CLAVE niería se está haciendo.
cipantes deben estar de acuerdo en que el prototipo sirva como el mecanismo para definir los El modelo en espiral se adapta para
Un modelo en espiral es dividido por el equipo de software en un conjunto de actividades
requerimientos. Después se descartará (al menos en parte) y se hará la ingeniería del software emplearse a lo largo de todo el ciclo
de vida de una aplicación, desde el estructurales. Para fines ilustrativos, se utilizan las actividades estructurales generales ya ana-
real con la mirada puesta en la calidad.
desarrollo del concepto hasta el lizadas.9 Cada una de ellas representa un segmento de la trayectoria espiral ilustrada en la figura
mantenimiento. 2.7. Al comenzar el proceso evolutivo, el equipo de software realiza actividades implícitas en un

C ASA S EGURA
FIGURA 2.7
Planeación
Selección de un modelo de proceso, Doug: Es cierto, pero no sin muchos sobresaltos, y este proyecto Modelo de espiral estimación
parte 1 parece más grande y complejo que cualquier cosa que hayamos común programación
hecho antes. análisis de riesgo
La escena: Sala de juntas del grupo de ingeniería de software de Jamie: No parece tan mal, pero estoy de acuerdo… nuestro enfo-
CPI Corporation, compañía (ficticia) que manufactura artículos de que ad hoc de los proyectos anteriores no funcionará en éste, en Comunicación
consumo para el hogar y para uso comercial. particular si tenemos una fecha de entrega muy apretada.
Modelado
Participantes: Lee Warren, gerente de ingeniería; Doug Miller, Doug (sonríe): Quiero ser un poco más profesional en nuestro análisis
gerente de ingeniería de software; Jamie Lazar, miembro del equipo enfoque. La semana pasada asistí a un curso breve y aprendí mucho diseño
de software; Vinod Raman, miembro del equipo de software; y Ed sobre ingeniería de software… algo bueno. Aquí necesitamos un
Robbins, miembro del equipo de software. Inicio
proceso.
La conversación: Jamie (con el ceño fruncido): Mi trabajo es producir progra-
Lee: Recapitulemos. He dedicado algún tiempo al análisis de la mas de computadora, no papel.
línea de productos CasaSegura, según la vemos hasta el momento. Doug: Den una oportunidad antes de ser tan negativos conmigo. Lo Despliegue
No hay duda de que hemos efectuado mucho trabajo tan sólo para Construcción
que quiero decir es esto: [Doug pasa a describir la estructura del entrega
definir el concepto, pero me gustaría que ustedes comenzaran a pen- código
proceso vista en este capítulo y los modelos de proceso prescriptivo retroalimentación prueba
sar en cómo van a enfocar la parte del software de este proyecto. presentados hasta el momento.]
Doug: Pareciera que en el pasado hemos estado muy desorganiza- Doug: De cualquier forma, parece que un modelo lineal no es para
dos en nuestro enfoque del software. nosotros… pues supone que conocemos todos los requerimientos y, 9 El modelo espiral estudiado en esta sección es una variante del propuesto por Boehm. Para más información
Ed: No sé, Doug, siempre sacamos el producto. conociendo esta empresa, eso no parece probable. acerca del modelo espiral original, consulte [Boe88]. En [Boe98] se encuentra un análisis más reciente del modelo
espiral del mismo autor.
40 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E LO S D E L P R OC E SO 41

circuito alrededor de la espiral en el sentido horario, partiendo del centro. El riesgo se considera
conforme se desarrolla cada revolución (capítulo 28). En cada paso evolutivo se marcan puntos
C ASA S EGURA
de referencia puntuales: combinación de productos del trabajo y condiciones que se encuentran Selección de un modelo de proceso, otro incremento. También se ajusta a la naturaleza del producto.
a lo largo de la trayectoria de la espiral. parte 2 Podemos lanzar con rapidez algo al mercado y luego agregar fun-
El primer circuito alrededor de la espiral da como resultado el desarrollo de una especifica- cionalidad con cada versión, digo… con cada incremento.
La escena: Sala de juntas del grupo de ingeniería de software de
ción del producto; las vueltas sucesivas se usan para desarrollar un prototipo y, luego, versiones Lee: Un momento. Doug, ¿dijiste que volveríamos a hacer el plan a
CPI Corporation, compañía que manufactura productos de consumo
cada vez más sofisticadas del software. Cada paso por la región de planeación da como resul- cada vuelta de la espiral? Eso no es nada bueno; necesitamos un
para uso doméstico y comercial.
plan, un programa de actividades y apegarnos a ellos.
tado ajustes en el plan del proyecto. El costo y la programación de actividades se ajustan con Participantes: Lee Warren, gerente de ingeniería; Doug Miller,
Doug: Ésa es la vieja escuela, Lee. Como dijeron los chicos, tene-
base en la retroalimentación obtenida del cliente después de la entrega. Además, el gerente del gerente de ingeniería de software; Vinod y Jamie, miembros del
mos que hacerlo apegado a la realidad. Afirmo que es mejor afinar
proyecto ajusta el número planeado de iteraciones que se requieren para terminar el software. equipo de ingeniería de software.
el plan a medida de que aprendamos más y conforme se soliciten
A diferencia de otros modelos del proceso que finalizan cuando se entrega el software, La conversación: [Doug describe las opciones de proceso evoluti- cambios. Eso es más realista. ¿Qué sentido tiene un plan si no refleja
WebRef
el modelo espiral puede adaptarse para aplicarse a lo largo de toda la vida del software de vo.] la realidad?
En la dirección www.sei.cmu.
edu/publications/ cómputo. Entonces, el primer circuito alrededor de la espiral quizá represente un “proyecto Jamie: Ahora me doy cuenta de algo. El enfoque incremental tiene
Lee (con el ceño fruncido): Supongo, pero… a la alta dirección
documents/00.reports/ sentido, y en verdad me gusta el flujo del modelo en espiral. Es bas-
de desarrollo del concepto” que comienza en el centro de la espiral y continúa por iteraciones no le va a gustar… quieren un plan fijo.
00sr008.html se encuentra tante realista.
información útil sobre el modelo múltiples10 hasta que queda terminado el desarrollo del concepto. Si el concepto va a desarro- Doug (sonriente): Entonces tendrás que reeducarlos, amigo.
Vinod: De acuerdo. Entregamos un incremento, aprendemos de la
espiral. llarse en un producto real, el proceso sigue hacia fuera de la espiral y comienza un “proyecto retroalimentación del cliente, volvemos a planear y luego entregamos
de desarrollo de producto nuevo”. El nuevo producto evolucionará a través de cierto número de
iteraciones alrededor de la espiral. Más adelante puede usarse un circuito alrededor de la espiral
para que represente un “proyecto de mejora del producto”. En esencia, la espiral, cuando se actividad —modelado— puede estar en cualquiera de los estados12 mencionados en un mo-
caracteriza de este modo, sigue operativa hasta que el software se retira. Hay ocasiones en las mento dado. En forma similar, es posible representar de manera análoga otras actividades,
CONSEJO
que el proceso está inmóvil, pero siempre que se inicia un cambio comienza en el punto de acciones o tareas (por ejemplo, comunicación o construcción). Todas las actividades de in-
Si su administración pide un geniería de software existen de manera concurrente, pero se hallan en diferentes estados.
entrada apropiado (por ejemplo, mejora del producto).
desarrollo apegado al presupuesto
(mala idea, por lo general), la El modelo espiral es un enfoque realista para el desarrollo de sistemas y de software a gran
espiral se convierte en un problema. escala. Como el software evoluciona a medida que el proceso avanza, el desarrollador y cliente
El costo se revisa y modifica cada comprenden y reaccionan mejor ante los riesgos en cada nivel de evolución. El modelo espiral
FIGURA 2.8
vez que se termina un circuito. usa los prototipos como mecanismo de reducción de riesgos, pero, más importante, permite Un elemento Inactivo
del modelo
aplicar el enfoque de hacer prototipos en cualquier etapa de la evolución del producto. Mantiene
de proceso Actividad de modelado
el enfoque de escalón sistemático sugerido por el ciclo de vida clásico, pero lo incorpora en una concurrente
estructura iterativa que refleja al mundo real en una forma más realista. El modelo espiral de-
Representa el estado
manda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y, si En de una actividad o
desarrollo tarea de la ingeniería
Cita: se aplica de manera apropiada, debe reducir los riesgos antes de que se vuelvan un problema. de software

“Sólo voy aquí y sólo el mañana Pero, como otros paradigmas, el modelo espiral no es una panacea. Es difícil convencer a los
me guía.” clientes (en particular en situaciones bajo contrato) de que el enfoque evolutivo es controlable.
Cambios
Demanda mucha experiencia en la evaluación del riesgo y se basa en ella para llegar al éxito. en espera
Dave Matthews Band
No hay duda de que habrá problemas si algún riesgo importante no se descubre y administra.

2.3.4 Modelos concurrentes En revisión

El modelo de desarrollo concurrente, en ocasiones llamado ingeniería concurrente, permite que En
un equipo de software represente elementos iterativos y concurrentes de cualquiera de los mo- evaluación
CONSEJO
delos de proceso descritos en este capítulo. Por ejemplo, la actividad de modelado definida para
Con frecuencia, el modelo Alcance mínimo
el modelo espiral se logra por medio de invocar una o más de las siguientes acciones de soft-
concurrente es más apropiado para
proyectos de ingeniería de productos ware: hacer prototipos, análisis y diseño.11
en los que se involucran varios La figura 2.8 muestra la representación esquemática de una actividad de ingeniería de soft-
equipos de trabajo. ware dentro de la actividad de modelado con el uso del enfoque de modelado concurrente. La
Terminado

10 Las flechas que apuntan hacia dentro a lo largo del eje que separa la región del despliegue de la de comunica-
ción indican un potencial para la iteración local a lo largo de la misma trayectoria espiral.
11 Debe observarse que el análisis y diseño son tareas complejas que requieren mucho análisis. La parte 2 de este
libro considera en detalle dichos temas. 12 Un estado es algún modo de comportamiento observable externamente.
42 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E LO S D E L P R OC E SO 43

Por ejemplo, la actividad de comunicación (no se muestra en la figura) termina su primera El objetivo de los modelos evolutivos es desarrollar software de alta calidad14 en forma itera-
iteración al principio de un proyecto y existe en el estado de cambios en espera. La actividad tiva o incremental. Sin embargo, es posible usar un proceso evolutivo para hacer énfasis en la
de modelado (que existía en estado inactivo mientras concluía la comunicación inicial, ahora flexibilidad, expansibilidad y velocidad del desarrollo. El reto para los equipos de software y sus
hace una transición al estado en desarrollo. Sin embargo, si el cliente indica que deben hacerse administradores es establecer un balance apropiado entre estos parámetros críticos del pro-
cambios en los requerimientos, la actividad de modelado pasa del estado en desarrollo al de yecto y el producto, y la satisfacción del cliente (árbitro definitivo de la calidad del software).
cambios en espera.
El modelado concurrente define una serie de eventos que desencadenan transiciones de un
estado a otro para cada una de las actividades, acciones o tareas de la ingeniería de software.
2. 4 MODELOS DE PROCESO ESPECIALIZADO
Por ejemplo, durante las primeras etapas del diseño (acción importante de la ingeniería de soft-
ware que ocurre durante la actividad de modelado), no se detecta una inconsistencia en el Los modelos de proceso especializado tienen muchas de las características de uno o más de los
modelo de requerimientos. Esto genera el evento corrección del modelo de análisis, que disparará modelos tradicionales que se presentaron en las secciones anteriores. Sin embargo, dichos mo-
la acción de análisis de requerimientos del estado terminado al de cambios en espera. delos tienden a aplicarse cuando se elige un enfoque de ingeniería de software especializado
Cita: El modelado concurrente es aplicable a todos los tipos de desarrollo de software y propor- o definido muy específicamente.15
“Todo proceso en su organiza- ciona un panorama apropiado del estado actual del proyecto. En lugar de confinar las activida-
ción tiene un cliente, y un des, acciones y tareas de la ingeniería de software a una secuencia de eventos, define una red
2.4.1 Desarrollo basado en componentes
proceso sin cliente no tiene pro- del proceso. Cada actividad, acción o tarea de la red existe simultáneamente con otras activida-
pósito.” Los componentes comerciales de software general (COTS, por sus siglas en inglés), desarrolla-
des, acciones o tareas. Los eventos generados en cierto punto de la red del proceso desencade- WebRef
V. Daniel Hunt nan transiciones entre los estados. En la dirección www.cbd-hq.com dos por vendedores que los ofrecen como productos, brindan una funcionalidad que se persigue
hay información útil sobre el desarrollo con interfaces bien definidas que permiten que el componente se integre en el software que se
basado en componentes. va a construir. El modelo de desarrollo basado en componentes incorpora muchas de las caracte-
2.3.5 Una última palabra acerca de los procesos evolutivos
rísticas del modelo espiral. Es de naturaleza evolutiva [Nie92] y demanda un enfoque iterativo
Ya se dijo que el software de cómputo moderno se caracteriza por el cambio continuo, por tiem-
para la creación de software. Sin embargo, el modelo de desarrollo basado en componentes
pos de entrega muy apretados y por una necesidad apremiante de la satisfacción del cliente o
construye aplicaciones a partir de fragmentos de software prefabricados.
usuario. En muchos casos, el tiempo para llegar al mercado es el requerimiento administrativo
Las actividades de modelado y construcción comienzan con la identificación de candidatos
más importante. Si se pierde un nicho de mercado, todo el proyecto de software podría carecer
de componentes. Éstos pueden diseñarse como módulos de software convencional o clases
de sentido.13
orientadas a objetos o paquetes16 de clases. Sin importar la tecnología usada para crear los
Los modelos de proceso evolutivo fueron concebidos para cumplir esos requisitos, pero, aun
componentes, el modelo de desarrollo basado en componentes incorpora las etapas siguientes
así, como clase general de modelos de proceso tienen demasiadas debilidades, que fueron re-
(se implementan con el uso de un enfoque evolutivo):
sumidas por Nogueira y sus colegas [Nog00]:
1. Se investigan y evalúan, para el tipo de aplicación de que se trate, productos disponi-
A pesar de los beneficios incuestionables de los procesos evolutivos de software, existen algunas pre-
bles basados en componentes.
ocupaciones. La primera es que hacer prototipos (y otros procesos evolutivos más sofisticados) plantea
un problema para la planeación del proyecto debido a la incertidumbre en el número de ciclos que se 2. Se consideran los aspectos de integración de los componentes.
requieren para elaborar el producto. La mayor parte de técnicas de administración y estimación de pro- 3. Se diseña una arquitectura del software para que reciba los componentes.
yectos se basa en un planteamiento lineal de las actividades, por lo que no se ajustan por completo.
4. Se integran los componentes en la arquitectura.
En segundo lugar, los procesos evolutivos de software no establecen la velocidad máxima de la
5. Se efectúan pruebas exhaustivas para asegurar la funcionalidad apropiada.
evolución. Si las evoluciones ocurren demasiado rápido, sin un periodo de relajamiento, es seguro que
el proceso se volverá un caos. Por otro lado, si la velocidad es muy lenta, se verá perjudicada la pro- El modelo del desarrollo basado en componentes lleva a la reutilización del software, y eso
ductividad… da a los ingenieros de software varios beneficios en cuanto a la mensurabilidad. Si la reutiliza-
En tercer lugar, los procesos de software deben centrarse en la flexibilidad y capacidad de exten- ción de componentes se vuelve parte de la cultura, el equipo de ingeniería de software tiene la
sión en lugar de en la alta calidad. Esto suena preocupante. Sin embargo, debe darse prioridad a la posibilidad tanto de reducir el ciclo de tiempo del desarrollo como el costo del proyecto. En el
velocidad del desarrollo con el enfoque de cero defectos. Extender el desarrollo a fin de lograr alta capítulo 10 se analiza con más detalle el desarrollo basado en componentes.
calidad podría dar como resultado la entrega tardía del producto, cuando haya desaparecido el nicho
de oportunidad. Este cambio de paradigma es impuesto por la competencia al borde del caos.

En realidad, sí parece preocupante un proceso del software que se centre en la flexibilidad, 14 En este contexto, la calidad del software se define con mucha amplitud para que agrupe no sólo la satisfacción
expansión y velocidad del desarrollo por encima de la calidad. No obstante, esta idea ha sido del cliente sino también varios criterios técnicos que se estudian en los capítulos 14 y 16.
propuesta por varios expertos en ingeniería de software muy respetados ([You95], [Bac97]). 15 En ciertos casos, los modelos de proceso especializado pueden caracterizarse mejor como un conjunto de téc-
nicas o “metodología” para alcanzar una meta específica de desarrollo de software. No obstante, implican un
proceso.
13 Sin embargo, es importante notar que ser el primero en llegar al mercado no es garantía de éxito. En realidad, 16 En el apéndice 2 se estudian los conceptos orientados a objetos, y se utilizan en toda la parte 2 del libro. En este
muchos productos de software muy exitosos han llegado en segundo o hasta en tercer lugar al mercado (apren- contexto, una clase agrupa un conjunto de datos y los procedimientos para procesarlos. Un paquete de clases es
den de los errores de sus antecesores). un conjunto de clases relacionadas que funcionan juntas para alcanzar cierto resultado final.
44 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E LO S D E L P R OC E SO 45

2.4.2 El modelo de métodos formales 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
El modelo de métodos formales agrupa actividades que llevan a la especificación matemática
de las transacciones, seguridad, integridad, etc. Los componentes pueden proveer o requerir uno o
formal del software de cómputo. Los métodos formales permiten especificar, desarrollar y veri-
más “detalles de aspectos” en relación con un aspecto particular, como un mecanismo de visión, al-
ficar un sistema basado en computadora por medio del empleo de una notación matemática
cance extensible y clase de interfaz (aspectos de la interfaz de usuario); generación de eventos, trans-
rigurosa. Ciertas organizaciones de desarrollo de software aplican una variante de este enfoque,
porte y recepción (aspectos de distribución); almacenamiento, recuperación e indización de datos
que se denomina ingeniería de software de quirófano [Mil87, Dye92].
(aspectos de persistencia); autenticación, encriptación y derechos de acceso (aspectos de seguridad);
Cuando durante el desarrollo se usan métodos formales (capítulo 21), se obtiene un meca-
descomposición de las transacciones, control de concurrencia y estrategia de registro (aspectos de las
nismo para eliminar muchos de los problemas difíciles de vencer con otros paradigmas de la
transacciones), entre otros. Cada detalle del aspecto tiene cierto número de propiedades relacionadas
ingeniería de software. Lo ambiguo, incompleto e inconsistente se descubre y corrige con más
con las características funcionales o no del detalle del aspecto.
facilidad, no a través de una revisión ad hoc sino con la aplicación de análisis matemático. Si
durante el diseño se emplean métodos formales, éstos sirven como base para la verificación del Aún no madura un proceso distinto orientado a aspectos. Sin embargo, es probable que un
programa, y así permiten descubrir y corregir errores que de otro modo no serían detectados. proceso así adopte características tanto de los modelos de proceso evolutivo como concurrente.
Aunque el modelo de los métodos formales no es el más seguido, promete un software libre El modelo evolutivo es apropiado en tanto los aspectos se identifican y después se construyen.
de defectos. Sin embargo, se han expresado preocupaciones acerca de su aplicabilidad en un La naturaleza paralela del desarrollo concurrente es esencial porque la ingeniería de aspectos
ambiente de negocios: 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-
• El desarrollo de modelos formales consume mucho tiempo y es caro.
? Si con los métodos
formales puede • Debido a que pocos desarrolladores de software tienen la formación necesaria para
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.
demostrarse lo correcto aplicar métodos formales, se requiere mucha capacitación. El análisis detallado del desarrollo de software orientado al aspecto se deja a libros especia-
de un software, ¿por
• Es difícil utilizar los modelos como mecanismo de comunicación para clientes sin lizados en el tema. Si el lector tiene interés en profundizar, se le invita a consultar [Saf08],
qué no son ampliamente
utilizados? complejidad técnica. [Cla05], [Jac04] y [Gra03].

A pesar de estas preocupaciones, el enfoque de los métodos formales ha ganado partidarios

entre los desarrolladores que deben construir software de primera calidad en seguridad (por
H ERRAMIENTAS DE SOFTWARE
ejemplo, control electrónico de aeronaves y equipos médicos), y entre los desarrolladores que
sufrirían graves pérdidas económicas si ocurrieran errores en su 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.
2.4.3 Desarrollo de software orientado a aspectos ción de modelos de proceso prescriptivo.
SpeeDev, desarrollada por SpeeDev Corporation (www.speedev.
Sin importar el proceso del software que se elija, los constructores de software complejo imple- Mecánica: Las herramientas de administración del proceso permiten com), incluye un conjunto de herramientas para la definición del
WebRef
que una organización o equipo de software defina un modelo com- proceso, administración de los requerimientos, resolución de pro-
Existen muchos recursos e información mentan de manera invariable un conjunto de características, funciones y contenido de informa-
pleto del proceso (actividades estructurales, acciones, tareas, asegura- blemas, y planeación y seguimiento del proyecto.
sobre SOA en la dirección: aosd.net ción localizados. Estas características localizadas del software se modelan como componentes miento de la calidad, puntos de revisión, referencias y productos del
(clases orientadas a objetos) y luego se construyen dentro del contexto de una arquitectura de 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-
sistemas. A medida que los sistemas modernos basados en computadora se hacen más sofisti- los ingenieros de software realizan el trabajo técnico, y una plantilla
dan a definir el proceso y que automatizan el flujo del trabajo.
cados (y complejos), ciertas preocupaciones —propiedades que requiere el cliente o áreas de para los gerentes que deben dar seguimiento y controlar el proceso
del software. En la dirección www.processwave.net/Links/tool_links.
interés técnico— se extienden a toda la arquitectura. Algunas de ellas son las propiedades
htm, se encuentra una lista extensa de muchas herramientas dife-
de alto nivel de un sistema (por ejemplo, seguridad y tolerancia a fallas). Otras afectan a funcio- Herramientas representativas:17
rentes asociadas con el proceso del software.
GDPA, grupo de herramientas de investigación de definición del pro-
nes (aplicación de las reglas de negocios), mientras que otras más son sistémicas (sincroniza-
ceso, desarrollada por la Universidad de Bremen, en Alemania
ción de la tarea o administración de la memoria).
PU Cuando las preocupaciones afectan múltiples funciones, características e información del
N TO sistema, es frecuente que se les llame preocupaciones globales. Los requerimientos del aspecto
CLAVE definen aquellas preocupaciones globales que tienen algún efecto a través de la arquitectura del
El DSOA define “aspectos” que software. El desarrollo de software orientado a aspectos (DSOA), conocido también como progra- 2.5 EL PROCESO UNIFICADO
expresan preocupaciones del cliente mación orientada a aspectos (POA), es un paradigma de ingeniería de software relativamente En su libro fundamental, Unified Process, Ivar Jacobson, Grady Booch y James Rumbaugh [Jac99]
que afectan múltiples funciones,
nuevo que proporciona un proceso y enfoque metodológico para definir, especificar, diseñar y analizan la necesidad de un proceso del software “impulsado por el caso de uso, centrado en la
características e información del
construir aspectos: “mecanismos más allá de subrutinas y herencia para localizar la expresión arquitectura, iterativo e incremental”, con la afirmación siguiente:
sistema.
de una preocupación global” [Elr01].
Grundy [Gru02] analiza con más profundidad los aspectos en el contexto de lo que denomina
ingeniería de componentes orientada a aspectos (ICOA):
17 Las herramientas mencionadas aquí no representan una obligación; sólo son una muestra de las de esta catego-
La ICOA usa el concepto de rebanadas horizontales a través de componentes de software descom- ría. En la mayoría de casos, los nombres de las herramientas son marcas registradas por sus desarrolladores
puestos verticalmente, llamados “aspectos”, para caracterizar las propiedades globales funcionales y respectivos.
46 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E LO S D E L P R OC E SO 47

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
FIGURA 2.9
Elaboración
usuarios esperen más de ellas. Esta tendencia también se ha visto influida por el uso creciente de in- El proceso
unificado
ternet para intercambiar toda clase de información […] Nuestro apetito por software cada vez más
Concepción
sofisticado aumenta conforme aprendemos, entre un lanzamiento y otro de un producto, cómo mejo-
ación
rar éste. Queremos software que se adapte mejor a nuestras necesidades, pero eso a su vez lo hace plane mode
lado

más complejo. En pocas palabras, queremos más.

ón
En cierto modo, el proceso unificado es un intento por obtener los mejores rasgos y caracterís- nicaci rucció
n
comu const
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
egue Construcción
unificado reconoce la importancia de la comunicación con el cliente y los métodos directos para despli

describir su punto de vista respecto de un sistema (el caso de uso).18 Hace énfasis en la impor- Lanzamiento Transición
tancia de la arquitectura del software y “ayuda a que el arquitecto se centre en las metas correc- incremento del software

tas, tales como que sea comprensible, permita cambios futuros y la reutilización” [Jac99]: Su-
Producción
giere un flujo del proceso iterativo e incremental, lo que da la sensación evolutiva que resulta
esencial en el desarrollo moderno del software.
se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la natura-
2.5.1 Breve historia leza iterativa e incremental del proyecto en cuestión. Los requerimientos fundamentales del
Al principio de la década de 1990, James Rumbaugh [Rum91], Grady Booch [Boo94] e Ivar Jacob- negocio se describen por medio de un conjunto de casos de uso preliminares (véase el capítulo
son [Jac92] comenzaron a trabajar en un “método unificado” que combinaría lo mejor de cada 5) que detallan las características y funciones que desea cada clase principal de usuarios. En este
uno de sus métodos individuales de análisis y diseño orientado a objetos. El resultado fue un punto, la arquitectura no es más que un lineamiento tentativo de subsistemas principales y la
UML, lenguaje de modelado unificado, que contiene una notación robusta para el modelado y función y rasgos que tienen. La arquitectura se mejorará después y se expandirá en un conjunto
desarrollo de los sistemas orientados a objetos. de modelos que representarán distintos puntos de vista del sistema. La planeación identifica los
El UML se utiliza en toda la parte 2 del libro para representar tanto los modelos de requeri- recursos, evalúa los riesgos principales, define un programa de actividades y establece una base
mientos como el diseño. En el apéndice 1 se presenta un método introductorio a la enseñanza para las fases que se van a aplicar a medida que avanza el incremento del software.
para quienes no están familiarizados con las reglas básicas de notación y modelado con el UML. La fase de elaboración incluye las actividades de comunicación y modelado del modelo gene-
El estudio exhaustivo del UML se deja a libros dedicados al tema. En el apéndice 1 se enlistan ral del proceso (véase la figura 2.9). La elaboración mejora y amplía los casos de uso prelimina-
los textos recomendables. res desarrollados como parte de la fase de concepción y aumenta la representación de la arqui-
El UML brinda la tecnología necesaria para apoyar la práctica de la ingeniería de software tectura para incluir cinco puntos de vista distintos del software: los modelos del caso de uso, de
orientada a objetos, pero no da la estructura del proceso que guíe a los equipos del proyecto requerimientos, del diseño, de la implementación y del despliegue. En ciertos casos, la elabora-
cuando aplican la tecnología. En los siguientes años, Jacobson, Rumbaugh y Booch desarrolla- ción crea una “línea de base de la arquitectura ejecutable” [Arl02] que representa un sistema
ron el proceso unificado, estructura para la ingeniería de software orientado a objetos que utiliza ejecutable de “primer corte”.20 La línea de base de la arquitectura demuestra la viabilidad de ésta,
UML. Actualmente, el proceso unificado (PU) y el UML se usan mucho en proyectos de toda clase pero no proporciona todas las características y funciones que se requieren para usar el sistema.
orientados a objetos. El modelo iterativo e incremental propuesto por el PU puede y debe adap- Además, al terminar la fase de elaboración se revisa con cuidado el plan a fin de asegurar que
tarse para que satisfaga necesidades específicas del proyecto. el alcance, riesgos y fechas de entrega siguen siendo razonables. Es frecuente que en este mo-
mento se hagan modificaciones al plan.
2.5.2 Fases del proceso unificado19 WebRef La fase de construcción del PU es idéntica a la actividad de construcción definida para el pro-
PU Al principio de este capítulo se estudiaron cinco actividades estructurales generales y se dijo que En la dirección www.ambysoft. ceso general del software. Con el uso del modelo de arquitectura como entrada, la fase de
N TO com/unifiedprocess/agileUP. construcción desarrolla o adquiere los componentes del software que harán que cada caso
podían usarse para describir cualquier modelo de proceso del software. El proceso unificado no html, se encuentra un análisis
CLAVE es la excepción. La figura 2.9 ilustra las “fases” del PU y las relaciona con las actividades gene- interesante del PU en el contexto del
de uso sea operativo para los usuarios finales. Para lograrlo, se completan los modelos de re-
Las fases del PU tienen un objetivo rales estudiadas en el capítulo 1 y al inicio de éste. desarrollo ágil. querimientos y diseño que se comenzaron durante la fase de elaboración, a fin de que reflejen
similar al de las actividades la versión final del incremento de software. Después se implementan en código fuente todas las
La fase de concepción del PU agrupa actividades tanto de comunicación con el cliente como
estructurales generales definidas en características y funciones necesarias para el incremento de software (por ejemplo, el lanza-
este libro. de planeación. Al colaborar con los participantes, se identifican los requerimientos del negocio,
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-
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. 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
19 El proceso unificado en ocasiones recibe el nombre de Proceso Racional Unificado (PRU), acuñado por Rational el contrario, es revestida durante la fase siguiente del PU.
Corporation (adquirida posteriormente por IBM), que contribuyó desde el principio al desarrollo y mejora 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-
y a la elaboración de ambientes completos (herramientas y tecnología) que apoyan el proceso. rias).
48 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E LO S D E L P R OC E SO 49

nentes y pruebas de integración). Se emplean casos de uso para obtener un grupo de pruebas estimación y programación de actividades) y delega en el practicante el poder de controlar la
de aceptación que se ejecutan antes de comenzar la siguiente fase del PU. calidad de todos los productos del trabajo de software que se desarrollen. El modelo del PPS
La fase de transición del PU incluye las últimas etapas de la actividad general de construcción define cinco actividades estructurales:
y la primera parte de la actividad de despliegue general (entrega y retroalimentación). Se da el
Planeación. Esta actividad aísla los requerimientos y desarrolla las estimaciones tanto
software a los usuarios finales para las pruebas beta, quienes reportan tanto los defectos como
del tamaño como de los recursos. Además, realiza la estimación de los defectos (el número
los cambios necesarios. Además, el equipo de software genera la información de apoyo nece-
de defectos proyectados para el trabajo). Todas las mediciones se registran en hojas de tra-
saria (por ejemplo, manuales de usuario, guías de solución de problemas, procedimientos de
bajo o plantillas. Por último, se identifican las tareas de desarrollo y se crea un programa
instalación, etc.) que se requiere para el lanzamiento. Al finalizar la fase de transición, el soft-
para el proyecto.
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. Diseño de alto nivel. Se desarrollan las especificaciones externas para cada compo-

Durante esta fase, se vigila el uso que se da al software, se brinda apoyo para el ambiente de
? ¿Qué actividades
estructurales se usan nente que se va a construir y se crea el diseño de componentes. Si hay incertidumbre, se

operación (infraestructura) y se reportan defectos y solicitudes de cambio para su evaluación. durante el PPS? elaboran prototipos. Se registran todos los aspectos relevantes y se les da seguimiento.

Es probable que al mismo tiempo que se llevan a cabo las fases de construcción, transición Revisión del diseño de alto nivel. Se aplican métodos de verificación formal (véase el
y producción, comience el trabajo sobre el siguiente incremento del software. Esto significa que capítulo 21) para descubrir errores en el diseño. Se mantienen las mediciones para todas
las cinco fases del PU no ocurren en secuencia sino que concurren en forma escalonada. las tareas y resultados del trabajo importantes.
El flujo de trabajo de la ingeniería de software está distribuido a través de todas las fases del Desarrollo. Se mejora y revisa el diseño del componente. El código se genera, revisa,
PU. En el contexto de éste, un flujo de trabajo es análogo al conjunto de tareas (que ya se descri- compila y prueba. Las mediciones se mantienen para todas las tareas y resultados de tra-
bió en este capítulo). Es decir, un flujo de trabajo identifica las tareas necesarias para completar bajo de importancia.
una acción importante de la ingeniería de software y los productos de trabajo que se generan
Post mórtem. Se determina la eficacia del proceso por medio de medidas y mediciones
como consecuencia de la terminación exitosa de aquéllas. Debe notarse que no toda tarea iden-
obtenidas (ésta es una cantidad sustancial de datos que deben analizarse con métodos es-
tificada para el flujo de trabajo del PU es realizada en todos los proyectos de software. El equipo
tadísticos). Las medidas y mediciones deben dar la guía para modificar el proceso a fin de
adapta el proceso (acciones, tareas, subtareas y productos del trabajo) a fin de que cumpla sus
mejorar su eficacia.
necesidades.
PU El PPS enfatiza la necesidad de detectar pronto los errores; de igual importancia es entender
NT
O los tipos de ellos que es probable cometer. Esto se logra a través de una actividad de evaluación
CLAVE rigurosa ejecutada para todos los productos del trabajo que se generen.
2.6 MODELOS DEL PROCESO PERSONAL Y DEL EQUIPO
El PPS pone el énfasis en la El PPS representa un enfoque disciplinado basado en la medición para la ingeniería de soft-
El mejor proceso del software es el que está cerca de las personas que harán el trabajo. Si un necesidad de registrar y analizar los ware que quizá sea un choque cultural para muchos de sus practicantes. Sin embargo, cuando
tipos de errores que se cometen, de
modelo del proceso del software se ha desarrollado en un nivel corporativo u organizacional, se introduce el PPS en forma apropiada en los ingenieros de software [Hum96], es significativa
modo que se desarrollen estrategias
será eficaz sólo si acepta una adaptación significativa para que cubra las necesidades del equipo para eliminarlos. la mejora resultante en la productividad de la ingeniería respectiva y en la calidad del software
de proyecto que en realidad hace el trabajo de ingeniería de software. En la situación ideal se [Fer97]. No obstante, el PPS no ha sido adoptado con amplitud por la industria. Es triste recono-
Cita: crearía un proceso que se ajustara del mejor modo a los requerimientos, y al mismo tiempo cer que las razones de esto tienen que ver más con la naturaleza humana y la inercia organiza-
“La persona que es exitosa tan cubriera las más amplias necesidades del equipo y de la organización. En forma alternativa, el cional que con las fortalezas y debilidades del enfoque del PPS. Dicho enfoque plantea desafíos
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- intelectuales y demanda un nivel de compromiso (por parte de los practicantes y sus adminis-
hacer las cosas que no hacen las duos y las más generales de la organización. Watts Humphrey ([Hum97] y [Hum00]) afirma que tradores) que no siempre es posible obtener. La capacitación es relativamente larga y sus costos
personas que no tienen éxito.” es posible crear un “proceso personal de software” y/o un “proceso del equipo de software”. elevados. El nivel requerido de las mediciones es culturalmente difícil para muchas personas de
Dexter Yager Ambos requieren trabajo duro, capacitación y coordinación, pero los dos son asequibles.22 la comunidad del software.
¿Es posible usar el PPS como un proceso eficaz de software a nivel personal? La respuesta es
2.6.1 Proceso personal del software (PPS) un rotundo “sí”. Pero aun si no se adoptara por completo el PPS, muchos de los conceptos del
proceso de mejora personal que introduce constituyen un aprendizaje provechoso.
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;
2.6.2 Proceso del equipo de software (PES)
pero sí existe un “proceso”. Watts Humphrey [Hum97] sugiere que a fin de cambiar un proceso
personal ineficaz, un individuo debe pasar por las cuatro fases, cada una de las cuales requiere WebRef Debido a que muchos proyectos de software industrial son elaborados por un equipo de profe-
WebRef
capacitación e instrumentación cuidadosa. El proceso personal del software (PPS) pone el énfasis En la dirección www.sei.cmu. sionales, Watts Humphrey extendió las lecciones aprendidas de la introducción del PPS y pro-
En la dirección www.ipd.uka.de/
PSP, se hallan muchos recursos para edu/tsp/, hay información sobre la puso un proceso del equipo de software (PES). El objetivo de éste es construir un equipo “autodi-
en la medición personal tanto del producto del trabajo que se genera como de su calidad. Ade-
formación de equipos de alto
el PPS.
más, el PPS responsabiliza al profesional acerca de la planeación del proyecto (por ejemplo, rigido” para el proyecto, que se organice para producir software de alta calidad. Humphrey
rendimiento que usan PES y PPS.
[Hum98] define los objetivos siguientes para el PES:

• Formar equipos autodirigidos que planeen y den seguimiento a su trabajo, que esta-
22 Es útil notar que quienes proponen un desarrollo ágil del software (véase el capítulo 3) también plantean que el blezcan metas y que sean dueños de sus procesos y planes. Éstos pueden ser equipos de
proceso debe ser cercano al equipo. Para lograr esto sugieren un método alternativo. software puros o de productos integrados (EPI) constituidos por 3 a 20 ingenieros.
50 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E LO S D E L P R OC E SO 51

• Mostrar a los gerentes cómo dirigir y motivar a sus equipos y cómo ayudarlos a una red, se analiza para determinar el flujo de trabajo normal y se examinan estructuras alter-
mantener un rendimiento máximo. nativas del proceso que podrían llevar a disminuir el tiempo o costo del desarrollo.
Una vez creado un proceso aceptable, se emplean otras herramientas de tecnología para
• Acelerar la mejora del proceso del software, haciendo del modelo de madurez de la
capacidad, CMM,23 nivel 5, el comportamiento normal y esperado. asignar, vigilar e incluso controlar todas las actividades, acciones y tareas de la ingeniería de
software definidas como parte del modelo del proceso. Cada miembro de un equipo de software
• Brindar a las organizaciones muy maduras una guía para la mejora.
utiliza dichas herramientas para desarrollar una lista de verificación de las tareas de trabajo que
• Facilitar la enseñanza universitaria de aptitudes de equipo con grado industrial. deben realizarse. La herramienta de tecnología del proceso también se usa para coordinar el
Un equipo autodirigido tiene la comprensión consistente de sus metas y objetivos generales; empleo de otras herramientas de la ingeniería de software que sean apropiadas para una tarea
CONSEJO define el papel y responsabilidad de cada miembro del equipo; da seguimiento cuantitativo a los particular del trabajo.
Para formar un equipo autodirigido, datos del proyecto (sobre la productividad y calidad); identifica un proceso de equipo que sea
usted debe colaborar bien en lo apropiado para el proyecto y una estrategia para implementarlo; define estándares locales apli-
interno y comunicarse bien en lo cables al trabajo de ingeniería de software del equipo; evalúa en forma continua el riesgo y re- H ERRAMIENTAS DE SOFTWARE
externo.
acciona en consecuencia; y da seguimiento, administra y reporta el estado del proyecto. Herramientas de modelado del proceso calidad, etc.), dan una guía detallada acerca del contenido o descrip-
El PES define las siguientes actividades estructurales: inicio del proyecto, diseño de alto ción de cada elemento del proceso, y después administran el proceso
Objetivo: Si una organización trabaja para mejorar un
conforme se realiza. En ciertos casos, las herramientas de tecnología
nivel, implementación, integración y pruebas, y post mórtem. Como sus contrapartes del proceso (o software) de negocios, primero debe entender-
del proceso incorporan tareas estándar de administración de proyec-
PPS (observe que la terminología es algo diferente), estas actividades permiten que el equipo lo. Las herramientas de modelado del proceso (también llamadas
tos, tales como estimación, programación, seguimiento y control.
planee, diseñe y construya software en forma disciplinada, al mismo tiempo que mide cuantita- herramientas de tecnología del proceso o de administración del pro-
ceso) se usan para representar los elementos clave de un proceso, de Herramientas representativas:25
tivamente el proceso y el producto. La etapa post mórtem es el escenario de las mejoras del Igrafx Process Tools: herramientas que permiten que un equipo
modo que se entienda mejor. Dichas herramientas también se relacio-
proceso. mapee, mida y modele el proceso del software (www.micro-
nan con descripciones del proceso que ayudan a los involucrados a
El PES utiliza una variedad amplia de scripts, formatos y estándares que guían a los miembros entender las acciones y tareas del trabajo que se requieren para lle- grafx.com)
del equipo en su trabajo. Los scripts definen actividades específicas del proceso (por ejemplo, varlo a cabo. Las herramientas de modelado del proceso tienen víncu- Adeptia BPM Server: diseñado para administrar, automatizar y opti-
inicio del proyecto, diseño, implementación, integración y pruebas del sistema, y post mórtem), los con otras que dan apoyo a las actividades del proceso definido. mizar procesos de negocios (www.adptia.com)
así como otras funciones más detalladas del trabajo (planeación del desarrollo, desarrollo de Mecánica: Las herramientas en esta categoría permiten que un SpeedDev Suite: conjunto de seis herramientas con mucho énfasis en
requerimientos, administración de la configuración del software y prueba unitaria) que forman equipo defina los elementos de un modelo de proceso único (accio- las actividades de administración de la comunicación y modelado
nes, tareas, productos del trabajo, puntos de aseguramiento de la (www.speedev.com)
parte del proceso de equipo.
PU El PES reconoce que los mejores equipos de software son los autodirigidos.24 Los miembros
N TO
del equipo establecen los objetivos del proyecto, adaptan el proceso para que cubra las necesi-
CLAVE dades, controlan la programación de actividades del proyecto y, con la medida y análisis de las
Los scripts del PES definen
elementos del proceso del equipo y
mediciones efectuadas, trabajan de manera continua en la mejora del enfoque de ingeniería de 2. 8 PRODUCTO Y PROCESO
de las actividades que ocurren dentro software que tiene el equipo.
Si el proceso es deficiente, no cabe duda de que el producto final sufrirá. Pero también es peli-
del proceso. Igual que el PPS, el PES es un enfoque riguroso para la ingeniería de software y proporciona
grosa la dependencia excesiva del proceso. En un ensayo corto escrito hace muchos años,
beneficios distintivos y cuantificables en productividad y calidad. El equipo debe tener un com-
Margaret Davis [Dav95a] hace comentarios atemporales sobre la dualidad del producto y del
promiso total con el proceso y recibir capacitación completa para asegurar que el enfoque se
proceso:
aplique en forma apropiada.
Cada diez años, más o menos, la comunidad del software redefine “el problema” por medio de cambiar
su atención de aspectos del producto a aspectos del proceso. Así, hemos adoptado lenguajes de pro-
2.7 TE C N O L O G Í A DEL PROCESO gramación estructurada (producto) seguidos de métodos de análisis estructurados (proceso) que van
seguidos por el encapsulamiento de datos (producto) a los que siguieron el énfasis actual en el modelo
El equipo del software debe adaptar uno o más de los modelos del proceso estudiados en las
de madurez de la capacidad, del Instituto de Ingeniería de Software para el Desarrollo de Software
secciones precedentes. Para ello, se han desarrollado herramientas de tecnología del proceso que
(proceso) (seguido por métodos orientados a objetos, a los que sigue el desarrollo ágil de software).
ayudan a las organizaciones de software a analizar su proceso actual, organizar las tareas de
En tanto que la tendencia natural de un péndulo es alcanzar el estado de reposo en el punto medio
trabajo, controlar y vigilar el avance, y administrar la calidad técnica.
entre dos extremos, la atención de la comunidad del software cambia constantemente porque se
Las herramientas de tecnología del proceso permiten que una organización de software
aplica una nueva fuerza al fallar la última oscilación. Estos vaivenes son dañinos en sí mismos porque
construya un modelo automatizado de la estructura del proceso, conjuntos de tareas y activida-
confunden al profesional promedio del software al cambiar en forma radical lo que significa hacer el
des sombrilla, estudiados en la sección 2.1. El modelo, que normalmente se representa como
trabajo bien. Los cambios periódicos no resuelven “el problema” porque están predestinados a fallar
toda vez que el producto y el proceso son tratados como si fueran una dicotomía en lugar de una
dualidad.
23 El modelo de madurez de la capacidad (CMM), que es una medida de la eficacia de un proceso del software, se
estudia en el capítulo 30.
24 En el capítulo 31 se analiza la importancia de los equipos “autoorganizados” como elemento clave del desarrollo 25 Las herramientas mencionadas aquí no son obligatorias, sino una muestra de las que hay en esta categoría. En la
ágil del software. mayoría de casos, los nombres de las herramientas son marcas registradas por sus respectivos desarrolladores.
52 PA R T E UN O EL P R O C E S O D E L S O F TWA RE CA P Í T UL O 2 M O D E LO S D E L P R OC E SO 53

En la comunidad científica existe el precedente de adoptar nociones de dualidad cuando las con- niería de software, desde el desarrollo del concepto hasta el mantenimiento del sistema a largo
tradicciones en las observaciones no pueden ser explicadas por alguna teoría alternativa. La natura- plazo.
leza dual de la luz, que parece ser al mismo tiempo onda y partícula, ha sido aceptada desde la década El modelo de proceso concurrente permite que un equipo de software represente los elemen-
de 1920, cuando la propuso Louis de Broglie. Pienso que las observaciones que podemos hacer sobre tos iterativos y concurrentes de cualquier modelo de proceso. Los modelos especializados in-
el conjunto del software y su desarrollo demuestran una dualidad fundamental entre el producto y el
cluyen el basado en componentes, que pone el énfasis en la reutilización y ensamble de los
proceso. Nunca es posible derivar u obtener todo el conjunto, su contexto, uso, significado y beneficios
componentes; el modelo de métodos formales consiste en un enfoque basado en matemáticas
si se le ve sólo como proceso o sólo como producto…
para desarrollar y verificar el software; y el modelo orientado a aspectos implica preocupaciones
Toda la actividad humana es un proceso, pero cada uno de nosotros obtiene un sentido de benefi- globales que afectan toda la arquitectura del sistema. El proceso unificado es un proceso del
cio propio gracias a aquellas actividades que dan como resultado una representación o instancia que software diseñado como estructura para los métodos y herramientas del UML, y está “impulsado
puede usar o apreciar más de una persona, utilizarla una y otra vez, o emplearla en algún otro con- por el caso de uso, centrado en la arquitectura, y es iterativo e incremental”.
texto no considerado. Es decir, obtenemos sentimientos de satisfacción por la reutilización de nues- Se han propuesto modelos personal y del equipo para el proceso del software. Ambos enfa-
tros productos, ya sea que lo hagamos nosotros u otras personas.
tizan la medición, planeación y autodirección como los ingredientes clave para un proceso
Entonces, si bien la rápida asimilación de las metas de reutilización en el desarrollo del software exitoso del software.
incrementa potencialmente la satisfacción que obtienen los profesionales del software en su trabajo,
también aumenta la urgencia de la aceptación de la dualidad de producto y proceso. Pensar en un
artefacto reutilizable como si fuera sólo un producto o sólo un proceso oscurece el contexto y las PROBLEMAS Y PUNTOS POR EVALUAR
formas de emplearlo, o bien oculta el hecho de que cada uso da como resultado un producto que a su
2.1. En la introducción de este capítulo, Baetjer afirma que: “El proceso genera interacción entre usuarios y
vez será utilizado como entrada para alguna otra actividad de desarrollo de software. Privilegiar un
diseñadores, entre usuarios y herramientas cambiantes [tecnología].” Enliste cinco preguntas que a) los di-
punto de vista sobre el otro reduce mucho las oportunidades para la reutilización y, por tanto, se pierde señadores deben responder a los usuarios, b) los usuarios deben plantear a los diseñadores, c) los usuarios
la oportunidad de aumentar la satisfacción por el trabajo. deben hacerse a sí mismos sobre el producto de software que ha de elaborarse, d) los diseñadores deben
plantearse acerca del producto de software que va a construirse y del proceso que se usará para ello.
La gente obtiene tanta (o más) satisfacción del proceso creativo como del producto final. Un
artista disfruta las pinceladas tanto como el resultado que enmarca. Un escritor goza de la bús- 2.2. Trate de desarrollar un conjunto de acciones para la actividad de comunicación. Seleccione una acción
y defina un conjunto de tareas para ella.
queda de la metáfora apropiada tanto como del libro terminado. Como profesional creativo del
software, usted también debe obtener tanta satisfacción del proceso como del producto final. La 2.3. Un problema común durante la comunicación ocurre cuando se encuentra a dos participantes que
dualidad de producto y proceso es un elemento importante para hacer que personas creativas tienen ideas en conflicto sobre lo que debe ser el software, es decir, que tienen requerimientos mutuamente
conflictivos. Desarrolle un patrón del proceso (esto sería un patrón de la etapa) con el empleo de la plantilla
se involucren conforme la ingeniería de software evoluciona.
presentada en la sección 2.1.3 que aborda este problema y sugiera un enfoque eficaz para él.

2.4. Investigue un poco sobre el PPS y haga una breve presentación que describa los tipos de mediciones
2.9 RESUMEN que se pide hacer a un ingeniero individual de software y la forma en la que pueden usarse para mejorar la
eficacia personal.
Un modelo general del proceso para la ingeniería de software incluye un conjunto de actividades
2.5. El uso de scripts (mecanismo requerido en el PES) no es apreciado de manera universal en la comuni-
estructurales y sombrilla, acciones y tareas de trabajo. Cada uno de los modelos de proceso
dad del software. Haga una lista de pros y contras en relación con los scripts y sugiera al menos dos situa-
puede describirse por un flujo distinto del proceso: descripción de cómo se organizan secuencial
ciones en las que serían útiles, y otras dos en las que generarían menos beneficios.
y cronológicamente las actividades estructurales, acciones y tareas. Los patrones del proceso
2.6. Lea a [Nog00] y escriba un ensayo de dos o tres páginas donde analice el efecto que tiene el “caos” en
pueden utilizarse para resolver los problemas comunes que surgen como parte del proceso del
la ingeniería de software.
software.
Los modelos de proceso prescriptivo se han aplicado durante muchos años en un esfuerzo 2.7. Dé tres ejemplos de proyectos de software que podrían efectuarse con el modelo de cascada. Sea espe-
cífico.
por introducir orden y estructura al desarrollo de software. Cada uno de dichos modelos sugiere
un flujo de proceso algo distinto, pero todos llevan a cabo el mismo conjunto de actividades 2.8. Proporcione tres ejemplos de proyectos de software que podrían abordarse con el modelo de hacer
estructurales generales: comunicación, planeación, modelado, construcción y desarrollo. prototipos. Sea específico.

Los modelos de proceso secuencial, como el de la cascada y en V, son los paradigmas más 2.9. ¿Qué adaptaciones del proceso se requerirían si el proyecto evolucionara en un sistema o producto que
antiguos del software. Sugieren un flujo lineal del proceso que con frecuencia no es congruente se entregase?
con las realidades modernas (cambio continuo, sistemas en evolución, plazos ajustados, etc.) 2.10. Diga tres ejemplos de proyectos de software que podrían realizarse con el modelo incremental. Sea
del mundo del software. Sin embargo, tienen aplicación en situaciones en las que los requeri- específico.
mientos están bien definidos y son estables.
2.11. Conforme avanza hacia fuera por el flujo de proceso en espiral, ¿qué puede decirse sobre el software
Los modelos de proceso incremental son de naturaleza iterativa y producen con mucha ra- que se está desarrollando o que está en mantenimiento?
pidez versiones funcionales del software. Los modelos de proceso evolutivo reconocen la natu-
2.12. ¿Es posible combinar modelos de proceso? Si es así, diga un ejemplo.
raleza iterativa e incremental de la mayoría de proyectos de ingeniería de software y están di-
señados para aceptar los cambios. Los modelos evolutivos, tales como el de hacer prototipos y 2.13. El modelo de proceso concurrente define un conjunto de “estados”. Describa con sus propias palabras
el espiral, generan rápido productos de trabajo incremental (o versiones funcionales del soft- qué es lo que representan, y después indique cómo entran en juego dentro del modelo de proceso concu-
rrente.
ware). Estos modelos se adoptan para aplicarse a lo largo de todas las actividades de la inge-
54 PA R T E UN O EL P R O C E S O D E L S O F TWA RE

2.14. ¿Cuáles son las ventajas y desventajas de desarrollar software en el que la calidad no es “suficiente-
mente buena”? Es decir, ¿qué pasa cuando se pone el énfasis en la velocidad de desarrollo sobre la calidad
del producto?

2.15. Dé tres ejemplos de proyectos de software que serían abordables con el modelo basado en compo-
nentes. Sea específico.

2.16. ¿Es posible demostrar que un componente de software, o incluso un programa completo, es correcto?
Entonces, ¿por qué no todos lo hacen?

2.17. ¿Son lo mismo el proceso unificado y el UML? Explique su respuesta.

LECTURAS ADICIONALES Y FUENTES DE INFOR MACIÓN

La mayor parte de los libros de ingeniería de software consideran en detalle los modelos de proceso tradi-
cionales. Libros como el de Sommerville (Software Engineering, 8a. ed., Addison-Wesley, 2006), Pfleeger y
Atlee (Software Engineering, 3a. ed., Prentice-Hall, 2005), y Schach (Object-Oriented and Classical Software
Engineering, 7a. ed., McGraw-Hill, 2006) consideran los paradigmas tradicionales y estudian sus fortalezas y
debilidades. Glass (Facts and Fallacies of Software Engineering, Prentice-Hall, 2002) da un punto de vista prag-
mático y crudo del proceso de ingeniería de software. Aunque no se dedica específicamente al proceso,
Brooks (The Mythical Man-Month, 2a. ed., Addison-Wesley, 1995) presenta la sabiduría antigua sobre los
proyectos y plantea que todo tiene que ver con el proceso.
Firesmith y Henderson-Sellers (The OPEN Process Framework: An Introduction, Addison-Wesley, 2001)
presenta una plantilla general para crear “procesos de software flexibles pero con disciplina” y analiza los
atributos y objetivos del proceso. Madachy (Software Process Dynamics, Wiley-IEEE, 2008) estudia técnicas de
modelado que permiten analizar los elementos técnicos y sociales interrelacionados del proceso del soft-
ware. Sharpe y McDermott (Workflow Modeling: Tools for Process Improvement and Application Development,
Artech House, 2001) presentan herramientas para modelar procesos tanto de software como de negocios.
Lim (Managing Software Reuse, Prentice-Hall, 2004) estudia la reutilización desde la perspectiva del ge-
rente. Ezran, Morisio y Tully (Practical Software Reuse, Springer, 2002) y Jacobson, Griss y Jonsson (Software
Reuse, Addison-Wesley, 1997) presentan mucha información útil sobre el desarrollo basado en componentes.
Heineman y Council (Component-Based Software Engineering, Addison-Wesley, 2001) describen el proceso
requerido para implementar sistemas basados en componentes. Kenett y Baker (Software Process Quality:
Management and Control, Marcel Dekker, 1999) analizan la manera en la que se conectan íntimamente la
administración de la calidad y el diseño del proceso.
Nygard (Release It!: Design and Deploy Production-Ready Software, Pragmatic Bookshelf, 2007) y Richard-
son y Gwaltney (Ship it! A Practical Guide to Successful Software Projects, Pragmatic Bookshelf, 2005) presentan
una amplia colección de lineamientos útiles aplicables a la actividad de despliegue.
Además del libro fundamental de Jacobson, Rumbaugh y Booch acerca del proceso unificado [Jac99], los
libros de Arlow y Neustadt (UML 2 and the Unified Process, Addison-Wesley, 2005), Kroll y Kruchten (The
Rational Unified Process Made Easy, Addison-Wesley, 2003) y Farve (UML and the Unified Process, IRM Press,
2003) proveen información complementaria excelente. Gibbs (Project Management with the IBM Rational
Unified Process, IBM Press, 2006) analiza la administración de proyectos dentro del contexto del PU.
En internet existe una amplia variedad de fuentes de información sobre la ingeniería de software y el
proceso del software. En el sitio web del libro, www.mhhe.com/engcs/compsci/pressman/professio-
nal/olc/ser.htm, hay una lista actualizada de referencias en la Red Mundial que son relevantes para el
proceso del software.