- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
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. 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.- Introducción
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
InicioNombre: Describir el
Problema de NegocioArtefactos de Entrada:
Bases de Licitación, Contrato y Anexos.Artefactos de Salida:
Conceptos del Dominio, Proceso de Negocio,
Visión del Sistema.Actores Involucrados:
Analistas, Jefe de Proyecto, Stakeholders.Descripción:
A partir de lo estipulado en las Bases de
Licitación, en los Contratos y Anexos y por medio de
entrevistas personales se pretende
generar la Visión del Sistema que tiene el
cliente. Los analistas junto con el Jefe de Proyecto
deben identificar los principales Stakeholders del
proyecto y recoger sus visiones particulares sobre
cómo el nuevo sistema los afectará en su
quehacer cotidiano (qué esperan de él y
cómo piensan interactuar con él). Se
deben además identificar todos los procesos,
conceptos y relaciones entre ellos que estarán
dentro del dominio del problema del sistema. Para ello
lo primero que se debe realizar es obtener una
visión general de la empresa cliente, de sus procesos de
negocio claves y de sus necesidades y dificultades que
presenta en la actualidad. Además de obtener los
procesos de negocio, estos se deben analizar
identificando sus entradas, salidas, procedimientos
internos, actores participantes y el entorno en el que
se ejecutan generando de este estudio los Diagramas de Procesos, los cuales
identifican cómo el cliente realiza actualmente
sus actividades.Nombre: Especificar
Requerimientos de la soluciónArtefactos de Entrada:
Bases de Licitación, Contrato y Anexos, Concepto de Dominio, Proceso de Negocio,
Descripción de la Solución.Artefactos de Salida:
Requerimiento original ofrecido, Requerimiento de
Negocio, Criterios de Aceptación, Requerimiento
de Sistema, Requerimientos Funcionales, Requerimientos
No Funcionales.Actores Involucrados:
Analistas, Jefe de Proyecto, StakeholdersDescripción (ver
Figura 6)En función de las Bases de
Licitación y de reuniones informales con el
cliente, se busca encontrar la respuesta a la pregunta
¿qué debe hacer el sistema?En esta disciplina se deben compatibilizar los
deseos del cliente y los alcances contractuales
ofrecidos con lo que se puede lograr sistematizar de
acuerdo a las capacidades tecnológicas tanto del
cliente como de ORDEN Integración. Para ello, se
registran aquellos requerimientos planteados
directamente por el cliente como Requerimientos de
Negocio. Estos conforman la primera forma de
requerimientos para el proyecto. Esta lista debe
permanecer invariable por el resto del proyecto como
registro de las necesidades originales del cliente.
Luego se identifican aquellos requerimientos que fueron
originalmente ofrecidos en la Descripción de la
Solución, desarrollada en la propuesta del
proyecto, y en el contrato firmado con el cliente.
Sobre los requerimientos originales ofrecidos, se les
debe relacionar con aquellos Requerimientos de Negocio
a los que estén dando respuesta. En
función de estas relaciones se deben identificar
aquellos requerimientos de negocio que no estén
ofrecidos y aquellos requerimientos ofrecidos que no
obedecen a ningún requerimiento de negocio
identificado y generar riesgos asociados a estas
diferencias. En el caso de Requerimientos de Negocio
que no se hayan ofrecido, estos se deben dejar en claro
al cliente para lograr un acuerdo en cuanto a que no se
debe esperar dicha funcionalidad o a que el
tamaño del proyecto ofrecido ha cambiado por lo
tanto se debe clasificar como cambio. En el caso de los requerimientos
ofrecidos que no responden a ningún
Requerimiento de Negocio se deben tener en cuenta que
puede que no sean necesarios para el cliente y por lo
tanto se pueden descartar previo acuerdo con todas las
partes involucradas.
Figura 6: Especificar
Requerimientos de la soluciónLa lista de Requerimientos originales
ofrecidos permanece invariable como registro del
límite comprometido del sistema. Finalmente se
genera una lista definitiva con todos los
Requerimientos del Sistema, los cuales deben estar
relacionados por lo menos con uno de los requerimientos
ofrecidos. Lo que se debe lograr es identificar y
acotar los límites de cada requerimiento y
los actores involucrados. Los Requerimientos de Sistema
deben además estar relacionados con aquellos
Procesos de Negocio que van a sistematizar y con
aquellos Conceptos de Dominio con los que
tendrán que lidiar. Cualquier proceso y concepto
que quede sin relacionar con algún requerimiento
de sistema se considerará fuera del dominio del
sistema y debe quedar apropiadamente
registrado.Como prueba final se debe comprobar que cada
uno de los Requerimientos originales ofrecidos que se
pretenden implementar esté siendo realizado por
un Requerimiento de Sistema y que el 100% de los
Requerimientos de Sistema estén dando
cumplimiento a por lo menos uno de los Requerimientos
originales ofrecidos. Los Requerimientos de Sistema que
no estén cumpliendo requerimientos ofrecidos dan
cuenta de cambios en el tamaño del sistema que
se piensa desarrollar en relación al que se
ofreció. Requerimientos originales que no
estén siendo realizados por Requerimientos de
Sistema dan cuenta de posibles omisiones de
funcionalidad comprometida en el sistema a ser
desarrollado y que luego podrían ser objetadas
por los clientes.Nombre: Realizar
Análisis y Diseño de la
SoluciónArtefactos de Entrada:
Descripción de la solución, Visión
del Sistema, Requerimiento de SistemaArtefactos de Salida:
Planteamiento de Arquitectura InicialActores Involucrados:
ArquitectoDescripción:
En función de los requerimientos
identificados el arquitecto del proyecto construye un
Planteamiento de Arquitectura Inicial, identificando
módulos y componentes principales y las
soluciones tecnológicas asociadas a cada uno. Se
debe determinar además cuáles componentes
de la arquitectura son aquellos que tienen mayor
riesgo de desarrollo.Nombre: Desarrollar
Solución SistémicaArtefactos de Entrada:
Planteamiento de Arquitectura InicialArtefactos de Salida:
Prueba de ConceptoActores Involucrados:
DesarrolladorDescripción:
Con el Planteamiento de Arquitectura Inicial
ya realizado se debe determinar si hay aspectos del
sistema que requieran una prueba de concepto de la
solución planteada para asegurar la factibilidad de la misma. Si se
determina que son necesarias una o más pruebas
de concepto, estas se desarrollan de acuerdo a la
importancia de cada una.Nombre: Asegurar
Correctitud y Funcionalidad de la
SoluciónArtefactos de Entrada:
Requerimiento original ofrecido, Visión del
Sistema, Prueba de ConceptoArtefactos de Salida:
N.A.Actores
Involucrados: Jefe de Proyecto,
Arquitecto.Descripción:
Verificar que las Pruebas de Concepto se
ajusten a lo ofrecido y que concuerde con la
Visión del Sistema que tiene el cliente. Esta
verificación generalmente involucra una
revisión de pares con otro arquitecto con el fin
de examinar la solución planteada por el
arquitecto del proyecto y proponer cambios o mejoras a
ésta.Nombre: Desplegar
SoluciónArtefactos de Entrada:
Prueba de ConceptoArtefactos de
Salida:Actores Involucrados: Jefe
de proyecto, Arquitecto, StakeholdersDescripción:
De ser necesario se pueden desplegar en un
ambiente temporal algunas de las pruebas de concepto
verificadas para ser mostradas a los Stakeholders
interesados y demostrar su correctitud y funcionalidad
ante ellos. - Fase de
InicioLa Fase de Elaboración –
Construcción tiene por objetivo establecer una base
sólida de la Arquitectura de Software a partir del
análisis y diseño de los requerimientos, para
luego implementar el sistema en base a estos diseños y
arquitectura planteados. En el diagrama de la Figura 7 se
modela esta fase, destacando con gris las disciplinas que por
su complejidad presentan un diagrama de actividades adicional
para detallar su comportamiento.
Figura 7: Fase de
Elaboración – ConstrucciónNombre: Describir el
Problema de NegocioArtefactos de Entrada:
Visión del Sistema, Concepto de Dominio, Proceso
de NegocioArtefactos de Salida: N.
A.Actores Involucrados:
AnalistaDescripción:
Se revisan los documentos de Visión del
Sistema, Procesos de Negocio y Concepto de Dominio en
términos de los requerimientos que se quieren
atacar. Se pueden realizar correcciones menores a estos
documentos cuando corresponda, en función del
análisis que se realiza en esta etapa de vida
del proyecto.Nombre: Especificar
Requerimientos de la soluciónArtefactos de Entrada:
Planteamiento de Arquitectura Inicial, Requerimiento de
Sistema, Arquitectura del SistemaArtefactos de Salida:
Criterios de Aceptación, Requerimiento de
Sistema, Prototipo de Sistema, Mecanismos de
Diseño (Patrones)Actores Involucrados:
Analistas, Arquitecto, Stakeholders, Jefe de
ProyectoDescripción (ver
Figura 8):La diferencia entre las fases de
Elaboración y Construcción radica que
durante la Elaboración se atacan los
requerimientos de arquitectura más importantes,
que darán como resultado la mayor parte de los
mecanismos de diseño del sistema.Sobre el conjunto de Requerimientos de Sistema
que se quieren atacar se deben detallar por completo
los antecedentes necesarios para comprender y acotar
qué es lo que debe hacer cada parte del sistema,
indicando los escenarios principales, secundarios y las
restricciones. Esto incluye la realización de
prototipos no funcionales, que sirvan tanto para
mostrar al cliente una vista previa del sistema como
para la fase de diseño donde la interfaz se debe
diseñar completamente.
Figura 8: Especificar
Requerimientos de la soluciónSe debe determinar que los Requerimientos de
Sistema estén cumpliendo con los requerimientos
ofrecidos y que no se requiere más de lo
originalmente ofrecido del sistema. Cualquier
desviación de estas líneas debe ser
debidamente controlada. También se deben revisar
los Criterios de Aceptación de los
requerimientos con el cliente con los analistas
encargados y con analistas que no sean parte del
proyecto por medio de una revisión de pares y si
existe una modificación en los requerimientos
también se debe modificar este documento con la
debida aprobación del cliente. Luego el
arquitecto debe determinar si los mecanismos de
diseño definidos alcanzan para cubrir estos
requerimientos si se deben generar nuevos mecanismos o
si se deben adaptar los antiguos. Esto debiese darse
solo en la fase de la Elaboración ya que durante
la Construcción todos los problemas deben haber
sido previamente atacados y por tanto no debiese surgir
la necesidad de crear nuevos mecanismos para los mismos
problemas. - Fase de
Elaboración –
Construcción
 Página anterior | Volver al principio del trabajo | Página siguiente  |