Ingenieria de Software PDF

Capítulo 12
Ingeniería de software: el proceso

para el desarrollo de software Por Alfredo Weitzenfeld Ridel y Silvia Guardati Buemo
El desarrollo de software es una de las acti- como lo eran durante los primeros años de
vidades más importantes de la computación, la computación. De esta manera, el lector po-
ya que está presente tanto en el desarrollo de drá conocer los fundamentos de la ingeniería
aplicaciones ajenas a la computación —por de software aplicables en el desarrollo de soft-
ejemplo, un programa que controla la asigna- ware tanto para las áreas de la computación
ción de salas de embarque en un aeropuer- estudiadas en este libro, como para cualquier
to— como en el desarrollo de programas área del saber.
básicos en el área —por ejemplo, un sistema
operativo—. Otro aspecto relevante que debe
tenerse en cuenta es que el desarrollo de 12.1 Modelo del proceso
software no es una tarea solamente técnica,
en la cual lo único que importa es la tecno- Un proceso define quién hace qué, cuándo
logía y los desarrolladores. La producción de y cómo lo hace, para alcanzar cierto obje-
software generalmente también involucra a tivo. En general, el éxito de las empresas u
terceros (es decir, en la mayoría de las situa- organizaciones depende en gran medida de
ciones se desarrolla un programa para satis- la definición y seguimiento adecuado de sus
facer una necesidad específica de un usuario procesos. En el caso de una empresa que se
que no es el mismo programador). Por lo dedica al desarrollo de software, se requieren
tanto, el éxito de un programa está sujeto procesos especializados que abarquen desde
a que éste haga lo que se espera que haga, la creación hasta la administración de un siste-
que haya sido desarrollado con los recursos ma de software. Como se ha visto en capítulos
estimados y que sea confiable. Considerando anteriores, los sistemas de software pueden
lo mencionado, el diseño, desarrollo y man- llegar a ser extremadamente complejos. Para
tenimiento de software debe realizarse con la administrar la complejidad de tales sistemas
misma seriedad y responsabilidad con la que es necesario contar con modelos de procesos
se llevan a cabo cualquiera de las actividades y tecnologías de software apropiadas. En este
propias de las ingenierías tradicionales. capítulo se describe en qué consiste el proce-
En este capítulo se presenta una introduc- so de software.
ción al proceso de desarrollo de software, así Un modelo de proceso de software
como los conceptos básicos acerca de meto- define cómo resolver la problemática del
dologías que existen para el trabajo en equi- desarrollo de sistemas de software. Para de-
po, dado que el software que se desarrolla sarrollar software se requiere resolver ciertas
hoy en día ya no son programas de cien líneas fases de un proceso que se conocen en su
de código, hechos por un solo programador, conjunto como el ciclo de vida1 del desarro-
1
Scacchi, W., 2001, “Process models in software engineering”, en J. Marciniak (Ed), Encyclopedia of
software engineering (second edition), Wiley.
CAP. 12.indd 355 10/31/07 8:31:07 PM

356 CAPÍTULO 12
llo de software. Un modelo de proceso debe en el sistema. Para hacer esta elección existen
considerar una variedad de aspectos, como ciertas heurísticas que muestran la tendencia
el conjunto de personas, estructuras organi- a cambiar en varios elementos de un sistema,
zacionales, reglas, políticas, actividades, com- como se muestra en la tabla 12.1.2 Las inter-
ponentes de software, metodologías y herra- faces representan los elementos gráficos, la
mientas utilizadas. funcionalidad son las reglas del negocio
A continuación se describen aspectos (requisitos del usuario), los datos y funcio-
esenciales que definen un proceso: arquitec- nes son los elementos internos que se usan
turas, actividades, métodos y metodologías, para describir a los objetos (correspondien-
estrategias y herramientas para la administra- tes a las estructuras de datos básicas de la
ción de software. programación orientada a objetos), mientras
que la información representa el dominio
12.1.1 Arquitecturas del problema en una aplicación.
Esta tabla resalta dos aspectos del desa-
rrollo de software. Primero, la arquitectura
Una arquitectura de software define la es-
del sistema debe distinguir entre elementos
tructura general de un sistema. Las arquitec-
con mayor y menor probabilidad de cambios.
turas varían de acuerdo con el tipo de sistema
Segundo, el desarrollo de software debe con-
a desarrollarse. Pueden ser arquitecturas ba-
siderar un modelo de proceso en el que
sadas en elementos sencillos o en componen-
aquellos elementos de mayor probabilidad
tes prefabricados de mayor tamaño. Además
de cambio no “arrastren” a los más estables.
de depender del tipo de sistema a desarrollar,
Este tema se discute con mayor detalle en la
la selección de una arquitectura afecta as-
sección de metodologías.
pectos como la extensibilidad del sistema
(qué tan fácil es extenderlo en el futuro para
incorporar más funcionalidad o mayor capa- 12.1.2 Actividades
cidad). Por lo tanto, la arquitectura debe ser
escogida de manera que minimice los efectos Una actividad es una unidad (un paso) bási-
de los cambios que pueda haber en el futuro ca de un proceso. En el proceso de software
Tabla 12.1 Probabilidad de cambios futuros en el software de acuerdo

con el tipo de elemento de diseño.
Elemento Probabilidad de cambio
Interfaces Alta
Funcionalidad Alta
Datos Mediana
Funciones Mediana
Objetos Baja
Información Baja
2
Coad, P., y Yourdon, E., 1991, Object-oriented analysis, Yourdon Press.
CAP. 12.indd 356 10/31/07 8:31:08 PM

Ingeniería de software: el proceso para el desarrollo de software 357
las actividades definen los pasos necesarios 12.1.2.1 REQUISITOS

para lograr las metas y objetivos (por ejem-
plo, especificar los requisitos del sistema).
La actividad de especificación de requisitos
Las actividades deben ser fáciles de definir
tiene como meta definir y delimitar la funcio-
y seguir, deben simplificar la comprensión
nalidad del sistema de software. La especifi-
del sistema, y ofrecer flexibilidad, precisión y cación de requisitos sirve como base de ne-
extensibilidad. Las actividades básicas del pro- gociación entre el desarrollador del sistema y
ceso de desarrollo de software, conocidas el cliente, y debe reflejar los deseos de éste.
como el ciclo de vida del software, son las El resultado es el modelo de requisitos. Es
siguientes: esencial que los clientes que no tengan co-
nocimientos en computación comprendan el
(i) especificación de requisitos para modelo de requisitos para facilitar la interac-
capturar los aspectos funcionales ción de los desarrolladores del software con
del sistema, describiendo cómo in- ellos.
teractuaría un usuario con la aplica- El modelo de requisitos gobierna el desa-
ción. rrollo de los demás modelos —los demás mo-
(ii) análisis para dar al sistema una delos se deben basar en éste—. El modelo de
estructura o arquitectura robusta requisitos también sirve como base para ela-
y extensible independiente del am- borar las instrucciones de operación y los ma-
biente de implementación final. nuales, los cuales deben ser redactados desde
(iii) diseño para adoptar y refinar la ar- el punto de vista del usuario.
quitectura del sistema y adaptarla El desafío en la especificación de requisitos
al ambiente de implementación es- comienza cuando el experto debe comunicar
pecífico. los conceptos importantes para su aplicación.
(iv) implementación para programar En general, no es posible hacer esto adecua-
el sistema. damente de manera sencilla. Como resultado,
(v) pruebas para validar y verificar el se provee de múltiples explicaciones, orales o
sistema. escritas, que el desarrollador trata de integrar
(vi) integración para combinar los dife- en una forma coherente. La especificación de
rentes componentes del sistema. requisitos es particularmente difícil cuando
(vii) documentación para describir los la información es incompleta, los expertos
diversos aspectos del sistema. no pueden articular lo que saben, o no están
(viii) mantenimiento para extender la seguros o, incluso, son incoherentes en su
funcionalidad del sistema. información o se contradicen.
La tabla 12.2 muestra las actividades más

importantes del ciclo de vida del proceso de 12.1.2.2 ANÁLISIS
software.
La transición entre las distintas actividades Después de desarrollar el modelo de re-
del ciclo de vida del software debe ser natu- quisitos y de que los usuarios del sistema o
ral: debe existir continuidad o rastreabili- clientes lo aprueben, se puede continuar con
dad (en inglés, traceability, la capacidad de la elaboración del modelo de análisis, te-
entender por qué razón surgió y a qué resul- niendo como meta construir una arquitectu-
tados llevó cada decisión realizada durante el ra capaz de resolver el problema bajo condi-
desarrollo de software) de una actividad a la ciones ideales. Esto significa desarrollar una
siguiente o la anterior. A continuación des- estructura lógica del sistema que debe ser es-
cribimos con mayor detalle cada una de las table y extensible. El análisis se enfoca en qué
actividades listadas arriba. debe hacer el sistema, en lugar de cómo se
CAP. 12.indd 357 10/31/07 8:31:08 PM

358 CAPÍTULO 12
Tabla 12.2 Actividades del desarrollo de software.
Actividad Descripción
Requisitos Se especifican las necesidades del sistema a desarrollar. La
especificación de requisitos sirve como base para la negociación entre
los desarrolladores y clientes del sistema y también para planear y
controlar el proceso de desarrollo.
Análisis Se busca comprender los requisitos del sistema con el propósito de
estructurar la arquitectura del sistema. Responde a la pregunta del
“qué” del sistema.
Diseño Se transforma la arquitectura obtenida durante el análisis en una
arquitectura especializada, donde se considera el ambiente de
implantación particular del sistema. Obedece al “cómo” del sistema.
Implementación Se expresa la arquitectura del sistema en una forma aceptable para la
computadora (es decir, el código programado).
Integración Se combinan los componentes creados de manera independiente
para formar el sistema completo.
Pruebas Se verifica y valida el sistema a nivel de componentes individuales y
su integración. Éste es uno de los aspectos más críticos del desarrollo
y debe desarrollarse de manera concurrente con el resto de las
actividades. Se busca descubrir cualquier defecto en los requisitos,
análisis, diseño, implementación e integración. Las pruebas se hacen a
varios niveles, desde funciones sencillas hasta el sistema completo.
Documentación Se describen los aspectos sobresalientes de los requisitos, análisis,
diseño, implementación, integración y pruebas. Esto servirá para
usuarios externos e internos, aquellos encargados de mantener el
sistema y extenderlo.
Mantenimiento Se corrigen errores que no se hayan encontrado durante el desarrollo
y las pruebas originales del sistema. Se extiende el sistema si surgen
nuevas necesidades.
supone que lo hará. El alcance del modelo no hacer esta extensión durante el modelo de
de análisis está directamente relacionado con análisis es que la propia aplicación controla la
la naturaleza del problema. En el caso de un arquitectura del sistema y no las circunstan-
análisis orientado a objetos, se desea identifi- cias existentes durante su implementación.
car los objetos y describir cómo interactúan En otras palabras, el modelo de análisis debe
entre sí. ser visto como un modelo conceptual y ló-
gico del sistema, mientras que el modelo de
diseño debe definir todo lo que es necesario
12.1.2.3 DISEÑO hacer para alcanzar el código final. Dado que
los ambientes de implementación tienden a
El propósito del modelo de diseño es exten- cambiar, es necesario guardar y congelar el
der la arquitectura de análisis. La razón para modelo de análisis para cualquier manteni-
CAP. 12.indd 358 10/31/07 8:31:08 PM

miento que se requiera en el futuro, incluso las cuales se tiene que construir el sistema.
después de terminar el diseño. El modelo de Además, el diseño del sistema debe apoyar
diseño se concentra en dos aspectos prin- aspectos adicionales como una terminación
cipales, el diseño de objetos y el diseño de inesperada durante la ejecución del sistema
sistemas, como se describe a continuación. por agotamiento de recursos o por fallas ex-
El modelo de análisis no es lo suficiente- ternas del hardware.
mente formal, por lo cual para llegar al códi-
go final se deben refinar las estructuras de la
arquitectura de análisis. Es necesario especifi-
12.1.2.4 IMPLEMENTACIÓN
car el detalle de cada clase (en otras palabras,
sus operaciones y atributos). Este aspecto se El modelo de implementación toma el resul-
conoce como el diseño de estructuras o, tado del modelo de diseño para generar el
de manera general, como el diseño de ob- código final del sistema. Esta traducción debe
jetos, en el caso de arquitecturas orientadas ser relativamente sencilla y directa, ya que
a objetos. El diseño de objetos incluye la se- todas las decisiones importantes han sido
lección de algoritmos y estructuras de datos tomadas en las etapas previas. La especializa-
para satisfacer los objetivos de rendimiento y ción al lenguaje de programación, o base de
espacio del proyecto de software. El modelo datos, describe cómo traducir los términos
de análisis y diseño de objetos tienen bastan- usados en el diseño a los términos y propie-
te en común, incluyendo conceptos, técnicas dades del lenguaje específico de implementa-
y notaciones similares. Como consecuencia, ción. Muchas herramientas, como se ve más
las mismas herramientas de desarrollo se uti- adelante, apoyan el proceso de generación
lizan para llevar a cabo ambas actividades. automática de código a través de un proceso
A menudo estas similitudes hacen difícil saber de ingeniería hacia adelante (en inglés,
qué actividad se está llevando a cabo. Uno de forward engineering), como en el caso de
los beneficios de la tecnología orientada a herramientas CASE basadas en UML. Sin em-
objetos es representar la solución como una bargo, la generación automática de código es
consecuencia directa de la representación parcial, y se requiere que el desarrollador la
del problema, por lo cual la distinción entre complete de manera manual. En el modelo
análisis y diseño de objetos no es realmente de implementación, el concepto de rastreabi-
crítica, a diferencia de otros enfoques más lidad también es importante, dado que al leer
tradicionales de desarrollo de software. el código fuente se debe poderlo relacionar
Durante el análisis se considera un mundo con los modelos de diseño y análisis.
ideal para el sistema. En la realidad este mun- Aunque existen muchos tipos de lengua-
do ideal debe adaptarse al ambiente en el que jes de programación, el uso de un lenguaje
se va a implementar el sistema. Entre otros as- orientado a objetos facilita la implementación
pectos, se deben considerar los requisitos de de un diseño orientado a objetos. La elec-
rendimiento, uso de memoria, protocolos ción del lenguaje influye en el diseño, pero
de comunicación, tiempo real, concurrencia, el diseño no debe depender de los detalles
propiedades del lenguaje de programación, del lenguaje, de tal manera que si se cambia de
el sistema de manejo de base de datos, etc. lenguaje de programación no debe ser ne-
Este aspecto se conoce como el diseño de cesario el rediseño del sistema. Por razones
sistema, que define las decisiones estraté- de rastreabilidad, es deseable siempre tener
gicas sobre cómo organizar la funcionalidad una buena y fácil correspondencia entre los
del sistema en torno al ambiente de imple- objetos del modelo de diseño y los objetos del
mentación, incluyendo tanto hardware como lenguaje de programación.
software. Para adaptar el modelo de análisis En la actualidad, las bases de datos son
al ambiente de implementación, es necesa- parte integral de los sistemas de software.
rio identificar las restricciones técnicas bajo Aunque existen bases de datos orientadas a
CAP. 12.indd 359 10/31/07 8:31:09 PM

360 CAPÍTULO 12
objetos, aún siguen siendo más populares 12.1.2.7 DOCUMENTACIÓN

las bases de datos relacionales. El modelo de
implementación debe contemplar el diseño
de la base de datos que se vaya a utilizar en la La documentación se debe hacer durante la
generación del sistema final. elaboración del sistema y no como una eta-
pa final del mismo. Existen diferentes tipos
de documentos que se deben generar como
12.1.2.5 INTEGRACIÓN apoyo al sistema. Cada uno tiene diferentes
objetivos y está dirigido a distintos tipos de
El modelo de integración es un aspecto im- personas, desde los usuarios no técnicos
portante del desarrollo de software. En todo hasta los desarrolladores más técnicos. Los si-
diseño es deseable mantener una buena guientes son algunos documentos o manua-
modularidad en el sistema, de manera que les más importantes.
el desarrollo actual junto con las futuras ex- El manual del usuario permite a un
tensiones puedan hacerse con base en com- usuario comprender cómo utilizar el sistema.
ponentes independientes y no en la totalidad
El manual del programador contiene in-
del sistema. Cuando esto ocurre, es necesario
formación para que un desarrollador entien-
integrar los diversos componentes para obte-
da los aspectos más relevantes de diseño. El
ner como resultado el sistema final.
manual del operador permite al operador
del sistema comprender qué pasos debe se-
12.1.2.6 PRUEBAS guir para que el sistema funcione bajo cierta
configuración y con base en un ambiente de
El modelo de pruebas es el responsable de re- implementación particular. El manual del
visar la calidad del sistema. Este modelo cons- administrador permite que el encargado
ta de la validación del sistema (también co- de administrar el sistema comprenda sus as-
nocida como prueba de especificación) y la pectos más generales, como son los modelos
verificación (también conocida como prueba de requisitos y análisis.
de resultado). De manera adicional, el mode- En realidad no hay límite en cuanto a la
lo de pruebas combina pruebas de unidad y cantidad de manuales y el detalle de la do-
pruebas de integración. cumentación, así como tampoco hay límite
En la validación se prueba si la funcionali- con respecto a cuánto se puede extender y
dad del sistema corresponde a la especifica- optimizar un sistema. El objetivo es mante-
ción del cliente. Se cuestiona si se está cons- ner un nivel de documentación que sea útil
truyendo el sistema “correcto”, en contraste y extensible.
con la verificación, donde se cuestiona si se
está haciendo el sistema “correctamente”.
Durante el diseño e implementación se revisa 12.1.2.8 MANTENIMIENTO
el sistema de acuerdo con las especificaciones
de los modelos de análisis y de requisitos.
En la verificación se prueba si se está El mantenimiento de un sistema es la con-
construyendo el sistema “correctamente”. La tinuación del ciclo de vida luego de haber
verificación debe comenzar lo antes posible, completado una primera versión del sistema.
desde el nivel más bajo, con la revisión de Aunque parte del objetivo involucra resolver
los componentes individuales, prosiguiendo problemas, durante el mantenimiento se de-
con la integración de éstos, hasta verificar el ben considerar las extensiones del sistema de
sistema completo. La especificación de veri- acuerdo con nuevas necesidades. El manteni-
ficación del sistema debe ser una extensión miento significa seguir un nuevo ciclo de ac-
del modelo de requisitos e integrarse en la tividades de desarrollo, pero partiendo de un
arquitectura del sistema. sistema ya existente.
CAP. 12.indd 360 10/31/07 8:31:09 PM

Los métodos deben permitir la genera-

12.1.3 Métodos
ción de modelos a partir de la información
y metodologías recopilada. Por ejemplo, si en cierto desarro-
llo se requiere un modelo de seguridad o uno
Los métodos definen las reglas para las de rendimiento, entonces los métodos deben
transformaciones internas de las actividades, considerar estos requisitos o poder exten-
mientras que las metodologías definen el derse para obtener la información deseada.
conjunto de métodos. Un método es un pro- Se debe evaluar esta capacidad, además del
cedimiento que define tareas o acciones a esfuerzo necesario para obtener tales resul-
realizar, donde cada tarea incluye condiciones tados.
de entrada y de salida que se deben satisfacer Los métodos deben apoyar la integridad
antes de realizarse y después de completar- de los modelos generados, verificando y
se. Las diferentes metodologías varían en el evitando errores de coherencia, además de
alcance del apoyo que proporcionan al desa- incluir técnicas para detectar problemas. Esto
rrollo de software. significa que las herramientas que sólo apo-
Los métodos deben apoyar conceptos bá- yan la diagramación son muy limitadas como
sicos que se consideren significativos para apoyo a métodos, ya que carecen de manejo
resolver el problema. Se deben poder utilizar de coherencia. Los métodos deben permitir
los métodos en diferentes dominios de apli- el desarrollo independiente, algo esencial
cación, y aplicar a sistemas basados en dife- para sistemas de gran tamaño con múltiples
rentes arquitecturas, incluyendo secuencial, analistas y diseñadores.
concurrente, distribuida e incluso en tiempo Los métodos deben ofrecer entradas y
real. salidas bien definidas que permitan la inte-
Los métodos deben ajustarse al ciclo de gración de diversos métodos, incluso perte-
vida del proceso, apoyando las distintas activi- necientes a distintas metodologías. A veces
dades, incluyendo la documentación. Deben es deseable aplicar diferentes metodologías a
explicar las suposiciones, metas y objetivos distintas actividades de desarrollo. Esto ocu-
que llevaron hacia un resultado particular. rre cuando ciertas metodologías son más apro-
Los métodos no deben contradecir el orden piadas para ciertos aspectos del desarrollo,
establecido para las actividades del modelo como análisis o diseño.
de proceso, sino proveer guías para llevarlas Los métodos y herramientas correspon-
a cabo. El mantenimiento de un sistema tam- dientes deben ser apropiados para el tamaño
bién debe estar apoyado por los métodos. del problema a resolver. Un método necesita
Los métodos deben proveer técnicas para escalar hacia arriba o hacia abajo según las
recopilar información de acuerdo con el pro- necesidades del proyecto.
ceso de desarrollo. Por ejemplo, si el proceso Es muy importante contar con una nota-
se basa en tecnologías orientadas a objetos, ción estandarizada para representar los mo-
los métodos deben apoyar la identificación delos desarrollados. Estos modelos deben
de objetos en el sistema. Por otro lado, si el incluir elementos gráficos, de texto o alguna
proyecto tiene como objetivo crear compo- combinación de ambos. Una notación no
nentes reutilizables, los métodos deben in- es simplemente buena o mala, si no más o
cluir técnicas para la obtención y verificación menos eficaz en comunicar los resultados.
de estos componentes. Una buena notación debe tener la suficiente
Los métodos deben apoyar su propia ex- expresividad para modelar conceptos al nivel
tensibilidad, identificando qué aspectos del del detalle deseado. Algunas notaciones tie-
método pueden ser modificados por el de- nen un vocabulario más extenso que otras,
sarrollador para adaptarlo a sus necesidades por lo cual permiten mostrar más detalles.
particulares (por ejemplo, el formato de la También se hace necesaria una notación que
documentación). permita representar modelos con varios ni-
CAP. 12.indd 361 10/31/07 8:31:10 PM

362 CAPÍTULO 12
veles de abstracción. Una buena notación Los diagramas de transición de esta-

también facilita su comprensión y aprendiza- dos sirven para modelar el comportamiento
je, teniendo un subconjunto mínimo como en el tiempo. Los diagramas de transición
apoyo a los principiantes. Las notaciones más describen el efecto de eventos externos en
pobres expresan grandes cambios semánticos los procesos y funciones de un sistema.
con pequeños cambios en los símbolos. Las Los diagramas de entidad-relación
notaciones deben comunicar información de (o entidad-vínculo) sirven para modelar el
manera que minimicen el factor sorpresa. almacenamiento de datos (la forma en la que
Como no siempre se tiene apoyo de herra- éstos están organizados).
mientas para dibujar una notación, se buscan
notaciones que sean fáciles de dibujar. 12.1.3.2 METODOLOGÍAS
Se debe tener confianza en los métodos
ORIENTADAS A OBJETOS
y herramientas correspondientes, en que és-
tas se mantendrán en el mercado (seguirán
estando disponibles) y en que haya la posibi- Las metodologías orientadas a objetos se
lidad de capacitación y apoyo técnico. enfocan principalmente en el modelado de un
Existe una gran variedad de métodos y me- sistema en término de los objetos (y clases de
todologías en apoyo al proceso de software. objetos) que va a manipular. A diferencia de las
A continuación se describen las metodologías metodologías estructuradas, inicialmente se
estructuradas o tradicionales y las orientadas identifican los objetos del sistema, para luego
a objetos. especificar su comportamiento (funciones).
Durante las actividades de desarrollo se utili-
zan diferentes herramientas de modelado.
12.1.3.1 METODOLOGÍAS Los diagramas de clases sirven para des-
ESTRUCTURADAS cribir los componentes esenciales de la ar-
quitectura de un sistema. A diferencia de los
Las metodologías tradicionales o meto- diagramas de flujo de datos, los diagramas
dologías estructuradas se enfocan prin- de clases muestran relaciones de asociación
cipalmente en la descomposición funcional entre clases, y no flujo de datos entre ellas.
de un sistema. El objetivo es lograr una de- Los diagramas de casos de uso sirven
finición completa del sistema en término de para especificar un sistema en términos de su
funciones, estableciendo los datos de entrada funcionalidad. A diferencia de las metodologías
y salida correspondientes a cada función que estructuradas, los diagramas de casos de uso
debe cumplir el sistema. A estas metodologías no son descompuestos en funciones de pro-
se les conoce como de análisis y diseño es- gramación.
tructurado (en inglés, SA/SD—structured Los diagramas de transición de estado
analysis and structured design). Durante sirven para describir los cambios de estado en
las actividades de desarrollo se utilizan dife- los objetos, siendo equivalentes a sus simila-
rentes herramientas de modelado. res en las metodologías estructuradas.
Los diagramas de flujo de datos (DFD) Los diagramas de secuencia sirven para
sirven para modelar la transformación de da- describir los aspectos dinámicos del sistema,
tos a través de las funciones del sistema. Un mostrando el flujo de eventos entre objetos a
diagrama de flujo de datos se compone de través del tiempo.
procesos, flujo de datos, actores (entidades Los diagramas de colaboración sirven
externas) y almacenamiento de datos. Duran- para describir la comunicación entre objetos
te el análisis, los procesos del DFD se descom- en un sistema.
ponen hasta convertirse, durante el diseño, Los diagramas de subsistemas sirven
en funciones de programación, creando una para describir agrupaciones de clases en un
carta (chart) estructurada del sistema. sistema.
CAP. 12.indd 362 10/31/07 8:31:10 PM

A menudo se confunden algunos de los proceso y las metodologías a utilizarse. Dada

conceptos descritos hasta el momento, como la variedad de posibilidades, es necesario to-
los de actividad, método y notación. La figu- mar ciertas decisiones iniciales dependiendo
ra 12.1 ilustra la relación entre ellos. El lado del tipo de proyecto que se va a desarrollar.
izquierdo de la figura muestra diferentes ac- Estas decisiones son parte de una estrategia
tividades, la parte media muestra ejemplos de desarrollo, lo cual incluye la selección de
de métodos para llevar a cabo las actividades una tecnología y lenguaje de programación
correspondientes, mientras que el lado de- particular (por ejemplo, la tecnología orien-
recho contiene ejemplos de notaciones para tada a objetos y el lenguaje Java, respectiva-
capturar el resultado de estos métodos. mente). Otras estrategias aceptadas en la ac-
tualidad son los prototipos y la reutilización,
12.1.4 Estrategias que se describirán a continuación.
Una estrategia se define como un plan para 12.1.4.1 PROTOTIPOS

lograr un objetivo. Las estrategias afectan as-
pectos como la arquitectura del sistema, el or- Un prototipo es una versión preliminar, in-
den en que se llevan a cabo las actividades del tencionalmente incompleta o reducida de un
Modelo de proceso Método Notación
Métodos de requisitos
Requisitos • OBA
• Fusión
• Casos de uso actor 1 actor 2
Casos de uso en UML
Métodos de análisis
clase 1 clase 2
• OBA
Análisis
• Fusión
• Objectory
Métodos de diseño
• UML clase 1 clase 2
Diseño
• Fusión
• RDD
Asociación de clase en UML
Método de codificación class Clase 1 extends ClaseX {

• Técnicas de Java ....
Implementación • Técnicas de C }
• Técnicas de Smalltalk
Figura 12.1 Contraste de las actividades, métodos y notaciones de desarrollo de software.
CAP. 12.indd 363 10/31/07 8:31:11 PM

364 CAPÍTULO 12
sistema. El uso de prototipos es una estrate- tre un desarrollo rápido y un producto de

gia que puede aplicarse en casi todas las ac- calidad. Las siguientes dos listas muestran al-
tividades del proceso de software. El propó- gunas consideraciones para el éxito o fracaso
sito de los prototipos es obtener de manera de los prototipos3.
rápida la información necesaria como ayuda Los prototipos tienen éxito cuando se
en la toma de decisiones. Los siguientes son comprende su propósito y se usan de mane-
algunos tipos de prototipo. ra adecuada, se comprende la tecnología que
Los prototipos de requisitos permiten va a utilizarse y su relación con el proceso
que los usuarios perciban la funcionalidad de prototipos, se integra un grupo técnico
del producto final a través del diseño de inapropiado para hacer el prototipo (líder de
terfaces o pantallas del sistema. El objetivo proyecto, documentador, elaborador de pro-
es ayudar a aclarar los requisitos y solicitar totipos de requisitos y análisis, y elaborador
nuevas ideas. de prototipos de diseño), se evalúa al grupo
Los prototipos de análisis permiten ge- y las entregas finales, se involucra temprano
nerar rápidamente una arquitectura general en el proceso de software a los usuarios fina-
que considere las características principales les, se está dispuesto a repetir el proceso de
del sistema de acuerdo con la especificación prototipos para comprender mejor la arqui-
de requisitos. tectura básica, se establecen criterios de eva-
Los prototipos de diseño permiten ex- luación apropiados al comienzo de cada eta-
plorar y comprender la arquitectura particu- pa de prototipos y se basa uno firmemente
lar de un sistema para poder evaluar aspectos en estos criterios para su terminación y/o se
como cuellos de botella (rendimiento y uso construyen prototipos basados en una biblio-
de memoria) o incoherencias en el diseño. teca de código reutilizable, controlada por el
Los prototipos verticales permiten com- bibliotecario asignado.
prender parte de un problema y desarrollar Los prototipos fallan cuando no se com-
su solución completa. Esto se hace general- prende qué es un prototipo y cómo debe
mente cuando los conceptos básicos no es- usarse, no se comprende el proceso lo su-
tán bien comprendidos (por ejemplo, el se- ficientemente bien como para organizar al
guimiento de cierta metodología). grupo de manera adecuada, no se sabe hasta
Los prototipos de factibilidad permi- cuándo dejar de evolucionar el prototipo y
ten demostrar si es posible lograr ciertos obje- comenzar de cero (así extendiendo dema-
tivos del proyecto (por ejemplo, aplicar una siado el proceso), no se sabe hasta cuándo
arquitectura particular, conectarse a una base continuar para tratar de lograr los criterios de
de datos bajo ciertas restricciones de rendi- evaluación deseados (así terminando prema-
miento, aprender a programar en cierto len- turamente el proceso), no se utilizan ambien-
guaje en un tiempo determinado o predecir tes o herramientas de apoyo adecuados para
los costos de desarrollo de un proyecto). el desarrollo particular, se cree que un proto-
Un prototipo no es necesariamente un pro- tipo razonable es un producto aceptable y/o
ducto de calidad, que deba mantenerse a lar- los prototipos nunca terminan.
go plazo. Por el contrario, los prototipos a
menudo son creados y probados rápidamen-
te, para luego ser descartados. Sin embargo, 12.1.4.2 REUTILIZACIÓN
es común que, por presiones de tiempo, se
trate de enviar un prototipo al mercado (ven- La reutilización es la explotación de compo-
derlo) como si éste fuera el producto final. nentes desarrollados anteriormente dentro
En general, siempre existirá un conflicto en- de un mismo proyecto o entre proyectos, para
3
Goldberg, A., y Rubin, K, 1995, Succeeding with objects: decision framework for project management
(primera edición), Addison-Wesley.
CAP. 12.indd 364 10/31/07 8:31:18 PM

no comenzar a desarrollar algo desde cero reutilización.4 La reutilización es valiosa cuan-

cuando ya se tiene un componente que pro- do se desea apoyar lo común, promover la
porciona cierta funcionalidad necesaria. Den- coherencia mediante estándares, incremen-
tro de un mismo proyecto, la reutilización se tar la habilidad para analizar problemas entre
aprovecha mediante estructuras comunes de diversos grupos, reducir costos, facilitar el
bajo nivel, como procedimientos, clases o inicio de un desarrollo, acelerar el tiempo de
herencia. Este tipo de reutilización produce entrega o mejorar la calidad del producto. La
generalmente programas más compactos. reutilización no es valiosa cuando se tienen
Entre proyectos, la reutilización se aprovecha que ajustar los componentes generalizados
mediante estructuras comunes de alto nivel, a los requisitos de rendimiento y el tiempo de
como paquetes gráficos y bibliotecas de análi- aprendizaje para consumir y producir com-
sis numérico. La reutilización entre proyectos ponentes reutilizables a los tiempos del pro-
requiere planeación y representa una inver- yecto, se tiene que ajustar algo existente ha-
sión tanto para producir componentes reuti- ciendo demasiados cambios, la componente
lizables como para consumirlos. La decisión reutilizada provee un exceso de funcionali-
para reutilizar componentes se basa en una dad, no se entienden las interfaces de pro-
evaluación de los costos relativos entre crear gramación de los componentes, o cuando
una nueva solución o adaptar una existente. estos últimos son propiedad de un proyecto
Consumir componentes reutilizables re- específico, incluyen demasiada funcionalidad
quiere identificar si ya existe una solución no requerida o no disminuye la cantidad total
disponible, ya sea parcial o completa. Las ven- de código a ser probada.
tajas de la reutilización incluyen soluciones
coherentes entre aplicaciones y confianza
en la calidad del componente, al haber sido 12.1.5 Herramientas
probado anteriormente en múltiples aplica-
ciones. Para tener éxito con la reutilización, Las herramientas son aplicaciones que apo-
la solución debe adaptarse a las necesidades yan diversos aspectos en la administración
del sistema. Es común que los desarrollado- del proceso de software. El conjunto de estas
res sólo reutilicen soluciones si confían en su herramientas se conoce como ingeniería
nivel de calidad. Las oportunidades de reuti- de software asistida por computadora
lización pueden ocurrir durante todo el ciclo (en inglés, CASE—Computer-Aided Software
de vida de un proyecto. Engineering), cuyo objetivo es asistir al de-
Producir componentes reutilizables signi- sarrollador durante las diferentes actividades
fica tener una perspectiva de múltiples pro- del ciclo de vida del proceso de software. Las
yectos. Una organización debe considerar los herramientas varían en su apoyo a los proce-
costos adicionales de producir un componen- sos, integrando componentes como editores
te reutilizable, planeando la reducción de cos- de texto, generadores de modelos gráficos
tos que ocasiona utilizar los componentes en (diagramas), generadores de código, compi-
otros proyectos. Así, el esfuerzo para producir ladores, depuradores, verificadores, validado-
componentes reutilizables es bastante mayor res, medidores (monitores), administradores
al esfuerzo de desarrollo de componentes de configuración y administradores del pro-
“normales”, generados específicamente para yecto. Las herramientas CASE son indispen-
una aplicación dada. sables en la administración del proceso de
A continuación se presentan razones a fa- software. La selección de estas herramientas
vor y en contra (ventajas y desventajas) de la debe considerar el apoyo a las metodolo-
4
Goldberg, A. y Rubin, K., 1995, Succeeding with objects: decision framework for project management
(primera edición), Addison-Wesley.
CAP. 12.indd 365 10/31/07 8:31:18 PM

366 CAPÍTULO 12
gías utilizadas. Se debe tomar en cuenta si progreso del desarrollo de software hacia
proveen apoyo explícito para cada paso del puntos de revisión bien definidos (en inglés,
método, administran toda la información que milestones o checkpoints) mediante en-
el método requiere obtener o especificar, per- tregas programadas con fechas precisas (en
miten manejar grandes cantidades de infor- inglés, schedule). La figura 12.2 muestra un
mación y hacer proyectos escalables, incluyen diagrama del modelo de cascada que descri-
un mecanismo que permita probar que la in- be el orden de las actividades del desarrollo
formación recolectada es coherente, apoyan de software. No se muestra una etapa explíci-
la organización de los diagramas de manera ta de documentación dado que ésta se lleva a
automática, permiten usuarios simultáneos en cabo en el transcurso de todo el desarrollo. El
uno o más proyectos, pueden generar una modelo original planteaba que cada actividad
implementación inicial junto con la docu- debía completarse antes de poder continuar
mentación y apoyan la ingeniería en reversa con la siguiente actividad. Sin embargo, en una
para asegurar que los cambios directos en revisión posterior se extendió el modelo, per-
la implementación sean coherentes con los mitiendo regresar a actividades anteriores.7
modelos administrados. Algunas de las creencias del modelo de
cascada son que las metas se logran mejor
cuando se tienen puntos de revisión bien
12.2 Modelos clásicos preestablecidos y documentados (dividien-
Los modelos de proceso dependen de las do el desarrollo del software en actividades
opiniones o creencias de las personas involu- secuenciales bien definidas), los documentos
cradas en un proyecto.5 Por ejemplo, algunas técnicos son comprensibles para usuarios y
de estas opiniones o creencias implican que administradores no técnicos, cada detalle de
es necesario comprender el problema antes los requisitos se conoce de antemano antes
de desarrollar una solución, el proceso para de desarrollar el software (dichos detalles son
resolver un problema debe dar un resultado estables durante el desarrollo) y las pruebas y
predecible (sin importar qué individuo hace evaluaciones se realizan de manera eficiente
el trabajo), es indispensable planear y calcu- al final del desarrollo.
lar el proceso con gran precisión, para que El modelo de cascada fue inicialmente
un proceso tenga éxito es importante evaluar bien recibido, dado que las actividades de las
y administrar el riesgo y la entrega de etapas etapas eran razonables y lógicas. Lamentable-
intermedias bien definidas aumenta la con- mente, el modelo no explicaba cómo modi-
fianza que se tiene en el resultado final. ficar un resultado, en especial considerando
A continuación se describen los modelos lo difícil que es definir todos los requisitos de
de procesos “clásicos”, analizando las creen- un sistema desde el inicio y que éstos se man-
cias en las cuales se basan. tengan estables y sin cambios durante el de-
sarrollo. Además, toma demasiado tiempo en
obtener resultados, retrasando la detección
12.2.1 Modelo de cascada de errores hasta el final. El modelo también
hace difícil rastrear (en otras palabras, ver la
El modelo de cascada original se desarrolló dependencia entre los requisitos iniciales y el
entre las décadas de los años 60 y 706 y se código final). Esta rigidez trajo dudas sobre la
define como una secuencia de actividades, utilidad del modelo, resultando en que éste
donde la estrategia principal es seguir el dejase de utilizarse de acuerdo con su defini-
5
Idem.
6
Royce, W., 1970, Managing the development of large software systems: concepts and techniques,
Proceedings WESTCON, IEEE Computer Society Press, San Francisco, CA.
7
Boehm, B., 1981, Software engineering economics, Englewood Cliffs, NJ: Prentice Hall.
CAP. 12.indd 366 10/31/07 8:31:18 PM

especificación
de requisitos
análisis
diseño
implementación
pruebas
parciales
integración
mantenimiento
Figura 12.2 Secuencia de actividades para el modelo de cascada.
ción original, llevando a los desarrolladores construirse de manera serial o paralela de-
a utilizar variantes del modelo básico, inclu- pendiendo de la naturaleza de la dependencia
yendo el uso de prototipos y la reutilización entre versiones y recursos. Cada incremento
de software.8 agrega funcionalidad adicional o mejorada so-
bre el sistema. Conforme se completa cada
etapa, se verifica e integra la última versión
12.2.2 Modelo incremental con las demás versiones ya completadas del
sistema. Durante cada incremento, el sistema
El modelo incremental consiste de un de- se evalúa con respecto al desarrollo de versio-
sarrollo inicial de la arquitectura completa del nes futuras. Las actividades se dividen en pro-
sistema, seguida de incrementos y versiones cesos y subprocesos, dando lugar al término
parciales de éste.9 Cada incremento tiene su fábrica de software (en inglés, software
propio ciclo de vida, típicamente siguiendo el factory). Para que la secuencia de desarrollo
modelo de cascada. Los incrementos pueden sea exitosa, es esencial definir etapas que no
8
Yourdon, E., 1992, Decline and fall of the american programmer, Prentice Hall.
9
Boehm, B., 1981, Software engineering economics, Englewood Cliffs, NJ: Prentice Hall.
CAP. 12.indd 367 10/31/07 8:31:19 PM

368 CAPÍTULO 12
requieran cambiar los resultados anteriores al siendo entregados los incrementos. Desde el
agregar nuevas. Por lo tanto, es importante punto de vista del desarrollador, los requeri-
comprender al inicio los requisitos completos mientos que son claros al principio del pro-
del sistema, algo que normalmente es muy yecto dictan el incremento inicial, mientras
difícil de lograr. El desarrollo incremental evi- que los incrementos para cada uno de los
ta la teoría del “big bang” para el desarrollo siguientes ciclos de desarrollo se clarifican a
de software, donde una gran explosión de través de la experiencia de los incrementos
desarrollo se transforma repentinamente en anteriores. Este modelo considera que el
el sistema final. desarrollo de sistemas es un proceso de cam-
Algunas de las creencias del modelo de bios progresivos mediante deltas (cambios)
cascada son que la administración de proyec- de especificación de requerimientos. En la
tos es más fácil de lograr en incrementos más figura 12.3 se ilustra este concepto.
pequeños, es más fácil comprender y probar El modelo evolutivo es también conocido
incrementos de funcionalidad más peque- como desarrollo rápido de aplicaciones
ños, la funcionalidad inicial se desarrolla más (en inglés, RAD—rapid application deve-
temprano (logrando resultados de inversión lopment), que se basa tradicionalmente en
en menor tiempo) y hay más probabilidad de el uso de prototipos (en inglés, rapid pro-
satisfacer el cambio en los requisitos de usua- totyping). Un prototipo de software se con-
rio mediante incrementos del software en el sidera como un medio para especificar los
tiempo que si fueran planeados todos a la vez requisitos y un enlace de comunicación entre
en un mismo periodo. el usuario final y el diseñador, ayudando a re-
ducir el riesgo de carecer de requerimientos
12.2.3 Modelo evolutivo iniciales completos y estables.
Algunas de las creencias del modelo de
El modelo evolutivo es una extensión al cascada son la entrega temprana de parte del
modelo incremental en la que los incremen- sistema, aunque no estén completos todos
tos se hacen de manera secuencial, en lugar los requerimientos, ya que esto permite uti-
de en paralelo.10 Desde el punto de vista del lizarlo como herramienta para la generación
cliente, el sistema evoluciona según vayan de requerimientos faltantes, obteniendo be-
10
Boehm, B., 1987, A spiral model of software development and enhancement, Software engineering
project management, IEEE.
Primer ciclo
de desarrollo versión 1
versión 1
versión 2
versión n
Figura 12.3 Secuencia de versiones en el modelo evolutivo.
CAP. 12.indd 368 10/31/07 8:31:21 PM

diseño análisis
versión 1 versión 2 versión 3

lista lista lista
implementación pruebas
Figura 12.4 Secuencia de actividades para el modelo espiral.
neficios para el sistema mediante entregas jo, cada uno de los cuales estudia el riesgo
iniciales mientras las entregas posteriores se antes de proceder al siguiente ciclo. Cada
encuentran en desarrollo. ciclo comienza con la identificación de los
objetivos, soluciones alternas y restricciones
asociadas con cada alternativa, y finalmente
12.2.4 Modelo espiral se procede a su evaluación. Cuando se en-
cuentra que existe cierta incertidumbre, se
El modelo espiral,11 desarrollado duran- utilizan diversas técnicas para reducir el ries-
te la década de los años 80, es una exten- go de las distintas alternativas. Cada ciclo del
sión del modelo de cascada. A diferencia modelo espiral termina con una revisión que
del modelo de cascada, que es dirigido por discute los logros actuales y los planes para
documentos, el modelo espiral se basa en el siguiente ciclo. La figura 12.4 muestra un
una estrategia para reducir el riesgo del diagrama conceptual del modelo espiral.
proyecto en áreas de incertidumbre, como Al igual que el modelo evolutivo, el mode-
tener requerimientos iniciales incompletos e lo espiral incorpora una estrategia de uso de
inestables. El modelo enfatiza ciclos de traba- prototipos como parte del manejo del riesgo.
11
Idem.
CAP. 12.indd 369 10/31/07 8:31:22 PM

370 CAPÍTULO 12
Las creencias del modelo de espiral son que yendo la partición del sistema en subsistemas
una actividad comienza cuando se entienden para ser considerados en ciclos paralelos, lo
los objetivos y riesgos involucrados, se usan cual puede incluir un plan para terminar el
las herramientas que mejor reduzcan los ries- proyecto si es muy riesgoso o no es factible,
gos basándose en la evaluación de soluciones asegurando el compromiso de la administra-
alternas, todo el personal relacionado debe in- ción para continuar según lo planeado.
volucrarse en una revisión que determine cada Una vez revisadas las actividades, los ciclos
actividad (planeando y comprometiéndose definen líneas específicas a seguir. En el Ciclo
con las siguientes actividades) y el desarrollo 0 (grupos de aplicación) se determina la viabi-
se incrementa en cada etapa, permitiendo lidad de un grupo apropiado de aplicaciones.
prototipos sucesivos del producto. Con algu- En el Ciclo 1 (objetivos del ciclo de vida de
nas variantes, éste es el modelo de proceso la aplicación) se desarrollan los objetivos del
más importante en la actualidad. ciclo de vida, incluyendo prototipos, planes
y especificaciones de aplicaciones individua-
12.3 Modelos nuevos les, y se verifica la existencia de al menos una
arquitectura viable para cada aplicación. En el
Ciclo 2 (arquitectura del ciclo de vida de la
En esta sección se describen algunos de los
aplicación) se establece una arquitectura del
modelos de procesos “nuevos” que surgieron
ciclo de vida detallado, se verifica su viabili-
después de los clásicos.
dad, y se determina que no existen riesgos
mayores en satisfacer los planes y especifica-
12.3.1 Modelo ganar-ganar ciones. En el Ciclo 3 (capacidad de operación
inicial) se alcanza una capacidad operacio-
El modelo ganar-ganar (en inglés, win-win)12 nal inicial para cada etapa crítica del proyecto
extiende el modelo espiral, haciendo énfasis en en el ciclo de vida del software.
la identificación de las condiciones de ganancia Las creencias del modelo son: crear soft-
para todas las partes, creando un plan para al- ware basado en componentes para lograr ma-
canzar las condiciones ganadoras y evitar los yor calidad en los sistemas de mayor tama-
riesgos correspondientes. Se establecen las ño, escribir software reutilizable para hacer
reglas para definir el proceso de desarrollo del eficiente el proceso de desarrollo, medir la
proyecto, tomando en cuenta todas las partes calidad del sistema como aspecto clave del
implicadas. El modelo no necesita mucho tiem- desarrollo del producto, lograr mayor calidad
po de gestión. Esto permite utilizarlo tanto en en el proceso de ensamblaje a partir de com-
proyectos pequeños como grandes. ponentes menores, usar tecnologías basadas
Se consideran cuatro los ciclos, cada uno en objetos como aspecto básico para lograr
compuesto de cuatro actividades. Las cuatro la calidad, producir sistemas rápidamente (sen-
actividades son: elaborar los objetivos, res- cillos, confiables y de calidad) empleando pro-
tricciones y alternativas del proceso y procesos bien definidos, utilizar el modelo es-
ducto del sistema y subsistema; evaluar las piral como base del proceso, hacer flexible
alternativas con respecto a los objetivos y el proceso de creación del software para lo-
restricciones (identificando y resolviendo las grar los objetivos generales de eficiencia, in-
fuentes principales de riesgo en el proceso volucrar al cliente mediante el manejo de
y producto); elaborar la definición del pro- prototipos y analizar los riesgos en el proceso
ducto y proceso; y planear el siguiente ciclo, del desarrollo del software para asegurar la
actualizando el plan del ciclo de vida, inclu- calidad final del sistema.
12
Boehm, B., Egyed, A., Port, D., Shah, A., Kwan, J. y Madachy, R., “A stakeholder win-win approach to
software engineering education”, Annals of software engineering, enero de 1999.
CAP. 12.indd 370 10/31/07 8:31:24 PM

12.3.2 Proceso unificado (UP) ro es necesario que cada uno de sus ingenie-
ros alcancen resultados de excelencia y luego
El proceso unificado (en inglés, UP—uni- que sus grupos de trabajo también lo hagan.
fied process)13 es una extensión al proceso En el caso del desarrollo de software de alta
objectory (del inglés object factory),14 que calidad, que responda a las expectativas de
tiene sus orígenes en la década de los años los usuarios, es fundamental definir proce-
80. Estos modelos de proceso se basan prin- sos tanto personales como para el trabajo en
cipalmente en la especificación de reque- equipo. En cuanto al proceso personal, aquí
rimientos de un sistema mediante casos de se explican dos de los más importantes, el
uso (maneras de utilizar un sistema). El pro- PSP (Personal Software Process) y el XP
ceso unificado considera como aspecto esen- (Extreme Programming). Con respecto al
cial del desarrollo de software una visión proceso de trabajo en equipos se explica el
que parte de la arquitectura del sistema, si- TSP (Team Software Process).
guiendo un proceso iterativo e incremental.
El proceso considera e integra diferentes as-
pectos, como son los ciclos, fases, flujos de 12.4.1 PSP (Personal
trabajo, mitigación de riesgo, control de cali- Software Process)
dad, administración de proyecto y control de
configuración. De manera adicional, el pro- El proceso personal (Humphrey, 2004a) con-
ceso unificado considera las cuatro P del de- siste en especificar la secuencia de pasos re-
sarrollo de software: personas, proyecto, pro- queridos por un programador para desarrollar
ducto y proceso. o mantener software. Un proceso bien definido
El proceso unificado tiene las siguientes proporciona el marco técnico y administrativo
creencias: para construir un sistema exitoso para la aplicación de metodologías, herramien-
se debe conocer qué quieren y necesitan los tas y el esfuerzo personal en el desarrollo de
usuarios potenciales; al igual que la arquitec- software. Éste determina los papeles y las ta-
tura, en la construcción, permite diseñar edi- reas que deben llevarse a cabo.
ficios desde múltiples puntos de vista, estruc- PSP propone un proceso. Sin embargo,
tura, electricidad, etc., las arquitecturas de los cada individuo debe adaptarlo a su propia
sistemas de software deben permitir visuali- situación. Las principales ideas en las que se
zar un sistema desde múltiples perspectivas; basa PSP son:
y el desarrollo de un producto de software co-
mercial puede significar un gran esfuerzo con- 1. Los desarrolladores entienden mejor
tinuando por meses, años o incluso más, lo que hacen cuando definen, miden y
por lo que es práctico dividir el trabajo en controlan su trabajo.
pedazos, donde cada iteración resulta en un 2. Tener un proceso e indicadores bien
incremento del proyecto. definidos favorece la evaluación y el
aprendizaje a partir de las propias ex-
12.4 Proceso personal periencias y de las ajenas.
y de equipo para 3. Con el conocimiento y la experiencia
el desarrollo de software se pueden seleccionar aquellos méto-
dos y prácticas que mejor se adapten
Para lograr buenos resultados a nivel de las a las habilidades particulares de cada
empresas desarrolladoras de software, prime- ingeniero.
13
Jacobson, I., Booch, G., y Rumbaugh, J., 1999, The unified software development process, Addison
Wesley.
14
Jacobson, C., Christensen, M., Jonsson, P., y Overgaard, G., 1992, Object-oriented software engi-
neering: a use-case driven approach, Addison-Wesley.
CAP. 12.indd 371 10/31/07 8:31:25 PM

372 CAPÍTULO 12
4. Con el uso de un conjunto de prácticas desarrollo de software. Es un proceso evolu-

personales de alta calidad, cada indivi- tivo: se parte del estado actual del desarrolla-
duo se torna en un miembro eficaz de dor, se van agregando elementos, dando lu-
su equipo de trabajo. gar a nuevos procesos, y así se continúa hasta
llegar a la última etapa en la cual se repite el
proceso personal cíclicamente. A continua-
12.4.1.1 LOS PROCESOS DE PSP ción se describe con más detalle cada uno de
los subprocesos.
En la figura 12.5 (Humphrey, 2004c) se pre- PSP0 es el proceso de desarrollo en sí, in-
senta un esquema del proceso personal de cluyendo mediciones básicas que permiten
PSP3
Desarrollo cíclico
PSP2.1
PSP2 Plantillas de diseño
Revisión de código
Revisión de diseño
PSP1.1
Planeación de tareas
PSP1
Planeación de tiempo
Estimación de tamaño
Reporte de prueba
PSP0.1
Estandarizar codificación
PSP0 Establecer medidas de tamaño
Propuesta de mejoras en el proceso
Proceso actual
Registro de tiempo
Registro de defectos
Estandarizar el tipo de defectos
Figura 12.5 La evolución de PSP.
CAP. 12.indd 372 10/31/07 8:31:25 PM

identificar aspectos a mejorar y llevar un se- la que se lleva a cabo. El mejoramiento con-
guimiento del progreso alcanzado. Se registra tinuo del proceso se logra gracias al uso ade-
el tiempo y los defectos. Para esto último se cuado de los datos obtenidos en experiencias
requiere definir un estándar de tipos de defec- previas, por lo cual se requiere el registro
tos o se puede tomar el propuesto por PSP. constante de datos durante todas las etapas
PSP0.1 se obtiene agregando al PSP0 la es- de PSP. Es importante mencionar que los da-
tandarización del código, medidas de tamaño tos recolectados por los programadores du-
y una propuesta para el mejoramiento del rante las distintas etapas del desarrollo deben
proceso. Es importante registrar los proble- ser respetados como propiedad de los pro-
mas encontrados en el proceso y sugerencias gramadores. No deben ser usados por los
para mejorarlo. administradores para establecer premios o
En PSP1 se incorpora la actividad de pla- castigos.
neación. Se incluye la estimación de recursos
y tiempo. Además, se empiezan a realizar
reportes de las pruebas efectuadas a los pro-
12.4.1.2 PLANEACIÓN
gramas desarrollados.
Para alcanzar el nivel de PSP1.1 se agrega En el plan del proyecto se define el trabajo y
la planeación de tareas y el calendario de en- la manera en la que se va a realizar. Asimismo,
tregas. La planeación permite al programador se especifican las principales tareas, así como
entender la relación entre el tamaño de los una estimación del tiempo y de los recursos
programas que desarrolla y el tiempo que re- requeridos para realizarlas. Para elaborar un
quiere para ello, establecer metas que puede plan se recomienda tener en cuenta los si-
alcanzar y poder saber en cada momento cuál guientes puntos: 1. definir para desarrollar un
es el estado de avance de su trabajo. producto específico; 2. revisar con el cliente;
En PSP2 el énfasis está en la calidad de los 3. dividir en varias etapas bien definidas y
productos que se elaboran. Para poder con- que se puedan evaluar, y 4. debe servir para
trolar los defectos introducidos en el código, medir el progreso que se vaya alcanzando en
primero se necesita saber cuántos se introdu- el proyecto.
cen y de qué tipo son. Con este conocimiento Considerando lo anterior, un buen plan
se elaboran listas de los defectos más frecuen- proporciona información valiosa tanto para
tes. Teniendo estas listas, se establecen revi- el desarrollador como para el cliente. Al desa-
siones e inspecciones de diseño y de código, rrollador, el plan le indica todo lo correspon-
de tal manera que los defectos se detecten diente al tamaño del trabajo, las etapas en las
en una etapa inicial. Cuanto antes se detec- que lo va a desarrollar, el estado del trabajo
te un defecto, más barato resulta su correc- en grado de avance y la precisión o no con la
ción. que se hizo la planeación de las tareas y de los
En PSP2.1 se incluyen plantillas de diseño recursos. Al cliente, el plan le indica todo lo
que ayudan a garantizar que el diseño esté correspondiente al producto que recibirá, el
completo y sea coherente con las necesida- tiempo y el costo involucrados, la evaluación
des planteadas. El PSP no dice cómo realizar de los progresos y la manera en la que va a ser
el diseño; para ello se puede usar cualquiera desarrollado el proyecto.
de las metodologías existentes. Para poder planear un proyecto se re-
En la etapa PSP3 se plantea un proceso quiere poder estimar el tamaño del sistema.
cíclico, útil para el desarrollo de programas El método elegido para hacer la estimación
o módulos muy grandes. El problema debe debe ser automático, preciso y útil para la
subdividirse de tal manera que cada uno de planeación. En PSP se usa el método PROBE
los subproblemas quede en un nivel PSP2. (PROxy-Based Estimating). Además, se
PSP se apoya fundamentalmente en la debe establecer un estándar para el conteo
planeación del proyecto y en la calidad con de líneas de código, de funciones o de los
CAP. 12.indd 373 10/31/07 8:31:28 PM

374 CAPÍTULO 12
elementos que se vayan a contar para esti- de entender y adaptar. Cada desarrollador de-
mar el tamaño. be definir su propio proceso de calidad. Para
Otro elemento importante que interviene ello debe primero definir un proceso y poste-
en la planeación es la estimación del tiempo riormente medirlo, darle seguimiento y me-
requerido para desarrollar el producto. En jorarlo de manera continua. Se recomienda
PSP la selección del método para estimar el la siguiente estrategia para asegurar la calidad
tiempo depende de la cantidad de datos his- del proceso:
tóricos disponibles.
1. Medir la calidad del proceso a través de
12.4.1.3 ADMINISTRACIÓN la calidad del producto, de la producti-
vidad alcanzada, del total de defectos
DE LA CALIDAD
corregidos, entre otros.
2. Incorporar los mejores métodos de
La estrategia seguida por PSP para asegurar la calidad (por ejemplo, revisiones e ins-
calidad del producto desarrollado se lleva a pecciones), encontrar las causas de los
cabo a través del manejo de la cantidad de errores que se cometen, usar los me-
defectos insertados en el software. Si se con- jores métodos para el diseño, entre
trolan los defectos en cada unidad de soft- otros.
ware, se puede garantizar la calidad de todo el 3. Evaluar periódicamente la estrategia y
sistema una vez que las partes sean integradas. establecer nuevos objetivos, obedecien-
La calidad del producto está estrechamente li- do al carácter dinámico de PSP en cuan-
gada con la calidad del proceso seguido para to a la mejora del proceso.
su producción. Para determinar el nivel de ca-
lidad del proceso usado, se deben establecer
métricas y hacer seguimientos del proceso. 12.4.1.4 EL USO DE PSP
La calidad también se mide por el servicio
prestado al usuario. Este servicio incluye si el La adopción de PSP es eficaz cuando existe
sistema es fácil de usar, de instalar y de man- un compromiso por parte de toda la organi-
tener, si es seguro tanto al protegerse contra zación, o al menos de un grupo de la misma.
los mismos usuarios como de externos, si su Inicialmente implica cambiar los hábitos de
desempeño es aceptable y si está acompaña- trabajo, recopilar datos, realizar planes, escri-
do de toda la documentación necesaria. PSP bir reportes y realizar otras actividades que
se centra en los defectos, ya que si un sistema aquellos que no están familiarizados con el
de baja calidad entra a la etapa de pruebas proceso podrían considerar como una pérdi-
es casi seguro que se descuidarán los otros da de tiempo. Además, la organización que
aspectos relacionados con la calidad por de- está desarrollando el proyecto debe dar apo-
tectar y corregir todos los defectos. En el área yo para formar la base de datos y llevar a cabo
de la ingeniería de software, la mayoría de los el análisis de los datos recolectados. Por lo
defectos de un programa proviene de erro- tanto, es importante que los desarrolladores
res cometidos por los individuos que lo desa- y administradores entiendan los beneficios
rrollaron. Generalmente un proceso de baja que ofrece PSP y colaboren para que el per-
calidad produce un producto de baja cali- sonal se capacite y defina su propio proceso.
dad. De ahí la insistencia de PSP de que cada En (Humphrey 2004c) se señalan los cos-
desarrollador defina un proceso propio de tos y beneficios relacionados con el uso de
alta calidad. PSP. Con respecto a los costos, en primer lugar
Un PSP de calidad es aquel que se ajusta se indica el tiempo necesario para aprender a
a las características del desarrollador y le per- usarlo. Se requiere tiempo para aprender PSP
mite producir software de excelente nivel de y para registrar los datos, tarea que debe ha-
manera sistemática. Además, debe ser fácil cerse continuamente para poder contar con
CAP. 12.indd 374 10/31/07 8:31:28 PM

información válida cuando haya que hacer En la actualidad ya no es posible seguir

planes y estimaciones, y para ir mejorando de desarrollando software de manera artesanal,
manera permanente el proceso propio de de- como se solía hacer al inicio de la compu-
sarrollo. Definir y usar un proceso personal tación. La industria del software requiere que
puede ocasionar un costo emocional. Se re- cada uno de los involucrados haga un trabajo
quiere de mucha disciplina para usar un pro- profesional. Los desarrolladores, además de
ceso, autoevaluarse y detectar aquellas áreas usar PSP, deben utilizar métodos eficaces, te-
en las que se puede mejorar. Una vez detec- ner presente sus fortalezas y debilidades, prac-
tadas las oportunidades de mejoras, se deben ticar mucho, aprender de sus experiencias y
establecer objetivos y las medidas que lle- estar dispuestos a seguir mejorando.
ven a alcanzar esos objetivos. Por último, se
pone en riesgo el ego. Junto al costo emocio-
12.4.2 TSP (Team Software
nal de estar buscando una mejora continua
está el efecto que esto puede tener sobre Process)
la imagen que cada uno tiene acerca de sí
mismo. Con el uso de PSP queda explícito el El TSP (Humphrey, 2004b) es un proceso
desempeño de cada persona. Sin embargo, de desarrollo de software en equipo. El TSP
es importante señalar que para el desarrollo ofrece un marco de trabajo para los equipos
de software son necesarias diferentes habi- encargados de desarrollar grandes sistemas.
lidades, conocimientos y aptitudes. Por lo tan- Dedica atención al proceso, al producto y
to, cada uno debe identificar sus fortalezas y al trabajo en grupo. Además, basado en ex-
tratar de mejorar las áreas menos fuertes por periencias, guía cómo planear y administrar
medio de la experiencia. proyectos de software de gran tamaño que
Los beneficios son muchos, tanto a nivel requieren ser realizados por grupos de pro-
personal como a nivel de la organización. En gramadores. Un equipo no se forma simple-
cuanto a los beneficios personales, el desarro- mente con la unión de varios programadores.
llador puede conocer y entender sus propias Se necesita definir objetivos comunes, un plan
fortalezas y debilidades, y aprovechar las pri- de acción aceptado por todos, tener lideraz-
meras y buscar superar las últimas. Además, go adecuado, conocer y respetar las debilida-
define su propio proceso sobre el que tiene des y fortalezas de cada miembro, ayudarse
control, y está en condiciones de mejorarlo entre compañeros y ser capaz de pedir ayuda
continuamente y en consecuencia mejorar cuando se requiera. Debido a esto, resulta de
su desempeño. Cuenta con datos para hacer fundamental importancia definir un proceso
planes más certeros. Con estos planes puede para el trabajo en equipo.
hacer seguimientos sobre su trabajo, lo cual Para que el grupo de desarrollo pueda ir
le permite administrarlo mejor. A nivel de la mejorando su proceso, TSP, al igual que PSP,
organización, si PSP es adoptado por todos requiere del registro continuo de los datos del
los programadores, éstos pueden definir un proyecto. Los datos recopilados, a nivel per-
proceso de desarrollo en equipo de mejor sonal y de equipo, sirven para hacer estima-
calidad. Cada miembro del equipo puede ha- ciones más precisas de tiempo y tamaño en el
cer su trabajo sin depender tanto del desem- futuro, así como para conocer el desempeño
peño de sus compañeros. La organización de los involucrados e implementar medidas
puede hacer planes más certeros y tener más para lograr mejoras. TSP provee un conjunto
elementos para negociar con sus clientes: de formas que sirven para ese registro.
puede planear el tamaño del producto que TSP está diseñado para grupos de por lo
va a entregar, la calidad del mismo, el tiempo menos veinte ingenieros de software dedica-
que requiere para su desarrollo y la cantidad dos a proyectos de gran tamaño que requie-
de personas que asigna para trabajar en el ren de varios años de desarrollo. Se define
proyecto. TSPi (introductory Team Software Process)
CAP. 12.indd 375 10/31/07 8:31:29 PM

376 CAPÍTULO 12
como una versión reducida de TSP, que man- diseño, implementación, prueba y postmor-
tiene sus mismos principios, y a partir de la tem. Además, usa múltiples ciclos para cons-
cual se puede escalar fácilmente a TSP. En truir un producto final. En cada uno de los
este libro se describe TSPi. Tanto TSP como ciclos se aplican los ocho procesos menciona-
TSPi presuponen que todos los miembros del dos. Se inicia con una junta de lanzamiento,
equipo conocen PSP. en la que se presentan los objetivos del pro-
ducto. Posteriormente, se aplican los otros
12.4.2.1 LOS PRINCIPIOS DE TSPI siete procesos. En el siguiente ciclo se aplican
los mismos procesos, pero trabajando sobre
lo que haya sido desarrollado en el ciclo an-
TSPi está basado en cuatro principios funda-
terior, logrando que el producto vaya aumen-
mentales:
tando sus funcionalidades. La cantidad de
1. El aprendizaje es más eficaz si se sigue ciclos depende del tamaño del proyecto y del
un proceso definido y se recibe retro- tiempo que se disponga. En la figura 12.6 se
alimentación. TSPi provee un marco de presenta un esquema de la estructura y del
trabajo que cumple con estas caracterís- flujo de TSPi.
ticas. Además, cuenta con mediciones Para usar una estrategia de desarrollo cí-
establecidas y está diseñado para reali- clica se requiere definir el producto básico
zarse de manera cíclica. El uso de ciclos que se ha de generar con el primer ciclo. Se
pequeños permite que el equipo reciba recomienda que sea una versión pequeña del
información sobre su desempeño pe- producto, pero que incluya alguna funciona-
riódicamente. Es decir, el trabajo del lidad que dé valor al negocio. Para decidir el
grupo se evalúa al terminar cada ciclo y contenido y tamaño de cada ciclo se debe
los resultados se analizan y utilizan para tener en cuenta que debe producir una ver-
mejorar el desempeño del mismo. sión que pueda probarse y que represente un
2. Para que el trabajo en equipo sea pro- subconjunto de la versión final del producto,
ductivo, se requiere definir objetivos, que debe ser lo suficientemente pequeño
un ambiente de trabajo apropiado y para que pueda desarrollarse y probarse en
liderazgo adecuado. el tiempo disponible y que la combinación de
3. Es importante recibir la guía apropia- los productos obtenidos en cada ciclo debe
da para encontrar soluciones eficaces dar el producto final deseado.
a los problemas de desarrollo que se
originen. TSPi ayuda a definir papeles,
métodos y prácticas adecuadas para
12.4.2.3 LOS PROCESOS DE TSPI
cada grupo de trabajo.
4. La instrucción es más eficaz cuando Los ocho procesos de TSPi aplicados de ma-
se construye sobre la base de conoci- nera cíclica permiten a los equipos de inge-
mientos previamente adquiridos. TSPi nieros de software alcanzar productos de alta
se basa en el conocimiento y las expe- calidad en el tiempo estimado. TSPi provee
riencias que existen sobre equipos de una guía en la que se presenta el objetivo, el
desarrolladores de software y material criterio de entrada, las etapas (con las activi-
disponible sobre este tema. dades que involucra cada una de ellas) y el
criterio de salida de cada proceso. El criterio
de entrada es todo aquello que necesita el
12.4.2.2 LA ESTRUCTURA Y EL FLUJO proceso para llevarse a cabo y el criterio de
DE TSPI salida es el producto o los productos gene-
rados por el proceso. Asimismo, la guía pro-
TSPi está formado por ocho procesos: lan- porciona unas formas para el registro de todos
zamiento, estrategia, plan, requerimientos, los datos relevantes del proyecto. Estos da-
CAP. 12.indd 376 10/31/07 8:31:29 PM

Instrucciones sobre el producto a desarrollar
Ciclo 1 - Lanzamiento
Ciclo 2 - Lanzamiento
Estrategia 1
Plan 1
Ciclo n - Lanzamiento
Requerimientos 1
Estrategia 2
Diseño 1
Plan 2
Implementación 1
Requerimientos 2 Estrategia - n
Prueba 1
Plan - n
Diseño 2
Postmortem 1
Requerimientos - n
Implementación 2
Diseño - n
Prueba 2
Implementación - n
Postmortem 2
Prueba - n
Postmortem - n
Producto terminado
Evaluación final
Figura 12.6 Estructura y flujo de TSPi.
tos sirven para evaluar el desempeño del equi- administrador de planeación, administrador
po, de cada uno de sus integrantes y definir de la calidad del proceso y administrador de
posibles mejoras al proceso de desarrollo. soporte. Los miembros del equipo a quie-
nes se les asignan estos roles realizan tam-
bién actividades propias de los ingenieros de
12.4.2.3.1 LANZAMIENTO software.
Establecer objetivos es de fundamental im-
El establecimiento del equipo de trabajo se portancia. Se requiere que los mismos estén
lleva a cabo en la etapa de lanzamiento. Se de- bien definidos y sean cuantificables. Si no
terminan las relaciones de trabajo, los roles de se pueden medir, entonces resulta difícil de-
los miembros, quién va a ocupar cada uno terminar con precisión la calidad del pro-
de ellos y se llega a un acuerdo sobre los ob- ducto generado y del proceso seguido por el
jetivos. equipo. Se deben fijar objetivos ambiciosos
Los roles básicos propuestos por TSPi son: pero realistas, de tal manera que motiven a
líder de equipo, administrador de desarrollo, los integrantes del grupo. Para fijar objeti-
CAP. 12.indd 377 10/31/07 8:31:30 PM

378 CAPÍTULO 12
vos con estas características, es importante También se deben establecer objetivos para
contar con experiencias previas. Cuando no cada uno de los roles definidos en el equipo. Es
se cuente con esta experiencia, TSPi sugiere importante tener presente que, en caso de que
adoptar, como objetivos básicos, elaborar un haya un conflicto entre los objetivos del equipo
producto de calidad, llevar a cabo un pro- y los personales o de papeles, la prioridad más
yecto productivo y bien administrado, y ter- alta la tiene el objetivo del equipo.
minar el proyecto a tiempo. Cada objetivo
debe acompañarse de métricas para que pue-
da evaluarse en qué grado fue alcanzado. En
12.4.2.3.2 ESTRATEGIA
la tabla 12.3 se presentan los objetivos pro-
puestos por TSPi con sus correspondientes Una vez completada la etapa de lanzamiento,
métricas. se debe fijar una estrategia para llevar a cabo el
Después de cada ciclo se debe evaluar el proyecto. En esta etapa se debe idear una es-
desempeño y establecer objetivos para me- trategia para realizar el trabajo, crear un diseño
jorar el proceso en el siguiente ciclo. Luego conceptual del producto, y hacer una estima-
se deben definir los cambios necesarios para ción preliminar del tamaño del producto y
que los objetivos planteados puedan ser al- del tiempo de desarrollo. El tiempo estimado
canzados. debe corresponder al tiempo disponible. De
Además de los objetivos para el equipo, no ser así, se debe revisar y ajustar la estrategia
se deben establecer objetivos para cada uno hasta que los tiempos coincidan.
de los miembros del mismo. Si no se cuenta TSPi propone un proceso cíclico en el que
con experiencia previa, TSPi sugiere adoptar cada ciclo toma la versión del sistema gene-
los objetivos y las métricas que se presentan rada en el ciclo anterior y produce una ver-
en la tabla 12.4. sión aumentada. La cantidad total de ciclos
Tabla 12.3 Objetivos propuestos para el equipo y sus indicadores.
Objetivos Indicador 1 Indicador 2 Indicador 3
Producir un El porcentaje de La cantidad Al terminar el

producto de defectos encontrados de defectos proyecto se debió
calidad antes de la primera encontrados en la haber incluido
compilación debe ser prueba del sistema el 100% de las
80%. debe ser 0. funcionalidades
requeridas.
Llevar a cabo El error en la El error en la El porcentaje de

un proyecto estimación del estimación del datos del proyecto
productivo tamaño del producto número de horas de registrados debe ser
y bien debe ser menor a desarrollo debe ser 100%.
administrado 20%. menor a 20%.
Terminar el El total de días de

proyecto a tiempo retraso o adelanto
para completar el
ciclo debe ser menor
a 4.
CAP. 12.indd 378 10/31/07 8:31:32 PM

Tabla 12.4 Objetivos propuestos para los miembros del equipo y sus indicadores.
Objetivos Indicador 1 Indicador 2 Indicador 3 Indicador 4
Ser un El promedio de El promedio de

miembro la evaluación la evaluación
del equipo de cada miembro de cada miembro
cooperativo del equipo, del equipo,
y efectivo efectuada por efectuada por los
los pares acerca pares acerca de
de la disposición la contribución
a ayudar y la general hecha al
aportación del equipo, debe ser
trabajo, debe ser mayor a 3.
mayor a 3.
Realizar El porcentaje de los El porcentaje

un trabajo datos personales de semanas
personal registrados debe registradas en
disciplinado ser 100%. el documento
semanal debe ser
100%.
Planear y dar El porcentaje El porcentaje de las

seguimiento de los datos del tareas del proyecto
al trabajo proyecto personal con plan y datos
personal registrados reales registradas
en las formas en la forma
correspondientes correspondiente
debe ser 100%. debe ser 100%.
Producir El porcentaje La densidad La densidad La densidad

productos de defectos de defectos de defectos de defectos
de calidad encontrados encontrados encontrados encontrados
antes de la primer durante la durante la después de
compilación debe compilación debe prueba de la prueba de
ser mayor a 70%. ser menor a unidad debe unidad debe
10/KLOC. ser menor a ser 0.
5/KLOC.
depende del tamaño del sistema y del tiempo producto. Para esto, TSPi sugiere contestar
disponible. las siguientes preguntas:
El diseño conceptual se requiere para po-
der hacer posteriormente la planeación del 1. Tomando en cuenta experiencias pre-
proyecto. Se debe lograr un diseño de alto vias, ¿cómo se podría desarrollar este
nivel, definiendo la estructura general del producto?
CAP. 12.indd 379 10/31/07 8:31:32 PM

380 CAPÍTULO 12
2. ¿Cuáles son los principales componen- en el plan inicial. Por lo tanto, es conveniente
tes que deben construirse para lograr incluir algunas horas en el plan para realizar
este producto? esas tareas, especialmente en el primer ciclo.
3. ¿Cuáles son las funciones que estos El resultado de este proceso es el plan
componentes deben proveer? completo del equipo y de cada uno de los
4. ¿Qué tan grande son estos componen- ingenieros que lo forman, incluyendo tareas,
tes? tiempos y calidad.
Hecho el diseño conceptual, se puede 12.4.2.3.4 REQUERIMIENTOS

estimar el tamaño del producto así como el
tiempo requerido para su desarrollo.
En esta etapa, las especificaciones de los re-
querimientos del sistema son generadas por
12.4.2.3.3 PLAN el grupo de trabajo. Éstas deben ser claras y
precisas. Además, el equipo debe definir in-
El plan indica todas las actividades y el orden dicadores que permitan evaluar el producto
en el que deben realizarse. Proporciona el terminado para asegurar que éste cumpla
marco y el contexto de trabajo. Una vez de- con todas las especificaciones planteadas por
finido el plan, se puede trabajar de manera el cliente.
más eficiente, pues se sabe qué hacer y cuán- Para obtener una buena especificación de
do hacerlo. los requerimientos, normalmente se necesita
Las actividades planeadas entre los miem- dedicar tiempo junto al usuario final del siste-
bros del equipo deben ser distribuidas de ma- ma, o un representante del mismo. Es impor-
nera equilibrada. Es decir, el trabajo asignado tante que no queden dudas acerca de lo que
a cada miembro del equipo se debe poder se espera del sistema. Por lo tanto, a través
realizar en el mismo periodo de tiempo. De de preguntas y respuestas los miembros del
esta manera no se ocasionan esperas inútiles equipo junto al usuario deben ir definiendo
para algunos miembros, mientras otros están y precisando todos aquellos aspectos que ha-
saturados de trabajo. yan quedado ambiguos. Algunas veces, los
Por otra parte, los planes permiten hacer usuarios no tienen claro qué necesitan (o no
seguimientos del trabajo y avances de cada lo saben expresar explícitamente), por lo que
miembro del equipo. Durante el desarrollo durante esta etapa se les debe ayudar a de-
de un producto se realizan varias tareas que finir y precisar sus expectativas acerca del
se planean para ser ejecutadas en un cierto sistema. Una vez que se llegue a un acuerdo
tiempo. El seguimiento permite saber en cada con el cliente sobre los requerimientos, cual-
momento cuáles tareas fueron completadas y quier cambio ocasionará un incremento en el
en qué tiempo, y de esta manera saber si se costo y/o tiempo (y esto le debe quedar claro
está cumpliendo con el calendario estable- al cliente).
cido. Para que los retrasos no sean excesiva- Los requerimientos son obtenidos duran-
mente costosos, es conveniente tener planes te una etapa de extracción en la que se pre-
detallados. TSPi sugiere subdividir cada acti- gunta al usuario final (y/o al cliente) acerca de
vidad en unidades que no consuman más de sus necesidades. Algunas actividades propias
diez horas de trabajo. De esta forma, en caso de la obtención de los requerimientos son:
de que una tarea se retrase no implicaría evaluar la viabilidad del sistema, entender las
más de diez horas de atraso en todo el pro- características de la organización, evaluar
yecto antes de que se detecte el problema. las características del negocio, identificar los
Otro aspecto importante a tener en cuen- usuarios del sistema, registrar las fuentes de
ta es que durante el desarrollo del proyecto requerimientos, definir el ambiente de ope-
pueden surgir algunas tareas no contempladas ración del sistema, registrar aquellos reque-
CAP. 12.indd 380 10/31/07 8:31:32 PM

rimientos que fueron bien entendidos, reali- formar el sistema. Los estándares más impor-
zar prototipos de aquellos requerimientos tantes para realizar el diseño de alto nivel son
sobre los que se tenga alguna duda, definir los siguientes:
posibles escenarios de uso del sistema e iden-
tificar restricciones del dominio. 1. Convenciones para la identificación.
En la tabla 12.5 se presentan los requeri- Se debe establecer el criterio que se
mientos, clasificados por tipos, en los que se va a aplicar para nombrar al sistema,
centra TSPi. sus componentes, módulos, archivos,
Durante la elaboración del documento variables y demás elementos.
de requerimientos, el equipo discute acerca de 2. Formatos para la relación. Se debe
la necesidad del cliente, la posible solución especificar cómo va a ser la comunica-
y cómo se va a implementar. De esta forma ción entre las partes del software, pa-
se genera el documento y se va logrando un rámetros de entrada/salida, códigos de
acuerdo entre los miembros del grupo sobre error u otras condiciones que deban
el producto que van a desarrollar. preverse.
3. Mensajes. Se debe establecer un están-
dar para escribir los mensajes de tal ma-
12.4.2.3.5 DISEÑO nera que la información proporcionada
por el sistema resulte comprensible.
En este proceso se elabora un diseño de alto 4. Estándar de defectos. TSPi sugiere uti-
nivel del sistema (es decir, de la estructura lizar el estándar de defectos propuesto
general del mismo). El diseño es un proceso por PSP que se pueden consultar en
creativo que permite identificar los princi- (Humphrey 2004a).
pales componentes, así como la manera en 5. Conteo de líneas de código. Si bien aún
que éstos interactúan. Esto ayuda a decidir no se utilizará, TSPi sugiere que en esta
la manera en la que se va a desarrollar cada una etapa se defina el estándar para llevar a
de las partes y cómo van a ser integradas para cabo el conteo de líneas de código.
Tabla 12.5 Principales requerimientos manejados por TSPi.
Tipo de requerimientos Relacionado con
Funcionales Entradas, salidas, cálculos y casos de uso.
De vinculación del sistema Usuarios, hardware, software, comunicación con otras

con el exterior computadoras o dispositivos.
De software Manejadores de bases de datos, lenguajes, instalación,

etcétera.
De diseño Estándares, compatibilidad, integración con otros

sistemas, etcétera.
Otros Seguridad, mantenimiento, portabilidad, etcétera.
CAP. 12.indd 381 10/31/07 8:31:33 PM

382 CAPÍTULO 12
6. Estándar para la representación del generan otros productos que deben

diseño. Se debe establecer un estándar medirse y para los cuales se requiere de-
para que el diseño generado pueda ser finir nuevos estándares. Algunos ejem-
entendido sin ambigüedades por todos plos de estos productos son los docu-
los miembros del equipo. mentos con los requerimientos y el
diseño, pantallas y reportes, bases de
Otros aspectos que deben tenerse en datos, y reportes de pruebas.
cuenta durante este proceso son la facilidad 4. Estándar de defectos. Se sugiere adop-
de uso del sistema y la prueba del mismo. tar el estándar propuesto en PSP (Hum-
Además, se sugiere que se revise y se inspec- phrey, 2004a). Éste es útil para poder
cione el diseño generado. clasificar los defectos y posteriormente
analizarlos con el objetivo de mejorar
12.4.2.3.6 IMPLEMENTACIÓN el proceso.
5. Prevención de defectos. Es importante
conocer las causas que pueden ocasio-
Este proceso produce la implementación del
nar los defectos. Un ejemplo de una
producto. Antes de la codificación se debe
posible causa de defectos es la falta de
hacer un diseño más detallado, a partir del
conocimiento del lenguaje o del am-
diseño de alto nivel generado en la fase an-
biente de desarrollo utilizado. Una vez
terior. Es conveniente ir subdividiendo cada
detectada la causa se pueden tomar las
parte del sistema hasta que los elementos a
medidas correspondientes para elimi-
codificar lleguen a tener 150 o menos líneas.
narla. En este caso sería aprender más
Una vez que se alcance este nivel de detalle,
sobre el lenguaje o el ambiente.
se procede a la codificación de los elementos,
la cual se puede hacer de manera paralela por
Luego de la codificación se debe revisar y
diferentes miembros del equipo.
posteriormente inspeccionar el código. Cada
Aquí se definen algunos estándares de im-
unidad debe ser revisada por el programador
plementación que aumentan y complemen-
que la desarrolló. El tiempo estimado para
tan los que se presentaron en la discusión
llevar a cabo la revisión es al menos el 50%
sobre el proceso de diseño:
(preferentemente el 75%) del tiempo usado
para la codificación. Luego es conveniente
1. Revisión de estándares. Se revisan los
que otros programadores inspeccionen el
estándares definidos en el proceso an-
código generado.
terior (diseño) y, si siguen resultando
útiles, éstos se emplean. Se recomien-
da ir mejorándolos a medida que se 12.4.2.3.7 PRUEBA
va adquiriendo experiencia con ellos
y que todos los miembros del equipo Este proceso se aplica para probar el produc-
los utilicen. to obtenido. Es importante que la mayoría
2. Estándar de codificación. Éste debe de los defectos (preferentemente todos) se
ser usado por todos los miembros, ya hayan detectado y corregido antes de esta
que esto facilitará la revisión e inspec- etapa, ya que si no, el costo de hacerlo se in-
ción del código, así como la medición crementa notablemente. En TSPi se sugiere
del sistema en líneas de código, funcio- seguir las siguientes prácticas de prueba:
nes, objetos o el criterio que se decida
seguir. 1. Construir el sistema integrando unida-
3. Estándar de tamaño. Permite contar des ya probadas.
líneas de código para medir el sistema. 2. Probar el sistema integrado para eva-
Sin embargo, durante el proyecto se luar si fue construido de manera co-
CAP. 12.indd 382 10/31/07 8:31:33 PM

rrecta y verificar que están todas las requieren del trabajo de equipos, no de pro-
partes presentes y que funcionan ade- gramadores individuales. Además, los equi-
cuadamente juntas. pos en los cuales cada miembro cuenta con
3. Probar el sistema para evaluar que cu- buenas prácticas de trabajo, y trabajan coo-
bre todos los requerimientos. perativa y eficazmente juntos, producen re-
sultados de alta calidad. Cuando un equipo
En esta fase, mientras algunos ingenieros encuentra condiciones adecuadas, sus miem-
prueban el sistema, otros deben ir elaboran- bros realizan un trabajo superior, son más
do la documentación que se va a entregar al productivos y disfrutan su trabajo.
usuario. Dentro de esta documentación se de-
ben incluir todas las explicaciones necesarias 12.4.3 XP (Extreme
para entender la instalación, entrenamiento,
uso y mantenimiento del sistema.
Programming)
La programación extrema (Beck, 2004) ofre-
12.4.2.3.8 POSTMORTEM ce un marco flexible, de bajo riesgo y eficien-
te para el desarrollo de software, basándose
En este proceso se revisa todo el trabajo he- en algunos principios muy sencillos. XP se
cho por los ingenieros y todos los datos reco- caracteriza además porque tiene en cuenta
lectados durante los procesos previos. Poste- al ser humano como elemento clave en el de-
riormente se hace un análisis para identificar sarrollo.
los puntos en los cuales se puede mejorar el El desarrollo de software es una actividad
proceso, lo cual provee un medio para apren- dinámica que exige mucha flexibilidad y dis-
der y mejorar. Se debe comparar lo planeado posición por parte de los clientes y de los de-
con lo hecho. Además, se deben detectar sarrolladores. Algunos de los problemas que
oportunidades para mejorar y decidir cam- surgen en los proyectos de software son los
bios en las prácticas para el siguiente ciclo o siguientes: cambios en el negocio durante el
proyecto. desarrollo del sistema, cancelación de parte
Para determinar en qué áreas se puede o todo el proyecto, introducción de defectos
mejorar el proceso se deben realizar revisio- en el diseño y/o en el código, implementación
nes. Algunas de las más importantes son: de requerimientos que no fueron solicitados,
cambios en el equipo de trabajo, caducidad
1. Revisión de calidad. Se debe comparar del sistema, etc. XP toma en cuenta todas
la calidad planeada a nivel personal y a estas posibles desventajas del desarrollo de
nivel de equipo con la calidad produci- software y genera prácticas para vencerlas o
da. Deben plantearse las siguientes tres disminuir sus consecuencias.
preguntas. ¿Qué se puede aprender de
esta experiencia? ¿Qué objetivos se
pueden plantear para el siguiente de- 12.4.3.1 LAS VARIABLES DE XP
sarrollo? ¿Dónde se podría modificar
al proceso para mejorarlo? XP es un modelo de desarrollo de software
2. Evaluación de roles. Se deben evaluar en el que hay cuatro variables que juegan un
los diferentes roles del equipo. Deben papel fundamental: costo, tiempo, calidad y
plantearse las siguientes tres pregun- alcance. La interacción entre las variables y el
tas. ¿Qué sirvió? ¿Dónde hubo proble- control de las mismas son decisivos para el éxi-
mas? ¿Qué se puede mejorar? to del proyecto. El control de estas variables
es llevado a cabo por los programadores, ad-
El éxito de TSPi se basa en que la mayoría ministradores y clientes. Aquí se analizan las
de los sistemas que se desarrollan actualmente cuatro variables:
CAP. 12.indd 383 10/31/07 8:31:34 PM

384 CAPÍTULO 12
1. Costo: hace referencia a cuánto cuesta siempre que no se descuiden las funciona-
(en recursos humanos, tecnológicos y de lidades más importantes, para mantener el
oportunidad) desarrollar y/o mantener costo, la calidad y el tiempo.
un producto de software. XP propone
empezar invirtiendo poco e ir gastando 12.4.3.2 LOS VALORES DE XP
más de manera productiva, es decir en-
tregando resultados útiles al cliente. Los valores de XP son la comunicación, la
2. Tiempo: hace referencia al tiempo que simplicidad, la retroalimentación y la valentía.
transcurre hasta que un sistema se libera. Éstos deben ser aceptados y respetados por
XP propone establecer alcances a corto todos los miembros del equipo y de la orga-
plazo, de tal manera que los programas, nización, ya que de ellos depende el éxito de
con sólo algunas de sus funciones, entren este modelo.
en producción, y con la retroalimenta- La comunicación es básica en el desarro-
ción que se recibe se siga agregando llo de software (¿existirá alguna actividad en
funcionalidades y mejorando lo existente. la cual no lo sea?). Muchos de los problemas
3. Calidad: hace referencia a que el soft- que se presentan en los proyectos de soft-
ware desarrollado se ajuste a los reque- ware tienen su origen en la falta de comu-
rimientos del cliente, así como a que el nicación. Por ejemplo, se pueden ocasionar
mismo esté libre de defectos. El nivel de graves problemas si un programador no avisa
calidad es medido por los programado- a sus compañeros acerca de un cambio que
res, dando origen a la calidad interna. introdujo en el código o reporta de mane-
También es medido por los clientes, lo ra inadecuada el grado de avance del pro-
cual se conoce como calidad externa. ducto, o un cliente no avisa a tiempo a los
XP propone realizar pruebas de manera programadores que un requerimiento cam-
continua sobre el producto que se está bió o no da toda la información necesaria a
desarrollando. Por otra parte, XP se apo- los programadores. XP ayuda a mantener una
ya en el hecho de que los seres huma- buena comunicación por medio de prácticas
nos quieren hacer un buen trabajo. Los que, por su naturaleza, exigen que los invo-
desarrolladores trabajan más a gusto y de- lucrados se comuniquen. Estas prácticas son
sarrollan con mayor calidad si sienten que las pruebas de unidades, la programación de
su trabajo es bueno. pares y la estimación de tareas. Además, y
4. Alcance: hace referencia a los objetivos complementando lo anterior, XP requiere de
que se plantean para el producto a desa- la actividad de una persona cuyo trabajo es
rrollar. Es una variable difícil de controlar detectar cuándo la gente no se está comuni-
porque, en la práctica, cuando se inicia cando bien y lograr que vuelvan a hacerlo.
un proyecto ni el cliente ni los progra- La simplicidad permite que los productos
madores tienen claro adónde se quiere se diseñen e implementen de la manera más
llegar con el desarrollo de un software sencilla posible. ¿Por qué usar una estructura
nuevo. Muchas veces a medida que el de tipo árbol para representar unos datos si el
sistema entra en producción, el cliente problema se puede resolver igualmente bien
se da cuenta de qué es lo que realmente usando un arreglo? Si bien es una tendencia
necesita. XP propone establecer alcances natural en el ser humano ver más allá de lo in-
pequeños, empezando siempre por los mediato, la simplicidad es un valor que debe
requerimientos de mayor prioridad para mantenerse en XP. Esta idea se fundamenta
el cliente. en el hecho de que tratar de desarrollar un
producto simple y tener un costo adicional,
La variable alcance puede condicionarse si posteriormente se debe aumentar, es pre-
a las otras tres. Se puede reducir el alcance, ferible a desarrollar un producto complejo y
CAP. 12.indd 384 10/31/07 8:31:34 PM

caro que posiblemente nunca se use y cuyo todo el sistema de una manera más simple.
desarrollo puede ser muy tardado. Existe una La valentía es importante siempre que estén
estrecha relación entre la simplicidad y la co- presentes los otros tres valores. La comunica-
municación. Cuanto más sencillo sea un pro- ción favorece la presencia de valentía entre
grama, más fácil será la comunicación entre los miembros del equipo ya que facilita que los
los involucrados en él. Cuanto más se comu- mismos intenten, de común acuerdo, tomar
niquen los miembros de un equipo, más fácil riesgo al cambiar un código o un diseño. La
será detectar con precisión las actividades simplicidad también la promueve, ya que es
que deben realizarse. más fácil tomar una decisión sobre un siste-
La retroalimentación acerca del estado ma simple que sobre un sistema complejo,
actual del proyecto es fundamental para poder especialmente si la decisión es tirar el siste-
tomar decisiones apropiadas. Se lleva a cabo ma al bote de la basura. La retroalimentación
por medio de pruebas. Se definen pruebas de también contribuye a su presencia, ya que es
unidades para garantizar que se va avanzando más seguro basar una decisión en la infor-
sobre resultados sólidos. De esta manera mación proporcionada por las pruebas que
los programadores prueban la lógica de sus en la intuición o idea que pueda tener algún
programas. Por otra parte, tanto los clientes miembro del equipo. Por su parte, la valentía
como los programadores responsables de las produce simplicidad. En cuanto se detecta
pruebas deben definir pruebas funcionales que un sistema puede simplificarse, se hacen
que permitan determinar el estado actual de los cambios necesarios para lograrlo.
todo el sistema. En cuanto se implemente Existe un elemento adicional señalado
un mínimo de funcionalidades que tengan por (Beck, 2004), sin el cual ninguno de los
sentido, el sistema debe ponerse en produc- otros valores se sostendría: el respeto. Es fun-
ción. Ya operando el sistema, el equipo de damental que todos los miembros del equipo
desarrollo recibirá retroalimentación valiosa se respeten mutuamente y respeten el traba-
sobre el desempeño del mismo y sobre otras jo de los demás. Se requiere compromiso y
funcionalidades que se podrán incorporar. La disfrutar ser parte de un equipo que hace las
retroalimentación se relaciona con los valores cosas bien.
ya mencionados. Cuanta mayor retroalimen-
tación se tenga, más fácil será la comunica-
ción. Seguramente será más eficaz comuni- 12.4.3.3 PRINCIPIOS BÁSICOS DE XP
car el hecho de que cierto código es inco-
rrecto por medio de una prueba que así lo Los principios básicos que se generan a partir
demuestre, que por medio de una discusión de los valores, y que ofrecen medios más con-
entre pares o entre administrador y progra- cretos para aplicarlos son: retroalimentación
mador. Por otra parte, cuanto más simple sea rápida, simplicidad, cambios incrementales,
un sistema más fácil será probarlo. cambios sin alterar lo ya desarrollado y traba-
La valentía permite tomar las decisiones jo de calidad.
oportunas en el momento exacto, aunque La retroalimentación rápida consiste en
parezcan descabelladas. Por ejemplo, si lue- obtener retroalimentación, interpretarla y
go de trabajar todo un día en un trozo de aplicar lo aprendido al sistema, lo más pronto
código, éste no funciona correctamente y su que se pueda. Todo lo que se puede aprender
desarrollo se está saliendo del plan, entonces de la experiencia se debe tratar de llevar al
con valor se debe desechar y volver a em- sistema cuanto antes.
pezar a la mañana siguiente. Si de repente a La simplicidad consiste en hacer un buen
algún miembro del equipo se le ocurre cómo trabajo para resolver el problema actual,
simplificar el sistema complejo ya desarro- confiando en que si en el futuro se necesita,
llado, la valentía de todos los miembros del se podrá aumentar la complejidad del siste-
equipo permite enfrentar el reto de rehacer ma. XP promueve soluciones simples, que se
CAP. 12.indd 385 10/31/07 8:31:35 PM

386 CAPÍTULO 12
ajusten a los requerimientos presentes, en funcionalidades, determinar el mínimo

lugar de dedicar esfuerzo buscando solucio- de funcionalidades requerido para que el
nes generales que se adelanten a necesidades negocio se beneficie al poner el sistema
futuras. en producción e indicar las fechas en
Los cambios incrementales consisten en las cuales se debe contar con el software.
hacer pequeños cambios que aunados lle- Por su parte, el personal técnico debe
ven a la solución de un problema. XP propo- estimar el tiempo para desarrollar una
ne cambios pequeños en la planeación, el di- determinada funcionalidad, informar a
seño, la codificación e incluso en los equipos los responsables del negocio acerca de
de trabajo. las consecuencias que puede haber al
Los cambios sin alterar lo ya desarro- tomar ciertas decisiones (por ejemplo,
llado consisten en que cada cambio que se la compra de una plataforma de desarro-
realiza no altere lo ya planeado, diseñado o llo), organizar las tareas y el equipo de
desarrollado. Es decir, que cada cambio sea trabajo para producir el software con alta
para incrementar las funcionalidades ya re- calidad, y definir el plan de las activida-
sueltas, no para reemplazarlas por otras. des de tal manera que se asegure realizar
El trabajo de calidad consiste en desarro- aquellas que son de más alta prioridad,
llar el trabajo de la mejor manera posible. Se así como empezar con aquellas que tie-
basa en que todos los miembros del equipo nen implícito un mayor riesgo para el
desean sentir que su trabajo es excelente. De negocio.
otra manera la motivación baja, el trabajo no 2. Alcance pequeño: se trata de definir en-
se disfruta ni se realiza de manera correcta y tregas tan pequeñas como sea posible,
finalmente todo el proyecto fracasa. pero que implementen al menos una de
las funcionalidades esperadas. XP pro-
pone que se hagan planes para periodos
12.4.3.4 LAS PRÁCTICAS DE XP cortos, por ejemplo uno o dos meses.
3. Metáfora: es una frase que define de ma-
Considerando los valores y los principios bá- nera sencilla todo el sistema. Se hace re-
sicos presentados, aquí se plantean las prác- ferencia al proyecto por medio de la me-
ticas requeridas para usar XP en el desarrollo táfora elegida. Ésta permitirá identificar
de software de alta calidad. Las prácticas los principales elementos del sistema y la
son: planeación, alcance pequeño, metáfora, relación entre ellos.
diseño sencillo, pruebas, reestructuración, 4. Diseño sencillo: se debe diseñar la solu-
programación de pares, propiedad colectiva, ción del problema de la manera más senci-
integración continua, 40 horas de trabajo por lla. Es decir, el diseño debe incluir sólo los
semana, cliente en el lugar de desarrollo y elementos necesarios para cubrir los re-
estándares de codificación. querimientos actuales. XP propone no di-
señar para el futuro, ya que lo único cierto
1. Planeación: permite determinar de ma- es lo que actualmente se está resolviendo.
nera rápida el alcance de la siguiente Además, se supone que el desarrollador
entrega. Para ello se deben considerar debe ser capaz de realizar cambios a su di-
tanto las prioridades del negocio como seño si en el futuro nuevos requerimientos
las estimaciones técnicas. El éxito de la lo exigen. El diseño se considera correcto
planeación depende en gran medida del si pasa todas las pruebas, no tiene lógica
equilibrio entre lo que se desea hacer y duplicada, expresa todos los propósitos
lo que es posible hacer. Los responsables importantes y tiene la menor cantidad po-
del negocio tienen que decidir sobre sible de elementos.
el alcance del sistema a desarrollar, es- 5. Pruebas: se debe probar cada una de las
tablecer las prioridades de las diversas unidades de un programa, así como el
CAP. 12.indd 386 10/31/07 8:31:35 PM

programa completo. XP lleva este concep- prueba, si falla tiene la certeza de que es
to al extremo, por lo que sostiene que sólo su parte la que tiene defectos.
cualquier función de un programa que no 10. Trabajar 40 horas semanales: la canti-
sea probada no existe. Los programa- dad de horas trabajadas por cada desa-
dores definen pruebas que validan la rrollador es un factor importante para
operación del sistema. Por su parte, los el éxito de un proyecto. A pesar de que
clientes definen pruebas funcionales que la cantidad de horas que cada persona
validan la operación del sistema desde puede trabajar de manera eficaz puede
el punto de vista del negocio. Cuanto variar, se sabe que para que el rendimien-
más probado esté un sistema, más fácil to se mantenga, la cantidad de horas no
será aceptar cambios. debe exceder las 40 semanales. Además,
6. Reestructuración: se revisa el programa se considera de fundamental importan-
cada vez que se agregan nuevas funcio- cia que los programadores dediquen los
nalidades, buscando simplificarlo. Si se fines de semana a realizar actividades dis-
detecta la posibilidad de hacer algo más tintas al trabajo y que tomen vacaciones.
simple, se hace. Cuando se requiere du- 11. Cliente en el lugar de desarrollo: el clien-
plicar código se está en presencia de un te, en este caso, es una de las personas
caso que exige la reestructuración del que usará el sistema cuando sea liberado,
sistema. y debe formar parte del equipo de tra-
7. Programación de pares: se programa bajo. Por lo tanto, debe ayudar al equipo
entre dos personas. Es decir, cada trozo contestando las preguntas que vayan sur-
de código es generado por un par de per- giendo, sin detener el trabajo, y definien-
sonas compartiendo una computadora. do prioridades entre funcionalidades a
Se establecen dos papeles entre los pro- implementar. Por otra parte, debido a su
gramadores. Uno de ellos se concentra participación activa durante el desarro-
en buscar la mejor manera de implemen- llo, el sistema podrá proporcionar mayor
tar el método o la clase asignada. El otro valor al negocio.
analiza el problema más globalmente 12. Codificación estándar: se requiere esta-
(por ejemplo, se cuestiona si se podría blecer un estilo común de codificación.
simplificar el sistema y así evitar la pro- Teniendo en cuenta las prácticas de pro-
gramación del método o clase actual o si gramación de pares, que todos son due-
se podrían definir nuevos casos de prue- ños del sistema y por lo tanto todos pue-
ba). La asignación de pareja es dinámica den de manera permanente modificar o
—cambian durante el transcurso del pro- agregar código y que el sistema se está
yecto. reestructurando de manera continua, es
8. Propiedad colectiva: todos los miem- de fundamental importancia establecer
bros del equipo son dueños del sistema. y respetar el estándar. XP propone que
Por lo tanto, todos tienen la posibilidad el estándar sea lo más sencillo posible,
de modificar o agregar código en cual- adoptado por los programadores de ma-
quier momento y todos tienen la misma nera voluntaria y que el mismo debe en-
responsabilidad ante el sistema. fatizar la no duplicación de código y la
9. Integración continua: se debe ir inte- comunicación entre los miembros del
grando y probando el código de manera equipo.
continua. XP propone que se integre lue-
go de algunas horas de trabajo o como XP se apoya en el hecho de que si estas
máximo una vez al día. El código inte- prácticas son buenas, entonces ¿por qué no
grado debe pasar todas las pruebas de- usarlas de manera intensiva? Es decir, si inte-
finidas. De esta manera, cuando otro par grar código es una práctica buena, ¿por qué
de programadores integra su parte y la no integrar código de manera continua? O, si
CAP. 12.indd 387 10/31/07 8:31:36 PM

388 CAPÍTULO 12
la simplificación del sistema es una práctica sables del negocio, los clientes, y los de los
buena, ¿por qué no simplificar continuamen- responsables de la tecnología, los desarrolla-
te? Lo mismo se podría decir acerca de las prue- dores. El éxito de un proyecto depende de
bas. Si es bueno probar el código, ¿por qué que los grupos colaboren entre sí y manten-
no probarlo todo el tiempo? gan una buena comunicación.
Las prácticas se apoyan mutuamente, De acuerdo con lo presentado en las sec-
y muchas de ellas sólo pueden aplicarse ciones precedentes, se puede decir que XP
en presencia de otras. Por ejemplo, esta- es un modelo de programación novedoso e
blecer alcances pequeños es posible sólo interesante. Una de las razones para efectuar
si se hace una planeación adecuada, si se esa afirmación es la importancia que le da al
hacen diseños sencillos que puedan imple- ser humano como pieza clave en el desarro-
mentarse fácil y rápidamente, y si el código llo de software. Esto da origen a algunas de
se prueba e integra de manera continua. las prácticas y estrategias del modelo, como
Por su parte, el estándar de codificación, la cantidad de horas trabajadas, la comuni-
que implica un esfuerzo adicional para los cación entre miembros del equipo y el am-
miembros del equipo, se requiere y justifica biente de trabajo. Otro pilar de este modelo
si se tienen otras prácticas como la progra- que merece ser destacado es la idea de que
mación de pares, la propiedad colectiva y toda persona gusta de hacer las cosas de la
la integración continua. En la figura 12.7 se mejor manera posible, por naturaleza, no por
presenta un esquema de la relación entre obligación.
prácticas de XP. Las diferencias más importantes entre XP
XP resalta la importancia de buscar un y otras metodologías de programación se re-
equilibrio entre los intereses de los respon- sumen en la tabla 12.6.
Metáfora
Planeación
Clientes en el lugar de desarrollo
40 horas/semana
Restauración
Propiedad colectiva Alcance pequeño
Diseño sencillo
Estándares de
codificación
Pruebas
Programación de pares
Integración continua
Figura 12.7 Relación entre las prácticas de XP.
CAP. 12.indd 388 10/31/07 8:31:36 PM

Tabla 12.6 Diferencias entre XP y otras metodologías de programación.
XP Otras metodologías de
programación
Diseño Evolutivo Fijo
Codificación En pares Individual
Complejidad Sólo si no se puede evitar Permitida
Integración Continua Al final del desarrollo
Pruebas Continua Al terminar cada

componente y el sistema
Reuso No se busca Se busca
Asignación de tareas Flexible Fija
Comunicación Permanente Limitada
Clientes Parte del equipo Fuera del equipo
dades o expectativas del cliente o usuario.

12.5 Calidad de software
En la definición de la norma ISO-9000 de la
y madurez del proceso Organización Internacional para la Estanda-
rización (ISO—International Organization
for Standardization)16 la calidad de software
12.5.1 Calidad de software
es el grado (pobre, bueno o excelente) de
y modelos de madurez cómo un conjunto de características inhe-
del proceso rentes del software cumplen con los requi-
sitos del sistema.
La calidad de software tiene diferentes La calidad del software está directamente
significados para distintos grupos. Para el relacionada con el proceso de su desarrollo.
Instituto de Ingenieros Eléctricos y Electró- Se considera que un proceso bien conoci-
nicos (en inglés, IEEE—Institute of Electri- do y ampliamente utilizado, sustentado en
cal and Electronic Engineers)15 la calidad medición y predicción de eventos, permite
de software es el grado en que un sistema, controlar en buena medida la producción de
componente o proceso cumple con los software y, en consecuencia, producir soft-
requerimientos especificados y las necesi- ware de calidad17.
15
ANSI/IEEE Std. 729-1983, IEEE standard glossary of software engineering terminology, IEEE Inc.,
Nueva York, 1983.
16
ISO 9000-3:1997, http://www.iso.org
17
DeMarco, T., 1982, Controlling software projects: management, measurement and estimation, Pren-
tice Hall.
CAP. 12.indd 389 10/31/07 8:31:38 PM

390 CAPÍTULO 12
Los factores que más afectan la obtención la calidad de software más importantes en la
de un producto de calidad son: el cliente o actualidad.
usuario (participante primordial en el proce- En las siguientes secciones se describen
so de desarrollo del producto y responsable algunos de los modelos de madurez más im-
en definir los requisitos del producto final), portantes.
el desarrollador (responsable del proceso de
producción y el responsable de asegurar la ca-
lidad del producto), el proceso seguido para 12.5.2 Modelo de madurez
el desarrollo del producto final y el producto de capacidad (CMM)
(correspondiente al sistema desarrollado).
Estos factores tienen una estrecha y conti- El modelo más importante en la actualidad
nua correlación que afecta a la ingeniería del para la evaluación de la madurez de los proce-
producto, tanto como a la organización, la cual sos de desarrollo es el modelo de madurez
debe establecer estándares para los procesos de capacidad (en inglés, CMM—Capabili-
de desarrollo y evaluación, empleando medi- ty Maturity Model) del Instituto de Inge-
das bien establecidas que permitan mejoras niería de Software (en inglés, SEI—Software
continuas de los productos. La evaluación de Engineering Institute)20. CMM tiene como
los procesos evita especificaciones incomple- objetivo evaluar los procesos en sus niveles
tas o anómalas, la aplicación incorrecta de de madurez e identificar los niveles que una
metodologías, etc.18 Con el objetivo de eva- organización debe formar para establecer
luar la calidad de los procesos de software se una cultura de excelencia en la ingeniería de
define el concepto de modelo de madurez software. Los modelos de CMM se generan
del proceso de producción de software. Estos gracias a la experiencia colectiva de los pro-
modelos apoyan no sólo la mejora continua yectos más exitosos de software. Dentro de la
de los procesos de desarrollo de software familia de modelos CMM, se define el modelo
sino también la estandarización de la produc- para el área de software, SW-CMM.
ción en toda la organización. Cabe resaltar En particular, CMM es un marco de trabajo
que no se debe aplicar modelos de madurez, que especifica guías para organizaciones de
bajo el supuesto de mejorar su calidad, sin software que quieren incrementar su capaci-
antes establecer y definir completamente los dad de procesos, considerando los siguientes
procesos de desarrollo. Dada la importancia puntos: identificar fortalezas y debilidades en
de los procesos, existen diversas certificacio- la organización, ponderar los riesgos de se-
nes basadas en los modelos de madurez de leccionar entre diferentes contratos y moni-
proceso que evalúan que las empresas “digan torear los mismos, entender las actividades
lo que hacen”, “lo hagan como dicen” y “de- necesarias para planear e implementar los
muestren que lo que dicen así lo hacen”19. La procesos de software, y ayudar a definir e
razón adicional para estas certificaciones es implementar procesos de software en la or-
que los modelos a menudo requieren cam- ganización a través de una guía.
bios en la cultura de la organización y una El modelo CMM se evalúa según el área
fuerte inversión en recursos financieros, tec- de proceso clave (en inglés, KPA—Key Pro-
nológicos y humanos. cess Area), donde cada organización debe
En la tabla 12.7 se muestra una cronología incorporar procesos adecuados en cada una
de algunos de los estándares y modelos para de las áreas establecidas. Los procesos se eva-
18
Jones, C., 1994, Assessment and control of software risks, Prentice Hall.
19
Humphrey, W., 1995, A discipline for software egngineering, Addison Wesley.
20
http://www.sei.cmu.edu/cmm/
CAP. 12.indd 390 10/31/07 8:31:38 PM

Tabla 12.7 Cronología de los estándares y modelos de madurez más importantes para la calidad
de software.
Año Descripción
ISO 9000:2000
2000
SEI CMMI V1.02
1999 PEMM V1.0
ISO 15504 (SPICE) (lanzamiento al público como Reportes Técnicos “tipo 2”)
1998
TickIT V4.0
ISO 9000-3 (nuevo lanzamiento)

1997
SEI para las revisions de SW-CMM apoyando a CMM Integración (CMMI)
IEEE/EIA 12207 (corresponde a ISO 12207)

1996
TSP
ISO 12207 (lanzamiento inicial)
ISO 15504 (SPICE) (lanzamiento inicial)
1995
PSP
1994 ISO 9001 (nuevo lanzamiento)
1993 SEI SW-CMM V1.1
1992 TickIT V2.0
ImproveIT V1.0 (origen de TickIT)
1991 ISO 9000-3 (lanzamiento inicial)
SEI SW-CMM V1.0 (lanzamiento inicial)
1987 ISO 9001 (lanzamiento inicial)
lúan mediante distintos niveles de madurez, cado CMM, más allá de sólo el desarrollo de
como se muestra en la figura 12.8. software. Esto es algo similar al modelo de ca-
En la tabla 12.8 se describen con mayor lidad ISO-9000, que se aplica en múltiples
detalle los niveles de madurez. disciplinas, como se explica a continuación.
Según información del SEI, hasta abril de
2003 se contaba con cerca de 100 empresas
certificadas en el nivel 5 en todo el mundo21.
12.5.3 Organización
Existe una extensión del modelo básico Internacional para la
de madurez, la integración del mode- Estandarización (ISO)
lo de madurez de capacidad (en inglés,
CMMI—Capability Maturity Model Inte- Existen diversas normas de la Organización
gration) que tiene como objetivo integrar Internacional para la Estandarización (en
los diferentes dominios en los que se ha apli- inglés, ISO—International Organization for
21
http://www.sei.cmu.edu/sema/profile.html, http://www.sei.cmu.edu/sema/pdf/SW-CMM/2003apr.pdf
CAP. 12.indd 391 10/31/07 8:31:39 PM

392 CAPÍTULO 12
Procesos
de mejora Optimizado
continua
Procesos
predecibles Administrado
Procesos
estandarizados Definido
Procesos
disciplinados Repetible
Inicial
Figura 12.8 Los cinco niveles de madurez del proceso de software.
Tabla 12.8 Los cinco niveles del modelo de CMM.
Nivel Características Transición al siguiente nivel

1 Inicial Ad hoc, poca formalización, Iniciar una administración
herramientas aplicadas de rigurosa del proyecto y asegurar
manera informal al proceso. la calidad.
2 Repetible Se cuenta con un proceso Establecer un grupo y una
estable con un nivel repetible arquitectura de proceso
de control estadístico. de desarrollo de software.
Introducir métodos y tecnologías
de ingeniería de software.
3 Definido Se cuenta con una base Establecer un conjunto básico
para un progreso mayor y de administraciones del proceso
continuo. para identificar la calidad y costo
de los parámetros, y una base
de datos del proceso. Juntar y
mantener los datos del proceso.
Calcular la calidad relativa de
cada producto e informar a la
administración.
4 Administrado Mejoras sustanciales en la Apoyar la recopilación
calidad junto con medidas automática de datos del proceso.
comprensivas del proceso. Usar los datos para analizar y
modificar el proceso.
5 Optimizado Mejoras con base en mayor Continuar mejorando y
calidad y cantidad. optimizando el proceso.
CAP. 12.indd 392 10/31/07 8:31:39 PM

Standarization)22 que son aplicables al desa- primarios, adquisición, suministro, desarrollo,

rrollo de software, como se describe a con- mantenimiento y operación. Los cinco proce-
tinuación. sos se dividen en actividades, y las activida-
des en tareas, agregando requisitos para su
12.5.3.1 ISO-9000 ejecución. Se especifcan ocho procesos de
apoyo, documentación, administración de con-
figuración, aseguramiento de calidad, verifica-
ISO-900023 es una familia de normas interna-
ción, validación, auditoría y resolución de
cionales relacionadas con la administración
problemas. Además se consideran cuatro pro-
de la calidad en productos y servicios que
cesos organizacionales, administración, in-
especifica qué requisitos de calidad se deben
fraestructura, mejora y entrenamiento. Esta
cumplir, sin especificar cómo se deben cum-
norma busca que las organizaciones adapten
plir. Dentro de la familia ISO-9000 existen tres
estos procesos según el alcance de los proyec-
estándares, ISO-9001, ISO-9002 e ISO-9003,
tos particulares, eliminando actividades que
que se deben considerar dependiendo del al-
no se aplican.
cance de las actividades de la empresa. En el
caso del desarrollo de software, ISO-9001 es
el estándar más apropiado, ya que considera 12.5.4 Modelo de madurez
actividades de diseño y desarrollo. En cierta de ingeniería de
manera, ISO-9000 es comparable a CMMI por desempeño (PEMM)
ser una familia de estándares, mientras que
ISO-9001 es comparable a CMM. De esta ma-
El modelo de madurez de ingeniería de
nera, ISO-9001 es un estándar aplicable a la
desempeño (en inglés, PEMM—Performan-
administración de la calidad en el desarrollo
ce Engineering Maturity Model)25 es un mo-
de software. A diferencia de CMM, el modelo
delo para evaluar los niveles de integración,
ISO-9001 no incluye múltiples niveles de ca-
aplicación, ejecución y diseño, basado en el
lidad a los cuales se puede estar certificado.
modelo de madurez de capacidades de CMM.
La certificación es equivalente al nivel 3 de la
El objetivo de PEMM es evaluar la ejecución
escala de SEI.
de la ingeniería y proceso del modelo de ma-
durez. El modelo sirve tanto para evaluar una
12.5.3.2 ISO-12207 organización como para los propios procesos
de desarrollo tecnológicos particulares. Sirve
ISO-1220724 es una familia de normas interna- también para definir el criterio para escoger
cionales relacionadas con la administración un proveedor de software para los productos
de la calidad en los procesos del ciclo de vida críticos o semicríticos de la empresa.
del software. Esta norma está dirigida a lograr Al igual que CMM, PEMM cuenta con cin-
acuerdos o contratos entre los desarrolladores co niveles que determinan la mejora del com-
y clientes en situaciones en las que se requie- portamiento de ejecución y el decremento
re el desarrollo, mantenimiento u operación del riesgo de ejecución, como se muestra en
de un sistema de software. Es una norma de la figura 12.9.
alto nivel que deja sin especificar los detalles La evaluación de una compañía se hace
de cómo llevar a cabo las actividades y tareas midiendo los aspectos relacionados con la
de los procesos. Se describen cinco procesos organización, la definición de procesos de
22
http://www.iso.org
23
http://www.iso.org/iso/en/iso9000-14000/iso9000/iso9000index.html
24
http://www.12207.com/
25
Schmietendorf, A., y Scholz, A., 1999, “The Performance Engineering Maturity Model”, en Metrics
News, vol. 4, núm. 2.
CAP. 12.indd 393 10/31/07 8:31:41 PM

394 CAPÍTULO 12
Optimización de los procesos

Nivel 5 Mejora
de la F1
del
comporta- Éxito de integración y prueba
Nivel 4 miento de los procesos de la F1
de
ejecución Completa definición del proceso
Nivel 3
de la E.I. Decre-
Consideraciones de la E.I. mento
Nivel 2 del riesgo
en subprocesos
de ejecución
Nivel 1 Prácticas sin coordinación
Figura 12.9 Modelo general PEMM.
ingeniería, el proyecto de la dirección y la asegurar la calidad durante el desarrollo de

tecnología. Esto se logra mediante encuestas software. La guía de auditoría provee la liga
expertas del método de métricas sobre pre- para evaluar la conformación del sistema
guntas y metas (en inglés, GQM—Goal Ques- auditado con respecto al modelo TickIt, de
tion Metric), identificando y midiendo los manera que pueda ser expresada en función
objetivos con preguntas y respuestas cuan- de los criterios de la ISO 9001.
tificables (en la actualidad dichas respuestas Esta guía se compone de (i) un capítulo de
sólo pueden ser sí o no). conceptos de calidad, (ii) la norma ISO 9000-
3, (iii) una serie de guías para proveedores y
12.5.5 TickIt compradores, (iv) una guía para la auditoría
del sistema de calidad, (v) el proceso de cer-
tificación y (vi) guías complementarias.
TickIt,26 desarrollado por el Departamento
de Comercio e Industria del Reino Unido,
es primordialmente una guía con estrategias 12.5.6 Mejoramiento del
para lograr la certificación en la producción proceso de software
de software según los estándares ISO-9000. y determinación
Los objetivos principales de TickIt son, ade-
más de desarrollar un sistema de certifica-
de capacidad
ción aceptable en el mercado, estimular a los (ISO-15504/SPICE)
desarrolladores de software a implementar
sistemas de calidad, dando la dirección y El modelo de mejoramiento del proceso
guías necesarias para tal efecto. El objetivo de software y determinación de capaci-
de la certificación es demostrar que existen, y dad (en inglés, SPICE—Software Process Im-
son verificables, las prácticas necesarias para provement and Capability dEtermination)27
26
http://www.tickit.org/
27
Dorling, A., 1993, SPICE: “Software Process Improvement and Capability Determination”, Software
quality journal, 2, 209-224.
CAP. 12.indd 394 10/31/07 8:31:41 PM

es un modelo de evaluación o determinación su dinero y reducir el riesgo asociado a los

de la capacidad de los procesos, conocido grandes proyectos de software. Este modelo
también como la norma ISO-1550428. Es una busca mejorar la calidad del producto me-
familia de normas internacionales que tiene diante una evaluación comprobada, sistemá-
como objetivo el desarrollo de sistemas de tica y confiable del estado de los procesos
calidad en el software. Combina los enfoques de software de una organización, y usar los
de CMM con los de ISO-9000, incorporando resultados de estas evaluaciones como parte
al marco de referencia de ISO 9000 con la de programas coherentes de mejoramiento.
evaluación de capacidad y madurez de pro- La norma establece un denominador común
ceso de CMM. Su objetivo es lograr ganancias para una evaluación uniforme de los proce-
significativas en productividad y calidad, ade- sos de desarrollo. Ya que la tecnología evolu-
más de ayudar a los compradores de produc- ciona, ISO-15504 hace énfasis en la calidad,
tos de software a obtener un mejor valor por actualización, y vigencia del producto.
28
http://www.sei.cmu.edu/iso-15504/
Parte 1 Parte 9
Conceptos y guía Vocabulario
introductoria
Parte 7 Parte 8 Parte 6

Guía para uso en Guía para uso en Guía para calificación y
mejora del proceso determinar capacidad de entrenamiento de asesores
proceso de un proveedor
Parte 3 Parte 4
Realización de evaluación Guía para realización
de evaluación
Parte 5 Parte 2
Modelo de evaluación y Modelo de referencia de
guía de indicadores procesos y capacidades
Figura 12.10 Componentes del modelo ISO-15504.
CAP. 12.indd 395 10/31/07 8:31:43 PM

396 CAPÍTULO 12
ISO-15504 está conformado por nueve 3. Defina brevemente qué es TSPi.

documentos que permiten instrumentar 4. Explique brevemente cada uno de los
paso a paso la norma con su correspondien- procesos de TSPi.
te evaluación, como se muetra en la figura 5. Defina brevemente qué es XP.
12.10: parte 1 (conceptos y guía introducto- 6. Enumere y explique las variables que ma-
ria), parte 2 (modelo de referencia de proce- neja XP.
sos y capacidad), parte 3 (realización de eva- 7. Enumere y explique brevemente las prác-
luación), parte 4 (guía para realización de ticas de XP.
evaluación), parte 5 (modelo de evaluación y
guía de indicadores), parte 6 (guía para califi- Referencias
cación y entrenamiento de asesores), parte 7
(guía para uso en mejora del proceso), parte (Beck, 2004) Beck, K. Extreme programming
8 (guía para uso en determinar capacidad del explained: embrace change. Addison-Wesley,
proceso de un proveedor) y parte 9 (vocabu- 2004.
lario). (Humphrey, 2004a) Humphrey, W.S. Intro-
La arquitectura de evaluación de SPICE de- duction to the personal software process.
fine las siguientes prácticas y procesos. Al igual SEI Series in Software Engineering. Addison-
que CMM, las prácticas de SPICE son tratadas Wesley, 2004.
de acuerdo con niveles de capacidad: nivel 0 (Humphrey, 2004b) Humphrey, W.S. Intro-
(incompleto), nivel 1 (definido), nivel 2 (ad- duction to the team software process. SEI Se-
ministrado), nivel 3 (establecido), nivel 4 (pre- ries in Software Engineering. Addison-Wesley,
decible) y nivel 5 (optimizado). Los procesos 2004.
consideran cincos áreas de actividad: cliente- (Humphrey, 2004c) Humphrey, W.S. A disci-
proveedor, ingeniería, soporte, administración pline for software engineering. SEI Series in
y organización. Al igual que CMM, ISO-15504 Software Engineering. Addison-Wesley, 2004.
integra una serie de niveles de madurez por (Weitzenfeld, 2004) Weitzenfeld, A. Ingenie-
los que deben pasar sus procesos. ría de software orientada a objetos con
UML, Java e Internet, International Thomson
Preguntas de repaso Editores, 2004.
y ejercicios
1. Defina brevemente qué es PSP.

2. Enumere y explique brevemente cada
uno de los procesos de PSP.
CAP. 12.indd 396 10/31/07 8:31:45 PM

Ingenieria de Software PDF

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Ingenieria de Software PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria de Software PDF

Cargado por

Copyright:

Formatos disponibles

Capítulo 12

Ingeniería de software: el proceso

CAP. 12.indd 355 10/31/07 8:31:07 PM

Tabla 12.1 Probabilidad de cambios futuros en el software de acuerdo

Elemento Probabilidad de cambio

CAP. 12.indd 356 10/31/07 8:31:08 PM

las actividades definen los pasos necesarios 12.1.2.1 REQUISITOS

La tabla 12.2 muestra las actividades más

CAP. 12.indd 357 10/31/07 8:31:08 PM

Tabla 12.2 Actividades del desarrollo de software.

CAP. 12.indd 358 10/31/07 8:31:08 PM

CAP. 12.indd 359 10/31/07 8:31:09 PM

objetos, aún siguen siendo más populares 12.1.2.7 DOCUMENTACIÓN

CAP. 12.indd 360 10/31/07 8:31:09 PM

Los métodos deben permitir la genera-

CAP. 12.indd 361 10/31/07 8:31:10 PM

veles de abstracción. Una buena notación Los diagramas de transición de esta-

CAP. 12.indd 362 10/31/07 8:31:10 PM

A menudo se confunden algunos de los proceso y las metodologías a utilizarse. Dada

Una estrategia se define como un plan para 12.1.4.1 PROTOTIPOS

Modelo de proceso Método Notación

Método de codificación class Clase 1 extends ClaseX {

Figura 12.1 Contraste de las actividades, métodos y notaciones de desarrollo de software.

CAP. 12.indd 363 10/31/07 8:31:11 PM

sistema. El uso de prototipos es una estrate- tre un desarrollo rápido y un producto de

CAP. 12.indd 364 10/31/07 8:31:18 PM

no comenzar a desarrollar algo desde cero reutilización.4 La reutilización es valiosa cuan-

CAP. 12.indd 365 10/31/07 8:31:18 PM

CAP. 12.indd 366 10/31/07 8:31:18 PM

Figura 12.2 Secuencia de actividades para el modelo de cascada.

CAP. 12.indd 367 10/31/07 8:31:19 PM

Figura 12.3 Secuencia de versiones en el modelo evolutivo.

CAP. 12.indd 368 10/31/07 8:31:21 PM

versión 1 versión 2 versión 3

Figura 12.4 Secuencia de actividades para el modelo espiral.

CAP. 12.indd 369 10/31/07 8:31:22 PM

CAP. 12.indd 370 10/31/07 8:31:24 PM

CAP. 12.indd 371 10/31/07 8:31:25 PM

4. Con el uso de un conjunto de prácticas desarrollo de software. Es un proceso evolu-

PSP2 Plantillas de diseño

Figura 12.5 La evolución de PSP.

CAP. 12.indd 372 10/31/07 8:31:25 PM

CAP. 12.indd 373 10/31/07 8:31:28 PM

CAP. 12.indd 374 10/31/07 8:31:28 PM

información válida cuando haya que hacer En la actualidad ya no es posible seguir

CAP. 12.indd 375 10/31/07 8:31:29 PM

CAP. 12.indd 376 10/31/07 8:31:29 PM

Instrucciones sobre el producto a desarrollar

Figura 12.6 Estructura y flujo de TSPi.

CAP. 12.indd 377 10/31/07 8:31:30 PM

Tabla 12.3 Objetivos propuestos para el equipo y sus indicadores.

Objetivos Indicador 1 Indicador 2 Indicador 3

Producir un El porcentaje de La cantidad Al terminar el

Llevar a cabo El error en la El error en la El porcentaje de

Terminar el El total de días de

CAP. 12.indd 378 10/31/07 8:31:32 PM

Objetivos Indicador 1 Indicador 2 Indicador 3 Indicador 4

Ser un El promedio de El promedio de