Propuesta CMMI Nivel 2 Pymes Desarrollo Software

UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO
FACULTAD DE CIENCIAS DE LA COMPUTACION Y TELECOMUNICACIONES
UNIDAD DE POSTGRADO
DOCUMENTACION
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de
Pymes Desarrolladoras de Software
Por:
Eliana Mancilla Vargas
Heydi Barja Bravo
Betty Chaca Flores
Joshep Lujan Pardo
Patricia Juchani Roman
Dirigido por:
Ing. Karen Infanta Soto
Santa Cruz – Bolivia

2 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Propuesta para la Preparación
de la Certificación CMMI Nivel 2
de Pymes Desarrolladoras de
Software

3 | P á g i n a
Tabla de Contenido
1 Presentación De La Empresa ...................................................................................9
1.1 Misión................................................................................................................9
1.2 Visión ................................................................................................................9
1.3 Organigrama general de la empresa...............................................................9
1.4 Políticas de la Empresa ...................................................................................9
2 Descripción de roles ...............................................................................................10
3 Ciclo de vida del Proyecto......................................................................................11
3.1 Fases del ciclo de vida ..................................................................................12
3.1.1 Artefactos que se generan en cada fase del ciclo de vida.......................12
4 Áreas del Procesos del CMMI nivel 2....................................................................14
4.1 Gestión de Requerimientos...........................................................................14
4.1.1 Acta de Reunión de Requerimientos........................................................15
4.1.2 Lista de Requerimientos...............................................................................15
4.1.3 Especificación de requerimiento...................................................................19
4.1.4 Documento de validación de requerimientos...............................................19
Control de cambios.................................................................................................21
4.2 Planificación del Proyecto PP ....................................................................21
4.2.1 Definir Estrategia de desarrollo.....................................................................21
4.2.2 Elaborar plan de proyecto ............................................................................22
4.2.3 Presupuesto del Proyecto..........................................................................22
4.2.4 Calendario del Proyecto .............................................................................23
4.2.5 Identificar Riesgos del Proyecto .................................................................27
4.2.3 Elaborar plan de desarrollo.......................................................................28
4.2.4 Definir Responsables por área ..................................................................28
4.2.5 Informe de situación del proyecto .............................................................29
4.3 Monitoreo y Control de proyecto PMC ......................................................29
4.3.1. Responsables.................................................................................................29
4.3.3. Registro de actividades..............................................................................30
4.3.4. Evaluación y ajuste del plan de proyecto ...................................................33
4.4 Gestión de Proveedores......................................................................................33
4.4.1 Planifica y Elaborar Adquisición ..................................................................33
Propuesta para la Preparación de la Certificación
CMMI Nivel 2 de Pymes Desarrolladoras de Software

4 | P á g i n a
4.4.2 Seleccionar Proveedor...................................................................................35
4.4.4 Contratar Proveedores ...............................................................................35
4.4.5 Realizar Control y Seguimiento..................................................................36
4.4.6 Aceptar Producto Adquirido.........................................................................37
4.4.7 Documentos de aceptación o rechazo de productos o servicios ..........37
4.5 Gestión de la Configuración..........................................................................38
4.5.1 Plan de Gestión de la Configuración del Software .....................................38
4.5.2 Definiciones, Acronimos y Abreviaturas .....................................................38
4.5.3 Roles ...............................................................................................................39
4.5.4 Guia de Proceso en la Gestion de Configuracion ........................................39
4.5.4.1 Entradas ...................................................................................................39
4.5.4.2 Proceso.....................................................................................................40
4.5.5 Planeacion...................................................................................................40
4.5.5.1 Proposito..................................................................................................40
4.5.6 Responsables..............................................................................................40
4.5.6.1 Entradas ...................................................................................................40
4.5.6.2 Actividades ..............................................................................................41
4.5.2.3 Salidas ......................................................................................................41
4.5.3 Identificar Elementos de la Configuración ...................................................41
4.5.3.1 Propósito ..................................................................................................41
4.5.3.2 Responsables..........................................................................................41
4.5.3.3 Criterio de Entrada...................................................................................41
4.5.3.4 Entradas .................................................................................................42
4.5.3.5 Actividades..............................................................................................42
4.5.3.6 Salidas ......................................................................................................42
4.5.7 Establecer un Sistema de Administración de Configuración..................42
4.5.7.1 Propósito...............................................................................................42
4.5.7.2 Responsables .......................................................................................42
4.5.7.3 Criterio de Entrada ...............................................................................43
4.5.7.4 Entradas................................................................................................43
4.5.7.5 Actividades ...........................................................................................43

5 | P á g i n a
4.5.7.6 Salidas...................................................................................................44
4.5.8 Crear o Liberar las líneas Bases................................................................44
4.5.8.1 Propósito...............................................................................................44
4.5.8.1.1 Responsables .....................................................................................44
4.5.8.1.2 Criterios de entrada ............................................................................44
4.5.8.1.3 Entradas ..............................................................................................44
4.5.8.2 Actividades ...........................................................................................44
4.5.8.3 . Salidas.................................................................................................45
4.5.9 Seguir las peticiones de Cambios..........................................................45
4.5.9.1.1 Propósito.............................................................................................45
4.5.9.1.2 Responsables .....................................................................................45
4.5.9.1.3 Criterios de entrada ............................................................................45
4.5.9.1.4 Entradas ..............................................................................................45
4.5.9.1.5 Actividades..........................................................................................45
4.5.9.2 Salidas...................................................................................................46
4.5.10 Realizar Auditorías de Configuración .................................................46
4.5.10.1.1 Propósitos.........................................................................................46
4.5.10.2 Responsables ......................................................................................46
4.5.10.3 Criterios de entrada.............................................................................46
4.5.10.4 Entradas ...............................................................................................47
4.5.10.5 Actividades ..........................................................................................47
4.5.10.6 Salidas..................................................................................................47
4.5.11 Verificaciones .......................................................................................47
4.5.11.1 Propósito..............................................................................................47
4.5.11.2 Responsable ........................................................................................47
4.5.11.3 Criterios de entrada.............................................................................47
4.5.11.4 Entradas ...............................................................................................47
4.5.11.5 Actividades ..........................................................................................47

6 | P á g i n a
4.5.11.6 Salidas..................................................................................................48
4.5.11.7 Métricas................................................................................................48
4.6 Plan de aseguramiento de la calidad............................................................48
4.6.2. Proceso...........................................................................................................49
4.6.2.1. Proporcionar una Visión Objetiva.................................................................49
4.6.2.2. Planificación de Proceso...............................................................................49
4.6.2.2.1. Criterio de Entrada ..................................................................................49
4.6.2.2.2. Recursos ..................................................................................................49
4.6.2.2.3. Responsables ..........................................................................................50
4.6.2.2.4. Practicas...................................................................................................50
4.6.2.2.5. Verificación ..............................................................................................51
4.6.2.2.6. Métricas....................................................................................................51
6 Madurez del Proceso de Software..........................................................................51
6.1 Scampin..........................................................................................................51
6.2 Radar...............................................................................................................57
7 Caso de estudio.......................................................................................................57
7.1 Titulo del Proyecto...............................................................................................57
7.1.1 Introducción....................................................................................................58
7.1.2 Objetivo Especifico ........................................................................................58
7.1.3 Objetivo General.............................................................................................58
7.2 Definición de Requerimientos..............................................................................59
7.2.1 Identificación de actores de Caso de Uso ..................................................59
7.2.2 Detalle de caso de uso.................................................................................60
7.2.3 Modelo Físico de la base de datos................................................................61
7.3 Implementación...................................................................................................61
7.3.1 Estándar de Codificación del Caso de Uso Gestionar Producto ................61
7.3.2 Postmorten..................................................................................................65
7.3.3 Métricas en Cuanto a Defectos......................................................................65
7.3.4 Requerimientos no funcionales del sistema ................................................66
8 Conclusiones...........................................................................................................66
Anexos. ...........................................................................................................................67
Informe de avance del Proyecto.............................................................................67
Acta de la reunión del Equipo ................................................................................67
GC1. Lista de criterios para identificar los elementos de Configuración............81

7 | P á g i n a
GC. Lista de pasos para asignar los identificadores únicos los elementos de
Configuración..........................................................................................................83
GC3. Lista de criterios para identificar cada cuándo un elemento de
configuración se colocara bajo la administración de configuración. .................83
GC5.Lista de características a considerar para la Elección de una Herramienta
para el control de los elementos de configuración del software.........................85
GC6.Formulario para el registro de la Herramienta de Gestión de la
Configuración..........................................................................................................86
GC7. Proceso para obtener autorización de la tarjeta de control de
configuración (CCB) antes de crear o liberar líneas de base de los elementos de
configuración...........................................................................................................88
GC8. Plantilla para la solicitud de creación o liberación de un elemento de
configuración del software.....................................................................................89
Solicitud de elementos de configuración del software ...............................................89
GC9. Plantilla para la Petición de Cambio.............................................................90
Petición de Cambio (RFC)..............................................................................................90
GC10. Proceso para la Petición de Cambio...........................................................91
GC13. Plantilla para la auditoría de Gestión de la Configuración........................94

8 | P á g i n a
Prefacio.
Este proyecto fue realizado durante el período que va desde el mes de julio. El desarrollo
del mismo surgió a partir de la investigación del modelo CMMI.
Somos una empresa de desarrollo de software y nuestra meta es lograr la satisfacción del
cliente ofreciendo un producto de calidad. Para lograr un producto de calidad debemos de
mejorar nuestros procesos ya que depende de ello nuestro éxito.
CMMI nos ayuda a identificar las mejores prácticas para cada proceso definido en nuestra
empresa. En transcurso de este documento iremos detallando cada proceso y sus prácticas
de tal forma que nos permitirá acreditarnos como una empresa madura en base a sus
procesos.

9 | P á g i n a
1 PRESENTACIÓN DE LA EMPRESA
1.1 Misión
Satisfacer las necesidades de nuestros clientes en Desarrollo de Software
con los mayores niveles de calidad, confiabilidad, rapidez con un equipo de
trabajo motivado y capacitado.
1.2 Visión
Convertirnos en un referente dentro del mercado Boliviano en el desarrollo de
Software para la industria de Software.
1.3 Organigramageneral dela empresa
1.4 PolíticasdelaEmpresa
La norma ISO 9004:2000 establece que las políticas de calidad son
competencia directa de la gerencia de la empresa.
Santa Cruz Software Developers aplica las siguientes normas de calidad:
 Producir un producto de calidad que satisfaga, y si es posible supere
las expectativas del cliente.
 Proporcionar nuestros servicios acordes en calidad y precio.
 Trabajar en la mejora continua de nuestros procesos, procurando que
resulten más efectivos y eficientes
 Proporcionar a los empleados toda la información relevante y el
entrenamiento y formación apropiada en relación con la calidad.

10 | P á g i n a
 Facilitar a los empleados el desarrollo de sus habilidades y
conocimientos, para beneficio tanto de los empleados, como de la
propia empresa.
 Mantener un sistema que satisfaga los requisitos de la norma ISO
9001 y facilite la realización de productos software de calidad.
 Proporcionar un entorno seguro a sus empleados.
 Establecer objetivos de calidad medibles.
 Esforzarse continuamente para mejorar el funcionamiento en relación
con la calidad.
Consideramos la calidad como una responsabilidad dentro de nuestras
áreas de trabajo, comprometidos con el estricto cumplimiento de las normas
de calidad establecidas.
2 DESCRIPCIÓN DE ROLES
Tabla de roles de acuerdo a las áreas de proceso establecidos en CMMI nivel 2
Área de
proceso Responsable
Roles
involucrados
Categoría y
Comentarios
Gestión de
Requerimientos
REQM
Ing. Eliana
Mancilla
Gestor de
requerimientos
Función
básicamente de
gestión a nivel de
proyecto que
involucra a cliente y
patrocinador de
proyecto
Plan del
proyecto
PP
Ing. Eliana
Mancilla
Gestor de
planificación
Función desarrollar
el plan del proyecto,
estimar esfuerzo y
costo y lograr
compromiso con el
plan.
Monitoreo y
Control de
proyecto
PMC
Ing. Joshep
Lujan
Líder o jefe de
proyecto
Supervisa y hace
seguimiento

11 | P á g i n a
Gestión de
Proveedores
SAM
Ing. Betty
Chaca
Área de
compras o
adquisiciones
Actividades de
gestión de proyectos
que según la
estructura de la
organización se
gestiona por el
mismo proyecto o
existe un área de
adquisición que
ejecuta la mayoría de
las actividades
Gestión de
Aseguramiento
de la Calidad
PPQA
Ing. Heydi
Barja
Personal de
aseguramiento
de calidad
Función de apoyo a
proyectos
establecidos en
SQA, Eje.: un
responsable de
realizar una revisión
objetiva del
cumplimiento del
proceso y los
productos de trabajo
Gestión de la
Configuración
CM
Ing. Patricia
Juchani
Responsable
de
configuración
Actividad de apoyo
que se puede llevar
por cada proyecto,
principalmente
cuando son
desarrollos
independientes.
Gestión de
desarrollo
Ing. Betty
Chaca
Gestor de
desarrollo
Actividad de
desarrollo de
software según
establecido en los
requerimientos y el
plan de proyecto.
3 CICLO DE VIDADEL PROYECTO
SC Software Developers utiliza el ciclo de vida AUP (Agile unified process). Este
describe de una manera simple y fácil de entender la forma de desarrollar
aplicaciones de software de negocio usando técnicas ágiles y conceptos que
aún se mantienen válidos en RUP. El AUP aplica técnicas ágiles incluyendo
Desarrollo Dirigido por Pruebas (test driven development - TDD), Modelado Ágil,

12 | P á g i n a
Gestión de Cambios Ágil, y Refactorización de Base de Datos para mejorar la
productividad.
3.1 Fasesdel ciclo de vida
 Incepción (Concepción): El objetivo de esta fase es obtener una
comprensión común cliente- equipo de desarrollo del alcance del
nuevo sistema y definir una o varias arquitecturas candidatas para
el mismo.
 Elaboración: El objetivo es que el equipo de desarrollo profundice en
la comprensión de los requisitos del sistema y en validar la
arquitectura.
 Construcción: Durante la fase de construcción el sistema es
desarrollado y probado al completo en el ambiente de desarrollo.
 Transición: el sistema se lleva a los entornos de preproducción
donde se somete a pruebas de validación y aceptación y finalmente
se despliega en los sistemas de producción.
3.1.1 Artefactos que se generan en cada fase del ciclo de vida
FASE ACTIVIDADES
ARTEFACTO QUE
SE GENERA
RESPONSABL
E
INICIO
Modelado
Modelo de Casos de
Uso del Negocio
Diagrama de casos
de uso
Gestor de
Requerimiento

13 | P á g i n a
s
Estimación de
costos y riesgos
Documento del
plan de proyecto
Gestor de
Requerimiento
s
Definición de
riesgos
Documento del
plan de proyecto
Gestor de
Requerimiento
s
Implementación
Prototipo de interfaz
de usuario
Documento
Gestión de
Requisitos
Gestor de
Requerimiento
s
Prueba
Revisión inicial
de modelos
Documento del
plan del proyecto
Gestor de
Requerimiento
s
Gestión del proyecto
Administre el riesgo Documento del
plan del proyecto
Gestor de
Requerimiento
s
Ambiente
Establecer el
ambiente de
capacitación
Documento de Plan
de Aseguramiento
de la calidad
Gestos de
aseguramient
o de la calidad
ELABORACION
Modelado
Modelo de Casos de
Uso
Documento
Gestión de
Requisitos
Gestor de
Requerimiento
s
Especificaciones de
Casos de Uso
Documento
Gestión de
Requisitos
Gestor de
Requerimiento
s
Prototipos de
Interfaces de
Usuario
Documento
Gestión de
Requisitos
Gestor de
Requerimiento
s
Modelo de Análisis /
Diseño
Documento
Gestión de
Requisitos
Gestor de
Requerimiento
s
Modelo de
Componentes
Documento
Gestión de
Requisitos
Gestor de
Requerimiento
s
Pruebas
Validar la
arquitectura
Documento del
plan del proyecto
Gestor de
Requerimiento
s

14 | P á g i n a
Manejo de riesgo Documento del
plan del proyecto
Gestor de
Requerimiento
s
Actualice su plan de
proyecto
Documento del
plan del proyecto
Gestor de
Requerimiento
s
Ambiente
Establecer el
ambiente de
capacitación
Documento de Plan
de Aseguramiento
de la calidad
Gestos de
aseguramient
o de la calidad
CONSTRUCCIÓN E
IMPLEMENTACIÓN
Implementación
Implementación/Cod
ificación
Documento del
plan de
configuración
Gestor de
configuración
Despliegue
Desplegar el script
de instalación
Documento del
Plan del Proyecto
Gestor de
Requerimiento
s
Desplegar
documentación
inicial
Documento del
Plan del Proyecto
Gestor de
Requerimiento
s
Manejo del riesgo Documento del
Plan del Proyecto
Gestor de
Requerimiento
s
Actualizar su plan de
proyecto
Documento del
Plan del Proyecto
Gestor de
Requerimiento
s
Ambiente
Establecer el
ambiente de
capacitación
Documento de Plan
de Aseguramiento
de la calidad
Gestor de
aseguramient
o de la calidad
4 ÁREASDEL PROCESOS DEL CMMI NIVEL 2
SC Software Developers va rumbo a la certificación CMMI nivel 2 para lo
cual está implantando procesos definidos en áreas claves que se
describirán a continuación.
4.1 Gestión de Requerimientos
El propósito del proceso de gestión de requerimientos es controlar la
documentación referente a los requerimientos del producto, los cambios
que ocurran y también identificar inconsistencias entre los

15 | P á g i n a
requerimientos y los productos (documentos y componentes de
software) del proyecto generados en cada fase del ciclo de desarrollo.
4.1.1 Acta de Reunión de Requerimientos
Se establecerán actas de requerimientos para obtener una comprensión de
los requerimientos y el compromiso sobre los requerimientos acordados.
Dicha información se registrara en un formulario Acta de reuniones, favor
remitirse al los anexos para ver el formulario.
4.1.2 Lista de Requerimientos
Enumerar todos los requerimientos establecidos en el compromiso de
requerimientos acordados. Este registro se lleva a cabo en los
siguientes formularios:

16 | P á g i n a

17 | P á g i n a

18 | P á g i n a
Finalmente:
LISTA DE REQUERMIENTOS
Empresa: No.
Cliente: Fecha:
Id Requisito Descripción

19 | P á g i n a
4.1.3 Especificación de requerimiento
Detallar y documentar cada uno de los requisitos siendo lo más
explícitos posibles, definir responsables y tiempo de desarrollo.
Esta información queda detallada en el siguiente formulario:
REGISTRO DE REQUERMIENTOS
Empresa:
No.
Cliente: Fecha:
Id Prioridad Estado Responsable Tiempo de
desarrollo
4.1.4 Documento de validación de requerimientos
Gestión de cambios de los requerimientos, Los cambios ocurren
conforme avanza el trabajo o incluso se derivan requerimientos
adicionales. Es por eso que es necesario gestionar estas acciones de
manera eficiente y eficaz. Analizar el impacto del cambio conociendo la
fuente del requerimiento y la razón del cambio debe estar documentado.
Mantener la trazabilidad bidireccional entre los requerimientos desde su
fuente hasta sus requerimientos derivados y la asignación a las
funciones, a las interfaces, a los objetos, a la gente, a los procesos y a
los productos.

20 | P á g i n a

21 | P á g i n a
Control de cambios
4.2 Planificación del Proyecto PP
El objetivo de este proceso es establecer y mantener planes que definan las
actividades a realizar en el proyecto, y en base a las mismas, establecer el
presupuesto y los cronogramas del proyecto.
4.2.1 Definir Estrategia de desarrollo
A continuación se desglosan las metas a conseguir con este proceso, y las
prácticas que se requieren para conseguir estas metas:

22 | P á g i n a
 Establecer estimaciones
 Desarrollar el plan del proyecto
 Obtener un compromiso para realizar el plan
4.2.2 Elaborar plan de proyecto
El plan de proyecto es un documento formal que se utilizará para manejar
y controlar la ejecución del proyecto. Este documento estará basado en
los requisitos del proyecto y en las estimaciones anteriores. Para
conseguir esta meta hay que:
 Establecer el presupuesto y calendario del proyecto.
 Identificar riesgos del proyecto.
 Definir plan para administrar recursos.
 Definir un plan para administrar los conocimientos y habilidades.
 Definir un plan para involucrar a los interesados.
4.2.3 Presupuesto del Proyecto
El presupuesto del proyecto se detalla a continuación:
RECURSOS CANTIDAD
COSTO
UNITARIO
%
DEPRECIACION
COSTO
UNITARIO
NETO
COSTO
TOTAL EN
($US)
MODALIDAD
ADQUIRIR
HARDWARE
COMPUTADORA 4 658 25 164.50 2,632.00 COMPRAR
IMPRESORA 1 60 25 15.00 60.00 COMPRAR
SOFTWARE
S.O. 4 199.9 50 99.95 0.00 FREE
NETBEANS 1 0 40 0.00 0.00 FREE
GESTOR DE BASE DE
DATOS 1 0 40 0.00 0.00 FREE
HERRAMIENTA CASE 1 200 30 60.00 200.00 COMPRAR
PERSONAL
GESTOR 1 800 0 0.00 800.00 CONTRATAR
ANALISTA 1 600 0 0.00 600.00 CONTRATAR
DISEÑADOR 1 600 0 0.00 600.00 CONTRATAR
GESTORES DE
PRUEBAS 2 500 0 0.00 1,000.00 CONTRATAR
DESARROLLADOR 4 400 0 0.00 1,600.00 CONTRATAR
INFRAESTRUCTURA

23 | P á g i n a
ENERGIA ELECTRICA 30 0 0.00 300.00 SERVICIOS
AGUA POTABLE 20 0 0.00 200.00 SERVICIOS
INTERNET 30 0 0.00 300.00 SERVICIOS
OTROS
MATERIAL DE
ESCRITORIO 50 25 12.50 50.00 COMPRAR
MATERIAL DE
LIMPIEZA 50 0 0.00 50.00 SERVICIOS
COSTO TOTAL MARGEN DE UTILIDAD 25% IMPUESTOS IVA
8,392.00 2,098.00 1,090.96 209.80
4.2.4 Calendario del Proyecto
A continuación se presenta un calendario de las principales tareas del
proyecto. Como se ha comentado, el proceso iterativo e incremental de
AUP (Proceso Unificado Ágil) está caracterizado por la realización en
paralelo de todas las disciplinas de desarrollo a lo largo del proyecto,
con lo cual la mayoría de los artefactos son generados muy
tempranamente en el proyecto pero van desarrollándose en mayor o
menor grado de acuerdo a la fase e iteración del proyecto Para este
proyecto se ha establecido el siguiente calendario. La fecha de
aprobación indica cuándo el artefacto en cuestión tiene un estado de
completitud suficiente para someterse a revisión y aprobación, pero esto
no quita la posibilidad de su posterior refinamiento y cambios.
Inicio
Disciplinas / Artefactos generados o modificados
durante las Fase de AUP
Comienzo Aprobación
Modelado
Modelo de Casos de Uso del Negocio Dia 1 Dia 1
Estimación de costos y riesgos Dia 1 Dia 1
Definición de riesgos Dia 1 Dia 2
Implementación

24 | P á g i n a
Prototipo de interfaz de usuario Dia 2 Dia 2
Prueba
Revisión inicial de modelos Dia 2 Dia 2
Inicia la creación del equipo Dia 3 Dia 3
Administre el riesgo Dia 3 Dia 3
Ambiente
Establecer el entorno de trabajo Dia 3 siguiente iteración / fase
Elaboración
Modelado
Modelo de Casos de Uso Dia 1 Dia 1
Especificaciones de Casos de Uso Dia 1 Dia 1
Prototipos de Interfaces de Usuario Dia 2 Dia 2
Modelo de Análisis / Diseño Dia 3 Dia 3
Implementación
Modelo de Componentes Dia 4 Dia 4
Pruebas
Validar la arquitectura Dia 4 Dia 4
Maneje el riego Dia 5 Dia 5
Actualice su plan de proyecto Dia 5 Dia 5
Ambiente
Ajuste los materiales de procesos Dia 5 siguiente iteración / fase

25 | P á g i n a
Construcción
Modelado
Abordaje del Análisis del Modelado Dia 1 Dia 1
Implementación
Implementación/Codificación Dia 1 Dia 2
Primeras pruebas Dia 1 Dia 2
Pruebas
Pruebas de software Dia 3 Dia 3
Despliegue
Desplegar el script de instalación Dia 3 Dia 3
Desplegar documentación inicial
Manejo del riesgo Dia 3 Dia 3
Actualizar su plan de proyecto Dia 3 Dia 3
Ambiente
Establecer el ambiente de capacitación Dia 3 siguiente iteración / fase
Transición
Modelado
Finalice la documentación general del
sistema.
Dia 1 Dia 1
Implementación
Corrija defectos Dia 1 Dia 1

26 | P á g i n a
Pruebas
Valide el sistema Dia 1 Dia 1
Valide la documentación Dia 2 Dia 3
Finalice su modelo de pruebas Dia 3 Dia 3
Despliegue
Finalice el paquete de entrega o liberación. Dia 4 Dia 4
Capacite el personal Dia 5 Dia 5
Libere el sistema en producción. Dia 5 Dia 5
Material de Apoyo al Usuario Final Semana 2 Semana 2
Manual de Instalación Semana 2 Semana 2
Ambiente
Establezca las operaciones y / o el ambiente
de soporte
Semana 2
siguiente iteración /
fase
Para este proyecto se ha establecido el siguiente calendario. La fecha
de aprobación indica cuándo el artefacto en cuestión tiene un estado
de completitud suficiente para someterse a revisión y aprobación,
pero esto no quita la posibilidad de su posterior refinamiento y
cambios.
durante la Fase de Inicio
Documento de visión general
Inicio fase de
inicio
Fin fase de
inicio
Modelo de casos de uso / requerimientos
funcionales
Inicio fase de
elaboración
fin fase de
elaboración
Software con descripción del reléase actual Inicio
iteración de
fin iteración
de

27 | P á g i n a
construcción construcción
Pruebas de Aceptación
Inicio fase de
transición
Fin fase de
transición
4.2.5 Identificar Riesgos del Proyecto
A partir de la fase de Inicio se mantendrá una lista de riesgos asociados
al proyecto y de las acciones establecidas como estrategia para
mitigarlos o acciones de contingencia. Esta lista será evaluada al menos
una vez en cada iteración.
Riesgo Tipo Descripción
Rotación del
personal
Proyecto Personal con experiencia abandona el
proyecto antes de que finalice.
Cambio de
gestión
Proyecto Habrá un cambio de gestión
organizacional con diferentes prioridades.
No
disponibilidad
de hardware
Proyecto El hardware esencial para el proyecto no
será entregado a tiempo.
Cambio de
requerimientos
Proyecto
y
producto
Habrá un cambio en el requerimiento de lo
esperado.
Retrasos en la
especificación
Proyecto
y
producto
Las especificaciones de las interfaces
esenciales no estarán a tiempo.
Subestimación
del tamaño
Proyecto
y
producto
El tamaño del proyecto se ha subestimado.
Bajo
rendimiento de
la herramienta
case
Producto Las herramientas case estimados en el
proyecto no tienen el rendimiento
esperado.
Cambio de
tecnología
Negocio Un producto competitivo se pone en venta
antes de que sistema se complete.
Competencia
del producto
Negocio La tecnología fundamental sobre la que se
construirá el sistema se sustituye por una
nueva.

28 | P á g i n a
Formulario de roles para responsables de riesgos
4.2.3 Elaborar plan de desarrollo
Este documento esta detallado en el apartado ANEXOS.
4.2.4 Definir Responsables por área
La autoridad y responsabilidad de la ejecución del proceso y de establecer
los roles estará a cargo del gestor del proyecto
Para la definición de responsabilidades se utilizará el formato RACI-V, que
consiste en utilizar una de las 5 siglas (R, A, C, I o V) en función de:
R: Responsible (Responsable). Encargado de ejecutar o de que se
ejecute la tarea.
A: Accountable (Aprobador). Responsable de aprobar y cerrar una
tarea.
C: Consult (Consultado). Persona a la que se debe consultar y que
debe proporcionar información necesaria para la ejecución de la
tarea.
I: Inform (Informado). Persona a la que se debe informar del resultado
o de la completitud de la ejecución de la tarea.

29 | P á g i n a
V: Verify (Verificador). Persona que debe validar o verificar la
ejecución de una tarea (normalmente sus productos) generalmente
como paso previo a la aprobación formal por parte del aprobador.
Personas
Actividades
Joshep Lujan Eliana
Mancilla
Heydi Barja Patricia
Juchani
Betty
Chaca
Verificar cumplimiento de
actividades
R V
Desarrollo del plan del
proyecto
C R V I
Actividades de
Aseguramiento de calidad
C A R I
Administración de la
configuración.
C A V R
Requerimientos, análisis,
diseño, codificación,
testing, y documentación, e
informes técnicos.
C A V I R
4.2.5 Informe de situación del proyecto
Se realizaran reportes para indicar el estado actual del proyecto. Esta
información quedara registrada en el formulario informe de avance. Favor
remitirse a los anexos para verificar formulario.
4.3 Monitoreo yControl deproyecto PMC
El propósito del monitoreo y control del proyecto es proporcionar una
comprensión del avance del proyecto para que se puedan tomar las
acciones correctivas apropiadas, cuando el rendimiento del proyecto se
desvíe significativamente del plan.
Un plan de proyecto documentado es la base para el monitoreo de las
actividades, la comunicación del estado del proyecto y la ejecución de
acciones correctivas. El avance se determina principalmente comparando
los atributos de los productos de trabajo y de las tareas, el esfuerzo, el
coste y el calendario reales, con el plan en los hitos establecidos dentro del
calendario del proyecto o de la estructura de descomposición del trabajo. El
conocimiento apropiado del avance del proyecto permite que las acciones
correctivas sean llevadas a cabo de manera oportuna cuando el avance se
desvía significativamente del plan. Una desviación es significativa, sí,
cuando se deja sin resolver, impide al proyecto cumplir sus objetivos.
4.3.1. Responsables
 Administrador del proyecto
 Equipo de revisiones

30 | P á g i n a
 Administrador de la configuración
4.3.2. Entradas
 Plan del proyecto.
 Plantilla de monitoreo y control del proyecto
 Calendario del proyecto.
 Lista de compromisos identificados en el plan del proyecto.
 Plantilla de monitoreo y control de compromisos.
 Plan de administración de riesgos.
 Plantilla de monitoreo y control de riesgos.
 Plantilla de monitoreo y control de los datos.
 Lista de stakeholders que tendrán participación dentro del proyecto.
 Plantilla de monitoreo y control de la participación de los
stakeholders.
 Plantilla de monitoreo y control del avance del proyecto.
 Plantilla de monitoreo y control de hitos.
 Plantilla de monitoreo y control de acciones correctivas
 Productos de trabajo
 Elementos de configuración
 Documentos de procesos que generen el producto de trabajo.
 Documentos de contratos o compromisos pertinentes.
4.3.3. Registro de actividades
Monitorear los valores reales de los parámetros de planificación del
proyecto frente al plan del proyecto.
Los parámetros de la planificación del proyecto constituyen indicadores
típicos del avance y del rendimiento del proyecto, e incluyen atributos de los
productos de trabajo y tareas, coste, esfuerzo y calendario. Los atributos de
los productos de trabajo y de las tareas incluyen elementos tales como
tamaño, complejidad, peso, forma, ajuste o función.

31 | P á g i n a
El monitoreo normalmente involucra la medición de los valores reales de los
parámetros de la planificación del proyecto, la comparación de los valores
reales con los estimados en el plan del proyecto, y la identificación de
desviaciones significativas. Registrar los valores reales de los parámetros
de planificación del proyecto incluye el registro de la información contextual
asociada que ayuda a comprender las medidas. En la segunda meta
específica y sus prácticas específicas de este área de proceso, se maneja un
análisis del impacto que tienen las desviaciones significativas para
determinar qué acciones correctivas tomar.
4.3.3.1 Comparar el avance actual del proyecto con el plan o calendario
del mismo.
El monitoreo del progreso del proyecto incluye lo siguiente:
 Establecer en el plan de proyecto fechas para medir el porcentaje
completado de hitos y actividades.
 Comparar el porcentaje actual de la realización de los hitos y
actividades con el calendario documentado en el plan de proyecto
según las fechas establecidas en el plan del proyecto.
 Identificar desviaciones significativas de las estimaciones
calendarizadas en el plan del proyecto. Las desviaciones
significativas serán aquellas que de no ser corregidas garanticen que
no se cumplirá con alguna fecha de entrega o finalización de actividad
o poder alcanzar un hito establecidos en el plan del proyecto.
4.3.3.2. Monitorear el costo del proyecto y el esfuerzo utilizado.
El monitoreo del costo y esfuerzo incluye lo siguiente:
 Establecer en el plan del proyecto las fechas en las cuales se medirá
el esfuerzo actual y el dinero usado en el personal asignado.
 Comparar el esfuerzo, los costes, el personal y la formación reales
con las estimaciones y el presupuesto documentados en el plan de
proyecto.
 Identificar las desviaciones significativas del presupuesto en el plan
de proyecto, es decir que se esté usando significativamente más o
menos capital de acuerdo a lo planeado.
4.3.3.3. Monitorear los atributos de los productos de trabajo y de las
tareas.
Para información sobre los atributos de los productos de trabajo y de las
tareas, consúltese el área de proceso de Planificación de proyecto.

32 | P á g i n a
El monitoreo de los atributos de los productos de trabajo y de las tareas
incluye:
 Establecer en el plan de proyecto las fechas en las cuales se medirán
los atributos reales de los productos de trabajo y de las tareas (y los
cambios a los atributos), tales como el tamaño o la complejidad.
 Comparar los atributos reales de los productos de trabajo y de las
tareas (y los cambios a los atributos) con las estimaciones
documentadas en el plan del proyecto.
 Identificar las desviaciones significativas de las estimaciones en el
plan del proyecto.
4.3.3.4. Monitorear los recursos proporcionados y los usados.
Para información sobre los recursos planificados, consúltese el área de
proceso de Planificación del proyecto.
Algunos ejemplos de recursos son:
 Instalaciones físicas.
 Computadoras, periféricos y software usados en el diseño,
fabricación, pruebas y operación.
 Redes
 Entornos de seguridad.
 Personal del proyecto
 Procesos.
4.3.3.5. Monitorear el conocimiento y las habilidades del personal del
proyecto.
Para información sobre la planificación del conocimiento y de las
habilidades necesarias para la ejecución del proyecto, consúltese el área de
proceso de Planificación de proyecto.
El monitoreo del conocimiento y de las habilidades del personal del
proyecto incluye:
 Periódicamente medir según lo establecido en el plan del proyecto la
adquisición del conocimiento y habilidades del personal del proyecto.
 Comparar según lo establecido en el plan del proyecto el
entrenamiento actual obtenido con el documentado en el plan de
proyecto.

33 | P á g i n a
 Identificar desviaciones significantes de las estimadas en el plan de
proyecto.
Todas las tareas mencionadas anteriormente serán documentadas en el
documento de monitoreo del proyecto.
Documentar las desviaciones significativas en los parámetros de la
planificación del proyecto.
4.3.4. Evaluación y ajuste del plan de proyecto
Determinar y documentar en la plantilla de monitoreo y control de acciones
correctivas las acciones apropiadas para corregir desviaciones obtenidas
de lo planeado con respecto a los resultados de las acciones correctivas.
Las lecciones aprendidas como resultado de realizar acciones correctivas
pueden ser entradas para el proceso de planeación y administración de
riesgos.
Una vez realizadas todas estas medidas y con las respectivas
autorizaciones se realizaran la actualización del plan de proyecto
corrigiendo todas las desviaciones y asumiendo e implementando todas las
acciones correctivas que se han determinado y aprobado durante este
proceso.
4.4 Gestión deProveedores
El presente documento ilustra el proceso a ser seguido con el objeto de
desarrollar y sostener las capacidades de la organización para seleccionar
proveedores calificados y manejarlos en forma eficiente, de manera tal de
cumplir con los objetivos planteados en el proyecto.
4.4.1 Planifica y Elaborar Adquisición
Propósito: En principio cubre la adquisición de productos o servicios que
serán entregados al cliente o que se requieren para su desarrollo. Elaborar
el pedido de tercerización, estableciendo los criterios de evaluación de los
productos, servicios y proveedores postulados.
Entradas: SRS, Criterio de evaluación del producto, Template de Pedido de
Cotización, Template de Matriz de Evaluación.
Salidas: Pedido de Cotización, Criterio de evaluación del producto, Matriz de
Evaluación | Actividad | Descripción |
Responsable

34 | P á g i n a
Elaborar Pedido de
Cotización
El PM analiza el proyecto, a partir de los
requerimientos especificados en el SRS, elabora el
Pedido de Cotización, especificando:
 Productos a entregar y servicios a prestar por el
proveedor.
 Requerimientos funcionales y técnicos del
producto o servicio a contratar.
 Criterios de Aceptación de los productos y
servicios.
 Obligaciones a cumplir por ambas partes.
 Mecanismos de control y seguimiento del
proveedor.
 Acción a tomar por incumplimientos en la
calidad de los productos y los plazos
establecidos (multas, cancelaciones).
 Condiciones de confidencialidad de
información.
 Propiedad intelectual de los productos o en su
defecto, la correspondiente autorización para
poder comercializar los mismos.
 Cuestiones formales de presentación (lugar,
fecha límite, formato, etc.).
 Requerimientos no técnicos (términos
contractuales, costos, tiempos, etc.).
Adjuntar
Documentación
Complementaria
El PM obtiene la documentación complementaria
necesaria para adjuntar al Pedido de Cotización. Esta
depende del motivo de la contratación, pero puede
contener entre otras: * SRS
 Normas y Estándares de Diseño y
Programación.
 Templates de documentación a ser presentada.
Completar Matriz
de Evaluación
El PM completa la Matriz de Evaluación, especificando
los criterios (o factores) sobre los cuales se basará la
evaluación de las propuestas, ponderando los mismos
según su importancia en el proyecto. Los factores que

35 | P á g i n a
siempre se evaluarán en una propuesta son: Precio y
Servicio Post-Venta o Mantenimiento, garantía y
fechas de entrega.
El PM de acuerdo a los documentos decide la alternativa más conveniente,
establece y documenta el criterio de evaluación del producto a adquirir.
4.4.2 Seleccionar Proveedor
Propósito: Refinar la evaluación de los proveedores y productos candidatos.
Elegir la solución y el proveedor definitivo (definir requerimientos de
personalización, si corresponde).
Entradas: Propuestas del Proveedores, Matriz de Evaluación
Salidas: SDP [Anexo de Proveedores] | Actividad | Descripción |
Responsable |
Seleccionar al
Proveedor
Cuando se termina la fecha de presentación de las
propuestas y han sido recibidas todas, se procede a
hacer la evaluación.
El PM analiza cada Propuesta de Proveedor a la que se
envió el Pedido de Cotización, y refina la evaluación
sobre los proveedores y/o productos candidatos.
Posteriormente, el PM refiere a la Matriz de Evaluación
para tomar la decisión de a quién contratar.
Completar SDP
con Información
de Proveedor
El PM completa el Anexo Proveedores del Plan de
Proyecto, donde se especifican los mecanismos de
control, los criterios de aceptación condiciones y
supuestos que enmarcarán la relación con el proveedor
durante todo le ciclo de vida del proyecto.
Acordar detalles
con Proveedor
El PM negocia con el Proveedor elegido, si es necesario,
cuestiones técnicas y no técnicas pendientes de
resolución antes de la firma del contrato (por ejemplo,
complementar información pendiente, ajustar
compromisos de fechas, costo del proyecto, cronograma
de pagos).
4.4.4 Contratar Proveedores
Propósito: Redactar y firmar el contrato entre ambas partes.
Entradas: Template de Contrato, Propuesta del Proveedor, SDP,
Cronograma, Lista de Riesgos

36 | P á g i n a
Salidas: SDP [Actualizado], Contrato [Firmado], Cronograma [Actualizado],
Lista de Riesgos [Actualizada] | Actividad | Descripción | Responsable |
Armar el
Contrato
El PM, si considera necesario, ajusta la propuesta del
proveedor plasmándolo en un contrato o documento que
sirva a tal efecto.
Revisar y
Aprobar el
Contrato
El PM revisa con la Gerencia y el Área Comercial dicho
documento antes de su aprobación. Pueden intervenir,
cuando se lo considere necesario, el Gerente General o
algún otro responsable de la contratación.
El Proveedor y la empresa aprueban el documento.
Ajustar
Artefactos de
Planificación
El PM ajusta el SDP (Roles y Responsabilidades del
Proveedor, Cronograma) y el Anexo Proveedores, si fuera
necesario.
El PM actualiza la Lista de Riesgos identificando aquellos
relacionados con la tercerización acordada.
4.4.5 Realizar Control y Seguimiento
Propósito: Realizar el control del progreso, los resultados y el desempeño
del proveedor. Controlar el cumplimiento de los compromisos acordados en
el Contrato, tomando las acciones preventivas y correctivas necesarias para
cumplir con los objetivos.
Entradas: SDP, Cronograma, Lista de Riesgos
Salidas: Cronograma [Actualizado], Lista de Riesgos [Actualizada] |
Actividad | Descripción | Responsable |
Organizar y Controlar
Actividades del
Proveedor
El PM organiza las actividades en conjunto a
realizar por el Proveedor y su equipo de proyecto.
El PM realiza periódicamente el control de las
actividades del proveedor, a través de las
siguientes actividades: * Control del cumplimiento
de las fechas e hitos definidos en el cronograma
del proyecto.
 Control del cumplimiento del contrato.
 Control del cumplimiento de las
condiciones de aceptación de los
productos entregados o servicios
brindados.
 Control de pedidos de modificaciones
solicitadas y pendientes de realización por

37 | P á g i n a
el proveedor.
Reportar
Incumplimientos
El PM informa a la Gerencia correspondiente los
incumplimientos incurridos por el proveedor, y le
solicita que tome las acciones pertinentes.
Identificar y Mitigar
Riesgos
El PM administra los riesgos relacionados con el
proveedor, detectando la aparición de nuevos
riesgos, evaluando los ya considerados y
tomando las acciones preventivas y correctivas
pertinentes.
PM
4.4.6 Aceptar Producto Adquirido
Propósito: Dar conformidad de los productos/servicios entregados y de la
participación del proveedor en el proyecto.
Entradas: Criterios de Aceptación
Salidas: Minuta de Aceptación del Cliente | Actividad | Descripción |
Responsable |
Verificar
Entrega del
Proveedor
Ante la entrega de un producto o subproducto
por parte del Proveedor, se realizan las
siguientes pruebas:
a) El Analista Funcional realiza las
revisiones de los artefactos asociados al
producto entregado.
b) El Tester realiza el testing del producto
entregado.
c) El PM realiza un testing de aceptación,
verificando que el producto cumpla con los
requerimientos solicitados y con las
condiciones de aceptación definidas.
PM /
Analista
Funcional /
Tester
Aprobación
del Cliente
En aquellos casos en que no agregara valor al
producto final a entregar al Cliente mediante la
modificación, agregado de software, o
integración del software provisto con otro, el
PM obtiene la conformidad del producto
recibido por parte del Cliente.
PM
4.4.7 Documentos de aceptación o rechazo de productos o servicios
El proceso de aseguramiento de la calidad de proceso y producto evaluará
objetivamente los procesos, los productos de trabajo y los servicios
ejecutados frente a las descripciones de proceso, los estándares y los

38 | P á g i n a
procedimientos aplicables. Identificar y documentar las inconformidades.
Proporcionar retroalimentación al equipo del proyecto y a los gerentes
sobre los resultados de las actividades de aseguramiento de la calidad.
Asegurar que sean tratadas las inconformidades.
4.5 Gestión delaConfiguración
El proceso de Gestión de la Configuración, controlara la integridad, que es
la corrección y completitud de todos los elementos de trabajo que sean el
resultado de alguno de los procesos de desarrollo del sistema, es decir cada
elemento que se encuentre bajo el resguardo de la gestión no solo se
encuentre ahí por simple mecanización, sino que se asegure que dicho
elemento cumple con lo establecido en los lineamientos de nombramiento,
así como permitir identificar que dicho elemento cumple con su objetivo
dentro del sistema (p. e. Un código fuente que se encuentre nombrado
adecuadamente y que realice lo que en su especificación dicta y que al
mismo tiempo se puede encontrar a partir de él al requisito del cual fue
origen).
Lo anterior con el objetivo de no solo tener un control adecuado de los
elementos, sino también un histórico de cambios y versiones en caso de
contingencias y errores de acoplamiento o de cualquier otra índole
4.5.1 Plan de Gestión de la Configuración del Software
Describimos todas las actividades de Gestión de Configuración y Cambios
que serán realizadas durante todo el ciclo de vida del proyecto. Brindando
planificaciones detalladas de las actividades, responsabilidades asignadas,
recursos necesarios que incluyen personal, herramientas y equipamiento.
El Plan de Gestión de Configuración contiene información que puede ser
cubierta a una mayor o menor magnitud por otros planes. Los enfoques
siguientes pueden ser usados para manejar esta potencial coincidencia:
 Hacer referencias al contenido relacionado que se encuentre en otro
plan.
 Proveer la visión general en otro plan, suministrar los detalles más
significativos en este plan y hacer referencias necesarias desde los
otros planes hacia este plan.
 Asegurar que las secciones de este artefacto cubran solamente las
áreas que no han sido cubiertas anteriormente en otro lugar.
4.5.2 Definiciones, Acronimos y Abreviaturas
Línea Base: Es una especificación o producto de trabajo que se ha revisado
formalmente y sobre los que se ha llegado a un acuerdo, es de la versión 0 y
que de ahí en adelante sirve como base para un desarrollo posterior y que

39 | P á g i n a
puede cambiarse solamente a través de procedimientos formales de control
de cambios.
Configuration Control Board o Junta de Control de Cambios: Es el conjunto
de personas que se encargan de analizar peticiones de cambio y las cuales
designan al gestor y a todos los involucrados dentro del proceso de gestión
de la configuración.
Cuestión: Una solicitud que alguien ha presentado al sistema de control de
cambio que describe un problema de software, una mejora solicitada, una
propuesta de cambio en los requisitos de un producto en fase de desarrollo,
o un nuevo proyecto que se propone.
Stakeholder: Persona que directa o indirectamente se ve afectada por el
sistema y que puede afectar el proyecto.
CCB: Configuration Control Board
CM: Control Management
GCS: Gestión de la Configuración del Software
ECS: Elementos de la Configuración de Software
4.5.3 Roles
 CCB.- Junta de Control de Cambios que decide aprobar o rechazar un
cambio y que designa los otros roles del proceso integrada por 2
personas del equipo.
 Originador de cambios.- Es aquella persona que haya realizado la
petición de cambio ante la CCB.
 Gestor de la Configuración de Software.- Es el encargo de mantener el
control de los ECS.
 Líder de Proyecto.- Es el encargado de administrar y controlar todo lo
referente al proyecto al cual es asignado.
4.5.4 Guia de Proceso en la Gestion de Configuracion
4.5.4.1 Entradas
Las entradas del proceso son las siguientes:
 Planes, calendarios, reportes y revisiones del Proyecto
 Especificaciones, requerimientos, diseño, código y documentación
del Proyecto

40 | P á g i n a
 Procesos del proyecto
4.5.4.2 Proceso
Para llevar a cabo este proceso se tienen los siguientes objetivos
Objetivo 1. Establecer líneas base.
Para cumplir este objetivo se tienen las siguientes prácticas:
 Identificar elementos de configuración.
 Establecer un sistema de administración de configuración.
 Crear o liberar las líneas base.
Hemos definido como línea base en nuestro proyecto la versión 0
Objetivo 2. Seguir y controlar los cambios.
Para cumplir este objetivo se tienen las siguientes prácticas:
 Seguir las peticiones de cambio.
 Controlar los elementos de configuración.
Nosotros para controlar los cambios utilizamos la herramienta ASSEMBLA
para la gestión de la configuración y el seguimiento de los requerimientos
apoyados con GIT.
Objetivo 3. Establecer la integridad.
 Para cumplir este objetivo se tienen las siguientes prácticas:
 Realizar auditorías de configuración.
Para cumplir la auditoria utilizamos los formularios y las plantillas que hemos
definido
4.5.5 Planeacion
4.5.5.1 Proposito
Realizar la planeación de cada una de las tareas que deben de realizarse
para llevar a cabo el proceso de gestión de la configuración.
4.5.6 Responsables
 Administrador del Proyecto
4.5.6.1 Entradas
 Tener un Sistema en desarrollo.

41 | P á g i n a
 Todos los involucrados en el desarrollo del sistema deben de
estar informados que la planeación del proceso será llevada a
cabo.
 Una agenda de trabajo.
 Un equipo de trabajo informado.
4.5.6.2 Actividades
 El administrador de proyectos, con base al conjunto de lineamientos
para la selección de la CCB, nombrara a las personas que formaran
parte de la misma. (Ver Apéndice A11).
 La nueva CCB, deberá asignar al gestor de la configuración.
 El gestor de la configuración deberá determinar el tiempo estimado
que le llevara identificar todos los elementos de Gestión con base a
un conjunto coherente de requisitos.
 Por otra parte la CCB deberá determinar el tiempo estimado que le
tomara
la selección del sistema de administración.
 Por último y con base al calendario del proyecto, el gestor en
conjunto con la CCB, deberán determinar los días para las auditorias
de la gestión
4.5.2.3 Salidas
 Una nueva CCB.
 Un Gestor de la configuración.
 Un Plan para la Gestión de la configuración.
4.5.3 Identificar Elementos de la Configuración
4.5.3.1 Propósito
Identificar los ECS, permitiendo tener un control de todos aquellos
productos de trabajo que deben de ser considerados como ECS dentro del
sistema.
4.5.3.2 Responsables
 Gestor de la Configuración de Software
4.5.3.3 Criterio de Entrada
 Tener un conjunto coherente de requisitos.

42 | P á g i n a
4.5.3.4 Entradas
 La EDT del sistema.
 El plan de Gestión de la Configuración
4.5.3.5 Actividades
 El gestor de la configuración de software seleccionará los elementos
de configuración y productos de trabajo que los componen sobre la
base de criterios documentados.(Ver Apéndice GC1)
 El gestor de la configuración de software asignará identificadores
únicos a los elementos de configuración.(Ver Apéndice GC2)
 El gestor de la configuración de software agregará los elementos a las
plantillas de registro de elementos de configuración(Ver Apéndice
GC4)
 El gestor de la configuración de software identificará el momento
adecuado cuando un elemento de configuración de software deberá
ser colocado bajo administración en base a los criterios
establecidos.(Ver Apéndice GC3)
 Al finalizar la practica el Gestor de la configuración deberá colocar los
tipos de ECS que haya identificado dentro del plan de Gestión de la
Configuración
4.5.3.6 Salidas
Tipos de ECS identificados. (Ver Apéndice GC4)
Plan de gestión de configuración Actualizando con los tipos de ECS
4.5.7 Establecer un Sistema de Administración de Configuración
4.5.7.1 Propósito
Permitir establecer un sistema en el cual serán colocados todos los ECS
con el propósito de ser un punto de acceso para el Gestor de la
Configuración del Software e interesados para poder liberar o ingresar un
ECS del sistema en desarrollo con el fin de ser modificado o utilizado.
 Gestor de la Configuración de Software.
 CCB.

43 | P á g i n a
4.5.7.3 Criterio de Entrada
 Tener un Sistema en desarrollo
4.5.7.4 Entradas
 Tipos de ECS identificados (Ver Apéndice GC4)
4.5.7.5 Actividades
 El gestor de la configuración de software definirá los puntos que deberá
cumplir la herramienta, identificando las características más
significativas para la empresa, por ejemplo, la capacidad de acceso
mediante web es una característica importante, decida si quiere
continuar almacenando los elementos de configuración en documentos
o prefiere almacenarlos en una base de datos.
 Así mismo el Gestor de la Configuración de Software deberá de
establecer la estructura de almacenamiento con la cual contara el
sistema. (Ver Apéndice GC12)
 El gestor de la configuración de software deberá listar de 10 a 15
factores que pueden influenciar en su decisión, incluyendo factores
subjetivos como adaptabilidad (en la empresa), eficiencia, y efectividad
de la interfaz de usuario. El costo debe ser un factor, pero evalué las
herramientas sin considerarlo en una primera instancia tome en
consideración los siguientes puntos (Ver apéndice GC5).
 El Gestor de la Configuración de Software distribuirá 100 puntos entre
los factores listados anteriormente, y asignará más puntos a los
factores más importantes.
 La CCB obtendrá información acerca de las herramientas con base en
opiniones en foros, revistas especializadas, páginas web, etc.
 La CCB obtendrá una versión de prueba para evaluar los factores
subjetivos.
 La CCB evaluará la herramienta en un proyecto real, y no sólo el
proyecto tutorial del producto.
 La CCB asignará las calificaciones pertinentes.
 El Gestor de la Configuración de Software tomará una decisión sobre la
elección de la herramienta y llenará el siguiente formulario. (Ver
Apéndice GC6).

44 | P á g i n a
 Por último el Gestor de la Configuración de Software deberá informar a
todos los involucrados en el proyecto sobre el sistema que ha sido
seleccionado para la gestión de la configuración.
4.5.7.6 Salidas
 Sistema de gestión de configuración con productos de trabajo
controlados. (Ver Apéndice GC6).
4.5.8 Crear o Liberar las líneas Bases
4.5.8.1 Propósito
Permitir el control de las líneas Base de los ECS que son utilizados dentro
del sistema, lo cual permitirá comprender el estado actual de cada uno de
los elementos, así como poder tener un control histórico de las líneas base
para su uso en caso de conflictos.
4.5.8.1.1 Responsables
 CCB
4.5.8.1.2 Criterios de entrada
 Haber seleccionado un sistema para la gestión de la
configuración.
estar informados sobre el sistema de gestión de la configuración.
4.5.8.1.3 Entradas
 ECS identificados. (Ver Apéndice A4)
 Sistema de gestión de configuración con productos de trabajo
controlados. (Ver Apéndice GC6).
4.5.8.2 Actividades
 Cualquier persona interesada en la creación o liberación de líneas
base debe obtener la autorización de la CCB, siguiendo el

45 | P á g i n a
procedimiento establecido y haciendo una petición a través del
formato correspondiente.(Ver Apéndice A7)(Ver Apéndice A8)
 Si la petición de liberación fue aprobada por el CCB, el Gestor de la
Configuración de Software deberá de liberar los elementos de línea
base que se le soliciten y deberá de registrar la salida de dichos
elementos de la línea base en el formato de historial de emisiones de
líneas base. (Ver Apéndice A13)
 El CCB informará qué el conjunto actual de líneas base esté
disponible a los interesados.
4.5.8.3. Salidas
Líneas base creadas o liberadas.
4.5.9 Seguir las peticiones de Cambios
4.5.9.1.1 Propósito
El seguimiento de las peticiones de cambio permite tener una idea del
impacto y del costo que tendrá un cambio solicitado hacía algún ECS,
además de conocer el historial de cambios que se han realizado sobre algún
ECS.
4.5.9.1.2 Responsables
 Gestor de la Configuración de Software.
 Evaluador.
 Modificador.
 Verificador.
4.5.9.1.3 Criterios de entrada
 Tener liberadas líneas base.
4.5.9.1.4 Entradas
 Solicitud de Cambio(Ver Apéndice A9)
4.5.9.1.5 Actividades
 El interesado en el cambio envía su solicitud de cambio a la CCB.
 El CCB asignará un evaluador para realizar el análisis de impacto
sobre la solicitud de cambio.
 El evaluador dará su resultado al CCB, esta última tomara la decisión
de aceptar o rechazar la petición.

46 | P á g i n a
 En caso de que la solicitud fuera aceptada, al CCB asignará un
modificador, el cual realizara el cambio solicitado.
 Con forme a lo especificado en la Práctica de Liberación de Líneas
Base, el modificador realizara la petición de los elementos de línea
base para su modificación.
 Una vez realizados los cambios, el CCB nombrara un verificador quien
realizara la inspección de las modificaciones del modificador,
mediante técnicas como pruebas de regresión y caminatas.
 Una vez terminada la inspección, el verificador dará su reporte a la
CCB.
 Con base al reporte del verificador, la CCB podrá optar por cancelar la
modificación y notificar al modificador los detalles encontrados
durante la verificación, así mismo si la CCB nota que el cambio es
más grande de lo previsto puede optar por cancelar la solicitud de
cambio, tras lo cual el originador de la misma deberá de ser
notificado sobre el estado de su solicitud.
 Después de que la CCB apruebe el cambio realizado con base al
reporte del verificador, el modificador deberá entregar los elementos
de línea base que le fueron liberados ya modificados y el Gestor de la
Configuración de Software deberá colocar en el formato de historial
de emisiones de líneas base, los datos de ingreso de dichos
elementos de nuevo al sistema de gestión de la configuración.
4.5.9.2 Salidas
Peticiones de Cambio. (Ver Apéndice A9)
Líneas Base Actualizadas si es que el cambio fue aprobado.
Actualización de los historiales de peticiones del sistema de
gestión de la configuración, si es que la petición procede.
4.5.10 Realizar Auditorías de Configuración
4.5.10.1.1 Propósitos
Permitir identificar que tan consistente es la información que se encuentra
en los historiales de la Gestión de la Configuración del Software, así como
mostrar en qué punto del tiempo se suscitaron las inconsistencias.
 Evaluador
4.5.10.3 Criterios de entrada
 Tener un Sistema en desarrollo

47 | P á g i n a
estar informados
4.5.10.4 Entradas
 Solicitud de auditoría(Ver Apéndice A12)
4.5.10.5 Actividades
 El gestor de la configuración de software realiza una petición para
realizar una auditoría sobre los ECS
 El evaluador evaluara la integridad de las líneas de base.
 El evaluador confirmara que la gestión de configuración de los
registros identifican correctamente los elementos de configuración,
revisa la estructura y la integridad de los ECS, esto a través de un
checklist.(Ver Apéndice A13)
 El evaluador se encargara de dar seguimiento a los puntos de acción
desde la auditoría al cierre.
4.5.10.6 Salidas
 Resultados de la auditoria de configuración. (Ver Apéndice A13)
4.5.11 Verificaciones
4.5.11.1 Propósito
Las verificaciones permitirán al Gestor de la Configuración de Software el
ver cuál es el estado actual de la gestión y detectar de manera pronta
cualquier inconsistencia o detalle sobre saliente durante el proceso.
4.5.11.2 Responsable
Gestor de la Configuración de Software.
4.5.11.3 Criterios de entrada
 Todos los involucrados en el desarrollo del sistema deben de estar
informados.
4.5.11.4 Entradas
Sistema de Gestión con elementos dentro de él.
4.5.11.5 Actividades
 El gestor deberá revisar los historiales generados hasta la fecha por
EGC.

48 | P á g i n a
 El gestor deberá identificar a los elementos que no sufrieron cambio
alguno hasta la fecha.
 El gestor deberá de realizar pruebas de acoplamiento y regresión de
los EGC que hayan tenido una incidencia de peticiones mayores a 2
durante un mes.
 El gestor deberá de colocar todas las observaciones encontradas en
el registro de Observaciones de Revisión. (Ver Apéndice GC14)
 Posterior a ello, el gestor deberá notificar a los responsables de los
EGC que se encuentren en estado corrupto, es decir que no son
consistentes con sus requisitos origen o que no realizan la función
que describen.
 Una vez hecho esto el Gestor notificara de esto a la CCB pidiendo la
autorización de regresar a la versión inmediata estable y consistente
de los EGC que se encuentren corruptos.
 Si el CCB acepta dicho cambio se llevara a cabo y se notificara a
todos aquellos que tengan en uso la versión del EGC corrupto que lo
actualicen a la versión actual mediante la práctica de liberación de
líneas base.
4.5.11.6 Salidas
 Reportes de verificación del gestor.
 Un sistema de gestión estable.
4.5.11.7 Métricas
 Número de Inconsistencias encontradas en auditorias por
EGS.
 Número de Solicitudes de liberación por EGS
4.6 Plandeaseguramientode lacalidad
El proceso de aseguramiento de la calidad de proceso y producto evaluará
objetivamente los procesos, los productos de trabajo y los servicios
ejecutados frente a las descripciones de proceso, los estándares y los
procedimientos aplicables. Identificar y documentar las inconformidades.
Proporcionar retroalimentación al equipo del proyecto y a los gerentes
sobre los resultados de las actividades de aseguramiento de la calidad.
Asegurar que sean tratadas las inconformidades.
Documentos que se analizan durante todo este proceso:
 Estándares de la organización: políticas de calidad, lineamientos
de la organización.

49 | P á g i n a
 Documentación producida a lo largo del proyecto tales como
documentación de requisitos, planes de pruebas etc.
 Productos generados a lo largo del proyecto.
 Plantillas que serán empleadas para las evaluaciones de éste
proceso.
4.6.1. Responsables
 Líder del proyecto.
 Encargado de PPQA.
 Cualquier participante del proyecto.
4.6.2. Proceso
4.6.2.1.ProporcionarunaVisión Objetiva
Para cumplir este objetivo se tienen las siguientes prácticas, éstas se
resumen a continuación:
 Comunicar y asegurar la resolución de las inconformidades.
 Establecer registros
4.6.2.2.Planificación deProceso
El propósito de la planificación es establecer el nivel de detalle que se
tendrá en la ejecución del aseguramiento de la calidad de procesos y
productos.
4.6.2.2.1. Criterio deEntrada
Se han identificado los estándares, procesos, herramientas y producto que
se van a evaluar a lo largo del desarrollo del proyecto.
4.6.2.2.2. Recursos
Los recursos para realizar el proceso serán:
 Las plantillas provistas por el encargado de PPQA para
evaluar los procesos y los productos.
 Los documentos tales como plantillas, estándares y guías
para realizar los procesos, productos o servicios que serán
evaluados.
 Material de oficina.

50 | P á g i n a
4.6.2.2.2.1. Responsables
La autoridad y responsabilidad de la ejecución del proceso estará a cargo
de:
 Ing. Heydi Anel Barja Bravo.
4.6.2.2.3. Practicas
Teniendo como criterio de documentación tales como los estándares, las
especificaciones de los procesos, los planes etc., y conforme se vaya
desarrollando el proyecto, Evaluar los procesos que se ejecuten al igual que
los productos que generen se llevarán a cabo las siguientes actividades:
 EVALUAR OBJETIVAMENTE LOS PROCESOS.
 Verificar que los procesos cumplen las condiciones
establecidas en el apéndice A1. Esto para asegurar que la
aplicación del proceso sigue los estándares y
documentaciones establecidas.
 Documentar las inconformidades y las acciones para
corregirlas llenando los campos descritos en el apéndice A2.
 De ser necesario modificar los documentos de la línea base
para corregir las posibles fuentes de inconformidades.
 EVALUAR OBJETIVAMENTE LOS PROCESOS DE TRABAJO Y LOS
SERVICIOS.
 Verificar que los productos o servicios cumplen las condiciones
establecidas en el apéndice A3. Esto es para asegurar que en la
generación del producto o servicio se siguieron los estándares,
guías, plantillas y demás documentación establecida, también
para asegurar que el producto cumple con las especificaciones
del cliente antes de llegar a sus manos.
 Documentar las inconformidades y las acciones para
corregirlas llenando los campos descritos en el apéndice A2.
 De ser necesario modificar los documentos de la línea base
para corregir las posibles fuentes de inconformidades
 COMUNICAR Y ASEGURAR LA RESOLUCION DE LAS
INCONFORMIDADES
 Debe contarse tanto con los reportes de inconformidades del
apéndice A2 como con las plantillas de seguimiento del
apéndice A4 para contar con un control y seguimiento de las
mismas.

51 | P á g i n a
 Resolver las inconformidades con los responsables
establecidos y en caso de no resolverlas escalar la
responsabilidad al siguiente en la jerarquía de mando.
 ESTABLECER REGISTROS.
 Se crean registros de las actividades de aseguramiento de la
calidad en los procesos o áreas y se lleva un seguimiento de su
estado mediante la plantilla de actividades de aseguramiento de
la calidad en el apéndice A5.
4.6.2.2.4. Verificación
 El grupo de aseguramiento de la calidad debe verificar que los
procedimientos, formatos y del proceso se llenan según las
instrucciones.
 Si algún elemento del proceso necesita modificarse ya sea para la
mejora o adaptación, esta modificación deberá especificarse en el
control de la versión del presente documento.
 Las verificaciones por parte de las inconformidades deben ser
revisadas por el administrador y cualquier miembro del equipo que se
vea involucrado con dicha inconformidad.
4.6.2.2.5. Métricas
Las siguientes métricas buscan la mejora del proceso, son las siguientes:
 Número de inconformidades detectadas por evaluación.
 Frecuencia de la evaluación de productos o procesos.
 Tiempo de resolución de la inconformidad
6 MADUREZ DEL PROCESODE SOFTWARE
6.1 Scampin
CMMI-2: PA1: - Gestión de requisitos
#
NA
#
? Valor
P
1
SP 1.1 Se consigue la comprensión de los requisitos 9,00 9
SP 1.2 Se obtiene un compromiso basado en los
requisitos 9,00 9
SP 1.3 Se gestionan las modificaciones de requisitos 8,00 8
SP 1.4 Se mantiene la trazabilidad bi-direccional de los
requisitos 8,00 8
SP 1.5 Se identifican las inconsistencias entre el trabajo
del proyecto y los requisitos 7,00 7

52 | P á g i n a
GP 2.1 (CO 1) La organización tiene establecida una
política 7,00 7
GP 2.2 (AB 1) Se planifica este proceso 8,00 8
GP 2.3 (AB 2) Se le proporcionan los recursos
adecuados 7,00 7
GP 2.4 (AB 3) Tiene asignadas las responsabilidades 8,00 8
GP 2.5 (AB 4) Las personas implicadas reciben
formación 8,00 8
GP 2.6 (DI 1) Se gestiona la configuración de los
elementos de este proceso 8,00 8
GP 2.7 (DI 2) Se identifica a los actores importantes para
el proceso 7,00 7
GP 2.8 (DI 3) Se monitoriza y controla el proceso 8,00 8
GP 2.9 (VE 1) Se evalúa objetivamente su cumplimiento 8,00 8
GP 2.10 (VE2) Se revisa el proceso con los directivos
responsables 8,00 8
GP 3.1 Está establecido como proceso definido de la
organización (*) 9,00 9
GP 3.2 Se obtiene información para su mejora (*) 9,00 9
Tot
al 7,87
CMMI-2 - PA2: Planificación de proyecto
#
NA
#
? Valor
P
1
SP 1.1 Se estima el alcance del proyecto (relación de
tareas) 9,00 9
SP 1.2 Se realizan estimaciones de los productos de
trabajo y atributos de las tareas 8,00 8
SP 1.3 Se define el ciclo de vida del proyecto (fases) 9,00 9
SP 1.4 Se realizan estimaciones de esfuerzo y coste 8,00 8
SP 2.1 Se establece el presupuesto y calendario del
proyecto 6,00 6
SP 2.2 Se identifican los riesgos del proyecto 7,00 7
SP 2.3 Se define un plan para administrar la información 7,00 7
SP 2.4 Se define un plan para administrar los recursos 8,00 8
SP 2.5 Se define un plan para administrar los recursos y
las habilidades 8,00 8
SP 2.6 Se define un plan para involucrar a los
interesados 9,00 9
SP 2.7 Se establece el plan general de proyecto 8,00 8
SP 3.1 Se revisan los planes que afectan al proyecto 6,00 6
SP 3.2 Se reconcilia el trabajo y el nivel de los recursos 8,00 8
SP 3.3 Se obtiene un compromiso de los implicados,
con el plan del proyecto 7,00 7
política 8,00 8
adecuados 7,00 7

53 | P á g i n a
formación 9,00 9
el proceso 7,00 7
responsables 7,00 7
Tot
al 7,79
CMMI-2 - PA3: Seguimiento y control del proyecto
#
NA
#
? Valor
P
1
SP 1.1 Hay parámetros en la planificación para el
seguimiento del proyecto 9,00 9
SP 1.2 Se realiza un seguimiento de las
responsabilidades 8,00 8
SP 1.3 Se realiza un seguimiento de los riesgos del
proyecto 6,00 6
SP 1.4 Se realiza un seguimiento de la gestión de la
información 7,00 7
SP 1.5 Se realiza un seguimiento de la implicación de
los actores 7,00 7
SP 1.6 Se realizan revisiones de seguimiento 6,00 6
SP 1.7 Se realizan revisiones de hitos 8,00 8
SP 2.1 Se analizan la casuística del proyecto 7,00 7
SP 2.2 Se toman acciones correctivas 9,00 9
SP 2.3 Se gestionan las acciones correctivas 8,00 8
política 7,00 7
adecuados 7,00 7
formación 8,00 8
el proceso 8,00 8
responsables 8,00 8
GP 3.1 Está establecido como proceso definido de la 7,00 7

54 | P á g i n a
organización (*)
Tot
al 7,70
CMMI-2 - PA4: Gestión de acuerdo con proveedores
#
NA
#
? Valor P1
SP 1.1 Se determina el tipo de adquisición 8,00 8
SP 1.2 Se realiza una selección de suministradores 7,00 7
SP 1.3 Se establece un acuerdo con el proveedor 8,00 8
SP 2.1 Se evalúan posibles productos estándar 8,00 8
SP 2.2 Se ejecuta el acuerdo con el proveedor 9,00 9
SP 2.3 Se realizan acciones de aceptación de los
productos adquiridos 9,00 9
SP 2.3 Se planifica la integración de los productos
adquiridos 8,00 8
política 8,00 8
adecuados 7,00 7
formación 9,00 9
el proceso 7,00 7
responsables 7,00 7
Tot
al 7,88
(*) No es necesario en el nivel 2 de madurez
CMMI-2 - PA6: Aseguramiento de la calidad de producto y
proceso
#
NA
#
?
Val
or P1
SP 1.1 Se evalúan objetivamente los procesos 9,00 9
SP 1.2 Se evalúan objetivamente los productos de
trabajo y los servicios 7,00 7
SP 2.1 Se comunican y se garantiza la resolución de las
no-conformidades 8,00 8
SP 2.2 Hay establecidos registros 8,00 8
política 7,00 7
GP 2.3 (AB 2) Se le proporcionan los recursos 8,00 8

55 | P á g i n a
adecuados
formación 8,00 8
el proceso 9,00 9
responsables 8,00 8
Tot
al 8,21
CMMI-2 - PA7: Gestión de la configuración
#
NA
#
?
Va
lor P1
SP 1.1 Se identifican los elementos de la configuración
9,0
0 9
SP 1.2 Hay establecido un sistema para gestionar la
configuración
8,0
0 8
SP 1.3 Se crean o ponen en marcha las líneas base
9,0
0 9
SP 2.1 Se trazan las peticiones de cambios
9,0
0 9
SP 2.2 Se controlan los elementos de la configuración
9,0
0 9
SP 3.1 Hay un registro mantenido para los elementos de
la configuración
9,0
0 9
SP 3.2 Se audita la integridad de las líneas base
9,0
0 9
política
8,0
0 8
GP 2.2 (AB 1) Se planifica este proceso
8,0
0 8
adecuados
8,0
0 8
GP 2.4 (AB 3) Tiene asignadas las responsabilidades
8,0
0 8
formación
7,0
0 7
elementos de este proceso
8,0
0 8
el proceso
9,0
0 9
GP 2.8 (DI 3) Se monitoriza y controla el proceso
9,0
0 9

56 | P á g i n a
GP 2.9 (VE 1) Se evalúa objetivamente su cumplimiento
8,0
0 8
responsables
8,0
0 8
organización (*)
7,0
0 7
GP 3.2 Se obtiene información para su mejora (*)
7,0
0 7
CMMI-2 - PA5: Medición y análisis
#
N
A
#
?
Val
or
P
1
SP 1.1 Se establecen los objetivos de la
medición
8,0
0 8
SP 1.2 Se especifican las métricas
8,0
0 8
SP 1.3 Se especifican los
procedimientos de obtención y registro
8,0
0 8
SP 1.4 Se especifican los
procedimientos de análisis
7,0
0 7
SP 2.1 Se obtienen datos de las
mediciones
7,0
0 7
SP 2.2 Se analizan los resultados de las
mediciones
6,0
0 6
SP 2.3 Se guardan los datos y los
resultados de las mediciones
6,0
0 6
SP 2.3 Se comunican los resultados
7,0
0 7
GP 2.1 (CO 1) La organización tiene
establecida una política
8,0
0 8
GP 2.2 (AB 1) Se planifica este proceso
6,0
0 6
GP 2.3 (AB 2) Se le proporcionan los
recursos adecuados
8,0
0 8
GP 2.4 (AB 3) Tiene asignadas las
responsabilidades
8,0
0 8
GP 2.5 (AB 4) Las personas implicadas
reciben formación
8,0
0 8
GP 2.6 (DI 1) Se gestiona la
configuración de los elementos de este
proceso
7,0
0 7
GP 2.7 (DI 2) Se identifica a los actores
importantes para el proceso
9,0
0 9
GP 2.8 (DI 3) Se monitoriza y controla el
proceso
8,0
0 8
GP 2.9 (VE 1) Se evalúa objetivamente
su cumplimiento
7,0
0 7
GP 2.10 (VE2) Se revisa el proceso con
los directivos responsables
7,0
0 7
Tot
al 8,41

57 | P á g i n a
GP 3.1 Está establecido como proceso
definido de la organización (*)
7,0
0 7
GP 3.2 Se obtiene información para su
mejora (*)
7,0
0 7
Total
7,3
9
(*) No es necesario en el nivel 2 de
madurez
6.2 Radar
Áreasdeproceso
Gestión de requisitos (REQM) 7,87
Planificación de proyecto (PP) 7,79
Seguimiento y control de proyecto (PMC) 7,70
Gestión de acuerdo con proveedores (SAM) 7,88
Medición y análisis (MA) 7,39
Aseguramiento de la calidad del producto y servicio (PPQA) 8,21
Gestión de la configuración (CM)
8,41
7 CASO DE ESTUDIO
El presente caso de estudio tiene como base el modelo PSP que está
siendo aplicado en el caso de uso GESTIONAR PRODUCTO.
7.1 Titulo del Proyecto
Sistema de gestión para la compra, venta e inventario de La Librería y
Papelería “LIBER”.

58 | P á g i n a
7.1.1 Introducción
En la actualidad la mayoría de las empresas, grandes y pequeñas,
cuentan con la ayuda de un Sistema Informático que les permite
manejar su información de una manera cómoda y eficiente, y así
aumentar su productividad pero también hay algunas empresas u
organizaciones que aun manejan parte o todos sus datos de forma
manual, lo cual le ocasiona una serie de contratiempos e incluso serios
problemas a la hora de procesar sus datos para obtener la información
requerida, tal es el caso de La Librería y Papelería “LIBER” la cual es
una empresa que se dedica a la compra, venta de material de escritorio y
material escolar, además de la fabricación y distribución de tableros
melamínicos, tableros de vidrio, pizarras acrílicas, ranuradas y de
corcho.
Por esta razón, el proyecto a desarrollar consistirá en automatizar y
gestionar las transacciones de comercialización de los productos, tener
una mejor organización de los mismos y un inventario actualizado.
7.1.2 Objetivo Especifico
Desarrollar un Sistema de Información para la compra, venta e inventario
de la Librería y Papelería “LIBER”.
7.1.3 Objetivo General
A continuación se detallan cada uno de los objetivos específicos:
 Recolectar la información necesaria para el desarrollo del
Sistema mediante entrevistas con los funcionarios de la
Librería.
 Observar en forma detallada todos los movimientos de la
empresa que nos interesen para la elaboración de este
proyecto.
 Modelar los requisitos del Sistema para obtener el modelo de
negocio de la empresa.
 Realizar un análisis de los requerimientos obtenidos en las
entrevistas para desarrollar modelos utilizando casos de uso.

59 | P á g i n a
 Realizar el diseño del Sistema, a través de un modelo
conceptual para obtener una base de datos apropiada.
 Implementar el producto, en un lenguaje de programación
adecuado a partir del diseño del Software.
 Diseñar las interfaces del Sistema de forma iterativa con la
ayuda de los usuarios finales, para obtener interfaces
sencillas y fáciles de manejar.
 Realizar las pruebas del Sistema con datos reales y ficticios
con la intención de descubrir algún error no detectado hasta
entonces y proceder a su respectiva corrección.
 Asignar privilegios y poner restricciones al sistema de
acuerdo al cargo que tenga el usuario.
7.2 Definición deRequerimientos
7.2.1 Identificación de actores de Caso de Uso
Administrador: Administra la librería, dirige a los empleados.
Administrador
Vendedor: Atiende al cliente y busca los productos que el cliente
requiera.
Vendedor
Cliente: informa al vendedor que artículos desea comprar.
Cliente

60 | P á g i n a
7.2.2 Detalle de caso de uso
Ilustración 1. CU Gestionar Producto
Nro. CU1
Descripción Gestionar Producto
Actores Administrador
Iniciador Administrador
PRE- Condición Ninguna
POST- Condición Ninguna
Curso Básico
Acciones del Actor Respuestas del Sistema
1.-Registrar
1.2.- Ingresar la descripción
del producto
1.3.- Seleccionar la marca
1.4.- Seleccionar la Unidad
de medida
1.5.- Seleccionar el grupo al
que pertenecerá el
producto
2.-Modificar
2.2.- Seleccionar el articulo a
modificar
2.3.- Realizar las
modificaciones respectivas
3.-Eliminar
3.2.-Seleccionar el articulo o
introducir solamente el código
3.4.-Confirmar Solicitud
1.1.- Generar el código para el
nuevo producto
1.6.- Guardar datos del Producto
2.1.- Obtener todos los
productos existentes
2.4- Registrar las
modificaciones
3.1.- Obtener todos los
productos existentes
3.3.- Obtener producto
3.5-Eliminar Producto

61 | P á g i n a
Prototipo Gestionar Producto
7.2.3 Modelo Físico de la base de datos
Producto
Id_Producto descripción precio_venta costo_promedio stock_minimo stock_actual
int string float float int int
Marca
Id_marca marca
int string
Medida
id_medida medida
int string
Categoría
id_categoria categoria
int string
7.3 Implementación
7.3.1 Estándar de Codificación del Caso de Uso Gestionar Producto
/*

62 | P á g i n a
* Clase que define gestión de marca de producto
* @author Betty Chaca
* @author Eliana Mancilla
* @version 1.0, 12/07/2013
* @since 1.4
*/
package Negocio; //Import all packege Negocio
import Datos.Conexion; //import class conection
import Datos.Marca; //import class Marca
import java.sql.ResultSet;
public class GestionarMarca {
prívate Conexión conex; // Crea una instancia a la clase conexión a la
base de datos
private Marca marca; // Crea una instancia a la clase marca
publicGestionarMarca() {
conex = new Conexion();
marca = new Marca();
}
/** Envia el código generado */
publicResultSetgenerarCodigo() {
return marca.generarCodigo();
}
/** Obtiene el identificador de esta unidad organizativa */
publicvoidsetDatos(intcodigo,String nombre) {
marca.setCodMarca(codigo);
marca.setMarca(nombre);
}
/** Agrega una marca a la base de datos **/

63 | P á g i n a
public void adicionar(intcodigo,String nombre) {
setDatos(codigo,nombre);
marca.Adicionar(marca);
}
/**Actualiza los datos a la tabla marca de la base de datos **/
public void actualizar(intcodigo,String nombre) {
setDatos(codigo,nombre);
marca.actualizar(marca);
}
/** Obtiene la marca del producto**/
public ResultSetObtenerMarca() {
return marca.obtenerMarca();
}
/** Obtiene el identificador de la marca de un producto*/
public int codigoMarca(String dato) {
return marca.codigoMarca(dato);
}
}
//********************class GestionarProducto *************************
public class GestionarProducto {
private Conexión conex; //Instancia a la clase conexión a la base de datos
prívate Producto prod; //Instancia a la clase producto a la base de datos
public GestionarProducto() {
conex = new Conexion(); // inicializacion de variables conex
prod = new Producto(); //inicializacion de variablr prod
}

64 | P á g i n a
/** Obtiene el código generado del producto */
public ResultSet generarCodigo() {
return prod.generarCodigo();
}
/** Envia los datos a la Clase Producto */
public void
setDatos(intcodigo,Stringnombre,intstock,intprecio_venta,intprecio_compra
, String ubicacion, intmarca) {
prod.setcodigo(codigo);
prod.setNombre(nombre);
prod.setStock(stock);
prod.setPrecioVenta(precio_venta);
prod.setPrecioCompra(precio_compra);
prod.setUbicacion(ubicacion);
prod.setCodMarca(marca);
}
/** Adiciona un producto a la base de datos*/
public void adicionar(intcodigo, String nombre, int stock, int precio_venta,
int precio_compra, String ubicacion, int marca) {
setDatos(codigo,nombre,stock,precio_venta,precio_compra,ubicacion,
marca);
prod.adicionar(prod);
}
/** Obtiene el producto del la tabla producto */
public ResultSet obtenerProducto() {
return prod.obtenerProducto();
}
}

65 | P á g i n a
7.3.2 Postmorten
7.3.3 Métricas en Cuanto a Defectos
Alumno : Betty
Chaca Flores Fecha:8/7
FEC
HA
ST
AR
T
STO
P
INTERR
UPCION
TIEMPO
DELTA
ACTIVIDAD COMENTARIO
08/07
/2013
17:
30
18:0
0 30 min Diseño
Diseño logico
de la base de
datos en
Postgres
08/07
/2013
18:
00
18:1
5
call
phone 15 min Charla informativa
Coordinacion
con el Gestor
de proyecto
08/07
/2013
18:
16
19:0
0 44min
investigacion modelo
Hibernate
Investigacion
para SQL
Server y
herramientas
de ayuda
08/07
/2013
19:
01
19:3
0 29min
Configuracion de
hibernate
Configuracion
y Creacion de
conexión SQL
08/07
/2013
19:
31
20:0
0 29min
Configuracion de
aplicación de modelo 3
capas
Creacion de
clases en
modelo 3
capas
08/07
/2013
20:
01
20:4
5 44min Creacion de los ABMs
implementacio
n de las
funciones
Insertar,
Modificar,Elim
inar,Actualizar
08/07
/2013
20:
46
21:1
0 24min Test
Test de
funciones
creadas
Insertar,
Modificar,Elim
inar,Actualizar
08/07
/2013
21:
11
22:0
0 49min Diseño Presentacion
Diseño de
formularios
Producto y
marca
08/07
/2013
22:
01
22:2
0 19min
Verificacion del
proyecto
Pruebas de la
funcionalidad
y integracion
del proyecto

66 | P á g i n a
7.3.4 Requerimientos no funcionales del sistema
 Gestor de base de datos Mysql
 ID de desarrollo JAVA 7.0 y Netbeans 7.2
8 CONCLUSIONES.
La presente documentación es una propuesta para certificación CMMI Nivel
2 de nuestra empresa SC software developers

67 | P á g i n a
ANEXOS.
Informe de avance del Proyecto
Acta de la reunión del Equipo
ACTA DE REUNIÓN
Comité o Grupo: Acta N°:

68 | P á g i n a
Citada por: Fecha:
Coordinador: Hora inicio: Fin:
Secretario: Lugar:
PARTICIPANTES
No. Nombre Cargo Teléfono
1
2
3
PUNTOS DE DISCUSION
1
2
3
DESARROLLO DE LA REUNIÓN
Observaciones.

69 | P á g i n a
CONCLUSIONES
Nº Tarea Responsable Periodo de
cumplimiento
Responsable
A1. Lista de criterios para distinguir proveedores de requerimientos.
Gestión de Requerimientos Lista de Criterios para distinguir proveedores de
Requerimientos.
Guía
Lo enlistado son los posibles proveedores de requerimientos con los cuales
podrán ser seleccionados y clasificados según la importancia de la información
que pudieren proporcional.
Es importante distinguir cual será la fuente de requisitos para evitar información
innecesaria.
La siguiente lista se usa de referencia para los criterios empleados para la
selección del originador de requerimientos para el proyecto.
Criterio Descripción
El cargo que tiene en la
empresa.
o Se tomará en cuenta el cargo o lugar que
ocupa el sujeto en la jerarquía de la empresa.
El conocimiento que
tiene sobre la
problemática
presentada.
Que tanto sabe el sujeto sobre el problema al que
se debe dar solución.
El tiempo que lleva en la
empresa
Mientras más tiempo lleve el sujeto en la
organización, mayor es su conocimiento acerca del
funcionamiento de la misma.
El grado en que
empleará el producto a
desarrollar
Si el sujeto es el que más empleará u operará el
producto entonces también es una fuente
importante de requerimientos.
Su trabajo no se verá
perjudicado por el
producto
Si lo que se desea es automatizar una función
llevada a cabo por uno o varios sujetos entonces
habrá cierta resistencia a ayudar en el desarrollo o
bien puede resultar perjudicial.

Propuesta CMMI Nivel 2 Pymes Desarrollo Software

Propuesta CMMI Nivel 2 Pymes Desarrollo Software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Propuesta CMMI Nivel 2 Pymes Desarrollo Software

Similar a Propuesta CMMI Nivel 2 Pymes Desarrollo Software (20)

Último

Último (20)

Propuesta CMMI Nivel 2 Pymes Desarrollo Software