Modelo Cmmi

www.monografias.
com
Modelo CMMI
Matas Fuentes Contreras mat_fuentes@hotmail.com
Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com
1
www.monografias.com
1. Resumen
2. Capability Maturity Model Integration (CMMI)
3. reas de Proeso de Ingeniera
!. "esarrollo de Re#uerimientos
$. Integrai%n de Produtos
&. 'alidai%n
(. Proeso de desarrollo de so)t*are de orden integrai%n
+. ,rte)atos
-. ,tores Partiipantes
1.. Proesos de ,poyo
11. Pruebas de /o)t*are
12. Re0isi%n de Pares
13. Re)erenias
1!. 1losario de 23rminos
M4"564 "5 C,6I"," CMMI 7 PR4C5/4 "5 "5/,RR4664 "5 /4F28,R5
"5 4R"59 I9251R,CI:9
2
www.monografias.com
Resumen
El siguiente trabajo consta de dos partes. La primera corresponde a una visin general del modelo C!,
comen"ando con una descripcin de los componentes principales del modelo para luego finali"ar con una
referencia a las #reas de proceso de la categor$a de !ngenier$a del modelo. La segunda parte es
simplemente dar a conocer el proceso de desarrollo de software de la empresa %&'E( !ntegracin
modelado en el lenguaje )L * +ue cumple los re+uerimientos del modelo C! en nivel ,.
3
www.monografias.com
Capability Maturity Model Integration (CMMI)
Modelos de Calidad
Para las compa-$as un producto o servicio es de calidad cuando satisface las necesidades * e.pectativas
del cliente otorgando a /ste seguridad sobre su uso, fiabilidad de sus funciones esperadas * confian"a en
un producto o servicio sin fallos * duradero seg0n tiempos establecidos * acordados. 'ebido a la amplitud
de temas +ue engloba el concepto de calidad se ha definido el concepto de Calidad 1otal, el cual se define
como un sistema de gestin organi"acional enfocado en la mejora continua del producto o servicio en todo
su ciclo de vida, involucrando mar2eting, compras, dise-o, fabricacin * entrega 34on567. La Calidad 1otal
contempla dos fases8
9. Control de calidad, basado en t/cnicas de inspeccin aplicadas a produccin.
:. ;seguramiento de la calidad, +ue persigue garanti"ar un nivel continuo de la calidad del Producto o
<ervicio proporcionado.
Los principios b#sicos de la Calidad 1otal son nueve 3=il5578
9. Consecucin de la plena satisfaccin de las necesidades * e.pectativas del cliente >interno *
e.terno?.
:. 'esarrollo de un proceso de mejora continua en todos los procesos.
,. 1otal compromiso de la 'ireccin.
@. Lidera"go activo de todo el e+uipo directivo.
A. Participacin de todos los miembros de la organi"acin
B. Comento del trabajo en e+uipo hacia una gestin de Calidad 1otal.
6. El proveedor debe estar involucrado en el sistema de Calidad 1otal de la empresa.
D. !dentificacin * 4estin de los Procesos Claves de la organi"acin.
E. 1oma de decisiones de gestin basada en datos * hechos objetivos.
En este conte.to, los modelos de calidad son sistemas basados en estudios e.perimentales de
mejores pr#cticas +ue a*udan a una organi"acin a implantar un <istema de aseguramiento de la calidad.
Los modelos de calidad se dividen en modelos de referencia, +ue indican cu#les son las pr#cticas pero no
cmo se consiguen, * los modelos de implantacin +ue se enfocan en cmo se consiguen a+uellas
pr#cticas 3=il557. ;un+ue e.iste gran variedad de ambos tipos de modelos se destacan por su eficacia
probada los modelos de referencia.
Capabilit* aturit* odel !ntegration, de ahora en adelante C!, es un modelo de referencia +ue
se diferencia de otros modelos por el hecho de estar basado en pr#cticas ajustables a cual+uier dominio de
produccin * poseer un enfo+ue global e integrado de la organi"acin, con el propsito de alcan"ar los
objetivos del negocio. 'e esa forma C! permite a empresas complejas compuestas por varias #reas de
negocio instaurar de una forma m#s sencilla un sistema de aseguramiento de la calidad.
Modelos de Madure; de Capaidades
Las dimensiones cr$ticas de una empresa son8 la gente, los procedimientos * m/todos, * las herramientas *
e+uipo. Los procesos son los encargados de unir tales dimensiones con el propsito de alcan"ar los
objetivos del negocio. El enfo+ue en los procesos a*uda a construir una plataforma de mejora continua, *a
+ue se est# de acuerdo en +ue la gente * la tecnolog$a cambian * son slo los procesos los +ue
transcienden en el tiempo, adapt#ndose a nuevas personas * tecnolog$as.
El <oftware Engineering !nstitute ><E!? de la Carnegie ellon )niversit* de los Estados )nidos,
creador del modelo C! * de la ma*or$a de sus predecesores, ha elaborado sus modelos bajo la premisa
+ue la calidad de un producto o servicio est# altamente influenciada por la calidad de los procesos +ue los
producen * los mantienen 3Chr5B7. Es por ello +ue la mejora continua de los procesos debiese ir
paulatinamente incrementando el nivel de capacidad * madure" de una organi"acin. Los procesos en
conjunto transitan desde procesos no definidos, es decir, procesos cu*a organi"acin cuenta con poca
capacidad * con inmadure" para reali"arlos, a procesos disciplinados cu*a organi"acin cuenta con la
capacidad * madure" suficiente para desarrollarlos con calidad probada. Luego una organi"acin es capa"
de definir su calidad total por medio del nivel de madure" de capacidades en +ue se encuentre de acuerdo a
sus procesos.
Modelos Previos
)no de los propsitos de C! fue unir en forma coherente varios modelos +ue eran utili"ados en conjunto
dentro de una organi"acin * +ue generaban repeticin de contenido provocando +ue el proceso de mejora
llevado a cabo en la organi"acin fuera m#s dif$cil * costoso. Estos modelos integrados por C!, +ue
ser#n descritos a continuacin * +ue se ilustran en la Cigura 9, eran modelos enfocados en el desarrollo de
sistemas software ><FGC?, en la ingenier$a de sistemas ><EC? * en el desarrollo de productos
integrados >!P'GC?.
4
www.monografias.com
Figura 2< Modelos Pre0ios a CMMI
CMM para /o)t*are
1ras su creacin en 9ED@ el <E! comen" la investigacin para desarrollar un marco de mejora * evaluacin
de la calidad de las empresas desarrolladoras de software +ue prestaban servicios al 'epartamento de
'efensa de los Estados )nidos. El resultado de la investigacin se denomin HCapabilit* aturit* odel for
<oftwareH ><FGC?, cu*a versin 9.5 se public en ;gosto de 9EE9 3Pal5B7. Posteriormente, como
resultado de la retroalimentacin generada por parte de la comunidad de software 3PauE,7, se desarrollaron
las versiones 9.9 publicada en 9EE, * :.5 la cual agregaba * modificaba una serie de elementos al vigente
C v9.9, principalmente +ue tienen relacin con alcan"ar la institucionali"acin en la organi"acin. Esta
versin se complet en 9EE6 * se denomin I<oftware C, =ersion :.5 >'raft C?J, pero nunca fue
publicada 3<E!E67. <FGC es un modelo de madure" de capacidades desarrollado para los procesos
relativos a la produccin * mantenimiento de sistemas software. 'e esta forma el <FGC puede
emplearse con dos finalidades 3Pal5B78
9. 4u$a para mejorar procesos relativos a la produccin * mantenimiento del software.
:. Criterio para determinar el nivel de madure" de una organi"acin +ue produce * mantiene software.
Las organi"aciones +ue usan <FGC! transitan por cinco niveles de madure" de capacidades
donde se pueden encontrar al evaluar sus procesos. Estos niveles son8 !nicial, donde no ha* procesosK
&epetible, en el cual los procesos relacionados a la gestin de pro*ectos * gestin de re+uerimientos son
manejados de alguna manera para su repeticin en pro*ectos distintosK definido, cuando los procesos est#n
totalmente definidos * disponibles para todos los miembros de una organi"acinK gestionado, donde se
pueden medir los procesos cuantitativamenteK * optimi"ado, en donde los procesos son mejorados
continuamente seg0n una serie de m/tricas definidas.
/5CM
<EC corresponde al esfuer"o conjunto de !(C%<E G !nternational Council on <*stem Engineering
>Consejo !nternacional sobre !ngenier$a de sistemas? L * EP!C 4roup L Enterprise Process !mprovement
Collaboration 4roup >4rupo de colaboracin de mejora de procesos en la empresa? L para integrar sus dos
modelos ><EC; * <EGC, respectivamente? en el denominado <*stem Engineering Capabilit* odel
><EC? o tambi/n llamado E!;M!< 6,9, +ue fue liberado en su versin 9.5 en 9EED.
<EC >odelo de Capacidades de !ngenier$a de <istemas? fue elaborado con el objetivo de proveer
una gu$a para efectuar, manejar * mejorar la ingenier$a de sistemas 3<ec56a7. El modelo describe un
conjunto m$nimo de actividades cr$ticas para reali"ar ingenier$a de sistemas o manejar tareas, tal como
derivar * asignar re+uerimientos o manejar riesgos. El modelo tambi/n captura las actividades gen/ricas
relacionadas a manejar o mejorar como una tarea espec$fica es reali"ada 3<ec56a7. Estas actividades son
especificadas en cinco niveles secuenciales e incrementales >niveles de capacidad?, los cuales proveen al
5
www.monografias.com
usuario un m/todo estructurado para lograr una mejora continua 3<ec56a7. Los niveles fueron obtenidos
sobre pr#cticas probadas e.perimentalmente * ellos son8 Nabilidad para desarrollar ingenier$a de sistemas,
%bteniendo control local, Compartiendo conocimiento a trav/s de la organi"acin, edida cuantitativa de lo
+ue se hace, * ejora usando las medidas cuantitativas * objetivos organi"acionales.
El primer predecesor de <EC descrito es <EC; ><*stems Engineering Capabilit* ;ssessment
odel?, traducido como odelo de Evaluacin de Capacidades de !ngenier$a de <istemas. Cue elaborado
por C;F4 L Capabilit* ;ssessment For2ing 4roup on <*stems Engineering >4rupo de trabajo de
evaluacin de capacidades en !ngenier$a de sistemas? L * aprobado por !(C%<E para ser liberado en 9EEB
3!ncEB7. <EC; junto son su m/todo de evaluacin fue utili"ado evaluar la capacidad de los procesos
relacionados a la ingenier$a de sistemas en una organi"acin * trataba de determinar #reas de potencial
mejora. El segundo predecesor es <EGC v9.9 L <*stem Engineering Capabilit* aturit* odel >odelo
de adure" de Capacidad para <istema de !ngenier$a? L +ue fue creado por el <E! en el a-o 9EEA *
describe los elementos esenciales +ue deben e.istir para +ue los procesos de ingenier$a de sistemas de
una organi"acin aseguren una buena ingenier$a de sistemas 3OatEA7. Punto con su m/todo de evaluacin
tienen el objetivo de mejorar * evaluar los procesos asociados a la ingenier$a de sistemas.
IP" CMM
!P' C L !ntegrated Product 'evelopment Capabilit* aturit* odel >odelo de madure" de capacidad
para el desarrollo de productos integrados? L fue el elaborado * liberado en 9EE6 por el <E!. El modelo
describe los elementos esenciales para el desarrollo de un producto integradoK una gu$a para el proceso de
mejora del desarrollo del producto integradoK * una metodolog$a de evaluacin del proceso de desarrollo del
producto integrado +ue es hecho por una organi"acin 3<ec56b7.
!P' C puede ser aplicado a cual+uier tipo disciplina * abarca casi todo el ciclo de vida de un
producto desde la seleccin de oportunidades de negocio hasta el retiro del producto del mercado,
marginando la etapa de desarrollo del plan estrat/gico 3<ec56b7. Cue dise-ado con la idea de eliminar la
duplicacin de actividades del <FGC * el <EGC, los cuales al ser aplicados en una organi"acin se
traslapaban entre s$, * consta de A niveles de madure" de capacidad semejantes en su descripcin a los
niveles de <FGC * <EGC 3<ec56b7.
6
www.monografias.com
CMMI Versin 1.2
Capabilit* aturit* odelQ !ntegration >C!? es un modelo de aseguramiento de la calidad +ue busca la
mejora continua de las organi"aciones mediante el an#lisis * reGdise-o de los procesos +ue sub*acen en la
organi"acin. Cue creado por el <E! ><oftware Engineering !nstitute? de la )niversidad de CarnegieGellon *
patrocinado por el inisterio de 'efensa de los Estados )nidos. Con el propsito de lograr la mejora de los
procesos, C! provee8
R )na forma de integrar los elementos funcionales de una organi"acin 3<E!56b7.
R )n conjunto de mejores pr#cticas basadas en casos de /.ito probado de organi"aciones
e.perimentadas en la mejora de procesos.
R ;*uda para identificar objetivos * prioridades para mejorar los procesos de la organi"acin 3<E!56b7,
dependiendo de las fortale"as * debilidades de la organi"acin +ue son obtenidas mediante un m/todo de
evaluacin.
R )n apo*o para +ue las empresas complejas en actividades productivas puedan coordinar sus
actividades en la mejora de los procesos.
R )n punto de referencia para evaluar los procesos actuales de la organi"acin 3<E!56b7.
C! v9.: corresponde a la tercera versin entregable del modelo C!, posterior a las versiones
9.5: >primera versin a-o :555? * 9.9 >a-o :55:? 3Chr5B7. Las versiones previas sirvieron como
retroalimentacin para +ue los propios usuarios, evaluadores * evaluados hicieran acotaciones sobre
posibles mejoras, las cuales fueron estudiadas, refinadas * algunas incluidas en la versin 9.:. C! v9.:
para desarrollo, +ue corresponde a una de tres constelaciones de pr#cticas, es una gu$a +ue a*uda a
manejar, medir * monitorear procesos 3<E!56a7 utili"ados en el desarrollo de productos * servicios de una
organi"acin, * contiene pr#cticas ligadas a la administracin de pro*ectos, administracin de procesos,
ingenier$a * soporte. Las otras dos constelaciones son C! para ;d+uisicin +ue provee una gu$a para
liderar la ad+uisicin informada * decisiva 3<E!56a7, * C! para <ervicios +ue proporciona una gu$a para
la entrega de servicios a clientes internos * e.ternos de la organi"acin 3<E!56a7. ;mbas constelaciones se
encuentran a0n en desarrollo.
Punto con C! se desarroll * public el m/todo de evaluacin I;ssessment &e+uirements for
C! >;&C?J 3<E!557 en el a-o :555, el cual define los re+uerimientos considerados esenciales para
reali"ar una evaluacin de C! en una organi"acin * I<tandard C! ;ppraisal ethod for Process
!mprovementJ, ><C;P!? 3<E!597, manual seguido por los evaluadores para medir el nivel de madure" de
una organi"acin. Estos dos documentos tambi/n se han actuali"ado como consecuencia de la
retroalimentacin de la comunidad involucrada en C!, generando la 0ltima versin 9.: de <C;P!
3<E!5Ba7 * ;&C 3<E!5Bb7 ambas publicadas el a-o :55B.
Representaiones
La representacin usada en C! entrega una gu$a para efectuar las actividades de mejora de los procesos
* es utili"ada en el m/todo de evaluacin. <eg0n el modelo se tienen dos formas para mejorar. )na forma
es mejorar un proceso espec$fico o un conjunto de ellos usando la &epresentacin Continua >Continuous
&epresentation? * la otra es la mejora de la organi"acin completa seg0n los procesos definidos * ocupados
usando la &epresentacin Escalonada o por Etapas ><taged &epresentation?. En la 1abla 9 se muestran los
niveles para estos dos tipos de representaciones.
&epresentacin Continua
La representacin continua se focali"a en la mejora de un proceso o un conjunto de ellos relacionado>s?
estrechamente a un #rea de proceso en +ue una organi"acin desea mejorar, por lo tanto una organi"acin
puede ser certificada para un #rea de proceso en cierto nivel de capacidad. E.isten seis niveles de
capacidad por donde transitan los procesos asociados a un #rea de proceso * cada nivel es construido
sobre el nivel anterior, es decir para +ue un proceso alcance un nivel de capacidad necesariamente debe
haber alcan"ado el nivel anterior.
Representacin Continua Representacin Escalonada
(ivel de Capacidad (ivel de adure"
(ivel 5 !ncompleto G
(ivel 9 &eali"ado !nicial
(ivel : anejado anejado
(ivel , 'efinido 'efinido
7
www.monografias.com
(ivel @ anejado cuantitativamente anejado cuantitativamente
(ivel A %ptimi"ando %ptimi"ando
2abla 1< 9i0eles de Representai%n ontinua y esalonada =C>r.&?.
Los niveles de capacidad son8
(ivel 5 G !ncompleto8 )n proceso es denominado Iproceso incompletoJ cuando una o m#s objetivos
espec$ficos del #rea de proceso no son satisfechos.
(ivel 9 L &eali"ado8 )n proceso es denominado Iproceso reali"adoJ cuando satisface todos los objetivos
espec$ficos del #rea de proceso. <oporta * permite el trabajo necesario para producir artefactos 3Chr5B7.
(ivel : L anejado8 )n proceso es denominado como Iproceso manejadoJ cuando tiene la infraestructura
base para apo*ar el proceso. El proceso es planeado * ejecutado en concordancia con la pol$tica, emplea
gente calificada los cuales tienen recursos adecuados para producir salidas controladasK involucra partes
interesadasK es monitoreado, controlado * revisadoK * es evaluado seg0n la descripcin del proceso 3Chr5B7.
(ivel , L 'efinido8 )n proceso denominado Iproceso definidoJ es adaptado desde el conjunto de procesos
est#ndares de la organi"acin de acuerdo a las gu$as de adaptacin de la organi"acin, * aporta artefactos,
medidas, * otra informacin de mejora a los activos organi"acionales 3Chr5B7.
(ivel @ L anejado cuantitativamente8 )n proceso denominado Iproceso manejado cuantitativamenteJ es
controlado usando t/cnicas estad$sticas * otras t/cnicas cuantitativas. %bjetivos cuantitativos para la calidad
* reali"acin del proceso son establecidos * usados como criterios para manejar el proceso 3Chr5B7.
(ivel A L %ptimi"acin8 )n proceso denominado Iproceso optimi"acin es mejorado basado en el
entendimiento de causas comunes de variacin del proceso. )n proceso en optimi"acin se focali"a en la
mejora continua del proceso reali"ado a trav/s de mejoras incrementales * usando innovacin tecnolgica
3Chr5B7.
Para m#s informacin consultar 3Sul5,7 * 3Chr5B7.
&epresentacin Escalonada
En la representacin escalonada o por etapas se ofrece un m/todo estructurado * sistem#tico de
mejoramiento de procesos, +ue implica mejorar por etapas o niveles. ;l alcan"ar un nivel, la organi"acin se
asegura de contar con una infraestructura robusta en t/rminos de procesos para optar a alcan"ar el nivel
siguiente. Por lo tanto es una organi"acin la +ue puede ser certificada bajo un nivel, en este caso llamado
nivel de madure". <eg0n esta representacin un nivel de madure" est# compuesto por #reas de procesos
>ver 1abla :? en donde los objetivos asociados a ese nivel deben ser cumplidos para +ue la organi"acin
pueda certificarse en a+uel nivel de madure". Na* cinco niveles de madure", los +ue son descritos a
continuacin8
(ivel 98 !niciado
En el nivel de madure" 9, la ma*or$a de los procesos son IadGhocJ * caticos. La organi"acin usualmente
no provee un ambiente estable para soportar los procesos. T.itos en estas organi"aciones se debe a la
competencia * esfuer"os heroicos de la gente dentro de la organi"acin * no al uso de procesos probados.
; pesar de este caos, organi"aciones pertenecientes al nivel de madure" 9 con frecuencia producen
productos * servicios +ue funcionanK sin embargo, ellos frecuentemente e.ceden sus presupuestos * no
cumplen sus planes. Estas organi"aciones son caracteri"adas por la tendencia a no cumplir sus
compromisos, al abandono de procesos durante tiempos de crisis, * a la incapacidad para repetir sus /.itos
3Chr5B7. El (ivel 9 est# caracteri"ado adem#s por la reali"acin de trabajo redundante, por personas +ue no
comparten sus m/todos de trabajo a lo largo de la organi"acin * cuando una persona clave en un #rea de
negocio espec$fica dentro de la organi"acin se marcha, su conocimiento se va con ella * se pierde para la
organi"acin. Es claro +ue el (ivel 9 es uno donde ninguna organi"acin +uiere estar * donde por lo general
la ma*or$a +ue no tiene sus procesos definidos se encuentra.
(ivel :8 anejado
En el nivel de madure" : se ordena el caos. En el nivel : las organi"aciones se enfocan en tareas cotidianas
referentes a la administracin. Cada pro*ecto de la organi"acin cuenta con una serie de procesos para
llevarlo a cabo, los cuales son planeados * ejecutados de acuerdo con pol$ticas establecidasK los pro*ectos
utili"an gente capacitada +uienes disponen de recursos para producir salidas controladasK se involucran a
las partes interesadasK son monitoreados, controlados * revisadosK * son evaluados seg0n la descripcin del
proceso. La disciplina del proceso reflejada por el nivel de madure" : a*uda a asegurar +ue e.isten
pr#cticas * los pro*ectos son reali"ados * manejados de acuerdo a los planes documentados. En el nivel de
madure" : el estado de los artefactos * la entrega de los servicios siguen planes definidos. ;cuerdos son
establecidos entre partes interesadas * son revisados cuando sea necesario 3Chr5B7. Los artefactos *
8
www.monografias.com
servicios son apropiadamente controlados. Estos adem#s satisfacen sus descripciones especificadas,
est#ndares, * procedimientos 3Chr5B7.
(ivel ,8 'efinido
En el nivel de madure" ,, procesos son caracteri"ados * entendidos de buena forma, * son descritos en
est#ndares, procedimientos, herramientas, * m/todos. El conjunto de procesos est#ndares de la
organi"acin, los cuales son la base para el nivel de madure" ,, es establecido * mejorado continuamente.
Estos procesos est#ndares son usados para establecer consistencia a trav/s de la organi"acin. Los
pro*ectos establecen sus procesos adaptando el conjunto de procesos est#ndares de la organi"acin de
acuerdo a gu$as de adaptacin 3Chr5B7.
)na diferencia importante entre el nivel : * , es el alcance de los est#ndares8 la descripcin de
procesos * los procedimientos. En el nivel de madure" :, los est#ndares pueden ser un poco diferentes en
cada instancia espec$fica del proceso >por ejemplo sobre un pro*ecto particular?. En el nivel de madure" ,,
los est#ndares, descripcin de procesos * procedimientos para un pro*ecto, son adaptados desde un
conjunto de procesos est#ndares de la organi"acin a un particular pro*ecto o unidad organi"acional * as$
son m#s consistentes 3Chr5B7. %tra distincin cr$tica es +ue el nivel de madure" ,, los procesos son
t$picamente descritos m#s rigurosamente +ue en el nivel :. )n proceso definido claramente plantea el
propsito, entradas, criterios de entrada, actividades, roles, medidas, pasos de verificacin, salidas *
criterios de salida. En el nivel de madure" ,, procesos son manejados m#s proactivamente entendiendo las
interrelaciones de las actividades * medidas detalladas del proceso, sus artefactos * sus servicios 3Chr5B7.
(ivel @8 anejado cuantitativamente
En el nivel de madure" @, la organi"acin * pro*ectos establecen objetivos cuantitativos para medir la
calidad * reali"acin de los procesos * los usa como criterios en el manejo de ellos. Los bjetivos
cuantitativos son definidos en base a las necesidades de clientes, usuarios finales, organi"acin, * actores
de los procesos. La calidad * reali"acin de procesos son entendidos en t/rminos estad$sticos * son
manejados durante todo el ciclo de vida del proceso 3Chr5B7. Para subprocesos seleccionados, se
recolectan * anali"an estad$sticamente medidas sobre la reali"acin de procesos. Estas m/tricas son
incorporadas en el repositorio de m/tricas de la organi"acin para apo*ar la toma de decisiones. Causas
especiales de variacin de procesos son identificadas *, cuando sea necesario, las fuentes de estas causas
son corregidas para prevenir futuras ocurrencias.
)na diferencia importante entre los niveles , * @ es la capacidad de prediccin de la reali"acin del
proceso. En el nivel de madure" @, la reali"acin de procesos es controlada usando t/cnicas estad$sticas *
cuantitativas, * el proceso es cuantitativamente predecible, en cambio en el nivel de madure" , la
reali"acin del proceso es slo predecible cualitativamente 3Chr5B7.
(ivel A8 %ptimi"ado
En el nivel de madure" A, una organi"acin mejora continuamente sus procesos bas#ndose en el
conocimiento de las causas comunes de variacin inherente en los procesos. El nivel de madure" A se
focali"a sobre la mejora continua de los procesos a trav/s de mejoras continuas, incrementales *
tecnolgicas. Los objetivos de mejora cuantitativa de procesos para la organi"acin son establecidos,
continuamente revisados para reflejar cambios en los objetivos del negocio * usados como criterio en la
mejora de procesos. Los efectos del empleo de las mejoras de procesos son medidos * evaluados contra
los objetivos de mejora cuantitativa del proceso.
)na diferencia importante entre el nivel de madure" @ * A es el enfo+ue de la variacin de los
procesos. En el nivel de madure" @, la organi"acin est# orientada a encontrar causas especiales de
variacin * proveer una prediccin estad$stica de los resultados. <in embargo, los resultados pueden ser
insuficientes para alcan"ar los objetivos establecidos. En el nivel de madure" A la organi"acin est#
enfocada en las causas comunes de variacin de procesos * modificar los procesos afectados para mejorar
la reali"acin de ellos * alcan"ar los objetivos cuantitativos de mejora de procesos 3Chr5B7.
'ado a +ue la organi"acin con +ue se trabajar# +uiere certificarse en forma organi"acional en (ivel
de madure" ,, en adelante slo se detallar# el modelo seg0n la &epresentacin Escalonada.
5strutura del CMMI
)n #rea de proceso es un conjunto de pr#cticas relacionadas +ue cuando son implementadas
colectivamente, satisfacen un conjunto objetivos considerados importantes para mejorar esa #rea de
proceso 3Chr5B7. Las #reas de proceso del modelo son ::. En la 1abla : se indica los nombres de las #reas
de proceso junto con su abreviacin. Cada una de ellas es implementada para alcan"ar el nivel de madure"
correspondiente * se agrupan de acuerdo a cuatro categor$as8 ;dministracin de Procesos, ;dministracin
de Pro*ectos, !ngenier$a * <oporte. Este agrupamiento es reali"ado para mostrar cmo se relaciona cada
#rea de proceso dentro de una categor$a. <in embargo, #reas de procesos de distintas categor$as pueden
9
www.monografias.com
encontrarse relacionadas, pero dado +ue en este documento se desarrollar#n slo #reas de procesos de
una misma categor$a >!ngenier$a? estas relaciones se desprecian.
rea de proeso Categora 9i0el de
Madure;
;n#lisis * &esolucin Causales >C;&? <oporte A
;n#lisis * &esolucin de 'ecisiones >';&? <oporte ,
;seguramiento de la Calidad de Procesos * Productos
>PPU;?
<oporte :
'efinicin de Procesos %rgani"acionales V!PP'>%P'
V!PP'?
9
4estin de
procesos
,
'esarrollo de &e+uerimientos >&'? !ngenier$a ,
Entrenamiento %rgani"acional >%1? 4estin de
procesos
,
;dministracin Cuantitativa de Pro*ectos >UP? 4estin de
pro*ectos
,
;dministracin de ;cuerdos con Proveedores ><;? !ngenier$a :
;dministracin de &e+uerimientos >&EU? 4estin de
pro*ectos
,
;dministracin de &iesgos >&<S? <oporte :
;dministracin de la Configuracin >C? 4estin de
pro*ectos
,
;dministracin !ntegral de Pro*ecto V !P' >!PV!PP'?
9
4estin de
pro*ectos
,
!nnovacin * 'espliegue %rgani"acional >%!'? 4estin de
procesos
A
!ntegracin de Producto >P!? !ngenier$a ,
edicin * ;n#lisis >;? <oporte :
onitoreo * Control de Pro*ecto >PC? 4estin de
pro*ectos
:
Planificacin de Pro*ecto >PP? 4estin de
pro*ectos
:
Procesos %rientados a la %rgani"acionales >%PC? 4estin de
procesos
,
&endimiento de Procesos %rgani"acionales >%PP? 4estin de
procesos
@
<olucin 1/cnica >1<? !ngenier$a ,
=alidacin >=;L? !ngenier$a ,
=erificacin >=E&? !ngenier$a ,
2abla 2< reas de Proeso
Componentes
;un+ue los componentes son independientes de la representacin elegida, se definir#n de acuerdo al
es+uema propuesto por la &epresentacin Escalonada +ue es la re+uerida por %&'E( !ntegracin.
Como se puede apreciar en Cigura , un #rea de proceso est# asociado a un nivel de madure"
dentro de C!K tiene adem#s un conjunto de objetivos espec$ficos * uno o varios objetivos gen/ricos
asociados, dependiendo del nivel de madure" al cual pertenece el #rea de procesoK los objetivos espec$ficos
* gen/ricos cuentan con un conjunto de pr#cticas espec$ficas * gen/ricas respectivamente. C! define
componentes re+ueridos, esperados e informativos. Los Componentes informativos, +ue se representadas
por elipses en la Cigura ,, no son referenciados ni descritos en este documento pues no son de inter/s para
1
Las reas de proceso que tienen +IPPD al lado derecho contienen metas y prcticas adicionales relacionadas a IPPD
(Integrated Product and Process Development) Desarrollo de Procesos y Productos integrados) Para ver ms in!ormaci"n acerca
de IPPD consultar #$hr%&'
10
www.monografias.com
%&'E( !ntegracin * slo son una a*uda propuesta por el modelo para entender de mejor manera las
componentes re+ueridas * esperadas.
Componentes Requeridas
<on las componentes +ue obligatoriamente deben ser satisfechas * visiblemente implementadas para poder
cumplir con un #rea de proceso. )na componente re+uerida es usada en las evaluaciones para a*udar a
determinar si un #rea de proceso es satisfecho 3Chr5B7. E.isten dos componentes re+ueridas8
G %bjetivo Espec$fico ><4?8 Es un enunciado +ue describe la 0nica caracter$stica +ue deber estar
presente para satisfacer el #rea de proceso a la cual pertenece 3Chr5B7. Las <4 son parte de un #rea de
proceso.
G %bjetivo 4en/rico >44?8 Es un enunciado +ue describe una caracter$stica +ue debe ser satisfechas
por un conjunto de #reas de proceso seg0n sea el caso. Las 44 tienen el objetivo de institucionali"ar los
procesos +ue implementan un #rea de proceso * son comunes a un conjunto de #reas de proceso 3Chr5B7.
Figura 3< Componentes del CMMI @ Representai%n 5salonada
Componentes esperadas
<on las componentes +ue pueden ser utili"adas para alcan"ar una componente re+uerida, es decir se
podr$an implementar estas componentes o modificaciones v#lidas de ellas con el objetivo de alcan"ar los
objetivos gen/ricos o espec$ficos. Las componentes esperadas pueden ser utili"adas como gu$as de mejora
* de evaluacin de procesos 3Chr5B7. E.isten dos tipos de componentes esperadas8
R Pr#cticas Espec$ficas ><P?8 )na pr#ctica espec$fica es un enunciado +ue describe una actividad +ue
es importante o esperada para alcan"ar un objetivo espec$fico de cierta #rea de proceso 3Chr5B7.
R Pr#cticas 4en/ricas >4P?8 )na pr#ctica gen/rica es un enunciado +ue describe una actividad +ue
es importante o esperada para alcan"ar un objetivo gen/rico 3Chr5B7.
"esripi%n de las reas de Proeso
; continuacin se har# una breve descripcin de cada #rea de proceso nombrada en 1abla :.
E.pl$citamente se nombra a productos pero tambi/n se puede aplicar las mismas definiciones a servicios.
11
www.monografias.com
G ;n#lisis * &esolucin Causales >C;&?8 !dentifica la causa de defectos u otros problemas. Luego de
ellos toma acciones correctivas para prevenir la ocurrencia de tales defectos o problemas en el futuro.
G ;n#lisis * &esolucin de 'ecisiones >';&?8 Proporciona un proceso estructurado de toma de
decisiones +ue asegura +ue las alternativas se comparan con criterios establecidos * objetivos para as$
tomar la mejor decisin posible.
G ;seguramiento de Calidad de Procesos * Productos >PPU;?8 Proporciona un conjunto de pr#cticas
con el objetivo de evaluar productos, servicios, procesos * sus artefactos relacionados.
G 'efinicin de Procesos %rgani"acionales >%P'?8 Establece * mantiene un conjunto de est#ndares
tanto en procesos organi"acionales como en ambientes de trabajo.
G 'esarrollo de &e+uerimientos >&'?8 &ecopila las necesidades del cliente para convertirlas en
re+uerimientos del producto esperado.
G Entrenamiento %rgani"acional >%1?8 Permite a la gente de la organi"acin obtener habilidades *
conocimientos necesarios para +ue el trabajo reali"ado por ellos sea efectivo * eficiente.
G ;dministracin Cuantitativa de Pro*ectos >UP?8 aneja m/tricas cuantitativas de los procesos con
el objetivo de alcan"ar los objetivos de calidad establecidos. ;dem#s mediante el an#lisis de estos datos
permite identificar oportunidades de mejora para los procesos.
G ;dministracin de ;cuerdos con Proveedores ><;?8 4estiona la ad+uisicin de productos de
proveedores con los cuales e.ista un acuerdo formal 3&ig5B7.
G ;dministracin de &e+uerimientos >&EU?8 4estiona los re+uerimientos del producto durante todo
el ciclo de vida de /l, identificando inconsistencias con los artefactos * planes de pro*ecto.
G ;dministracin de &iesgos >&<S?8 !dentifica riesgos del pro*ecto para evaluarlos, priori"arlos *
gestionarlos para prevenir su futura ocurrencia.
G ;dministracin de la Configuracin >C?8 Establece * mantiene la integridad * consistencia de los
artefactos 3&ig5B7.
G ;dministracin !ntegral de Pro*ecto >!P?8 ;dapta el conjunto de procesos est#ndares de la
organi"acin a procesos llevados a cabo para un pro*ecto en particular. ;dem#s maneja a las partes
interesadas involucradas en el pro*ecto.
G !nnovacin * 'espliegue %rgani"acional >%!'?8 <elecciona * despliega mejoras incrementales e
innovadoras +ue mejoran en forma medida los procesos de la organi"acin * tecnolog$as, para alcan"ar los
objetivos de calidad organi"acional * de reali"acin de procesos derivados de los objetivos de negocio de la
organi"acin 3Chr5B7.
G !ntegracin de Producto >P!?8 Ensambla las componentes del producto para producir un producto
m#s complejo manteniendo el cumplimiento de los re+uerimientos establecidos.
G edicin * ;n#lisis >;?8 Establece m/tricas con el objetivo de entregar resultados objetivos +ue
sirvan como base para tomar decisiones informadas * correctivas.
G onitoreo * Control de pro*ecto >PC?8 ;nali"a el pro*ecto con el objetivo de establecer un control
* evaluacin seg0n lo planes establecidos, tomando acciones correctivas cuando es necesario.
G Planificacin de Pro*ecto >PP?8 'esarrolla * mantiene planes del pro*ecto, compromisos ad+uiridos
por parte de los participantes del pro*ecto * gestiona las partes interesadas del pro*ecto.
G Procesos %rientados a la %rgani"acin >%PC?8 ;*uda a mantener un entendimiento de los procesos
por parte de los miembros de la organi"acin. 1ambi/n a*uda a identificar posibles mejoras de los
procesos, +ue son evaluadas * eventualmente implementadas.
G &endimiento de Procesos %rgani"acionales >%PP?8 'eriva objetivos cuantitativos de calidad *
ejecucin de lo procesos desde el conjunto de objetivos de negocio de la organi"acin 3&ig5B7.
G <olucin 1/cnica >1<?8 'ise-a, desarrollo e implementa soluciones para los re+uerimientos del
producto establecido.
G =alidacin >=;L?8 'emuestra +ue el producto, componentes del producto * artefactos corresponden
a lo esperado para su uso.
G =erificacin >=E&?8 'emuestra +ue el producto, componentes del producto * artefactos cumplen con
los re+uerimientos establecidos.
50aluaiones
)na evaluacin de C! corresponde al estudio * an#lisis de uno o m#s procesos reali"ado por un e+uipo
capacitado de profesionales, utili"ando un modelo de referencia de evaluacin como base para determinar,
a lo menos, fortale"as * debilidades dentro de una organi"acin. )n m/todo de evaluacin puede ser
aplicado para distintos propsitos, inclu*endo evaluaciones internas para mejora de los procesos,
evaluaciones de capacidad de seleccin de proveedores, evaluaciones de monitoreo de procesos, entre
otros enfo+ues.
12
www.monografias.com
El <E! ha publicado dos documentos gu$as +ue actualmente son utili"ados para reali"ar una
evaluacin de C!8
R ;ppraisal &e+uirements for C! >;&C? 3<E!5Bb7
R <tandard C! ;ppraisal ethod for Process !mprovement ><C;P!? 3<E!5Ba7.
;&C define un conjunto de re+uerimientos considerados esenciales para reali"ar una evaluacin
C! mientras +ue <C;P! es la referencia para la evaluacin. <e definen en ;&C tres clases de
evaluaciones8 clase ;, clase O * clase C. Las clases definen los re+uerimientos +ue debe cumplir una
evaluacin de cierta complejidad.
La clase ; de ;&C corresponde al m/todo de evaluacin +ue satisface el 955W de los re+uerimientos +ue
el documento define * es la 0nica evaluacin +ue se considera oficial para otorgar un nivel de certificacin
de C! en una organi"acin. <e denomina <C;P! clase ;. Este m/todo permite comprender de mejor
forma las capacidades de la organi"acin, identificando fortale"as * debilidades en sus procesos *
relacionar estas fortale"as * debilidades con el modelo de referencia C!. El m/todo permite adem#s
enfocar la organi"acin en el mejoramiento continuo de procesos * priori"ar los planes de mejoraK
finalmente permite evaluar con una nota el nivel de madure" en el cual se encuentra una organi"acin.
<C;P! clase ; consta de tres fases8 planificar * preparar la evaluacin, llevar a cabo la evaluacin *
reportar resultados de la evaluacin. 'entro de estas fases se ejecutan una serie de procesos. ;lgunos de
ellos inclu*en asignar responsabilidades, documentar el proceso, entrevistar a personas de la organi"acin,
agrupar los datos +ue se utili"ar#n, verificar * validar los procesos con el est#ndar, asignar notas o ratings,
crear reportes. <e espera contar con un e+uipo evaluador de cmo m$nimo re+uerido cuatro personas * un
m#.imo recomendado de nueve, inclu*endo al evaluador l$der certificado en C! por el <E!.
Las evaluacin clase O est# basada en la evaluacin clase ;. La evaluacin clase O a*uda a una
organi"acin a comprender, con relativamente alto grado de confian"a, el estado de los procesos relativos a
C!. 4eneralmente se ejecuta una evaluacin clase O cuando la organi"acin necesita autoGevaluar sus
procesos, con miras a una evaluacin clase ; para lograr el objetivo de la certificacin. Esta clase de
evaluacin debe ser ejecutada por dos personas, inclu*endo a un l$der de C! * re+uiere mucho menos
informacin +ue la evaluacin clase ;.
enos formal a0n, de menor duracin * con menos informacin re+uerida es la evaluacin clase C
+ue adem#s es reali"ada por slo una persona * tiene por objetivo evaluar pe+ue-os aspectos de la
organi"acin +ue +uieren apo*arse.
Relaiones entre las Areas de proeso
Na* cuatro grupos o categor$as de #reas de procesos +ue a*udan a guiar el proceso de mejora de la
organi"acin. Estos grupos est#n formados por #reas de proceso +ue se interrelacionan fuertemente *
tienen caracter$sticas comunes asociadas a objetivos de negocio tradicionales. Estas categor$as son las
indicadas en la 1abla : para cada #rea de proceso8 ;dministracin de procesos, ;dministracin de
pro*ectos, <oporte e !ngenier$a. ; Continuacin se describen brevemente las tres primeras categor$as,
para luego enfocarse en una descripcin detallada de la categor$a de !ngenier$a +ue es la de inter/s en este
documento.
;dministracin de procesos8 Contiene #reas de proceso relacionadas con definir, planear, desplegar,
implementar, monitorear, controlar, evaluar, medir * mejorar procesos 3Chr5B7.
;dministracin de pro*ectos8 Contiene #reas de proceso relacionadas con planeacin, monitoreo * control
de pro*ectos 3Chr5B7.
<oporte8 Contiene #reas de proceso relacionadas con actividades +ue apo*an el desarrollo * mantenimiento
del producto, * +ue est#n dirigidas a los procesos +ue son usados en el conte.to del desarrollo de procesos
pertenecientes a otras #reas 3Chr5B7.
!ngenier$a8 Cubre actividades relacionadas al desarrollo * mantenimiento +ue son compartidas por toda la
organi"acin. Cual+uier disciplina t/cnica involucrada en desarrollo de productos o servicios puede ocupar
esta categor$a para enfocar el proceso de mejora.
13
www.monografias.com
reas de Proeso de Ingeniera
Las #reas de proceso de !ngenier$a pueden integrar los procesos asociados con diferentes disciplinas de
ingenier$a cuando el producto final es consecuencia de ellas, dando as$ un soporte para estrategias
organi"acionales orientas en el producto. Las #reas de proceso pertenecientes a la categor$a de !ngenier$a
est#n indicadas en la 1abla : * ellas son8
R 'esarrollo de &e+uerimientos >&'?.
R 4estin de &e+uerimientos >&EU?.
R <olucin 1/cnica >1<?.
R !ntegracin de Productos >P!?.
R =erificacin >=E&?.
R =alidacin >=;L?.
La Cigura @ muestra las relaciones e.istentes entre las distintas #reas de proceso de la categor$a
se-alada.
Figura !< Relai%n entre reas de Proeso de Ingeniera
&' identifica las necesidades de un cliente * las transforma en Ire+uerimientos del productoJ.
Luego, estos son anali"ados para producir Ire+uerimientos de las componentes del productoJ,
Ire+uerimientos de interfa" de las componentesJ * un modelo conceptual de alto nivel de la solucin
3Chr5B7.
Los distintos re+uerimientos son suministrados a 1< +ue produce una ar+uitectura del producto, un
dise-o del producto en componentes * dise-o de las propias componentes. ;dem#s, 1< desarrolla cada
componente las cuales son suministradas a P! G donde las componentes son integradas verificando el
cumplimiento de las interfaces +ue fueron definidas. 1< utili"a a =E& para reali"ar la verificacin del dise-o.
&EU mantiene los re+uerimientos L describiendo actividades para obtener * controlar los cambios
L * la tra"abilidad de las necesidades del cliente al producto. Como &EU controla los cambios a los
re+uerimientos +ue pueden tener como fuente todas las otras #reas de proceso de !ngenier$a, esta #rea de
proceso es recursiva, din#mica * transversal a la categor$a.
14
www.monografias.com
El #rea de proceso =E& asegura +ue los artefactos satisfacen los re+uerimientos especificados.
=E& es un #rea incremental, pues comien"a con la verificacin de las componentes del producto para
terminar con la verificacin del producto completo.
=;L es un #rea de proceso incremental +ue valida el producto, las componentes del producto, los
artefactos intermedios * los procesos con respecto a las necesidades de los clientes. Los conflictos +ue son
descubiertos son usualmente resueltos en &' * 1<.
P! es el responsable de generar la mejor secuencia de integracin de componentes posible,
integrarlas * dar la aprobacin para la entrega del producto al cliente. P! usa pr#cticas espec$ficas de =E& *
=;L para implementar el proceso de integracin del producto.
; continuacin se detalla cada una de las #reas de proceso de la categor$a de !ngenier$a del modelo C!.
Esta informacin fue obtenida de la referencia del modelo, C! para 'esarrollo v9.: >ver 3Chr5B7?.
,dministrai%n de Re#uerimientos
El #rea de proceso ;dministracin de &e+uerimientos >&EU? se encarga de administrar todos los
re+uerimientos recibidos o generados por el pro*ecto, inclu*endo tanto los t/cnicos * noGt/cnicos como los
impuestos por la organi"acin. Cuando un pro*ecto recibe re+uerimientos, estos son revisados con un
proveedor para resolver inconsistencias * malentendidos antes de ser ingresados a los planes del pro*ecto.
El jefe de pro*ecto administra los cambios en los re+uerimientos a medida +ue el pro*ecto avan"a e
identifica inconsistencias +ue ocurren entre planes, productos de trabajo * re+uerimientos.
SG 18 ;dministrar &e+uerimientos
%bjetivo8 I6os re#uerimientos deben ser administrados y las inonsistenias on el plan de proyeto
y arte)atos son identi)iadasJ
Los pro*ectos deben mantener actuali"ados * aprobados el conjunto de re+uerimientos durante el
transcurso del pro*ecto para reali"ar lo siguiente8
G ;dministrar todos los cambios en los re+uerimientos.
G antener las relaciones entre los re+uerimientos, el plan del pro*ecto * los productos de trabajo.
G !dentificar las inconsistencias entre los re+uerimientos, el plan del pro*ecto * los productos de trabajo.
G 1omar las acciones correctivas.
<P 9 %btener una comprensin de los re+uerimientos
Pr#ctica8 IDesarrollar entendimiento comn con los responsables de entregar los requerimientos sobre el
significado y alcance de cada uno de ellosJ
; medida +ue el pro*ecto avan"a * los re+uerimientos son derivados, todas las actividades o
disciplinas recibir#n re+uerimientos. Para evitar un flujo descontrolado de re+uerimientos, se establecen
criterios para se-alar las fuentes oficiales de las cuales recibirlos. <e debe asegurar un entendimiento
compatible * compartido con los proveedores de re+uerimientos sobre el significado de cada uno de ellos.
El resultado de este an#lisis * di#logo es un conjunto de re+uerimientos consensuado.
<P : %btener compromiso con los re+uerimientos
Pr#ctica8 IObtener compromiso de requerimientos por parte del los participantes del proyectoJ
ientras la pr#ctica espec$fica anterior se ocupa de alcan"ar entendimiento con los proveedores de
re+uerimientos, esta pr#ctica espec$fica se refiere a los acuerdos * compromisos de +uienes tienen +ue
cumplir con las actividades necesarias para implementar los re+uerimientos, es decir, el e+uipo de pro*ecto.
; medida +ue los re+uerimientos evolucionan, esta pr#ctica espec$fica asegura +ue los participantes
del pro*ecto se comprometan con los re+uerimientos aprobados * con los cambios resultantes en planes,
actividades * artefactos.
<P , ;dministrar cambios a los re+uerimientos
Pr#ctica8 IManejar cambios de requerimientos a medida que estos se desarrollan durante el proyectoJ
'urante el pro*ecto, los re+uerimientos cambian por distintas ra"ones. ; medida +ue las
necesidades cambian * el trabajo avan"a, se obtienen re+uerimientos adicionales * puede ser necesario
modificar los e.istentes. Es esencial administrar estos re+uerimientos nuevos * modificados en forma
efectiva * eficiente. Para anali"ar el impacto de los cambios de forma efectiva, es necesario +ue la fuente de
cada re+uerimiento sea conocida * +ue el fundamento del cambio sea documentado. El Pefe de Pro*ecto
puede, sin embargo, verificar m/tricas apropiadas de volatilidad de re+uerimientos para ju"gar si se
re+uieren nuevos controles o modificar los actuales.
<P @ antener tra"abilidad bidireccional de los re+uerimientos
Pr#ctica8 IMantener trazabilidad bidireccional entre requerimientos y artefactosJ.
El propsito de esta <P es mantener la tra"abilidad bidireccional por cada nivel de descomposicin
del producto final.
Cuando los re+uerimientos son bien administrados, la tra"abilidad puede ser establecida desde la
fuente del re+uerimiento a su nivel m#s bajo, * desde el nivel m#s bajo volver a sus or$genes. 'icha
15
www.monografias.com
tra"abilidad bidireccional a*uda a determinar +ue todos los re+uerimientos fuente han sido completamente
abordados * +ue todos los re+uerimientos de m#s bajo nivel puedan ser relacionados con una fuente v#lida.
La tra"abilidad puede tambi/n cubrir relaciones hori"ontales, tales como interfaces * es particularmente
necesaria al evaluar el impacto de cambios a re+uerimientos en los planes, actividades * productos de
trabajo del pro*ecto.
<P A8 !dentificar inconsistencias entre artefactos del pro*ecto * los re+uerimientos
Pr#ctica8 IIdentificar inconsistencias entre los planes de proyecto y artefactos y los requerimientosJ
Esta pr#ctica espec$fica detecta las inconsistencias entre re+uerimientos * los planes de pro*ecto *
artefactos, e inicia las acciones correctivas para solucionarlas.
"esarrollo de Re#uerimientos
El #rea de proceso de 'esarrollo de &e+uerimientos >&'? se encarga de identificar las necesidades de los
clientes * traducirlas en re+uerimientos. El conjunto de re+uerimientos de un pro*ecto es anali"ado para
producir una solucin conceptual de alto nivel. Estos re+uerimientos se destinan a ciertos componentes del
producto final * son los +ue describen su rendimiento, caracter$sticas de dise-o, su verificacin, etc. para
comprensin * utili"acin futura por parte de desarrolladores.
/1 18 'esarrollar re+uerimientos del cliente
%bjetivo8 I9eesidades de las partes interesadasB eCpetaionesB restriionesB e inter)aes son
reogidas y traduidas en re#uerimientos del lienteJ.
Las necesidades de las partes interesadas >clientes, usuarios finales, proveedores, desarrolladores
* encargados de prueba? son la base para determinar los re+uerimientos del cliente. Estas necesidades,
e.pectativas, restricciones, interfaces, conceptos operacionales * conceptos de productos son anali"ados,
mati"ados, refinados * elaborados para traducirlos en un conjunto de re+uerimientos del cliente.
Crecuentemente estas son mal identificadas o contradictorias. Xa +ue las necesidades de actores,
e.pectativas, restricciones * limitaciones deben ser claramente identificadas * entendidas, un proceso
iterativo es usado durante todo el pro*ecto para conseguir este objetivo. Para facilitar la interaccin
re+uerida, un sustituto del usuario final o cliente es frecuentemente involucrado para representar las
necesidades de /ste * a*udar a resolver conflictos. &estricciones de ambiente, legales * otras debieran ser
consideradas cuando se crea o resuelve el conjunto de re+uerimientos del cliente.
<P 98 %btener necesidades
Pr#ctica8 IIdentificar y recoger las necesidades e!pectati"as restricciones e interfaces de las partes
interesadas para todas las fases del ciclo de "ida del productoJ.
La obtencin va m#s all# de recopilar re+uerimientos, *a +ue implica buscar activamente la
identificacin de re+uerimientos +ue no ha*an sido provistos e.pl$citamente por el cliente. Los
re+uerimientos adicionales debiesen abordar las diversas actividades del ciclo de vida del producto * su
impacto en /l.
<P :8 'esarrollar los re+uerimientos del cliente
Pr#ctica8 I#ransformar las necesidades de las partes interesadas e!pectati"as restricciones e interfaces en
requerimientos del clienteJ.
Las distintas entradas de las partes interesadas deben ser consolidadas, la informacin faltante
debe ser obtenida * los conflictos deben ser resueltos al documentar el conjunto de re+uerimientos
reconocidos por el cliente. Los re+uerimientos del cliente pueden incluir necesidades, e.pectativas *
restricciones con respecto a verificacin * validacin.
En algunas situaciones, el cliente provee un conjunto de re+uerimientos al pro*ecto, o los
re+uerimientos e.isten como una salida de actividades anteriores del pro*ecto. En estos casos, los
re+uerimientos del cliente podr$an contradecir las necesidades, e.pectativas, restricciones e interfaces de
las partes interesadas * deber#n ser transformadas en un conjunto de re+uerimientos reconocidos por el
cliente, luego de resolver los conflictos adecuadamente.
Las partes interesadas +ue forman parte de todas las etapas del ciclo de vida del producto debieran
incluir funciones t/cnicas * de negocios. 'e esta manera, los conceptos de todos los procesos relacionados
con el ciclo de vida del producto son considerados junto con el concepto del producto.
/1 28 'esarrollar re+uerimientos de productos
%bjetivo8 IRe#uerimientos del liente son re)inadas y elaboradas para desarrollar re#uerimientos del
produto y omponentes del produtoJ.
Los re+uerimientos del cliente son anali"ados en conjunto con el desarrollo del concepto
operacional para obtener un conjunto de re+uerimientos m#s detallado * preciso * se le llama
re+uerimientos del producto * de componentes del producto. Los re+uerimientos del producto * de
componentes del producto abordan las necesidades asociadas con cada fase del ciclo de vida del producto.
16
www.monografias.com
'e los re+uerimientos obtenidos surgen de las restricciones, consideraciones de temas no e.pl$citamente
indicados en la l$nea base de re+uerimientos del cliente * factores introducidos por la ar+uitectura
seleccionada, el dise-o * las consideraciones espec$ficas de negocio del desarrollador. Los re+uerimientos
son revisados con nivel anterior de conjunto de re+uerimientos * ar+uitectura funcional, * el concepto
preferido del producto es refinado.
Los re+uerimientos son asociados a funciones * componentes del producto inclu*endo objetos,
personas * procesos. La tra"abilidad de los re+uerimientos a funciones, objetos, pruebas, problemas u otras
entidades es documentada. Los re+uerimientos asociados * las funciones son la base de la s$ntesis de la
solucin t/cnica. ; medida +ue los componentes internos son desarrollados se definen interfaces
adicionales * establecen los re+uerimientos de interfa".
<P 98 Establecer re+uerimientos del producto * de componentes del producto
Pr#ctica8 IEstablecer y mantener requerimientos del producto y componentes del producto los cuales son
basados en los requerimientos del clienteJ.
Los re+uerimientos del cliente pueden ser e.presados en los t/rminos del cliente * pueden ser
descripciones no t/cnicas. Los re+uerimientos del producto son la e.presin de estos re+uerimientos en
t/rminos t/cnicos +ue pueden ser usados para decisiones de dise-o.
&e+uerimientos del producto * de componentes del producto abordan la satisfaccin del cliente, los
negocios, los objetivos del pro*ecto * los atributos asociados, tales como eficacia * econom$a. 1ambi/n
abordan el costo * rendimiento de otras fases del ciclo de vida.
La modificacin de re+uerimientos debido a la aprobacin de cambios en estos es cubierta por
funciones de mantenimiento de esta #rea de procesoK mientras +ue la administracin de cambios de
re+uerimientos es cubierta por el #rea de proceso de ;dministracin de &e+uerimientos.
<P :8 'estinar re+uerimientos de componentes del producto
Pr#ctica8 IDestinar los requerimientos por cada componente del productoJ.
Los re+uerimientos de componentes del producto inclu*en el destino de /stos al comportamiento del
producto final, el dise-o de restricciones * el ajuste, formacin * creacin de funciones para satisfacer los
re+uerimientos * facilitar la produccin. En los casos donde los re+uerimientos de alto nivel especifi+uen
comportamiento +ue ser# responsabilidad de dos o m#s componentes del producto, este comportamiento
debe ser dividido para ser asociado a cada componente de producto como re+uerimiento derivado.
<P ,8 !dentificar re+uerimientos de interfa"
Pr#ctica8 IIdentificar requerimientos de interfazJ.
!nterfaces entre funciones >o entre objetos? son identificadas. !nterfaces funcionales pueden
impulsar el desarrollo de soluciones alternativas. Los re+uerimientos de interfaces entre productos o entre
componentes del producto identificados en la ar+uitectura del producto son definidos. Estos son controlados
como parte de la integracin del producto * componentes del producto * son parte integral de la definicin
de la ar+uitectura.
/1 38 ;nali"ar * validar re+uerimientos
%bjetivo8 I6os re#uerimientos son anali;ados y 0alidadosB y una de)inii%n de la )unionalidad
re#uerida es desarrolladaJ.
Las pr#cticas espec$ficas de este objetivo espec$fico apo*an el desarrollo de los re+uerimientos en
los objetivos espec$ficos 9 * :. Las pr#cticas espec$ficas asociadas con este objetivo cubren el an#lisis *
validacin de re+uerimientos con respecto al ambiente previsto por el usuario.
Los an#lisis son desarrollados para determinar +ue impacto tendr# el ambiente operacional previsto
en la habilidad para satisfacer las necesidades de las partes interesadas, sus e.pectativas, restricciones e
interfaces. ;spectos como viabilidad, necesidades de misin corporativa, restricciones de costos, tama-o de
potencial de mercado * estrategia de ad+uisicin deben ser tomados en consideracin dependiendo del
conte.to del producto.
Los objetivos de los an#lisis son determinar re+uerimientos candidatos para conceptos de productos
+ue van a satisfacer las necesidades, e.pectativas * restricciones de las partes interesadas * luego traducir
estos conceptos a re+uerimientos. En paralelo con esta actividad, los par#metros +ue ser#n usados para
evaluar la eficacia del producto son determinados basados en la informacin del cliente * el concepto
preliminar del producto.
Los re+uerimientos son validados para aumentar la probabilidad de +ue el producto resultante
funcionar# como se espera en el ambiente de produccin.
<P 98 Establecer conceptos operacionales * escenarios
Pr#ctica8 IEstablecer y mantener conceptos operacionales y escenarios asociadosJ.
)n escenario es t$picamente una secuencia de eventos +ue pueden ocurrir en la utili"acin del
producto, el cual es usado para hacer e.plicitas algunas de las necesidades de las partes interesadas. En
17
www.monografias.com
contraste, un concepto operacional para un producto usualmente depende de la solucin de dise-o * del
escenario. Xa +ue las soluciones alternativas no son usualmente definidas cuando se definen los conceptos
operacionales iniciales, las soluciones conceptuales son desarrolladas para usarse cuando se anali"an los
re+uerimientos. Los conceptos operacionales son refinados a medida +ue las decisiones sobre la solucin
son tomadas * re+uerimientos de m#s bajo nivel detallados son desarrollados.
;s$ como una decisin de dise-o para un producto puede convertirse en un re+uerimiento para
componentes del producto, el concepto operacional puede convertirse en escenarios >re+uerimientos? para
componentes del producto. Los conceptos operacionales * escenarios son desarrollados para facilitar la
seleccin de soluciones para componentes del producto +ue podr#n, cuando se implementen, satisfacer el
uso esperado del producto. Los conceptos operacionales * escenarios documentan la interaccin de los
componentes del producto con el ambiente, los usuarios * otros componentes del producto independiente
de la disciplina de ingenier$a. Los escenarios pueden incluir secuencias operacionales, si /stas son una
e.presin de los re+uerimientos del cliente m#s +ue conceptos operacionales.
<P :8 Establecer una definicin de la funcionalidad re+uerida
Pr#ctica8 IEstablecer y mantener una definicin de la funcionalidad requeridaJ.
La definicin de funcionalidad, tambi/n referida como Han#lisis funcionalH, es la descripcin de lo
+ue se pretende +ue el producto haga. La definicin de funcionalidad puede incluir acciones, secuencias,
entradas, salidas u otra informacin +ue d/ a conocer la manera en la cual el producto va a ser usado.
El an#lisis funcional no es lo mismo +ue el an#lisis estructurado en 'esarrollo de <oftware * no
supone un dise-o de software orientado a la funcionalidad. En el dise-o de software orientado al objeto, se
relaciona con definir los denominados HserviciosH o Im/todosJ. La definicin de funciones, sus agrupaciones
lgicas * sus asociaciones con re+uerimientos es referido como ar+uitectura funcional.
<P ,8 ;nali"ar re+uerimientos
Pr#ctica8 I$nalizar requerimientos para asegurar que ellos son necesarios y suficientesJ.
; la lu" del concepto operacional * los escenarios, los re+uerimientos para un nivel de la jerar+u$a
del producto son anali"ados para determinar si ellos son necesarios * suficientes para alcan"ar los objetivos
de niveles m#s altos de la jerar+u$a del producto. Los re+uerimientos anali"ados proveen la base para
re+uerimientos m#s detallados * precisos en niveles inferiores de la jerar+u$a de productos.
ientras los re+uerimientos son definidos, sus relaciones con re+uerimientos * la funcionalidad
definida de m#s alto nivel deben ser entendidas. %tra de las acciones es la determinacin de cu#les
re+uerimientos claves ser#n usados para medir el avance. Por ejemplo, el peso de un producto o el tama-o
de un software pueden ser monitoreados durante su desarrollo bas#ndose en sus riesgos.
<P @8 ;nali"ar re+uerimientos para lograr balance
Pr#ctica8 I$nalizar requerimientos para balacear necesidades y restricciones de los %ta&e'oldersJ.
(ecesidades * restricciones pueden abordar costos, cronogramas, funcionalidades, componentes
reutili"ables, mantenimiento o riesgos.
<P A8 =alidar re+uerimientos
Pr#ctica8 I(os requerimientos se "alidan para asegurar que el producto resultante operar) como est)
pre"isto en el ambiente del usuarioJ
La validacin de re+uerimientos es reali"ada tempranamente con los usuarios para obtener certe"a
de +ue los re+uerimientos permitir#n guiar el desarrollo +ue resulte en una validacin final e.itosa. Las
organi"aciones maduras t$picamente reali"ar#n validacin de re+uerimientos de una manera m#s sofisticada
aplicando diversas t/cnicas * ampliar#n la base de la validacin para incluir necesidades * e.pectativas de
otras partes interesadas.
/olui%n 23nia
El P; de <olucin 1/cnica >1<? tiene como propsito dise-ar, desarrollar e implementar soluciones a
re+uerimientos. Es aplicable a cual+uier nivel de la ar+uitectura del producto * a cada producto, componente
de producto * proceso relacionado con el ciclo de vida del producto. Estos procesos relacionados con el
ciclo de vida del producto son desarrollados conjuntamente con el producto * los componentes del producto.
'icho desarrollo puede incluir la seleccin o adaptacin de procesos e.istentes >procesos est#ndares? o el
desarrollo de nuevos procesos.
/1 18 <eleccionar soluciones para componentes del producto
%bjetivo8 I/oluiones de produto o de omponentes del produto son seleionadas a partir de
alternati0as de solui%nJ.
Las soluciones alternativas * sus ventajas relativas son consideradas antes de seleccionar una
solucin. Los re+uerimientos claves, los temas de dise-o * las restricciones son establecidos para ser
utili"ados en el an#lisis de soluciones alternativas. Las caracter$sticas de la ar+uitectura +ue proveen una
base para la mejora * evolucin del producto son consideradas. El uso de componentes de producto tipo
18
www.monografias.com
C%1< >Commercial %ff 1he <helf? es considerado en relacin con costos, cronograma, rendimiento *
riesgos. Las alternativas tipo C%1< pueden ser utili"adas con o sin adaptaciones. En ocasiones, dichos
elementos re+uieren modificaciones en aspectos tales como interfaces o personali"acin de alguna de sus
caracter$sticas para cumplir en mejor forma con los re+uerimientos del producto.
)n indicador de buen proceso de dise-o es +ue el dise-o fue escogido despu/s de compararlo *
evaluarlo con soluciones alternativas. Las decisiones de ar+uitectura deben ser tomadas. ;lgunas de estas
decisiones pueden re+uerir un proceso formal de toma de decisiones.
En general las soluciones son definidas como un conjunto. Esto significa +ue al definir la siguiente
capa de componentes, la solucin para cada uno de los componentes del conjunto es definida. Las
soluciones alternativas no son slo formas distintas de abordar los mismos re+uerimientos, sino tambi/n
reflejan un destino diferente de re+uerimientos entre los componentes del producto +ue componen el
conjunto solucin. El objetivo es optimi"ar el conjunto de re+uerimientos como un todo * no sus partes.
<P 98 'esarrollar soluciones alternativas * criterios de seleccin
Pr#ctica8 IDesarrollar alternati"as de solucin y criterios de seleccinJ.
Las alternativas de solucin deben ser identificadas * anali"adas para poder seleccionar una
solucin e+uilibrada a trav/s del ciclo de vida del producto en t/rminos de costos, cronograma *
rendimiento. Estas soluciones se basan en ar+uitecturas de producto propuestas +ue abordan
caracter$sticas cr$ticas del producto * abarcan un conjunto de soluciones factibles.
Las alternativas de soluciones frecuentemente comprenden asociaciones alternativas de re+uerimientos a
diferentes componentes del producto. 'ichas alternativas pueden incluir el uso de soluciones C%1< en la
ar+uitectura del producto.
Las alternativas de soluciones cubren el rango aceptable de costo, cronograma * rendimiento. Los
re+uerimientos de componentes del producto son recibidos * utili"ados junto con problemas de dise-o,
restricciones, * criterios para desarrollar soluciones alternativas. Los criterios de seleccin abordar#n
t$picamente costos >tiempo, recursos humanos * otros gastos? * riesgos >t/cnicos, de costo * cronograma?.
Las consideraciones para alternativas de soluciones * criterios de seleccin inclu*en lo siguiente8
G Costo de desarrollo, construccin, ad+uisicin, mantenimiento, soporte, etc.
G &endimiento.
G Complejidad de componentes del producto * de procesos relacionados con su ciclo de vida.
G &obuste" del producto en operacin * condiciones de uso, modos de operacin, ambientes *
variaciones de los procesos relacionados con el ciclo de vida del producto.
G E.pansin * crecimiento del producto.
G Limitantes de la tecnolog$a.
G <ensibilidad a los m/todos * materiales de construccin.
G &iesgos.
G Evolucin de re+uerimientos * tecnolog$a.
G 'ada de baja >eliminacin? del producto.
G Capacidades * limitantes de usuarios finales * operadores.
G Caracter$sticas de productos tipo C%1<.
La anterior es una lista b#sica de consideraciones. Las organi"aciones debieran hacer pro*ecciones
para acortar la lista de alternativas +ue sean consistentes con sus objetivos de negocio. Los costos de ciclo
de vida del producto pueden estar fuera del control de las organi"aciones de desarrollo aun+ue sea un
par#metro atractivo para minimi"ar costos. )n cliente puede no estar dispuesto a pagar por funciones +ue
cuestan m#s en el corto pla"o pero +ue en 0ltima instancia disminu*en el costo durante la vida 0til del
producto. En tales casos, los clientes debieran al menos estar informados de las posibilidades de reducir los
costos durante la vida 0til de un producto. Los criterios utili"ados para seleccionar las soluciones finales
debieran proveer un enfo+ue e+uilibrado de costos, beneficios * riesgos.
<P :8 <eleccionar soluciones para componentes del producto
Pr#ctica8 I%eleccionar las componentes del producto que mejor satisfacen los criterios establecidosJ.
<eleccionar soluciones para componentes del producto +ue mejor satisfagan los criterios
establecidos. &e+uerimientos de m#s bajo nivel son generados a partir de la alternativa seleccionada *
utili"ados para desarrollar el dise-o de los componentes de producto. Los re+uerimientos de interfa" entre
componentes de producto son funcionalmente descritos al inicio. Las descripciones de interfa" f$sica son
incluidas en la documentacin de interfaces hacia elementos * actividades e.ternas al producto.
La descripcin de soluciones * los fundamentos de la seleccin son documentadas. La
documentacin evoluciona a medida +ue las soluciones * los dise-os son detallados, desarrollados e
implementados. El mantenimiento de un registro de fundamentos es cr$tico para la toma de decisiones.
/1 28 'esarrollar el dise-o
19
www.monografias.com
%bjetivo8 I"iseDos del produto y omponentes del produto son desarrolladasJ
'ise-os de productos o componentes de productos deben proveer el contenido apropiado no slo
para la implementacin, sino tambi/n para otras fases del ciclo de vida del producto tales como
modificacin, ad+uisicin, mantenimiento e instalacin. La documentacin de dise-o provee una referencia
para apo*ar el entendimiento mutuo del dise-o por parte de las partes interesadas * as$ apo*ar futuros
cambios al dise-o *a sea durante el desarrollo como en las fases siguientes del ciclo de vida del producto.
)na descripcin completa del dise-o es documentada inclu*endo una completa gama de caracter$sticas *
par#metros inclu*endo forma, ajuste, funcin, interfa", caracter$sticas del proceso de construccin * otros
par#metros. Est#ndares establecidos de dise-o de pro*ecto u organi"acionales >listas, plantillas, estructura
de objetos? forman la base para alcan"ar un alto grado de definicin * completitud en la documentacin del
dise-o.
<P 98 'ise-ar el producto o los componentes del producto
Pr#ctica8 IDesarrollar un dise*o para el producto o componente del productoJ.
El dise-o del producto consiste en dos e.tensas fases +ue pueden superponerse en ejecucin8
dise-o preliminar * dise-o detallado. El dise-o preliminar establece las capacidades * la ar+uitectura del
producto, inclu*endo divisiones del producto, identificacin de los componentes del producto, estados de
sistemas * modos, interfaces principales e interfaces e.ternas del producto. El dise-o detallado define
completamente la estructura * las capacidades de los componentes del producto.
La definicin de la ar+uitectura es guiada a partir de un conjunto de re+uerimientos de ar+uitectura.
Estos re+uerimientos e.presan los elementos de calidad * rendimiento +ue son cr$ticos para el /.ito del
producto. La ar+uitectura define los elementos estructurales * los mecanismos de coordinacin +ue
directamente satisfacen los re+uerimientos o apo*an su reali"acin a medida +ue se establecen los detalles
del dise-o del producto. Las ar+uitecturas pueden incluir est#ndares * reglas de dise-o +ue dirigen el
desarrollo de los componentes del producto * sus interfaces, as$ como una gu$a para a*udar a sus
desarrolladores.
Los ar+uitectos postulan * desarrollan un modelo del producto, haciendo juicios sobre la asociacin
de re+uerimientos con los componentes del producto, inclu*endo hardware * software. 0ltiples
ar+uitecturas +ue apo*an las soluciones alternativas pueden ser desarrolladas * anali"adas para determinar
las ventajas * desventajas en el conte.to de los re+uerimientos de ar+uitectura.
Los conceptos operacionales * escenarios son usados para generar casos de uso * escenarios de
calidad +ue se usan para refinar la ar+uitectura. 1ambi/n son usados como un medio para evaluar +u/ tan
apropiada es la ar+uitectura para el propsito previsto durante las evaluaciones, las cuales son reali"adas
peridicamente durante todo el dise-o del producto.
'urante el dise-o detallado, los detalles de la ar+uitectura del producto son finali"ados, los
componentes del producto son definidos completamente * las interfaces son descritas en su totalidad. Los
dise-os de los componentes de productos pueden ser optimi"ados para ciertas caracter$sticas de
rendimiento o calidad. ; medida +ue el dise-o madura, los re+uerimientos asignados a componentes de
productos de m#s bajo nivel son monitoreados para asegurar +ue esos re+uerimientos son satisfechos.
<P :8 Establecer un pa+uete de datos t/cnicos
Pr#ctica8 IEstablecer y mantener un paquete de datos t+cnicosJ.
)n pa+uete de datos t/cnicos provee al desarrollador una descripcin e.haustiva del producto o de
sus componentes a medida +ue es desarrollado. 'icho pa+uete tambi/n provee fle.ibilidad de ad+uisiciones
en diversas circunstancias, tales como IPerformanceGOased ContractingJ >POC? o IOuild 1o PrintJ.
El dise-o es registrado en un pa+uete de datos t/cnicos creado durante el dise-o preliminar para
documentar la definicin de la ar+uitectura. Este pa+uete de datos t/cnicos es mantenido durante toda la
vida del producto para registrar detalles esenciales del dise-o del producto. El pa+uete de datos t/cnicos
provee la descripcin del producto * sus componentes +ue apo*an la estrategia de ad+uisicin, o la
implementacin, produccin, ingenier$a * fases de soporte log$stico del ciclo de vida del producto. La
descripcin inclu*e la definicin de la configuracin re+uerida del dise-o * procedimientos para asegurar el
comportamiento adecuado del producto o de sus componentes. Esto inclu*e todos los datos t/cnicos
aplicables como dibujos, listas asociadas, especificaciones, descripciones de dise-o, bases de datos de
dise-o, est#ndares, re+uerimientos de rendimiento, provisiones de aseguramiento de calidad * detalles de
empa+uetamiento. El pa+uete de datos t/cnicos inclu*e una descripcin de la solucin alternativa
seleccionada a ser implementada.
)n pa+uete de datos t/cnicos deber$a incluir lo siguiente, si dicha informacin es apropiada para el
tipo de producto * componentes del producto8
G 'escripcin de ar+uitectura de producto.
G &e+uerimientos asignados.
20
www.monografias.com
G 'escripcin de componentes del producto.
G 'escripcin de los procesos relacionados con el ciclo de vida del producto, si no es descrito como
componentes de productos separados.
G Caracter$sticas de productos claves.
G Caracter$sticas f$sicas re+ueridas * restricciones.
G &e+uerimientos de interfa".
G &e+uerimientos de materiales.
G Cabricacin * re+uerimientos de manufactura.
G Criterios de verificacin usados para asegurar +ue los re+uerimientos han sido satisfechos.
G Condiciones de uso >ambientes? * escenarios de uso M operacin, modos * estados de operacin,
soporte, capacitacin, manufactura, eliminacin del producto * verificaciones a los largo de la vida 0til del
producto.
G Cundamentos de decisiones * caracter$sticas >re+uerimientos, asignacin de re+uerimientos *
opciones de dise-o?.
'ebido a +ue las descripciones de dise-o pueden contener una gran cantidad de informacin *
pueden ser cruciales para el desarrollo e.itoso de los componentes del producto, es aconsejable establecer
criterios para organi"ar * seleccionar la informacin. Es particularmente 0til utili"ar la ar+uitectura del
producto como una manera de organi"ar la informacin * elaborar vistas claras * relevantes para un tema o
caracter$stica de inter/s. Estas vistas inclu*en lo siguiente8
G Clientes.
G &e+uerimientos.
G El ambiente.
G Cuncionalidad.
G Lgica.
G <eguridad.
G 'atos.
G Estados M modos.
G Construccin.
G ;dministracin
Estas vistas son documentadas en el pa+uete de datos t/cnicos.
<P ,8 'ise-ar interfaces utili"ando criterios
Pr#ctica8 IDise*ar interfaces de componentes del producto utilizando los criterios establecidosJ.
Estos dise-os de interfaces inclu*en lo siguiente8
G %r$genes.
G 'estino.
G Est$mulos * caracter$sticas de datos para el software
G Caracter$sticas el/ctricas, mec#nicas * funcionales para hardware
G L$neas de comunicacin.
El criterio para interfaces frecuentemente refleja par#metros cr$ticos +ue deben ser definidos, o al
menos investigados, para asegurar su aplicabilidad. Estos par#metros son a menudo caracter$sticos de un
cierto tipo de producto >software, mec#nico, el/ctrico, de servicio? * son a menudo asociados con seguridad,
durabilidad * caracter$sticas de la misin cr$tica.
<P @8 Ejecutar ;n#lisis de8 Nacer, Comprar o &eutili"ar
Pr#ctica8 IE"aluar si los componentes del producto debieran ser desarrollados comprados o reutilizados
bas)ndose en los criterios establecidosJ.
La determinacin acerca de +u/ producto o componentes del producto ser#n ad+uiridos es
frecuentemente referido como Ima2eGorGbu* anal*sisJ >an#lisis de hacerGoGcomprar?. Este an#lisis esta
basado en las necesidades del pro*ectoK comien"a tempranamente durante la primera iteracin de dise-o,
contin0a durante el proceso de dise-o * conclu*e con la decisin de desarrollar, ad+uirir o reutili"ar el
producto.
Cactores +ue afectan la decisin de hacerGoGcomprar inclu*en los siguientes8
G Cunciones +ue los productos o servicios proveer#n * cmo estas funciones se ajustan al pro*ecto.
G &ecursos * habilidades disponibles del pro*ecto.
G Costos de ad+uisicin versus costos de desarrollo interno.
G Entregas cr$ticas * fechas de integracin.
G ;lian"as estrat/gicas de negocios, inclu*endo re+uerimientos de negocio de alto nivel.
G !nvestigacin de mercado de productos disponibles, inclu*endo productos tipo C%1<.
G Cuncionalidad * calidad de productos disponibles.
21
www.monografias.com
G Nabilidades * capacidades de potenciales proveedores.
G !mpacto en las competencias esenciales.
G Licencias, garant$as, responsabilidades * limitantes asociadas a productos +ue est#n siendo
ad+uiridos.
G 'isponibilidad de productos
G Calidad propietaria de productos * componentes.
G &educcin de riesgos.
La decisin de hacerGoGcomprar puede efectuarse aplicando un proceso formal de toma de
decisiones. ; medida +ue la tecnolog$a evoluciona, tambi/n lo hacen las ra"ones para elegir el desarrollo o
compra de componentes de producto. ientras el esfuer"o de desarrollo complejo puede favorecer la
compra de un componente tipo C%1<, los avances en la productividad * herramientas pueden presentar
ra"ones en sentido contrario. Productos tipo C%1< pueden tener documentacin incompleta o incorrecta *
pueden no contar con soporte en el futuro.
/1 38 !mplementar el 'ise-o del Producto
%bjetivo8 IComponentes del produtoB y su doumentai%n de apoyo asoiadaB son implementadas
segEn sus diseDosJ.
Los componentes del producto son implementados a partir de los dise-os establecidos por las
pr#cticas espec$ficas de la pr#ctica espec$fica 'esarrollar el 'ise-o. La implementacin usualmente inclu*e
pruebas unitarias de los componentes del producto antes de la integracin de producto * el desarrollo de
documentacin de usuarios finales.
<P 98 !mplementar el 'ise-o
Pr#ctica8 IImplementar los dise*os de las componentes del productoJ.
)na ve" +ue el dise-o se ha completado, /ste es implementado como un componente del producto.
Las caracter$sticas de esa implementacin dependen del tipo de componente.
La implementacin del dise-o en el primer nivel de la jerar+u$a del producto implica la especificacin
de cada uno de los componentes del producto en el siguiente nivel de la jerar+u$a. Esta actividad inclu*e la
asignacin, refinamiento * verificacin de cada componente del producto. 1ambi/n inclu*e la coordinacin
de los trabajos de desarrollo del componente del producto.
<P :8 'esarrollar la documentacin de apo*o del producto
Pr#ctica8 IDesarrollar y mantener la documentacin de utilizacin finalJ.
Esta pr#ctica espec$fica desarrolla * mantiene la documentacin +ue ser# usada para instalar,
operar * mantener el producto.
Integrai%n de Produtos
El propsito de P! es ensamblar las componentes del producto para obtener el producto, asegurar +ue el
producto L seg0n la integracin +ue se hi"o L funciona correctamente, * liberar el producto al cliente.
P! involucra tanto8
R !ntegracin del producto8 !ntegracin para el producto final.
R !ntegracin de las componentes del producto8 !ntegracin de componentes para producir
componentes m#s complejas.
El #mbito de P! es alcan"ar la integracin del producto completo a trav/s del ensamble de
progresivas componentes, en uno o m#s pasos, de acuerdo a la secuencia de integracin definida * los
procedimientos. <e usa el t/rmino !ntegracin de Productos para tambi/n referirse a la !ntegracin de
<ervicios.
/1 18 Preparacin para la !ntegracin del producto
%bjetivo8 IPreparai%n para la integrai%n del produto es onduidaJ
Preparar la integracin de los componentes del producto inclu*e establecer * mantener8
R )na secuencia de integracin del producto * de las componentes del producto.
R El ambiente para reali"ar la integracin del producto * de las componentes del producto.
R Procedimientos * criterios para la integracin del producto * de las componentes del producto.
La preparacin para la integracin comien"a al inicio del pro*ecto * la secuencia de integracin es
desarrollada al mismo tiempo con las pr#cticas del #rea de proceso de <olucin 1/cnica.
<P 98 'eterminar la <ecuencia de !ntegracin
Pr#ctica8 IDeterminar la secuencia de integracin de componentes del productoJ
Las componentes del producto son anali"adas para su integracin. <e define un conjunto de
secuencias posibles para integrar las componentes * se elige la mejor secuencia posible.
<P :8 Establecer el ;mbiente de !ntegracin del Producto
22
www.monografias.com
Pr#ctica8 JEstablecer y mantener el ambiente necesario para apoyar la integracin de las componentes del
productoJ.
El ambiente para la integracin de producto puede ser ad+uirido o desarrollado. Para establecer un
ambiente, re+uerimientos para la compra o desarrollo de e+uipamientos, software u otros recursos
necesitar#n ser desarrollados. El ambiente re+uerido en cada paso del proceso de integracin de producto
puede incluir e+uipos para reali"ar pruebas, simuladores >tomando el lugar de componentes de productos
no disponibles?, pie"as de e+uipos reales * dispositivos de almacenamiento.
<P ,8 Establecer Procedimientos * Criterios de !ntegracin del Producto
Pr#ctica8 IEstablecer y mantener procedimientos y criterios para la Integracin de las componentes del
productoJ.
Los procedimientos para la integracin de las componentes del producto pueden incluir cosas como
el n0mero de iteraciones incrementales +ue se reali"an * detalles de las evaluaciones +ue ser#n llevadas a
cabo en cada etapa.
Los criterios pueden indicar si la componente del producto esta o no preparada para su integracin
o su grado de aceptacin.
Los procedimientos * criterios para la integracin del producto dirigen lo siguiente8 (ivel de prueba
para construir componentes, =erificacin de interfaces, )mbrales de desviacin de ejecucin,
&e+uerimientos derivados para el ensamble * sus interfaces e.ternas, <ustituciones permitidas de
componentes, Par#metros del ambiente de prueba, Limites en los costos de prueba, E+uilibrio
calidadMcostos para operaciones de integracin, Probabilidad del funcionamiento apropiado, 1asas de
entrega * sus variaciones, 1iempo de entrega desde el pedido hasta la entrega, 'isponibilidad de personal *
'isponibilidad de la facilidadMl$neaMambiente de integracin.
Los criterios pueden ser definidos por cmo las componentes del producto est#n para ser
verificados * las funciones +ue se espera +ue ellas tengan. Los criterios pueden ser definidos por cmo las
componentes ensambladas del producto * el producto integrado final son validados * liberados. Los criterios
tambi/n pueden restringir el grado de simulacin permitidos para +ue las componentes puedan pasar una
prueba, o pueden restringir el ambiente para ser usado en el test de integracin.
/1 28 ;segurar la compatibilidad de interfaces
%bjetivo8 I6as inter)aes de las omponentes del produtoB internas y eCternasB son ompatiblesJ.
uchos problemas de integracin de productos surgen por aspectos no conocidos o no controlados
de interfaces internas * e.ternas a cada componente. La administracin efectiva de re+uerimientos de
interfaces de componentes de productos, especificaciones * dise-os, a*udan a asegurar +ue las interfaces
implementadas ser#n compatibles * completas.
<P 98 &evisar 'escripcin de !nterfaces para Completitud
Pr#ctica8 IRe"isar descripciones de interfaces para su cobertura y completitudJ.
Las interfaces deben incluir, adem#s de las interfaces de los componentes del producto, todas las
interfaces con el ambiente de integracin del producto.
<P :8 4estionar !nterfaces
Pr#ctica8 I,estionar definiciones de interfaces internas y e!ternas dise*os y cambios en productos y
componentes del productoJ.
Los re+uerimientos de interfa" manejan el desarrollo de las interfaces necesarias para integrar las
componentes del producto. 4estionar interfases del producto * componentes del producto comien"a
tempranamente en el desarrollo del producto. Las definiciones * el dise-o para interfaces afecta, no
solamente a los componentes de producto * sistemas e.ternos, sino +ue tambi/n puede afectar la
validacin * verificacin de ambientes.
La gestin de interfaces inclu*e la mantencin de la consistencia de las interfaces durante todo el
ciclo de vida del producto, * resolucin de conflictos, disconformidades, * cambios en temas. La gestin de
interfaces entre productos ad+uiridos desde proveedores * otros productos o componentes de productos
son cr$ticas para el /.ito del pro*ecto.
Las interfaces deben incluir, adem#s de las interfaces de las componentes del producto, todas las
interfaces con el ambiente, as$ como con otros como ambientes para verificacin, validacin, operaciones *
soporte. Los cambios en la interfase son documentados, mantenidos * f#cilmente accesibles.
/1 38 Ensamblar las componentes del producto * liberar el producto
%bjetivo8 IComponentes del produto 0eri)iadas son ensambladas y el produto integradoB
0eri)iado y 0alidado es entregadoJ.
La integracin de las componentes del producto se hace de acuerdo a la secuencia de integracin
del producto * los procedimientos disponibles. ;ntes de la integracin, cada componente del producto es
verificada de acuerdo a los re+uerimientos de interfa" establecidos. Las componentes del producto son
23
www.monografias.com
ensambladas en componentes m#s complejas * grandes. Estas componentes ensambladas son
che+ueadas para su correcta interoperacin. Este proceso contin0a hasta +ue la integracin del producto es
completada. <i durante este proceso se identifican problemas estos deben ser documentados * un proceso
de acciones correctivas es iniciado.
<P 98 Confirmar Componentes para !ntegracin preparados
Pr#ctica8 IConfirmar pre"io al ensamble que cada componente del producto requerido para ensamblar el
producto 'a sido debidamente identificado funciones corresponden a su descripcin y las interfaces de las
componentes del producto cumplen con las descripciones de las interfacesJ.
El propsito de esta pr#ctica espec$fica es asegurar +ue las componentes del producto
adecuadamente identificadas +ue cumplen con su descripcin puedan ser realmente ensambladas de
acuerdo a la secuencia de integracin del producto * procedimientos disponibles. 1ambi/n la consistencia
entre las componentes de producto * descripciones de interfase son che+ueadas.
Uuienes conducen la integracin del producto son los responsables en 0ltima instancia de che+uear
para asegurarse +ue todo est# correcto * as$ continuar con el ensamble.
<P :8 Ensamblar las componentes del producto
Pr#ctica8 IEnsamblar las componentes del producto de acuerdo a la secuencia de integracin y
procedimientos disponiblesJ.
Las actividades de ensamblaje de esta pr#ctica espec$fica * las actividades de evaluacin de la
pr.ima son conducidas en forma iterativa, desde los componentes iniciales del producto, a trav/s de los
componentes ensamblados provisorios, hasta el producto como un todo.
<P ,8 Evaluar Componentes del Producto ensambladas
Pr#ctica8 IE"aluar componentes de producto ensamblados para la compatibilidad de interfaseJ.
Esta evaluacin involucra e.aminar * probar las componentes del producto ensambladas para su
reali"acin, conveniencia o preparacin usando los procedimientos * ambiente disponibles. Esto es
reali"ado para los diferentes pasos del ensamble seg0n lo dispuesto por la secuencia de integracin *
procedimientos disponibles. La secuencia de integracin del producto * procedimientos disponibles, el
n0mero de componentes, * la complejidad del producto podr$an definir una secuencia de integracin *
evaluacin m#s refinada.
<P @8 Empa+uetar * Entregar Productos o Componentes del Producto
Pr#ctica8 IEmpaquetar el producto ensamblado o componente del producto y entregarlo al cliente
apropiadoJ.
Los re+uerimientos de empa+ue para algunos productos pueden ser dirigidos seg0n sus
especificaciones * criterios de verificacin. Esto es especialmente importante cuando los $tems son
registrados * transportados por los clientes. En tales casos, pudiese haber condiciones de estr/s * ambiente
especificadas para el pa+uete. En otras circunstancias econom$a * re+uerimientos de transporte,
responsabilidad, * facilidad * seguridad del desempa+ue son factores importantes.
'eri)iai%n
El propsito de =erificacin >=E&? es asegurar +ue los artefactos cumplen con los re+uerimientos
especificados.
=E& involucra la verificacin del producto o servicios * artefactos intermedios con respecto a los
re+uerimientos seleccionados, inclu*endo re+uerimientos del cliente, del producto o servicio * componentes
del producto o servicio. =E& es un proceso incremental por+ue se aplica al desarrollo del producto *
artefactos, comen"ando con la verificacin de los re+uerimientos, pasando por la verificacin de artefactos *
terminando con la verificacin del producto completo.
=E& * =;L son similares pero tienen diferencias. =;L demuestra +ue el producto +ue se entregar#
satisface su uso entendido, mientras +ue =E& se enfoca en +ue los artefactos reflejen los re+uerimientos
especificados. En otras palabras, =E& asegura +ue algo se constru*e correctamente, mientras +ue =;L
asegura +ue se constru*e algo correcto.
/1 18 Preparar la verificacin
%bjetivo8 J6a preparai%n de la 0eri)iai%n es onduidaJ.
)na preparacin es necesaria para asegurar +ue los re+uerimientos de verificacin est#n incluidos
en los re+uerimientos del producto * las componentes del producto, dise-os, planes de desarrollo *
programas. La verificacin inclu*e seleccin, inspeccin, prueba, an#lisis * demostracin de artefactos.
Los m/todos de verificacin inclu*en, pero no est#n limitados a ellos, inspecciones, revisiones de
pares, auditorias, inspecciones, an#lisis, simulaciones, pruebas * demostraciones.
La preparacin tambi/n supone la definicin de herramientas de apo*o, e+uipamientos para
pruebas * software, simulaciones, prototipos * facilidades.
24
www.monografias.com
<P 98 <eleccionar artefactos para =erificacin
Pr#ctica8 I%eleccionar artefactos a ser "erificados y m+todos de "erificacin que ser)n usados para cada
uno de ellosJ.
Los artefactos son seleccionados bas#ndose en su contribucin para alcan"ar los objetivos *
re+uerimientos del pro*ecto, * para dirigir los riesgos del pro*ecto.
Los artefactos +ue ser#n verificados pueden incluir a+uellos asociados con la mantencin,
entrenamiento * servicios de apo*o. Los m/todos de verificacin dirigen el enfo+ue t/cnico de la verificacin
de artefactos * los procedimientos espec$ficos +ue ser#n usados para verificar +ue los productos de trabajo
espec$ficos cumplan sus re+uerimientos.
La seleccin de los m/todos de verificacin comien"a t$picamente con la participacin en la
definicin de los re+uerimientos del producto o componentes del producto para asegurar +ue estos
re+uerimientos son verificables.
<P :8 Establecer el ambiente de =erificacin
Pr#ctica8 IEstablecer y mantener el ambiente necesario para apoyar la "erificacinJ.
)n ambiente debe ser establecido para permitir +ue la verificacin tome lugar. El ambiente de
verificacin puede ser ad+uirido, desarrollado, reutili"ado, modificado, o una combinacin de estos,
dependiendo de las necesidades del pro*ecto.
Cada ambiente re+uerido va a depender de los artefactos seleccionados para su verificacin * los
m/todos de verificacin usados.
<P ,8 Establecer procedimientos * criterios de verificacin
Pr#ctica8 IEstablecer y mantener procedimientos y criterios de "erificacin para los artefactos
seleccionadosJ
Los criterios de verificacin son definidos para asegurar +ue los artefactos cumplan con sus
re+uerimientos.
/1 28 &eali"ar &evisin de Pares
%bjetivo8 IRe0isiones de pares son desarrolladas sobre arte)atos seleionadosJ.
La revisin de pares es un an#lisis metodolgico de artefactos reali"ado por los productores o
desarrolladores pares para identificar defectos a ser removidos * recomendar otros cambios seg0n sean
necesarios.
La revisin de pares es un m/todo de ingenier$a importante * efectivo implementado v$a
inspecciones u otros m/todos de revisin.
<P 98 Preparar la revisin de pares
Pr#ctica8 I-reparar para la re"isin de pares de artefactos seleccionadosJ.
;ctividades de preparacin para la revisin de pares t$picamente inclu*en identificar el personal +ue
ser# invitado a participar en la revisin de pares de cada artefactoK identificar los revisores claves +ue deben
participar en la revisin de paresK preparar * actuali"ar cual+uier material +ue ser# usado durante la revisin
de pares.
<P :8 Conducir la revisin de pares
Pr#ctica8 IConducir la re"isin de pares sobre artefactos seleccionados e identificar defectos resultantes de
la re"isin de paresJ.
)no de los propsitos de conducir la revisin de pares es encontrar * remover tempranamente
defectos. La revisin de pares es reali"ada incrementalmente tal como los artefactos est/n siendo
desarrollados. Estas revisiones son estructuradas * no son revisiones administrativas.
La revisin de pares puede ser reali"ada en cual+uier tipo de artefacto. Cuando surgen defectos de
la revisin de pares, estos deben ser comunicados al desarrollador principal del artefacto para su
correccin.
La revisin de pares debe dirigir lo siguiente8 'ebe haber la preparacin suficiente, la conduccin
debe ser administrada * controlada, datos consistentes * suficientes deben ser registrados, * puntos de
accin deben ser registrados.
<P ,8 ;nali"ar los datos de la revisin de pares
Pr#ctica8 I$nalizar datos acerca de la preparacin conduccin y resultados de la re"isin de paresJ.
;nali"ar datos acerca de la preparacin, conduccin * resultados de la revisin de pares.
/1 38 =erificar ;rtefactos <eleccionados
%bjetivo8 I6os arte)atos son 0eri)iados ontra sus re#uerimientos espe)iosJ.
Los m/todos, procedimientos * criterios de evaluacin son usados para verificar +ue el artefacto
seleccionado * cual+uier mantencin asociada, entrenamiento * servicios de soporte usan el ambiente de
25
www.monografias.com
verificacin apropiado. ;ctividades de verificacin deben ser reali"adas durante todo el ciclo de vida del
producto.
<P 98 &eali"ar la verificacin
Pr#ctica8 IRealizar "erificacin de los artefactos seleccionadosJ.
=erificar incrementalmente productos * artefactos promueve la deteccin temprana de problemas *
puede resultar en la remocin temprana de defectos. Los resultados de la verificacin ahorran costos
considerables de fallas aisladas * trabajo repetido asociado a la resolucin de problemas.
<P :8 ;nali"ar resultados de verificacin identificando acciones correctivas
Pr#ctica8 I$nalizar los resultados de todas las acti"idades de "erificacinJ.
Los resultados actuales deben ser comparados con los criterios de verificacin establecidos para
determinar la aceptabilidad.
Los resultados del an#lisis son registrados como evidencia de +ue la verificacin fue reali"ada.
Para cada artefacto, todos los resultados de verificacin son anali"ados incrementalmente para
asegurar +ue los re+uerimientos ha*an sido cumplidos. 'ado +ue la revisin de pares es uno de varios
m/todos de verificacin, los datos de revisin de pares deben ser incluidos en esta actividad de an#lisis
para asegurar +ue los resultados de la verificacin son suficientemente anali"ados.
'alidai%n
El propsito de =alidacin >=;L? es demostrar +ue un producto o componentes del producto cumplen su uso
planeado cuando es ubicado en su planeado ambiente.
;ctividades de validacin pueden ser aplicadas a todos los aspectos del producto en cual+uiera de
sus ambientes planeados, tal como operacin, entrenamiento, manufactura, mantencin, * servicios de
soporte, Los m/todos empleados para conseguir la validacin pueden ser aplicados a artefactos as$ como
tambi/n a productos o servicios * componentes del producto o servicios.
/1 18 Preparar la validacin
%bjetivo8 I6a preparai%n para la 0alidai%n es onduidaJ.
;ctividades de preparacin inclu*en la seleccin de productos * los componentes del producto para
validacin, * establecer * mantener el ambiente, procedimientos * criterios de validacin. Los artefactos
seleccionados para validacin pueden incluir slo el producto o puede incluir niveles apropiados de las
componentes del producto +ue son usados para construir el producto. El ambiente de !ntegracin de
Productos, =erificacin * =alidacin puede ser el mismo.
<P 98 <eleccionar Productos para la validacin
Pr#ctica8 I%eleccionar productos y componentes de productos a ser "alidados y los m+todos de "alidacin
que ser)n usados para cada unoJ.
Productos * componentes de productos son seleccionados para validacin sobre la base de sus
relaciones con las necesidades del usuario. Para cada componente de producto, el alcance de la validacin
>comportamiento operacional, mantencin, entrenamiento e interfase de usuario? deber$a ser determinado.
Los re+uerimientos * restricciones para reali"ar la validacin son recopilados. Entonces, los
m/todos de validacin son seleccionados bas#ndose en su capacidad para demostrar +ue las necesidades
de los usuarios est#n satisfechas. Los m/todos de validacin no slo definen el enfo+ue t/cnico de la
validacin del producto, sino tambi/n dirige las necesidades para los e+uipos a utili"ar * ambientes de
validacin. &e+uerimientos derivados, como re+uerimientos de interfaces para hacer pruebas *
e+uipamientos, pueden ser generados.
Los m/todos de validacin deben ser seleccionados tempranamente en la vida del pro*ecto para
+ue sean claramente entendidos * acordados con las partes interesadas.
Los m/todos de validacin dirigen el desarrollo, mantencin, soporte * entrenamiento para el
producto o las componentes del producto seg0n sea apropiado.
<P :8 Establecer el ambiente para la validacin
Pr#ctica8 IEstablecer y mantener el ambiente necesario para apoyar la "alidacinJ.
Los re+uerimientos para el ambiente de validacin son manejados por el producto o las
componentes de productos seleccionadas, por el tipo de artefacto >por ejemplo, dise-o, prototipo, versin
final? * por los m/todos de validacin. Esto podr$a producir re+uerimientos para la compra o desarrollo de
e+uipamiento, software u otros recursos. El entorno de validacin puede incluir la reutili"acin de recursos
e.istentes. En este caso, se deben hacer arreglos para el uso de estos recursos. Ejemplos de tipos de
elementos en un ambiente de validacin inclu*en lo siguiente8
G Nerramientas de prueba interconectadas con el producto +ue esta siendo validado.
G <oftware para prueba.
G <ubsistemas simulados o componentes.
26
www.monografias.com
G <istemas simulados.
G <istemas reales.
G Cacilidades * productos provistos por el cliente.
G Las personas h#biles para operar o usar todos los elementos precedentes.
G ;mbiente de prueba con computador dedicado o sistema distribuido.
<P ,8 Establecer Procedimientos * Criterios de =alidacin
Pr#ctica8 IEstablecer y mantener procedimientos y criterios de "alidacinJ
Procedimientos * criterios de validacin son definidos para asegurar +ue el producto o las
componentes del producto van a satisfacer su uso planificado cuando es ubicado en su ambiente
planificado. La aceptacin de casos de pruebas * procedimientos pueden satisfacer la necesidad de
procedimientos de validacin.
Los procedimientos * criterios de validacin inclu*en pruebas * evaluaciones de mantenimiento,
entrenamiento * servicios de soporte.
/1 28 =alidar Productos o Componentes del Producto
%bjetivo8 I5l produto o las omponentes del produto son 0alidados para asegurar #ue son aptas
para su uso en su ambiente operaional pre0istoJ.
Los m/todos, procedimientos * criterios de validacin son usados para validar los productos * las
componentes de los productos seleccionados * cual+uier mantenimiento, entrenamiento * servicios de
apo*o asociado usando el apropiado ambiente de validacin. ;ctividades de validacin son reali"adas
durante todo el ciclo de vida del producto.
<P 98 &eali"ar la validacin
Pr#ctica8 IRealizar la "alidacin sobre los productos y las componentes del producto seleccionadosJ.
Para +ue sea aceptable para los usuarios, un producto o componente del producto debe reali"arse
como es esperado en su ambiente operacional planificado.
Las actividades de validacin son reali"adas * los datos resultantes son recogidos de acuerdo a los
m/todos, procedimientos * criterios establecidos.
Los procedimientos de validacin sobre la marcha deben ser documentados * las desviaciones +ue
ocurran durante la ejecucin deben ser atendidas, seg0n sea apropiado.
<P :8 ;nali"ar los resultados de la validacin
Pr#ctica8J$nalizar los resultados de las acti"idades de "alidacinJ.
Los datos resultantes de las pruebas de validacin, inspecciones, demostraciones o evaluaciones
son anali"adas contra los criterios de validacin definidos. Los informes de an#lisis indican si las
necesidades fueron satisfechasK en el caso de las deficiencias, estos documentos informan el grado de /.ito
o fracaso * categori"an las probables causas de fracaso. Las pruebas recolectadas, inspecciones o
resultados revisados son comparados con los criterios de evaluacin establecidos para determinar si
avan"ar o enfocarse en los re+uerimientos +ue est#n bajo cuestin.
;nali"ar informes o documentacin de validacin sobre la marcha tambi/n puede indicar +ue los
malos resultados de las pruebas son debido a problemas en los procedimientos de validacin o un problema
en el ambiente de validacin.
27
www.monografias.com
Proeso de "esarrollo de /o)t*are de 4R"59 Integrai%n
Introduccin
%&'E( !ntegracin es una organi"acin tecnolgica chilena perteneciente al consorcio de <onda <.;. cu*a
misin es la de aportar con soluciones inform#ticas precisas, de calidad, en forma oportuna * a un precio
justo al progreso * desarrollo de sus clientes. Cuenta con m#s de :A a-os de e.periencia tanto a nivel
nacional como internacional * su visin es la de ser una empresa global, con capacidad de aprendi"aje, leal
a sus principios * de creciente competitividad, por lo cual su inversin * proceso de transformacin es
constante
:
. Es considerada la f#brica de software de <onda <.;., *a +ue es a+u$ donde se reali"an la
ma*or$a de los desarrollos de software a medida. ;lgunos sus clientes son8 Nospital )niversitario ;ustral de
Ouenos ;ires, Poder Pudicial, C%(;<;, C#mara de Comercio de <antiago, E1&% <antiago, 'ireccin
4eneral de ;eron#utica Civil, &egistro Civil, Contralor$a 4eneral de la &ep0blica, entre otros.
'ado +ue estos * sus dem#s clientes son instituciones de prestigio nacional, la calidad de los productos *
servicios ofrecidos deben poder estar de alguna manera garanti"adaK esto como parte de la estrategia de
calidad definida por la organi"acin. Es por ello +ue el :55A %&'E( recibi la certificacin de calidad del *a
obsoleto modelo C nivel : * actualmente ha iniciado el proceso de acreditacin de C! nivel ,, lo +ue
va a implicar +ue no slo la organi"acin cuente con una metodolog$a propia, con un proceso de desarrollo
de software bien definido de acuerdo a su propia forma de hacer negocio, sino +ue se ponga /nfasis en la
ingenier$a de la metodolog$a, lo cual sumado a los procesos de gestin * apo*o se conforme una estructura
completa de todo el ciclo productivo de desarrollo de pro*ectos software.
<in embargo el objetivo principal +ue persigue tanto el modelo como la organi"acin es +ue la metodolog$a
sea conocida formalmente * bien utili"ada por todos los miembros de %&'E(, cambiando para mejor la
forma de trabajar de cada una de estas personas, no con el propsito de obligar a la gente a reali"ar sus
actividades cotidianas de una manera determinada, sino para mejorar el orden, la comunicacin, la
responsabilidad * finalmente la productividad de todos. 'e esta forma se lograr$a institucionali"ar la
metodolog$a * madurar como organi"acin.
Como se acaba de mencionar, %&'E( !ntegracin actualmente se encuentra trabajando junto con
la empresa chilena ;m/rica YY! en la mejora de sus procesos de negocio con el objetivo de certificarse bajo
C! (ivel , para los primeros meses del siguiente a-o. Es por ello +ue han decidido enfocarse en los
componentes esperados L pr#cticas espec$ficas * gen/ricas L para cumplir con los componentes
re+ueridos L objetivos espec$ficos * gen/ricos L de este nivel de madure" del modelo en su versin 9.:.
Para alcan"ar tal certificacin %&'E( integracin se encuentra por un lado redefiniendo algunos de sus
procesos de acuerdo al modelo para luego ser publicados a la organi"acin, mientras +ue por otro lado
a+uellos los procesos +ue *a fueron redefinidos * publicados est#n en etapa de institucionali"acin en la
organi"acin.
Los procesos de %&'E( !ntegracin est#n divididos en dos grandes #reas. La primera corresponde
a los Procesos de ;dministracin de Pro*ectos e !ngenier$a de <oftware * la segunda a los Procesos de la
;dministracin 4eneral de la C#brica de <oftware. 'entro del #rea de Procesos de ;dministracin de
Pro*ectos e !ngenier$a de <oftware se encuentran una serie de sub#reas +ue en conjunto son las
encargadas de desarrollar * apo*ar un pro*ecto en particular siguiendo su ciclo de vida por completo. Estas
sub#reas inclu*en8 Procesos %rgani"acionales >capacitaciones, m/tricas?, Procesos de ;dministracin de
Pro*ecto >planificacin, control * seguimiento, riesgos?, Procesos de !ngenier$a de <oftware >re+uerimientos,
an#lisis * dise-o, construccin, pruebas * despliegue? * Procesos de <oporte >administracin de la
configuracin, aseguramiento de la calidad?.
'entro del #rea de Procesos de la ;dministracin 4eneral de la C#brica de <oftware se encuentran todos
los procesos +ue no participan directamente del desarrollo de un pro*ecto, pero +ue son vitales para el
funcionamiento interno de la organi"acin8 Planificacin * Control Estrat/gico >presupuesto anual?, Procesos
de Cierre ensual de ;ctividades, Evaluacin * Preparacin de Propuestas, ;dministracin de Personal *
;dministracin de Proveedores * ;lian"as Estrat/gicas.
Como se mencion anteriormente, es dentro del #rea de Procesos de ;dministracin de Pro*ectos
e !ngenier$a de <oftware donde efectivamente los pro*ectos son desarrollados de inicio a fin. En la sub#rea
de Procesos de !ngenier$a de <oftware se encuentra alojado el Proceso de desarrollo de software de
%&'E( !ntegracin, +ue ser# presentado en detalle en este documento.
El proceso o metodolog$a de desarrollo de software de %&'E( !ntegracin est# basado en un
modelo iterativo L incremental inspirado en el proceso de desarrollo unificado &)P >&ational )nified
Process, 3PacEE7? desarrollado por &ational * perteneciente actualmente a !O. <e dice +ue est# inspirado
en &)P *a +ue est# acomodado de acuerdo a la e.periencia de la organi"acin en el desarrollo de
2
In!ormaci"n o(tenida de la pgina )e( de la organi*aci"n+ http+,,---ordencl
28
www.monografias.com
pro*ectos de ingenier$a de software de acuerdo al conocimiento por parte de sus creadores sobre la
metodolog$a &)P * en parte tambi/n por el conocimiento de estos sobre el modelo de calidad C!. La
metodolog$a consta de tres fases instauradas por %&'E( !ntegracin8 Case de !nicio, Case de Elaboracin
L Construccin * Case de 1ransicin. Estas fases son an#logas a las fases de la metodolog$a &)P.
La Case de Elaboracin L Construccin se presenta como una sola fase en los modelos debido a +ue
presenta m#s $tems en com0n +ue diferentes, pero como metodolog$a de desarrollo es tratada en fases
diferentes al igual +ue en el &)P, por lo cual impl$citamente se puede decir +ue la metodolog$a de %&'E(
!ntegracin se reali"a en cuatro fases. En cada una de estas se desarrollan seis disciplinas de !ngenier$a8
'escribir el Problema de (egocio, Especificar &e+uerimientos de la <olucin, &eali"ar ;n#lisis * 'ise-o de
la <olucin, 'esarrollar <olucin <ist/mica, ;segurar Correctitud * Cuncionalidad de la <olucin *
'esplegar <olucin, adem#s de tres procesos transversales * de apo*o a estas disciplinas en cual+uiera de
las tres fases, los cuales son8 ;dministracin de &e+uerimientos, &evisin de Pares * Pruebas de <oftware.
En este documento se describir#n las tres fases separadamente mediante un diagrama )L,
describiendo las disciplinas presentes en cada fase, los procesos, actividades a reali"ar, entradas *
artefactos generados para cada una de ellas. En los casos de las disciplinas de la fase +ue re+uieran de
an#lisis adicional por su complejidad, se detallar# su comportamiento en un diagrama de actividades
reali"ando la descripcin respectiva. Las l$neas de color negro corresponden al flujo de actividades +ue se
reali"an en la disciplina * las de color a"ul al flujo de artefactos utili"ados o generados en la misma. ;dem#s
se describir#n los artefactos utili"ados * generados en el proceso de desarrollo, adem#s de los actores
responsables de cada uno de ellos * finalmente de describir#n los tres procesos de apo*o a las disciplinas
*a mencionados.
29
www.monografias.com
Fase de Inicio
Es la fase +ue da por iniciado un pro*ecto. 'urante esta fase se debe establecer el caso de negocio para el
sistema * se debe delimitar el alcance del pro*ecto. El diagrama de la Cigura A es el +ue modela esta fase *
la disciplina resaltada en gris tiene un diagrama de actividades adicional debido a su complejidad.
Figura $< Fase de Iniio
9ombre8 'escribir el Problema de (egocio
,rte)atos de 5ntrada8 Oases de Licitacin, Contrato * ;ne.os.
,rte)atos de /alida8 Conceptos del 'ominio, Proceso de (egocio, =isin del <istema.
,tores In0olurados8 ;nalistas, Pefe de Pro*ecto, <ta2eholders.
"esripi%n8
; partir de lo estipulado en las Oases de Licitacin, en los Contratos * ;ne.os * por medio de
entrevistas personales se pretende generar la =isin del <istema +ue tiene el cliente. Los analistas junto
con el Pefe de Pro*ecto deben identificar los principales <ta2eholders del pro*ecto * recoger sus
visiones particulares sobre cmo el nuevo sistema los afectar# en su +uehacer cotidiano >+u/ esperan
de /l * cmo piensan interactuar con /l?. <e deben adem#s identificar todos los procesos, conceptos *
relaciones entre ellos +ue estar#n dentro del dominio del problema del sistema. Para ello lo primero +ue
se debe reali"ar es obtener una visin general de la empresa cliente, de sus procesos de negocio claves
* de sus necesidades * dificultades +ue presenta en la actualidad. ;dem#s de obtener los procesos de
negocio, estos se deben anali"ar identificando sus entradas, salidas, procedimientos internos, actores
participantes * el entorno en el +ue se ejecutan generando de este estudio los 'iagramas de Procesos,
los cuales identifican cmo el cliente reali"a actualmente sus actividades.
9ombre8 Especificar &e+uerimientos de la solucin
,rte)atos de 5ntrada8 Oases de Licitacin, Contrato * ;ne.os, Concepto de 'ominio, Proceso de
(egocio, 'escripcin de la <olucin.
,rte)atos de /alida8 &e+uerimiento original ofrecido, &e+uerimiento de (egocio, Criterios de
;ceptacin, &e+uerimiento de <istema, &e+uerimientos Cuncionales, &e+uerimientos (o Cuncionales.
,tores In0olurados8 ;nalistas, Pefe de Pro*ecto, <ta2eholders
"esripi%n >ver Cigura B?
30
www.monografias.com
En funcin de las Oases de Licitacin * de reuniones informales con el cliente, se busca encontrar la
respuesta a la pregunta Z+u/ debe hacer el sistema[
En esta disciplina se deben compatibili"ar los deseos del cliente * los alcances contractuales
ofrecidos con lo +ue se puede lograr sistemati"ar de acuerdo a las capacidades tecnolgicas tanto del
cliente como de %&'E( !ntegracin. Para ello, se registran a+uellos re+uerimientos planteados
directamente por el cliente como &e+uerimientos de (egocio. Estos conforman la primera forma de
re+uerimientos para el pro*ecto. Esta lista debe permanecer invariable por el resto del pro*ecto como
registro de las necesidades originales del cliente. Luego se identifican a+uellos re+uerimientos +ue
fueron originalmente ofrecidos en la 'escripcin de la <olucin, desarrollada en la propuesta del
pro*ecto, * en el contrato firmado con el cliente. <obre los re+uerimientos originales ofrecidos, se les
debe relacionar con a+uellos &e+uerimientos de (egocio a los +ue est/n dando respuesta. En funcin
de estas relaciones se deben identificar a+uellos re+uerimientos de negocio +ue no est/n ofrecidos *
a+uellos re+uerimientos ofrecidos +ue no obedecen a ning0n re+uerimiento de negocio identificado *
generar riesgos asociados a estas diferencias. En el caso de &e+uerimientos de (egocio +ue no se
ha*an ofrecido, estos se deben dejar en claro al cliente para lograr un acuerdo en cuanto a +ue no se
debe esperar dicha funcionalidad o a +ue el tama-o del pro*ecto ofrecido ha cambiado por lo tanto se
debe clasificar como cambio. En el caso de los re+uerimientos ofrecidos +ue no responden a ning0n
&e+uerimiento de (egocio se deben tener en cuenta +ue puede +ue no sean necesarios para el cliente
* por lo tanto se pueden descartar previo acuerdo con todas las partes involucradas.
31
www.monografias.com
Figura &< 5spei)iar Re#uerimientos de la solui%n
32
www.monografias.com
La lista de &e+uerimientos originales ofrecidos permanece invariable como registro del l$mite
comprometido del sistema. Cinalmente se genera una lista definitiva con todos los &e+uerimientos del
<istema, los cuales deben estar relacionados por lo menos con uno de los re+uerimientos ofrecidos. Lo
+ue se debe lograr es identificar * acotar los l$mites de cada re+uerimiento * los actores involucrados.
Los &e+uerimientos de <istema deben adem#s estar relacionados con a+uellos Procesos de (egocio
+ue van a sistemati"ar * con a+uellos Conceptos de 'ominio con los +ue tendr#n +ue lidiar. Cual+uier
proceso * concepto +ue +uede sin relacionar con alg0n re+uerimiento de sistema se considerar# fuera
del dominio del sistema * debe +uedar apropiadamente registrado.
Como prueba final se debe comprobar +ue cada uno de los &e+uerimientos originales ofrecidos
+ue se pretenden implementar est/ siendo reali"ado por un &e+uerimiento de <istema * +ue el 955W de
los &e+uerimientos de <istema est/n dando cumplimiento a por lo menos uno de los &e+uerimientos
originales ofrecidos. Los &e+uerimientos de <istema +ue no est/n cumpliendo re+uerimientos ofrecidos
dan cuenta de cambios en el tama-o del sistema +ue se piensa desarrollar en relacin al +ue se ofreci.
&e+uerimientos originales +ue no est/n siendo reali"ados por &e+uerimientos de <istema dan cuenta
de posibles omisiones de funcionalidad comprometida en el sistema a ser desarrollado * +ue luego
podr$an ser objetadas por los clientes.
9ombre8 &eali"ar ;n#lisis * 'ise-o de la <olucin
,rte)atos de 5ntrada8 'escripcin de la solucin, =isin del <istema, &e+uerimiento de <istema
,rte)atos de /alida8 Planteamiento de ;r+uitectura !nicial
,tores In0olurados8 ;r+uitecto
"esripi%n8
En funcin de los re+uerimientos identificados el ar+uitecto del pro*ecto constru*e un Planteamiento de
;r+uitectura !nicial, identificando mdulos * componentes principales * las soluciones tecnolgicas
asociadas a cada uno. <e debe determinar adem#s cu#les componentes de la ar+uitectura son a+uellos
+ue tienen ma*or riesgo de desarrollo.
9ombre8 'esarrollar <olucin <ist/mica
,rte)atos de 5ntrada8 Planteamiento de ;r+uitectura !nicial
,rte)atos de /alida8 Prueba de Concepto
,tores In0olurados8 'esarrollador
"esripi%n8
Con el Planteamiento de ;r+uitectura !nicial *a reali"ado se debe determinar si ha* aspectos del sistema
+ue re+uieran una prueba de concepto de la solucin planteada para asegurar la factibilidad de la
misma. <i se determina +ue son necesarias una o m#s pruebas de concepto, estas se desarrollan de
acuerdo a la importancia de cada una.
9ombre8 ;segurar Correctitud * Cuncionalidad de la <olucin
,rte)atos de 5ntrada8 &e+uerimiento original ofrecido, =isin del <istema, Prueba de Concepto
,rte)atos de /alida8 (.;.
,tores In0olurados8 Pefe de Pro*ecto, ;r+uitecto.
"esripi%n8
=erificar +ue las Pruebas de Concepto se ajusten a lo ofrecido * +ue concuerde con la =isin del
33
www.monografias.com
<istema +ue tiene el cliente. Esta verificacin generalmente involucra una revisin de pares con otro
ar+uitecto con el fin de e.aminar la solucin planteada por el ar+uitecto del pro*ecto * proponer cambios
o mejoras a /sta.
9ombre8 'esplegar <olucin
,rte)atos de 5ntrada8 Prueba de Concepto
,rte)atos de /alida8
,tores In0olurados8 Pefe de pro*ecto, ;r+uitecto, <ta2eholders
"esripi%n8
'e ser necesario se pueden desplegar en un ambiente temporal algunas de las pruebas de concepto
verificadas para ser mostradas a los <ta2eholders interesados * demostrar su correctitud * funcionalidad
ante ellos.
34
www.monografias.com
Fase de Elaboracin Construccin
La Case de Elaboracin L Construccin tiene por objetivo establecer una base slida de la ;r+uitectura de
<oftware a partir del an#lisis * dise-o de los re+uerimientos, para luego implementar el sistema en base a
estos dise-os * ar+uitectura planteados. En el diagrama de la Cigura 6 se modela esta fase, destacando con
gris las disciplinas +ue por su complejidad presentan un diagrama de actividades adicional para detallar su
comportamiento.
Figura (< Fase de 5laborai%n F Construi%n
9ombre8 'escribir el Problema de (egocio
,rte)atos de 5ntrada8 =isin del <istema, Concepto de 'ominio, Proceso de (egocio
,rte)atos de /alida8 (. ;.
,tores In0olurados8 ;nalista
"esripi%n8
<e revisan los documentos de =isin del <istema, Procesos de (egocio * Concepto de 'ominio en
t/rminos de los re+uerimientos +ue se +uieren atacar. <e pueden reali"ar correcciones menores a estos
documentos cuando corresponda, en funcin del an#lisis +ue se reali"a en esta etapa de vida del
pro*ecto.
9ombre8 Especificar &e+uerimientos de la solucin
,rte)atos de 5ntrada8 Planteamiento de ;r+uitectura !nicial, &e+uerimiento de <istema, ;r+uitectura
del <istema
,rte)atos de /alida8 Criterios de ;ceptacin, &e+uerimiento de <istema, Prototipo de <istema,
ecanismos de 'ise-o >Patrones?
,tores In0olurados8 ;nalistas, ;r+uitecto, <ta2eholders, Pefe de Pro*ecto
"esripi%n >ver Cigura D?8
La diferencia entre las fases de Elaboracin * Construccin radica +ue durante la Elaboracin se atacan
los re+uerimientos de ar+uitectura m#s importantes, +ue dar#n como resultado la ma*or parte de los
mecanismos de dise-o del sistema.
35
www.monografias.com
<obre el conjunto de &e+uerimientos de <istema +ue se +uieren atacar se deben detallar por
completo los antecedentes necesarios para comprender * acotar +u/ es lo +ue debe hacer cada parte
del sistema, indicando los escenarios principales, secundarios * las restricciones. Esto inclu*e la
reali"acin de prototipos no funcionales, +ue sirvan tanto para mostrar al cliente una vista previa del
sistema como para la fase de dise-o donde la interfa" se debe dise-ar completamente.
Figura +< 5spei)iar Re#uerimientos de la solui%n
<e debe determinar +ue los &e+uerimientos de <istema est/n cumpliendo con los re+uerimientos
ofrecidos * +ue no se re+uiere m#s de lo originalmente ofrecido del sistema. Cual+uier desviacin de
estas l$neas debe ser debidamente controlada. 1ambi/n se deben revisar los Criterios de ;ceptacin de
los re+uerimientos con el cliente con los analistas encargados * con analistas +ue no sean parte del
pro*ecto por medio de una revisin de pares * si e.iste una modificacin en los re+uerimientos tambi/n
se debe modificar este documento con la debida aprobacin del cliente. Luego el ar+uitecto debe
determinar si los mecanismos de dise-o definidos alcan"an para cubrir estos re+uerimientos si se deben
generar nuevos mecanismos o si se deben adaptar los antiguos. Esto debiese darse solo en la fase de
la Elaboracin *a +ue durante la Construccin todos los problemas deben haber sido previamente
atacados * por tanto no debiese surgir la necesidad de crear nuevos mecanismos para los mismos
problemas.
9ombre8 &eali"ar ;n#lisis * 'ise-o de la <olucin
,rte)atos de 5ntrada8 Planteamiento de ;r+uitectura !nicial, ecanismos de 'ise-o >Patrones?,
Prototipo de <istema, &e+uerimiento de <istema, ;r+uitectura del <istema
,rte)atos de /alida8 ;r+uitectura del <istema, ecanismos de !mplementacin, Especificacin de
'ise-o
,tores In0olurados8 ;nalista, ;r+uitecto
"esripi%n >ver Cigura E ?8
El objetivo +ue se intenta alcan"ar es de lograr una definicin t/cnica de cmo debe construirse el
sistema. Esta definicin debe contemplar todas las decisiones a tomar al momento de construir la
36
www.monografias.com
solucin, inclu*endo aspectos de ar+uitectura, de dise-o particular, etc. En este conte.to el dise-o
e.iste como un facilitador para transformar los re+uerimientos en cdigo ejecutable, conteniendo las
gu$as necesarias para lograr la fabricacin de la aplicacin.
'espu/s de reali"ar el an#lisis de los re+uerimientos se deben aplicar los mecanismos de
dise-o establecidos * junto a los prototipos no funcionales desarrollados en la disciplina anterior se debe
producir la Especificaciones de 'ise-o para cada caso tomando en cuenta la ar+uitectura planteada
para el sistema para poder definir e.actamente cmo el sistema va a producir el comportamiento
definido. La obtencin de la Especificacin de 'ise-o de la aplicacin posee las ventajas de +ue provee
una mejor visuali"acin de las dependencias * del uso de los componentes, algo esencial al momento
de tener +ue reali"ar una modificacinK lo mismo trae a su ve" la desventaja de +ue los dise-os se
deben mantener * esta mantencin debe reali"arse junto con la del cdigo fuente, si se espera
beneficiarse posteriormente de estos planos de dise-o.
; medida +ue se van dise-ando los componentes del sistema se debe ir completando la
;r+uitectura del <istema con m#s detalle. ;l finali"ar la fase de Elaboracin se debiera tener un plano
completo del sistema, *a +ue a este punto es posible predecir la cantidad * los tipos de componentes
+ue generar# el sistema. 1ambi/n en este punto deben generarse los mecanismos de implementacin
para cada mecanismo de dise-o establecido +ue a0n no tenga definida su forma de implementar.
Figura -< Reali;ar ,nAlisis y "iseDo de la /olui%n
9ombre8 'esarrollar <olucin <ist/mica
,rte)atos de 5ntrada8 ;r+uitectura del <istema, Prototipo de <istema, Especificacin de 'ise-o,
ecanismos de !mplementacin
,rte)atos de /alida8 Pruebas )nitarias, Componente de <oftware
,tores In0olurados8 'esarrollador, ;nalista
"esripi%n8
El objetivo principal es producir las pie"as de cdigo especificadas de la manera m#s eficiente * efica"
37
www.monografias.com
posible. Los desarrolladores deben tomar las Especificaciones de 'ise-o * los Prototipos del <istema *,
luego de revisarlos, debe generar los componentes de cdigo +ue sean necesarios de acuerdo a la
especificacin * siguiendo los mecanismos de implementacin. Punto con la construccin de cada
componente se deben generar Pruebas )nitarias para las mismas +ue aseguren su correcto
comportamiento. Para ello estos deben conocer en profundidad la herramienta de desarrollo * estar
familiari"ados con el lenguaje utili"ado en las especificaciones.
,rte)atos de 5ntrada8 &e+uerimiento de <istema, Especificacin de 'ise-o, Prototipo de <istema,
Componente de <oftware, Criterios de ;ceptacin
,rte)atos de /alida8 Pruebas de Cuncionalidad, !ncidencias
,tores In0olurados8 ;nalista, 'esarrollador, 1ester
"esripi%n >ver Cigura 95?
Esta disciplina tiene por objetivos asegurar dos cosas8 +ue se est# constru*endo la pie"a adecuada para
el trabajo * +ue dicha pie"a est# construida de la manera correcta.
En primera instancia se deben elaborar pruebas funcionales para los re+uerimientos +ue est#n
siendo desarrollados. <e debe tener en cuenta tanto el &e+uerimiento de <istema * su prototipo como la
Especificacin de 'ise-o para generar la prueba funcional +ue est/ probando todos los escenarios
necesarios para lograr la ma*or cobertura posible del cdigo. ;l generar la prueba se deben tener en
cuenta adem#s los Criterios de ;ceptacin definidos por el cliente de manera de +ue las pruebas
funcionales aseguren cobertura de estos criterios.
Las pruebas son ejecutadas por un actor no involucrado en el an#lisis ni desarrollo del
componente con el objetivo de generar !ncidencias cuando los resultados esperados no concuerdan con
los obtenidos, para +ue estos puedan ser corregidos por los desarrolladores * luego las pruebas ser
ejecutadas nuevamente hasta lograr un resultado satisfactorio, es decir, el cumplimiento de los Criterios
de ;ceptacin.
38
www.monografias.com
Figura 1.< ,segurar Corretitud y Funionalidad de la /olui%n
,rte)atos de 5ntrada8 ;r+uitectura de <istema, Componente de <oftware.
,rte)atos de /alida8 =ersin desplegada del sistema, 'ocumentacin de 'espliegue.
,tores In0olurados8 ;r+uitecto, !ntegrador
"esripi%n8
En el despliegue se debe instalar o asegurar la instalacin de los componentes de software
desarrollados en los ambientes computacionales +ue corresponda. Lo relevante en esta etapa es tener
una versin funcional del sistema desarrollado * no mdulos sueltos +ue no se puedan probar ni instalar.
Es importante adem#s actuali"ar la documentacin con los nuevos componentes desplegados. <e
considera 0til tener una versin desplegada desde los primeros componentes construidos, *a +ue para
cuando se termine el desarrollo del sistema estos componentes *a habr#n estado en produccin por un
tiempo, reduciendo la cantidad de errores potenciales no encontrados.
39
www.monografias.com
Fase de Transicin
La Case de 1ransicin tiene por finalidad asegurar +ue el sistema desarrollado est/ disponible para los
usuarios finales. Esto implica +ue se lleven a cabo las pruebas de certificacin del software en el ambiente
de control de calidad * se genere adem#s la documentacin final necesaria para su utili"acin en
produccin. En el diagrama de la Cigura 99 se presenta modelada esta fase.
Figura 11< Fase de 2ransii%n
; esta altura todos los procesos se encuentran detallados en la disciplina de 'escribir el Problema
de (egocio, todos los re+uerimientos *a han sido completamente detallados * anali"ados en la disciplina de
Especificar &e+uerimientos de la <olucin, el dise-o completo de la aplicacin debe estar completo en la
disciplina de &eali"ar ;n#lisis * 'ise-o de la <olucin * todos los componentes necesarios *a deben haber
sido desarrollados en la disciplina 'esarrollar <olucin <ist/mica, por lo +ue no se entrar# en detalle en
estas disciplinas para su documentacin.
,rte)atos de 5ntrada8 Pruebas de ;ceptacin
,rte)atos de /alida8 !ncidencias.
,tores In0olurados8 Pefe de Pro*ecto, Cliente
"esripi%n8
;c# se deben ejecutar las pruebas de aceptacin definidas por el cliente. Cual+uier inconformidad
genera una incidencia +ue debe ser revisada. La conformidad de las pruebas de aceptacin es un hito
importante +ue debe ser registrado.
,rte)atos de 5ntrada8 Componente de <oftware, =ersin desplegada del sistema
,rte)atos de /alida8 'ocumentacin de 'espliegue, =ersin 9.5.5
,tores In0olurados8 !ntegrador
"esripi%n8
<e genera la primera versin del sistema, en funcin de sus componentes de software construidas *
probadas * de las versiones desplegables +ue se han generado del sistema hasta ese momento. <e
asocia en esta disciplina la generacin de instaladores * de documentacin de instalacin * operacin
necesaria para las personas +ue ser#n luego las encargadas de mantener el sistema operando dentro
de los rangos de rendimiento necesarios. ;dem#s se debe reali"ar el despliegue final sobre el ambiente
de produccin de la primera versin del sistema * se hace una copia de esta versin para entrega al
cliente junto con la documentacin final.
40
www.monografias.com
,rte)atos
Los artefactos generados * utili"ados en los diagramas de procesos mostrados anteriormente ser#n
detallados a continuacin. 'entro de este detalle se inclu*en8
9ombre8 (ombre utili"ado para referirse al artefacto.
2ipo8 <i el artefacto corresponde a un 'iagrama de Clase, 'iagrama de Casos de )so, 'iagrama de
Componentes, 'iagrama de 'espliegue, 'iagrama de ;ctividades, 'ocumento o Cdigo, Ejecutable.
,tores Responsables8 Persona, rol u organi"acin encargada de la produccin * mantencin del
artefacto. 1$picamente es +uien lo genera.
"esripi%n8 'escribe los objetivos * usos del artefacto.
9ombre8 Oases de Licitacin
2ipo8 'ocumento
,tores Responsables8 Cliente
"esripi%n
Las bases de Licitacin deber ser revisadas en busca de re+uerimientos espec$ficos con respecto a la
entrega de productos al cliente.
9ombre8 Contrato * ;ne.os
2ipo8 'ocumento
,tores Responsables8 %&'E( !ntegracin * Cliente.
"esripi%n
El contrato es un acuerdo pactado entre %&'E( !ntegracin * la empresa cliente en el cual se definen
una serie de compromisos * responsabilidades entre ambas partes +ue deben ser cumplidas. Los
;ne.os son documentos e.tra como minutas de reuniones con el cliente, entrevistas, etc.
9ombre8 'escripcin de la <olucin
2ipo8 'ocumento
;ctores responsables8 E+uipo de Pro*ecto
"esripi%n
Corresponde a una breve descripcin de la <olucin. 'ebe contener8
G Planteamiento de la ar+uitectura8 Consiste en un diagrama de subsistemas o componentes estimados
a partir de los re+uerimientos detectados * un diagrama de despliegue +ue contenga los re+uerimientos
de plataforma, ubicacin de componentes * herramientas.
G 'ecisiones respecto a tecnolog$as, framewor2s, motores de integracin u otros componentes de
terceros +ue se ha*a decidido utili"ar.
9ombre8 =isin del <istema
2ipo8 'iagrama de Casos de )so
,tores Responsables8 Pefe de Pro*ecto
"esripi%n
<e busca concentrar en un solo lugar la visin original +ue tiene cada uno de los <ta2eholders
respecto al sistema. 'ebe contener los objetivos principales * secundarios +ue el sistema debe cumplir *
una descripcin lo m#s detallada posible del problema de negocio +ue debe resolver. La visin del
sistema una ve" establecida +ueda congelada para poder tener en todo momento una referencia a lo
+ue originalmente el sistema buscaba resolver.
9ombre8 Concepto de 'ominio
2ipo8 'iagrama de Clases
,tores Responsables8 Pefe de Pro*ecto * ;nalista
"esripi%n
<e e.presa en t/rminos de una clase. !nclu*e la definicin del concepto +ue se +uiere representar * sus
principales atributos, +ue a su ve" son definidos como atributos de esa clase. ;dem#s inclu*e las
relaciones entre los conceptos en forma de asociaciones con sus diversos estereotipos. ;l conjunto
completo de conceptos con sus relaciones se le llama 'iagrama de 'ominio *a +ue representa todos los
conceptos involucrados de alguna manera en el #mbito o dominio del problema.
41
www.monografias.com
9ombre8 Proceso de (egocio
2ipo8 'iagrama de ;ctividades
,tores Responsables8 Pefe de Pro*ecto * ;nalista de la C#brica de <oftware
"esripi%n
!nclu*e los procesos junto con los eventos +ue los gatillan, los trabajadores * objetos involucrados en la
organi"acin * los #mbitos en los +ue se estima +ue el sistema tenga influencia. Los procesos deben
estar debidamente descritos con el nivel de detalle +ue correspondaK se espera +ue puedan relacionarse
en t/rminos de sus entradas * salidas. Esto para poder a futuro identificar las partes de la aplicacin +ue
van a ser sistemati"adas. Los conceptos mencionados en los procesos como entradas, salidas, etc.
deben estar definidos en los conceptos de dominio, para asegurar un entendimiento de lo +ue involucra
el generar como salida o recibir como entrada el objeto al +ue se hace referencia.
9ombre8 &e+uerimiento original ofrecido
2ipo8 'ocumento
,tores Responsables8 ;nalista
"esripi%n
E.presados en la forma original en +ue fueron ofrecidos al cliente cuando este acept el pro*ecto.
Ouscan mantener una referencia de lo +ue se ofreci originalmente * conocer cu#l era el tama-o del
pro*ecto al momento de comen"arlo.
9ombre8 &e+uerimiento de (egocio
2ipo8 'ocumento
,tores Responsables8 ;nalista
"esripi%n
<e especifican en forma de prosa o de forma te.tual a como aparecen en los documentos originales
>sean bases de licitacin, documentos de reuniones, etc.?. Ouscan preservar en un artefacto los deseos
* necesidades originales del cliente para con el sistema al momento de proponer una primera solucin.
9ombre8 &e+uerimiento de <istema
2ipo8 'iagrama de Casos de )so
"esripi%n
'eben incluir a los actores involucrados en el sistema, los casos de uso con sus descripciones,
escenarios, restricciones * finalmente todo a+uello +ue pueda dar una idea completa sobre +u/ debe
hacer el sistema.
Los &e+uerimientos de <istema deben estar relacionados con a+uellos Procesos de (egocio +ue deben
ser automati"ados * con a+uellos Conceptos de (egocio con los cuales deben interactuar. ;dem#s
deben satisfacer al menos uno de los re+uerimientos ofrecidos, en caso contrario se considerar#n como
re+uerimientos nuevos.
9ombre8 Criterios de ;ceptacin
2ipo8 'ocumento
"esripi%n
Los criterios definidos por el cliente para dar por satisfecho el cumplimiento de cada re+uerimiento.
4eneralmente escritos en prosa. Esto puede variar desde la definicin de una prueba hasta unos $ndices
generales de funcionamiento +ue se deben poder comprobar con la reali"acin de una prueba funcional.
9ombre8 &e+uerimientos Cuncionales
2ipo8 'ocumento
"esripi%n
Los re+uerimientos funcionales representan las caracter$sticas fundamentales del producto finalK
constitu*en una e.presin del tama-o del pro*ecto as$ como la base de toda su planificacin posterior.
La volatilidad +ue e.perimenten durante el transcurso del pro*ecto debe ser rigurosamente monitoreada
por el Pefe de Pro*ecto, a fin de evitar impacto en el desarrollo normal del trabajo. Es importante vigilar
+ue los re+uerimientos se encuentren siempre dentro del #mbito definido para el pro*ecto. En caso
42
www.monografias.com
contrario, se deber# activar el procedimiento de control de cambios.
9ombre8 &e+uerimientos (o Cuncionales
2ipo8 'ocumento
"esripi%n
Estos re+uerimientos est#n asociados generalmente a caracter$sticas cualitativas del producto final,
e.presadas en t/rminos amplios * sin criterios de aceptacin claros. 'ichos re+uerimientos pueden
representar una importante fuente de riesgo si no se logra acotar su alcance a un nivel claro * objetivo.
Para tal efecto, el Pefe de Pro*ecto deber# intentar, con la aprobacin del cliente, transformar los
criterios cualitativos en cuantitativos.
9ombre8 Prototipo de <istema
2ipo8 Cdigo
,tores Responsables8 'esarrollador, ;nalista, ;r+uitecto
"esripi%n
Los prototipos buscan dar una vista previa de cmo debiera verse el <istema una ve" +ue est/
construido. Por lo general los prototipos no deber$an ser funcionales, a menos +ue el costoMbeneficio
justifi+ue +ue se gaste esfuer"o en construirlos funcionales.
9ombre8 Planteamiento de ;r+uitectura !nicial
2ipo8 'iagrama de 'espliegue M 'iagrama de Componentes
,tores Responsables8 ;r+uitecto
<e identifican en primera instancia mdulos * componentes principales * las posibles soluciones
tecnolgicas asociadas a cada uno de ellos, adem#s de determinar cu#les son a+uellos componentes
m#s riesgosos.
9ombre8 ;r+uitectura del <istema
2ipo8 'iagrama de Componentes
,tores Responsables8 ;r+uitecto
"esripi%n
La ;r+uitectura del <istema involucra un plano en t/rminos de pa+uetes, mdulos * componentes de
cada uno de los elementos del sistema. Esto artefacto se va elaborando a medida +ue se dise-a el
sistema, *a +ue es a medida +ue se ataca cada problema +ue aparecen las componentes +ue los van a
resolver. Es posible +ue al finali"ar la fase de Elaboracin se pueda lograr un plano terico de cmo
debiera ser la ;r+uitectura del <istema con una baja incertidumbre, *a +ue para esa altura se debiese
haber terminado de estereotipar todos los componentes del sistema * *a es posible, en funcin de los
re+uerimientos de los componentes faltantes, estimar la forma * tama-o +ue ellos tendr#n.
9ombre8 ecanismos de 'ise-o >Patrones?
2ipo8 'ocumento
;ctores &esponsables8 ;r+uitecto
"esripi%n
Los mecanismos de dise-o son instrucciones de cmo se debe dise-ar cada tipo de problema
identificado. !ndican en forma de instructivo cu#les son los patrones de dise-o +ue se deben aplicar *
cu#les debieran ser los resultados en cada caso.
9ombre8 Especificacin de 'ise-o
2ipo8 'iagrama de Clases
,tores Responsables8 ;nalista, ;r+uitecto
"esripi%n
Las especificaciones de dise-o consisten en diagramas de clases donde aparecen claramente
estereotipadas los distintos componentes, descritos sus atributos, m/todos * las relaciones de
dependencia entre ellos. En el caso de los atributos se re+uiere +ue se especifi+ue su tipo * las
validaciones b#sicas asociadas al mismo. En el caso de los m/todos, se re+uiere +ue se especifi+ue la
firma * el comportamiento +ue tiene el mismoK en caso +ue sea demasiado complejo se debe crear un
43
www.monografias.com
diagrama de actividades dentro de la clase +ue describa el comportamiento del mismo * +ue represente
su flujo de actividades. Cada componente debe estar e.pl$citamente reali"ando al menos uno de los
&e+uerimientos de <istema.
9ombre8 ecanismos de !mplementacin
2ipo8 'ocumento M Cdigo
,tores Responsables8 ;r+uietecto
"esripi%n
En estrecha relacin con los ecanismos de 'ise-o, *a +ue se debe establecer para cada uno de ellos
la forma de transformar dicha especificacin a cdigo.
9ombre8 Prueba de Concepto
2ipo8 Cdigo
,tores Responsables8 ;r+uitecto, 'esarrollador
"esripi%n8
Corresponde a un pe+ue-o pro*ecto de desarrollo +ue busca probar la factibilidad de una solucin para
un problema en particular +ue generalmente es innovadora * no e.iste e.periencia previa con esa
tecnolog$a o l$nea de solucin en general.
La prueba de concepto se da por concluida cuando +ueda demostrado, por una aplicacin o alg0n tipo
de demostracin, +ue la solucin propuesta cumple con necesidades funcionales +ue se re+uieren de
ella * con las restricciones de escalabilidad, performance, robuste", etc. asociadas con el pro*ecto.
9ombre8 Componente de <oftware
2ipo8 Cdigo
,tores Responsables8 'esarrollador
"esripi%n
dulo software desarrollado, ad+uirido o reutili"ado +ue posee una funcionalidad definida * +ue cumple
con al menos un &e+uerimiento de <istema.
9ombre8 Pruebas )nitarias
2ipo8 Cdigo
,tores Responsables8 'esarrollador, ;nalista
"esripi%n
Pruebas de caja blanca dise-adas para probar un componente de software en particular, generalmente
apo*adas por la misma herramienta de desarrollo del componente. <on generadas por los
desarrolladores con apo*o de los analistas en a+uellos aspectos +ue no est/n indicados en la
especificacin.
9ombre8 Pruebas de Cuncionalidad
2ipo8 'iagrama de ;ctividades
;ctores &esponsables8 1ester
"esripi%n
Estas pruebas est#n orientadas a probar la funcionalidad de un conjunto de componentes en forma de
escenarios de operacin para comprobar el correcto funcionamiento del sistema. Las Pruebas de
Cuncionalidad dependen de la funcionalidad * del sistema +ue se +uiere probar.
9ombre8 Pruebas de ;ceptacin
2ipo8 'ocumento
"esripi%n
Es un conjunto de pruebas +ue una ve" ejecutadas aseguran la conformidad del cliente con el producto.
Estas pruebas deben estar descritas en el formato de pruebas definido para el pro*ecto o estar
acompa-adas de una gu$a de accin +ue indi+ue cmo reali"arlas.
Las pruebas de aceptacin debieran ser ejecutadas por un ente distinto al cliente * al e+uipo del
pro*ecto, pero t$picamente las ejecuta el mismo cliente o el mismo e+uipo de pruebas del pro*ecto,
44
www.monografias.com
previo acuerdo por las dos partes.
9ombre8 !ncidencias
2ipo8 Entidad de (egocio
"esripi%n
)na !ncidencia es un hecho +ue no est# considerado en la planificacin del pro*ecto, *a sea una
necesidad, problema o re+uerimiento +ue no estaba considerado como parte del pro*ecto * +ue surge
en forma inesperada. 1ambi/n puede ser un riesgo +ue estaba incluido en el Plan de ;dministracin de
&iesgos +ue se ha materiali"ado, en cu*o caso se debe reali"ar el plan de contingencia all$ definido.
)n evento de este tipo puede nacer del mismo pro*ecto, puede ser un re+uerimiento de otro pro*ecto o
de otra #rea de negocios * puede afectar los recursos * el cronograma de actividades del pro*ecto.
)na incidencia debe entenderse como una orden de servicio +ue debe ser atendida por la f#brica de
software. En la resolucin de una incidencia pueden participar m#s de una persona natural e incluso una
incidencia puede llegar a dar origen a un pro*ecto en s$ +ue debe abordarse en forma separada.
9ombre8 =ersin 9.5.5
2ipo8 Cdigo
,tores Responsables8 !ntegrador
"esripi%n
Corresponde a la primera versin del sistema completo +ue *a ha pasado los criterios de aceptacin
planteados por el cliente.
9ombre8 =ersin desplegada del sistema
2ipo8 Cdigo
"esripi%n
)na versin parcial del sistema +ue es funcional * desplegable, dado un conjunto de re+uerimientos de
plataforma determinados +ue se encuentran indicados en la documentacin de despliegue asociada a
esta versin.
9ombre8 'ocumentacin de 'espliegue
2ipo8 'iagrama de 'espliegue
"esripi%n
Esta documentacin debe incluir descripciones de los nodos donde ser#n desplegadas las componentes
del sistema >inclu*endo las configuraciones necesarias para asegurar el funcionamiento del sistema?, la
lista de componentes desplegadas indicando en +u/ nodo se han desplegado, los procedimientos de
respaldo * recuperacin >todos los pasos * antecedentes a tener en cuenta en caso de un respaldo o
recuperacin van juntos por la dependencia +ue tienen uno del otro? * los procedimientos de mantencin
necesarios >inclu*e balanceos de carga, inde.acin de las bases de datos, etc.?.
,tores Partiipantes
G Cliente8 Parte responsable de aceptar el producto o de autori"ar el pago de este. Es e.terno al
pro*ecto pero no necesariamente e.terno a la organi"acin. Los clientes son parte de los <ta2eholders.
G Ge)e de Proyeto8 Es el responsable ante la gerencia del desarrollo * mantencin del pro*ecto.
G ,nalista8 !nclu*e a los analistas de re+uerimientos avocados en un pro*ecto.
G ,r#uiteto8 &esponsable de definir la ar+uitectura lgica * tecnolgica +ue ser# usada para el
desarrollo, soporte, mantencin * operacin del <istema.
G "esarrollador8 Corresponde a los programadores del <istema.
G 2ester8 Encargados de hacer las pruebas de los componentes del <istema * del <istema completo.
G Integrador8 &esponsable de unir los componentes separados para formar el <istema completo.
G /taHe>olders8 !nvolucra a todas las personas u organi"aciones +ue son afectados por el <istema.
Puede incluir a miembros del pro*ecto, proveedores, clientes, usuarios finales * otros.
45
www.monografias.com
Proesos de ,poyo
,dministrai%n de Re#uerimientos
El Proceso de ;dministracin de &e+uerimientos permite establecer * mantener un entendimiento com0n
entre el cliente * el pro*ecto acerca de los re+uerimientos +ue ser#n abordados * +ue ser#n el v$nculo
coherente * rastreable +ue une a todo el ciclo de desarrollo. 'icho acuerdo representa la base para estimar,
planificar, ejecutar * controlar las actividades del pro*ecto a trav/s del ciclo de vida.
La ;dministracin de &e+uerimientos comprende actividades relacionadas con la definicin,
clasificacin, asignacin, seguimiento * control de los re+uerimientos durante todo el ciclo de vida de
desarrollo de software. En la Cigura 9: se muestra un diagrama +ue modela el ciclo de actividades de este
proceso.
Figura 12< ,dministrai%n de Re#uerimientos
El proceso se inicia con !ngresar el &e+uerimiento, actividad +ue se modela en la Cigura 9,.
46
www.monografias.com
Figura 13< Ingresar Re#uerimiento
,ti0idad8 ;nali"ar ;ntecedentes e historia de los re+uerimientos del pro*ecto
5ntradas8 Oases de Licitacin, 1/rminos de &eferencia, Propuesta 1/cnica, ail, 'ocumentos ;djuntos
/alidas8 (. ;.
,tores In0olurados8 Pefe de Pro*ecto
"esripi%n8
<e deben anali"ar todos los antecedentes * la historia de los re+uerimientos del pro*ecto, desde +ue se
reali"a la propuesta hasta el momento actual en +ue este se encuentra. Pueden e.istir otros artefactos
de entradaK en el diagrama por simplicidad se se-alan slo algunos t$picamente usados.
,ti0idad8 'eterminar tipo de re+uerimiento
5ntradas8 (. ;.
/alidas8 (. ;.
"esripi%n8
'e esta decisin pueden surgir dos alternativas8
9.G El re+uerimiento es un Cambio de &e+uerimiento.
El re+uerimiento es una modificacin, correccin o simplemente la eliminacin de un re+uerimiento +ue
pertenece a la L$nea Oase vigente * aprobada.
:.G El re+uerimiento es un &e+uerimiento (uevo.
El re+uerimiento no ha sido anali"ado antes, por lo tanto es necesario hacer su estudio detallado.
,ti0idad8 !ngresar !nformacin del Pro*ecto * del re+uerimiento
5ntradas8 (. ;.
/alidas8 &egistro de &e+uerimientos.
47
www.monografias.com
"esripi%n8
La informacin de cada re+uerimiento inclu*e8
Cecha8 Cecha en +ue se reali"a este plan.
!' Pro*ecto8 !dentificacin del pro*ecto.
(ombre Pro*ecto8 (ombre completo del pro*ecto.
&esponsable 4&8 (ombre de la persona responsable de la ;dministracin de los &e+uerimientos.
Case8 (0mero de la fase del mismo pro*ecto. <e genera un nuevo encabe"ado por cada fase del mismo
pro*ecto.
!' LO8 !dentificacin de la L$nea Oase vigente de la fase * el pro*ecto
Cecha inicio LO8 Cecha planificada del comien"o de esta fase, aprobada por C. <i est# en blanco
implica +ue aun no est# definida.
Cecha aprobacin LO8 Cecha de aprobacin de LO utili"ada cuando ha* cambio de LO debido a Control
de Cambios, si est# en blanco implica +ue a0n no se ha modificado la L$nea Oase inicial.
<e actuali"a adem#s el estado del re+uerimiento como I!ngresadoJ.
El &egistro de &e+uerimientos se reali"a en el software Enterprise ;rchitect
,
.
,ti0idad8 Completar o adaptar re+uerimientos predefinidos seg0n aplican al pro*ecto
5ntradas8 4losario * ;*uda. :.6 Corma de llenado del &egistro de &e+uerimientos
/alidas8 &egistro de &e+uerimientos
"esripi%n8
En base a la forma de llenado de los re+uerimientos en el Enterprise ;rchitect se actuali"a los datos en
el sistema, agregando a su ve" ma*or detalle a cada uno, dependiendo del pro*ecto * del re+uerimiento
en s$.
<i e.iste un control de cambios en alg0n re+uerimiento se activa esta actividad, +ue se modela en la
Cigura 9@
3
Enterprise Architect de Sparx Systems. Para cons!tar in"ormaci#n so$re !a herramienta %isite e! sitio&
http&''(((.sparxsystems.com'
48
www.monografias.com
Figura 1!< Control de Cambios
,ti0idad8 Evaluar Control de Cambios
5ntradas8 ;ntecedentes ;sociados al control de cambio, &egistro de &e+uerimiento
/alidas8 &egistro de &e+uerimiento
,tores In0olurados8 Pefe de Pro*ecto, 4erente de Pro*ecto
"esripi%n >=er Cigura 9A?8
49
www.monografias.com
Figura 1$< 50aluar Control de Cambios
El objetivo de esta actividad es evaluar un control de cambios desde el punto de vista de su
complejidad para ser implementado. El proceso se inicia registrando la incidencia de reali"ar el cambio.
<i son varios los cambios involucrados en la misma solicitud se debe sumar todo lo +ue est# contenido
en ella. Para estimar el esfuer"o se recomienda considerar al menos los siguientes aspectos8
G Cantidad de cambios incluidos en la solicitud.
G Complejidad en cuanto a si los re+uerimientos afectan pocas o muchas #reas del pro*ecto, en cuanto a
funciones * a #reas de desarrollo * produccin involucradas >cliente, usuarios, ambiente de desarrollo,
e.plotacin?
G Case del pro*ecto en +ue llega el re+uerimiento. ; ma*or avance del pro*ecto puede ser m#s
complejo incorporar un cambio.
Los niveles de complejidad del cambio son tres8 Complejo, edio * <imple. <e define +ue un
cambio es de nivel complejo si se encuentra en alguna de las siguientes situaciones8
G El n0mero de cambios a los re+uerimientos es ma*or +ue cinco.
G Es necesario un cambio importante en el dise-o.
G El esfuer"o para implementar el cambio es superior a dos d$as.
<e define +ue un cambio de nivel edio cuando no es Complejo, pero si re+uiere an#lisis o
especificacin detallada durante su ejecucin. <e define +ue un cambio es de nivel <imple si no cumple
50
www.monografias.com
,ti0idad8 ;nali"ar Control de Cambios
5ntradas8 ;ntecedentes asociados al Control de Cambios, &egistro de &e+uerimientos
/alidas8 &egistro de &e+uerimientos, Carta 4antt
,tores In0olurados8 Pefe de Pro*ecto, ;nalista
"esripi%n >ver Cigura 9B?8
Figura 1&< ,nali;ar Control de Cambios
El objetivo general de esta actividad es anali"ar en profundidad el alcance de un cambio
solicitado, para efectos de estimar el esfuer"o * costos necesarios para implementarlo, as$ como evaluar
los riesgos asociados
En base a la decisin tomada en el paso anterior, +ue depende de la magnitud de los cambios *
los riesgos +ue se visualicen para el cumplimiento de los objetivos del pro*ecto, se reali"a un Proceso
Cormal de 1oma de 'ecisiones >basado en el #rea de proceso ';& del modelo C!? o se procede
como se describir# a continuacin.
El ;nalista a cargo del Control de Cambio determinar# la necesidad de planificar actividades
espec$ficas dependiendo de la complejidad del cambio anali"ada en la etapa anterior. Esta complejidad
determinar# tambi/n la necesidad de ejecutar las actividades venideras. El Pefe de Pro*ecto debe
actuali"ar la carta 4antt del pro*ecto registrando cambios en los cronogramas de las actividades debido
al cambio.
<e debiesen identificar todos los objetos afectados por el cambio, seleccionar a las personas
51
www.monografias.com
idneas para resolver el cambio, definir cu#les ser#n los artefactos +ue generar# el implementar el
cambio e identificar tambi/n las eventuales inconsistencias con la solucin *a definida +ue provocar# el
cambio. Con todas estas actividades resueltas *a se podr$a actuali"ar el detalle del control de cambio
con su estado, como a su ve" mantener un historial * actuali"ar la tra"abilidad de re+uerimientos.
,ti0idad8 Calcular tama-o * esfuer"o seg0n metodolog$a * tailoring seleccionados para cada disciplina
de la ingenier$a.
5ntradas8 For2 Orea2down <tructure >FO<?.
/alidas8 For2 Orea2down <tructure >FO<?, Estimacin de Esfuer"o, Estimacin de Costo.
,tores In0olurados8 E+uipo responsable de estimar tama-o, esfuer"o, costos * pla"os del pro*ecto.
"esripi%n >=er Cigura 96?8
El objetivo de esta actividad es efectuar estimaciones de tama-o, esfuer"o * costos del pro*ecto, de
acuerdo a la metodolog$a seleccionada, a datos histricos * supuestos. <e debiesen considerar datos
histricos acumulados para ajustar supuestos * validar resultados de estimaciones. <e debiese tambi/n
fundamentar el uso de estos datos histricos seleccionados para las estimaciones * se debe mantener
consistencia en los nombres usados en el &egistro de &e+uerimientos en E; para asegurar tra"abilidad.
1odas las estimaciones e identificaciones, tama-o, esfuer"o * costo principalmente, deben ser
actuali"adas en el For2 Orea2down <tructure >FO<?.
52
www.monografias.com
Figura 1(< Calular tamaDo y es)uer;o segEn metodologa y tailoring seleionados para ada
disiplina de la ingeniera
53
www.monografias.com
,ti0idad8 !ngresar cubicacin * evaluar compromisos
5ntradas8 &esultado de Cubicacin
/alidas8 &egistro de &e+uerimientos, !nforme de Control de Cambios al Cliente
,tores In0olurados8 Ejecutivo Comercial, Pefe de Pro*ecto
"esripi%n >=er Cigura 9D?8
Figura 1+< Ingresar ubiai%n y e0aluar ompromisos

El objetivo de esta actividad es adoptar una posicin definitiva ante el cambio solicitado * formali"ar la
respuesta al cliente.
Luego de actuali"ar la informacin de esfuer"o * costo correspondiente al re+uerimiento tratado,
se procede a revisar, sobre la base del an#lisis de impacto reali"ado * el estado actual del pro*ecto, los
compromisos +ue deben asumirse por el pro*ecto para implementar el cambio solicitado. <i no se reali"a
un cambio por desaprobacin del cliente se elabora una propuesta alternativa * se informa al cliente para
conseguir la aprobacin formal por parte del cliente. <i el cambio es reali"ado se debe generar la
propuesta comercial para el cliente cuando corresponda, * crear una carta de aprobacin formal para el
cambio, +ue debe ser enviada al cliente para su aprobacin.
,ti0idad8 Cormali"ar implementacin
5ntradas8 !nforme de Control de Cambios al Cliente, Carta de &espuesta
54
www.monografias.com
/alidas8 (. ;.
,tores In0olurados8 Cliente, Pefe de Pro*ecto
"esripi%n >=er Cigura 9E?
Figura 1-< Formali;ar implementai%n
El objetivo de esta actividad es formali"ar la implementacin del Control de Cambios a un re+uerimiento.
La informacin del informe de control de cambios preparado para el cliente * la carta de respuesta
enviada al Cliente es revisada por /ste para su aprobacin. Cuando el cambio es aprobado por el cliente
se gestionan las l$neas bases del pro*ecto, tanto las correspondientes a los re+uerimientos como a las de
planificacin * de entregables. Punto con ello se actuali"an los artefactos de gestin +ue correspondan,
de acuerdo a las caracter$sticas e impacto del cambio aprobado * considerando al menos los siguientes8
Carta 4antt, Plan de &iesgos, C#lculo de Esfuer"o, FO< * Plan de Pro*ecto. Cinalmente se debe
comunicar a todas las partes interesadas el alcance del control de cambios, ll#mense e+uipo de
pro*ecto, e+uipo de pruebas, de aseguramiento de la calidad * de administracin de la configuracin. <i
el cambio no es aceptado por el cliente, se debe escalar el caso al nivel de jefatura correspondiente,
ajustando estimaciones de esfuer"o * costos * replanteando las estrategias.
Luego de atacar alg0n posible cambio a los re+uerimientos se reali"a la &evisin de Pares, otro de
los procesos de apo*o a la metodolog$a de desarrollo de %&'E( !ntegracin +ue ser# detallado como
proceso aparte m#s adelante en este documento.
&eali"ada la &evisin de Pares, se ejecuta la actividad modelada con el diagrama +ue *a fue
presentada * detallada en la Cigura 96, para poder reali"ar estimaciones de tama-o, esfuer"o * costos del
pro*ecto de acuerdo a la metodolog$a seleccionada >t$picamente la +ue se est# presentando en este
documento?, de acuerdo a datos histricos de la organi"acin * a supuestos del pro*ecto.
Con los datos de las estimaciones de tama-o, esfuer"o * costos se reali"a la actividad !ngresar
cubicacin * comunicar &e+uerimiento cu*o diagrama se presenta en la Cigura :5
55
www.monografias.com
Figura 2.< Ingresar ubiai%n y omuniar Re#uerimiento
,ti0idad8 Planificacin
5ntradas8 (. ;.
/alidas8 (. ;.
"esripi%n8
La planificacin reali"ada para cada re+uerimiento entrega como resultado las estimaciones de su costo,
esfuer"o * tama-o.
,ti0idad8 !ncorporar informacin de esfuer"o al re+uerimiento +ue corresponda
5ntradas8
/alidas8 &egistro de &e+uerimientos
"esripi%n8
Los datos de cubicacin, ll#mense estimaciones de esfuer"o, tama-o * costo principalmente, son
incorporadas al re+uerimiento correspondiente, siendo a su ve" actuali"adas en la herramienta
Enterprise ;rchitect.
,ti0idad8 &ecopilar informacin de re+uerimientos
5ntradas8 ....PPPXE.Productos * Entregables..ls, ....P'P.Plan de Pro*ecto.doc, ....PPC'E.Calculo
de Esfuer"o..ls, ....PPP;&.Plan ;dministracin de &iesgos..ls
/alidas8 (. ;.
"esripi%n8
<e recopila la informacin almacenada de los re+uerimientos en base a las planillas * documentos
generadas * al registro de re+uerimientos almacenado en Enterprise ;rchitect
,ti0idad8 Enviar 'ocumentacin a grupos involucrados
5ntradas8 (. ;.
/alidas8 U;,C, 1esting, 4erente Pro*ectos, otros roles identificados.
56
www.monografias.com
"esripi%n8
La informacin de los re+uerimientos se env$a a las partes involucradas en el desarrollo del pro*ecto.
57
www.monografias.com
Re0isi%n de Pares
La &evisin de Pares es un t/cnica de testing est#tico definido como un proceso metdico, formal *
estructurado en el cual se e.amina un producto intermedio o final, con el propsito de encontrar * corregir
defectos en forma temprana, e incluso identificar eventualmente cambios re+ueridos para optimi"ar el
funcionamiento de un sistema. Esta revisin puede ser conducida por un par o un e+uipo de pares del autor
del producto con roles * tareas espec$ficas.
El proceso consiste en someter un producto de trabajo al escrutinio de uno o m#s profesionales con
un nivel de conocimiento * e.periencia e+uivalente al del autor del artefacto, de tal manera de poder evaluar
objetivamente su contenido, detectar eventuales falencias * proponer medidas correctivas. Ejemplos de
interlocutores v#lidos para la revisin de pares pueden ser un jefe de pro*ecto, un ar+uitecto de software, un
desarrollador u otro rol dependiendo de las caracter$sticas del artefacto seleccionado.
El proceso de revisin de pares consta de dos actividades como se puede apreciar en la Cigura :9
Figura 21< Re0isi%n de Pares
,ti0idad8 Preparar revisin de pares
5ntradas8 Chec2list de &evisin de Pares, Producto de trabajo a revisar
/alidas8 (. ;.
,tores In0olurados8 Pefe de Pro*ecto, &evisor, ;utor del producto a revisar
"esripi%n >=er Cigura ::?8
58
www.monografias.com
Figura 22< Preparar re0isi%n de pares
El objetivo de esta actividad es efectuar las actividades preparatorias * generar las condiciones para una
revisin de pares. El criterio de entrada es cuando corresponda e.aminar un artefacto del pro*ecto con
esta t/cnica.
En principio de debe convocar al autor del producto a revisar * al revisor designado a una
reunin * en ella se deben e.poner brevemente las caracter$sticas del producto a ser revisado * se
acuerdan criterios b#sicos para reali"ar la revisin de pares, seg0n las caracter$sticas del pro*ecto * del
producto. ;lgunas de las caracter$sticas +ue se deben definir son8 Criterios de entrada * salida, &eglas
de proceso, Pla"os de la revisin. Luego de esto se procede a actuali"ar el chec2list de la &evisin de
Pares con las definiciones reali"adas.
El autor debe seleccionar el material de apo*o +ue se le proveer# al revisor dependiendo del
producto de trabajo a revisar * de las definiciones surgidas de la reunin de coordinacin * finalmente
debe enviar el producto a ser verificado junto con sus antecedentes asociados * cual+uier material de
apo*o 0til para reali"ar la revisin.
,ti0idad8 Ejecutar &evisin de Pares
5ntradas8 Chec2list de &evisin de Pares, Producto de trabajo a revisar
/alidas8 !nforme de observaciones
,tores In0olurados8 Pefe de Pro*ecto, &evisor>es?, ;utor>es?
"esripi%n >=er Cigura :,?8
59
www.monografias.com
Figura 23< 5Ieutar Re0isi%n de Pares
El objetivo de esta actividad es ejecutar una revisin de pares en el momento en +ue un revisor ha
recibido conforme el artefacto a revisar junto con todo su material de apo*o.
Esta actividad comien"a verificando +ue e.istan las condiciones para efectuar la &evisin de
Pares, en cuanto a disponibilidad de artefactos * documentacin asociada seg0n los acuerdos
alcan"ados en la reunin preparatoria. Luego se reali"a la revisin del artefacto seg0n la chec2list, la
aplicacin de la metodolog$a * los antecedentes asociados, registrando los defectos encontrados en el
&eporte de %bservaciones * registrando adem#s el tiempo dedicado a la revisin.
Paso siguiente es convocar a reunin al Pefe de Pro*ecto * al ;utor o ;utores del artefacto con el
objetivo de anali"ar las observaciones encontradas, unificar criterios, determinar los defectos definitivos,
registrarlos en el reporte * de ser necesario definir pla"os para nueva revisin. El autor debe responder a
las observaciones mencionadas * aclarar los temas +ue sean necesarios. <i la respuesta satisface al
e+uipo revisor, el problema no se registra. El Pefe de Pro*ecto registra el resultado de la reunin *
entrega al ;utor * E+uipo &evisor sus conclusiones.
;dem#s se debe determinar si las modificaciones re+ueridas ameritan una nueva revisin de
paresK si es as$, se planifica una nueva reunin. 1ambi/n se deben registrar m/tricas asociadas, como lo
son esfuer"o, cantidad de defectos encontrados, cantidad de revisin de pares por producto, etc.
Luego se debe planificar la incorporacin de las correcciones re+ueridas al artefacto revisado,
ingresando los defectos v#lidos como eventos no planificados. Necha la planificacin, se reali"an las
modificaciones solicitadas * en base a estas se reali"a la evaluacin * validacin a estas correcciones
para determinar si estas corrigen los defectos encontrados en la revisin, para en consecuencia definir si
el producto cumple con los criterios de salida definidos, de manera de dar por finali"ada la &evisin de
60
www.monografias.com
Pruebas de /o)t*are
Este proceso tiene por objetivo asegurar +ue el producto cumple con lo esperado * con los re+uerimientos
definidos. Es un proceso +ue es transversal a todo el ciclo de vida del pro*ecto * presenta las siguientes
pol$ticas8
La planificacin, coordinacin * ejecucin de pruebas es responsabilidad de la )nidad de Control de
Calidad.
Las pruebas son ejecutadas de acuerdo al contenido del Plan de Pruebas de cada pro*ecto.
<e generan reportes con observaciones * las acciones correctivas son planificadas * controladas.
1odos los productos de software desarrollados en %&'E( !ntegracin son sometidos a Control de
Calidad.
La )nidad de Control de Calidad, perteneciente a la P%, es la instancia encargada de llevar a
cabo la verificacin del software generado, como resultado de un pro*ecto de desarrollo, mediante
reali"acin de pruebas de diversos tipos. Para tal efecto cada pro*ecto cuenta con un responsable de dicha
unidad, el cual responde por el dise-o, planificacin * ejecucin de las pruebas as$ como de reportar el
resultado de las pruebas al Pefe de Pro*ecto. La )nidad de Control de Calidad representa una funcin de
apo*o a los pro*ecto de desarrollo * administra sus actividades como un pro*ecto independiente, aplicando
las pr#cticas de gestin de pro*ectos, a saber8
;dministracin de &e+uerimientos
Planificacin de Pro*ectos
Control * <eguimiento
;seguramiento de calidad
;dministracin de la Configuracin
El Proceso de Pruebas de <oftware se divide en dos actividades o subprocesos +ue se ejecutan de
manera secuencial, las cuales son Preparar Pruebas * Ejecutar Pruebas >ver Cigura :@?
Figura 2!< Pruebas de /o)t*are
,ti0idad8 Preparar Pruebas
5ntradas8 Oases de Licitacin, &egistro de &e+uerimientos, !nforme de 'ise-o, etodolog$as de prueba
de software.
/alidas8 Casos de Prueba, 'atos de Prueba, 'efinicin de ambientes de prueba, Plan de Pruebas.
,tores In0olurados8 &esponsable de Pruebas de <oftware, Pefe de Pro*ecto
"esripi%n >=er Cigura :A?8
Esta actividad o proceso tiene como objetivo efectuar actividades preparatorias * generar las condiciones
para pruebas de software * se ejecuta cuando ha* +ue verificar el funcionamiento del software
construido en un pro*ecto de desarrollo. El proceso describe las siguientes actividades8
9. 'eterminar productos de software +ue ser#n probados a partir del contenido de las Oases de
Licitacin * &egistro de &e+uerimientos. Estos pueden ser mdulos, funciones, re+uerimientos,
productos * componentes de productos.
:. 'efinir alcance de las pruebas. !nclu*e tipos de pruebas, enfo+ues * restricciones. Los tipos de
prueba son funcionales, de seguridad, de rendimiento, de aceptacin o de instalacin.
,. 'efinir m/todo de pruebas para productos * componentes de software. Los m/todos pueden ser8
Caja (egra, Caja Olanca, Particin E+uivalente, ;n#lisis de =alor L$mite, Comparacin, Caja de
61
www.monografias.com
Cristal, Caja de Pandora, !ntegracin ;scendente, !ntegracin 'escendente, !ntegracin Combinada
o !ntegracin OigGOang.
@. 4enerar casos de prueba * datos de prueba +ue se utili"ar#n en la ejecucin de pruebas. Los datos
de prueba mencionados en el punto @ pueden ser generados por el e+uipo de trabajo, el e+uipo de
pruebas o proporcionados por el cliente, lo cual debe +uedar establecido en el Plan de Pruebas.
A. 'efinir ambiente de pruebas. <e debe &egistrar todos los detalles t/cnicos de la creacin * todas
a+uellas consideraciones especiales +ue sea necesario recordar ante una reconstitucin del
ambiente para iterar todos o algunos de los casos de prueba. Los datos son registrados en el
documento 'efinicin de ;mbiente de Pruebas el cual es ane.ado al Plan de Pruebas. Este
documento inclu*e red, servidor, privilegios, espacio en disco, herramientas de prueba * recurso
humano +ue ejecutar#n las pruebas.
Figura 2$< Preparar Pruebas
B. Estimar esfuer"o para ejecucin de las pruebas. <e debe considerar todas las actividades
relacionadas con las pruebas8 revisin de documentacin, elaboracin del Plan de Pruebas,
62
www.monografias.com
generacin del ambiente de pruebas, an#lisis transaccional, generar escenarios de pruebas,
preparacin de casos de prueba, generacin de datos de prueba, ejecucin de las pruebas,
seguimiento de las pruebas, consolidar resultados * generar reportes, * generar informe final *
m/tricas.
6. Estimar pla"os para ejecucin de las pruebas, considerando recursos disponibles para pruebas *
estimaciones de productividad individual
\ 1odos los anteriores documentos generados formar#n parte del Plan de Pruebas.
D. !nformar planificacin de pruebas al Pefe de Pro*ecto para coordinacin
El Pefe de Pro*ecto es el encargado de aprobar el Plan de Pruebas anali"ando su compatibilidad con las
eventuales restricciones del pro*ecto. En el caso de no aprobar el documento se debe revisar los puntos
en conflicto.
,ti0idad8 Ejecutar Pruebas
5ntradas8 Plan de Pruebas, !nforme de 'ise-o, <oftware a probar, Casos de Prueba, 'atos de Prueba
/alidas8 /tricas de validacin, &eporte de %bservaciones
,tores In0olurados8 &esponsable de Pruebas de <oftware, E+uipo de Pro*ecto.
"esripi%n >ver Cigura :B?8
Figura 2&< 5Ieutar Pruebas
Esta actividad o proceso tiene como objetivo verificar el funcionamiento del software construido
en un pro*ecto de desarrollo * alcan"ar los criterios de aceptacin o de t/rmino de pruebas definidos. El
proceso contiene las siguiente actividades8
9. Ejecutar pruebas de acuerdo al plan8 <e ejecutan las acciones, procedimientos * programas
establecidos para cada prueba aplicando los Casos de Prueba definidos * los datos de pruebas
generados para tal efecto.
:. En caso de pruebas sobre funciones corregidas se ejecutan pruebas de regresin para asegurar +ue
las correcciones no crearon problemas en otra parte del software.
,. 'ocumentar resultados en el !nforme de %bservaciones.
63
www.monografias.com
@. ;nali"ar resultados de las pruebas determinando8 problemas de construccin de software, problema
con el m/todo de pruebas seleccionado, problemas del ambiente de pruebas >infraestructura, datos
de pruebas, componentes de software faltantes, emitir recomendaciones de mejora si es posible?.
A. 'eterminar criticidad de las observaciones8 defectos de forma, defectos de fondo, factibilidad de
continuar con otras pruebas a pesar de los defectos detectados.
B. Comunicar resultados de las pruebas al pro*ecto
6. ;cumular m/tricas del proceso8 cantidad de defectos total, cantidad de defectos por categor$a
>grave, mediana, leve?, cantidad de iteraciones.
64
www.monografias.com
Re)erenias
3OatEA7 &oger Oate, 'oroth* Suhn, Curt Fells, Pames ;rmitage, 4loria Clar2, Serinia Cusic2,
<u"anne 4arcia, ar2 Nanna, &obert Pones, Peter alpass, !lene innich, Nal
Pierson, 1im Powell, ;l &eichner8 I$ %ystems Engineering Capability Maturity Model
.ersion /0/J, 9EEA.
http8MMwww.sei.cmu.eduMpubMdocumentsMEA.reportsMpdfMmm55,.EA.pdf
3Chr5B7 ar* Oeth Chrissis, i2e Sonrad, <and* <hrumK ICMMI1 for De"elopment "/02J,
:55B.
34on567 4on"ale", Carlos8 IConceptos ,enerales de Calidad #otalJ, onograf$as, :556.
http8MMwww.monografias.comMtrabajos99McongeMconge.shtml
3!ncEB7 !(C%<E8 I%ystems Engineering Capability $ssessment ModelJ, 9EEB.
http8MMwww.incose.orgMProductsPubsMpdfM<EC;G
<*sEngCapabilit*;ssessodel_9EEBG5B.pdf
3PacEE7 !var Pacobson, 4rad* Oooch, Pames &umbaugh8 I#'e 3nified %oft4are De"elopment
-rocess5, 9EEE.
3Sul5,7 argaret S. Sulpa, Sent ;. Pohnson8 IInterpreting t'e CMMI6 $ -rocess Impro"ement
$pproac'J, :55,.
3Pal5B7 Palacio, Puan8 I%inopsis de los modelos CMM7%8 y CMMIJ, :55B
http8MMwww.navegapolis.netMfilesMarticulosMsinopsis_cmm.pdf
3PauE,7 ar2 C. Paul2, Oill Curtis, ar* Oeth Chrissis, Charles =. Feber8 ICapability Maturity
Model for %oft4are .ersion /0/J, 9EE,.
http8MMwww.sei.cmu.eduMpubMdocumentsME,.reportsMpdfMtr:@.E,.pdf
3&at5,7 !O <taff8 IRational 3nified -rocess 9est -ractices for %oft4are De"elopment
#eamsJ, :55,.
http8MMwww.ibm.comMdeveloperwor2sMrationalMlibrar*McontentM5,Pul*M9555M9:A9M9:A9_b
estpractices_1P5:BO.pdf
3&ig5B7 &igoni, Cecilia8 ICMMI16 Mejora del proceso en :)bricas de %oft4areJ, :55B.
http8MMwww.mit*c.esM(&Mrdonl*resM;A65OE5CGO@9;G@BE:GO',EG
@;,9'9DOO6C'M5Ms59Cecilia&igoni.pdf
3<ec56a7 ] <EC;1 LLC8 I3nderstanding t'e %ECM ;EI$<I% =>/0/?J, :556.
http8MMwww.secat.comMwor2shopsM6,9.9_For2shop'escription.htm
3<ec56b7 ] <EC;1 LLC8 IIntegrated -roduct De"elopment Capability Maturity Model o"er"ie4
briefingJ, :556.
http8MMwww.secat.comMdownloadMloc2ed_pdfM!P'ovrvw_l2d.pdf
3<E!557 <oftware Engineering !nstitute, Carnegie ellon )niversit*8 I$RC ./0@ $ssessment
Requirements for CMMI .ersion /0@5, :555
http8MMwww.sei.cmu.eduMpubMdocumentsM55.reportsMpdfM55tr599.pdf
3<E!597 <oftware Engineering !nstitute, Carnegie ellon )niversit*8 I%tandard CMMI
$ppraisal Met'od for -rocess Impro"ement ;%C$M-I? .ersion /0/6 Met'od Definition
Document5, :559
http8MMwww.sei.cmu.eduMpubMdocumentsM59.reportsMpdfM59hb559.pdf
3<E!5Ba7 <oftware Engineering !nstitute, Carnegie ellon )niversit*8 I$ %tandard CMMI
$ppraisal Met'od for -rocess Impro"ement ;%C$M-I? .ersion /026 Met'od Definition
DocumentJ, :55B.
http8MMwww.sei.cmu.eduMpubMdocumentsM5B.reportsMpdfM5Bhb55:.pdf
3<E!5Bb7 <oftware Engineering !nstitute, Carnegie ellon )niversit*8 I$ppraisal Requirements
for CMMI .ersion /02 ;$RC ./02?5 :55B.
http8MMwww.sei.cmu.eduMpubMdocumentsM5B.reportsMpdfM5Btr599.pdf
3<E!56a7 <oftware Engineering !nstitute, )niversit* CarnegieGellon8 ICapability Maturity
Model1 Integration ;CMMI? .ersion /02 O"er"ie4J, :556.
http8MMwww.sei.cmu.eduMcmmiMadoptionMpdfMcmmiGoverview56.pdf
3<E!56b7 <oftware Engineering !nstitute, Carnegie ellon )niversit*8 8'at is CMMIA
<eptiembre :556. http8MMwww.sei.cmu.eduMcmmiMgeneralMinde..html
3=il557 =illate Olanco, Pos/ ar$a8 IModelos de calidad en la industria0 %ituacin y
65
www.monografias.com
perspecti"as de futuro en la C$-.J, :555.
http8MMwww.eus2onews.comM55B9"b2MgaiaB95,es.html
66
www.monografias.com
1losario de 23rminos
,mbiente de integrai%n8 <on las herramientas de soporte necesarias para acoplar las diferentes
componentes de un producto, puede incluir software * e+uipos necesarios.
,m3ria JJI8 Empresa chilena focali"ada al desarrollo * mantenimiento de productos <oftware a medida.
Esta empresa se encuentra actualmente certificada por el modelo de calidad C! (ivel , * adem#s cuenta
en su organi"acin con dos especialistas * certificadores del modelo de calidad C! +ue prestan servicios
de asesor$a * certificacin a diversas organi"aciones, entre ellas a %&'E( !ntegracin.
,rte)ato8 &esultado 0til de un proceso. Puede incluir archivos, documentos, productos, partes de un
producto, servicios, descripciones de proceso, especificaciones * facturas 3Chr5B7.
Casos de prueba8 Conjunto de condiciones, las cuales forman la base informativa para +ue el analista
determine si el re+uerimiento est# satisfecho por el <istema.
Calidad8 La capacidad de un conjunto de caracter$sticas inherentes de un producto, de los componentes del
producto o de un proceso para satisfacer los re+uerimientos impuestos por los clientes 3Chr5B7.
Capaidad8 ;tributo de los procesos. El nivel de capacidad de un proceso indica si slo se ejecuta, o si
tambi/n se planifica se encuentra organi"ativa * formalmente definido, se mide * se mejora de forma
sistem#tica 3Pal5B7.
ConIunto de proesos estAndares de la organi;ai%n8 Es una coleccin de definiciones de los procesos
+ue gu$an actividades en una organi"acin. Estas descripciones de proceso cubren los elementos
fundamentales de proceso >* sus relaciones con otros? +ue deben ser incorporados en los Iprocesos
definidosJ +ue son implementados en pro*ectos 3Chr5B7.
Commerial 4)) 2>e />el) (C42/)8 Corresponde a objetos, componentes de productos o productos en s$
+ue pueden ser ad+uiridos desde un vendedor comercial 3Chr5B7.
Criterios de entrada8 Estados de e.istencias +ue deben estar presente antes de +ue un esfuer"o pueda
empe"ar con el /.ito 3Chr5B7.
Criterios de salida8 Estados de e.istencias +ue deben estar presente antes de +ue un esfuer"o pueda
terminar e.itosamente 3Chr5B7.
"atos de prueba8 Coleccin de datos +ue se utili"ar#n en las pruebas del <istema.
"isiplinas8 <on las etapas, flujos de trabajo o subprocesos del Proceso de !ngenier$a de <oftware. Cada
disciplina contiene tareas a reali"ar, actores involucrados, artefactos producidos * recursos utili"ados.
;dem#s son transversales a todas las fases del ciclo de vida del pro*ecto.
Fases8 <on la etapas por las +ue cual+uier desarrollo de pro*ecto de %&'E( integracin debiera transitar.
Las fases son8 !nicio, ElaboracinGConstruccin * 1ransicin.
1uas de adaptai%n8 4u$as organi"acionales +ue permiten a pro*ectos, grupos, * funciones
organi"acionales adaptarse apropiadamente a los procesos est#ndares para sus usos. Las gu$as de
adaptacin cubren la seleccin de procesos est#ndares, la seleccin de un apropiado modelo de ciclo de
vida, * la adaptacin de los procesos est#ndares seleccionados * modelo del ciclo de vida a las
necesidades del pro*ecto. 4u$as de adaptacin describe +ue puede o no puede ser modificado e identifica
componentes del proceso +ue so n candidatos a ser modificados 3Chr5B7.
Implementai%n8 E.iste evidencia suficiente de +ue un objetivo >espec$fico? es alcan"ado mediante la
definicin de alg0n proceso, en este caso se dice +ue el proceso implementa el objetivo espec$fico.
Instituionali;ai%n8 E.iste evidencia suficiente de +ue un objetivo >espec$fico? se encuentra arraigado en
la forma de hacer el negocio dentro de una organi"acin. Este forma de trabajar se hace rutinariamente *
es parte de la cultura organi"acional, en este caso se dice +ue el objetivo espec$fico se encuentra
institucionali"ado. Los objetivos gen/ricos a*udan a institucionali"ar los objetivos espec$ficos.
Integrai%n asendente8 <e integran incrementalmente las componentes, comen"ando con las inferiores.
Las nuevas componentes se van probando. <e finali"a cuando se alcance el producto final de software * su
respectiva prueba.
Integrai%n KigFKang8 Es un tipo de integracin de componentes no incremental. <e combinan todos los
mdulos * se prueba el programa.
Integrai%n ombinada8 1ipo de integracin de componentes efectuada en forma incremental, es decir se
integra en forma controlada conjuntos, previamente especificados, de componentes.
Integrai%n desendente8 Es una estrategia de integracin incremental a la construccin de la estructura
de programas, en cual se integran los mdulos movi/ndose en direccin hacia abajo por la jerar+u$a de
control comen"ando con el mdulo principal >Programa principal?. Los mdulos subordinados al mdulo de
control principal se incorpora en la estructura, bien, de forma primeroGenGprofundidad, bien de forma
primeroGenGanchura 3Par567.
Madure;8 ;tributo de las organi"aciones +ue desarrollan o mantienen los sistemas de software. En la
medida +ue /stas llevan a cabo su trabajo siguiendo procesos, * en la +ue /stos se encuentran
67
www.monografias.com
homog/neamente implantados, definidos con ma*or o menor rigorK conocidos * ejecutados por todos los
e+uipos de la empresaK * medidos * mejorados de forma constante, las organi"aciones ser#n m#s o menos
ImadurasJ 3Pal5B7.
Medidas8 edidas de un proceso indican el grado de correctitud en +ue un proceso est# siendo ejecutado.
Modelo de alidad8 son sistemas basados en estudios e.perimentales de mejores pr#cticas +ue a*udan a
organi"acin a implantar <istema de ;seguramiento de la calidad.
9i0el de apaidad8 4rado +ue involucra la mejora dentro de una individual #rea de proceso 3Chr5B7, es
decir involucra la mejora de un conjunto de procesos relacionados al #rea de proceso especificada.
9i0el de madure;8 4rado +ue involucra un conjunto predefinido de #reas de proceso, las cuales todos sus
objetivos son alcan"ados 3Chr5B7.
4rgani;ai%n8 Es una estructura administrativa en +ue la gente colectivamente maneja uno o m#s
pro*ectos +ue comparten un alto directivo * operan bajo las mismas pol$ticas. %rgani"acin puede ser
tambi/n aplicada a una persona +uien reali"a una funcin en una pe+ue-a organi"acin +ue podr$a ser
reali"ada por un grupo de gente en una gran organi"acin 3Chr5B7.
Partes Interesadas< =er <ta2eholders
Partii%n 5#ui0alente8 1ipo de prueba de caja negra. 'ivide las entradas de un programa en clases +ue
podr$an llegar a derivan casos de prueba.
Proeso8 )n conjunto de pasos +ue a*udan a resolver un problema. Estos pasos deben estar definidos de
manera +ue no sean ambiguos, esto implica +ue puedan ser f#cilmente entendidos * capaces de ser
seguidos de manera consistente por cual+uier persona +ue lo utilice. ;dem#s un proceso debe tener sus
entradas * salidas claras * bien definidas.
Proeso de "esarrollo de /o)t*are8 Proceso definido por %&'E( !ntegracin referido al proceso o
metodolog$a de desarrollo de soluciones software Ia medidaJ para sus clientes.
ProIet Managment 4rgani;ation (PM4)8 ^rea ejecutiva de %&'E( !ntegracin encargada de la
administracin de los pro*ectos.
Pruebas de ,eptai%n8 Pruebas reali"adas por el usuario +uien comprueba en su ambiente de operacin
el sistema entregado. Los puede aceptar o recha"ar.
Pruebas de ,nAlisis de 'alor 6mite8 Prueba +ue tiene por objetivo verificar la ejecucin de programa
anali"ando los valores l$mite de los tipos de datos especificados. Para ello se debe probar con valores
dentro * fuera de los l$mites especificados para el tipo de dato.
Pruebas de CaIa Klana8 Los objetivos de este tipo de pruebas es garanti"ar la ejecucin por lo menos
una ve" todos los caminos independientes de cada modulo, la ejecucin de todas las decisiones lgicas en
sus caminos verdadero * falso, la ejecucin de todos los la"os en sus limites, * la ejecucin de las
estructuras internas de datos para asegurar su valide".
Pruebas CaIa de Cristal8 Prueban por lo menos una ve" todos los caminos en el control de cada
componente * todas las decisiones lgicas.
Pruebas de CaIa 9egra8 Las pruebas de caja negra se centran en los re+uerimientos funcionales.
Permiten al ingeniero del software obtener un conjunto de entradas +ue prueben completamente los
re+uerimientos funcionales de un programa sin importar los detalles internos del programa, a fin de verificar
+ue el programa corra bien.
Pruebas de CaIa de Pandora8 Consiste en abstenerse de reali"ar pruebas de depurar bastante bien un
pro*ectoK se deja al cliente +ue lo ensa*e * acepte. El resultado es una bomba de tiempo.
Pruebas de Comparai%n8 Consiste en la comparacin de las salidas de las distintas versiones de una
misma componente o producto software.
Pruebas Funionales8 Ouscan satisfacer los re+uerimientos funcionales de las componentes del producto o
producto final.
Pruebas de Instalai%n8 Pruebas +ue buscan satisfacer los re+uerimientos de operacin del sistema.
Pruebas de Regresi%n8 Las pruebas de regresin consisten en a reali"ar pruebas ejecutadas previamente,
con el fin de asegurar de +ue los cambios hecho en el cdigo no ha provocado efectos laterales no
deseados.
Pruebas de Rendimiento8 Ouscan satisfacer los re+uerimientos no funcionales asociados satisfacer
re+uerimientos de rendimiento del sistema >volumen de datos, tasa de transacciones, etc.?
Pruebas de /eguridad8 Ouscan satisfacer los re+uerimientos no funcionales referidos a mantener la
integridad del sistema ante cual+uier amena"a definida +ue pueda llegar a tener en su operacin.
Prueba de 'alidai%n8 el producto final se prueba para definir si cumple los re+uerimientos funcionales *
de rendimiento, facilidad de mantenimiento, recuperacin de errores.
Re#uerimientos de operai%n8 &e+uerimientos provistos por el ambiente en el cual operar# el sistema.
68
www.monografias.com
Roles8 &oles de un proceso se refiere al conjunto de responsabilidades * funciones +ue deben ser
reali"adas por los actores del proceso.
RLP (Rational Lni)ied Proess)< Proceso de desarrollo de software unificado. Provee un enfo+ue
disciplinado para asignar tareas * responsabilidades dentro de una organi"acin. El objetivo es asegurar
productos software de alta calidad +ue satisfagan las necesidades de los usuarios finales, dentro de los
tiempos * presupuestos previstos 3&at5,7.
/taHe>olders8 <e refiere a una persona o un conjunto de persona +ue son afectadas o responsables por las
actividades de un pro*ecto.
2ra;abilidad8 )na asociacin distinguible entre dos o m#s entidades lgicas, como re+uerimientos,
elementos del sistema, verificaciones, tareas.
Lnidad de Control de Calidad8 )nidad de %&'E( !ntegracin encargada de controlar * asegurar la
calidad de los productos software producidos por la empresa * liberados a los clientes
8orH KreaHdo*n /truture (8K/)8 El FO< es la descomposicin del pro*ecto en fases, etapas,
subetapas, hitos, hasta concluir con los entregables a producir al t/rmino de cada hito. Es 0nico para cada
pro*ecto * es preparado en forma general al principio del pro*ecto * se detalla en la medida +ue el pro*ecto
avan"a en su ejecucin. El FO< se actuali"a mensualmente * permite reconocer contablemente el avance
del pro*ecto a partir del valor del costo de los artefactos producidos * aceptados como terminados por el
Pefe de Pro*ecto. Cada artefacto indicado en el FO< debe ser presupuestado en t/rminos del Esfuer"o
estimado para producirlo * el Costo a incurrir hasta su t/rmino. Las cartas 4antt del pro*ecto +ue
peridicamente debe actuali"ar el jefe de pro*ecto deben relacionar en forma e.plicita cada tarea con uno
de los entregables declarados en el FO<. 'e esta manera, cuando la tarea sea finali"ada, se podr#
comparar los valores de esfuer"o presupuestado en el FO< con los valores reales informados por los
responsables de producir el artefacto.
69
www.monografias.com
(ota sobre los ;utores
Matas Fuentes Contreras.
Estudiante de !ngenier$a Civil !nform#tica de la )niversidad de Concepcin, Concepcin, Chile.
mat_fuentes@hotmail.com
Pablo 2euber Menr#ue;.
Estudiante de !ngenier$a Civil !nform#tica de la )niversidad de Concepcin, Concepcin, Chile.
pteuber@gmail.com
1rabajo reali"ado en la ciudad de <antiago de Chile.
70

Modelo Cmmi

Cargado por

Información del documento

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

Modelo Cmmi

Cargado por

Copyright:

Formatos disponibles

www.monografias.

También podría gustarte