Las Cuatro "P" en El Desarrollo de Software: Personas, Proyecto, Producto y Proceso E

EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE / CAPITULO 2
Capitulo 2
Las cuatro "P" en el desarrollo de
software: Personas, Proyecto, Producto
y Proceso
El resultado final de un proyecto software (Apndice C) es un producto que toma forma
durante su desarrollo gracias a la interenci!n de muc"os tipos de personas# $n proceso de
desarrollo de software gu%a los esfuer&os de las personas implicadas en el proyecto, a modo de
plantilla que e'plica los pasos necesarios para terminar el proyecto# (%picamente, el proceso
esta automati&ado por medio de una "erramienta o de un con)unto de ellas Vase la *igura +#,#
A lo largo de este li-ro utili&aremos los trminos personas, proyecto, producto, proceso
(Apndice C) y herramienta, que definimos a continuaci!n:
Personas. Los principales autores de un proyecto software son los arquitectos
desarrolladores, ingenieros de prue-a, y el personal de gesti!n que les da soporte, adem.s
de los usuarios clientes, y otros interesados# Las personas son realmente seres "umanos a
diferencia del trmino a-stracto trabajadores, que introduciremos mas adelante#
Proyecto# Elemento organi&atio a tras del cual se gestiona el desarrollo de software# El
resultado de un proyecto es una ersi!n de un producto#
Producto Artefactos que se crean durante la ida del proyecto como los modelos (Apndice
A), c!digo fuente, e)ecuta-les, y documentaci!n#
Proceso# $n proceso de ingenier%a de software es una definici!n del con)unto completo de
actiidades necesarias para transformar los requisitos de usuario en un producto $n proceso
es una plantilla para crear proyectos#
Herramientas: /oftware que se utili&a para automati&ar las actiidades definidas en el
proceso
Liliana Gonzlez Morales
2.1. Las personas son decisivas
0ay personas implicadas en el desarrollo de un producto software durante todo su ciclo de ida,
*inancian el producto, lo planifican, lo desarrollan, lo gestionan, lo prue-an, lo utili&an y se
-enefician de l# Por tanto, el proceso que gu%a este desarrollo de-e orientarse a las personas,
es decir, de-e funcionar -ien para las personas que lo utili&an#
2.1.1. Los procesos de desarrollo afectan a las personas
El modo en que se organi&a gestiona un proyecto software afecta profundamente a las
personas implicadas en l# Conceptos como la ia-ilidad, la gesti!n del riesgo, la organi&aci!n
de los equipos, la planificaci!n del proyecto y la facilidad de comprensi!n del proyecto tienen un
papel importante:
Viabilidad del proyecto# La mayor%a de la gente no disfruta tra-a)ando en proyectos que
parecen imposi-les 1nadie quiere "undirse con la nae# Como imos en el Capitulo ,, una
apro'imaci!n iteratia en el desarrollo permite )u&gar pronto la ia-ilidad del proyecto# Los
proyectos que no son ia-les pueden detenerse en una fase temprana, aliiando as% los
pro-lemas de moral#
Gestin del riesgo. 2e igual forma, cuando la gente siente que los riesgos no "an sido
anali&ados y reducidos, se sienten inc!modos# La e'ploraci!n de los riesgos significatios en
las primeras fases aten3a este pro-lema#
structura de los e!uipos# La gente tra-a)a de manera m.s efica& en grupos peque4os de
seis a oc"o miem-ros# $n proceso que produce tra-a)o significatio para grupos peque4os,
como el an.lisis de un determinado riesgo, el desarrollo de un su-sistema (Apndice A), o el
llear a ca-o una iteraci!n, proporciona esta oportunidad# $na -uena arquitectura, con
interfaces -ien definidas (Apndice A5 "ase tam-in el Capitulo 6) entre su-sistemas y
componentes (Apndice A5 "ase tam-in el Capitulo ,7) "ace posi-le una diisi!n del
esfuer&o de este tipo#
Plani#icacin del proyecto. Cuando la gente cree que la planificaci!n de un proyecto no es
realista, la moral se "unde 1la gente no quiere tra-a)ar a sa-iendas de que por muc"o que
lo intenten, nunca podr.n o-tener los resultados deseados# Las tcnicas que se utili&an en
las fases de inicio y de ela-oraci!n permiten a los desarrolladores tener una -uena noci!n
de cual de-er%a ser el resultado del proyecto1 es decir, de lo que de-er%a "acer la ersi!n
del producto# 2e-ido a que "ay una sensaci!n adecuada de lo que de-er%a "acer el
producto, puede crearse un plan de proyecto realista para el esfuer&o requerido# As% como
una definici!n del tiempo necesario para lograr los o-)etios, atenuando el pro-lema del
"nunca aca-aremos"#
$acilidad de comprensin del proyecto# A la gente le gusta sa-er lo que esta "aciendo5
quieren tener una comprensi!n glo-al# La descripci!n de la arquitectura proporciona una
isi!n general para cualquiera que se encuentre implicado en el proyecto#
%ensacin de cumplimiento# En un ciclo de ida iteratio, la gente reci-e retroalimentaci!n
frecuentemente, lo cual a su e&, "ace llegar a conclusiones# La retroalimentaci!n frecuente
y las conclusiones o-tenidas aceleran el ritmo de tra-a)o# $n ritmo de tra-a)o r.pido
com-inado con conclusiones frecuentes aumenta la sensaci!n de progreso de la gente#
2.1.2. Los papeles cambiaran
2e-ido a que son las personas las que e)ecutan las actiidades clae del desarrollo de software,
es necesario un proceso de desarrollo uniforme que este soportado por "erramientas y un
Lengua)e $nificado de 8odelado ("oy disponi-le en $8L) (Apndice C), para "acer que las
personas sean mas eficaces# Ese proceso permitir. a los desarrolladores construir un me)or
software en trminos de tiempo de salida al mercado, calidad y costes# Les permite especificar
los requisitos que me)or se a)usten a las necesidades de los usuarios# Les permite elegir una
arquitectura que permita construir los sistemas de forma econ!mica y puntual# $n -uen proceso
de software tiene otra enta)a: nos ayuda a construir sistemas m.s comple)os# /e4alamos en el
primer capitulo que a medida que el mundo real se "ace mas comple)o, los clientes requerir.n
sistemas software mas comple)os# Los procesos de negocio y su correspondiente software
tendr.n una ida mas larga# 2e-ido a que los cam-ios en el mundo real seguir.n sucediendo
durante estos ciclos de ida, los sistemas software tendr.n que dise4arse de un modo que les
permita crecer durante largos periodos de tiempo#
Para comprender y dar soporte a esos procesos de negocio m.s comple)os y para
implementarlos en software, los desarrolladores de-er.n tra-a)ar con muc"os otros
desarrolladores# Para tra-a)ar efica&mente en equipos cada e& m.s grandes, se necesita un
proceso que sira como gu%a# Esta gu%a tendr. como resultado desarrolladores "que tra-a)an de
manera m.s inteligente", es decir, que limitan sus esfuer&os indiiduales a aquello que
proporcione un alor al cliente# $n paso en esta direcci!n es el modelado de casos de uso, que
centra el esfuer&o en lo que el usuario necesita "acer# 9tro paso es una arquitectura que
permitir. a los sistemas el continuar su eoluci!n durante los a4os enideros# $n tercer paso es
la compra o reutili&aci!n de tanto software como sea posi-le# Esto, a su e&, puede lograrse solo
si "ay un modo consistente de integrar componentes reutili&a-les con elementos de nueo
desarrollo#
En los a4os enideros, la mayor%a de los inform.ticos an a empe&ar a tra-a)ar m.s
estrec"amente con sus o-)etios, y ser.n capaces de desarrollar software m.s comple)o gracias
a un proceso automati&ado y a los componentes reutili&a-les# Las personas ser.n decisias en
el desarrollo de software en el futuro que esperamos# En 3ltimo termino, el contar con las
personas adecuadas es lo que nos llea al 'ito# El pro-lema radica en "acerlas eficaces y
permitir que se dediquen a lo que solo los seres "umanos pueden "acer 1ser creatios,
encontrar nueas oportunidades, utili&ar la ra&!n, comunicarse con los clientes y usuarios, y
comprender r.pidamente un mundo cam-iante#

2.1.3. Convirtiendo "recursos' en trabajadores"
La gente llega a ocupar muc"os puestos diferentes en una organi&aci!n de desarrollo de
software# /u preparaci!n para esos puestos requiere una formaci!n y un entrenamiento preciso,
seguidos de una cuidadosa asignaci!n guiada por el an.lisis y por una adecuada superisi!n#
$na organi&aci!n se enfrenta con una tarea esencial siempre que "ace que una persona pase
de recurso :latente; a un puesto concreto de "tra-a)ador"#
0emos elegido la pala-ra trabajador (Apndice C) para denominar a los puestos a los cuales se
pueden asignar personas, y los cuales esas personas aceptan <=># $n tipo de trabajador es un
papel que un indiiduo puede desempe4ar en el desarrollo de software, como puede ser un
especificador de casos de uso, un arquitecto, un ingeniero de componentes, o un ingeniero de
prue-as de integraci!n# ?o utili&amos el trmino rol (en lugar de trabajador& principalmente por
dos motios: tiene un significado preciso y diferente en $8L, y el concepto de tra-a)ador tiene
que ser muy concreto: de-emos pensar en trminos de tra-a)adores indiiduales como los
puestos que asumen las personas# (am-in de-emos emplear el termino rol para "a-lar de los
papeles que cumple un tra-a)ador# $n tra-a)ador puede asumir roles en relaci!n con otros
tra-a)adores en diferentes flu)os de tra-a)o# Por e)emplo, el tra-a)ador ingeniero de componentes
puede participar en arios flu)os de tra-a)o y puede asumir un rol diferente en cada uno de ellos#
Cada tra-a)ador (un tra-a)ador concreto) es responsa-le de un con)unto complete de
actiidades, como las actiidades necesarias para el dise4o de un su-sistema# Para tra-a)ar
efica&mente, los tra-a)adores necesitan la informaci!n requerida para llear a ca-o sus
actiidades# ?ecesitan comprender cuales son sus roles en relaci!n con los de otros
tra-a)adores# Al mismo tiempo, si tienen que "acer su tra-a)o, las "erramientas que emplean
de-en ser las adecuadas# Las "erramientas no solo de-en ayudar a los tra-a)adores a llear a
ca-o sus propias actiidades, sino que tam-in de-en aislarles de la informaci!n que no les sea
releante# Para lograr estos o-)etios, el Proceso $nificado descri-e formalmente los puestos 1
es decir, los tra-a)adores1 que las personas pueden asumir en el proceso#
La *igura +#+ ilustra como una persona puede ser arios tra-a)adores dentro de un proyecto#
$n tra-a)ador tam-in puede representar a un con)unto de personas que tra-a)an )untas# Por
e)emplo, un tra-a)ador arquitecto puede ser un grupo de arquitectura#
Cada tra-a)ador tiene un con)unto de responsa-ilidades y llea a ca-o un con)unto de
actiidades en el desarrollo de software#
Al asignar los tra-a)adores a un proyecto, el )efe del proyecto de-e identificar las aptitudes de las
personas y casarlas con las aptitudes requeridas de los tra-a)adores# Esta no es una tarea f.cil,
en especial si es la primera e& que se utili&a el Proceso $nificado# /e de-en casar las
"a-ilidades de los recursos (las personas reales) con las competencias especificadas por los
diferentes tra-a)adores que el proyecto necesita# Las aptitudes requeridas por algunos
tra-a)adores pueden conseguirse mediante formaci!n, mientras que otras solo pueden o-tenerse
por medio de la e'periencia# Por e)emplo, las "a-ilidades necesarias para ser un especificador
de casos de uso pueden o-tenerse mediante formaci!n, pero las de un arquitecto "e adquieren
normalmente de la e'periencia#
$na persona puede ser muc"os tra-a)adores durante la ida de un proyecto# Por e)emplo, 8aria
puede comen&ar como especificador de casos de uso, y despus pasar a ser ingeniero de
componentes#
Al asignar recursos, el )efe de proyecto de-er%a minimi&ar el trasiego de artefactos de un recurso
a otro de manera que el flu)o del proceso sea tan continuo como se pueda# Por e)emplo, el
ingeniero de casos de uso del caso de uso /acar 2inero (Apndice A5 "ase tam-in el Capitulo
@) o-tendr. gran cantidad de conocimiento so-re las responsa-ilidades de la clase Cuenta
(Apndice A), as% que el o ella seria una elecci!n l!gica para ser el ingeniero de componentes de
la clase Cuenta# La alternatia seria la de formar a una nuea persona para "acer el tra-a)o, lo
cual es posi-le, pero seria menos eficiente por la perdida de informaci!n, por el riesgo de una
mala comprensi!n# etc#
2.2. Los proyectos construyen el producto
$n proyecto de desarrollo da como resultado una nuea ersi!n de un producto# El primer
proyecto dentro del ciclo de ida (es decir, el primer ciclo de desarrollo, llamado a eces en
ingles "greenAfield pro)ect", (proyecto inicial o inno"ador en castellano) desarrolla y o-tiene el
sistema o producto inicial# Vase <6> y <,7> para una presentaci!n mas completa de la gesti!n de
proyecto#
A tras de su ciclo de ida, un equipo de proyecto de-e preocuparse del cam-io, las
iteraciones, y el patr!n organi&atio dentro del cual se conduce el proyecto:
A 'na secuencia de cambio# Los proyectos de desarrollo de sistema o-tienen productos como
resultados, pero el camino "asta o-tenerlos es una serie de cam-ios# Este "ec"o de la ida
del proyecto de-e tenerse en mente mientras los tra-a)adores progresan a tras de las
fases e iteraciones# Cada ciclo, cada fase y cada iteraci!n modifican el sistema de ser una
cosa a otra distinta# El primer ciclo de desarrollo es un caso especial que conierte el sistema
de nada en algo# Cada ciclo llea a una "ersin, y m.s all. de una secuencia de ciclos, el
cam-io contin3a por generaciones#
A 'na serie de iteraciones: 2entro de cada fase de un ciclo, los tra-a)adores llean a ca-o las
actiidades de la fase a tras de una serie de iteraciones# Cada iteraci!n implementa un
con)unto de casos de uso relacionados o aten3a algunos riesgos# En una iteraci!n los
desarrolladores progresan a tras de una serie de flu)os de tra-a)o: requisitos, dise4o,
implementaci!n y prue-a# 2e-ido a que cada iteraci!n pasa por cada uno de esos flu)os de
tra-a)o, podemos pensar en una iteraci!n como si fuese un mini proyecto#
A 'n patrn organi(ati"o: $n proyecto implica a un equipo de personas asignadas para lograr
un resultado dentro de las restricciones del negocio, es decir, tiempo, coste y calidad# La
gente tra-a)a como diferentes tra-a)adores# La idea de "proceso" es proporcionar un patr!n
dentro del cual las personas en su papel de tra-a)adores e)ecutan un proyecto# Este patr!n o
plantilla indica los tipos de tra-a)adores que el proyecto necesita y los artefactos por los
cuales "ay que tra-a)ar# El proceso tam-in ofrece un mont!n de gu%as, "eur%sticas y
practicas de documentaci!n que ayudan a "acer su tra-a)o a las personas asignadas#
2.3. El producto es ms que cdi!o
En el conte'to del Proceso $nificado, el producto que se o-tiene es un sistema software# El
termino producto aqu% "ace referencia al sistema entero, y no solo al c!digo que se entrega#
2.3.1. "#u$ es un sistema soft%are&
B$n sistema software es el c!digo maquina, los e)ecuta-lesC Lo es, por supuesto, pero Bque es
el c!digo maquinaC DEs una descripci!nE $na descripci!n en forma -inaria que puede :ser le%da"
y "ser comprendida" por un computador#
B$n sistema software es el c!digo fuenteC Es decir, Bes una descripcin escrita por
programadores que puede leer y comprender un compiladorC /i, puede que esta sea la
respuesta#
Podemos seguir de esta forma "acindonos preguntas similares so-re el dise4o de un sistema
software en trminos de su-sistemas, clases, dia!ramas de interaccin (Apndice A),
dia!ramas de estados (Apndice A), y otros artefactos# B/on ellos el sistemaC /i, son parte de
el# BFu "ay de los requisitos, prue-as, enta, producci!n, instalaci!n y operaci!nC B/on el
sistemaC /i, tam-in son parte del sistema#
$n sistema es todos los artefactos que se necesitan para representarlo en una forma
comprensi-le por maquinas u "om-res, para las maquinas, los tra-a)adores y los interesados#
Las maquinas son las "erramientas, compiladores, u ordenadores destinatarios# Entre los
tra-a)adores tenemos directores, arquitectos, desarrolladores, ingenieros de prue-a, personal de
marGeting, administradores, y otros# Los interesados son los inersores, usuarios, comerciales,
)efes de proyecto, directores de l%nea de producto, personal de producci!n, agencias de
regulaci!n, etc#
En este li-ro, utili&aremos el trmino tra-a)ador para estas tres categor%as a la e&, a menos que
indiquemos e'pl%citamente otra cosa#
2.3.2. 'rtefactos
'rtefacto (Apndice C) es un trmino general para cualquier tipo de informaci!n creada,
producida, cam-iada o utili&ada por los tra-a)adores en el desarrollo del sistema# Algunos
e)emplos de artefactos son los diagramas $8L y su te'to asociado, los -ocetos de la interfa& de
usuario y los prototipos (Apndice C5 "ase tam-in los Cap%tulos @ y ,H), los componentes, los
planes de prue-a )"ase Capitulo ,,) y los procedimientos de prue-a *"ase Capitulo ,,)#
I.sicamente, "ay dos tipos de artefactos: artefactos de ingnienla y artefactos de gesti!n# Este
li-ro se centra en los artefactos de ingenier%a creados durante las distintas fases del proceso
(requisitos# An.lisis, dise4o, implementaci!n y prue-a)#
/in em-argo, el desarrollo de software tam-in requiere artefactos de gesti!n# Jarios de estos
artefactos tienen un tiempo de ida corto 1solo duran lo que dure la ida del proyecto# A este
con)unto pertenecen artefactos como el an.lisis del negocio, el plan de desarrollo (incluyendo el
plan de ersiones e iteraciones), un plan para la asignaci!n de personas concretas a
tra-a)adores (es decir, a diferentes puestos o responsa-ilidades en el proyecto), y el dise4o de
las actiidades de los tra-a)adores en el plan# Estos artefactos se descri-en mediante te'to o
diagramas, utili&ando cualquier tipo de isuali&aci!n requerida para especificar el compromiso
asumido por el equipo de desarrollo con los inersores# Los artefactos de gesti!n tam-in
incluyen las especificaciones del entorno de desarrollo1 el software de automati&aci!n del
proceso as% como la plataforma "ardware necesaria para los desarrolladores y necesaria como
repositorio de los artefactos de ingenier%a#
2.3.3. (n sistema posee una coleccin de modelos
El tipo de artefacto m.s interesante utili&ado en el Proceso $nificado es el modelo# Cada
tra-a)ador necesita una perspectia diferente del sistema )"ase la *igura +#H)# Cuando
dise4amos el Proceso $nificado, identificamos todos los tra-a)adores y cada una de las
perspectias que posi-lemente podr%an necesitar# Las perspectias recogidas de todos los
tra-a)adores se estructuran en unidades m.s grandes, es decir, modelos, de modo que un
tra-a)ador puede tomar una perspectia concreta del con)unto de modelos#
La construcci!n de un sistema es por tanto un proceso de construcci!n de modelos, utili&ando
distintos modelos para descri-ir todas las perspectias diferentes del sistema# La elecci!n de los
modelos para un sistema es una de las decisiones m.s importantes del equipo de desarrollo#
)i!ura +#=# El con)unto fundamental de modelos del Proceso $nificado
,
En el Capitulo , presentamos los modelos principales del Proceso $nificado (K"ase la *igura
+#=)#
El Proceso $nificado proporciona un con)unto de modelos cuidadosamente seleccionado con el
cual comen&ar# Este con)unto de modelos "ace claro el sistema para todos los tra-a)adores,
incluyendo a los clientes, usuarios y )efes de proyecto# *ue elegido para satisfacer las
necesidades de informaci!n de esos tra-a)adores#
2.3.*. "#u$ es un modelo&
$n modelo es una a-stracci!n del sistema, especificando el sistema modelado desde un cierto
punto de ista y en un determinado niel de a-stracci!n <,># $n punto de ista es, por e)emplo,
una ista de especificaci!n o una ista de dise4o del sistema#
Los modelos son a-stracciones del sistema que construyen los arquitectos y desarrolladores#
Por e)emplo, los tra-a)adores que modelan los requisitos funcionales piensan en el sistema con
los usuarios fuera de l y con los casos de uso en su interior# ?o se preocupan de como es el
sistema por dentro, solo se preocupan de lo que puede "acer para sus usuarios# Los
tra-a)adores que construyen el dise4o piensan en los elementos estructurales como su-sistemas
y clases5 piensan en trminos de como esos elementos funcionan en un conte'to dado y como
cola-oran para proporcionar los casos de uso# Comprenden como funcionan esos elementos
a-stractos, y poseen en sus mentes una interpretaci!n particular#
2.3.+. Cada modelo es una vista auto contenida del sistema
$n modelo es una a-stracci!n sem.nticamente cerrada del sistema# Es una ista auto contenida
en el sentido de que un usuario de un modelo no necesita para interpretarlo mas informaci!n (de
otros modelos)#
La idea de ser auto contenido significa que los desarrolladores trataron de que "u-iera una sola
interpretaci!n de lo que ocurrir. en el sistema cuando se dispare un eento descrito en el
modelo# Adem.s del sistema, un modelo de-e descri-ir las interacciones entre el sistema y los
que le rodean# Por tanto, aparte del sistema que se esta modelando, el modelo tam-in de-er%a
incluir elementos que descri-an partes releantes de su entorno, es decir, actores (Apndice A5
Jase tam-in el Capitulo @)#
1
En trminos de UML, estos paquetes representan entidades del negocio, business entities (o unidades
de trabajo, work units) en el Proeso Uni!iado, " no elementos del modelo para modelar un sistema
onreto# Vase tambin la e$pliai%n de la &ei%n '#1#
La mayor%a de los modelos de ingenier%a se definen mediante un su-con)unto de $8L
cuidadosamente seleccionado# Por e)emplo, el modelo de casos de uso comprende a los casos
de uso y los actores# Esto es -.sicamente lo que un lector necesita para comprenderlo# El
modelo de dise4o descri-e los su-sistemas y las clases del sistema y c!mo interact3an para
llear a ca-o los casos de uso# (anto el modelo de casos de uso como el modelo de dise4o
descri-en dos interpretaciones, diferentes pero mutuamente consistentes, de lo que el sistema
"ar. dado un con)unto de est%mulos e'ternos proenientes de los actores# /on diferentes de-ido
a que est.n pensados para ser utili&ados por diferentes tra-a)adores con diferentes tareas y
o-)etios# El modelo de casos de uso es una ista e'terna del sistema# el modelo de dise4o es
una ista interna# El modelo de casos de uso captura los usos del sistema, mientras que el
modelo de dise4o representa la construcci!n del sistema#
2.3.,. -entro de un modelo
$n modelo siempre identifica el sistema que esta modelando# Este elemento del sistema es por
tanto el contenedor de los dem.s elementos# El subsistema de ms alto nivel (Apndice I)
representa al sistema en construcci!n# En el modelo de casos de uso, el sistema contiene casos
de uso: en el modelo de dise4o, contiene su-sistemas, interfaces y clases# (am-in contiene
cola-oraciones (Apndice A) que identifican a todos los su-sistemas o clases participantes, y
puede contener mas cosas, como diagramas de estado o diagramas de interacci!n# En el
modelo de dise4o cada su-sistema puede ser contenedor de construcciones similares# Esto
implica que "ay una )erarqu%a de elementos en este modelo#
2.3... /elaciones entre modelos
$n sistema contiene todas las relaciones (Apndice A) y restricciones entre elementos incluidos
en diferentes modelos <,># Por tanto un sistema no es solo la colecci!n de sus modelos sino que
contiene tam-in las relaciones entre ellos#
Por e)emplo, cada caso de uso en el modelo de casos de uso tiene una relaci!n con una
cola-oraci!n en el modelo de an.lisis (y iceersa)# Esa relaci!n se llama en $8L dependencia
de tra&a, o simplemente tra&a (Apndice A)# Vase la *igura +#L, en la que se indican las tra&as
en un solo sentido#
(am-in "ay, por e)emplo, tra&as entre las cola-oraciones del modelo de dise4o y las
cola-oraciones en el modelo de an.lisis, y entre los componentes en el modelo de
implementaci!n y los su-sistemas en el modelo de dise4o# Por tanto, podemos conectar
elementos en un modelo a elementos en otro mediante tra&as#
El "ec"o de que los elementos en dos modelos estn conectados no cam-ia lo que "acen en los
modelos a los que pertenecen# Las relaciones de tra&a entre elementos en modelos distintos no

a4aden informaci!n sem.ntica para ayudar a comprender los propios modelos relacionados:
simplemente los conectan# La posi-ilidad de crear tra&as es muy importante en el desarrollo de
software por ra&ones como la comprensi-ilidad y la propagaci!n de los cam-ios#
2.*. El proceso diri!e los proyectos
La pala-ra proceso es un termino demasiado utili&ado# /e utili&a en muc"os conte'tos
diferentes, como cuando decimos proceso de negocio, proceso de desarrollo y proceso software,
con muc"os significados diferentes# En el conte'to del Proceso $nificado, el termino se refiere a
los procesos :de negocio" claes en una empresa de desarrollo de software, es decir, en una
organi&aci!n que desarrolla y da soporte al software (so-re el dise4o de una empresa de
desarrollo de software, "ase <+>)# En estos negocios tam-in e'isten otros procesos, como el
proceso de soporte, que interact3a con los usuarios de los productos, y un proceso de enta, que
comien&a con un pedido y entrega un producto# /in em-argo, en este li-ro nos centramos en el
proceso de desarrollo#
2.*.1. El proceso0 una plantilla
En el Proceso $nificado, proceso "ace referencia a un conte'to que sire como plantilla que
puede reutili&arse para crear instancias de ella# Es compara-le a una clase, que puede utili&arse
para crear o-)etos en el paradigma de la orientaci!n a o-)etos# +nstancia del proceso es un
sin!nimo de proyecto.
En este li-ro, un proceso de desarrollo de so#t,are es una definici!n del con)unto completo de
actiidades necesarias para conertir los requisitos de usuario en un con)unto consistente de
artefactos que conforman un producto software, y para conertir los cam-ios so-re esos
requisitos en un nueo con)unto consistente de artefactos#
La pala-ra re!uisita se utili&a con un sentido general, refirindose a "necesidades"# Al principio,
estas necesidades no necesariamente se entienden en su totalidad# Para capturar estos
requisitos, o necesidades, de una forma mas completa, tenemos que comprender con mayor
amplitud el negocio de los clientes y el entorno en que tra-a)an sus usuarios#
El resultado de alor a4adido del proceso es un con)unto consistente de artefactos, una l%nea
-ase que conforma una aplicaci!n o una familia de ellas que forman un producto software#
$n proceso es una definici!n de un con)unto de actiidades, no su e)ecuci!n#
Por ultimo, un proceso cu-re no solamente el primer ciclo de desarrollo (la primera ersi!n) sino
tam-in los ciclos posteriores m.s comunes# En ersiones posteriores, una instancia del proceso
toma cam-ios incrementales en los requisitos y produce cam-ios incrementales en el con)unto
de artefactos#
2.*.2. Las actividades relacionadas conforman flujos de trabajo
El modo en que descri-imos un proceso es en trminos de flu)os de tra-a)o, donde un flu)o de
tra-a)o es un con)unto de actiidades# BCual es el origen de esos flu)os de tra-a)oC ?o los
o-tenemos mediante diisi!n del proceso en un n3mero de su-procesos m.s peque4os que
interact3an# ?o utili&amos diagramas de flu)o tradicionales para descri-ir como descomponemos
el proceso en partes m.s peque4as# Estas no son formas eficaces de dise4ar la estructura de
flu)os de tra-a)o#
En cam-io, identificamos primero los distintos tipos de tra-a)adores que participan en el proceso#
2espus identificamos los artefactos que necesitamos crear durante el proceso para cada tipo
de tra-a)ador# Esta identificaci!n, por supuesto, no es algo que se pueda "acer en un a-rir y
cerrar de o)os# El Proceso $nificado se -asa en una amplia e'periencia para encontrar el
con)unto facti-le de artefactos y tra-a)adores# $na e& que lo "emos identificado, podemos
descri-ir como fluye el proceso a tras de los diferentes tra-a)adores, y como ellos crean,
producen y utili&an los artefactos de los dem.s# En la *igura +#M mostramos un dia!rama de
actividad (Apndice A) que descri-e el flu)o de tra-a)o en el modelado de casos de uso#
9-srense las "calles" (Apndice A) 1"ay una para cada tra-a)ador1, como fluye el tra-a)o
de un tra-a)ador a otro, y como los tra-a)adores de este flu)o llean a ca-o las actiidades
(representadas por ruedas dentadas)#
A partir de aqu% podemos identificar f.cilmente las actiidades que estos tra-a)adores de-en
reali&ar cuando se actian# Estas actiidades por tra-a)ador son tra-a)os significatios para una
persona que act3e como tra-a)ador# Adem.s, podemos er inmediatamente a partir de esas
descripciones si alg3n tra-a)ador concreto necesita participar m.s de una e& en el flu)o de
tra-a)o#
En otras pala-ras, descri-imos el proceso entero en partes llamadas flujos de trabajo
(Apndice C)# En trminos de $8L, un flu)o de tra-a)o es un estereotipo (Apndice A) de
cola-oraci!n, en el cual los tra-a)adores y los artefactos son los participantes# Por tanto, los
tra-a)adores y artefactos que participan en un flu)o de tra-a)o pueden participar (y lo suelen
"acer) tam-in en otros flu)os de tra-a)o# $saremos para los flu)os de tra-a)o la notaci!n de la
*igura +#@#
$n e)emplo de un flu)o de tra-a)o es el flu)o de tra-a)o de los requisitos# Nncluye a los siguientes
tra-a)adores: analista de sistemas, arquitecto, especificador de casos de uso y dise4ador de
interfa& de usuario# O los siguientes artefactos: modelo de casos de uso, caso de uso, y otros#
9tros e)emplos de tra-a)adores son: ingenieros de componentes e ingenieros de prue-as de
integraci!n# 9tros e)emplos de artefacto son las reali1aciones de caso de uso (Apndice I5
"ase tam-in los Cap%tulos P y 6), clases, su-sistemas e interfaces#
2.*.3. 2rocesos especiali1ados
D?ing3n proceso de desarrollo de software es de aplica-ilidad uniersalE Los procesos ar%an
porque tienen lugar en diferentes conte'tos, desarrollan diferentes tipos de sistemas y se a)ustan
a diferentes tipos de restricciones del negocio (pla&os, costes# calidad y fia-ilidad)# Por
consiguiente, un proceso de desarrollo de software del mundo real de-e ser adapta-le y
configura-le para cumplir con las necesidades reales de un proyecto yQo organi&aci!n concreta#
El Proceso $nificado se dise4o para poder ser adaptado (so-re el dise4o del proceso, "ase <M>)#
Es un proceso genrico, es decir, un marco de tra-a)o de proceso# Cada organi&aci!n quo utilice
el Proceso $nificado en alg3n momento lo especiali&ara para a)ustarlo a su situaci!n (es decir,
su tipo de aplicaci!n, su plataforma, etc#) (/o-re la especiali&aci!n de un proceso# "ase <P>)#
El Proceso $nificado puede especiali&arse para cumplir diferentes necesidades de aplicaci!n o
de organi&aci!n# Al mismo tiempo, es desea-le que el proceso sea, al menos, completamente
consistente dentro de una organi&aci!n# Esta consistencia permitir. el intercam-io de
componentes, una transici!n efica& de personas y directios entre proyectos, y el logro de
conseguir que las mtricas sean compara-les#
Los factores principales que influyen en como se diferenciara el proceso son:
A $actores organi(ati"os: La estructura organi&atia, la cultura de la empresa, la
organi&aci!n y la gesti!n del proyecto, las aptitudes y "a-ilidades disponi-les,
e'periencias preias y sistemas software e'istentes#
A $actores del dominio: El dominio de la aplicaci!n, procesos de negocio que se de-en
soportar, la comunidad de usuarios y las ofertas disponi-les de la competencia#
A $actores del ciclo de "ida: El tiempo de salida al mercado, el tiempo de ida esperado
del software, la tecnolog%a y la e'periencia de las personas en el desarrollo de
software, y las ersiones planificadas y futuras#
A $actores tcnicos: Lengua)e de programaci!n, "erramientas de desarrollo, -ase de
datos, marcos de tra-a)o y arquitecturas "est.ndar" su-yacentes, comunicaciones y
distri-uci!n#
Estas son las causas# BFue efecto tendr.nC Iien, puede decidir eliminar tra-a)adores y
artefactos del Proceso $nificado para que se a)uste me)or a organi&aciones de desarrollo menos
maduras# (am-in puede ocurrir que e'tienda el proceso con tra-a)adores o artefactos nueos
1aun no especificados1 ya que esas e'tensiones pueden "acer el proceso m.s eficiente para
su proyecto# (am-in puede cam-iar la forma en que piensa que un determinado artefacto
de-er%a descri-irse5 puede imponer una estructura diferente a su definici!n# ?uestra e'periencia
es que la gente en los primeros proyectos utili&a muc"o lo que sugiere el Proceso $nificado# A
medida que transcurre el tiempo y ganan m.s e'periencia, desarrollan sus propias e'tensiones
secundarias#
BFu tiene el dise4o del Proceso $nificado que le permite ser especiali&ado <M>C La respuesta es
simple pero no es f.cil de comprender al principio# El propio 9-)ectory esta dise4ado con lo que
son, en efecto, o-)etos: casos de uso, cola-oraciones y clases# Por supuesto, las clases aqu% no
son software sino o-)etos de negocio, es decir, tra-a)adores y artefactos# Pueden especiali&arse
o intercam-iarse con otros sin cam-iar el dise4o del proceso# En cap%tulos posteriores cuando
descri-amos los flu)os de tra-a)o, eremos como utili&amos o-)etos para descri-irlos# Esos
o-)etos son tra-a)adores y artefactos#
2.*.*. 3eritos del proceso
$n proceso com3n dentro a lo largo de los equipos de desarrollo proporciona muc"os
-eneficios:
A (odo el inundo en el equipo de desarrollo puede comprender lo que tiene que "acer para
desarrollar el producto#
A Los desarrolladores pueden comprender me)or lo que los otros est.n "aciendo 1en
momentos al principio o al final del proyecto, en proyectos similares en la misma
empresa, en diferentes u-icaciones geogr.ficas, e incluso en proyectos de otras
empresas#
A Los superisores y directores, incluso los que no entienden el c!digo, pueden
comprender lo que los desarrolladores est.n "aciendo gracias a los esquemas de la
arquitectura#
A Los desarrolladores, los superisores y los directores pueden cam-iar de proyecto o de
diisi!n sin tener que aprender un nueo proceso#
A La formaci!n puede estandari&arse dentro de la empresa, y puede o-tenerse de
compa4eros o de cursos -rees#
A El deenir del desarrollo del software es repeti-le, es decir, puede planificarse y
estimarse en coste con suficiente e'actitud como para cumplir las e'pectatias#
A pesar de estas enta)as de un proceso com3n, "ay quien insiste en que un proceso com3n no
resuele los "pro-lemas erdaderamente dif%ciles"# A esto simplemente contestamos: "por
supuesto que no"# Es la gente la que realmente resuele los pro-lemas# Pero un -uen proceso
ayuda a la gente a so-resalir como equipo# Comparmoslo con una organi&aci!n de operaciones
militares# La -atalla siempre se reduce a personas que "acen cosas, pero el resultado tam-in
se decide por la eficacia de la organi&aci!n#
2.+ Las 4erramientas son esenciales en el proceso
Las "erramientas soportan los procesos de desarrollo de software modernos# 0oy, es
impensa-le desarrollar software sin utili&ar un proceso soportado por "erramientas# El proceso y
las "erramientas ienen en el mismo paquete: las "erramientas son esenciales en el proceso <L>,
<@>#
2.+.1. Las 4erramientas influyen en el proceso
El proceso se e influido fuertemente por las "erramientas# Las "erramientas son -uenas para
automati&ar procesos repetitios, mantener las cosas estructuradas, gestionar grandes
cantidades
Con poco soporte por "erramientas, un proceso de-e sostenerse so-re gran cantidad de tra-a)o
manual y ser. por tanto menos formal# En la pr.ctica, la mayor%a del tra-a)o formal de-e
posponerse a las actiidades de implementaci!n# /in un soporte por "erramientas que
automatice la consistencia a lo largo del ciclo de ida, ser. dif%cil mantener actuali&ados los
modelos y la implementaci!n# El desarrollo iteratio e incremental ser. mas dif%cil aca-ara siendo
inconsistente, o requerir. una gran cantidad de tra-a)o manual para actuali&ar documentos y
mantener as% la consistencia Esto 3ltimo podr%a disminuir la productiidad del equipo de manera
significatia El equipo tendr%a que "acer manualmente todas las compro-aciones de
consistencia# Esto es muy dif%cil, si no imposi-le, por lo que tendr%amos muc"as fisuras en los
artefactos desarrollados# O "acerlo de ese modo requerir%a m.s tiempo de desarrollo#
Las "erramientas se desarrollan para automati&ar actiidades, de manera completa o parcial,
para incrementar la productiidad y la calidad, y para reducir el tiempo de desarrollo# A medida
que introducimos soporte por "erramientas, o-tenemos un proceso diferente, m.s formal#
Podemos incluir nueas actiidades que seria poco pr.ctico reali&ar sin "erramientas# Podemos
tra-a)ar de una manera mas precisa durante el ciclo de ida entero: podemos utili&ar un lengua)e
de modelado formal como $8L para asegurar que cada modelo es consistente internamente y
en relaci!n con otros modelos# Podemos utili&ar un modelo y a partir de el generar partes de otro
modelo (por e)emplo, del dise4o a la implementaci!n y iceersa)#
2.+.2. El proceso diri!e las 4erramientas
El proceso tanto si se define e'plicita como impl%citamente, especifica la funcionalidad de
las "erramientas, es decir, los casos de uso de las "erramientas# El "ec"o de que e'iste un
proceso es, por supuesto, el 3nico motio para necesitar "erramientas# Las "erramientas est.n
a"% para automati&ar tanto como sea posi-le del proceso#
La capacidad de automati&ar un proceso depende de que tengamos una isi!n clara de qu
casos de uso necesita cada usuario y que artefactos necesita mane)ar# $n proceso automati&ado
proporciona un medio eficiente de permitir el tra-a)o concurrente del con)unto completo de los
tra-a)adores, y proporciona una manera de compro-ar la consistencia de todos los artefactos#
Las "erramientas que implementan un proceso automati&ado de-en ser #-ciles de usar#
0acerlas muy mane)a-les significa que los desarrolladores de "erramientas de-en considerar
seriamente la forma en que se llea a ca-o el desarrollo de software# Por e)emplo, Bc!mo
afrontara un tra-a)ador una determinada tareaC BC!mo se dar. cuenta de c!mo le puede ayudar
la "erramientaC BFu tareas "ar. con frecuencia y por tanto, merecen la pena ser
automati&adasC BFu tareas son poco frecuentes y qui&. no merece la pena incluir en una
"erramientaC BComo puede la "erramienta guiar a un tra-a)ador para que ocupe su tiempo en
las tareas importantes que solo el puede "acer, ocup.ndose la "erramienta del restoC
Para responder a preguntas como estas, la "erramienta de-e ser sencilla de comprender y
mane)ar para los tra-a)adores# Es mas, para que mere&ca la pena el tiempo que se tarda en
aprenderla, de-e proporcionar un incremento de productiidad sustancial#
0ay ra&ones especiales para el o-)etio de la facilidad de uso# Los tra-a)adores de-en ser
capaces de pro-ar diferentes alternatias y de-er%an poder tantear los dise4os candidatos para
cada alternatia con facilidad# 2e-er%an ser capaces de elegir una apro'imaci!n y pro-arla# /i
resulta ser inia-le, de-er%an poder pasar f.cilmente de esa apro'imaci!n a otra# Las
"erramientas de-er%an permitir a los tra-a)adores reutili&ar tanto como sea posi-le: no de-er%an
comen&ar todo de nueo para cada alternatia pro-ada# En resumen, es esencial que las
"erramientas sean capaces tanto de soportar la automati&aci!n de actiidades repetitias como
de gestionar la informaci!n representada por la serie de modelos y artefactos, fomentando y
soportando las actiidades creatias que son el n3cleo fundamental del desarrollo#
2.+.3. El equilibrio entre el proceso y las 4erramientas
Por tanto, desarrollar un proceso sin pensar como se automati&ara es un mero e)ercicio
acadmico# 2esarrollar "erramientas sin sa-er qu proceso (marco de tra-a)o) an a soportar
puede ser una e'perimentaci!n infructuosa# 2e-e "a-er un equili-rio entre proceso y
"erramientas#
Por un lado, el proceso dirige el desarrollo de las "erramientas# Por otro lado, las "erramientas
dirigen el desarrollo del proceso# El desarrollo del proceso y su soporte por "erramientas de-e
tener lugar de manera simult.nea# En cada ersi!n del proceso de-e "a-er tam-in una ersi!n
de las "erramientas# En cada ersi!n de-e darse este equili-rio# Alcan&ar casi el ideal de este
equili-rio nos lleara arias iteraciones, y las sucesias iteraciones de-en guiarse por la
retroalimentaci!n de los usuarios entre ersiones#
Esta relaci!n procesoA"erramienta es otro pro-lema del ""ueo y la gallina"# BCual e'iste
primeroC En el caso de las "erramientas, muc"as de ellas en las 3ltimas dcadas "an llegado
antes de tiempo# El proceso aun no esta-a -ien desarrollado# En consecuencia, las "erramientas
no funciona-an tan -ien como se espera-a en los procesos, -astante mal planificados, en los
cuales los usuarios intentaron aplicarlas# 8uc"os de nosotros "a-%amos perdido la re en las
"erramientas# En otras pala-ras, el proceso de-e aprender de las "erramientas, y las
"erramientas de-en soportar un proceso -ien pensado#
Fueremos e'plicar este tema con la mayor claridad: el desarrollo con 'ito de una
automati&aci!n de un proceso ("erramientas) no puede "acerse sin el desarrollo paralelo de un
marco de tra-a)o de proceso en el cual ayan a funcionar las "erramientas# Este tema de-e
quedar claro para todo el mundo# /i aun al-erga una som-ra de duda, preg3ntese si seria
posi-le desarrollar un soporte inform.tico para los procesos de negocio en un -anco sin conocer
cuales son#
2.+.*. El modelado visual soporta (3L
0asta aqu% solo "emos dic"o que las "erramientas son importantes para llear a ca-o el
prop!sito del proceso#
Jamos a e'aminar un e)emplo significatio de una "erramienta en el conte'to del soporte del
Proceso $nificado# ?uestro e)emplo es la "erramienta de modelado para $8L# $8L es un
lengua)e isual# Como tal, se le suponen caracter%sticas comunes en muc"os productos de
di-u)o, como edici!n, dar formato, "acer &oom, imprimir, dar color y dise4o autom.tico# Adem.s
de esas caracter%sticas, $8L define reglas sint.cticas que especifican como com-inar elementos
del lengua)e# Por tanto, la "erramienta de-e ser capa& de garanti&ar que se cumplen esas reglas#
Esta posi-ilidad esta fuera del alcance de los productos de di-u)o "a-ituales, donde no se
comprue-an reglas#
2esafortunadamente, "acer cumplir reglas sint.cticas de este tipo sin e'cepci!n "ar%a que la
"erramienta fuese imposi-le de utili&ar# Por e)emplo, durante la edici!n de un modelo, el modelo
ser. con frecuencia sint.cticamente incorrecto, y la "erramienta de-e poder permitir
incorrecciones sint.cticas en este modo# Por e)emplo, de-e permitirse incluir mensa)es en un
dia!rama de secuencia (Apndice A5 ase tam-in el Capitulo 6) antes de que se "aya
definido ninguna operaci!n para la clase#
$8L incluye un cierto n3mero de reglas sem.nticas que tam-in requieren soporte# Estas
"erramientas pueden incluirse en la "erramienta de modelado, -ien como de cumplimiento
o-ligado inmediato o como rutinas -a)o demanda que recorren el modelo y comprue-an si "ay
errores comunes, o -uscan faltas de compleci!n sem.ntica o sint.ctica# En resumen, la
"erramienta de modelado de-e incorporar m.s que conocimiento de $8L: de-e permitir que los
desarrolladores tra-a)en creatiamente con $8L#
8ediante el uso de $8L como lengua)e est.ndar, el mercado e'perimentara un soporte por
"erramientas muc"o me)or que el que nunca "aya tenido ning3n lengua)e de modelado# Esta
oportunidad de un soporte me)or es de-ida en parte a la definici!n precisa de $8L# (am-in
puede atri-uirse al "ec"o de que $8L es "oy un est.ndar industrial ampliamente utili&ado# En
lugar de "a-er fa-ricantes de "erramientas compitiendo para dar soporte a muc"os lengua)es de
modelado diferentes, el )uego esta a"ora en encontrar al que me)or soporte $8L# Este nueo
)uego es me)or para los usuarios y clientes del software#
$8L es solo el lengua)e de modelado# ?o define un proceso que diga como utili&ar $8L para
desarrollar sistemas software# La "erramienta de modelado no tiene que o-ligar a utili&ar un
proceso, pero si el usuario utili&a uno, la "erramienta puede soportarlo#

2.+.+. Las 4erramientas dan soporte al ciclo de vida completo
0ay "erramientas que soportan todos los aspectos del ciclo de vida del soft%are (Apndice C):
R Gestin de re!uisitos: /e utili&a para almacenar, e'aminar, reisar, "acer el seguimiento y
naegar por los diferentes requisitos de un proyecto software# $n requisito de-er%a tener un
estado asociado, y la "erramienta de-er%a permitir "acer el seguimiento de un requisito desde
otros artefactos del ciclo de ida, como un caso de uso o un caso de prue-a ("ase el Capitulo
,,)#
.odelado "isual: /e utili&a para automati&ar el uso de $8L, es decir, para modelar y ensam-lar
una aplicaci!n isualmente# Con esta "erramienta conseguimos la integraci!n con entornos de
programaci!n y aseguramos que el modelo y la implementaci!n siempre son consistentes#
Herramientas de programacin: Proporciona una gama de "erramientas, incluyendo editores,
compiladores, depuradores, detectores de enAores y anali&adores de rendimiento#
/seguramiento de la calidad: /e utili&a para pro-ar aplicaciones y componentes, es decir, para
registrar y e)ecutar casos de prue-a que dirigen la prue-a de un NS$ y de las interfaces de un
componente# En un ciclo de ida iteratio, la prue-a de regresi!n es aun m.s esencial que en el
desarrollo conencional# La automati&aci!n de los casos de prue-a es esencial para conseguir
una productiidad alta# Adem.s, muc"as aplicaciones tam-in necesitan ser e'puestas a
prue-as de estrs y de carga# BC!mo responder. la arquitectura de la aplicaci!n cuando la
est.n utili&ando ,7#777 usuarios concurrentesC Fueremos sa-er la respuesta a esta pregunta
antes de entregarla al usuario n3mero ,7#777#
Adem.s de estas "erramientas orientadas a la funcionalidad, "ay otras "erramientas que
a-arcan todo el ciclo de ida# Estas "erramientas incluyen las de control de ersiones, gesti!n de
la configuraci!n, seguimiento de defectos, 2ocumentaci!n, gesti!n de proyecto y automati&aci!n
de procesos#
/eferencias
<,> 98S $nified 8odeling Language /pecification# 9-)ect 8anagement Sroup# *raming"am#
8A# ,66P# Nnternet: www#omg#org#
<+> Nar Taco-son# 8artin Sriss, and PatriG Tonsson# %o#t,are 0euse: /rchitecture. Process and
1rganisation #or 2usiness %uccess, Ueading# 8A: AddisonAVesley# ,66@#
<H> Vatts /# 0ump"rey, .anaging the %o#t3"are Process, Ueading, 8A: AddisonAVesley# ,6P6#
<=> Nar Taco-son, 8aria Ericsson# and Agneta Taco-son, 4he 1bject /d"antage: 2usiness
Process 0eengineering ,ith 1bject 4echnology, Ueading, 8A5 AddisonAVesley# ,66L#
<L> Nar Taco-son and /ten Taco-son, "Ieyond met"ods and CA/E: ("e software engineering
process wit" its integral support enironment"# 1bject .aga(ine. Tanuary ,66L#
<M> Nar Taco-son and /ten Taco-son, "2esigning a /oftware Engineering Process", 1bject
.aga(ine, Tune ,66L#
<@> Nar Taco-son and /ten Taco-son, "2esigning an integrated /EP/E", 1bject .aga(ine.
/eptem-er ,66L#
<P> Nar Taco-son and /ten Taco-son, "Iuilding your own met"odology -y speciali&ing a
met"odology frameworG"# 1bject .aga(ine, ?oem-erA2ecem-er ,66L#
<6> Srady Iooc"# 1bject %olutions: .anaging the 1bject51riented Project, Ueading, 8A:
AddisonAVesley, ,66M#
<,7> ValGer Uoyce, %o#t3"are Project .anagement: / 'ni#ied $rame,or6. Ueading, 8A: AdA
disonAVesley, ,66P#

Las Cuatro "P" en El Desarrollo de Software: Personas, Proyecto, Producto y Proceso E

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

Las Cuatro "P" en El Desarrollo de Software: Personas, Proyecto, Producto y Proceso E

Cargado por

Copyright:

Formatos disponibles

EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE / CAPITULO 2

También podría gustarte