Modelo de calidad CMMI (página 3)

40.  SP 2:
Establecer un paquete de datos técnicos

Práctica: "Establecer y mantener un paquete de
datos técnicos".

           
Un paquete de datos técnicos provee al desarrollador una
descripción exhaustiva del producto o de sus componentes a
medida que es desarrollado. Dicho paquete también provee
flexibilidad de adquisiciones en diversas circunstancias, tales
como "Performance-Based Contracting" (PBC) o "Build To
Print".

           
El diseño es registrado en un paquete de datos
técnicos creado durante el diseño preliminar para
documentar la definición de la arquitectura. Este paquete
de datos técnicos es mantenido durante toda la vida del
producto para registrar detalles esenciales del diseño del
producto. El paquete de datos técnicos provee la
descripción del producto y sus componentes que apoyan la
estrategia de adquisición, o la implementación,
producción, ingeniería y fases de soporte
logístico del ciclo de vida del producto. La
descripción incluye la definición de la
configuración requerida del diseño y procedimientos
para asegurar el comportamiento adecuado del producto o de sus
componentes. Esto incluye todos los datos técnicos
aplicables como dibujos, listas asociadas, especificaciones,
descripciones de diseño, bases de datos de diseño,
estándares, requerimientos de rendimiento, provisiones de
aseguramiento de calidad y detalles de empaquetamiento. El
paquete de datos técnicos incluye una descripción
de la solución alternativa seleccionada a ser
implementada.

           
Un paquete de datos técnicos debería incluir lo
siguiente, si dicha información es apropiada para el tipo
de producto y componentes del producto:

-          
Descripción de arquitectura de producto.

-          
Requerimientos asignados.

-          
Descripción de componentes del producto.

-          
Descripción de los procesos relacionados con el ciclo de
vida del producto, si no es descrito como componentes de
productos separados.

-          
Características de productos claves.

-          
Características físicas requeridas y
restricciones.

-          
Requerimientos de interfaz.

-          
Requerimientos de materiales.

-          
Fabricación y requerimientos de manufactura.

-          
Criterios de verificación usados para asegurar que los
requerimientos han sido satisfechos.

-          
Condiciones de uso (ambientes) y escenarios de uso /
operación, modos y estados de operación, soporte,
capacitación, manufactura, eliminación del producto
y verificaciones a los largo de la vida útil del
producto.

-          
Fundamentos de decisiones y características
(requerimientos, asignación de requerimientos y opciones
de diseño).

           
Debido a que las descripciones de diseño pueden contener
una gran cantidad de información y pueden ser cruciales
para el desarrollo exitoso de los componentes del producto, es
aconsejable establecer criterios para organizar y seleccionar la
información. Es particularmente útil utilizar la
arquitectura del producto como una manera de organizar la
información y elaborar vistas claras y relevantes para un
tema o característica de interés. Estas vistas
incluyen lo siguiente:

-          
Clientes.

-          
Requerimientos.

-          
El ambiente.

-          
Funcionalidad.

-          
Lógica.

-          
Seguridad.

-          
Datos.

-          
Estados / modos.

-          
Construcción.

-          
Administración

           
Estas vistas son documentadas en el paquete de datos
técnicos.

41.  SP 3:
Diseñar interfaces utilizando criterios

Práctica: "Diseñar interfaces de
componentes del producto utilizando los criterios
establecidos".

           
Estos diseños de interfaces incluyen lo
siguiente:

-          
Orígenes.

-          
Destino.

-          
Estímulos y características de datos para el
software

-          
Características eléctricas, mecánicas y
funcionales para hardware

-          
Líneas de comunicación.

           
El criterio para interfaces frecuentemente refleja
parámetros críticos que deben ser definidos, o al
menos investigados, para asegurar su aplicabilidad. Estos
parámetros son a menudo característicos de un
cierto tipo de producto (software, mecánico,
eléctrico, de servicio) y son a menudo asociados con
seguridad, durabilidad y características de la
misión crítica.

42.  SP 4:
Ejecutar Análisis de: Hacer, Comprar o
Reutilizar

Práctica: "Evaluar si los componentes del
producto debieran ser desarrollados, comprados o reutilizados
basándose en los criterios establecidos".

           
La determinación acerca de qué producto o
componentes del producto serán adquiridos es
frecuentemente referido como "make-or-buy analysis"
(análisis de hacer-o-comprar). Este análisis esta
basado en las necesidades del proyecto; comienza tempranamente
durante la primera iteración de diseño,
continúa durante el proceso de diseño y concluye
con la decisión de desarrollar, adquirir o reutilizar el
producto.

           
Factores que afectan la decisión de hacer-o-comprar
incluyen los siguientes:

-          
Funciones que los productos o servicios proveerán y
cómo estas funciones se ajustan al proyecto.

-          
Recursos y habilidades disponibles del proyecto.

-          
Costos de adquisición versus costos de desarrollo
interno.

-          
Entregas críticas y fechas de
integración.

-          
Alianzas estratégicas de negocios, incluyendo
requerimientos de negocio de alto nivel.

-          
Investigación de mercado de productos disponibles,
incluyendo productos tipo COTS.

-          
Funcionalidad y calidad de productos disponibles.

-          
Habilidades y capacidades de potenciales proveedores.

-          
Impacto en las competencias esenciales.

-          
Licencias, garantías, responsabilidades y limitantes
asociadas a productos que están siendo
adquiridos.

-          
Disponibilidad de productos

-          
Calidad propietaria de productos y componentes.

-          
Reducción de riesgos.

           
La decisión de hacer-o-comprar puede efectuarse aplicando
un proceso formal de toma de decisiones. A medida que la
tecnología evoluciona, también lo hacen las razones
para elegir el desarrollo o compra de componentes de producto.
Mientras el esfuerzo de desarrollo complejo puede favorecer la
compra de un componente tipo COTS, los avances en la
productividad y herramientas pueden presentar razones en sentido
contrario. Productos tipo COTS pueden tener documentación
incompleta o incorrecta y pueden no contar con soporte en el
futuro.

SG 3: Implementar el Diseño del
Producto       

Objetivo: "Componentes del producto, y su
documentación de apoyo asociada, son implementadas
según sus diseños".

           
Los componentes del producto son implementados a partir de los
diseños establecidos por las prácticas
específicas de la práctica específica
Desarrollar el Diseño. La implementación usualmente
incluye pruebas unitarias de los componentes del producto antes
de la integración de producto y el desarrollo de
documentación de usuarios finales.

43.  SP 1:
Implementar el Diseño

Práctica: "Implementar los diseños de
las componentes del producto".

           
Una vez que el diseño se ha completado, éste es
implementado como un componente del producto. Las
características de esa implementación dependen del
tipo de componente.

           
La implementación del diseño en el primer nivel de
la jerarquía del producto implica la especificación
de cada uno de los componentes del producto en el siguiente nivel
de la jerarquía. Esta actividad incluye la
asignación, refinamiento y verificación de cada
componente del producto. También incluye la
coordinación de los trabajos de desarrollo del componente
del producto.

44.  SP 2:
Desarrollar la documentación de apoyo del
producto

Práctica: "Desarrollar y mantener la
documentación de utilización final".

           
Esta práctica específica desarrolla y mantiene la
documentación que será usada para instalar, operar
y mantener el producto.

Integración de Productos

El propósito de PI es ensamblar las componentes
del producto para obtener el producto, asegurar que el producto
– según la integración que se hizo –
funciona correctamente, y liberar el producto al 
cliente.

           
PI involucra tanto:

•          
Integración del producto: Integración para el
producto final.

•          
Integración de las componentes del producto:
Integración de componentes para producir componentes
más complejas.

           
El ámbito de PI es alcanzar la integración del
producto completo a través del ensamble de progresivas
componentes, en uno o más pasos, de acuerdo a la secuencia
de integración definida y los procedimientos.  Se usa
el término Integración de Productos para
también referirse a la Integración de
Servicios.

SG 1: Preparación para la
Integración del producto

Objetivo: "Preparación para la
integración del producto es conducida"

           
Preparar la integración de los componentes del producto
incluye establecer y mantener:

•          
Una secuencia de integración del producto y de las
componentes del producto.

•          
El ambiente para realizar la integración del producto y de
las componentes del producto.

•          
Procedimientos y criterios para la integración del
producto y de las componentes del producto.

           
La preparación para la integración comienza al
inicio del proyecto y la secuencia de integración es
desarrollada al mismo tiempo con las prácticas del
área de proceso de Solución
Técnica.

45.  SP 1:
Determinar la Secuencia de Integración

Práctica: "Determinar la secuencia de
integración de componentes del
producto" 

           
Las componentes del producto son analizadas para su
integración.  Se define un conjunto de secuencias
posibles para integrar las componentes y se elige la mejor
secuencia posible.

46.  SP 2:
Establecer el Ambiente de Integración del
Producto

Práctica: "Establecer y mantener el ambiente
necesario para apoyar la integración de las componentes
del producto".

           
El ambiente para la integración de producto puede ser
adquirido o desarrollado. Para establecer un ambiente,
requerimientos para la compra o desarrollo de equipamientos,
software u otros recursos necesitarán ser
desarrollados.  El ambiente requerido en cada paso del
proceso de integración de producto puede incluir equipos
para realizar pruebas, simuladores (tomando el lugar de
componentes de productos no disponibles), piezas de equipos
reales y dispositivos de almacenamiento.

47.  SP 3:
Establecer Procedimientos y Criterios de Integración del
Producto

Práctica: "Establecer y mantener
procedimientos y criterios para la Integración de las
componentes del producto".

           
Los procedimientos para la integración de las componentes
del producto pueden incluir cosas como el número de
iteraciones incrementales que se realizan y detalles de las
evaluaciones   que serán llevadas a cabo en cada
etapa.

           
Los criterios pueden indicar si la componente del producto esta o
no preparada para su integración o su grado de
aceptación.

           
Los procedimientos y criterios para la integración del
producto dirigen lo siguiente: Nivel de prueba para construir
componentes, Verificación de interfaces, Umbrales de
desviación de ejecución, Requerimientos derivados
para el ensamble y sus interfaces externas, Sustituciones
permitidas de componentes, Parámetros del ambiente de
prueba, Limites en los costos de prueba, Equilibrio
calidad/costos para operaciones de integración,
Probabilidad del funcionamiento apropiado, Tasas de entrega y sus
variaciones, Tiempo de entrega desde el pedido hasta la entrega,
Disponibilidad de personal y Disponibilidad de la
facilidad/línea/ambiente de integración.

           
Los criterios pueden ser definidos por cómo las
componentes del producto están para ser verificados y las
funciones que se espera que ellas tengan. Los criterios pueden
ser definidos por cómo las componentes ensambladas del
producto y el producto integrado final son validados y liberados.
Los criterios también pueden restringir el grado de
simulación permitidos para que las componentes puedan
pasar una prueba, o pueden restringir el ambiente para ser usado
en el test de integración.

SG 2: Asegurar la compatibilidad de
interfaces

Objetivo: "Las interfaces de las componentes del
producto, internas y externas, son compatibles".

           
Muchos problemas de integración de productos surgen por
aspectos no conocidos o no controlados de interfaces internas y
externas a cada componente. La administración efectiva de
requerimientos de interfaces de componentes de productos,
especificaciones y diseños, ayudan a asegurar que las
interfaces implementadas serán compatibles y
completas.

48.  SP 1:
Revisar Descripción de Interfaces para
Completitud

Práctica: "Revisar descripciones de interfaces
para su cobertura y completitud".

           
Las interfaces deben incluir, además de las interfaces de
los componentes del producto, todas las interfaces con el
ambiente de integración del producto.

49.  SP 2:
Gestionar Interfaces

Práctica: "Gestionar definiciones de
interfaces internas y externas, diseños, y cambios en
productos y componentes del producto".

           
Los requerimientos de interfaz manejan el desarrollo de las
interfaces necesarias para integrar las componentes del producto.
Gestionar interfases del producto y componentes del producto
comienza tempranamente en el desarrollo del producto. Las
definiciones y el diseño para interfaces afecta, no
solamente a los componentes de producto y sistemas externos, sino
que también puede afectar la validación y
verificación de ambientes.

    
       La gestión de
interfaces incluye la mantención de la consistencia de las
interfaces durante todo el ciclo de vida del producto, y
resolución de conflictos, disconformidades, y cambios en
temas.  La gestión de interfaces entre productos
adquiridos desde proveedores y otros productos o componentes de
productos son críticas para el éxito del
proyecto.

           
Las interfaces deben incluir, además de  las
interfaces de las componentes del producto, todas las interfaces
con el ambiente, así como con otros  como ambientes
para verificación, validación, operaciones y
soporte.  Los cambios en la interfase son documentados,
mantenidos y fácilmente accesibles.

SG 3: Ensamblar las componentes del producto y
liberar el producto

Objetivo: "Componentes del producto verificadas son
ensambladas y el producto integrado, verificado y validado es
entregado".

           
La integración de las componentes del producto se hace de
acuerdo a la secuencia de integración del producto y los
procedimientos disponibles. Antes de la integración, cada
componente del producto es verificada de acuerdo a los
requerimientos de interfaz establecidos. Las componentes del
producto son ensambladas en componentes  más
complejas y grandes.  Estas componentes ensambladas son
chequeadas para su correcta interoperación. Este proceso
continúa hasta que la integración del producto es
completada. Si durante este proceso se identifican problemas
estos deben ser documentados y un proceso de acciones correctivas
es iniciado.

50.  SP 1:
Confirmar Componentes para Integración
preparados

Práctica: "Confirmar, previo al ensamble, que
cada componente del producto requerido para ensamblar el producto
ha sido debidamente identificado,  funciones corresponden a
su descripción y  las interfaces de las componentes
del producto cumplen con las descripciones de las
interfaces".

           
El propósito de esta práctica específica es
asegurar que las componentes del producto adecuadamente
identificadas que cumplen con su descripción puedan ser
realmente ensambladas de acuerdo a la secuencia de
integración del producto y procedimientos disponibles.
También la consistencia entre las componentes de producto
y descripciones de interfase son chequeadas.

 
          Quienes
conducen la integración del producto son los responsables
en última instancia de chequear para asegurarse que todo
está correcto y así continuar con el
ensamble.

51.  SP 2:
Ensamblar las componentes del producto

Práctica: "Ensamblar las componentes del
producto de acuerdo a la secuencia de integración y
procedimientos disponibles".

           
Las actividades de ensamblaje de esta práctica
específica y las actividades de evaluación de la
próxima son conducidas en forma iterativa, desde los
componentes iniciales del producto, a través de los
componentes ensamblados provisorios, hasta el producto como un
todo.

52.  SP 3:
Evaluar Componentes del Producto ensambladas

Práctica: "Evaluar componentes de producto
ensamblados para la compatibilidad de interfase".

           
Esta evaluación involucra examinar y probar las
componentes del producto ensambladas para su realización,
conveniencia o preparación usando los procedimientos y
ambiente disponibles. Esto es realizado para los diferentes pasos
del ensamble según lo dispuesto por la secuencia de
integración y procedimientos disponibles. La secuencia de
integración del producto y procedimientos disponibles, el
número de componentes, y la complejidad del producto
podrían definir una secuencia de integración y
evaluación más refinada.

53.  SP 4:
Empaquetar y Entregar Productos o Componentes del
Producto

Práctica: "Empaquetar el producto ensamblado o
componente del producto  y entregarlo al cliente
apropiado".

           
Los requerimientos de empaque para algunos productos pueden ser
dirigidos según sus especificaciones y criterios de
verificación. Esto es especialmente importante cuando los
ítems son registrados y transportados por los clientes. En
tales casos, pudiese haber condiciones de estrés y
ambiente especificadas para el paquete. En otras circunstancias
economía y requerimientos de transporte, responsabilidad,
y facilidad y seguridad del desempaque son factores
importantes.

Verificación

El propósito de Verificación (VER) es
asegurar que los artefactos cumplen con los requerimientos
especificados.

           
VER involucra la verificación del producto o servicios y
artefactos intermedios con respecto a los requerimientos
seleccionados, incluyendo requerimientos del cliente, del
producto o servicio y componentes del producto o servicio. VER es
un proceso incremental porque se aplica al desarrollo del
producto y artefactos, comenzando con la verificación de
los requerimientos, pasando por la verificación de
artefactos y terminando con la verificación del producto
completo.

 
          VER y VAL
son similares pero tienen diferencias. VAL demuestra que el
producto que se entregará satisface su uso entendido,
mientras que VER se enfoca en que los artefactos reflejen los
requerimientos especificados. En otras palabras, VER asegura que
algo se construye correctamente, mientras que VAL asegura que se
construye algo correcto.

SG 1: Preparar la verificación

Objetivo:   "La preparación de la
verificación es conducida".

           
Una preparación es necesaria para asegurar que los
requerimientos de verificación están incluidos en
los requerimientos del producto y las componentes del producto,
diseños, planes de desarrollo y programas. La
verificación incluye selección, inspección,
prueba, análisis y demostración de
artefactos.

           
Los métodos de verificación incluyen, pero no
están limitados a ellos, inspecciones, revisiones de
pares, auditorias, inspecciones, análisis, simulaciones,
pruebas y demostraciones.

           
La preparación también supone la definición
de herramientas de apoyo, equipamientos para pruebas y software,
simulaciones, prototipos y facilidades.

54.  SP 1:
Seleccionar artefactos para Verificación

Práctica: "Seleccionar artefactos a ser
verificados y métodos de verificación que
serán usados para cada uno de ellos".

           
Los artefactos son seleccionados basándose en su
contribución para alcanzar los objetivos y requerimientos
del proyecto, y para dirigir los riesgos del proyecto.

           
Los artefactos que serán verificados pueden incluir
aquellos asociados con la mantención, entrenamiento y
servicios de apoyo. Los métodos de verificación
dirigen el enfoque técnico de la verificación de
artefactos y los procedimientos específicos que
serán usados para verificar que los productos de trabajo
específicos cumplan sus requerimientos.

 
          La
selección de los métodos de verificación
comienza típicamente con la participación en la
definición de los requerimientos del producto o
componentes del producto para asegurar que estos requerimientos
son verificables.

55.  SP 2:
Establecer el ambiente de Verificación

Práctica: "Establecer y mantener el ambiente
necesario para apoyar la verificación".

           
Un ambiente debe ser establecido para permitir que la
verificación tome lugar. El ambiente de
verificación puede ser adquirido, desarrollado,
reutilizado, modificado, o una combinación de estos,
dependiendo de las necesidades del proyecto. 

           
Cada ambiente requerido va a depender de los artefactos
seleccionados para su verificación y los métodos de
verificación usados.

56.  SP 3:
Establecer procedimientos y criterios de
verificación

Práctica: "Establecer y mantener
procedimientos y criterios de verificación para los
artefactos seleccionados"

           
Los criterios de verificación son definidos para asegurar
que los artefactos cumplan con sus requerimientos.

SG 2: Realizar Revisión de
Pares

Objetivo: "Revisiones de pares son desarrolladas
sobre artefactos seleccionados".

           
La revisión de pares es un análisis
metodológico de artefactos realizado por los productores o
desarrolladores pares  para identificar defectos a ser
removidos y recomendar otros cambios según sean 
necesarios.

           
La revisión de pares es un método de
ingeniería importante y efectivo implementado vía
inspecciones u otros métodos de
revisión.

57.  SP 1:
Preparar la revisión de pares

Práctica: "Preparar para la revisión de
pares de artefactos seleccionados".

           
Actividades de preparación  para la revisión
de pares típicamente incluyen identificar el personal que
será invitado a participar en la revisión de pares
de cada artefacto; identificar los revisores claves que deben
participar en la revisión de pares; preparar y actualizar
cualquier material que será usado durante la
revisión de pares.

58.  SP 2:
Conducir la revisión de pares

Práctica: "Conducir la revisión de
pares sobre artefactos seleccionados e identificar defectos
resultantes de la revisión de pares".

           
Uno de los propósitos de conducir la revisión de
pares es encontrar y remover tempranamente defectos. La
revisión de pares es realizada incrementalmente tal como
los artefactos estén siendo desarrollados. Estas
revisiones son estructuradas y no son revisiones
administrativas.

 
          La
revisión de pares puede ser realizada en cualquier tipo de
artefacto.  Cuando surgen defectos de la revisión de
pares, estos deben ser comunicados al desarrollador principal del
artefacto para su corrección.

   
        La revisión de
pares debe dirigir lo siguiente: Debe haber la preparación
suficiente, la conducción debe ser administrada y
controlada, datos consistentes y suficientes deben ser
registrados, y puntos de acción deben ser
registrados. 

59.  SP 3:
Analizar los datos de la revisión de pares

Práctica: "Analizar datos acerca de la
preparación, conducción y resultados de la
revisión de pares".

Analizar datos acerca de la preparación,
conducción y resultados de la revisión de
pares.

SG 3: Verificar Artefactos
Seleccionados

Objetivo: "Los artefactos son verificados contra sus
requerimientos específicos".

           
Los métodos, procedimientos y criterios de
evaluación son usados para verificar que el artefacto
seleccionado y cualquier mantención asociada,
entrenamiento y servicios de soporte usan el ambiente de
verificación apropiado. Actividades de verificación
deben ser realizadas durante todo el ciclo de vida del
producto.

60.  SP 1:
Realizar la verificación

Práctica: "Realizar verificación de los
artefactos seleccionados".

           
Verificar incrementalmente productos y artefactos promueve la
detección temprana de problemas y puede resultar en la
remoción temprana de defectos. Los resultados de la
verificación ahorran costos considerables de fallas
aisladas y trabajo repetido asociado a la resolución de
problemas.

61.  SP 2:
Analizar resultados de verificación identificando
acciones correctivas

Práctica: "Analizar los resultados de todas
las actividades de verificación".

           
Los resultados actuales deben ser comparados con los criterios de
verificación establecidos para determinar la
aceptabilidad.

           
Los resultados del análisis son registrados como evidencia
de que la verificación fue realizada.

           
Para cada artefacto, todos los resultados de verificación
son analizados incrementalmente para asegurar que los
requerimientos hayan sido cumplidos.  Dado que la
revisión de pares es uno de varios métodos de
verificación, los datos de revisión de pares deben
ser incluidos en esta actividad de análisis para asegurar
que los resultados de la verificación son suficientemente
analizados.

Validación

El propósito de Validación (VAL) es
demostrar que un producto o componentes del producto cumplen su
uso planeado cuando es ubicado en su planeado
ambiente.

           
Actividades de validación pueden ser aplicadas a todos los
aspectos del producto en cualquiera de sus ambientes planeados,
tal como operación, entrenamiento, manufactura,
mantención, y servicios de soporte,  Los
métodos empleados para conseguir la validación
pueden ser aplicados a artefactos así como también
a productos o servicios y componentes del producto o
servicios.

SG 1: Preparar la validación

Objetivo: "La preparación para la
validación es conducida".

           
Actividades de preparación incluyen la selección de
productos y los componentes del producto para validación,
y establecer y mantener el ambiente, procedimientos y criterios
de validación. Los artefactos seleccionados para
validación pueden incluir sólo el producto o puede
incluir niveles apropiados de las componentes del producto que
son usados para construir el producto.  El ambiente de
Integración de Productos, Verificación y
Validación puede ser el mismo.

62.  SP 1:
Seleccionar Productos para la validación

Práctica: "Seleccionar productos y componentes
de productos a ser validados y los métodos de
validación que serán usados para cada
uno".

           
Productos y componentes de productos son seleccionados para
validación sobre la base de sus relaciones con las
necesidades del usuario. Para cada componente de producto, el
alcance de la validación (comportamiento operacional,
mantención, entrenamiento e interfase de usuario)
debería ser determinado.

           
Los requerimientos y restricciones para realizar la
validación son recopilados. Entonces, los métodos
de validación son seleccionados basándose en su
capacidad para demostrar que las necesidades de los usuarios
están satisfechas. Los métodos de validación
no sólo definen el enfoque técnico de la
validación del producto, sino también dirige las
necesidades para los equipos a utilizar y ambientes de
validación. Requerimientos derivados, como requerimientos
de interfaces para hacer pruebas y equipamientos, pueden ser
generados.

           
Los métodos de validación deben ser seleccionados
tempranamente en la vida del proyecto para que sean claramente
entendidos y acordados con las partes interesadas.

           
Los métodos de validación dirigen el desarrollo,
mantención, soporte y entrenamiento para el producto o las
componentes del producto según sea apropiado.

63.  SP 2:
Establecer el ambiente para la validación

Práctica: "Establecer y mantener el ambiente
necesario para apoyar la validación".

           
Los requerimientos para el ambiente de validación son
manejados por el producto o las componentes de productos
seleccionadas, por el tipo de artefacto (por ejemplo,
diseño, prototipo, versión final) y por los
métodos de validación. Esto podría producir
requerimientos para la compra o desarrollo de equipamiento,
software u otros recursos. El entorno de validación puede
incluir la reutilización de recursos existentes. En este
caso, se deben hacer arreglos para el uso de estos recursos.
Ejemplos de tipos de elementos en un ambiente de
validación incluyen lo siguiente:

-          
Herramientas de prueba interconectadas con el producto que esta
siendo validado.

-          
Software para prueba.

-          
Subsistemas simulados o componentes.

-          
Sistemas simulados.

-          
Sistemas reales.

-          
Facilidades y productos provistos por el cliente.

-          
Las personas hábiles para operar o usar todos los
elementos precedentes.

-          
Ambiente de prueba con computador dedicado o sistema
distribuido. 

64.  SP 3:
Establecer Procedimientos y Criterios de
Validación

Práctica: "Establecer y mantener
procedimientos y criterios de validación"

           
Procedimientos y criterios de validación son definidos
para asegurar que el producto o las componentes del producto van
a satisfacer su uso planificado cuando es ubicado en su ambiente
planificado. La aceptación de casos de pruebas y
procedimientos pueden satisfacer la necesidad de procedimientos
de validación.

           
Los procedimientos y criterios de validación incluyen
pruebas y evaluaciones de mantenimiento, entrenamiento y
servicios de soporte.

SG 2: Validar Productos o Componentes del
Producto

Objetivo: "El producto o las componentes del producto
son validados para asegurar que son aptas para su uso en su
ambiente operacional previsto".

           
Los métodos, procedimientos y criterios de
validación son usados para validar los productos y las
componentes de los  productos seleccionados y cualquier
mantenimiento, entrenamiento y servicios de apoyo asociado usando
el apropiado ambiente de validación. Actividades de
validación son realizadas durante todo el ciclo de vida
del producto.

65.  SP 1:
Realizar la validación

Práctica: "Realizar la validación sobre
los productos y las componentes del producto
seleccionados".

           
Para que sea aceptable para los usuarios, un producto o
componente del producto debe realizarse como es esperado en su
ambiente operacional planificado.

           
Las actividades de validación son realizadas y los datos
resultantes son recogidos de acuerdo a los métodos,
procedimientos y criterios establecidos.

           
Los procedimientos de validación sobre la marcha deben ser
documentados y las desviaciones que ocurran durante la
ejecución deben ser atendidas, según sea
apropiado.

66.  SP 2:
Analizar los resultados de la validación

Práctica:"Analizar los resultados de las
actividades de validación".

           
Los datos resultantes de las pruebas de validación,
inspecciones, demostraciones o evaluaciones son analizadas contra
los criterios de validación definidos. Los informes de
análisis indican si las necesidades fueron satisfechas; en
el caso de las deficiencias, estos documentos informan el grado
de éxito o fracaso y categorizan las probables causas de
fracaso. Las pruebas recolectadas, inspecciones o resultados
revisados son comparados con los criterios de evaluación
establecidos para determinar si avanzar o enfocarse en los
requerimientos que están bajo cuestión.

           
Analizar informes o documentación de validación
sobre la marcha también puede indicar que los malos
resultados de las pruebas son debido a problemas en los
procedimientos de validación o un problema en el ambiente
de validación.

Proceso de Desarrollo de Software de ORDEN
Integración

Introducción

ORDEN Integración es una organización
tecnológica chilena perteneciente al consorcio de Sonda
S.A. cuya misión es la de aportar con soluciones
informáticas precisas, de calidad, en forma oportuna y a
un precio justo al progreso y desarrollo de sus clientes. Cuenta
con más de 25 años de experiencia tanto a nivel
nacional como internacional y su visión es la de ser una
empresa global, con capacidad de aprendizaje, leal a sus
principios y de creciente competitividad, por lo cual su
inversión y proceso de transformación es
constante[2]. Es
considerada la fábrica de software de Sonda S.A., ya que
es aquí donde se realizan la mayoría de los
desarrollos de software a medida. Algunos sus clientes son:
Hospital Universitario Austral de Buenos Aires, Poder Judicial,
FONASA, Cámara de Comercio de Santiago, METRO Santiago,
Dirección General de Aeronáutica Civil, Registro
Civil, Contraloría General de la República, entre
otros. Dado que estos y sus demás clientes son
instituciones de prestigio nacional, la calidad de los productos
y servicios ofrecidos deben poder estar de alguna manera
garantizada; esto como parte de la estrategia de calidad definida
por la organización. Es por ello que el 2005 ORDEN
recibió la certificación de calidad del ya obsoleto
modelo CMM nivel 2 y actualmente ha iniciado el proceso de
acreditación de CMMI nivel 3, lo que va a implicar que no
sólo la organización cuente con una
metodología propia, con un proceso de desarrollo de
software bien definido de acuerdo a su propia forma de hacer
negocio, sino que se ponga énfasis en la ingeniería
de la metodología, lo cual sumado a los procesos de
gestión y apoyo se conforme una estructura completa de
todo el ciclo productivo de desarrollo de proyectos software. Sin
embargo el objetivo principal que persigue tanto el modelo como
la organización es que la metodología sea conocida
formalmente y bien utilizada por todos los miembros de ORDEN,
cambiando para mejor la forma de trabajar de cada una de estas
personas, no con el propósito de obligar a la gente a
realizar sus actividades cotidianas de una manera determinada,
sino para mejorar el orden, la comunicación, la
responsabilidad y finalmente la productividad de todos. De esta
forma se lograría institucionalizar la metodología
y madurar como organización.

           
Como se acaba de mencionar, ORDEN Integración actualmente
se encuentra trabajando junto con la empresa chilena
América XXI en la mejora de sus procesos de negocio con el
objetivo de certificarse bajo CMMI Nivel 3 para los primeros
meses del siguiente año. Es por ello que han decidido
enfocarse en los componentes esperados – prácticas
específicas y genéricas – para  cumplir
con los componentes requeridos – objetivos
específicos y genéricos – de este nivel de
madurez del modelo en su versión 1.2. Para alcanzar tal
certificación ORDEN integración se encuentra por un
lado redefiniendo algunos de sus procesos de acuerdo al modelo
para luego ser publicados a la organización, mientras que
por otro lado aquellos los procesos que ya fueron redefinidos y
publicados están en etapa de institucionalización
en la organización.

           
Los procesos de ORDEN Integración están divididos
en dos grandes áreas. La primera corresponde a los
Procesos de Administración de Proyectos e
Ingeniería de Software y la segunda a los Procesos de la
Administración General de la Fábrica de Software.
Dentro del área de Procesos de Administración de
Proyectos e Ingeniería de Software se encuentran una serie
de subáreas que en conjunto son las encargadas de
desarrollar y apoyar un proyecto en particular siguiendo su ciclo
de vida por completo. Estas subáreas incluyen: Procesos
Organizacionales (capacitaciones, métricas), Procesos de
Administración de Proyecto (planificación, control
y seguimiento, riesgos), Procesos de Ingeniería de
Software (requerimientos, análisis y diseño,
construcción, pruebas y despliegue) y Procesos de Soporte
(administración de la configuración, aseguramiento
de la calidad). Dentro del área de Procesos de la
Administración General de la Fábrica de Software se
encuentran todos los procesos que no participan directamente del
desarrollo de un proyecto, pero que son vitales para el
funcionamiento interno de la organización:
Planificación y Control Estratégico (presupuesto
anual), Procesos de Cierre Mensual de Actividades,
Evaluación y Preparación de Propuestas,
Administración de Personal y Administración de
Proveedores y Alianzas Estratégicas.

           
Como se mencionó anteriormente, es dentro del área
de Procesos de Administración de Proyectos e
Ingeniería de Software donde efectivamente los proyectos
son desarrollados de inicio a fin. En la subárea de
Procesos de Ingeniería de Software se encuentra alojado el
Proceso de desarrollo de software de ORDEN Integración,
que será presentado en detalle en este
documento.

           
El proceso o metodología de desarrollo de software de
ORDEN Integración está basado en un modelo
iterativo – incremental inspirado en el proceso de
desarrollo unificado RUP (Rational Unified Process, [Jac99])
desarrollado por Rational y perteneciente actualmente a IBM. Se
dice que está inspirado en RUP ya que está
acomodado de acuerdo a la experiencia de la organización
en el desarrollo de proyectos de ingeniería de software de
acuerdo al conocimiento por parte de sus creadores sobre la
metodología RUP y en parte también por el
conocimiento de estos sobre el modelo de calidad CMMI.  La
metodología consta de tres fases instauradas por ORDEN
Integración: Fase de Inicio, Fase de Elaboración
– Construcción y Fase de Transición. Estas
fases son análogas a las fases de la metodología
RUP. La Fase de Elaboración – Construcción se
presenta como una sola fase en los modelos debido a que presenta
más ítems en común que diferentes, pero como
metodología de desarrollo es tratada en fases diferentes
al igual que en el RUP, por lo cual implícitamente se
puede decir que la metodología de ORDEN Integración
se realiza en cuatro fases. En cada una de estas se desarrollan
seis disciplinas de Ingeniería: Describir el Problema de
Negocio, Especificar Requerimientos de la Solución,
Realizar Análisis y Diseño de la Solución,
Desarrollar Solución Sistémica, Asegurar
Correctitud y Funcionalidad de la Solución y Desplegar
Solución, además de tres procesos transversales y
de apoyo a estas disciplinas en cualquiera de las tres fases, los
cuales son: Administración de Requerimientos,
Revisión de Pares y Pruebas de Software.

           
En este documento se describirán las tres fases
separadamente mediante un diagrama UML, describiendo las
disciplinas presentes en cada fase, los procesos, actividades a
realizar, entradas y artefactos generados para cada una de ellas.
En los casos de las disciplinas de la fase que requieran de
análisis adicional por su complejidad, se detallará
su comportamiento en un diagrama de actividades realizando la
descripción respectiva. Las líneas de color negro
corresponden al flujo de actividades que se realizan en la
disciplina y las de color azul al flujo de artefactos utilizados
o generados en la misma. Además se describirán los
artefactos utilizados y generados en el proceso de desarrollo,
además de los actores responsables de cada uno de ellos y
finalmente de describirán los tres procesos de apoyo a las
disciplinas ya mencionados.

 Fase de
Inicio

Es la fase que da por iniciado un proyecto. Durante esta
fase se debe establecer el caso de negocio para el sistema y se
debe delimitar el alcance del proyecto. El diagrama de la Figura
5 es el que modela esta fase y la disciplina resaltada en gris
tiene un diagrama de actividades adicional debido a su
complejidad.

Figura 5: Fase de Inicio

Figura 6: Especificar Requerimientos de
la solución