Monografias.com > Uncategorized
Descargar Imprimir Comentar Ver trabajos relacionados

Modelo CMMI (página 3)



Partes: 1, 2, 3, 4, 5

  • 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.

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.

  1. 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.

  • 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

  1. 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.

  2. 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
    Inicio

    Nombre: Describir el
    Problema de Negocio

    Artefactos 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ón

    Artefactos 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, Stakeholders

    Descripció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ón

    La 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ón

    Artefactos de Entrada:
    Descripción de la solución, Visión
    del Sistema, Requerimiento de Sistema

    Artefactos de Salida:
    Planteamiento de Arquitectura Inicial

    Actores Involucrados:
    Arquitecto

    Descripció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émica

    Artefactos de Entrada:
    Planteamiento de Arquitectura Inicial

    Artefactos de Salida:
    Prueba de Concepto

    Actores Involucrados:
    Desarrollador

    Descripció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ón

    Artefactos de Entrada:
    Requerimiento original ofrecido, Visión del
    Sistema, Prueba de Concepto

    Artefactos 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ón

    Artefactos de Entrada:
    Prueba de Concepto

    Artefactos de
    Salida
    :

    Actores Involucrados: Jefe
    de proyecto, Arquitecto, Stakeholders

    Descripció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.

  3. Fase de
    Inicio

    La 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ón

    Nombre: Describir el
    Problema de Negocio

    Artefactos de Entrada:
    Visión del Sistema, Concepto de Dominio, Proceso
    de Negocio

    Artefactos de Salida: N.
    A.

    Actores Involucrados:
    Analista

    Descripció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ón

    Artefactos de Entrada:
    Planteamiento de Arquitectura Inicial, Requerimiento de
    Sistema, Arquitectura del Sistema

    Artefactos de Salida:
    Criterios de Aceptación, Requerimiento de
    Sistema, Prototipo de Sistema, Mecanismos de
    Diseño (Patrones)

    Actores Involucrados:
    Analistas, Arquitecto, Stakeholders, Jefe de
    Proyecto

    Descripció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ón

    Se 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.

  4. Fase de
    Elaboración –
    Construcción

Partes: 1, 2, 3, 4, 5
 Página anterior Volver al principio del trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter