Modelo CMMI (página 5)

Enviado por Mat�as Fuentes Contreras

Partes: 1, 2, 3, 4, 5

Actividad: Evaluar Control de Cambios

Entradas: Antecedentes
Asociados al control de
cambio, Registro de Requerimiento

Salidas: Registro de
Requerimiento

Actores Involucrados: Jefe
de Proyecto, Gerente de Proyecto

Descripción (Ver
Figura 15):

Figura 15: Evaluar Control de
Cambios

El objetivo de esta actividad es evaluar un
control de cambios desde el punto de vista de su
complejidad para ser implementado. El proceso se inicia registrando la
incidencia de realizar el cambio. Si son varios los cambios
involucrados en la misma solicitud se debe sumar todo lo
que está contenido en ella. Para estimar el
esfuerzo se recomienda considerar al menos los siguientes
aspectos:

– Cantidad de cambios incluidos en la
solicitud.

– Complejidad en cuanto a si los requerimientos
afectan pocas o muchas áreas del proyecto, en
cuanto a funciones y a áreas de desarrollo y producción involucradas (cliente, usuarios, ambiente de desarrollo,
explotación)

– Fase del proyecto en que llega el
requerimiento. A mayor avance del proyecto puede ser
más complejo incorporar un cambio.

Los niveles de complejidad del cambio son tres:
Complejo, Medio y Simple. Se define que un cambio es de
nivel complejo si se encuentra en alguna de las
siguientes situaciones:

– El número de cambios a los
requerimientos es mayor que cinco.

– Es necesario un cambio importante en el
diseño.

– El esfuerzo para implementar el cambio es
superior a dos días.

Se define que un cambio de nivel Medio cuando no
es Complejo, pero si requiere análisis o especificación
detallada durante su ejecución. Se define que un
cambio es de nivel Simple si no cumple con la
definición de nivel Complejo y el detalle de la
especificación se puede realizar durante la
especificación inicial del cambio y no requiere
análisis o especificación durante su
ejecución. El alcance del cambio es acotado y sin
ambigüedades.

Luego de determinar el nivel de complejidad del
cambio se da a conocer al Gerente de Proyecto, y es
éste quien decide si realizar o declinar el
Análisis de Impacto para un control de cambio. Las
opciones que tiene son aprobar, rechazar o postergar el
análisis de impacto del cambio, dependiendo del
estado
del proyecto, de la disponibilidad inmediata de recursos, de la criticidad del cambio o
algún otro criterio aplicable para la
decisión. En caso de aprobar el análisis de
impacto, se definirá también la
conveniencia de aplicar el Proceso Formal de Toma de
Decisiones dependiendo de la magnitud de los cambios
y los riesgos que se visualicen para los
objetivos del proyecto. Tomada la
decisión se actualiza el
estado del requerimiento como Aprobado, Rechazado,
Postergado según corresponda. El proceso finaliza
al designar un responsable de la incidencia en base a las
competencias y disponibilidades
existentes.

Actividad: Analizar Control
de Cambios

Entradas: Antecedentes
asociados al Control de Cambios, Registro de
Requerimientos

Salidas: Registro de
Requerimientos, Carta
Gantt

Actores Involucrados: Jefe
de Proyecto, Analista

Descripción (ver
Figura 16):

Figura 16: Analizar Control de
Cambios

El objetivo general de esta actividad es
analizar en profundidad el alcance de un cambio
solicitado, para efectos de estimar el esfuerzo y
costos
necesarios para implementarlo, así como evaluar
los riesgos asociados

En base a la decisión tomada en el paso
anterior, que depende de la magnitud de los cambios y los
riesgos que se visualicen para el cumplimiento de los
objetivos del proyecto, se realiza un Proceso Formal de
Toma de Decisiones (basado en el área de proceso
DAR del modelo
CMMI) o se procede como se describirá a
continuación.

El Analista a cargo del Control de Cambio
determinará la necesidad de planificar actividades
específicas dependiendo de la complejidad del
cambio analizada en la etapa anterior. Esta complejidad
determinará también la necesidad de
ejecutar las actividades venideras. El Jefe de Proyecto
debe actualizar la
carta Gantt del proyecto registrando cambios en los
cronogramas de las actividades debido al
cambio.

Se debiesen identificar todos los objetos
afectados por el cambio, seleccionar a las personas
idóneas para resolver el cambio, definir
cuáles serán los artefactos que
generará el implementar el cambio e identificar
también las eventuales inconsistencias con la
solución ya definida que provocará el
cambio. Con todas estas actividades resueltas ya se
podría actualizar el detalle del control de cambio
con su estado, como a su vez mantener un historial y
actualizar la trazabilidad de requerimientos.

Actividad: Calcular
tamaño y esfuerzo según metodología y tailoring
seleccionados para cada disciplina de la ingeniería.

Entradas: Work Breakdown
Structure (WBS).

Salidas: Work Breakdown
Structure (WBS), Estimación de Esfuerzo,
Estimación de Costo.

Actores Involucrados: Equipo
responsable de estimar tamaño, esfuerzo, costos y
plazos del proyecto.

Descripción (Ver
Figura 17):

El objetivo de esta actividad es efectuar
estimaciones de tamaño, esfuerzo y costos del
proyecto, de acuerdo a la metodología
seleccionada, a datos
históricos y supuestos. Se debiesen considerar
datos históricos acumulados para ajustar supuestos
y validar resultados de estimaciones. Se debiese
también fundamentar el uso de estos datos
históricos seleccionados para las estimaciones y
se debe mantener consistencia en los nombres usados en el
Registro de Requerimientos en EA para asegurar
trazabilidad.

Todas las estimaciones e identificaciones,
tamaño, esfuerzo y costo principalmente, deben ser
actualizadas en el Work Breakdown Structure
(WBS).

Figura 17: Calcular
tamaño y esfuerzo según metodología
y tailoring seleccionados para cada disciplina de la
ingeniería

Actividad: Ingresar
cubicación y evaluar compromisos

Entradas: Resultado de
Cubicación

Salidas: Registro de
Requerimientos, Informe de Control de Cambios al
Cliente

Actores Involucrados:
Ejecutivo Comercial, Jefe de Proyecto

Descripción (Ver
Figura 18):

Figura 18: Ingresar
cubicación y evaluar compromisos

El objetivo de esta actividad es adoptar una
posición definitiva ante el cambio solicitado y
formalizar la respuesta al cliente.

Luego de actualizar la información de esfuerzo y costo
correspondiente al requerimiento tratado, se procede a
revisar, sobre la base del análisis de impacto
realizado y el estado actual del proyecto, los
compromisos que deben asumirse por el proyecto para
implementar el cambio solicitado. Si no se realiza un
cambio por desaprobación del cliente se elabora
una propuesta alternativa y se informa al cliente para
conseguir la aprobación formal por parte del
cliente. Si el cambio es realizado se debe generar la
propuesta comercial para el cliente cuando corresponda, y
crear una carta de aprobación formal para el
cambio, que debe ser enviada al cliente para su
aprobación.

Actividad: Formalizar
implementación

Entradas: Informe de Control
de Cambios al Cliente, Carta de Respuesta

Salidas: N. A.

Actores Involucrados:
Cliente, Jefe de Proyecto

Descripción (Ver
Figura 19)

Figura 19: Formalizar
implementación

El objetivo de esta actividad es formalizar la
implementación del Control de Cambios a un
requerimiento. La información del informe de
control de cambios preparado para el cliente y la carta
de respuesta enviada al Cliente es revisada por
éste para su aprobación. Cuando el cambio
es aprobado por el cliente se gestionan las líneas
bases del proyecto, tanto las correspondientes a los
requerimientos como a las de planificación y de entregables.
Junto con ello se actualizan los artefactos de gestión que correspondan, de
acuerdo a las características e impacto del cambio
aprobado y considerando al menos los siguientes: Carta
Gantt, Plan
de Riesgos, Cálculo de Esfuerzo, WBS y Plan de
Proyecto. Finalmente se debe comunicar a todas las partes
interesadas el alcance del control de cambios,
llámense equipo de proyecto, equipo de pruebas, de aseguramiento de la calidad y de administración de la
configuración. Si el cambio no es aceptado por el
cliente, se debe escalar el caso al nivel de jefatura
correspondiente, ajustando estimaciones de esfuerzo y
costos y replanteando las estrategias.

Luego de atacar algún posible cambio a los
requerimientos se realiza la Revisión de Pares, otro de
los procesos de
apoyo a la metodología de desarrollo de ORDEN Integración que será detallado
como proceso aparte más adelante en este
documento.

Realizada la Revisión de Pares, se ejecuta la
actividad modelada con el diagrama que
ya fue presentada y detallada en la Figura 17, para poder
realizar estimaciones de tamaño, esfuerzo y costos del
proyecto de acuerdo a la metodología seleccionada
(típicamente la que se está presentando en este
documento), de acuerdo a datos históricos de la
organización y a supuestos del proyecto.

Con los datos de las estimaciones de tamaño,
esfuerzo y costos se realiza la actividad Ingresar
cubicación y comunicar Requerimiento cuyo diagrama se
presenta en la Figura 20

Figura 20: Ingresar
cubicación y comunicar Requerimiento

Actividad:
Planificación

Entradas: N. A.

Salidas: N. A.

Actores Involucrados: Jefe
de Proyecto

Descripción:

La planificación realizada para cada
requerimiento entrega como resultado las estimaciones de
su costo, esfuerzo y tamaño.

Actividad: Incorporar
información de esfuerzo al requerimiento que
corresponda

Entradas:

Salidas: Registro de
Requerimientos

Actores Involucrados: Jefe
de Proyecto

Descripción:

Los datos de cubicación, llámense
estimaciones de esfuerzo, tamaño y costo
principalmente, son incorporadas al requerimiento
correspondiente, siendo a su vez actualizadas en la
herramienta Enterprise Architect.

Actividad: Recopilar
información de requerimientos

Entradas: xxx.PPPYE.Productos y Entregables.xls, xxx.PDP.Plan
de Proyecto.doc, xxx.PPCDE.Calculo de Esfuerzo.xls,
xxx.PPPAR.Plan Administración de
Riesgos.xls

Salidas: N. A.

Actores Involucrados: Jefe
de Proyecto

Descripción:

Se recopila la información almacenada de
los requerimientos en base a las planillas y documentos generadas y al registro de
requerimientos almacenado en Enterprise
Architect

Actividad: Enviar Documentación a grupos
involucrados

Entradas: N. A.

Salidas: QA,CM, Testing,
Gerente Proyectos, otros roles
identificados.

Actores Involucrados: Jefe
de Proyecto

Descripción:

La información de los requerimientos se
envía a las partes involucradas en el desarrollo
del proyecto.

Revisión
de Pares

La Revisión de Pares es un técnica de
testing estático definido como un proceso
metódico, formal y estructurado en el cual se examina un
producto
intermedio o final, con el propósito de encontrar y
corregir defectos en forma temprana, e incluso identificar
eventualmente cambios requeridos para optimizar el
funcionamiento de un sistema. Esta
revisión puede ser conducida por un par o un equipo de
pares del autor del producto con roles y tareas
específicas.

El proceso consiste en someter un producto de trabajo al
escrutinio de uno o más profesionales con un nivel de
conocimiento
y experiencia equivalente al del autor del artefacto, de tal
manera de poder evaluar objetivamente su contenido, detectar
eventuales falencias y proponer medidas correctivas. Ejemplos
de interlocutores válidos para la revisión de
pares pueden ser un jefe de proyecto, un arquitecto de software, un
desarrollador u otro rol dependiendo de las
características del artefacto seleccionado.

El proceso de revisión de pares consta de dos
actividades como se puede apreciar en la Figura 21

Figura 21: Revisión de
Pares

Actividad: Preparar
revisión de pares

Entradas: Checklist de
Revisión de Pares, Producto de trabajo a
revisar

Salidas: N. A.

Actores Involucrados: Jefe
de Proyecto, Revisor, Autor del producto a
revisar

Descripción (Ver
Figura 22):

Figura 22: Preparar
revisión de pares

El objetivo de esta actividad es efectuar las
actividades preparatorias y generar las condiciones para
una revisión de pares. El criterio de entrada es
cuando corresponda examinar un artefacto del proyecto con
esta técnica.

En principio de debe convocar al autor del
producto a revisar y al revisor designado a una
reunión y en ella se deben exponer brevemente las
características del producto a ser revisado y se
acuerdan criterios básicos para realizar la
revisión de pares, según las
características del proyecto y del producto.
Algunas de las características que se deben
definir son: Criterios de entrada y salida, Reglas de
proceso, Plazos de la revisión. Luego de esto se
procede a actualizar el checklist de la Revisión
de Pares con las definiciones realizadas.

El autor debe seleccionar el material de apoyo
que se le proveerá al revisor dependiendo del
producto de trabajo a revisar y de las definiciones
surgidas de la reunión de coordinación y finalmente debe
enviar el producto a ser verificado junto con sus
antecedentes asociados y cualquier material de apoyo
útil para realizar la revisión.

Actividad: Ejecutar
Revisión de Pares

Entradas: Checklist de
Revisión de Pares, Producto de trabajo a
revisar

Salidas: Informe de
observaciones

Actores Involucrados: Jefe
de Proyecto, Revisor(es), Autor(es)

Descripción (Ver
Figura 23):

Figura 23: Ejecutar
Revisión de Pares

El objetivo de esta actividad es ejecutar una
revisión de pares en el momento en que un revisor
ha recibido conforme el artefacto a revisar junto con
todo su material de apoyo.

Esta actividad comienza verificando que existan
las condiciones para efectuar la Revisión de
Pares, en cuanto a disponibilidad de artefactos y
documentación asociada según los acuerdos
alcanzados en la reunión preparatoria. Luego se
realiza la revisión del artefacto según la
checklist, la aplicación de la metodología
y los antecedentes asociados, registrando los defectos
encontrados en el Reporte de Observaciones y registrando
además el tiempo
dedicado a la revisión.

Paso siguiente es convocar a reunión al
Jefe de Proyecto y al Autor o Autores del artefacto con
el objetivo de analizar las observaciones encontradas,
unificar criterios, determinar los defectos definitivos,
registrarlos en el reporte y de ser necesario definir
plazos para nueva revisión. El autor debe
responder a las observaciones mencionadas y aclarar los
temas que sean necesarios. Si la respuesta satisface al
equipo revisor, el problema no se registra. El Jefe de
Proyecto registra el resultado de la reunión y
entrega al Autor y Equipo Revisor sus
conclusiones.

Además se debe determinar si las
modificaciones requeridas ameritan una nueva
revisión de pares; si es así, se planifica
una nueva reunión. También se deben
registrar métricas asociadas, como lo son
esfuerzo, cantidad de defectos encontrados, cantidad de
revisión de pares por producto, etc.

Luego se debe planificar la incorporación
de las correcciones requeridas al artefacto revisado,
ingresando los defectos válidos como eventos no planificados. Hecha la
planificación, se realizan las modificaciones
solicitadas y en base a estas se realiza la evaluación y validación a
estas correcciones para determinar si estas corrigen los
defectos encontrados en la revisión, para en
consecuencia definir si el producto cumple con los
criterios de salida definidos, de manera de dar por
finalizada la Revisión de Pares. Si las
modificaciones no son satisfactorias, se efectúan
nuevamente las modificaciones solicitadas hasta que
cumplan con los criterios de salida.

La revisión de pares culmina con la
recolección de métricas generadas en cada
una de las etapas del proceso, con la
incorporación de nuevas métricas y con la
generación de resultados en el informe consolidado
del proceso. Se debe verificar que la Revisión de
Pares se haya aplicado sobre el producto definido, que
los reportes generados se hayan completado, que los
productos y métricas hayan sido actualizados
según lo acordado, que se haya consolidado y
archivado la documentación del proceso.

Pruebas de
Software

Este proceso tiene por objetivo asegurar que el producto
cumple con lo esperado y con los requerimientos definidos. Es un
proceso que es transversal a todo el ciclo de vida
del proyecto y presenta las siguientes políticas:

La planificación, coordinación y
ejecución de pruebas es responsabilidad de la Unidad de Control de
Calidad.
Las pruebas son ejecutadas de acuerdo al contenido
del Plan de Pruebas de cada proyecto.
Se generan reportes con observaciones y las acciones
correctivas son planificadas y controladas.
Todos los productos de software desarrollados en
ORDEN Integración son sometidos a Control de
Calidad.

La Unidad de Control de Calidad, perteneciente a la PMO,
es la instancia encargada de llevar a cabo la verificación
del software generado, como resultado de un proyecto de
desarrollo, mediante realización de pruebas de diversos
tipos. Para tal efecto cada proyecto cuenta con un responsable de
dicha unidad, el cual responde por el diseño,
planificación y ejecución de las pruebas así
como de reportar el resultado de las pruebas al Jefe de Proyecto.
La Unidad de Control de Calidad representa una función de
apoyo a los proyecto de desarrollo y administra sus actividades
como un proyecto independiente, aplicando las prácticas de
gestión de proyectos, a saber:

Administración de Requerimientos
Planificación de Proyectos
Control y Seguimiento
Aseguramiento de calidad
Administración de la
Configuración

El Proceso de Pruebas de Software se divide en dos
actividades o subprocesos que se ejecutan de manera secuencial,
las cuales son Preparar Pruebas y Ejecutar Pruebas (ver Figura
24)

Figura 24: Pruebas de
Software

Actividad: Preparar
Pruebas

Entradas: Bases de
Licitación, Registro de Requerimientos, Informe de
Diseño, Metodologías de prueba de
software.

Salidas: Casos de Prueba,
Datos de Prueba, Definición de ambientes de prueba,
Plan de Pruebas.

Actores Involucrados:
Responsable de Pruebas de Software, Jefe de
Proyecto

Descripción (Ver Figura
25):

Esta actividad o proceso tiene como objetivo
efectuar actividades preparatorias y generar las
condiciones para pruebas de software y se ejecuta cuando
hay que verificar el funcionamiento del software construido
en un proyecto de desarrollo. El proceso describe las
siguientes actividades:

Determinar productos de software que
serán probados a partir del contenido de las Bases
de Licitación y Registro de Requerimientos. Estos
pueden ser módulos, funciones, requerimientos,
productos y componentes de productos.
Definir alcance de las pruebas. Incluye tipos
de pruebas, enfoques y restricciones. Los tipos de prueba
son funcionales, de seguridad, de rendimiento, de
aceptación o de instalación.
Definir método de pruebas para productos y
componentes de software. Los métodos pueden ser: Caja Negra,
Caja Blanca, Partición Equivalente,
Análisis de Valor
Límite, Comparación, Caja de Cristal, Caja
de Pandora, Integración Ascendente,
Integración Descendente, Integración
Combinada o Integración Big-Bang.
Generar casos de prueba y datos de prueba que se
utilizarán en la ejecución de pruebas.
Los datos de prueba mencionados en el punto 4 pueden
ser generados por el equipo de trabajo, el equipo de
pruebas o proporcionados por el cliente, lo cual debe
quedar establecido en el Plan de Pruebas.

Figura 25: Preparar
Pruebas
Definir ambiente de pruebas. Se debe Registrar
todos los detalles técnicos de la creación
y todas aquellas consideraciones especiales que sea
necesario recordar ante una reconstitución del
ambiente para iterar todos o algunos de los casos de
prueba. Los datos son registrados en el documento
Definición de Ambiente de Pruebas el cual es
anexado al Plan de Pruebas. Este documento incluye
red,
servidor, privilegios, espacio en disco,
herramientas de prueba y recurso humano
que ejecutarán las pruebas.
Estimar esfuerzo para ejecución de las
pruebas. Se debe considerar todas las actividades
relacionadas con las pruebas: revisión de
documentación, elaboración del Plan de
Pruebas, generación del ambiente de pruebas,
análisis transaccional, generar escenarios de
pruebas, preparación de casos de prueba,
generación de datos de prueba, ejecución
de las pruebas, seguimiento de las pruebas, consolidar
resultados y generar reportes, y generar informe final
y métricas.
* Todos los anteriores documentos generados
formarán parte del Plan de Pruebas.
Estimar plazos para ejecución de las
pruebas, considerando recursos disponibles para pruebas y
estimaciones de productividad individual
Informar planificación de pruebas al
Jefe de Proyecto para coordinación

El Jefe de Proyecto es el encargado de aprobar el
Plan de Pruebas analizando su compatibilidad con las
eventuales restricciones del proyecto. En el caso de no
aprobar el documento se debe revisar los puntos en conflicto.

Actividad: Ejecutar
Pruebas

Entradas: Plan de Pruebas,
Informe de Diseño, Software a probar, Casos de
Prueba, Datos de Prueba

Salidas: Métricas de
validación, Reporte de Observaciones

Actores Involucrados:
Responsable de Pruebas de Software, Equipo de
Proyecto.

Descripción (ver Figura
26):

Figura 26: Ejecutar
Pruebas

Esta actividad o proceso tiene como objetivo
verificar el funcionamiento del software construido en un
proyecto de desarrollo y alcanzar los criterios de
aceptación o de término de pruebas definidos.
El proceso contiene las siguiente actividades:

Ejecutar pruebas de acuerdo al plan: Se
ejecutan las acciones, procedimientos y programas establecidos para cada prueba
aplicando los Casos de Prueba definidos y los datos de
pruebas generados para tal efecto.
En caso de pruebas sobre funciones corregidas
se ejecutan pruebas de regresión para asegurar que
las correcciones no crearon problemas en otra parte del
software.
Documentar resultados en el Informe de
Observaciones.
Analizar resultados de las pruebas
determinando: problemas de construcción de software, problema
con el método de pruebas seleccionado, problemas
del ambiente de pruebas (infraestructura, datos de
pruebas, componentes de software faltantes, emitir
recomendaciones de mejora si es posible).
Determinar criticidad de las observaciones:
defectos de forma, defectos de fondo, factibilidad de continuar con otras
pruebas a pesar de los defectos detectados.
Comunicar resultados de las pruebas al
proyecto
Acumular métricas del proceso: cantidad
de defectos total, cantidad de defectos por
categoría (grave, mediana, leve), cantidad de
iteraciones.

Referencias

[Bat95]	Roger Bate, Dorothy Kuhn, Curt Wells, James Armitage, Gloria Clark, Kerinia Cusick, Suzanne Garcia, Mark Hanna, Robert Jones, Peter Malpass, Ilene Minnich, Hal Pierson, Tim Powell, Al Reichner: "A Systems Engineering Capability Maturity Model, Version 1.1", 1995.
[Chr06]	Mary Beth Chrissis, Mike Konrad, Sandy Shrum; "CMMI® for Development, v1.2", 2006.
[Gon07]	Gonzalez, Carlos: "Conceptos Generales de Calidad Total", Monografías, 2007. http://www.monografias.com/trabajos11/conge/conge.shtml
[Inc96]	INCOSE: "Systems Engineering Capability Assessment Model", 1996. http://www.incose.org/ProductsPubs/pdf/SECAM-SysEngCapabilityAssessModel_1996-06.pdf
[Jac99]	Ivar Jacobson, Grady Booch, James Rumbaugh: "The Unified Software Development Process", 1999.
[Kul03]	Margaret K. Kulpa, Kent A. Johnson: "Interpreting the CMMI: A Process Improvement Approach", 2003.
[Pal06]	Palacio, Juan: "Sinopsis de los modelos CMM-SW y CMMI", 2006 http://www.navegapolis.net/files/articulos/sinopsis_cmm.pdf
[Pau93]	Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber: "Capability Maturity Model for Software, Version 1.1", 1993. http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf
[Rat03]	IBM Staff: "Rational Unified Process Best Practices for Software Development Teams", 2003. http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
[Rig06]	Rigoni, Cecilia: "CMMI®: Mejora del proceso en Fábricas de Software", 2006. http://www.mityc.es/NR/rdonlyres/A570B90C-B41A-46E2-BD39-4A31D18BB7FD/0/s01CeciliaRigoni.pdf
[Sec07a]	© SECAT LLC: "Understanding the SECM (EIA/IS 731.1)", 2007. http://www.secat.com/workshops/731.1_WorkshopDescription.htm

[Sec07b]	© SECAT LLC: "Integrated Product Development Capability Maturity Model overview briefing", 2007. http://www.secat.com/download/locked_pdf/IPDovrvw_lkd.pdf
[SEI00]	Software Engineering Institute, Carnegie Mellon University: "ARC, V1.0 Assessment Requirements for CMMI Version 1.0", 2000 http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr011.pdf
[SEI01]	Software Engineering Institute, Carnegie Mellon University: "Standard CMMI Appraisal Method for Process Improvement (SCAMPI) Version 1.1: Method Definition Document", 2001 http://www.sei.cmu.edu/pub/documents/01.reports/pdf/01hb001.pdf
[SEI06a]	Software Engineering Institute, Carnegie Mellon University: "A Standard CMMI Appraisal Method for Process Improvement (SCAMPI) Version 1.2: Method Definition Document", 2006. http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06hb002.pdf
[SEI06b]	Software Engineering Institute, Carnegie Mellon University: "Appraisal Requirements for CMMI, Version 1.2 (ARC, V1.2)", 2006. http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr011.pdf
[SEI07a]	Software Engineering Institute, University Carnegie-Mellon: "Capability Maturity Model® Integration (CMMI), Version 1.2 Overview", 2007. http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview07.pdf
[SEI07b]	Software Engineering Institute, Carnegie Mellon University: What is CMMI?, Septiembre 2007. http://www.sei.cmu.edu/cmmi/general/index.html
[Vil00]	Villate Blanco, José María: "Modelos de calidad en la industria. Situación y perspectivas de futuro en la CAPV", 2000. http://www.euskonews.com/0061zbk/gaia6103es.html

Glosario de Términos

Ambiente de integración: Son las
herramientas de soporte necesarias para acoplar las diferentes
componentes de un producto, puede incluir software y equipos
necesarios.

América XXI: Empresa chilena
focalizada al desarrollo y mantenimiento
de productos Software a medida. Esta empresa se encuentra
actualmente certificada por el modelo de calidad CMMI Nivel 3 y
además cuenta en su organización con dos especialistas y
certificadores del modelo de calidad CMMI que prestan servicios de
asesoría y certificación a diversas organizaciones,
entre ellas a ORDEN Integración.

Artefacto: Resultado útil de un proceso.
Puede incluir archivos,
documentos, productos, partes de un producto, servicios,
descripciones de proceso, especificaciones y facturas
[Chr06].

Casos de prueba: Conjunto de condiciones, las
cuales forman la base informativa para que el analista determine
si el requerimiento está satisfecho por el
Sistema.

Calidad: La capacidad de un conjunto de
características inherentes de un producto, de los
componentes del producto o de un proceso para satisfacer los
requerimientos impuestos por los
clientes
[Chr06].

Capacidad: Atributo de los procesos. El nivel de
capacidad de un proceso indica si sólo se ejecuta, o si
también se planifica se encuentra organizativa y
formalmente definido, se mide y se mejora de forma
sistemática [Pal06].

Conjunto de procesos estándares de la
organización: Es una colección de definiciones
de los procesos que guían actividades en una
organización. Estas descripciones de proceso cubren los
elementos fundamentales de proceso (y sus relaciones con otros)
que deben ser incorporados en los "procesos definidos" que son
implementados en proyectos [Chr06].

Commercial Off The Shelf (COTS): Corresponde a
objetos, componentes de productos o productos en sí que
pueden ser adquiridos desde un vendedor comercial
[Chr06].

Criterios de entrada: Estados de existencias que
deben estar presente antes de que un esfuerzo pueda empezar con
el éxito
[Chr06].

Criterios de salida: Estados de existencias que
deben estar presente antes de que un esfuerzo pueda terminar
exitosamente [Chr06].

Datos de prueba: Colección de datos que se
utilizarán en las pruebas del Sistema.

Disciplinas: Son las etapas, flujos de trabajo o
subprocesos del Proceso de Ingeniería de
Software. Cada disciplina contiene tareas a realizar, actores
involucrados, artefactos producidos y recursos utilizados.
Además son transversales a todas las fases del ciclo de
vida del proyecto.

Fases: Son la etapas por las que cualquier
desarrollo de proyecto de ORDEN integración debiera
transitar. Las fases son: Inicio,
Elaboración-Construcción y
Transición.

Guías de adaptación: Guías
organizacionales que permiten a proyectos, grupos, y funciones
organizacionales adaptarse apropiadamente a los procesos
estándares para sus usos. Las guías de
adaptación cubren la selección
de procesos estándares, la selección de un
apropiado modelo de ciclo de vida, y la adaptación de los
procesos estándares seleccionados y modelo del ciclo de
vida a las necesidades del proyecto. Guías de
adaptación describe que puede o no puede ser modificado e
identifica componentes del proceso que so n candidatos a ser
modificados [Chr06].

Implementación: Existe evidencia
suficiente de que un objetivo (específico) es alcanzado
mediante la definición de algún proceso, en este
caso se dice que el proceso implementa el objetivo
específico.

Institucionalización: Existe evidencia
suficiente de que un objetivo (específico) se encuentra
arraigado en la forma de hacer el negocio dentro de una
organización. Este forma de trabajar se hace
rutinariamente y es parte de la cultura
organizacional, en este caso se dice que el objetivo
específico se encuentra institucionalizado. Los objetivos
genéricos ayudan a institucionalizar los objetivos
específicos.

Integración ascendente: Se integran
incrementalmente las componentes, comenzando con las inferiores.
Las nuevas componentes se van probando. Se finaliza cuando se
alcance el producto final de software y su respectiva
prueba.

Integración Big-Bang: Es un tipo de
integración de componentes no incremental. Se combinan
todos los módulos y se prueba el programa.

Integración combinada: Tipo de
integración de componentes efectuada en forma incremental,
es decir se integra en forma controlada conjuntos,
previamente especificados, de componentes.

Integración descendente: Es una estrategia de
integración incremental a la construcción de la
estructura de
programas, en cual se integran los módulos
moviéndose en dirección hacia abajo por la
jerarquía de control comenzando con el módulo
principal (Programa principal). Los módulos subordinados
al módulo de control principal se incorpora en la
estructura, bien, de forma primero-en-profundidad, bien de forma
primero-en-anchura [Par07].

Madurez: Atributo de las organizaciones que
desarrollan o mantienen los sistemas de
software. En la medida que éstas llevan a cabo su trabajo
siguiendo procesos, y en la que éstos se encuentran
homogéneamente implantados, definidos con mayor o menor
rigor; conocidos y ejecutados por todos los equipos de la empresa; y
medidos y mejorados de forma constante, las organizaciones
serán más o menos "maduras" [Pal06].

Medidas: Medidas de un proceso indican el grado
de correctitud en que un proceso está siendo
ejecutado.

Modelo de calidad: son sistemas basados en
estudios experimentales de mejores prácticas que ayudan a
organización a implantar Sistema de Aseguramiento de la
calidad.

Nivel de capacidad: Grado que involucra la mejora
dentro de una individual área de proceso [Chr06], es decir
involucra la mejora de un conjunto de procesos relacionados al
área de proceso especificada.

Nivel de madurez: Grado que involucra un conjunto
predefinido de áreas de proceso, las cuales todos sus
objetivos son alcanzados [Chr06].

Organización: Es una estructura
administrativa en que la gente colectivamente maneja uno o
más proyectos que comparten un alto directivo y operan
bajo las mismas políticas. Organización puede ser
también aplicada a una persona quien
realiza una función en una pequeña
organización que podría ser realizada por un
grupo de gente
en una gran organización [Chr06].

Partes Interesadas: Ver Stakeholders

Partición Equivalente: Tipo de prueba de
caja negra. Divide las entradas de un programa en clases que
podrían llegar a derivan casos de prueba.

Proceso: Un conjunto de pasos que ayudan a
resolver un problema. Estos pasos deben estar definidos de manera
que no sean ambiguos, esto implica que puedan ser
fácilmente entendidos y capaces de ser seguidos de manera
consistente por cualquier persona que lo utilice. Además
un proceso debe tener sus entradas y salidas claras y bien
definidas.

Proceso de Desarrollo de Software: Proceso
definido por ORDEN Integración referido al proceso o
metodología de desarrollo de soluciones
software "a medida" para sus clientes.

Project Managment Organization (PMO): Área
ejecutiva de ORDEN Integración encargada de la
administración de los proyectos.

Pruebas de Aceptación: Pruebas realizadas
por el usuario quien comprueba en su ambiente de operación
el sistema entregado. Los puede aceptar o rechazar.

Pruebas de Análisis de Valor
Límite: Prueba que tiene por objetivo verificar la
ejecución de programa analizando los valores
límite de los tipos de datos
especificados. Para ello se debe probar con valores dentro
y fuera de los límites
especificados para el tipo de dato.

Pruebas de Caja Blanca: Los objetivos de este
tipo de pruebas es garantizar la ejecución por lo menos
una vez todos los caminos independientes de cada modulo, la
ejecución de todas las decisiones lógicas en sus
caminos verdadero y falso, la ejecución de todos los lazos
en sus limites, y la ejecución de las estructuras
internas de datos para asegurar su validez.

Pruebas Caja de Cristal: Prueban por lo menos una
vez todos los caminos en el control de cada componente y todas
las decisiones lógicas.

Pruebas de Caja Negra: Las pruebas de caja negra
se centran en los requerimientos funcionales. Permiten al
ingeniero del software obtener un conjunto de entradas que
prueben completamente los requerimientos funcionales de un
programa sin importar los detalles internos del programa, a fin
de verificar que el programa corra bien.

Pruebas de Caja de Pandora: Consiste en
abstenerse de realizar pruebas de depurar bastante bien un
proyecto; se deja al cliente que lo ensaye y acepte. El resultado
es una bomba de tiempo.

Pruebas de Comparación: Consiste en la
comparación de las salidas de las distintas versiones de
una misma componente o producto software.

Pruebas Funcionales: Buscan satisfacer los
requerimientos funcionales de las componentes del producto o
producto final.

Pruebas de Instalación: Pruebas que buscan
satisfacer los requerimientos de operación del
sistema.

Pruebas de Regresión: Las pruebas de
regresión consisten en a realizar pruebas ejecutadas
previamente, con el fin de asegurar de que los cambios hecho en
el código
no ha provocado efectos laterales no deseados.

Pruebas de Rendimiento: Buscan satisfacer los
requerimientos no funcionales asociados satisfacer requerimientos
de rendimiento del sistema (volumen de datos,
tasa de transacciones, etc.)

Pruebas de Seguridad: Buscan satisfacer los
requerimientos no funcionales referidos a mantener la integridad
del sistema ante cualquier amenaza definida que pueda llegar a
tener en su operación.

Prueba de Validación: el producto final se
prueba para definir si cumple los requerimientos funcionales y de
rendimiento, facilidad de mantenimiento, recuperación de
errores.

Requerimientos de operación:
Requerimientos provistos por el ambiente en el cual
operará el sistema.

Roles: Roles de un proceso se refiere al conjunto
de responsabilidades y funciones que deben ser realizadas por los
actores del proceso.

RUP (Rational Unified Process): Proceso de
desarrollo de software unificado. Provee un enfoque disciplinado
para asignar tareas y responsabilidades dentro de una
organización. El objetivo es asegurar productos software
de alta calidad que satisfagan las necesidades de los usuarios
finales, dentro de los tiempos y presupuestos
previstos [Rat03].

Stakeholders: Se refiere a una persona o un
conjunto de persona que son afectadas o responsables por las
actividades de un proyecto.

Trazabilidad: Una asociación distinguible
entre dos o más entidades lógicas, como
requerimientos, elementos del sistema, verificaciones,
tareas.

Unidad de Control de Calidad: Unidad de ORDEN
Integración encargada de controlar y asegurar la calidad
de los productos software producidos por la empresa y liberados a
los clientes

Work Breakdown Structure (WBS): El WBS es la
descomposición del proyecto en fases, etapas, subetapas,
hitos, hasta concluir con los entregables a producir al
término de cada hito. Es único para cada proyecto y
es preparado en forma general al principio del proyecto y se
detalla en la medida que el proyecto avanza en su
ejecución. El WBS se actualiza mensualmente y permite
reconocer contablemente el avance del proyecto a partir del valor
del costo de los artefactos producidos y aceptados como
terminados por el Jefe de Proyecto. Cada artefacto indicado en el
WBS debe ser presupuestado en términos del Esfuerzo
estimado para producirlo y el Costo a incurrir hasta su
término. Las cartas Gantt del
proyecto que periódicamente debe actualizar el jefe de
proyecto deben relacionar en forma explicita cada tarea con uno
de los entregables declarados en el WBS. De esta manera, cuando
la tarea sea finalizada, se podrá comparar los valores de
esfuerzo presupuestado en el WBS con los valores reales
informados por los responsables de producir el
artefacto.