Download - Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de 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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 Organigrama general de la empresa
1.4 Políticas de la Empresa
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 VIDA DEL 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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Gestión de Cambios Ágil, y Refactorización de Base de Datos para mejorar la
productividad.
3.1 Fases del 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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 Requerimientos
Implementación
Prototipo de interfaz de usuario
Documento Gestión de Requisitos
Gestor de Requerimientos
Prueba
Revisión inicial de modelos
Documento del plan del proyecto
Gestor de Requerimientos
Gestión del proyecto
Administre el riesgo Documento del plan del proyecto
Gestor de Requerimientos
Ambiente
Establecer el ambiente de capacitación
Documento de Plan de Aseguramiento de la calidad
Gestos de aseguramiento de la calidad
ELABORACION
Modelado
Modelo de Casos de Uso
Documento Gestión de Requisitos
Gestor de Requerimientos
Especificaciones de Casos de Uso
Documento Gestión de Requisitos
Gestor de Requerimientos
Prototipos de Interfaces de Usuario
Documento Gestión de Requisitos
Gestor de Requerimientos
Modelo de Análisis / Diseño
Documento Gestión de Requisitos
Gestor de Requerimientos
Modelo de Componentes
Documento Gestión de Requisitos
Gestor de Requerimientos
Pruebas
Validar la arquitectura
Documento del plan del proyecto
Gestor de Requerimientos
Gestión del proyecto
14 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Manejo de riesgo Documento del plan del proyecto
Gestor de Requerimientos
Actualice su plan de proyecto
Documento del plan del proyecto
Gestor de Requerimientos
Ambiente
Establecer el ambiente de capacitación
Documento de Plan de Aseguramiento de la calidad
Gestos de aseguramiento de la calidad
CONSTRUCCIÓN E IMPLEMENTACIÓN
Implementación
Implementación/Codificació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 Requerimientos
Desplegar documentación inicial
Documento del Plan del Proyecto
Gestor de Requerimientos
Gestión del proyecto
Manejo del riesgo Documento del Plan del Proyecto
Gestor de Requerimientos
Actualizar su plan de proyecto
Documento del Plan del Proyecto
Gestor de Requerimientos
Ambiente
Establecer el ambiente de capacitación
Documento de Plan de Aseguramiento de la calidad
Gestor de aseguramiento de la calidad
4 ÁREAS DEL 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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
17 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
18 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Finalmente:
LISTA DE REQUERMIENTOS
Empresa: No.
Cliente: Fecha:
Id Requisito Descripción
19 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
21 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Prototipo de interfaz de usuario Dia 2 Dia 2
Prueba
Revisión inicial de modelos Dia 2 Dia 2
Gestión del proyecto
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
Disciplinas / Artefactos generados o modificados
durante las Fase de AUP Comienzo Aprobació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
Gestión del proyecto
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Construcción
Disciplinas / Artefactos generados o modificados
durante las Fase de AUP Comienzo Aprobació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
Gestión del proyecto
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
Disciplinas / Artefactos generados o modificados durante las Fase de AUP
Comienzo Aprobació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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Gestión del proyecto
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.
Disciplinas / Artefactos generados o modificados
durante la Fase de Inicio Comienzo Aprobación
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 y Control de proyecto 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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 de Proveedores
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 de la Configuració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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 Sistema en desarrollo.
Tener un conjunto coherente de requisitos.
42 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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.
4.5.7.2 Responsables
Gestor de la Configuración de Software.
CCB.
43 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Gestor de la Configuración de Software
CCB
4.5.8.1.2 Criterios de entrada
Tener un Sistema en desarrollo.
Haber seleccionado un sistema para la gestión de la
configuración.
Todos los involucrados en el desarrollo del sistema deben de
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 un Sistema en desarrollo.
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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.
4.5.10.2 Responsables
Gestor de la Configuración de Software
Evaluador
4.5.10.3 Criterios de entrada
Tener un Sistema en desarrollo
47 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Todos los involucrados en el desarrollo del sistema deben de
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
Tener un Sistema en desarrollo.
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 Plan de aseguramiento de la calidad
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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. Proporcionar una Visió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 de Proceso
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 de Entrada
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 PROCESO DE SOFTWARE
6.1 Scampin
CMMI-2: PA1: - Gestión de requisitos #
NA # ? Valor
P1
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Total 7,87
CMMI-2 - PA2: Planificación de proyecto #
NA # ? Valor
P1
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
GP 2.1 (CO 1) La organización tiene establecida una política
8,00 8
GP 2.2 (AB 1) Se planifica este proceso
9,00 9 GP 2.3 (AB 2) Se le proporcionan los recursos adecuados
7,00 7
GP 2.4 (AB 3) Tiene asignadas las responsabilidades
7,00 7
53 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
GP 2.5 (AB 4) Las personas implicadas reciben formación
9,00 9
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
9,00 9 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
7,00 7
GP 3.1 Está establecido como proceso definido de la organización (*)
7,00 7
GP 3.2 Se obtiene información para su mejora (*)
7,00 7
Total 7,79
CMMI-2 - PA3: Seguimiento y control del proyecto #
NA # ? Valor
P1
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 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
7,00 7 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
9,00 9
GP 2.7 (DI 2) Se identifica a los actores importantes para el proceso
8,00 8
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
9,00 9
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
7,00 7
54 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
organización (*) GP 3.2 Se obtiene información para su mejora (*)
6,00 6
Total 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
GP 2.1 (CO 1) La organización tiene establecida una política
8,00 8
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
9,00 9
GP 2.6 (DI 1) Se gestiona la configuración de los elementos de este proceso
7,00 7
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
7,00 7 GP 2.9 (VE 1) Se evalúa objetivamente su cumplimiento
9,00 9
GP 2.10 (VE2) Se revisa el proceso con los directivos responsables
7,00 7
GP 3.1 Está establecido como proceso definido de la organización (*)
7,00 7
GP 3.2 Se obtiene información para su mejora (*)
7,00 7
Total 7,88
(*) No es necesario en el nivel 2 de madurez CMMI-2 - PA6: Aseguramiento de la calidad de producto y
proceso #
NA # ?
Valor 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 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
8,00 8
55 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
adecuados 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
9,00 9
GP 2.7 (DI 2) Se identifica a los actores importantes para el proceso
9,00 9
GP 2.8 (DI 3) Se monitoriza y controla el proceso
9,00 9 GP 2.9 (VE 1) Se evalúa objetivamente su cumplimiento
9,00 9
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 (*)
7,00 7
GP 3.2 Se obtiene información para su mejora (*)
7,00 7
Total 8,21
CMMI-2 - PA7: Gestión de la configuración #
NA # ?
Valor P1
SP 1.1 Se identifican los elementos de la configuración
9,00 9
SP 1.2 Hay establecido un sistema para gestionar la configuración
8,00 8
SP 1.3 Se crean o ponen en marcha las líneas base
9,00 9
SP 2.1 Se trazan las peticiones de cambios
9,00 9
SP 2.2 Se controlan los elementos de la configuración
9,00 9
SP 3.1 Hay un registro mantenido para los elementos de la configuración
9,00 9
SP 3.2 Se audita la integridad de las líneas base
9,00 9
GP 2.1 (CO 1) La organización tiene establecida una política
8,00 8
GP 2.2 (AB 1) Se planifica este proceso
8,00 8
GP 2.3 (AB 2) Se le proporcionan los recursos adecuados
8,00 8
GP 2.4 (AB 3) Tiene asignadas las responsabilidades
8,00 8
GP 2.5 (AB 4) Las personas implicadas reciben formación
7,00 7
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
9,00 9
GP 2.8 (DI 3) Se monitoriza y controla el proceso
9,00 9
56 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 (*)
7,00 7
GP 3.2 Se obtiene información para su mejora (*)
7,00 7
CMMI-2 - PA5: Medición y análisis
# NA
# ?
Valor
P1
SP 1.1 Se establecen los objetivos de la medición
8,00 8
SP 1.2 Se especifican las métricas
8,00 8
SP 1.3 Se especifican los procedimientos de obtención y registro
8,00 8
SP 1.4 Se especifican los procedimientos de análisis
7,00 7
SP 2.1 Se obtienen datos de las mediciones
7,00 7
SP 2.2 Se analizan los resultados de las mediciones
6,00 6
SP 2.3 Se guardan los datos y los resultados de las mediciones
6,00 6
SP 2.3 Se comunican los resultados
7,00 7
GP 2.1 (CO 1) La organización tiene establecida una política
8,00 8
GP 2.2 (AB 1) Se planifica este proceso
6,00 6
GP 2.3 (AB 2) Se le proporcionan los recursos adecuados
8,00 8
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
7,00 7
GP 2.7 (DI 2) Se identifica a los actores importantes para el proceso
9,00 9
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
7,00 7
GP 2.10 (VE2) Se revisa el proceso con los directivos responsables
7,00 7
Total 8,41
57 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
GP 3.1 Está establecido como proceso definido de la organización (*)
7,00 7
GP 3.2 Se obtiene información para su mejora (*)
7,00 7
Total 7,39
(*) No es necesario en el nivel 2 de madurez
6.2 Radar
Áre
as d
e p
roceso
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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 de Requerimientos
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
* 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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
/** 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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
7.3.2 Postmorten
7.3.3 Métricas en Cuanto a Defectos
Alumno : Betty Chaca Flores Fecha:8/7
FECHA
START
STOP
INTERRUPCION
TIEMPO DELTA
ACTIVIDAD COMENTARIO
08/07/2013
17:30
18:00 30 min Diseño
Diseño logico de la base de
datos en Postgres
08/07/2013
18:00
18:15
call phone 15 min Charla informativa
Coordinacion con el Gestor de proyecto
08/07/2013
18:16
19:00 44min
investigacion modelo Hibernate
Investigacion para SQL Server y
herramientas de ayuda
08/07/2013
19:01
19:30 29min
Configuracion de hibernate
Configuracion y Creacion de conexión SQL
08/07/2013
19:31
20:00 29min
Configuracion de aplicación de modelo 3 capas
Creacion de clases en modelo 3
capas
08/07/2013
20:01
20:45 44min Creacion de los ABMs
implementacion de las
funciones Insertar,
Modificar,Eliminar,Actualizar
08/07/2013
20:46
21:10 24min Test
Test de funciones creadas Insertar,
Modificar,Eliminar,Actualizar
08/07/2013
21:11
22:00 49min Diseño Presentacion
Diseño de formularios Producto y
marca
08/07/2013
22:01
22:20 19min
Verificacion del proyecto
Pruebas de la funcionalidad y integracion del proyecto
66 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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.
70 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
A2. Lista de Criterios para la evaluación y aceptación de Requerimientos.
Gestión de Requerimientos Lista de Criterios para Evaluar y Aceptar los Requerimientos.
Guía:
La lista de criterios para la evaluación y aceptación de requerimientos son preguntas a realizarse para evaluar el grado de confiabilidad de los requisitos elicitados. Pueden verse como condiciones para proceder en el proyecto con los requisitos actuales o si deben continuar en la elicitación.
La siguiente lista se usa de referencia para evaluar y aceptar los requerimientos del sistema por parte del analista de los requerimientos.
Criterio Preguntas sobre los criterios.
1. Requisitos ambiguos Los requisitos se pueden leer e interpretar de distinta forma por personas diferentes?
2. Requisitos realistas Son los requisitos realistas, dada la tecnología que se utilizará para la implementación del sistema?
3. Requisitos comprobables Se pueden comprobar los requisitos? Es decir, los testers pueden diseñar pruebas que permitan mostrar que el sistema cumple con los requisitos?
4. Requisitos combinados La descripción de los requisitos incluye requisitos únicos o pueden ser divididos en varios requisitos?
5. Requisitos innecesarios Hay requisitos como agregados “cosméticos” para el sistema, los cuales no son realmente necesarios?
6. Uso de hardware no estandarizado
Se utilizará hardware que no cumpla con las especificaciones del sistema?
7. Requisitos identificados de forma única.
Los requisitos son plenamente identificados unos de otros?
8. Requisitos Rastreables. Los requisitos pueden seguirse a través de las fases de desarrollo del sistema?
A3. Forma de Reporte del análisis de los criterios.
Gestión de Requerimientos Reporte del Análisis de los Criterios de Aceptación de los Requisitos.
Guía:
En la primera sección del documento se coloca la fecha en que se lleva a cabo el análisis, el nombre del proyecto y la lista de participantes en el análisis. En la segunda sección se enlistan el conjunto de documentos de requisitos que se revisarán así como su versión o estado. La tercera y última sección consiste en un checklist con características q deben cumplir los requisitos con un espacio para colocar observaciones o análisis
71 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
sobre los requisitos.
Versión: 1.0
Fecha:
Nombre del Proyecto:
Participantes del análisis:
Documentos de Requisitos analizados:
Titulo del Documento Versión o Revisión.
Criterios Analizados:
Núm.
Criterio Análisis Aprobado
1 Requisitos ambiguos
2 Requisitos realistas
3 Requisitos comprobables
4 Requisitos combinados
5 Requisitos innecesarios
6 Uso de hardware no estandarizado
7 Requisitos identificados de forma única
8 Requisitos Rastreables
72 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
A4. Forma de Acuerdos del conjunto de requerimientos.
Gestión de Requerimientos Acuerdo del conjunto de Requerimientos.
Guía:
En la primera sección del documento se coloca la fecha en que se lleva a cabo el análisis, el nombre del proyecto y la lista de participantes en el análisis. En la segunda sección se registran los requisitos clasificándolos en funcionales, no funcionales y otro tipo de requisitos, se les asigna una ID y algún documento en el que se referencie el requisito, y se marcará si se está de acuerdo con el requisito. En la tercera sección se coloca la lista de los participantes en los acuerdos, su cargo en el proyecto y su firma. En la última sección se coloca el nombre de la persona que aprobará el conjunto de requisitos, la fecha y su firma.
Versión: 1.0
Fecha: Nombre del Proyecto:
Participantes del acuerdo
Conjunto de Requisitos del Sistema:
ID Referencia
Requisitos Funcionales Acordado
ID Referencia
Requisitos No Funcionales Acordado
ID Referencia
Otros Requisitos Acordado
Participantes del acuerdo: Nombre:
Cargo:
Firma:
Nombre:
Cargo:
Firma:
73 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Nombre:
Cargo:
Firma:
Aprobado por:
Nombre:
Fecha:
Firma:
A5. Forma de Evaluación de impacto de los Requerimientos.
Gestión de Requerimientos Forma de Evaluación de impacto de los Requerimientos.
Guía:
Se coloca un número asignado a la petición de cambio para mantener un control. Se coloca el título para identificar la petición de cambio. Se proporciona una descripción sobre el cambio que se desea realizar. Se coloca el nombre del analista responsable de la petición. La fecha. Se coloca una breve descripción acerca de beneficios, penalizaciones, riesgos y costos provocados por la realización del cambio. Se calcula una prioridad para el cambio a realizar. Estimaciones de esfuerzos, impactos en el calendario y costos adicionales para la realización del cambio. Finalmente se enlistan los requisitos y tareas que pudieran afectarse por el cambio al requerimiento. Se escribe el nombre de la persona que aprobó la petición de cambio, la fecha y la firma.
Versión: 1.0
Petición de Cambio No:
Titulo:
Descripción:
Analista:
Fecha:
Estimaciones de Priorización
Beneficio Relativo:
Penalización Relativa:
Costo Relativo:
Riesgo Relativo:
Calculo de la prioridad:
Estimación del Esfuerzo Total: (Horas)
Estimación del Esfuerzo Perdido: (Horas)
Estimación del impacto en el calendario: (Días)
Impacto de Costos Adicionales:(Pesos)
Otros Requisitos Afectados:
Otras Tareas Afectadas:
Aprovado por:
74 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Nombre:
Fecha:
Firma:
Gestión de Requerimientos Forma de Estimación del Esfuerzo en los Cambios de los Requerimientos
Versión: 1.0
Fecha:
Nombre del Proyecto:
Encargado del documento:
Guía: 1. Identificar el subconjunto de las tareas antes mencionadas que tendrán que
hacer. 2. Asignar recursos a las tareas. 3. Estimar el esfuerzo necesario para las tareas pertinentes, sobre la base de
los recursos asignados. 4. Estimar el Total el esfuerzo. 5. Secuenciarlas tareas e identificar predecesores. 6. Determine si el cambio está en la ruta crítica del proyecto. 7. Estimar el calendario y el costo del impacto
Llenar la siguiente tabla usando el procedimiento:
Esfuerzo
(Horas
laborares)
Tarea
Actualizar el SRS o requisitos de base de datos con
el nuevo requisito
Desarrollo y evaluación de prototipos
Crear componentes de nuevo diseño
Modificar los componentes existentes de diseño
Desarrollar nuevos componentes de interfaz de
usuario
Modificar los componentes de interfaz de usuario
existente
Desarrollar publicaciones nuevo usuario y pantallas
de ayuda
Modificar las publicaciones existentes del usuario y
las pantallas de ayuda
75 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Desarrollar nuevas fuentes de código
Modificar el código fuente existentes
Compra e integrar software de terceros
Determinar los componentes, la compra, e integrar
hardware, y califica de proveedores
Modificar los ficheros de construcción
Desarrollar nuevas pruebas unitarias y de
integración
Modificar la unidad e integración existentes pruebas
Realizar las pruebas de integración y unidad
después de la aplicación
Escribir nuevo sistema y los casos las pruebas de
aceptación
Modificar actual sistema y los casos las pruebas de
aceptación
Modificar los pilotos de pruebas automatizadas
Realizar las pruebas de regresión en la unidad, la
integración, y el sistema de niveles
Desarrollar nuevos informes
Modificar los informes actuales de
Desarrollar nuevos elementos de base de datos
Modificar los elementos existentes de base de datos
Desarrollar nuevos archivos de datos
Modificar datos de los archivos existentes
Modificar varios planes de proyecto
Actualización de la documentación de otros
Requisitos de la actualización de la matriz de
trazabilidad
Examen de los productos modificados trabajo
76 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
reproceso Realizar siguientes revisiones y pruebas
Recertificar producto como seguros, seguro y
compatible con las normas.
Otras tareas adicionales
ESFUERZO TOTAL ESTIMADO
Realizó:
Fecha: Firma:
Aprobado por:
Nombre:
Fecha: Firma:
A6. Reporte de Estado de los Requerimientos.
Gestión de Requerimientos Reporte del estado de los Requerimientos.
Guía:
En la primera sección se coloca la fecha de la última actualización, el nombre del proyecto y el nombre del encargado de llenar el documento. En la segunda sección se enlistan los requisitos con su ID, los documentos que les hacen referencia y su estado. En la tercera sección se coloca un conjunto de estados con su descripción para los requisitos enlistados en la segunda sección. Por último se coloca el nombre de la persona encargada del seguimiento, la fecha y la firma, y posteriormente el nombre de la persona que aprobará el documento, su firma y la fecha.
Reporte del estado de los Requerimientos Versión: 1.0
Ultima Actualización:
Nombre del Proyecto:
Encargado del documento:
Conjunto de Requisitos del Sistema:
ID Referencia Requisitos Funcionales Estado*
ID Referencia Requisitos No Funcionales
77 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
ID Referencia Otros Requisitos
*Estados:
Estado Descripción
Propuesto El requisito es pedido por una fuente autorizada.
Aprobado El requisito ha sido analizado y puesto a disposición en la línea base del proyecto y el equipo de desarrollo se ha comprometido a implementarlo.
Implementado El código que implementa el requisito ha sido diseñado, codificado y probado. También ha sido seguido a través de la matriz de trazabilidad.
Verificado El correcto funcionamiento del requisito implementado ha sido confirmado en el producto y el requerimiento es considerado como completado.
Borrado Un requisito aprobado es quitado de la línea base del proyecto.
Rechazado Un requisito que es propuesto pero su implementación no está dentro los planes del proyecto.
Datos del encargado del seguimiento:
Nombre:
Fecha:
Firma:
Aprobado por: Nombre:
Fecha:
Firma:
A7. Elección de una Herramienta para el manejo de la base de datos de los
Requerimientos.
Gestión de Requerimientos Procedimiento para la Elección de una Herramienta para el manejo de la base de datos de los Requerimientos.
Versión: 1.0 Última Revisión:
Nombre del Proyecto:
Encargado del documento:
Guía:
Guía para la elección de la herramienta: Seleccione una herramienta basada en una combinación de la plataforma, precio, modos de acceso y paradigma—centrado en documentos o centrado en una base de datos— que mejor se ajusten al entono de desarrollo y cultura de la compañía. Realice el siguiente procedimiento antes de tomar una elección:
78 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
1. Defina los requerimientos de la empresa que deberá cumplir la herramienta, identifique 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 requerimientos en documentos o prefiere almacenarlos en una base de datos.
2. Liste 10 o 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.
3. Distribuya 100 puntos entre los factores listados anteriormente, y asígnele más puntos a los factores más importantes.
4. Obtenga información acerca de las herramientas con base en opiniones en foros, revistas especializadas, páginas web, etc.
5. Obtenga una versión de prueba para evaluar los factores subjetivos. 6. Evalué la herramienta en un proyecto real, y no solo el proyecto tutorial del
producto. 7. Asigne las calificaciones pertinentes y tome una decisión y llene el
siguiente formulario.
Plantilla de Elección de herramienta para la gestión de requisitos
Herramienta elegida:
Fecha:
Razones de la elección:
Histórico de elecciones
Herramienta elegida:
Fecha:
Razones de la elección:
Razones de la sustitución:
Nombre:
Fecha:
Firma:
Aprobado por: Nombre:
Fecha:
Firma:
Guía: Procedimiento para la Elección de una Herramienta para el manejo de
la base de datos de los Requerimientos.
En la primera sección se coloca la fecha de la última revisión, el nombre del
proyecto y el nombre del encargado de llenar el documento.
En la segunda sección se documenta una guía para elegir una herramienta
de almacenamiento de los requisitos.
79 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
En la tercera sección se escribe el nombre de la herramienta elegida, la
fecha y una justificación del porqué de la elección de la herramienta.
En la última sección se lleva a cabo el nombre de la nueva herramienta, la
fecha, las razones de la elección, y las razones por las que se sustituyó la
herramienta.
Por último se coloca el nombre de la persona encargada del seguimiento, la
fecha y la firma, y posteriormente el nombre de la persona que aprobará el
documento, su firma y la fecha.
A8. Procedimiento para el Sistema de Seguimiento de los Requerimientos.
Gestión de Requerimientos Procedimiento para el Sistema de Seguimiento de los Requerimientos.
Versión: 1.0 Ultima Actualización:
Nombre del Proyecto:
Encargado del documento:
Guía:
Es posible rastrear los requerimientos manualmente para aplicaciones de menos de 100 requerimientos aproximadamente, pero para sistemas más grandes es necesario elegir una herramienta de gestión de requerimientos. Considere la siguiente secuencia de pasos cuando deba implementar la trazabilidad de los requerimientos en un proyecto:
1. Seleccione las relaciones o enlaces que desea definir como posibilidades de trazabilidad, de acuerdo a la siguiente figura:
80 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Requerimientos de
Negocio.
Requerimientos de
Sistema, caso de uso,
atributo de calidad,
requisito de interface.
Petición de
CambioRegla de Negocio
Requerimiento
funcional del
software
Prueba del
Sistema
Planeación de las
Tareas del Proyecto de
Arquitectura,
interfaz de
usuario, diseño
funcional
Prueba de
IntegraciónCódigo
Pruebas de
unidad
Modifica
Modifica
Modifica
Modifica
2. Seleccione la forma de almacenar la información: una tabla en un
documento, una hoja de cálculo, o una herramienta de gestión de requerimientos.
3. Identifique las partes del producto de las cuales desea mantener información de rastreo. Inicie con las funciones críticas, las de más riesgo, o las porciones que requerirán mayor mantenimiento y cambios durante la vida del producto.
4. Modifique sus procedimientos de desarrollo y sus listas de verificación para poner al pendiente a los desarrolladores de actualizar la matriz de trazabilidad una vez que se implementa o aprueba un cambio en un requerimiento.
5. Defina como convenciones para identificar a cada componente del sistema que será enlazado. Por ejemplo CU-1, para caso de uso uno.
6. Defina sus matrices de trazabilidad con base en la siguiente plantilla del apéndice A8
Nombre:
Fecha:
Firma:
Aprobado por: Nombre:
Fecha:
Firma:
81 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Guía: Procedimiento para el Sistema de Seguimiento de los
Requerimientos.
En la primera sección se coloca la fecha de la última actualización, el
nombre del proyecto y el nombre del encargado de llenar el documento.
En la segunda sección se coloca una guía para diagramar los
requerimientos e inclusive su implementación de modo que su seguimiento
sea más sencillo.
Por último se coloca el nombre de la persona encargada del seguimiento, la
fecha y la firma, y posteriormente el nombre de la persona que aprobará el
documento, su firma y la fecha.
GC1. Lista de criterios para identificar los elementos de Configuración.
Sistema de Control de
Seguridad y Personal
Lista de Criterios para identificar los Elementos de
Configuración.
La siguiente lista se usa de referencia para la identificación de elementos de
configuración.
Para su uso el gestor deberá de tomar en cuenta las descripciones descritas por
cada fuente y considerar en que categoría se encuentra cada elemento descrito
en la EDT.
Fuente Descripción
Documentos usados por
un grupo.
Tomar en cuenta productos de trabajo que serán
usados por dos o más grupos de personas.
Documentos que se use
durante el ciclo de vida del
proyecto.
Tomar en cuenta productos de trabajo que se
espera que cambien con el tiempo.
Tomar en cuenta productos de trabajo que se
trabajen durante el ciclo de vida del proyecto.
Documentos que tienen
dependencia con otros
Tomar en cuenta productos de trabajo que son
dependientes de otro de manera que un cambio
82 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
documentos. en uno dicte cambios en otros documentos.
Documentos críticos. Tomar en cuenta productos de trabajo que son
críticos para el proyecto.
83 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
GC. Lista de pasos para asignar los identificadores únicos los elementos de Configuración.
Sistema de Control de
Seguridad y Personal
Lista de Pasos para asignar los identificadores
únicos a los Elementos de Configuración.
El siguiente proceso se usa para asignar los identificadores únicos los
elementos de Configuración.
Paso Descripción
Paso 1. Utilizar la siguiente nomenclatura para los
siguientes tipo de elementos:
Planes: Plan_Proceso del cual se realiza el
plan_
ERS: ERS_
Historial de Cambios de EGC:
Historial_Cambios_Nombre del EGC_
Código: Modulo_Nombre del Código
¿Ahora sí que no sé qué más hay?
Paso 2. Al final del cada elemento, excepto código agregar
el número “Ver-0.1” precedido por un guion bajo.
En caso de ser un cambio que se considera de
importancia alta, se incrementara el identificador
numérico al siguiente entero, en caso de ser un
cambio medio o bajo solo se aumentara un
decimal.
GC3. Lista de criterios para identificar cada cuándo un elemento de configuración se colocara bajo la administración de configuración.
Sistema de Control de
Seguridad y Personal
Lista de criterios para identificar cada cuándo un
elemento de configuración se colocara bajo la
administración de la configuración
84 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
La siguiente lista de criterios para identificarcadacuándoun elemento de
configuración se colocara bajo la administración de configuración.
Fuente Descripción
Ciclo de vida del proyecto. Un elemento de configuración puede ser puesto
bajo administración dependiendo de la fase de
ciclo de vida del software en la que se encuentre
el proyecto.
Listo para pruebas. Un elemento de configuración puede ser puesto
bajo administración cuando éste se encuentre
listo para las pruebas.
Costo y calendario. Un elemento de configuración puede ser puesto
bajo administración dependiendo de las
limitaciones de costo y calendario.
Requisitos del cliente. Un elemento de configuración puede ser puesto
bajo administración dependiendo de las
necesidades o requisitos del cliente.
2.7.9 A4. Plantilla para el Registro de Elementos de Configuración.
Sistema de Control de
Seguridad y Personal
Registro de Elemento de Configuración.
Autor: Cliente:
Propósito:
Identificador del
Proyecto
Tipo de Producto
Identificador del
Elemento
85 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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.
Sistema de Control de
Seguridad y Personal
Lista de características a considerar para la
elección de una herramienta para el control de
los elementos de la configuración del
software.
La siguiente lista presenta alguna de las características que deberían ser
consideradas para la elección de una herramienta para el control de los
elementos de configuración del software.
Característica Descripción
Control de acceso. Permite el manejo de múltiples usuarios y
control de permisos sobre el mismo de tal
manera que sea posible restringir
operaciones sobre los elementos de
configuración.
Recuperación de
elementos de
configuración.
Permite recuperar elementos de
configuración de versiones anteriores.
ÚltimaVersión
Fecha para colocar
bajo administración
de la configuración
Características
Importantes
Propietario
Responsable
Productos
Relacionados
Estatus
Comentarios
86 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Costo. Contemplar aspectos de costo de la
herramienta.
Usabilidad Es fácil usar la herramienta
Accesibilidad Es posible consultar los elementos de
configuración desde cualquier lugar con
acceso a internet.
GC6.Formulario para el registro de la Herramienta de Gestión de la Configuración.
Sistema de
Control de
Seguridad y
Personal
Formulario para el registro de la herramienta de gestión
de la configuración.
Formulario para el registro de la herramienta de gestión de la configuración.
Versión: 1.0
Última
Revisió
n:
Nombre del
Proyecto:
Encargado del
documento:
Plantilla de Elección de herramienta para la gestión de la configuración
Herramienta elegida:
Fecha:
Razones de la elección:
Herramienta elegida:
Fecha:
Razones de la elección:
87 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Razones de la sustitución:
N
o
m
br
e:
Fecha
: Firma:
Aprobado por:
N
o
m
br
e:
Fecha: Firma:
88 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
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.
89 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
GC8. Plantilla para la solicitud de creación o liberación de un elemento de configuración del software.
SOLICITUD DE ELEMENTOS DE CONFIGURACIÓN DEL SOFTWARE
Solicitante: Nombre del Proyecto:
Fecha de Solicitud: Jefe de Proyecto:
Nombre del ECS: Estado:
Descripción de motivos para la solicitud del elemento de configuración del
software:
Documentación Auxiliar:
Firma del Solicitante:
90 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
GC9. Plantilla para la Petición de Cambio.
PETICIÓN DE CAMBIO (RFC)
Petición Cambio No:
Solicitante: Nombre del Proyecto:
Fecha de Solicitud: Jefe de Proyecto:
Prioridad de Petición: Estado:
Descripción del Cambio:
Impacto en el Negocio: Impacto en el Sistema:
Beneficios del Cambio:
Costos del cambio:
Documentación Auxiliar:
91 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Firma del Solicitante:
GC10. Proceso para la Petición de Cambio.
Presentado
Evaluado Rechazado
Aprobado
Cambio Hecho
Verificado
Cerrado
El verificador confirma el cambio
El modificador instala el producto modificado
Falla la verificación
Modificador realiza el cambio y pide la verificación
No se requiere
verificación
CCB decide realizar el cambio
CCB decide no realizar el cambio
Evaluador realiza un
análisis de impacto
Se presenta un elemento
Cancelado
El cambio se cancela; se
elimina las modificaciones
El cambio se cancela; se
elimina las modificaciones
El cambio se cancela; se
elimina las modificaciones
92 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
GC11. Plantilla para el Historial de Cambios. (Obtenido desde Assemblla)
*A - AÑADIDO M - MODIFICADO D - BORRADO
NUMERODE VERSION FECHA *AMD DESCRIPCION NUMERO DE PETICION DE
CAMBIO
93 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
GC12. Plantilla para la solicitud de auditoría de los elementos de
configuración del software.
Plantilla de Petición de Auditoria
Fecha de Petición:
Responsable de la Petición:
Motivo de la Petición:
Resultado de la Auditoria:
Firma del Solicitante:
Firma del Gestor de la Configuración:
94 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
GC13. Plantilla para la auditoría de Gestión de la Configuración.
Plantilla de Auditoria de Gestión de la Configuración
Nombre del Auditor:
Fecha de la Auditoria:
Si No Notas
1.- ¿Existen ECS con más de 3 peticiones de salida para modificación durante el mes?
2.- ¿Se encontró inconsistencia a algún ECS?
3.- ¿Las versiones en el sistema de gestión son las últimas de cada ECS?
4.- ¿La estructura de almacenamiento se mantiene integra?
5.- ¿Existe algún conflicto con los niveles de acceso del sistema de gestión?
6.- ¿Existen más de 10 modificaciones de líneas base en el mes?
95 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
MC1. Plantilla para el registro del responsable de monitor del proyecto.
Proceso de
Monitoreo y
Control de
Proyectos
Plantilla para el registro del responsable de monitor del
proyecto.
La siguiente plantilla es un documento para el registro del responsable de
desempeñar el rol de monitor de proyecto.
Fecha: / /
Monitor del
proyecto
___________________________________________________
Nombre y firma
Líder del
proyecto
___________________________________________________
Nombre y firma
MC2. Plantilla para el registro de las desviaciones significativas encontradas
en la monitorización.
Proceso de Monitoreo y
Control de Proyectos
Plantilla para el registro de las desviaciones
significativas encontradas en las actividades
de monitoreo y control del proyecto.
En la siguiente tabla se registraran las desviaciones significativas
encontradas en las actividades de monitoreo y control del proyecto
identificando de manera correcta la fuente la cual puede ser:
Parámetro de planeación, compromisos, riesgos, datos, partes
interesadas, progreso, hitos
identificador Descripción Fuente Prioridad
96 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
97 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
MC3. Plantilla para el registro de problemas identificados en el proyecto a
través de la monitorización del proyecto.
Proceso de Monitoreo y
Control de Proyectos
Plantilla para el registro de problemas
identificados en el proyecto de configuración
se colocara bajo la administración de la
configuración
La siguiente lista presenta los problemas identificados en el proyecto a
través PMC así como también las acciones correctivas que se tomaran
para dicho problema y el responsable de ejecutar estas acciones
Nombre Descripción Acciones correctivas Responsa
ble
98 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Bibliografía
Documentos Electrónicos
“Guía de gestión pequeñas empresas basadas en cmmi”, Comité de
sistemas informáticos< www.inteco.es/file/jnPE0gHNH7k>
CMMI <www-03.ibm.com/press/es/es/pressrelease/35889.wss> ,
www.sei.cmu.edu/cmmi/ , CMMI v0.1
Calidad del Software <Generaknow.com/moodle>
PSP <Generaknow.com/moodle>
Base y Conocimiento del PSP <Generaknow.com/moodle>
Materia para el PSP0 <Generaknow.com/moodle>
Libros
Pressman, Roger. Ingenieria de Software: Un enfoque Practico.
España: Editorial McGraw-Hill, 2002.
Ponencia Diego Jodar y Anna Casals.pdf : PMBOK-PMI