Monografias.com > Uncategorized
Descargar Imprimir Comentar Ver trabajos relacionados

Modelo de calidad CMMI (página 5)



Partes: 1, 2, 3, 4, 5

Actividad: Determinar tipo de
requerimiento

Entradas: N. A.

Salidas: N.
A. 

Actores Involucrados: Jefe de
Proyecto

Descripción:

De esta decisión pueden surgir dos
alternativas:

1.- El requerimiento es un Cambio de
Requerimiento.

El requerimiento es una modificación,
corrección o simplemente la eliminación de un
requerimiento que pertenece a la Línea Base vigente
y aprobada.

2.- El requerimiento es un Requerimiento
Nuevo.

El requerimiento no ha sido analizado antes, por
lo tanto es necesario hacer su estudio
detallado.

           

Actividad: Ingresar
Información del Proyecto y del
requerimiento

Entradas: N. A.

Salidas: Registro de
Requerimientos. 

Actores Involucrados: Jefe de
Proyecto

Descripción:

La información de cada requerimiento
incluye:

Fecha: Fecha en que se realiza este
plan.

ID Proyecto: Identificación del
proyecto.

Nombre Proyecto: Nombre completo del
proyecto.

Responsable GR: Nombre de la persona responsable
de la Administración de los
Requerimientos.

Fase: Número de la fase del mismo proyecto.
Se genera un nuevo encabezado por cada fase del mismo
proyecto.

ID LB: Identificación de la Línea
Base vigente de la fase y el proyecto

Fecha inicio LB: Fecha planificada del comienzo de
esta fase, aprobada por CM. Si está en blanco
implica que aun  no está definida.

Fecha aprobación LB: Fecha de
aprobación de LB utilizada cuando hay cambio de LB
debido a Control de Cambios, si está en blanco
implica que aún no se ha modificado la Línea
Base inicial.

Se actualiza además el estado del
requerimiento como "Ingresado".

El Registro de Requerimientos se realiza en el
software Enterprise Architect[3].

 

Actividad: Completar o adaptar
requerimientos predefinidos según aplican al
proyecto

Entradas: Glosario y Ayuda.
2.7 Forma de llenado del Registro de
Requerimientos

Salidas: Registro de
Requerimientos

Actores Involucrados: Jefe de
Proyecto

Descripción:

En base a la forma de llenado de los
requerimientos en el Enterprise Architect se actualiza los
datos en el sistema, agregando a su vez mayor detalle a
cada uno, dependiendo del proyecto y del requerimiento en
sí.

 

           
Si existe un control de cambios en algún requerimiento se
activa esta actividad, que se modela en la Figura 14

Figura 14: Control de Cambios

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:

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

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

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

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

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

Figura 25: Preparar
Pruebas

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

7.     Estimar plazos
para ejecución de las pruebas, considerando
recursos disponibles para pruebas y estimaciones de
productividad individual

* Todos los anteriores documentos generados
formarán parte del Plan de Pruebas.

8.     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:

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

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

3.     Documentar
resultados en el Informe de Observaciones.

4.     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).

5.     Determinar
criticidad de las observaciones: defectos de forma,
defectos de fondo, factibilidad de continuar con otras
pruebas a pesar de los defectos detectados.

6.     Comunicar
resultados de las pruebas al proyecto

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

 

[1] Las
áreas de proceso que tienen "+IPPD" al lado derecho
contienen metas y prácticas adicionales relacionadas a
IPPD (Integrated Product and Process Development) –
Desarrollo de Procesos y Productos integrados).  Para ver
más información acerca de IPPD consultar
[Chr06].

[2]
Información obtenida de la página Web de la
organización: http://www.orden.cl

[3]
Enterprise Architect de Sparx Systems. Para consultar
información sobre la herramienta visite el sitio: http://www.sparxsystems.com/

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án comparar los valores
de esfuerzo presupuestado en el WBS con los valores reales
informados por los responsables de producir el
artefacto.

 

Nota sobre los Autores

Matías Fuentes Contreras

Estudiante de Ingeniería Civil Informática
de la Universidad de Concepción, Concepción,
Chile.

Pablo Teuber Henríquez

Estudiante de Ingeniería Civil Informática
de la Universidad de Concepción, Concepción,
Chile.

Fecha de Publicación:

26 de febrero de 2008

Trabajo realizado en la ciudad de Santiago de
Chile.

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