RESUMEN

Actualmente, las organizaciones han incrementado su interés en la adquisición de productos

software. Debido a ello este proceso debe estar bien definido, deber ser específico y debe permitir
a estas organizaciones poder apropiarse del mismo, para lograr satisfacer sus necesidades y
expectativas relacionadas con la adquisición. En este sentido, este artículo expone un método para
la adquisición de productos software ajustado a las características propias de las pequeñas
organizaciones, el cual está basado en las prácticas más comunes presentadas por referentes
internacionales relacionados con la adquisición. Además, se presenta de forma detallada el flujo
de actividades, tareas, roles y productos de trabajo que deben ser seguidas para adquirir un
producto software que satisfaga las necesidades y expectativas de la organización. De la aplicación
inicial del método propuesto en una pequeña organización vinculada al sector de economía
solidaria se ha observado que éste es útil y práctico para conducir la adquisición.

Palabras clave:Adquisición de software, Proceso de adquisición, Pequeña organización.

ABSTRACT

Currently organizations have increased their interest in the acquisition activities of software
products. As a result, this process should be well defined and specific in order to allow to these
organizations appropriate of them seeking satisfy their needs and expectations related to the
acquisition. In this sense, this article exposes a method for software products acquisition adjusted
to the specific characteristics of small organizations, which is based on common practices
presented by international referents related to the acquisition process. Furthermore, the flow of
activities, tasks, roles and work products that must be followed to acquire a product that satisfies
the needs and expectations of the organization is presented in detail. From the initial application
of the proposed method in a small organization linked to the cooperative sector has been
observed that this is useful and practical to conduct the activity of software acquisition.

Keywords:Software acquisition, Acquisition process, Small organization.

UIS Ingenierías, enero - junio 2014; Facultad de Ingenierías Fisicomecánicas, UIS

1. INTRODUCCIÓN

La participación de las micro, pequeña y medianas empresas en la transformación del aparato

productivo económico en Colombia es fundamental al representar el 96.4% de los
establecimientos a nivel nacional (Ministerio de Comercio, Industria, y Turismo 2009). Estas
pequeñas organizaciones, a su vez, en muchos casos desconocen los elementos que son
necesarios considerar y que se requieren para tomar una buena decisión al momento de adquirir
productos software que se ajusten a sus necesidades y características propias (L, Elissondo., 2004)
causando que los productos software que se adquieren en ocasiones no respondan a las
necesidades o no se ajustan a los requerimientos de las pequeñas organizaciones (L, Elissondo.,
2004) esto puede suceder debido a que no se le reconoce la importancia de la adecuada gestión
de la adquisición, la buena definición de los requerimientos y el cuidado en la selección y posterior
contratación del proveedor (HURTADO, 2000) entre otros. Por lo tanto para este tipo de
organizaciones sería importante llevar a cabo un buen proceso de adquisición de productos
software ya que un mayor control en el proceso de selección y adquisición aumenta la posibilidad
de éxito en la adquisición del producto adecuado (L, Elissondo., 2004)

La adquisición es el proceso de obtener un sistema, producto o servicio software (ISO/IEC

12207,2007). Este es un proceso necesario e indispensable en las actividades que realiza una
organización. Ahora más que antes, las organizaciones han incrementado su interés en las
actividades de adquisición de productos software (Weber, K., et al., 2007). Es por eso que este
proceso debe estar bien definido y permitir la satisfacción de las necesidades y expectativas
expresadas por las organizaciones.

Por otra parte, se encuentran establecidas normas internacionales, guías y recomendaciones tales
como CMMI-ACQ (SEI, CMMI for Acquisition, Version 1.3, 2010) ISO/IEC 12207 (ISO, ISO/IEC
12207, 2007) Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBok) (PMI,
2008) Recomendaciones para la adquisición de software (IEEE, 1998) entre otras, las cuáles
proponen prácticas sólidas que contribuyen en el proceso de adquisición de software, sin
embargo, estas normas están enfocadas hacia grandes empresas. La aplicación de las prácticas de
estas normas son complejas para las pequeñas empresas y éstas no disponen de recursos
necesarios para su aplicación (ISO/IEC, 2007) Esto provoca que las organizaciones no cuenten con
procesos adecuados para la adquisición de productos software, lo cual puede deberse a que es un
tema nuevo para las empresas, lo que conlleva a un desconocimiento de las prácticas que se
deben seguir para la adquisición y por ello no son utilizadas en estas empresas.
Considerando lo expuesto anteriormente, este artículo presenta un método de adquisición de
software que se ajusta a las necesidades de las pequeñas organizaciones y que permite guiar a
estas organizaciones en el proceso de adquisición de productos software. Este método está
basado en las prácticas propuestas por algunas normas, modelos, guías y recomendaciones
internacionales relacionadas con la adquisición de software.

Este artículo se organiza de la siguiente manera: la sección 2 presenta los trabajos relacionados a
la temática tratada y el método empleado para desarrollar la propuesta para adquisición de
software. En la sección 3 se muestra el desarrollo y especificación del método. Un caso de
aplicación en un entorno real del método de adquisición propuesto es descrito en la sección 4.
Finalmente las conclusiones y trabajos futuros se exponen en la sección 5.

2. ANTECEDENTES

En esta sección inicialmente se presenta los trabajos relacionados con adquisición de software y
finalmente se describe el método de trabajo utilizado para la creación de la propuesta.

2.1 Trabajos relacionados

Con respecto al proceso de adquisición de software se encontraron algunos referentes

internacionales, entre los cuales cabe destacar: (i) el modelo CMMIACQ (SEI, CMMI for Acquisition,
Version 1.3, 2010), que provee una guía para la aplicación de las mejores prácticas de CMMI en
organizaciones adquirientes; (ii) la norma técnica ISO/IEC 12207 (ISO, ISO/IEC 12207 - Systems and
software engineering - Software life cycle processes, 2007), que presenta los procesos del ciclo de
vida que se pueden emplear para adquirir, suministrar, desarrollar, operar y mantener productos
software, cubre además el control y la mejora de estos procesos; (iii) la guía del PMBok (PMI,
2008) que propone un conjunto de áreas de conocimiento para la gestión de proyectos, una de
estas áreas describe los procesos involucrados en la compra o adquisición de productos, servicios
o resultados para el proyecto; y (iv) las recomendaciones prácticas para la adquisición de software
de la IEEE (IEEE, 1998) que proporcionan una guía para la gestión y ejecución de actividades de
adquisición de productos software, para aquellas organizaciones que adquieren software de
proveedores. A pesar de que estas normas internacionales, guías y recomendaciones definen
buenas prácticas que deberían ser implementadas durante el proceso de adquisición de productos
software, dichas prácticas están centradas en el “qué” debe hacerse y no en el “cómo” debe
llevarse a cabo este proceso (no se especifican detalles de su implementación). Esto conlleva que
las pequeñas organizaciones no se apropien de estos referentes para guiar su proceso de
adquisición (Laporte, C., A. April, and A. Renault,. 2007) Además, es importante resaltar que estos
referentes internacionales han sido creados considerando las necesidades de grandes
organizaciones (Pino, F., .et al., 2008) Sin embargo, estos referentes fueron considerados y sus
prácticas adaptadas e integradas para la definición del método presentado en este artículo.

Además con respecto al área investigada se encontraron algunos estudios relacionados

importantes, entre los cuales cabe destacar:

En (Gallagher, B.P., 1999) se presenta una guía para la gestión de riesgos y proporciona una visión
general para identificar, analizar, planificar, seguir, controlar y comunicar las funciones de vital
importancia para la implementación exitosa de la gestión de riesgos en un proceso de adquisición.

En (Aaby, 2006) se propone un proceso simple de adquisición de software, el cual es diseñado

para que pueda ser utilizado por diferentes usuarios. Hace énfasis en la importancia de la
recolección de requisitos y el análisis de riesgos.

En (Tardy, 1991) se enumeran y se describen trece estrategias para la adquisición de software,

definiendo y explicando el mecanismo de adquisición, quienes deben intervenir y bajo qué

En (Mosko, M., et al.,) se describe un metamodelo para la adquisición de software COTS

(Commercial-Off-The-Shelf), llamado SAMM, este modelo se enfoca en el proceso de adquisición
de software e incorpora las mejores prácticas de la industria del software.

En (Cohen, et al., 2005) se presenta un manual que reúne y brinda orientación acerca de la
planeación de la adquisición y la estrategia de adquisición de software.

En (Goldenson, and Fisher, 2000) se describe una encuesta realizada por el Software Engineering
Institute (SEI) a expertos en gestión de adquisiciones.

De acuerdo con el estado actual del conocimiento descrito en esta sección, se puede observar que
existen diferentes formas de abordar el tema de adquisición de productos software tales como:
meta-modelos, técnicas, estrategias, prácticas, y actividades. Sin embargo, no se han encontrado
propuestas en esta área que presenten una forma detallada para la realización de la adquisición
de productos software, el cual incorpore: (i) un proceso de adquisición que describa actividades,
tareas, roles y productos de trabajo para el contexto de las pequeñas organizaciones, el cual se
ajuste a las necesidades y características propias de este tipo de empresas; (ii) una herramienta de
soporte tecnológico que apoye la ejecución del proceso de adquisición definido. También es
importante resaltar que si bien en las diferentes propuestas relacionadas con la adquisición de
software se establece qué es lo que se debe hacer no se especifica cómo hacerlo, lo que lo hace
complejo y dificulta que este proceso sea implementado por las pequeñas organizaciones. Además
las propuestas encontradas no se enfocan en guiar explícitamente a las pequeñas organizaciones
en la implementación de todos los aspectos relacionados con el proceso de adquisición. De
acuerdo con lo antes planteado, el método de adquisición que se presenta en este artículo
pretende guiar a las pequeñas organizaciones en el proceso de adquisición de productos software.
Este método está fundamentado en prácticas propuestas por los referentes internacionales
mencionados y que se ajusta a las características de las pequeñas organizaciones.

2.2 Método utilizado para la construcción de la propuesta

Para el desarrollo del método de adquisición propuesto, se llevaron a cabo las siguientes
actividades:

Comparar los referentes internacionales. Para llevar a cabo esta actividad se siguió el método de
comparación propuesto en (Pino, F., et al., 2009). Esta actividad involucró las siguientes tareas del
método de comparación: (i) analizar los modelos, (ii) diseñar la comparación, (iii) realizar la
comparación, (iv) presentar los resultados de la comparación.

Construir el método para la adquisición de software. Esta actividad involucró la tarea (v) analizar
los resultados obtenidos del método de comparación propuesto en (Pino, F., et al.,2009). En esta
tarea se realizaron los siguientes pasos: (i) construcción de los diagramas de actividades genéricos
para la adquisición de software de cada uno de los referentes internacionales, (ii) análisis de los
diagramas de actividades creados, (iii) identificación de las actividades genéricas a incluir en el
método, (iv) especificación del método propuesto para la adquisición.

3. DESARROLLANDO EL MÉTODO DE ADQUISICIÓN DE SOFTWARE

3.1 Comparación de los referentes internacionales

Inicialmente se realizó el análisis de los referentes internacionales para establecer la manera en

que cada uno lleva a cabo el proceso de adquisición. De igual manera se hizo un análisis de sus
estructuras, identificando entidades de proceso que serían utilizadas en la comparación.
Posteriormente se realizó la comparación entre las entidades de proceso identificadas, desde ISO/
IEC 12207, la guía del PMBok y las recomendaciones de la IEEE hacia CMMI-ACQ. Dependiendo del
grado de relación existente entre las entidades de proceso se asignó un valor de acuerdo a la
siguiente escala numérica: 0 (no relacionada), 1 (parcialmente relacionada) y 2 (fuertemente
relacionada). A manera de ejemplo y con el fin de mostrar detalladamente la comparación llevada
a cabo se presenta la Tabla 1 que describe el grado de relación entre el área de proceso de gestión
de acuerdo (CMMI-ACQ) y el proceso de Adquisición (ISO/IEC 12207).

3.1 Comparación de los referentes internacionales

Inicialmente se elaboraron los diagramas de actividades con el fin de identificar cómo se realiza la
adquisición de productos software, de acuerdo a la descripción presentada en cada referente.
Posteriormente se analizaron los diagramas realizados con el fin de tener una vista completa de
cómo es la adquisición de software en los diferentes referentes, con el fin de determinar las
carencias y fortalezas de cada uno de ellos. Luego se traslaparon las actividades de los diagramas
para identificar las actividades comunes entre los referentes. Las comparaciones realizadas
permitieron determinar qué entidades de proceso debían ser consideradas en la creación del
método, de esta manera se garantiza que este método está alineado con lo propuesto en la
mayoría de referentes. Además la comparación permitió visualizar e identificar qué entidades de
proceso son tenidas en cuenta por unos referentes y descartadas por otros, pero que serían
adecuadas considerarlas debido a la importancia que presentan en el proceso de adquisición. Las
actividades genéricas identificadas desde los referentes a incluir en el método son las siguientes:
Planear, Anunciar, Seleccionar proveedor, Contratar, Monitorear, Aceptar, Cerrar y Seguir. La
actividad Seguir solo es propuesta por las recomendaciones prácticas para la adquisición de la
IEEE, pero debido a la utilidad que presenta en el proceso de adquisición fue adecuado
considerarla en el método propuesto. Es importante resaltar que todos los referentes plantean
hacer la adquisición de un producto software con un proveedor, pero en el caso de las pequeñas
organizaciones éstas podrían pensar en adquirirlo no mediante la compra sino mediante la
búsqueda de un producto libre disponible en internet. Para ello se tuvieron en cuenta actividades
como: Buscar, Analizar y Seleccionar producto, debido a que cuando una organización desea
obtener un producto software no necesariamente lo adquiere de un proveedor sino que puede
adquirirlo de forma gratis buscando en internet. Es importante resaltar que las actividades
genéricas consideradas en el método son especificadas mediante la unión y adaptación de
distintas prácticas descritas por los diferentes referentes, para lo cual fue útil la comparación
realizada inicialmente.

Una vista general del grado de relación de los propósitos entre ISO/IEC 12207, la guía del PMBok y
las recomendaciones de la IEEE hacia CMMI-ACQ se presenta en la Tabla 2.
4. DESCRIPCIÓN DEL MÉTODO DE ADQUISICIÓN DE SOFTWARE

Por definición un método hace referencia a una articulación de un conjunto coherente,

consistente y completo de prácticas con un propósito específico que cumple las necesidades de los
interesados bajo condiciones específicas (Pardo, et al., 2011), (Oktaba, H.J., et al., 2012) A
continuación el método propuesto se describe mediante una descripción de su propósito,
objetivos, diagrama de actividades, actividades, tareas, roles y productos de trabajo. Debido a
restricciones de espacio en este artículo se presentan la descripción del método desde una
perspectiva general.

4.1 Propósito

El propósito del método para la adquisición de software en pequeñas organizaciones es permitir a

éstas obtener un producto software que se ajuste a sus necesidades, además esté método está
basado en prácticas propuestas por los referentes internacionales relacionados con el proceso de
adquisición.

4.2 Objetivo

Proponer un método de adquisición de software que guíe a las pequeñas organizaciones en la

obtención de un producto software, identificando las mejores prácticas de adquisición de software
adecuadas para las pequeñas organizaciones, a partir de las normas internacionales, guías y
recomendaciones.

4.3 Diagrama de actividades

La Figura 1 muestra el diagrama de actividades del método propuesto.

4.4 Descripción del método

Actividades y tareas: las actividades que integran el método son: Planear, Anunciar, Seleccionar
proveedor, Contratar, Monitorear, Buscar, Analizar, Seleccionar producto software, Aceptar,
Cerrar y Seguir. Cada una de estas actividades contiene un conjunto de tareas específicas que
guían el proceso de adquisición.

Las actividades y tareas descritas a continuación hacen parte de la adquisición de un producto

software mediante un proveedor:

Planear: en esta actividad se determina la necesidad de adquisición por parte de la organización,

se establecen los requisitos del producto software a adquirir, se identifican los proveedores
potenciales, se definen y documentan cuáles serían los criterios de aceptación. Adicionalmente, se
prepara y ejecuta el plan de adquisición. Las tareas definidas para la actividad Planear son:

Establecer la necesidad de adquisición de un producto software.

Definir y analizar requisitos del producto software a adquirir.

Determinar el presupuesto disponible para realizar la Adquisición.

Determinar tipo de contrato que se planea utilizar.

Identificar proveedores potenciales.

Definir y documentar criterios de aceptación.

Definir criterios de selección de proveedores.

Preparar y ejecutar un plan de adquisición

Anunciar: en esta actividad se da a conocer la necesidad de adquisición de la organización a los

posibles proveedores ya identificados. Paralelo a ello se documenta el proceso que se lleva a cabo
para realizar el anuncio. La tarea definida para la actividad Anunciar es:

Comunicar el paquete de solicitud del producto software a los posibles proveedores identificados.
Seleccionar proveedor: en esta actividad se escoge el proveedor más adecuado para llevar a cabo
el proceso de adquisición, de acuerdo con los criterios de selección y la propuesta preliminar
presentada. Las tareas definidas para la actividad Seleccionar proveedor son:

Recibir propuestas de proveedores.

Evaluar propuestas de proveedores aplicando criterios de selección de proveedores.

Seleccionar proveedor.

Negociar un contrato con el proveedor.

Contratar: en esta actividad se establece un acuerdo con un proveedor, para la adquisición del
producto software. De igual manera se establece el control de cambios durante el proceso de
adquisición. Las tareas definidas para la actividad Contratar son:

Preparar y Adjudicar el contrato.

Controlar los cambios en el contrato.

Monitorear: en esta actividad se monitorea el progreso de los proveedores para asegurar que se
cumplen todas las metas y se aprueban los entregables del producto software. Además se realiza
una revisión estructurada del avance del proveedor para cumplir con el producto, dentro del costo
y en el plazo acordado, tomando el contrato como referencia. Las tareas definidas para la
actividad Monitorear son:

Monitorear los procesos del proveedor.

Revisar y verificar el desempeño del proveedor.

Mantener el entendimiento mutuo con el proveedor.

Reportar los hallazgos

Aceptar: en esta actividad se recibe el producto software y se evalúa aplicando los criterios de
aceptación, mediante la realización de una serie de pruebas para verificar que cumple con los
requisitos establecidos en el acuerdo. De igual manera se informa sobre las no conformidades
encontradas y finalmente una vez sean resueltas las no conformidades se acepta el producto
software. Las tareas definidas para la actividad Aceptar son:
Recibir producto software.

Evaluar y probar el producto software aplicando criterios de aceptación.

Reportar no conformidades.

Aceptar el producto software.

Cerrar: en esta actividad se finaliza el proceso de adquisición. Las tareas definidas para la actividad
Cerrar son:

Verificar que todo el trabajo y los entregables son aceptados.

Administrar las facturas.

Cerrar: en esta actividad se finaliza el proceso de adquisición. Las tareas definidas para la actividad
Cerrar son:

Verificar que todo el trabajo y los entregables son aceptados.

Administrar las facturas.

Seguir: en esta actividad se realiza un monitoreo al producto software luego de haber sido puesto
en funcionamiento en la organización, evaluando el desempeño del producto software y del
proveedor, y la satisfacción del usuario. Las tareas definidas para la actividad Seguir son:

Utilización del producto software.

Evaluar satisfacción del usuario

Evaluar desempeño del producto.

Las actividades y tareas descritas a continuación hacen parte de la búsqueda de un producto

software libre disponible en internet:

Buscar: en esta actividad se averigua si hay un producto software libre en internet que se ajuste a
los requisitos que tiene la organización. Las tareas definidas para la actividad Buscar son:
Realizar una búsqueda de productos software libres en internet.

Descargar productos software.

Analizar: en esta actividad se revisa cada uno de los productos software descargados en la
actividad Buscar y se determina cuáles de ellos cumplen con los criterios de aceptación. Las tareas
definidas para la actividad Analizar son:

Hacer una revisión detallada de las características de cada producto software.

Escoger productos software que cumplan con los criterios de aceptación.

Seleccionar producto software: en esta actividad se obtiene el producto software que satisfaga de
una mejor manera las necesidades establecidas por la organización, realizando pruebas y
analizando los resultados obtenidos para seleccionar el producto software más indicado. Las
tareas definidas para la actividad Seleccionar producto software son:

Preparar casos de prueba, datos, procedimientos y el entorno.

Realizar el análisis de los resultados obtenidos.

Seleccionar un producto software.

Roles: en cada actividad se hace necesario asignar personas encargadas de llevar a cabo las tareas,
es por ello que se definieron los siguientes roles en términos de sus conocimientos y habilidades
esperadas:

Administrativo (AD): Conocimiento en los procesos de la organización. Capacidad en la gestión de

las actividades de la empresa. Facultad para controlar y aprobar inversiones de la organización.

Encargado de la adquisición (EA):Conocimiento de las expectativas y necesidades de adquisición.

Gestión del proceso de adquisición. Comunicación con los interesados y proveedores del producto
software.

Técnico software (TS): Conocimiento en tecnologías de desarrollo de software. Participación en

procesos de calidad de producto software. Verificación de componentes programados. Análisis,
diseño y documentación del desarrollo y mantenimiento de productos software. Interpretación de
especificaciones de diseño.

Encargado de contratación (EC):Conocimiento en contratación, aspectos legales y jurídicos.

Comunicación con los interesados en la adquisición y el proveedor del producto software.

Productos de trabajo: Conocimiento en los procesos de la organización. Capacidad en la gestión de

las actividades de la empresa. Facultad para controlar y aprobar inversiones de la organización.

Encargado de la adquisición (EA):son los resultados útiles de cada una de las actividades, entre
ellos se tienen: Plan de adquisición, Paquete de solicitud, Comunicado de la adquisición,
Documento con el proveedor seleccionado, Contrato de adquisición, Documento de control de
cambios, Evaluación del desempeño del proveedor, Revisión y verificación del producto software,
Documento de aceptación, Producto software, Soportes del pago, Notificación de terminación del
contrato (acta de cierre), Realimentación al proveedor.

Para realizar la descripción detallada de los elementos constitutivos del método se tuvo en cuenta
la plantilla presentada en el proyecto COMPETISOFT (COMPETISOFT and CYTED, COMPETISOFT ,
2006) a manera de ejemplo se presenta en la Tabla 3 la actividad Contratar.

En la Figura 2 se presenta el diagrama de la actividad Contratar, sus respectivas tareas y pasos.

Este diagrama es modelado utilizando estereotipos de la notación SPEM.

5. EVALUACIÓN DEL MÉTODO PROPUESTO

El método para la adquisición de software ha sido aplicado en una pequeña organización, además
también ha sido evaluado mediante el método de Focus group ( Kontio, J, et al, 2004). La
aplicación del método se describe mediante un reporte de experiencias teniendo en cuenta las
indicaciones para tal fin recomendados por (Pino, F., et al, 2011). En este sentido, esta sección
describe inicialmente el reporte de experiencias en términos de: (i) Contexto de aplicación, (ii)
Descripción de la organización participante, (iii) Informe y análisis del trabajo realizado en la
empresa y (iv) Discusión. Finalmente se muestra el Focus Group del método de adquisición el cual
siguió los lineamientos definidos en (Mendoza, M., et al, 2013).

5.1 Reporte de experiencia

El método para la adquisición de software está siendo aplicado en una pequeña organización
dedicada al sector de economía solidaria. Con el fin de mantener la privacidad de la empresa, esta
se denominará EES. La empresa participante EES deseaba adquirir un producto software para
sistematizar el proceso de gestión de la información de cada uno de sus asociados. Este proceso se
ha llevado a cabo aproximadamente durante dos meses con reuniones periódicas.

El método para la adquisición de software está siendo aplicado en una pequeña organización
dedicada al sector de economía solidaria. Con el fin de mantener la privacidad de la empresa, esta
se denominará EES. La empresa participante EES deseaba adquirir un producto software para
sistematizar el proceso de gestión de la información de cada uno de sus asociados. Este proceso se
ha llevado a cabo aproximadamente durante dos meses con reuniones periódicas.

5.2 Características de la organización

Las características de la empresa participante EES en la aplicación del método para la adquisición
de software se describen a continuación:

EES nace jurídicamente en el año 1984, actualmente cuenta con 354 asociados hábiles, y el
número de personas que trabaja en esta empresa es 5 (gerente, contadora, encargada de cartera,
secretaria y comunicador social).

Su objetivo general es buscar el mejoramiento de las condiciones económicas, sociales, culturales,

recreativas, educativas y de seguridad social de todos los Asociados, mediante la práctica de la
solidaridad, el compañerismo y el desarrollo de actividades empresariales.
Cuentan con una estructura organizacional encabezada por la Asamblea General y dirigida por la
Administración, quién a su vez es vigilada por los entes de Control Interno y apoyada por Comités
especiales y el grupo de personal.

5.3 Informe y análisis del trabajo realizado en la empresa

En esta subsección, se presenta una descripción general del uso del método para la adquisición de
software en la empresa participante ESS.

Inicialmente se presentó el método para la adquisición de software propuesto al gerente de la

organización, explicando de forma detallada el objetivo, las actividades a desarrollar y los
resultados esperados con la utilización del método. Posteriormente, se realizó un acercamiento a
la organización para conocer a fondo el quehacer a la cual se dedica ésta.

En reuniones establecidas con los miembros de la organización, se procedió a realizar las tareas
estipuladas para la actividad Planear, la cual es la actividad que hasta el momento ha sido llevada
a cabo y sobre la cual se tratará en este reporte de experiencias. Como resultado de las reuniones
realizadas se desarrollaron las siguientes tareas:

Establecer la necesidad de adquisición de la organización, donde se logró determinar que la

empresa participante EES buscaba un producto software para sistematizar el proceso de gestión
de la información de cada uno de sus asociados.

Definir y analizar requisitos del producto software a adquirir, se realizó una especificación de los
requerimientos funcionales y no funcionales, identificando y priorizando requisitos claves que
influyen en la implementación del producto software. El análisis de cada requisito se llevó a cabo
teniendo en cuenta las características que cada uno de estos debe cumplir: necesario, conciso,
completo, consistente, no ambiguo, verificable.

Determinar el presupuesto para el producto software que se deseaba adquirir, se estableció el

presupuesto disponible por parte de la organización.

Determinar tipo de contrato que se planea utilizar, se revisaron los tipos de contratos existentes
teniendo en cuenta ventajas y desventajas en su utilización y se eligió el que mejor se adapta a la
organización.
Identificar proveedores potenciales, la organización disponía de algunos proveedores identificados
previamente, sin embargo se buscó información sobre otros proveedores que pudieran
implementar el producto deseado, estos proveedores conformaron una lista con información de
contacto.

Definir y documentar criterios de aceptación, la organización estableció los criterios de aceptación

que consideran relevantes algunos de ellos son: el producto software debe cumplir con todos los
requisitos definidos, el proveedor debe entregar la documentación necesaria para la utilización del
producto software, la entrega debe hacerse de acuerdo a los tiempos establecidos, el producto
software debe cumplir satisfactoriamente con los casos de pruebas realizados, además el
proveedor debe cumplir satisfactoriamente los términos y condiciones estipulados en el contrato

Definir criterios de selección de proveedores, la organización estableció algunos criterios para

seleccionar proveedores entre ellos se encuentran: precio, la medida en que la propuesta del
proveedor responde al enunciado del trabajo a la adquisición, las habilidades y conocimientos
técnicos con los que cuenta el proveedor, las garantías qué propone el proveedor para garantizar
el producto final, desempeño pasado de los proveedores y la forma en que el proveedor maneja
los derechos de propiedad del producto (licencias, garantías).

Preparar un plan de adquisición, se recopiló toda la documentación realizada en las tareas

anteriores, con el fin de obtener un documento formal que guie las demás actividades del método
propuesto.

Como resultado de la actividad Planear llevada a cabo, se dejó definido el paquete de solicitud que
consta de la necesidad de adquisición y los requisitos establecidos del producto software, y el plan
de adquisición que contiene toda la documentación obtenida como resultado de la ejecución de
esta actividad.

Discusión

La empresa que participó y utilizó el método para la adquisición de software descrito en este
artículo, expresó su opinión de que este método: (i) es una ayuda importante y práctica para hacer
reflexionar a las pequeñas organizaciones acerca de su proceso de adquisición de productos
software, y (ii) el método ha sido útil en la obtención del producto deseado y además es una
buena forma de mejorar este proceso dentro de la organización.

Mediante la aplicación del método se logro observar que en la actividad Planear existen algunas
tareas que es necesario que sean revisadas nuevamente con el proveedor seleccionado, como lo
es: la tarea Definir y analizar requisitos del producto software a adquirir. Esta tarea es compleja
para aquellas pequeñas organizaciones, como la empresa participante EES, que no cuenta con
conocimientos suficientes en procesos de recolección de requisitos, motivo por el cual se dificulta
garantizar que los requisitos especificados en esta tarea sean los adecuados.

A partir de esta experiencia en un entorno real, se puede destacar que el uso del método para la
adquisición de productos software fue enriquecedor, tanto para la organización adquiriente como
para el grupo de investigación que definió el método, permitiendo a los investigadores ver la
utilidad de las actividades propuestas y refinar las mismas con este primer acercamiento para la
adquisición en un entorno real.

5.4 Focus Group

Para la evaluación del método de adquisición de software en pequeñas organizaciones se siguió el

método de focus group. La estructura procedimental utilizada para llevar a cabo el focus group fue
la presentada en (Mendoza, M.,et al, 2013) que es orientada a la aplicación de focus group dentro
de la ingeniería de software y mediante la cual se llevaron a cabo las siguientes fases: (i)
Planeamiento de la investigación, (ii) Definición de grupos de discusión, (iii) Conducción de la
sesión de debate, y (iv) Análisis de la información y reporte de resultados. La sesión de debate fue
llevada a cabo durante 2 horas con el grupo de discusión compuesto por 4 personas expertas en el
tema pertenecientes tanto a la academia (1) como a la industria (3). En esta sesión se debatió
sobre las actividades, tareas, productos de trabajo, roles, diagramas, plantillas, facilidad de
aplicación y necesidad del método, y para ello se hizo uso del planeamiento, materiales, encuestas
y demás artefactos diseñados para tal fin. Los resultados de la sesión de debate evidenciaron
aspectos positivos del método propuesto, entre otros: el método propuesto es necesario para las
pequeñas organizaciones, además de considerar que éste es una buena ayuda para disminuir la
incertidumbre y evitar el fracaso a la hora de adquirir un producto software. Además, se considera
que el método propuesto es fácil para ser aplicado en la pequeña empresa, ya que las actividades,
tareas, roles y productos de trabajo del mismo son apropiados para ser utilizados por este tipo de
organizaciones. De la misma manera, el focus group reflejó que los diagramas presentados
describen de forma clara el método y las actividades propuestas, además las plantillas utilizadas
para la descripción de las actividades del método son claras y concisas. Una versión extendida de
esta evaluación se puede encontrar en (Erazo, L., et al, 2013).

Además, para dar soporte a la ejecución del método propuesto también se construyó una
herramienta software que permite guiar paso a paso a las personas involucradas durante la
adquisición de un producto software y gestionar la documentación generada durante éste
proceso. La evaluación de esta herramienta software también fue realizada por personas expertas.
Para esta evaluación se utilizaron las siguientes métricas de funcionalidad establecidas en la
norma ISO/IEC 9126- 2 (ISO/IEC, 2013): (i) métricas de idoneidad funcional, para medir la aparición
de funciones u operaciones insatisfechas de un sistema durante las pruebas y la utilización por
parte del usuario, y (ii) métricas de precisión, para medir la frecuencia con la que los usuarios
encuentran cálculos erróneos o resultados inexactos. La información para determinar la medida
de cada una de estas métricas se recolectó mediante una encuesta diligenciado por los expertos
que utilizaron la herramienta. Finalmente la evaluación de la herramienta software refleja que
ésta si apoya y es apropiado para la ejecución del método propuesto, es importante destacar que
las historias de usuario especificadas necesarias para la ejecución del método, fueron
implementadas en su totalidad y según la métrica de idoneidad se tiene que la completitud de la
implementación funcional está en un cien por ciento.

6. CONCLUSIONES Y TRABAJOS FUTUROS

En este trabajo se describió la forma en que fue diseñado y planteado el método para la
adquisición de software para pequeñas organizaciones, el cual fue aplicado a la empresa
participante EES. Los diferentes miembros de la empresa quienes participaron durante la
aplicación del método de adquisición propuesto expresaron que éste era útil y práctico para
intentar adquirir un producto software que se ajuste a las necesidades, presupuesto y en general
al contexto de la organización.

A partir del trabajo realizado se pudo comprobar la importancia que tiene este proceso en una
organización, ya que cuando se lleva a cabo un proceso de adquisición apropiado las
probabilidades de obtener el producto software adecuado son mayores. Así mismo se documentó
la forma como se obtuvieron las actividades del método a partir de las comparaciones realizadas
entre los referentes relacionados con la temática.

El trabajo desarrollado sienta las bases para futuras investigaciones en el área de adquisición, así
como la posibilidad de adaptar el método a cualquier tipo de empresa independiente del sector
productivo al que pertenezca, ya que son los stakeholders potenciales de la documentación
generada y presentada en este artículo.

Como trabajo futuro se pretende que las otras actividades del método sean seguidas por la EES
con el fin de adquirir el producto software adecuado. Además se realizarán otros casos de estudio
del método propuesto al interior de nuevas pequeñas organizaciones. También se tiene planeado
implementar una herramienta software que soporte la ejecución del método, con el fin facilitar la
aplicación del mismo por las pequeñas organizaciones.

7. AGRADECIMIENTOS

Los autores agradecen a la Universidad del Cauca por el apoyo durante la realización de este
trabajo.

8. REFERENCIAS

Ministerio de Comercio. Industria. y Turismo, D.d.M., Reporte de Mipymes No. 3, 2009.

L, Elissondo., Auditoría de la adquisición de software, 2004, Universidad Nacional del Centro de la

Provincia de Buenos Aires: Buenos Aires.

HURTADO Gasca, G.P., Metodología de Gestión de Riesgos para la Adquisición de Software en

Pequeños Entornos - MEGRIAD, in Departamento de Lenguajes y Sistemas informáticos e
ingeniería del Software2000: Madrid, Espana. p. 191.

ISO, ISO/IEC 12207 - Systems and software engineering - Software life cycle processes, 2007,
International Organization for Standardization: Geneva. p. 122.

WEBER, K., et al., MPS Model-Based Software Acquisition Process Improvement in Brazil, in
QUATIC 2007 - Sixth International Conference on the Quality of Information and
Communications2007: Lisboa, Portugal. p. 110–119.

PMI, Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK), 2008, Project
Management Institute. p. 406.
IEEE, IEEE Recommended Practice for Software Acquisition, 1998, The Institute of Electrical and
Electronics Engineers: New York. p. 49.

ISO/IEC, Software Engineering - Lifecycle Profiles for Very Small Enterprises (VSE) - Part 1:
Overview, 2007. p. 24.

LAPORTE, C., A. April, and A. Renault, Applying International Software Engineering Standards in
Very Small Enterprises. CrossTalk The Journal of Defense Software Engineering, 2007. 20(2): p. 29-
30.

PINO, F., F. Garcia, and M. Piatini, Software process improvement in small and medium software
enterprises: a systematic review. Software Qual J, 2008.

GALLAGHER, B.P., Gestión de Riesgos en Adquisición de Software - área clave del Proceso (KPA)
version 1.02, 1999, Software Engineering Institute: Pittsburgh. p. 103.

Aaby, A.A., A Simple Software Acquisition Process, 2006. p. 7.

TARDY, J.E., Strategies for Software Acquisition, in A MAP For Software Acquisition 1991.

MOSKO, M., et al., COTS Software Acquisition Meta- Model. p. 6.

COHEN, Julie., A.L., LEVINE, Linda NOVAK William, PLACE, Patrick., RAY Williams., WOODY, Carol.,
Software Acquisition Planning Guidelines, 2005, Software Engineering Institute: Pittsburgh. p. 62.

GOLDENSON, D.r. and FISHER, M.j Improving the Acquisition of Software Intensive Systems, 2000,
Software Engineering Intitute. p. 54.
PINO, F., et al., , Harmonizing maturity levels from CMMI-DEV and ISO/IEC 15504. Journal of
software maintenance and evolution: Research and practice, 2009.

PARDO, Cesar et al., An ontology for the harmonization of multiple standards and models. Elsevier,
2011: p. 59.

OKTABA, H.J., MORALES, M.e. and M. Dávila, KUALI-BEH: Software Project Common Concepts
Version 1.1, 2012.

COMPETISOFT and CYTED, COMPETISOFT - Mejora de Procesos para Fomentar la Competitividad

de la Pequeña y Mediana Industria del Software de Iberoamérica. 2006.

PINO, F., et al., A software maintenance methodology for small organizations: Agile MANTEMA.
JOURNAL OF SOFTWAREMAINTENA
CMMI v 1.3 para Adquisición primer en Castellano
Lunes 4 de Junio de 2012
CMMI v 1.3 para Adquisición primer en Castellano
Hola a todos los que tengan a bien pasarse por esta página.

A continuación podéis encontrar la traducción del artículo "CMMI V 1.3 for Acquisition
primer " que puede encontrarse en su versión original en la siguiente
dirección:http://www.sei.cmu.edu/library/abstracts/reports/11tr010.cfm?WT.DCSext.abstra
ctsource=BrowseStacks

Tras releer no con mucho cuidado me he dado cuenta que la traduccion puede no ser muy
afortunada con algunas expresiones y que una lectura apresurada da como resultado
algunos fallos de prisa cuando lo traduje. Ahora mismo no tengo mucho tiempo, pero le he
dado un lavado de cara para que sea más sencillo seguirlo y no se confundan algunas
partes.

Las tablas a veces pueden ser maravillosas ;-)

La traducción que presento está estudiada y ha sido propuesta como traducción oficial a la
universidad de Carnegie Mellon, aunque ellos difieren en el uso de palabras como
"requisito" en lugar de "requerimiento" y otras cosas por el estilo, por lo que se publica esta
traducción, que como digo es muy fiel al original, pero que NO ES OFICIAL o pudiera
contener algún error, es decir que en la traducción se pudiera perder algo del contexto,
aunque por la naturaleza de guía inicial del documento, y la calidad de la misma, creo que
no hay problema posible. En cualquier caso, estoy abierto a sugerencias.

El texto está a continuación, para tener una copia en pdf, solo tenéis que pedírmela por
correo electrónico. ¡¡¡Es gratis!!!

Un saludo

--------------------------------------------------------------------------------------

Índice de contenido
1 Introducción
1.1 Propósito y objetivos
1.2 Terminología CMMI
1.3 Mejora de procesos para la Adquisición
1.3.1 Mejoras de procesos a nivel de proyecto
1.3.2 Mejoras de los procesos de la organización
2 Áreas de proceso
2.1 Áreas de proceso de gestión de proyectos
Planificación de Proyecto (PP)
1. Estimaciones de los parámetros del plan de proyecto son establecidas y mantenidas
2. Un plan de proyecto se establece y mantiene como las bases de gestión del proyecto
3. Los compromisos de cara al plan de proyecto son establecidos y mantenidos.
Monitorización y Control de proyecto (PMC)
1. Progreso real del proyecto y rendimiento son monitorizados contra el plan de proyecto
2. Acciones correctivas son manejadas al cierre cuando el rendimiento del proyecto o los
resultados se desvían significativamente del plan
Gestión de proyecto integrada (IPM)
1. El proyecto se lleva a cabo usando un proceso definido a medida desde un conjunto de
los procesos estándar de la organización
2. Se llevan a cabo la coordinación y colaboración entre el proyecto y las partes interesadas
más relevantes.
Gestión del Riesgo
1. Se lleva a cabo la preparación para la gestión del riesgo
2. Los Riesgos son identificados y analizados para determinar su importancia relativa
3. Los riesgos son manejados y mitigados, de forma apropiada para reducir los impactos
adversos a la hora de conseguir los objetivos
Solicitud y Acuerdo de Desarrollo con Proveedores. (SSAD)
1. Se lleva a cabo la preparación para la solicitud y el acuerdo de desarrollo con
proveedores.
2. Los proveedores se seleccionan usando una evaluación formal
3. Los acuerdos con proveedores se establecen y se mantienen.
Gestión de los acuerdos (AM)
1. Los términos del acuerdo con el proveedor deben cumplirse tanto por parte del
adquiridor como del proveedor.
Gestión de Requisitos (REQM)
1. Los requisitos son gestionados y las inconsistencias con los planes de proyecto y
productos de trabajo son identificados.
2.2 Áreas de proceso de ingeniería de adquisición
Desarrollo de requisitos para la adquisición (ARD)
1. Las necesidades de las partes interesadas, sus expectativas, limitaciones, e interfaces se
recogen y transmiten en los requisitos de cliente
2. Los requisitos de cliente se refinan y e incluyen como requisitos contractuales
3. Los requisitos son analizados y validados.
Gestión Técnica de Adquisición (ATM)
1. Las soluciones a nivel técnico son evaluadas para confirmar que los requisitos
contractuales van a ser alcanzados.
2. Gestionar los interfaces seleccionados.
Verificación de la adquisición (AVER)
1 Se dirige la preparación para la verificación.
2. Se realizan revisiones de los pares en los productos de trabajo seleccionados.
3 Los productos de trabajo seccionados se verifican contra sus requisitos específicos
Validación de la Adquisición (AVAL)
1. Se dirige la preparación para la validación
2. Seleccionar productos y componentes de productos a ser validados para asegurar que son
adecuados para usar en el medio en que pretenden ser usados
2.2 Analizar resultados de las actividades de validación
2.3 Áreas de soporte de procesos
Gestión de la Configuración
1. Se establecen las líneas base de productos de trabajo identificados.
2. Los cambios a los productos de trabajo bajo la gestión dela configuración se monitorizan
y controlan.
3. Se establece la integridad de las líneas base y se mantiene
Análisis de Decisión y Resolución (DAR)
1. Las decisiones se basan en una evaluación de alternativas usando el criterio establecido.
Mediciones y Análisis (MA)
1 Los objetivos y actividades de medida están alineados con las necesidades de la
información identificada y los objetivos.
2. Se proveen los resultados obtenidos sirvan a las necesidades de la información y los
objetivos
Proceso para la garantía de calidad del producto (PPQA)
1. Se evalúa la adhesión de los procesos llevados a cabo y los productos de trabajo
asociados a las descripciones de proceso aplicable, los estándares, y los procedimientos.
2. Los problemas de incumplimiento son objeto de seguimiento y comunicación y se debe
asegurar su resolución.
3. Prácticas Genéricas
1. Establecer y mantener una política organizacional para planificar y llevar a cabo los
procesos.
2. Establecer y mantener el plan para llevar a cabo los procesos
3. Proveer los recursos adecuado para llevar a cabo el proceso, desarrollando los productos
de trabajo y proveyendo los servicios del proceso.
4. Asignar responsabilidad y autoridad para llevar a cabo el proceso, desarrollando el
producto de trabajo, y proveyendo los servicios del proceso.
5. Enseñar a la gente a llevar a cabo el proceso o a darle soporte tal y como el proceso
necesite.
6 Colocar los productos de trabajo seleccionados bajo los niveles de control apropiados.
7. Identificar e involucrar a las partes interesadas relevantes para el proceso tal y como se
planificó.
8. Monitorizar y control el proceso contra el plan para llevar a cabo el proceso y tomar las
acciones correctivas pertinentes
9. Evaluar de forma objetiva la adhesión del proceso y los productos de trabajo
seleccionados contra la descripción del proceso, los estándares, y los procedimientos, y
comprobar incumplimientos.
10. Revisar las actividades, estado, y resultado de los procesos con mas alto nivel de
dirección y resolver los problemas hallados.
11. Establecer y mantener la descripción de un proceso definido.
12. Recoger las experiencias relacionadas con procesos derivadas de la planificación y
ejecución de procesos para dar soporte al uso futuro y mejora de los procesos de la
organización, así como de los activos de sus procesos.
Apéndices
Preguntas sobre implementación
Resumen
Esta guía básica identifica prácticas que son más efectivas y eficientes para proyectos de
adquisición de productos y servicios. Prestando especial atención a la mejora a un nivel de
proyecto, este manual selecciones un subconjunto de prácticas desde el modelo CMMI para
la Adquisición (CMMI-ACQ). Estas prácticas incluyendo monitorización y control de los
proveedores y contratas tanto para la ejecución efectiva y repetida del producto tanto como
para el desarrollo de servicios y la entrega de los mismos. Tras usar este manual, los
lectores serán capaces de expandir el uso de las mejores prácticas en sus proyectos de
adquisición y sus organizaciones estarán posicionadas para explorar el uso del modelo
CMMI_ACQ.
1 Introducción
El manual básico de CMMI para la adquisición (CMMI-ACQ) es una guía independiente
que describe prácticas a usar cuando los se van a adquirir productos o servicios. Esta guía
también sirve de preparación para implementar el modelo CMMI para la adquisición
(CMMI-ACQ) para la mejora de procesos.

Este manual básico se centra en procesos de adquisición eficientes y efectivos y prácticas

que se implementan en proyectos de adquisición de primer nivel, tales como los que son
conducidos por una oficina de programación de sistemas, o un director de programa en el
Departamento de Defensa, o un departamento de compras o una cadena de suministro en
una corporación.

Este manual básico también puede ser usado por las organizaciones que gestionan múltiples
programas (por ejemplo centros de producción, grupos de adquisición, ingenieros de
contratación, dirección en la cadena de suministro) para implementar actividades de mejora
de los procesos. De cualquier modo, a un nivel de organización, el modelo CMMI-ACQ es
más beneficioso y completo. (ver sección 1.3).

1.1 Propósito y objetivos

Los proyectos de adquisición son complejos porque se dirigen su punto de vista tanto hacia
dentro de la organización como hacia fuera. Hacia fuera es cuando se fija en los productos a
adquirir, los sistemas, servicios y capacidades para cumplir un conjunto de expectativas
operacionales. Dirige el punto de vista hacia dentro para asegurar que el proceso de
adquisición se lleva a cabo con disciplina. El modelo CMMI-ACQ incorpora esta dualidad
para reconocer que algunas actividades están bajo el control directo del proyecto de
adquisición, mientras que otras conllevan monitorizar y/o facilitar el éxito de compañeros
externos y proveedores.

Los proyectos de desarrollo se enfrentan al reto de conseguir un rendimiento agresivo en

costes, y de planificación de los objetivos en el tiempo. Al mismo tiempo, los líderes de la
adquisición crean un medio flexible para sus proyectos, mientras que se decrementa de un
modo drástico el ciclo de vida de la adquisición y se mejora la credibilidad:

 Elevando los niveles de de complejidad de productos y servicios;

 Incrementando la contribución del software a la funcionalidad del sistema global;
 Demandando productos ágiles y adaptables;
 Tiempos de entrega de productos mucho más cortos, ..
Todo lo anterior supone un aumento del estrés en las prácticas de adquisición. Tanto las
guías del Congreso como del Departamento de Defensa enfatizan en la mejora de los
procesos de adquisición del software, incluyendo las medidas de rendimiento de los
procesos.
El modelo CMMI-ACQ está diseñado para influir en el resultado del proceso de
adquisición tal que se entreguen las capacidades adecuadas a los usuarios en el tiempo
planificado y a los costes predichos a través de la aplicación disciplinada de procesos de
adquisición efectivos y eficientes.
Aplicar esta aproximación requiere una dedicación para definir, implementar, medir y
mantener los procesos de adquisición que son fundamentales para un proyecto técnico
sano.
Los proyectos de adquisición suponen llevar a cabo un número de procesos para conseguir
el éxito.
El primer objetivo y las prácticas que corresponden a estos procesos se describen en
términos generales para soportar las variaciones de la aplicación que pueden ocurrir en
diferentes medios de adquisición (diferentes clientes, diferentes tiempos).
Dado que las variaciones en la ejecución se dan en diferentes momentos de la vida de un
proyectos de adquisición, el modelo CMMI-ACQ y esta guía se centran en “qué” debe
hacerse, no “cómo” debe hacerse; ningún documento CMMI prescribe aproximaciones a
las implementaciones específicas.

1.2 Terminología CMMI

Este manual básico usa terminología del modelo CMMI-ACQ, que agrupa las áreas de
proceso en las siguientes categorías de área de proceso:
 Gestión de procesos (p.ej: Dirección de la organización).
 Gestión de proyectos.
 Soporte.
 Ingeniería de adquisición.
La gestión de la mayoría de los procesos, la gestión de proyectos y las áreas de soporte son
comunes a todos los modelos CMMI. Este hecho hace conveniente que deban alinearse los
procesos entre el adquiridor y el proveedor si el proveedor usa el CMMI para desarrollo
(CMMI-DEV) o CMMI para Servicios (CMMI-SVC).
Las áreas de procesos de la ingeniería de adquisición son específicas al modelo CMMI-
ACQ como también lo son dos de las áreas de proceso para gestión de proyectos.
Las áreas de proceso de gestión de procesos en el modelo CMMI-ACQ proveen detalles en
cómo se definen y mejorar los procesos dentro del contexto de la organización en que
reside el proyecto de adquisición.
El modelo CMMI-ACQ también contiene aquellas áreas de gestión de proyectos y procesos
de soporte consideradas que contienen prácticas a un nivel más alto de madurez que
aquellas que están contenidas este manual básico.
Para más información acerca de la gestión de procesos y de las áreas de madurez alta, ver el
modelo CMMI-ACQ en http://www.sei.cmu.edu/library/abstracts/reports/10tr032.cfm

Planificación de proyecto (PP)

Gestión Proyecto, Monitorización y Control

de (PMC)
Proyectos Gestión de Proyecto Integrada (IPM)

Gestión del Riesgo (RM)

 Solicitud y Acuerdo de Servicio con
Proveedores (SSAD)
Gestión de Acuerdos (AM)
Gestión de Requisitos (REQM)

Requisitos para el Desarrollo de la

Adquisición (ARD)
Ingeniería
de Gestión Técnica de la Adquisición (ATM)
Adquisición Verificación de la Adquisición (AVER)

Validación de la Adquisición (AVAL)

Gestión de la Configuración
(CM)
Análisis de Decisión y
Resolución (DAR)
Soporte
Medidas y Análisis (MA)
Asegurado de la Calidad de
Procesos y Productos
(PPQA)
Figura 1.-Áreas de proceso cubiertas en este manual básico.
Es importante entender la terminología CMMI en ambos contextos, el de adquisición y el
procesos de mejora, antes de usar este manual básico. Por ejemplo, en la Suite de Productos
CMMI, es importante comprender los siguientes términos:
 El término proyecto denota un conjunto de recursos interrelacionados que son
gestionados para enviar uno o más productos a un cliente o usuario final. Un proyecto (o
programa, dependiendo de la interpretación local) se refiere a un proyecto de adquisición
completo o, quizás, a subconjuntos importantes del proyecto inicial de adquisición.
El ámbito del término está hecho a medida para cada adquisición especifica (el término
proyecto no se usa en este caso en el modelo CMMI-SVC. En su lugar se usan los términos
trabajo y grupo de trabajo).
 El término organización es típicamente usado para denotar una estructura
administrativa en la cual la personas gestionan de forma colectiva uno o mas proyectos. Los
proyectos comparten un gestor principal y operan bajo las mismas políticas. Ejemplos de
organizaciones de adquisición pueden ser ayuntamientos, oficinas donde se llevan a cabo
desarrollo de servicios o programas, centros de producción en general, empresas de
selección de personal y contratación o departamentos de una empresa que supone una
cadena de suministro, comandos de adquisición, oficinas ejecutivas de programa, y
empresas ejecutivas que se dedican a la adquisición de productos y servicios.
 El término producto de trabajo es cualquier cosa producida por un proceso.
 El término producto denota un resultado tangible o un servicio que es, a su vez, el
resultado de un proceso y que se pretende que pueda enviarse a un cliente o usuario final.
Un producto es un producto de trabajo que se envía al cliente. El término sistema no se usa;
el término producto se usa en su lugar e incluye a los servicios.
 El término proveedor se usa en lugar del término contrata ya que los acuerdos pueden
tomar formas diferentes a los contratos, tales como memorandos o acuerdos de nivel de
servicio.
 El término acuerdo de proveedor se usa en lugar del término contrato. Un acuerdo de
proveedor es un documento de acuerdo entre el adquiridor y el proveedor (p.ej.- contratos,
licencias)
Se ha de decidir cómo estos términos se aplican en el medio de trabajo en que el lector trata
de aplicar esta guía básica.

1.3 Mejora de procesos para la Adquisición

La mejora de procesos puede verse desde dos perspectivas: a nivel de proyecto y a nivel de
organización. Ambos son importantes para sostener la mejora de procesos en una
organización de adquisición.
1.3.1 Mejoras de procesos a nivel de proyecto
Los proyectos de adquisición aseguran que las prácticas que se llevan a cabo efectivamente
reducen los riesgos asociados a la gestión común, técnica, y da soporte a los problemas que
surgen durante el proyecto.
Las prácticas específicas en la sección 2 y las prácticas genéricas en la sección 3 representa
los niveles prácticos del proyecto que pueden usarse para identificar lagunas en la
implementación del proyecto o bien los riesgos relacionados. El uso cauteloso de las
medidas seleccionadas puede ayudar a ganar una mejor visión de la efectividad de la
implementación de los procesos a nivel de proyecto.
En suma, las organizaciones de adquisición de mas alto nivel con múltiples proyectos o con
responsabilidad de supervisión pueden usar estas prácticas para identificar áreas que
puedan requerir hacer un mejor enfoque en mejoras de los procesos. Un proyecto que tiene
los procesos bien definidos tiene una mucho mayor habilidad para lidiar con riesgos y con
complejidad.

1.3.2 Mejoras de los procesos de la organización

La mejora de procesos a un nivel organizacional crea un medio efectivo y una
infraestructura que permite proyectos de adquisición bajo control de la organización con
una mucho mayor probabilidad de éxito. Cuando un proyecto tiene una guía clara, tal como
ejemplos de partida que sirven de referencia, datos históricos de experiencias similares, y
una fuerte cultura de proceso a un nivel organizacional, es mucho más probable que pueda
mantener prácticas efectivas y lograr sus objetivos de una forma definitiva.
Las organizaciones de adquisición que gestionan múltiples programas (p.ej.- centros de
producción, comandos de adquisición, oficinas ejecutivas de programa, ingeniería de
 contratación o departamentos de gestión de cadena de suministro) pueden ser mejorados
por los medios siguientes:
 Trabajar con proyectos exitosos para capturar historias de éxito,
 Medir la efectividad de los procesos a lo largo de los proyectos que se gestionan , y..
 Comenzar a construir un conjunto de prácticas de adquisición estándar, probadas por su
éxito en proyectos reales, para su uso en proyectos que vendrán a continuación.
Los líderes senior pueden establecer una infraestructura y una fuerte cultura basada en los
procesos que recompense a los proyectos que construyen planes realistas y los ejecutan de
acuerdo a esos mismos planes.
Las organizaciones de adquisición pueden mejorar la capacidad de sus procesos
organizacionales y la capacidad de los procesos en niveles de proyectos seleccionados a lo
largo de la organización usando el modelo CMMI-ACQ. Las áreas de proceso a usar
cuando se mejoran la capacidad organizacional incluyen la concentración en el proceso
organizacional, la definición de procesos organizacionales y el entrenamiento
organizacional. El modelo CMMI-ACQ está disponible en:
http://www.sei.cmu.edu/library/abstracts/reports/10tr32.cfm

2 Áreas de proceso
Las áreas de proceso en esta sección son seleccionadas del modelo CMMI-ACQ.
Representan un conjunto mínimo de procesos que cubren las mejores prácticas necesarias
para hacer frente al ciclo de vida completo en la adquisición a nivel de proyecto. Cada
proyecto de adquisición opera en un único medio que influye la definición de su ciclo de
vida.
El ciclo de vida de adquisición, especialmente dado que se aplica a las actualizaciones y
modificaciones, puede reiniciarse después de que el ciclo haya sido iniciado y completado
parcialmente. Por ejemplo, la adquisición de una actualización mayor puede ser iniciada
para un producto o servicio que ya ha sido desarrollado, enviado y puesto en operación. En
estos casos, la explotación de CMMI-ACQ podría resultar en la consideración de
adquisición de la actualización y comenzar un nuevo ciclo de vida, con la compleja
implementación de sus propios requisitos que podrían impactar en otros ciclos de vida de
adquisición que pudieran todavía estar en marcha, incluyendo los borrados.
Las áreas de proceso en esta sección listan los objetivos en texto plano. Bajo cada objetivo
se numeran declaraciones que reflejan las prácticas recomendadas. Para un tratamiento mas
extensivo de estos objetivos y prácticas, ver el modelo CMMI-ACQ, que también incluye
sub-prácticas, ejemplos de productos de trabajo, ejemplos de entregables del proveedor, y
referencias a otras áreas de proceso relacionadas.

2.1 Áreas de proceso de gestión de proyectos

Las áreas de proceso de gestión de proyectos cubren las actividades de gestión del
proyectos relacionadas al plan, monitorización y control de proyectos, incluyendo asegurar
el alineamiento de los planes y los productos de trabajo con los requisitos. En suma,
incluyen actividades que aseguran que los productos o servicios adquiridos pueden hacer la
transición al uso operacional y pueden ser mantenidos durante la vida operacional del
producto o servicio. Se incluyen dos áreas de proceso específicas de la adquisición. La
primera describe las actividades que llevan a la firma de un acuerdo los proveedores
elegidos. La segunda describe las actividades asociadas con la gestión del acuerdo
resultados con los proveedores elegidos.

Planificación de Proyecto (PP)

El propósito de la planificación de proyecto es establecer y mantener planes que definen las
actividades del proyecto.
La planificación del proyecto comienza por establecer la estrategia de adquisición y sigue con
la planificación de los procesos de la adquisición en un nivel incremental de detalle. Los
planes resultantes deberían ser revisados para la consistencia con el plan global de
adquisición. Los procesos de planes de proyecto del adquiridor y el proveedor son llevados a
cabo de forma continua, lo que indica que podrían cambiar dado que los planes evolucionan
para cumplir las necesidades del proyecto.
Si un producto existente se ha de reemplazar como una parte de la adquisición, el adquiridor
puede ser requerido para considerar la transición desde el estado de operación incluido el
borrado del producto existente como una parte del plan para ejecutar el nuevo producto.
Cualquiera que sea esta actividad de transición debe ser incluidas en el plan de proyecto, dado
que sera necesario para acomodar esos requisitos especiales
1. Estimaciones de los parámetros del plan de proyecto son establecidas y
mantenidas
1.1 Establecer y mantener la estrategia de adquisición
La estrategia de adquisición relata los objetivos de la adquisición, limitaciones, disponibilidad
de activos y tecnología, consideración de los métodos de adquisición, tipos de acuerdos con
proveedores potenciales y términos de dichos acuerdos, conciliación de las exigencias de los
usuarios finales, consideración de riesgos y soporte para el proyecto a lo largo del ciclo de
vida.

1.2 Establecer un alto nivel de trabajo en la estructura de descomposición (WBS) para

estimar el ámbito del proyecto.
El WBS debería listar las tareas para el proyecto completo,incluyendo actividades que lleva a
cabo el proyecto de adquisición, los proveedores y otras partes interesadas (p.ej.- comunidades
de test, usuarios operacionales). Incluye todas las partes para asegurar que los esfuerzos de
planificación incluyen el ámbito para la adquisición completa.

1.3 Establecer y mantener las estimaciones de los productos de trabajo y atributos de las
tareas.
Estimaciones de los atributos de los productos de trabajo y las tareas que se usan para limitar
el presupuesto y planificación en fechas.

1.4 Definir las fases del ciclo de vida del proyecto en el que se debe aplicar el esfuerzo de
la planificación
El ciclo de vida típico suele definirse como en pasos simples o de evolución incremental. En
la planificación se incluye el ciclo de vida conocido completo desde las necesidades del
usuario hasta las primeras y siguientes actualizaciones La organización de adquisición debería
considerar la colección completa de acuerdos de proveedor dentro el contexto de un proyecto
para asegurar una aproximación integrada, mejor que una aproximación que tenga que lidiar
con actividades individualmente. Una aproximación integrada soporta las actividades de
planificación de proyectos en ocasiones cuando algunos elementos de la adquisición o ciclo de
vida pueda estar fuera del control de la organización de la adquisición.

1.5 Estimar el esfuerzo del proyecto, así como el coste, para los productos de trabajo y
las tareas basadas en estimación racional
En suma, para crear una estimación de los productos de trabajo de un proyecto, la
organización de adquisición debería tener sus estimaciones independientemente revisadas por
aquellos externos al proyecto para validar dichas estimaciones. Debe de asegurar incluir el
esfuerzo y coste de soportar la ejecución de los procesos de adquisición así como el esfuerzo
de soportar el desarrollo del producto o servicio. Las estimaciones del esfuerzo y coste de los
productos de trabajo y las tareas se usan para establecer el presupuesto y planificación en
fechas del proyecto globalmente.

2. Un plan de proyecto se establece y mantiene como las bases de gestión del

proyecto

2.1 Establecer y mantener el presupuesto del proyecto y su planificación en fechas

El presupuesto del proyecto de adquisición y la planificación en fechas debería ser creada y
mantenida para que dure mientras dura el proyecto. El presupuesto y planificación debería
incluir actividades de la organización de adquisición relacionadas con el ciclo de vida en sí
mismo, el proveedor, las organizaciones de soporte, los proveedores que dan soporte a la
organización de adquisición y otras partes interesadas.

2.2 Identificar y analizar los riesgos del proyecto

Identificar riesgo desde múltiples perspectivas (p.ej- adquisición, técnicas, de gestión,
operacionales, de proveedor, de soporte y de usuario) para asegurar que todos los riesgos del
proyecto se han considerado en la planificación de las actividades.

2.3 Planificar la gestión de los datos del proyecto

Considerar como los datos serán compartidos a través de todas las partes interesadas
relevantes, incluyendo datos informales así como datos y planes formales relativos al
proyecto. Crear planes para gestionar datos con equipos integrados y la infraestructura
requerida para gestionar datos entre el proveedor, los usuarios operacionales y otras partes
interesadas relevantes. Decidir qué datos de proyectos y qué planes requieren control de
versión o control de configuración más estrictas y establecer mecanismos para asegurar que
los datos de proyecto se controlan. Considerar la implicación controlar el acceso a
información clasificada así como el acceso a información sensible aunque no clasificada
(p.ej.- propietarios, control de la exportación, e información sensible de selección de fuentes)
y otros datos de acceso controlado.

2.4 Planificar los recursos para llegar al objetivo del proyecto

Planificar los recursos requeridos para el proyecto de adquisición así como las herramientas y
la infraestructura requerida durante la vida del proyecto. Incluir la planificación de recursos
para la integración y las instalaciones de cara a realizar pruebas.

2.5 Planificación para el conocimiento y las habilidades necesarias para llegar al objetivo
Planificación para el conocimiento y las habilidades requeridas por el equipo de proyecto para
llevar a cabo sus tareas. El conocimiento y las habilidades requeridas pueden derivarse desde
los riesgo del proyecto. Por ejemplo, si el equipo de proyecto está adquiriendo un producto de
software intensivo, asegurar que existe un grado experto en sistemas e ingeniería del software
en equipo de proyecto o bien provéase entrenamiento para el equipo de proyecto en estas
áreas. Incluir orientación y entrenamiento para el equipo de proyecto y las partes interesada en
las prácticas de adquisición y el dominio del cocimiento requerido para ejecutar el proyecto.

2.6 Planificar la implicación de las partes interesadas identificadas

Las partes interesadas pueden incluir usuarios operacionales y participantes del proyecto desde
comunidades de prueba o de soporte así como proveedores potenciales. Cuando se adquieren
productos o servicios que deben interoperar con otros productos o servicios, planificar de cara
a la implicación de las partes interesadas desde otros proyectos o comunidades para asegurar
que el producto o servicio puede funcionar como se ha requerido en el medio en que se
pretende que funcione.

2.7 Planificar la transición a operaciones y soporte

El proyecto de adquisición es responsable de asegurar que los productos adquiridos no solo
cumplen los requisitos específicos (ver el área de proceso de la Gestión Técnica de la
Adquisición) sino que también pueden hacer la transición al uso operacional para conseguir
las misión de cumplir las expectativas de capacidad de los usuarios y que pueda ser mantenido
y sostenido a través de los ciclos de vida que se pretende que tenga el proyecto.
El proyecto de adquisición es responsable de asegurar una planificación razonable para que se
lleve a cabo la transición al plano de operaciones. Unos criterios de transición claros deben
existir y estar de acuerdo con las partes relevantes. La planificación se completa para el
mantenimiento y soporte del producto o productos después de que pasen a la parte operacional
del ciclo de vida. Estos planes incluyen una conciliación razonable para productos conocidos
así como para las potenciales evoluciones de los mismos y su eventual eliminación del uso
operacional.
La planificación para la transición incluye establecer la estrategia de soporte (p.ej.- la fuente
de reparación) a través del soporte orgánico de infraestructuras, la logística de soporte del
proveedor, u otras fuentes. También puede incluir la definición de los niveles de soporte a ser
establecidos (p.ej.- organización, intermedio y almacén). La estrategia es importante porque
conlleva la mayoría de las otras actividades de transición, así como las consideraciones al
diseño de los productos.
Planificar incluye identificar y proveer los repuestos iniciales, las capacidades operacionales y
de soporte, instalaciones, etc. Finalmente la eliminación de un producto debería también ser
considerada así como la eliminación de productos existentes que podrían ser reemplazados.
Los roles y responsabilidades del adquiridor, el proveedor y el usuario deberían ser definidos
para la duración del ciclo de vida de soporte del producto. Explícitamente identificando las
responsabilidades organizacionales de cara al soporte (p.ej.-, nivel 1 mantenimiento) y para las
mejoras(p.ej.-, nivel 2, mantenimiento) asegurando que la partes interesadas relevantes se
involucran desde los primeros estadios de los procesos de planificación del proyecto de
adquisición.
La responsabilidad de la capacidad de mejora durante la fase de soporte debería ser asignada.
Los criterios usados para dar soporte a la asignación de las responsabilidades debería incluir la
magnitud y complejidad de los cambios previstos, el dominio del conocimiento y la
experiencia requerida y el grado experto en adquisición requerido.

2.8 Establecer y mantener el plan de proyecto global

El plan de proyecto global puede tomar muchas formas y puede incluso ser encontrado en
múltiples planes, tales como los de estrategia de adquisición, plan simple de gestión de la
adquisición, plan de gestión de programa, plan de gestión de los ciclos de vida y plan de
ingeniería de sistemas.
Independientemente de su forma, el plan o planes deberían llevar a cabo la estrategia de
adquisición así como las consideración “desde la cuna a la tumba” para que tanto el proyecto
como el producto a ser adquirido.

3. Los compromisos de cara al plan de proyecto son establecidos y mantenidos.

3.1 Revisión de todos los planes que afectan al proyecto para entender los compromisos
del proyecto.
El proyecto puede tener una jerarquía de planes (por ejemplo, el plan de gestión de riesgos,
sistemas de plan de ingeniería, y el plan de necesidades de gestión). Además, los planes de las
partes interesada(por ejemplo, operacionales, de prueba, soporte, y planes de proveedor) deben
ser revisados para garantizar la coherencia entre todos los participantes en el proyecto.

3.2 Ajuste del plan de proyecto para reconciliar los recursos estimados y los disponibles
Cuando los recursos disponibles (p.ej.- personal, instalaciones, partes interesadas,
planificación en fechas y financiación) son inadecuados para cumplir con el proyecto,
considérese desfocalizar el esfuerzo para que se ajuste a los recursos disponibles. Cuando se
desfocalizar no es posible, identifíquense y mitíguense los riesgos

3.3 Obtener un compromiso de la partes interesadas mas relevantes responsable de

llevar a cabo y dar soporte a la ejecución del plan
Los planes de proyecto principales deberían estar coordinados con las partes interesadas
relevantes y los planes resultantes deberían ser aprobados por ellos también.

Monitorización y Control de proyecto (PMC)

El propósito de la Monitorización y Control de proyecto es proveer un entendimiento del
progreso del proyectos, tal que se puedan tomar acciones correctivas apropiadas cuando el
rendimiento del proyecto se desvía significativamente del plan.
Las funciones de monitorización y control del proyecto se dirigen desde las primeras fases del
proyecto en el proceso de adquisición dado que la planificación se lleva a cabo y la estrategia
esta definida. Como el proyecto de adquisición se despliega, monitorizar y controlar son
esenciales para asegurar que los recursos apropiados son aplicados y que las actividades de la
adquisición progresan de acuerdo al plan. El área de proceso de control y monitorización
conlleva establecer las actividades internas y la planificación en fechas para completar y
después monitorizar el estado de completado de estas actividades y productos a través de las
medidas y el análisis (p.ej.- métricas), Es importante que el proyecto de adquisición tenga
procesos internos, planes y productos de trabajo que sean monitorizados para el completado
satisfactorio y el progreso del proyecto.
Se debe incluir en aquellos artículos internos monitorizados el completado del producto (p.ej.-
especificaciones, planes y peticiones para los componentes propuestos), los niveles del
personal y las cualificaciones que se apliquen, el rendimiento de los objetivos del proyecto y
de los umbrales, la preparación de la infraestructura (p.ej.- herramientas y redes) y oras
actividades y productos incluidos en la planificación del proyecto. La identificación y
mitigación de los riesgos del proyecto también debería monitorizarse para conocer su estado.
Después de que se seleccionen uno o mas proveedores y se hayan establecido los acuerdos, el
rol de la monitorización y el control se convierte en dos aspectos: (1) el adquiridor, continua
con la monitorización y control de las actividades y productos de trabajo, (2) al mismo tiempo,
el adquiridor monitoriza y controla el proceso y rendimiento de las actividades del proveedor
que afectan al plan de proyecto global.

1. Progreso real del proyecto y rendimiento son monitorizados contra el plan

de proyecto
1.1 Monitorizar los valores reales de los parámetros del proyecto contra los que figuran
en el plan de proyecto
Monitorizar la planificación en fechas, el presupuesto y el progreso de las actividades de
adquisición debería comenzar tan pronto se establezca el plan de proyecto.

1.2 Monitorizar los compromisos contra aquellos que se identificaron en el plan de

proyecto
Los compromisos sobre recursos que resultan en gastos (p.ej.-ordenes de compras con
problemas y entregables completados que han sido aceptados) deberían ser objeto de
seguimiento cuando ocurran, incluso priorizado al pago forman, para asegurar que las
obligaciones futuras financieras y legales son contabilizadas tan pronto como se incurre en
ellas.

1.3 Monitorizar los riesgos contra aquellos que se identificaron en el plan de proyecto
El proyecto de adquisición debería gestionar los riesgos independientemente de los los
procedimientos de gestión de riesgos del proveedor. Muchos riesgos son la responsabilidad
del proyecto de adquisición y pueden incluir información sensible que no debería ser
compartida con el proveedor (p.ej.- la selección de fuentes sensibles, las formas de
competencia, e información interna sobre el personal).

1.4 Monitorizar la gestión de los datos de proyecto contra lo que figura en el plan de
proyecto

1.5 Monitorizar la implicación de las partes interesadas contra lo previsto en el plan de

proyecto

1.6 Revisiones periódicas del progreso del proyecto, rendimiento y problemas

encontrados

1.7 Revisar el cumplimiento del proyecto y los resultados en hitos seleccionados del
proyecto

1.8 Monitorizar la transición a las fases de operación y soporte

El adquiridor monitoriza y controla la transición de los productos o servicios contra el plan
para la transición a la fase de operación y soporte. La preparación se evalúa a través del ciclo
de vida del la adquisición y se basa en los criterios para la transición. Usando los criterios de
transición previamente definidos, objetivamente se evalúan la preparación de los productos
para la transición.
Como resultado del análisis, las actividades de transición y las acciones que pueden ser
requeridas por el proyecto de adquisición, el proveedor, usuarios o la organización de soporte.
El análisis también puede identificar áreas para la mejora en actividades de transición futuras.
2. Acciones correctivas son manejadas al cierre cuando el rendimiento del
proyecto o los resultados se desvían significativamente del plan
2.1 Recolectar y analizar problemas y determinar acciones correctivas para dirigir
dichos problemas a sus solución.
Las acciones correctivas se llevan a cabo tanto cuando existen desviaciones por parte del
adquiridor como cuando la ejecución por parte del proveedor no está alineada con el plan de
proyecto (p.ej.- hitos y desvíos en productos de trabajo)
Muchos problemas y acciones correctivas son la sola responsabilidad del adquiridor y pueden
incluir información que no debería ser compartida con el proveedor (p.ej.- selección de fuentes
sensible, formas de competencia e información interna sobre el personal).

2.2 Tomar acciones correctivas en problemas identificados

Las acciones correctivas deberían ser aplicadas cuando la ejecución no logra los planes de
proyecto (p.ej.- personal interno, fechas clave en el plan de proyecto, borrador y solicitudes
finales, y acuerdos de proveedor en fechas marcadas como hitos).

2.3 Gestionar las acciones correctivas al cierre

Si una acción correctiva se requiere para resolver variaciones desde el plan de proyecto, estas
acciones deberían ser definidas y ser objeto de un seguimiento al cierre.
Gestión de proyecto integrada (IPM)
El propósito de la gestión integrada de proyecto es establecer y gestionar el proyecto y la
implicaciones de las partes interesadas relevantes de acuerdo a un proceso integrado y
definido que está hecho a medida desde el conjunto de los procesos estándar de la
organización.

La gestión integrada de proyecto engloba establecer los procesos de gestión de proyecto que
están hechos a medida y son consistentes con los procesos estándar de la organización.
Incluye un nivel de adquisición mas alto, guía, regulaciones, instrucciones y establecer
prácticas locales para ser usadas a través de varios proyectos en la organización local.
Establecer un proceso de gestión integrada de proyecto que incorpora y engloba a las partes
interesadas relevantes ( p.ej.- oficina de adquisición de nivele ejecutivo, organizaciones de
usuarios de prueba, desarrolladores, y organizaciones de soporte asociadas a la gobernanza) es
crítico para el éxito del proyecto. Este proceso definido para la gestión del proyecto es
típicamente definido en un plan de proyecto global de gestión o documento equivalente.
El proceso de gestión integrada de proyecto necesita involucrar e integrar todas las actividades
relevantes de adquisición, desarrollo, soporte, y operacionales. Dependiendo del tamaño del
proyecto, el tamaño de de los esfuerzos de coordinación puede ser significativo.
Los interfaces formales entre las partes interesadas del proyecto toman la forma de
memorandos de entendimiento (MOUs), memorandos de acuerdos (MOAs), compromisos
contractuales, acuerdos de los proveedores asociados y documentos similares, dependiendo en
la naturaleza de los interfaces y las partes interesadas involucradas.

1. El proyecto se lleva a cabo usando un proceso definido a medida desde un

conjunto de los procesos estándar de la organización

Es posible que la organización no haya establecido un conjunto de procesos estándar. Si es así,

el proyecto debería definir sus propios procesos apropiados a sus necesidades.

1.1 Establecer y mantener el proceso definido del proyecto desde el inicio del mismo a
través de la vida del proyecto
A menudo el proceso definido para un proyecto se desarrollad mediante la realización a
medida de los procesos y la integración de la guía por parte de niveles organizacionales más
altos. Por ejemplo, la guía en la de “Defense Acquisition Guidebook (http:// akss.dau.mil/dag/)
[Guía para la adquisición en defensa] en conjunción con las guías a bajo nivel del servicio,
componentes u otro nivel, se usarían en un proyecto para establecer el proceso a ser usado
para adquirir el único producto o servicio para el proyecto. Donde no existe un proceso
organizacional, el proyecto desarrolla el proceso definido por sí mismo.
Este proceso definido para el proyecto se conduce por la estrategia de adquisición. El proceso
definido por el adquiridor se ve afectado, por ejemplo, por si la estrategia de adquisición
incluye introducir una nueva tecnología para la organización o para consolidar productos o
servicios que ya estaban en uso por parte del adquiridor.
1.2 Usar los activos de los procesos de la organización así como el repositorio de métricas
para estimar y planificar las actividades del proyecto
Cuando estén disponibles, usar los resultados de planes y ejecución de actividades previas
como predictores del ámbito relativo y el tamaño del esfuerzo que se estima para la
adquisición.

1.3 Establecer y mantener el medio de producción del proyecto basado en los estándares
de la organización.
El medio donde trabaja el proveedor debería ser compatible con el medio donde trabaja el
adquiridor para habilitar de forma efectiva y eficiente transferencia de productos de trabajo
entre ellos

1.4 Integrar el plan de proyecto y otros planes que afecten al proyecto para describir el
proceso refinado para el proyecto.
Los planes basados en niveles a menudo son los más efectivos para grandes proyectos

1.5 Gestionar el proyecto usando el plan de proyecto, otros planes que afecten al
proyecto y el proceso definido del proyecto

1.6 Establecer y mantener equipos de trabajo

Una de las mejores maneras de asegurar la coordinación y la colaboración con las partes
interesadas relevantes (objetivo específico 2 de este área de proceso) es incluirlos en un
equipo. Para proyectos con un sistema de marco de sistemas, el equipo mas importante puede
incluir a las partes interesadas que representen otros sistemas como miembros.

1.7 Contribuir con experiencias basadas en procesos a los activos de procesos

organizacionales
Si un repositorio de información desde proyectos similares previos existe al comienzo del
proyecto, considérese retener las estimaciones del proyecto y los resultado reales para uso en
la estimación de futuros proyectos.
2. Se llevan a cabo la coordinación y colaboración entre el proyecto y las partes
interesadas más relevantes.
2.1 Gestionar la implicación de las partes interesadas relevantes para el proyecto
Los acuerdos de proveedor proveen las bases para gestionar la implicación del proveedor ene l
proyecto. Los acuerdos de proveedor (p.ej.- acuerdos entre agencias y entre compañías,
memorandos de entendimiento, y memorandos de acuerdos) que el adquiridor hace con las
partes interesadas delas organizaciones, las cuales pueden ser productos o proveedores de
servicios o beneficiarios, proveer las bases para lograr la implicación. Estos acuerdos son
particularmente importantes cuando el proyecto del adquiridor produce un sistema que debe
ser integrado en un sistema de sistemas mayores.
2.2 Participar con las partes interesadas más relevantes para el proyecto para
identificar, negociar y realizar un seguimiento de las dependencias críticas
Las actividades de las partes interesadas que incluyen dependencias criticas para el proyecto
deberían ser negociadas con dichas partes interesadas para obtener compromisos para llevar a
cabo. Las dependencias criticas deberían ser identificadas en el plan de proyecto para que
dichas actividades puedan ser monitorizadas y controladas de forma relativa a las actividades
de que dependen.
3. Resolver problemas con las partes interesadas más relevantes.
Gestión del Riesgo
El propósito de la gestión del riesgo es identificar problemas potenciales antes de que ocurran,
así que el manejo de las actividades de riesgo pueda ser planeado y se use a través de la vida
del producto o proyecto para mitigar los impactos adversos a la hora de conseguir los
objetivos.

La identificación de riesgos y estimación de las probabilidades de ocurrencia e impacto,

particularmente para aquellos riesgos involucrados en conseguir el rendimiento requerido, las
planificaciones en fechas, y los objetivos de coste, ampliamente determinan la estrategia de
adquisición. El adquiridor tiene un rol dual:(1)Toma y gestiona los riesgos globales del
proyecto durante la duración total del mismo, y (2)Toma y gestiona los riesgos asociados con
el rendimiento del proveedor. Dado que la adquisición progresa hacia la selección de un
proveedor, el riesgo especifico de la gestión técnica del proveedor y la aproximación a la
dirección entonces se vuelve importante para el éxito de la adquisición.
El riesgo particular asociado con los equipos integrados debería ser considerado, del mismo
modo debería considerarse los riesgos asociados con la pérdida de la coordinación inter-
equipos o interna a cada equipo.

1. Se lleva a cabo la preparación para la gestión del riesgo

1.1 Determinar las fuentes del riesgo y sus categorías
Las organizaciones de adquisición deberían inicialmente identificar y categorizar riesgos y
fuentes de riesgo para el proyecto y refinar esos riesgos y categorías a través del tiempo (p.ej.-
planificación en fechas, costes, ejecución del proveedor, preparación de la tecnologías, y
problemas fuera del control de la organización de la adquisición).

1.2 Definir parámetros usados para analizar y categorizar riesgos y controlar el esfuerzo
para la gestión del riesgo
Las organizaciones de adquisición deberían documentar los parámetros usados para analizar y
categorizar riesgos tal que estén disponibles a través del a vida del proyecto para tener
referencias cuando las circunstancias cambien a lo largo del tiempo. De este modo, los riesgos
pueden ser fácilmente re-categorizados y analizados relativamente a la información original
cuando ocurran los cambios.

1.3 Establecer y mantener la estrategia a usarse para la gestión del riesgo

2. Los Riesgos son identificados y analizados para determinar su importancia

relativa
2.1 Identificar y documentar riesgos

2.2 Evaluar y categorizar cada riesgo identificado usando categorías de riesgo definidas
y parámetros, y determinar su prioridad relativa
3. Los riesgos son manejados y mitigados, de forma apropiada para reducir los
impactos adversos a la hora de conseguir los objetivos
3.1 Desarrollar un plan para mitigar riesgos de acuerdo con la estrategia de gestión de
riesgos

3.2 Monitorizar el estado de cada riesgo periódicamente e implementar el plan para

mitigar riesgos como sea apropiado.
Los riesgos deben ser continuamente monitorizados y, cuando esté garantizado, el plan para
mitigarlos debería ajustarse para adaptarse al cambio. Cuando la situación requiere acción, las
acciones de mitigación deberían ser ejecutadas sin demora basándose en el plan de mitigación.
Solicitud y Acuerdo de Desarrollo con Proveedores.
(SSAD)
El propósito de la solicitud y acuerdo de desarrollo (SSAD) es preparar un paquete de
solicitud, seleccionar uno o más proveedores para entregar el producto o servicio, y establecer
y mantener el acuerdo de proveedor.

La solicitud debe cumplir con las políticas y regulaciones federal, departamentales, y del
servicio de adquisición. La solicitud debería llevar a cabo actividades apropiadas para el
dominio del producto o el medio de la adquisición (p.ej.-, evaluaciones de proceso de
proveedores; seguridad operacional, idoneidad, y efectividad; certificaciones,; evaluaciones de
la arquitectura; e interoperabilidad). Los representantes responsables de estas actividades
dentro del proyecto o en la organización por parte de las partes interesadas deberían ser
consultadas para la correcta inclusión de aquellas actividades dentro de la solicitud y el
desarrollo del proceso para el acuerdo de proveedor. Las prácticas de solicitud se aplican igual
a las acciones iniciales sobre el acuerdo del proveedor y los subsiguientes cambios, ordenes de
tareas, etc...
El área de proceso de solicitud y desarrollo de acuerdo de proveedor crea un medio proactivo
que habilita al adquiridor a inicializar la relación con el proveedor para la ejecución exitosa
del proyecto. Fomenta la creación de un acuerdo de proveedor que permita al adquiridor
ejecutar su gestión sobre las actividades del proveedor usando otras áreas de proceso, tales
como La Gestión de Acuerdos y la Gestión Técnica de Adquisición. Este fomento puede
incluir percibir un requisito sobre el proveedor para crear un plan de proyecto que ejecutará
exitosamente el acuerdo de proveedor, para definir y ejecutar el proceso necesario para llegar
al éxito, y para acometer la ejecución del plan según evoluciona durante la ejecución del
acuerdo de proveedor.

1. Se lleva a cabo la preparación para la solicitud y el acuerdo de desarrollo

con proveedores.
1. Identificar y calificar a proveedores potenciales
1.2 Establecer y mantener un paquete de solicitud que incluya los requisitos y proponga
un criterio de evaluación
Para las órdenes de tareas o cambios contra un acuerdo de proveedor existente, asegurar que el
proyecto de adquisición tiene documentados los criterios de evaluación contra los cuales
evaluar los cambios propuestos desde el proveedor.
Definir el contenido de la propuesta que el proveedor debe enviar con su respuesta.

Ejemplos incluidos:
 Evidencia de procesos organizacionales existentes en los que se basarán los procesos
del proyecto y el compromiso para ejecutar aquellos procesos desde el inicio del proyecto.
 Las descripciones en los documentos propuestos tales como las declaraciones de
trabajo (SOW), el plan maestro integrado (IMP), la planificación en fechas maestra integrada
(IMS), y el plan de desarrollo de software (SDP) de los procesos, tareas y actividades
características de la aproximación del desarrollo propuesta.
 La descripción de como la aproximación propuesta (p.ej.- SOW, IMP,IMS,SDP u otros
documentos) demuestra un compromiso para ejecutar el proyecto usando los procesos y
métodos propuestos desde el inicio del proyecto. Se requiere a los proveedores que entreguen
evidencias de mecanismos para fomentar y monitorizar la ejecución de procesos
organizacionales al inicio del proyecto. Se requiere a los proveedores describir medidas que
provean visibilidad del equipo de trabajo en el proceso de adhesión del proveedor.
 La descripción de cómo la aproximación propuesta demuestra alta confianza es que el
tamaño y complejidad del esfuerzo para el desarrollo e integración se entiende correctamente;
el esfuerzo y planificación en fechas es necesario para desarrollar los productos requeridos se
estima con una alta confianza, y que el esfuerzo de desarrollo propuesto es compatible y puede
ser completado dentro de los gastos propuestos y en las fechas acordadas.
 Los planes son apropiados en el ámbito y contenido del proyecto (p.ej.- el plan de
gestión integrado, el plan de ingeniería de sistemas, el plan de desarrollo de software, y el plan
de gestión de riesgos).
 La identificación de las métricas, incluyendo las métricas de progreso del desarrollo,
serán usadas en el proyecto y serán puestas a disponibilidad de la oficina del proyecto.
 Una descripción del uso planificado del proveedor de COTS o un re-uso de
componentes hardware o software desarrollados previamente, incluido componente no
entregables (esta descripción debería identificar cualquier limitación de los derechos y razón
de ser de los datos para la confianza del proveedor para que puedan alcanzarse los niveles de
COTS y su reutilización).
 Una aproximación que provea visibilidad del progreso de las atareas de desarrollo y
costes a un nivel apropiado para el tipo de acuerdo del proveedor y que sea proporcional al
grado de riesgo relativo a la adquisición.
 Identificación del trabajo a ser llevado a cabo por proveedores de más bajo nivel.
 Actividades y tareas propuestas para dar soporte a la verificación del producto, la
validación y la transición a la fase de operaciones y soporte.
 Verificaciones técnicas, no técnicas y de producto han de ser satisfechas por el
proveedor.
 Entregables que proveen al proyecto de adquisición suficientes datos para evaluar y
analizar los productos adquiridos.
 Requisitos que aseguran que el proveedor da soporte a cada revisión técnica y
actividad de validación en cada uno de los proyectos de adquisición.
 Requisitos para que el proveedor establezca un sistema de acciones correctivas que
incluya un proceso de control de cambios para re evaluación y rehacer productos de trabajo si
es necesario.
La organización de adquisición debería solicitar evidencia de adhesión a los mecanismos de la
organización del proveedor para el comienzo del proyecto de acuerdo con sus procesos
definidos.

1.3 Revisar el paquete de solicitud con las partes interesadas mas relevantes para
obtener el compromiso al enfoque.
Para asegurar objetiva y realísticamente, las estimaciones de costes y la planificación deberían
ser revisadas por individuos independientes al equipo del proyecto de adquisición y del equipo
del proveedor.
Individuos representativos de la organización funcional u “oficina principal” de la
organización de la adquisición, tales como ingenieros y financieros, pueden ocuparse de este
tipo de tareas.

1.4 Distribuir el paquete de solicitud a los potenciales proveedores para su respuesta y

mantener el paquete mientras dura el proceso de solicitud
En un medio ambiente competitivo, asegurar que todos los proveedores potenciales tienen el
mismo acceso y oportunidad de dar su retroalimentación al paquete de solicitud. Proveer la
oportunidad para que los proveedores seleccionados y usuarios finales puedan clarificar
puntos ambiguos en el conjunto de capacidades requeridas así como desconexiones o
preocupaciones con la solución propuesta. En una una fuente orden de cambio de medio,
asegurar que las partes interesadas relevantes entienden el intento del nuevo esfuerzo o los
cambios antes de de añadir trabajos adicionales al acuerdo de proveedor.
2. Los proveedores se seleccionan usando una evaluación formal
2.1 Evaluar las soluciones propuestas de acuerdo al criterio documentado de selección de
propuestas.
Los criterios que se usan para evaluar la aproximación técnica del proveedor así como sus
prácticas de gestión, planes de suficiencia, procesar la capacidad en los puntos claves de las
áreas de riesgo del proyecto, experiencia en dominios relevantes, coste, planificación y
rendimiento en el pasado.
2.2 Establecer y mantener los planes de negociación para usar a la hora de completar un
acuerdo con un proveedor.
2.3 Seleccionar proveedores basándose en una evaluación de su capacidad para cumplir
los requisitos específicos así como el criterio de selección utilizado

3. Los acuerdos con proveedores se establecen y se mantienen.

3.1 Establecer y mantener un entendimiento mutuo de los acuerdos con los proveedores
seleccionas y los usuarios finales basados en las necesidades de la adquisición y los
enfoques propuestos por los proveedores.
Dado que los puntos de clarificación y las ambigüedades continúan saliendo tras la elección
del proveedor concreto así como del acuerdo con dicho proveedor, se debe asegurar que el
entendimiento mutuo se revisa y mantiene a través de la vida del proyecto. Asegurar que el
proveedor realiza un compromiso en el acuerdo de proveedor para ejecutar sus procesos
propuestos
3.2 Establecer y mantener el acuerdo con el proveedor.
El proyecto de adquisición es responsable de establecer y mantener las reglas de base para la
comunicación con el proveedor, documentando decisiones y resolviendo conflictos a través de
la vida del proyecto. El proyecto de adquisición facilita estas actividades con las partes
interesadas relevantes para el proyecto. Los roles específicos y las responsabilidades de las
partes interesadas relevantes para el proyecto de cara a la su interacción con bien la dirección,
bien los proveedores necesita ser definida, coordinada y adherida.

Después de que el acuerdo de proveedor haya sido seleccionado, el proyecto de adquisición

debería verificar que el proveedor es efectivamente ejecutando sus procesos de organización.
Tras establecer ella cuerdo de proveedor, el adquiridor puede encontrar requisitos que no
resultan óptimos o aplicables basándose en el progreso del proveedor o los cambios en el
medio ambiente de trabajo.
Los ejemplos incluyen la disponibilidad de nueva tecnología, carga excesiva de
documentación y requisitos de reportes. Cambios a los acuerdos del proveedor pueden ocurrir
cuando los procesos de proveedor o los productos fallan al no cumplir los criterios contenidos
en el acuerdo.
Gestión de los acuerdos (AM)
El propósito de la Gestión de los Acuerdos (AM) es asegurar que el proveedor y el adquiridor
llevan a cabo el proyecto de acuerdo a los términos del acuerdo de proveedor.

El acuerdo de proveedor es la base para gestionar la relación con el proveedor, incluyendo la

resolución de problemas. Define los mecanismos que permiten al adquiridor tener una visión
global de las actividades del proveedor y la evolución de los productos y para verificar
cumplimiento con los requisitos del acuerdo de proveedor.
También es el vehículo para un entendimiento mutuo entre el adquiridor y el proveedor.
Cuando el rendimiento del proveedor, los procesos o productos fallan al a hora de satisfacer
los criterios establecidos tal y como se contemplan en el acuerdo del proveedor, el adquiridor
debe tomar acciones correctivas.

1. Los términos del acuerdo con el proveedor deben cumplirse tanto por parte
del adquiridor como del proveedor.
1.1 Las actividades se llevan a cabo con el proveedor tal y como se especifica en el
acuerdo con el proveedor.
El adquiridor y el proveedor establecer y mantienen un entendimiento mutuo a través de
comunicaciones apropiadas, efectivas y en tiempo. El adquiridor debería claramente
identificar y priorizar sus necesidades y expectativas, tanto como las capacidades del
proveedor. El adquiridor trabaja de forma cercana a los proveedor para conseguir un
entendimiento mutuo de los requisitos de los productos, las responsabilidades y los procesos
que se aplican para conseguir los objetivos del proyecto.

1.2 Seleccionar, monitorizar y analizar los procesos del proveedor.

Los planes y procesos del proveedor se usan como las bases para monitorizar sus actividades.
El proyecto de adquisición es responsable de asegurar que los procesos del proveedor se
ejecutan tal y como se han implementado en los planes y acuerdos para hacer frente a las
necesidades del proyecto. El proyecto de adquisición debería verificar que los procesos del
proveedor se ejecutan desde el inicio del proyecto.
Si no se llevan a cabo con el cuidado adecuado, monitorizar puede llegar a ser invasivo y
gravoso, en el otro extremo puede ser inefectivo y causar desinformación. El adquiridor decide
los niveles de monitorización necesarios dependiendo en el nivel de riesgo asignado si los
procesos del proveedor no tienen el rendimiento correcto esperado. Las actividades de
monitorización pueden cubrir desde revisar los datos de procesos del proveedor provistos
hasta las evaluaciones de los procesos del proveedor.1

1.3 Asegurar que el acuerdo del proveedor es satisfecho antes de aceptar el producto
adquirido.
Esta practica involucra asegurar que el producto adquirido cumple todos los requisitos y que
los clientes están de acuerdo antes de que el producto sea aceptado. El adquiridor asegura que
todos los criterios han sido satisfechos y que todas las discrepancias han sido corregidas. Los
requisitos formales para la aceptación de los entregables y como llevar a cabo los entregables
que no han cumplido los requisitos está usualmente definido en el acuerdo del proveedor. El
adquiridor debería estar preparado para ejecutar todos los remedios posibles si el proveedor
falla en su cometido.

1.4 Gestionar las facturas enviadas por el proveedor.

La intención de esta práctica es asegurar que los términos definidos en cuanto al pago en ella
cuerdo de proveedor son satisfechos y que la compensación del proveedor está unida al
progreso del proveedor comos e define en el acuerdo de proveedor. Esta práctica cubre las
facturas para cualquier tipo de cargo (p.ej.- una vez, mensual, basado en entregables, a través
del proyecto). Cubre los posibles errores en facturas, cambios en las mismas, errores de
cuentas, y retenciones en los cargos que sean consistentes con los términos y condiciones del
acuerdo de proveedor. El adquiridor debe también asegurar que los controles a la gestión
financiera y de facturas se realizan de forma correcta.

Gestión de Requisitos (REQM)

El propósito de la gestión de requisitos es gestionar los requisitos de los productos del
proyecto y los componentes de los productos para asegurar la alineación entre aquellos
requisitos y los planes y productos de trabajo.

La gestión de requisitos procesas la gestión de todos los requisitos recibidos o generados por
el proyecto, incluyendo tanto requisitos técnicos como no técnicos, así como requisitos
generados por la organización del proyecto. La gestión de requisitos se aplica también a los
requisitos que se reciben desde el proceso de desarrollo de requisitos de la adquisición. La
gestión de requisitos incluye la gestión directa de los requisitos de los clientes que controla el
adquiridor y los requisitos contractuales (ver el área de proceso de desarrollo de requisitos de
adquisición) y supervisar la gestión de los requisitos del proveedor. Los requisitos se
gestionan y mantienen con disciplina tal que los cambios no se ejecuten sin reconocer el
impacto al proyecto.
La gestión de requisitos no termina con la selección de un proveedor y con la elección final
del mismo. El proceso de adquisición continua para gestionar los requisitos de alto
nivel,incluyendo cambios, mientras que los proveedores seleccionados manejan el producto a
mas bajo nivel así como los requisitos de los componentes del producto.
1. Los requisitos son gestionados y las inconsistencias con los planes de
proyecto y productos de trabajo son identificados.
1.1 Desarrollar un entendimiento con los proveedores sobre el significado de los
requisitos.
El adquiridor debería identificar requisitos “autorizados” para los proveedores así como una
forma aprobada de que dichos requisitos sean comunicados al proveedor. Esta identificación
previene a los proveedores de recibir cambios en los requisitos de fuentes no autorizadas que
están fuera del flujo establecido por los procesos de gestión de requisitos del adquiridor.

1.2 Obtener un compromiso sobre los requisitos por parte de los participantes en el
proyecto
El compromiso sobre los requisitos por parte de los participantes del proyecto incluye haber
coordinado y aprobado documentos que definen requisitos. Cambios a los requisitos pueden
llevar a cambios en los acuerdos de proveedor. Estos cambios deben acordarse por el
proveedor y el adquiridor tras negociaciones apropiadas.

1.3 Gestionar cambios en los requisitos según evolucionan durante la vida del proyecto
Para cada cambio de un requisito controlado debería tenerse en cuenta el posible impacto en el
rendimiento del proyecto, el coste, y la planificación de las líneas base de cara al posible
riesgo que suponga para el proyecto. El coste existente en la planificación y las líneas base del
rendimiento deberían cambiarse tal y como se requiere, para acomodar el cambio realizado en
los requisitos. Si los requisitos contractuales definidos en el acuerdo de proveedor se ven
afectados por los cambios, el acuerdo de proveedor también debe ser alineados con estos
cambios.

1.4 Mantener la trazabilidad bidireccional entre los requisitos y los productos de trabajo.
Cuando los requisitos se gestionan correctamente, se puede establecer la trazabilidad desde la
fuente de requisitos a su mas bajo niveles y de aquellos de mas bajo nivel de vuelta a sus
requisitos fuente. Esta trazabilidad bidireccional ayuda a determinar si los requisitos fuente
han sido llevados a cabo completamente de acuerdo al proyecto o si todos los requisitos de
bajo nivel pueden trazarse hasta unos requisitos de fuente válidos.2

La trazabilidad de requisitos debe también cubrir las relaciones entre otras entidades, tales
como los productos de trabajo intermedios y finales, los cambios en el diseño de la
documentación, y los planes de pruebas. La trazabilidad puede cubrir tanto relaciones
horizontales (como puede ser entre interfaces) como relaciones verticales. La trazabilidad es
particularmente necesaria a la hora de llevar a cabo el impacto activo de los cambios de los
requisitos en las actividades de un producto y los productos de trabajo.
El proveedor mantiene obligatoriamente la trazabilidad bidireccional para los requisitos
definidos en el acuerdo de proveedor por el adquirido, y el adquiridor verifica la trazabilidad.
El adquiridor mantiene la trazabilidad bidireccional entre los requisitos de cliente y los
requisitos contractuales.

1.5 Asegurar que el plan de proyecto y los productos de trabajo permanecen alineados
con los requisitos.
2.2 Áreas de proceso de ingeniería de adquisición
El proceso de ingeniería de adquisición establece un conjunto consistes de requisitos y
acuerdos que se derivan de las necesidades de las partes interesada y la capacidad
operacional de los diferentes estamentos tal que los productos de trabajo desarrollados
internamente por el adquiridor y los productos de trabajo, productos entregables, y servicios
desde los proveedores son probados para satisfacer de forma exitosa las necesidades del
usuario final y proveer capacidades operacionales. Estas áreas de proceso complementan
las dos áreas de proceso especificas de la adquisición consideradas parte de la categoría de
gestión de proyecto—Solicitud y Desarrollo de Acuerdo de Proveedor (SSAD) y Gestión
de Acuerdos (AM).

Desarrollo de requisitos para la adquisición (ARD)

El propósito del Desarrollo de requisitos para la adquisición es obtener, desarrollar y analizar

los requisitos de cliente y contractuales.
El Desarrollo de requisitos para la adquisición tiene dos contextos. El primer contexto es la
reunión y coordinación de los requisitos de las partes interesadas en un nuevo conjunto de
requisitos que define el ámbito y dirección de la adquisición. El segundo contexto es el de
refinar y elaborar los requisitos del cliente en requisitos contractuales que puedan convertirse
en las bases del producto y los requisitos de los componentes del producto derivados y
desarrollados por el proveedor.
Los requisitos incluyen en el paquete de solicitud desde las bases para evaluar propuestas por
los proveedor y para negociaciones mas avanzadas con los proveedores y comunicación el
cliente. Los requisitos contractuales para el proveedor están basados en el acuerdo de
proveedor.
Cuando se adquieren servicios en lugar de productos, se usa el mismo proceso para definir
necesidades operacionales de alto nivel y para asignar aquellas necesidades a los componentes
de mas bajo nivel del servicio para asegurar que el resultado del servicio cumple con la
intención original.

1. Las necesidades de las partes interesadas, sus expectativas, limitaciones, e

interfaces se recogen y transmiten en los requisitos de cliente
1.1 Obtener las necesidades de las partes interesadas, sus expectativas, limitaciones e
interfaces para todas las fases del ciclo de vida del producto.
Esta práctica incluye revisar, coordinar y formalizar las necesidades operacionales de más alto
nivel y los requisitos con el usuario.

1.2 Transformar las necesidades de las partes interesadas, sus expectativas limitaciones e
interfaces en requisitos de cliente prioritarios.
Esta práctica incluye la transformación de los requisitos de usuario de más alto nivel en
requisitos orientados a la ingeniería que típicamente se incluyen en una solicitud. Los
requisitos también incluyen requisitos no funcionales y otros atributos tales como la
evolución, mantenibilidad y re-usabilidad, los cuales pueden conducir a la definición de
requisitos y arquitectura del producto.
Esta práctica también incluye definir los requisitos de mas alto nivel para los interfaces en un
sistema de sistemas.

2. Los requisitos de cliente se refinan y e incluyen como requisitos

contractuales
2.1 Establecer y mantener los requisitos contractuales que se basan en los requisitos de
cliente.
Los requisitos incluyen no solo la funcionalidad clásica y los requisitos de rendimiento, sino
que también llevan los requisitos de interfaces, tanto si están contenidos en interfaces
separados como si entre las especificaciones de los requisitos.

2.2 Asignar los requisitos contractuales a los entregables del proveedor.

Como cada nivel de requisitos esta definido, hay un proceso de asignación iterativo, un diseño
de alto nivel, y una definición de requisitos (para el siguiente nivel inferior). Más allá del nivel
de la arquitectura, al cual está responsabilidad ha sido asignada al proveedor, esta el role del
adquiridor para supervisar la adecuación de los procesos del proveedor y el flujo de trabajo
descendiente resultado, así como la definición de requisitos de más bajo nivel.

3. Los requisitos son analizados y validados.

3.1 Establecer y mantener los conceptos operaciones y los escenarios asociados.
Los documentos de conceptos de operaciones o documentos similares que definen los
conceptos de para que pretende usarse el proyecto son útiles en el desarrollo de requisitos y el
diseño que definitivamente satisfará las necesidades operacionales del usuario final.

3.2 Analizar los requisitos para asegurar que son necesarios y suficientes.

3.3 Analizar los requisitos para equilibrar las necesidades de las partes interesadas y sus
limitaciones.
Equilibrar las necesidades de las partes interesadas contra las limitaciones tales como el coste
de desarrollo y la planificación o las consideraciones operacionales y de soporte.

3.4 Validar los requisitos para asegurar que el producto resultante cumple con lo que se
pretendía en el medio del cliente final.

Gestión Técnica de Adquisición (ATM)

El propósito de la Gestión Técnica de la Adquisición (ATM) es evaluar las soluciones a nivel
técnico del proveedor y gestionar los interfaces seleccionados de esa solución.
Las actividades de la gestión técnica de la adquisición implican medir el progreso técnicos y la
efectividad de los planes y requisitos. Las actividades incluyen aquellas asociadas con la
medida del rendimiento técnico y llevar a cabo revisiones técnicas. Un proceso de revisión
estructurada debería demostrar y confirmar la completitud de los cumplimiento requeridos y
los criterios de salida tal y como se define en el plan de proyecto y los planes técnicos (p-ej.-
el plan de gestión de ingeniería de sistemas).
Las actividades de Gestión de adquisición técnica descubren deficiencias o anomalías que
frecuentemente resulta en acciones correctivas.
1. Las soluciones a nivel técnico son evaluadas para confirmar que los
requisitos contractuales van a ser alcanzados.
1.1 Seleccionar las soluciones a nivel técnico de los proveedores para ser analizadas y los
métodos de análisis a ser usados.
Dependiendo en donde ocurran los mayores riesgos en el ciclo de vida de la adquisición, el
adquiridor selecciona soluciones técnicas de proveedor para análisis de como reducir aquellos
riesgos. Los métodos de análisis son seleccionados basándose en el tipo de solución técnica
que está siendo analizada.

1.2 Analizar las soluciones técnicas del proveedor seleccionado.

El adquiridor debería seleccionar un diseño de proveedor para analizarlo. El adquiridor
explora la adecuación y completitud de un diseño para revisar las representaciones de
producto (p.ej.- prototipos, simulaciones, modelos, escenarios, y storyboards ) y obtener
3

feedback acerca de ellos desde las partes interesadas más relevantes.

4

El adquiridor puede pedir la entrega o verificación de resultados del proveedor de la solución

técnica, si es aplicable. Los proveedores pueden llevar a cabo verificaciones de forma iterativa
de acuerdo con los análisis técnicos del adquiridor, o bien el proveedor puede pedir llevar a
cabo verificaciones de seguimiento a las soluciones técnicas.

1.3 Llevar a cabo las revisiones técnicas con el proveedor tal y como se define en el
acuerdo con el proveedor.
Las revisiones técnicas (p.ej.- evaluaciones de la arquitectura de la solución) se llevan a cabo a
través del ciclo de vida del proyecto para ganar confianza en que los requisitos, la arquitectura
y e las soluciones técnicas del proveedor son capaces de guiar un desarrollo que resulte en un
producto o servicio que provea la capacidad requerida. Esta actividad debería estar integrada
con las actividades de gestión de riesgos. Las organizaciones maduras, típicamente llevan a
cabo revisiones técnicas usando diferentes técnicas probadas dependiendo del tipo de revisión.
Estas organizaciones amplían las bases de las revisiones a incluir mas allá de las necesidades
de las partes interesadas, las expectativas y las limitaciones.
2. Gestionar los interfaces seleccionados.
2.1 Seleccionar los interfaces que deben ser gestionados
Los interfaces considerados para la selección incluyen todos los interfaces con otros productos
y servicios tanto en las operaciones y los medios de soporte como en los medios para la
verificación y validación y los servicios que dan soporte a estos medios. El adquiridor debería
revisar todos los interfaces con los datos del proveedor para dar una cobertura total a todos los
interfaces cuando se realice la selección.

2.2 Gestionar los interfaces seleccionados

Gestionar los interfaces incluye el mantenimiento de la consistencia de los interfaces a través
de la vida del producto y la resolución de conflictos, incumplimientos y problemas con los
cambios. En un medio “sistema de sistemas”, la gestión de los interfaces entre producto o
servicios adquiridos de proveedor y otros sistemas entre el sistema de sistemas es crítico para
el éxito del proyecto.
Verificación de la adquisición (AVER)
El propósito de la Verificación de la Adquisición es asegurar que los productos de trabajo
seleccionados están de acuerdo a sus requisitos especificados.

La verificación de la adquisición incluye asegurar que los productos de trabajo evolucionan

para cumplir sus requisitos específicos en el proyecto. El proyecto de adquisición debería
también asegurar que una verificación correcta del medio existe y que selecciona los
productos de trabajo para evaluar basándose en un criterio documentado. Las revisiones de los
pares se usan para evaluar los productos de trabajo desarrollados por el proyecto de
adquisición.
El proyecto de adquisición también es responsable de asegurar que el proveedor usa los
métodos apropiados para verificar sus productos de trabajo. En este texto, la comunidad de
pruebas en una parte interesada de importancia muy alta, incluyendo participar en la
planificación de primera nivel a través de la aceptación del producto final. El proveedor y /o la
comunidad de pruebas pueden llevar a cabo muchas de estas prácticas con el proyecto de
adquisición facilitando la corrección de deficiencias o mejoras por parte del proveedor en
seguimiento de la organización de mantenimiento. Es importante que el adquiridor defina al
principio el grado en el que se requiere verificación tanto al inicio del proyecto como más
tarde, cuando se reciben los productos.
Las verificaciones de la evolución de los productos por parte del proveedor son rutinariamente
llevadas a cabo durante toda la ejecución del acuerdo y los resultados son analizados para
determinar la aceptabilidad de los productos (ver las áreas de Gestión de adquisición técnica y
la Gestión de Acuerdos). Las actividades de verificación del proyecto de adquisición deberían
ser designada para reducir las interferencia con las actividades llevadas a cabo por el
proveedor y la comunidad de pruebas y para reducir duplicados de los esfuerzos de
verificación.

1 Se dirige la preparación para la verificación.

1.1 Se seleccionan los productos de trabajo a ser verificados y los métodos de verificación
a ser usados
El adquiridor selecciona los productos de trabajo basados en su contribución a cumplir los
objetivos y requisitos del proyecto, y para tener un control de los riesgos del proyecto. Las
revisiones de los pares son uno de los métodos usados para verificar los productos de trabajo
producidos por el proyecto de adquisición. Otros métodos deberían ser seleccionados cuando
se verifiquen los productos de trabajo desde el proveedor. Ejemplo de estos otros métodos
incluyen demostraciones, inspecciones y pruebas reales.

1.2 Establecer y mantener el medio necesario para dar soporte a la verificación

El proyecto de adquisición debería proporcionar un medio adecuado para llevar a cabo sus
actividades de verificación.

1.3 Establecer y mantener los procedimientos de verificación y los criterios para los
productos de trabajo seleccionados.
2. Se realizan revisiones de los pares en los productos de trabajo seleccionados.

Una revisión de un par es un método para llevar a cabo verificaciones de los productos de
trabajo que hayan tenido gran éxito a la hora de detectar defectos, especialmente en
documentos para requisitos y diseño. El proyecto de adquisición usa la revisión de pares en los
productos seleccionados (p.ej.- solicitud de documentos, planes de ingeniería de sistemas, y
planes de pruebas) se producen internamente para encontrar y quitar defectos y para asegurar
cumplimiento con los estándares de adquisición. Muchos productos de trabajo producidos por
el proyecto de adquisición sitúan la escena para el éxito de proyecto y son críticos para el
rendimiento del proveedor. El proveedor típicamente usas las revisiones de los pares
internamente sobre productos de trabajo internos seleccionados durante el desarrollo, pero el
adquiridor no debería confiar solamente en estos resultados.
1. Preparación para la revisión de los pares de los productos de
trabajo seleccionados
2. Dirigir las revisiones de los pares de los productos de trabajo e
identificar los problemas que resultan de esas revisiones.
3. Analizar los datos acerca de la preparación, dirección, y resultados
de esas revisiones.
3 Los productos de trabajo seccionados se verifican contra sus requisitos
específicos
1. Llevar a cabo verificaciones en los productos de trabajo
seleccionados
2. Analizar los resultados de todas las actividades de verificación.

Validación de la Adquisición (AVAL)

El propósito de la Validación de la Adquisición es demostrar que un producto o servicio
adquirido cumple su propósito cuando se pone en el medio en el que debe actuar.

Las actividades de validación de la adquisición pueden aplicarse a todos los aspectos del
producto o servicio en cualquier de los medios en que se pretenda usar tales como
operaciones, formación, fabricación, mantenimiento y servicios de soporte. Los métodos
empleados para cumplir la validación pueden ser aplicados tanto a los productos de trabajo
como al producto y a los componentes del producto. Los productos de trabajo (p.ej.-
requisitos, diseño y prototipos) deberían ser seleccionados para la validación basándose en
cuales son los mejores predictores de como de bien el producto final ha sido entregado y como
los componentes del producto satisfarán las necesidades de usuario.
La validación incluye asegurar que los productos de trabajo de la adquisición que evolucionan
(p.ej.- RFP's, SOW's y planes) cumplen las necesidades del proyecto de adquisición. Las
actividades de validación son normalmente llevadas a cabo al inicio y continuamente a lo
largo del ciclo de vida e la adquisición. El adquiridor también usa los procesos de validación
para asegurar que el producto o servicio que se recibe desde el proveedor cumplirá con el uso
que se le pretende dar. En este contexto, la comunidad de pruebas en una parte interesada de
gran importancia, participando en la planificación a través de la aceptación de los productos
finales. El proveedor y/o la comunidad de pruebas pueden llevar a cabo muchas de las
prácticas de validación con el proyecto de adquisición facilitando la corrección de deficiencias
o mejoras por parte del proveedor o la organización de seguimiento del mantenimiento.
La validación incluye el desarrollo de los requisitos de la aproximación para la validación,
incluyendo los criterios de aceptación, los cuales son incorporados en ambos, el paquete de
solicitud y ella cuerdo de proveedor. Validaciones de las evoluciones de los productos por
parte de tanto el proveedor como el proyecto son llevadas a cabo de forma rutinaria a través de
la vida del acuerdo de proveedor y los resultados se analizan para determinar la aceptabilidad
de los productos. Las actividades de validación del proyecto deberían designarse para reducir
interferencias con las actividades llevadas a cabo por el proveedor y la comunidad de pruebas
y para reducir el duplicado en esfuerzos de validación. Los procesos de validación dan soporte
a establecer y validar los requisitos. Ver las áreas de proceso de desarrollo de los requisitos de
adquisición para más información.
1. Se dirige la preparación para la validación
1.1 Se seleccionan los productos y los componentes de los productos a ser validados y los
métodos de validación a ser usados
Es importante que el adquiridor defina a la salida del proceso, el grado al cual la validación se
requiere tanto al inicio del proyecto (p.ej.- actividades para la validación de requisitos) o más
tarde cuando se reciben los productos finales.
1.2 Establecer y mantener el medio necesario para dar soporte a la validación
Los planes deberían identificar adecuadamente los recursos para ejecutar las actividades de
validación.
1.3 Establecer y mantener procedimientos y criterios de validación.
Los procedimientos de validación también llevan a cabo la validación de los requisitos y del
producto o servicio adquirido a lo largo del ciclo de vida del proyecto. Típicamente, los
procedimiento de teste para la aceptación formal y los criterios se establecen para asegurar que
el producto o servicio entregado cumple con las necesidades de las partes interesadas antes de
que sea puesto en producción en el medio de destino.
2. Seleccionar productos y componentes de productos a ser validados para
asegurar que son adecuados para usar en el medio en que pretenden ser
usados
2.1 Llevar a cabo la validación en los productos seleccionados y los componentes de los
productos
Las actividades de validación se llevan a cabo por parte del adquiridor, el proveedor o ambas
partes de acuerdo al acuerdo del proveedor.
2.2 Analizar resultados de las actividades de validación

2.3 Áreas de soporte de procesos

Las áreas de soporte de proceso incluyen los procesos y herramientas que se requieren para
permitir a los proyectos efectivamente aplicar medidas, control y técnicas de decisión para
gestionar el proyecto.
Gestión de la Configuración

El propósito de la Gestión de la Configuración es establecer y mantener la integridad de los

productos de trabajo usando identificación de la configuración, control de la configuración,
cuentas de estado de la configuración y auditorias de la configuración.

Los productos adquiridos pueden necesitar estar situados bajo la gestión de la configuración
por ambas partes, el proveedor y el adquiridor. Las provisiones para llevar a cabo la gestión de
la configuración deberían establecer en el acuerdo de proveedor. Los métodos para asegurar
que los datos son completos y consistentes debería estar establecido y ser mantenido.
1. Se establecen las líneas base de productos de trabajo identificados.
1.1 Identificar artículos de configuración, componentes, y productos de trabajo relacionados
para ser situados bajo la gestión de la configuración
Las organizaciones de adquisición deberían identificar y categorizar riesgos y las fuentes de
éstos para el inicio del proyecto y refinar aquellos riesgos a lo largo del tiempo (p.ej.-
planificación, costes, ejecución de proveedores, preparación de la tecnología y problemas
fuera del control de la organización de adquisición).

1.2 Establecer y mantener una gestión de la configuración y un sistema de gestión de cambio

para controlar los productos de trabajo.
El adquiridor considera cómo los elementos de configuración se compartes entre el adquiridor
y el proveedor del mismo modo a como se hace con el resto de partes interesadas. Si el uso de
un sistema de gestión de la configuración del adquiridor se extiende a un proveedor, el
adquiridor debe hacer ejercicios de seguridad y procedimientos de control de acceso. En
muchos casos, dejar los elementos de configuración en posesión, físicamente, del proveedor y
dar acceso a los entregables de dicho proveedor es una alternativa viable. Ella cuerdo de
proveedor especifica de forma apropiada los derechos del adquiridor sobre los entregables del
proveedor en suma a los requisitos para la entrega o el acceso. Los productos de trabajo del
proveedor cuando quiera que sean entregados al adquiridor, se presentan de acuerdo con los
estándares aceptados para asegurar la usabilidad de los mismos por parte del adquiridor.

1.3 Crear o liberar las líneas base para uso interno para envío al cliente
El adquiridor revisa y aprueba el lanzamiento de las líneas base de un producto creado por el
proveedor. El adquiridor crea las líneas base para los productos de trabajo de adquiridor que
describe el proyecto, los requisitos, los fondos económicos, la planificación y las medidas de
rendimiento y crea un compromiso a la gestión del proyecto en base a esas líneas.

2. Los cambios a los productos de trabajo bajo la gestión dela configuración se

monitorizan y controlan.
2.1 Hacer un seguimiento de las solicitudes de cambio a los artículos de configuración
Las solicitudes de cambio pueden ser iniciadas tanto por el adquiridor como por el proveedor.
Los cambios que impactan en los productos de trabajo del adquiridor y en los entregables del
proveedor se definen en el acuerdo de proveedor y se manejan a través de el proceso de
gestión de la configuración del adquiridor.

2.2 Se controlan los cambios a los elementos de configuración.

El adquiridor decide cuales de los elementos de configuración requieren control de versiones o
niveles más rigurosos de control de la configuración y establece mecanismos para asegurar
que los elementos de configuración están controlados.

3. Se establece la integridad de las líneas base y se mantiene

1. Establecer y mejorar los registros que describen artículos de
configuración.
2. Llevar a cabo auditorias de configuración para mantener la integridad de
las líneas base de configuración.
Análisis de Decisión y Resolución (DAR)
El propósito de los análisis de decisión y resolución es analizar las posibles decisiones usando
un proceso de evaluación forman que evalúe las alternativas identificadas contra el criterio
establecido.

1. Es especialmente importante que exista un criterio basado en el proceso de

toma de decisiones que sea repetible tanto cuando se han de tomar decisiones críticas
que definen y guían el proceso de adquisición en sí mismo como cuando, más tarde,
las decisiones críticas se han de tomar con un proveedor específico. El establecimiento
de un proceso de toma de decisiones formal facilita al proyecto de adquisición la
documentación donde se razonan las decisiones tomadas. Tal documentación permite
guardar los criterios para las decisiones críticas para ser re-visitadas cuando se
cambien los requisitos que más impacten en el proyecto o cualquier otro parámetro
crítico del proyecto.
1. Las decisiones se basan en una evaluación de alternativas usando el criterio
establecido.
1. Establecer y mantener las guías para determinar cuales de los problemas
están sujetos a un proceso de evaluación formal. Cualquier decisión no es
suficientemente significativa con para requerir un proceso de evaluación
formal. La elección entre lo trivial y lo verdaderamente importante puede ser
difusa sin la guía apropiada. El significado de una decisión particular depende
del proyecto y las circunstancias y es determinado por las líneas de guía
establecidas.
2. Establecer y mantener el criterio para la evaluación de alternativas y el
ranking de éstos criterios.
El uso regular de los criterios de toma de decisiones, incluso para decisiones menos
significativas, puede ser extremadamente útil a la hora de crear una práctica para la toma de
decisiones disciplinada. Evaluadores prácticos han demostrado que los criterios definidos y de
peso pueden ser de una contribución significativa a la rapidez y nivel de consenso de una
decisión.
3. Identificar soluciones alternativas para dirigir los problemas.
Un amplio rango de alternativas pueden aflorar a la superficie cuando es solicitada por tantas
partes interesadas como se va a realizar en la práctica en el proyecto. La información aportada
desde las partes interesadas con diferentes niveles y experiencias puede ayudar a los equipos a
identificar y dirigir supuestos, limitaciones y prejuicios. Las sesiones de Brainstorming con
soporte por parte de las partes interesadas puede estimular alternativas innovadores a través de
la interacción rápida y el feedback obtenido.
4. Seleccionar los métodos de evaluación
Los proveedores que compiten para desarrollar una solución técnica para el adquiridor deben
ser directamente valuados en una competición final que involucre una demostración de
rendimiento o funcional de las soluciones propuestas.
Evaluar soluciones alternativas usando el criterio establecido y los métodos para ello.
5. Seleccionar soluciones desde las alternativas basadas en el criterio de
evaluación.
 6. Documentar los resultados de la evaluación para referencias futuras.

Mediciones y Análisis (MA)

El propósito de las Mediciones y Análisis es desarrollar y sostener una capacidad de medición
que se use para dar soporte a las necesidades de información por parte de la dirección.

El proyecto de adquisición tiene necesidad de información para ayudar a determinar el estado

de sus actividades a través del ciclo de vida de la adquisición, las actividades del proveedor
para cada requisito marcado en ella cuerdo de proveedor, y el estado de la evolución de los
productos adquiridos. En proyecto de adquisición en los cuales múltiples productos se
adquieren para entregar una capacidad al usuario final, o aquellos en los que hay relaciones de
equipo con otros proyectos de adquisición para adquirir capacidades de unión, se puede
identificar la necesidad de información adicional para asegurar los objetivos de programación,
técnicos y de interoperabilidad. Dichos objetivos y necesidades deben ser identificados,
medidos y, finalmente conseguidos.
1 Los objetivos y actividades de medida están alineados con las necesidades de
la información identificada y los objetivos.
No todas las mediciones son valiosas. Aquellas mediciones que lleven consigo las necesidades
y objetivos del proyecto de adquisición son las más valiosas. Es mejor identificar las medidas
que se centran en los objetivos que otras medidas que se obtienen fácilmente, pero tienen un
valor cuestionable.

1. Establecer y mantener los objetivos de medida derivados de las

necesidades de la información identificada y los objetivos.
Identificar la información necesaria para mantener la adquisición en camino a una conclusión
exitosa. Establecer objetivos y criterios de medida necesarios para proveer esta información.
2. Especificar medidas para dirigir los objetivos de medida
En la mayoría d los casos, las medidas del proveedor son la fuente primaria de datos,
especialmente relativos al desarrollo del producto o servicio de adquirido. Por ejemplo, las
medidas y análisis del producto o componentes del producto provistos por un proveedor a
través de medidas de rendimiento técnicas es esencial para la gestión efectiva. Las medidas de
rendimiento técnico son medidas definidas de forma precisa basándose en un requisito de
producto, capacidad de producto o alguna combinación de requisitos y capacidades.
3. Especificar como los datos medidos se obtienen y almacenan.
El acuerdo de proveedor especifica los datos de medida que el proveedor debe entregar al
adquiridor, el formato en el cual los datos deben ser provistos, como los datos deben ser
recolectados y almacenados por el proveedor (p.ej.-periodos de retención de datos), como y
con que periodicidad los datos deben ser transferidos al adquiridor, y quien tiene acceso a los
datos. Algunos datos del proveedor pueden ser considerados propiedad del dicho proveedor y
pueden necesitar estar protegidos como tales por parte del adquiridor. Algunos datos medidos
pr el adquiridor (p.ej.- el coste total del proyecto) pueden ser propiedad suya y no deberían ser
compartidos con los proveedores. Un adquiridor deben planificar la recolección, almacenaje y
control de acceso a los datos sensibles.
 4. Especificar como los datos medidos se analizan y se comunican
El acuerdo de proveedor define el análisis de datos que la definición y ejemplos de medida
que el proveedor deben hacer llegar al adquiridor.
2. Se proveen los resultados obtenidos sirvan a las necesidades de la
información y los objetivos
2.1-Obtener los datos específicos de medida y los objetivos
2.2-Analizar e interpretar los datos medidos.
2.3-Gestionar y almacenar los datos medidos, las especificaciones de medida , y el análisis de
los resultados.
2.4-Comunicar el resultado de la medidas y las actividades de análisis a todas las partes
interesadas relevantes.

Garantizar la calidad del proceso y el producto (PPQA)

El propósito de garantizar la calidad del proceso y el producto (PPQA) es proveer el personal
y la dirección necesaria con un punto de vista objetivo en los procesos y los productos de
trabajo asociados a los mismos.

El adquiridor evalúa los productos de trabajo críticos para el adquiridor, los procesos del
adquiridor, el resultado de asegurar los procesos de calidad del proveedor, y los entregables
del proveedor. Por ejemplo, el proceso para la garantía de calidad del producto asegura que el
paquete de solicitud fue desarrollado usando procesos estándar cuerdos por el adquiridor y el
proveedor y que el paquete conforma con todas las políticas acordadas. El adquiridor puede
revisar los resultados de la calidad en las actividades del proveedor, en determinados procesos,
para asegurar que el proveedor está siguiendo sus propios procesos.
1. Se evalúa la adhesión de los procesos llevados a cabo y los productos de
trabajo asociados a las descripciones de proceso aplicable, los estándares, y los
procedimientos.
1. Se evalúan objetivamente los procesos llevados a cabo contra las
descripciones de proceso aplicables, los estándares y los procedimientos.
2. Se evalúan objetivamente los productos de trabajo seleccionados contra
las descripciones de proceso aplicables, los estándares, y procedimientos.
En suma para evaluar objetivamente los productos de trabajo críticos del adquiridor, el
adquiridor usa criterios de aceptación objetivos para evaluar los entregables a través del ciclo
de vida del proyecto. Los criterios de aceptación para los entregables del proveedor son
consistentes con los objetivos del proyecto y suficientes para permitir que el proveedor pueda
demostrar de forma satisfactoria que el producto conforma los requisitos en el acuerdo de
proveedor.
2. Los problemas de incumplimiento son objeto de seguimiento y comunicación
y se debe asegurar su resolución.
1. Los problemas de calidad se comunican y se asegura la resolución de los
problemas de incumplimiento con el personal y la dirección.
2. Se establecen y mantienen registros de para mantener la calidad de las
 actividades-

______________________________________________________

3. Prácticas Genéricas
Las prácticas genéricas son prácticas que deberían estar incluidas en cada área de procesos
en suma a las prácticas específicas que aparecen en cada área de proceso. Las prácticas
Genéricas mejoran el poder de un proceso asegurando que las prácticas especificas son
ejecutadas. Las prácticas genéricas también se aseguran que el proceso está apropiadamente
planeado para asegurar que es factible y que está correctamente soportado así como que las
partes interesadas están apropiadamente involucradas.
Es esta sección, las prácticas genéricas se ponen en texto plano y son seguidas de una breve
explicación.
Las dos últimas prácticas genéricas en esta sección aseguran que el rendimiento de cada
proceso y la lección aprendida son salvadas y que este conocimiento se usa para establecer
nuevos proyectos o para mejorar el rendimiento de un proyecto existente. Las 12 prácticas
listadas aquí corresponden a las 10 prácticas genéricas bajo el logro genérico 2 y los las dos
prácticas genéricas bajo el logro genérico 3 en el modelo CMMI-ACQ.
1. Establecer y mantener una política organizacional para planificar y llevar
a cabo los procesos.
El propósito de esta práctica genérica es definir las expectativas organizacionales sobre los
procesos y hacer estas expectativas visibles a los miembros de la organización que se vean
afectados. En general, el gestor senior es el responsable de establecer y comunicar los
principios de guía, la dirección y las expectativas de la organización.
No toda la dirección del gestor senior conlleva la etiqueta de “política”. La existencia de la
dirección organizacional apropiada es la expectativa de esta práctica genérica,
independientemente de como se llame o cómo se imparta.
Esta política establece expectativas organizaciones para planificar y llevar a cabo el
proceso, incluyendo no solo los elementos del proceso llevado a cabo directamente por el
adquiridor, sino también las interaccione del adquiridor con los proveedores.
2. Establecer y mantener el plan para llevar a cabo los procesos
El propósito de esta práctica genérica es determinar que se necesita para levar a cabo el
proceso y para conseguir los objetivos establecidos, preparar un plan para llevar a cabo el
procesos, preparar una descripción del proceso, y conseguir acuerdo en el plan por parte de
las partes interesadas relevantes.
Planificar un proceso se aplica a todas las áreas de proceso, incluyendo la Planificación de
Procesos. El proceso para planificar el proyecto requieren planificación (p.ej.- recursos,
duración), como cualquier otra actividad.
Los objetivos del proceso pueden ser derivados de otros planes (p.ej.- planes de proyecto).
Incluyendo los objetivos para la situación específica, incluyendo calidad, costes y objetivos
de planificación en fechas. Por ejemplo, un objetivo podría ser reducir el coste de llevar a
cabo un proceso para una implementación sobre su implementación previa.
Establecer un plan incluye documentar el plan y descripciones de procesos. Mantener el
plan incluye actualizarlo si es necesario en respuesta a acciones correctivas o cambios en
los requisitos del proyecto y objetivos.
El plan para llevar a cabo el proceso, típicamente incluye los siguientes elementos.
 Descripción del proceso.
 Estándares y requisitos para los productos de trabajo y los servicios del proceso.
 Objetivos para llevar a cabo el proceso (p.ej.- calidad, escala de tiempos, tiempo de
ciclo, uso de recursos).
 Dependencias entre las actividades, productos de trabajo, y servicios del proceso.
 Recursos (incluyendo fondos, personal y herramientas ) necesarios para llevar a
cabo el proyecto.
 Asignar responsabilidades y autoridad.
 Es necesario la formación para llevar a cabo y dar soporte al proceso.
 Productos de trabajo a ser controlados y el nivel de control de cada elemento.
 Requisitos de medida para proveer un punto de vista del rendimiento del proceso,
sus productos de trabajo y sus servicios.
 Involucración de las partes interesadas identificadas en el proceso.
 Actividades para monitorizar y controlar el proceso.
 Actividades de evaluación objetivas para el proceso.
 Actividades de revisión de la gestión para el proceso y los productos de trabajo.
3. Proveer los recursos adecuado para llevar a cabo el proceso,
desarrollando los productos de trabajo y proveyendo los servicios del
proceso.
El propósito de esta práctica genérica es asegurar que los recursos necesarios para llevar a
cabo el proceso como se ha definido en el plan están disponibles cuando son necesarios.
Los recursos incluyen fondos adecuados, instalaciones físicas adecuadas, personal con las
capacidades necesarias y las herramientas apropiadas.
4. Asignar responsabilidad y autoridad para llevar a cabo el proceso,
desarrollando el producto de trabajo, y proveyendo los servicios del proceso.
El propósito de esta práctica genérica es asegurar que hay una contabilidad para llevar a
cabo el proceso y alcanzar los resultados específicos a través de la vida del proceso. El
personal asignado debe tener la apropiada autoridad para llevar a cabo las responsabilidades
asignadas.
La responsabilidad puede ser asignada usando descripciones de trabajo detalladas o
documentos tales como el plan para llevar a cabo el proceso. La asignación dinámica de
responsabilidades es otro camino legitimo para llevar a cabo esta práctica genérica,
mientras que la asignación y aceptación de responsabilidad son aseguradas a través de la
vida del proceso.
5. Enseñar a la gente a llevar a cabo el proceso o a darle soporte tal y como
el proceso necesite.
El propósito de esta práctica genérica es asegurar que las personas tienen las capacidades
necesarias y la experiencia para llevar a cabo o dar soporte al proceso.
La formación da soporte al rendimiento éxito del proceso estableciendo un entendimiento
común del proceso e impartiendo las capacidades y el conocimiento necesario para llevar a
cabo el proceso.
6 Colocar los productos de trabajo seleccionados bajo los niveles de control
apropiados.
El propósito de esta práctica genérica es establecer y mantener la integridad de los
productos de trabajo seleccionados del proceso ( o sus descripciones) a través de su vida
útil.
Los productos de trabajo designados se identifican en el plan para llevar a cabo el proceso,
junto con la especificación del apropiado nivel de control.
7. Identificar e involucrar a las partes interesadas relevantes para el proceso
tal y como se planificó.
El propósito de esta práctica genérica es establecer y mantener la implicación esperada de
las partes interesadas relevantes durante la ejecución del proceso.
Para planificar la implicación de las partes interesadas, asegurar que la interacción
necesaria para cumplir con el proceso por parte de dichas partes interesadas es suficiente,
mientras que se evita el número excesivo de partes interesadas que podría impedir que el
proceso fuera ejecutado.
8. Monitorizar y control el proceso contra el plan para llevar a cabo el
proceso y tomar las acciones correctivas pertinentes
El propósito de esta práctica genérica es llevar a cabo la monitorización directa en el día a
día y controlar el proceso. La visibilidad apropiada del proceso se mantiene de tal forma
que que las acciones correctivas apropiadas se puedan tomar cuando sea necesario.
Monitorizar y controlar el proceso puede involucrar medir de la forma mas apropiada los
atributos del proceso o los productos de trabajo resultado de dicho proceso.
9. Evaluar de forma objetiva la adhesión del proceso y los productos de
trabajo seleccionados contra la descripción del proceso, los estándares, y los
procedimientos, y comprobar incumplimientos.
El propósito de esta práctica genérica es proveer un seguro creíble sobre que el proceso y
los productos de trabajo seleccionados se implementan tal y como se ha planificado y que
son tal y como se dice en las descripciones de proceso, los estándares y los procedimientos.
10. Revisar las actividades, estado, y resultado de los procesos con mas alto
nivel de dirección y resolver los problemas hallados.
El propósito de esta práctica genérica es proveer un alto nivel de gestión con la apropiada
visibilidad de todo el proceso.
Niveles superiores de gestión incluyen aquellos niveles en la organización que están por
encima del nivel inmediato responsable del proceso. En particular, el nivel superior de
gestión incluye la gestión senior. Estas revisiones son para los gestores que proveen la
política y la guía global para el proceso, y no para aquellos que llevan a cabo a
monitorización del día a día y los procesos de control.
Las siguientes dos prácticas genéricas forma la base para la propagación de las buenas
prácticas a los futuros proyectos de adquisición. Estas prácticas facilitan la definición de
procesos e identifican los beneficios del proceso que fomentan la adopción de las mejores
prácticas en nuevos proyectos.
Un proceso definido se hace a medida desde el conjunto de procesos estándar de la
organización de acuerdo a las líneas guía de la organización para realización de procesos a
medida y contribuye a los productos de trabajo, las medidas y otra información de mejora
de procesos para los activos de los procesos de la organización.
Estas dos prácticas genérica activan un ciclo de mejora de procesos. La organización
mantiene una librería de activos de proceso y un proceso estándar que puede usarse por un
proyecto para crear sus procesos. A su vez, el proyecto provee información acerca del
rendimiento de sus procesos a la librería de activos de proceso, la cual se usa para mejorar y
extender los procesos estándar.
El conjunto de procesos estándar de la organización, los cuales son la base de los procesos
definidos, se establecen y mejoran a lo largo del tiempo. Los procesos estándar describen
los elementos fundamentes del procesos que se esperan en un proceso definido. El proceso
estándar también describen las relaciones (p.ej.- ordenes,interfaces ) entre estos elementos
de proceso. El nivel organizacional de la infraestructura que da soporte al uso actual y
futuro del conjunto de procesos estándar de la organización se establece y mejora a lo largo
del tiempo.
11. Establecer y mantener la descripción de un proceso definido.
El propósito de esta práctica genérica es establecer y mantener una descripción del proceso
que está hecho a medida desde el conjunto de los procesos estándar de la organización para
llevar a cabo las necesidades de una instanciación específica. La organización debería tener
procesos estándar que cubren el área de proceso y las líneas guía para hacer a medida que
estos procesos estándar concluyan en las necesidades específicas del proyecto o una
función de la organización. Con un proceso definido, la variabilidad en cómo los procesos
se llevan a cabo a lo largo de la organización se reduce a activo de proceso, datos y
aprendizaje que deben ser debidamente compartidos.
12. Recoger las experiencias relacionadas con procesos derivadas de la
planificación y ejecución de procesos para dar soporte al uso futuro y
mejora de los procesos de la organización, así como de los activos de sus
procesos.
El propósito de esta práctica genérica es recolectar procesos de experiencias
relacionadas,incluyendo información y artefactos derivados de planificaciones y
aplicaciones de procesos. Ejemplos de experiencias relacionadas con procesos incluyen
productos de trabajo, medidas, resultados de medida, lecciones aprendidas y sugestiones
sobre la mejora de procesos. La información y los artefactos son recolectados de forma que
puedan incluirse en los activos de proceso de la organización y que puedan ponerse a
disposición de aquellos que bien actualmente bien en el futuro los usarán para planificar o
llevar a cabo procesos similares. La información y artefactos se almacenan en el
repositorios de medidas de la organización y la librería de activos de procesos.
Apéndices
Preguntas sobre implementación
Las preguntas en este apéndice le ayudarán, como gestor de proyecto en un proyecto de
adquisición, a implementar sus procesos. Las preguntas le ayudan a verificar que las
mejores prácticas se están empleando y provean unos medios para hacer acopio de
información de fondo necesaria par a determinar silos productos o servicios adquiridos
cumplirán las necesidades operacionales de su organización.
Las preguntas de la siguiente tabla se designaron para facilitar revisiones y mejoras de los
procesos en su organización de adquisición. Llevan a cabo tanto si hay un desarrollo de la
estrategia, una planificación y actividades de estimación como si no. en gran parte, estas
primeras actividades determinan el éxito de un proceso de adquisición desde el lanzamiento
del mismo.
Las preguntas también enfocan las identificaciones de riesgo, las prácticas de gestión, las
capacidades de definición, los requisitos de generación y la existencia de procesos
repetibles que habilitan a las organizaciones a institucionalizar las mejores prácticas. Para
cada cuestión en la columna de la izquierda, las áreas relevantes de procesos, descritas con
detalle en la sección 2, se listan en la columna de la derecha.

1. Procesos en General
Preguntas Áreas de proceso CMMI-ACQ
a. ¿Cuales son los Planificación de proyecto, Gestión Integrada de Proyecto
contenidos y
fuentes de su
proceso de
adquisición?
b. ¿ Qué Control y Monitorización de Proyecto, Medidas y Análisis, Asegurado de
mecanismos usa Procesos y Calidad de Productos.
para monitorizar,
controlar y mejorar
sus procesos de
adquisición?
c. ¿Como sabes que Control y Monitorización de Proyecto, Asegurado de Procesos y Calidad de
su proyecto se Productos
adhiere a su proceso
de adquisición?
2. Requisitos de Usuario
Preguntas Áreas de proceso CMMI-ACQ
a. ¿Hay un proceso Desarrollo de Requisitos de Adquisición
para definir,
verificar y validar
requisitos de cliente
y de contrato?
b. ¿Como se Planificación de Proyecto, Gestión Integrada de Proyecto, Gestión de
gestiona la Requisitos, Desarrollo de Requisitos para la Adquisición
implicación de los
usuarios en el
proceso de
requisitos?
c. ¿Como asegura Gestión de Requisitos, Desarrollos de Requisitos para la Adquisición,
un entendimiento Gestión Integrada de Proyectos
claro de las
necesidades de los
usuarios a las partes
interesadas
relevantes?
d. ¿ Que papel Desarrollo de Requisitos para la Adquisición, Gestión de Requisitos
desempeña su
organización a la
hora de establecer
los requisitos del
proyecto?
e. ¿ Cual es su Gestión de Proyecto Integrado, Gestión de Requisitos.
estrategia para estar
al dia con la
evolución
operacional (p.ej.-
amenazas, concepto
de operaciones y
preparación de la
tecnología)?
4. Planificación de la Adquisición
Preguntas Áreas de proceso CMMI-ACQ
a. ¿Como reflejan e Planificación de Proyectos, Gestión Integrada de Proyectos, Decisión,
implementan sus Análisis y Resolución
planes la estrategia
de adquisición?
b. ¿Como determina Planificación de Proyecto, Solicitud y Desarrollo de Acuerdo de Proveedor
y documenta el
ámbito del
proyecto,incluyendo
las actividades del
proyecto de
adquisición, las
actividades del
proveedor, y otras
actividades
relacionadas
(pruebas
operacionales,
actividades de
usuario, etc)?
c. ¿Cómo se Planificación de Proyecto
determina la
magnitud del
esfuerzo de
desarrollo?
d. ¿ Como se Planificación de Proyecto
determina las
necesidades de
fuentes para cada
elementos del
proyecto?
e ¿Como se Planificación de Proyecto, Gestión Integrada de Proyecto
determina el camino
crítico?
f. ¿Cómo se Planificación de Proyecto, Gestión Integrada de Proyecto
coordinan los
planes con las
partes interesadas
relevantes tanto a
nivel de gestión
como de trabajo?
g. Como asegurar Planificación de Proyecto
que tiene el
personal adecuado
con la experiencia y
formación
necesarias para
ejecutar sus planes?
h. ¿ Como asegura Planificación de Proyecto, Solicitud y Desarrollo de Acuerdo de Proveedor,
que el proveedor Gestión de Acuerdos
tiene los recursos y
herramientas
necesarias para
completar el
proyecto?
i. ¿Cómo asegura Planificación de Proyecto, Solicitud y Desarrollo de Acuerdo de Proveedor,
que el proveedor Gestión de Acuerdos
tiene la experiencia,
el dominio y la
capacidad en
procesos necesaria
para completar el
proyecto?
5. Coste, Planificación en fechas y líneas Base para el rendimiento.
Preguntas Áreas de proceso CMMI-ACQ
a. ¿Como asegura Planificación de Proyectos, Gestión Integrada de Proyectos
que el coste,
planificación en
fechas y líneas de
rendimiento son
integradas, realistas
y ejecutables?
b. ¿Qué provisiones Planificación de Proyecto, Gestión Integrada de Proyecto, Desarrollo de
se hacen para Requisitos de Adquisición, Gestión de los Requisitos
revisiones
independientes de
sus costes,
planificación y
líneas base de
rendimiento?
c. ¿Como asegura Planificación de Proyecto, Gestión Integrada de Proyecto
que todos los costes
del ciclo de vida se
incluyen en las
líneas base (p.ej.-
pruebas, formación,
mantenimiento,
soporte)?
d. ¿Como planifica Monitorización´de Proyecto y Control, Medidas y Análisis
hacer un
seguimiento del
coste, planificación
en tiempo y
rendimiento del
proyecto a lo largo
de su ciclo de vida?
e. ¿Como acomodar Planificación de Proyecto, Gestión del Riesgo, Gestión de Requisitos
riesgos y hacer
ingeniería de
cambios en sus
líneas base?
f. ¿Como se Gestión de la Configuración, Monitorización y Control del Proyecto,
gestionan cambios Gestión de requisitos
en las líneas base?
g. ¿Cómo evalúa el Monitorización y Control de Proyecto, Solicitud y Desarrollo de Acuerdo de
impacto de los Proveedor, Gestión de Requisitos.
cambios en coste y
planificación en los
esfuerzos de
desarrollo del
proveedor?
6. Identificación y Gestión de Riesgos
Preguntas Áreas de proceso CMMI-ACQ
a- ¿Como identifica Planificación de Proyecto, Gestión de Riesgos
los riesgos del
proyecto?
b. ¿Cómo se Planificación de Proyecto, Gestión de Riesgos
identifican Riesgos
relacionado a su
estrategia de
adquisición y planes
trazados?
c. ¿Cómo identifica Planificación de Proyecto, Gestión Integrada de Proyecto, Gestión de
riesgos asociados Riesgos
con costes y
planificación?
d. ¿Cómo asegura Planificación de Proyecto, Gestión del Riesgo, Desarrollo de Requisitos.
que entiende riego
en coste de obtener
la capacidad
deseada?
e. ¿Cómo identifica Planificación de Proyecto, Gestión de Riesgos, Solicitud y Desarrollo de
riesgos relacionados Acuerdo de Proveedor.
con la ejecución del
proveedor?
f. ¿Cómo identifica Planificación de Proyecto, Gestión Integrada de Proyecto, Gestión de
riesgos que escapan Riesgos
a su control?
g-¿Como maneja la Gestión del Riesgo
probabilidad y
consecuencias de
los riesgos de
proyecto?
h. ¿Cómo se Gestión del Riesgo
monitoriza los
esfuerzos de
mitigación para
riesgos
identificados?
i. ¿Qué Planificación de Proyecto, Gestión del Riesgo
herramientas de
gestión de riesgos
emplea?
j. ¿Quién está Gestión Integrada del Proyecto, Gestión del Riesgo
involucrado en
manejar la gestión
de riesgos del
proyecto (p.ej.-
usuarios, el
proveedor, expertos
en la materia
independientes)?
k. ¿Como se Planificación de Proyecto, Gestión del Riesgo
construyen las
reservas suficientes
para la mitigación
del riegos y
absorción del
impacto de los
riesgos reales?
Monitorización del Proveedor
Preguntas Área de proceso CMMI-ACQ
a. ¿Como se Gestión de Acuerdos, Gestión Técnica de la Adquisición, Gestión del
manejan los Riesgo
mecanismos que el
proveedor usa para
fomentar la
ejecución de sus
procesos de
organización desde
el principio del
proyecto?
b. ¿Existe un Desarrollo de Requisitos de Adquisición, Gestión Técnica de Adquisición
proceso en firme
para definir,
verificar y validar
requisitos y
arquitecturas para el
producto?
C ¿Como se Control y Monitorización del Proyecto, Medidas y Análisis, Gestión de
monitorizará el Acuerdos
estado de
desarrollo?
d. ¿Como Gestión de Acuerdos
demostrará el
proveedor el
rendimiento y
estabilidad de sus
desarrollo , de sus
herramientas y
medio de trabajo?
8. Elementos de no-desarrollo
Preguntas Áreas de Proceso CMMI-ACQ
a. ¿Cual es la Planificación de Proyecto, Análisis de Decisión y Resolución, Desarrollo de
estrategia para Requisitos de Adquisición
incorporar
productos no de
desarrollo (p.ej.-
artículos
comerciales no a la
venta [COTS],
b. ¿Qué porcentaje Planificación de Proyecto, Medidas y Análisis.
del software se
planifica que sea de
no-desarrollo?
c. ¿Como determina Planificación de Proyecto, Gestión del Riesgo, Verificación, Validación,
que puede Análisis de Decisión y Resolución.
conseguir el
porcentaje
planificado de uso
de software de no-
desarrollo en este
proyecto?
d. ¿Como determina Medidas y Análisis, Desarrollo de Requisitos, Verificación, Validación,
que los productos Análisis de Decisión y Resolución.
no-desarrollo
proveerán las
funcionalidades
requeridas y su
rendimiento?
e. ¿Cómo determina Gestión Técnica de la Adquisición
que las interfaces de
los productos no-
desarrollo son
definidas y están de
acuerdo con las
partes interesadas
relevantes?
f. ¿Cómo hace Desarrollo de Requisitos de Adquisición, Gestión Técnica de la
cuentas para el Adquisición, Validación.
esfuerzo requerido
para probar e
integrar productos
no-desarrollo?

Traduccion realizada por Juan José Nuevo Rosado

e-mail jjnuevo@hotmail.com

2
Para mas información acerca monitorizar los procesos del proveedor ver “Understanding
an levaragin a supplier's CMMI Effots: A guidebook for acquirers (CMU/SEI-2007-TR-
004).Pittsburg, PA: Sofware Engineering Institute, Carnegie Mellon Univesity, Marzo 2007
http://www.sei.cmu.edu/publications/documents/07.reports/07tr004.html
Nota del traductor: se refiere a que todo requisito en un nivel superior debe conllevar
cambios en todos los requisitos. Tanto la cadena de cambios hasta el nivel mas bajo debe
ser clara y poder trazarse, como viceversa. Desde un cambio en la base debe haber una
cadena clara de sucesos que puedan llevar de forma clara al cambio en el requisito de alto
nivel.
Nota del traductor: guion gráfico a modo de viñetas, si existiera.
Retroalimentación: información devuelta como resultado de sus impresiones tras la
evaluación de la solución técnica