UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO
FACULTAD DE CIENCIAS DE LA COMPUTACION Y TELECOMUNICACIONES
UNIDAD DE POSTGRADO
D...
2 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Propuesta para la Preparación
de ...
3 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Tabla de Contenido
1 Presentación...
4 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
4.4.2 Seleccionar Proveedor.........
5 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
4.5.7.6 Salidas.....................
6 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
4.5.11.6 Salidas....................
7 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
GC. Lista de pasos para asignar l...
8 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Prefacio.
Este proyecto fue reali...
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 ...
10 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 Facilitar a los empleados el d...
11 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Gestión de
Proveedores
SAM
Ing. ...
12 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Gestión de Cambios Ágil, y Refac...
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...
14 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Manejo de riesgo Documento del
p...
15 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
requerimientos y los productos (...
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 REQUERMIENT...
19 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
4.1.3 Especificación de requerim...
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 Planifica...
22 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 Establecer estimaciones
 Desa...
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....
24 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Prototipo de interfaz de usuario...
25 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Construcción
Disciplinas / Artef...
26 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Pruebas
Valide el sistema Dia 1 ...
27 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
construcción construcción
Prueba...
28 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Formulario de roles para respons...
29 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
V: Verify (Verificador). Persona...
30 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 Administrador de la configurac...
31 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
El monitoreo normalmente involuc...
32 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
El monitoreo de los atributos de...
33 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 Identificar desviaciones signi...
34 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Elaborar Pedido de
Cotización
El...
35 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
siempre se evaluarán en una prop...
36 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Salidas: SDP [Actualizado], Cont...
37 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
el proveedor.
Reportar
Incumplim...
38 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
procedimientos aplicables. Ident...
39 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
puede cambiarse solamente a trav...
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 ...
41 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 Todos los involucrados en el d...
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 si...
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
 Te...
44 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 Por último el Gestor de la Con...
45 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
procedimiento establecido y haci...
46 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 En caso de que la solicitud fu...
47 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 Todos los involucrados en el d...
48 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 El gestor deberá identificar a...
49 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 Documentación producida a lo l...
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 aut...
51 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 Resolver las inconformidades c...
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 ti...
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 impli...
54 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
organización (*)
GP 3.2 Se obtie...
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 as...
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 objetiva...
57 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
GP 3.1 Está establecido como pro...
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 actuali...
59 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
 Realizar el diseño del Sistema...
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
Ilu...
61 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Prototipo Gestionar Producto
7.2...
62 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
* Clase que define gestión de ma...
63 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
public void adicionar(intcodigo,...
64 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
/** Obtiene el código generado d...
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 ...
66 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
7.3.4 Requerimientos no funciona...
67 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
ANEXOS.
Informe de avance del Pr...
68 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
Citada por: Fecha:
Coordinador: ...
69 | P á g i n a
Santa Cruz – Bolivia 22/07/2013
Grupo de Trabajo: SC Software Developers
CONCLUSIONES
Nº Tarea Responsabl...
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software
Upcoming SlideShare
Loading in...5
×

Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software

976

Published on

Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
976
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
58
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Propuesta para la Preparación de la Certificación CMMI Nivel 2 de Pymes Desarrolladoras de Software"

  1. 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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. 7. 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. 8. 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. 9. 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 Organigramageneral dela empresa 1.4 PolíticasdelaEmpresa La norma ISO 9004:2000 establece que las políticas de calidad son competencia directa de la gerencia de la empresa. Santa Cruz Software Developers aplica las siguientes normas de calidad:  Producir un producto de calidad que satisfaga, y si es posible supere las expectativas del cliente.  Proporcionar nuestros servicios acordes en calidad y precio.  Trabajar en la mejora continua de nuestros procesos, procurando que resulten más efectivos y eficientes  Proporcionar a los empleados toda la información relevante y el entrenamiento y formación apropiada en relación con la calidad.
  10. 10. 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. 11. 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 VIDADEL PROYECTO SC Software Developers utiliza el ciclo de vida AUP (Agile unified process). Este describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP. El AUP aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas (test driven development - TDD), Modelado Ágil,
  12. 12. 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 Fasesdel ciclo de vida  Incepción (Concepción): El objetivo de esta fase es obtener una comprensión común cliente- equipo de desarrollo del alcance del nuevo sistema y definir una o varias arquitecturas candidatas para el mismo.  Elaboración: El objetivo es que el equipo de desarrollo profundice en la comprensión de los requisitos del sistema y en validar la arquitectura.  Construcción: Durante la fase de construcción el sistema es desarrollado y probado al completo en el ambiente de desarrollo.  Transición: el sistema se lleva a los entornos de preproducción donde se somete a pruebas de validación y aceptación y finalmente se despliega en los sistemas de producción. 3.1.1 Artefactos que se generan en cada fase del ciclo de vida FASE ACTIVIDADES ARTEFACTO QUE SE GENERA RESPONSABL E INICIO Modelado Modelo de Casos de Uso del Negocio Diagrama de casos de uso Gestor de Requerimiento
  13. 13. 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 Requerimiento s Implementación Prototipo de interfaz de usuario Documento Gestión de Requisitos Gestor de Requerimiento s Prueba Revisión inicial de modelos Documento del plan del proyecto Gestor de Requerimiento s Gestión del proyecto Administre el riesgo Documento del plan del proyecto Gestor de Requerimiento s Ambiente Establecer el ambiente de capacitación Documento de Plan de Aseguramiento de la calidad Gestos de aseguramient o de la calidad ELABORACION Modelado Modelo de Casos de Uso Documento Gestión de Requisitos Gestor de Requerimiento s Especificaciones de Casos de Uso Documento Gestión de Requisitos Gestor de Requerimiento s Prototipos de Interfaces de Usuario Documento Gestión de Requisitos Gestor de Requerimiento s Modelo de Análisis / Diseño Documento Gestión de Requisitos Gestor de Requerimiento s Modelo de Componentes Documento Gestión de Requisitos Gestor de Requerimiento s Pruebas Validar la arquitectura Documento del plan del proyecto Gestor de Requerimiento s Gestión del proyecto
  14. 14. 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 Requerimiento s Actualice su plan de proyecto Documento del plan del proyecto Gestor de Requerimiento s Ambiente Establecer el ambiente de capacitación Documento de Plan de Aseguramiento de la calidad Gestos de aseguramient o de la calidad CONSTRUCCIÓN E IMPLEMENTACIÓN Implementación Implementación/Cod ificación Documento del plan de configuración Gestor de configuración Despliegue Desplegar el script de instalación Documento del Plan del Proyecto Gestor de Requerimiento s Desplegar documentación inicial Documento del Plan del Proyecto Gestor de Requerimiento s Gestión del proyecto Manejo del riesgo Documento del Plan del Proyecto Gestor de Requerimiento s Actualizar su plan de proyecto Documento del Plan del Proyecto Gestor de Requerimiento s Ambiente Establecer el ambiente de capacitación Documento de Plan de Aseguramiento de la calidad Gestor de aseguramient o de la calidad 4 ÁREASDEL PROCESOS DEL CMMI NIVEL 2 SC Software Developers va rumbo a la certificación CMMI nivel 2 para lo cual está implantando procesos definidos en áreas claves que se describirán a continuación. 4.1 Gestión de Requerimientos El propósito del proceso de gestión de requerimientos es controlar la documentación referente a los requerimientos del producto, los cambios que ocurran y también identificar inconsistencias entre los
  15. 15. 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. 16. 16 | P á g i n a Santa Cruz – Bolivia 22/07/2013 Grupo de Trabajo: SC Software Developers
  17. 17. 17 | P á g i n a Santa Cruz – Bolivia 22/07/2013 Grupo de Trabajo: SC Software Developers
  18. 18. 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. 19. 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. 20. 20 | P á g i n a Santa Cruz – Bolivia 22/07/2013 Grupo de Trabajo: SC Software Developers
  21. 21. 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. 22. 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. 23. 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. 24. 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. 25. 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. 26. 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. 27. 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. 28. 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. 29. 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 yControl deproyecto PMC El propósito del monitoreo y control del proyecto es proporcionar una comprensión del avance del proyecto para que se puedan tomar las acciones correctivas apropiadas, cuando el rendimiento del proyecto se desvíe significativamente del plan. Un plan de proyecto documentado es la base para el monitoreo de las actividades, la comunicación del estado del proyecto y la ejecución de acciones correctivas. El avance se determina principalmente comparando los atributos de los productos de trabajo y de las tareas, el esfuerzo, el coste y el calendario reales, con el plan en los hitos establecidos dentro del calendario del proyecto o de la estructura de descomposición del trabajo. El conocimiento apropiado del avance del proyecto permite que las acciones correctivas sean llevadas a cabo de manera oportuna cuando el avance se desvía significativamente del plan. Una desviación es significativa, sí, cuando se deja sin resolver, impide al proyecto cumplir sus objetivos. 4.3.1. Responsables  Administrador del proyecto  Equipo de revisiones
  30. 30. 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. 31. 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. 32. 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. 33. 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 deProveedores El presente documento ilustra el proceso a ser seguido con el objeto de desarrollar y sostener las capacidades de la organización para seleccionar proveedores calificados y manejarlos en forma eficiente, de manera tal de cumplir con los objetivos planteados en el proyecto. 4.4.1 Planifica y Elaborar Adquisición Propósito: En principio cubre la adquisición de productos o servicios que serán entregados al cliente o que se requieren para su desarrollo. Elaborar el pedido de tercerización, estableciendo los criterios de evaluación de los productos, servicios y proveedores postulados. Entradas: SRS, Criterio de evaluación del producto, Template de Pedido de Cotización, Template de Matriz de Evaluación. Salidas: Pedido de Cotización, Criterio de evaluación del producto, Matriz de Evaluación | Actividad | Descripción | Responsable
  34. 34. 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. 35. 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. 36. 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. 37. 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. 38. 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 delaConfiguración El proceso de Gestión de la Configuración, controlara la integridad, que es la corrección y completitud de todos los elementos de trabajo que sean el resultado de alguno de los procesos de desarrollo del sistema, es decir cada elemento que se encuentre bajo el resguardo de la gestión no solo se encuentre ahí por simple mecanización, sino que se asegure que dicho elemento cumple con lo establecido en los lineamientos de nombramiento, así como permitir identificar que dicho elemento cumple con su objetivo dentro del sistema (p. e. Un código fuente que se encuentre nombrado adecuadamente y que realice lo que en su especificación dicta y que al mismo tiempo se puede encontrar a partir de él al requisito del cual fue origen). Lo anterior con el objetivo de no solo tener un control adecuado de los elementos, sino también un histórico de cambios y versiones en caso de contingencias y errores de acoplamiento o de cualquier otra índole 4.5.1 Plan de Gestión de la Configuración del Software Describimos todas las actividades de Gestión de Configuración y Cambios que serán realizadas durante todo el ciclo de vida del proyecto. Brindando planificaciones detalladas de las actividades, responsabilidades asignadas, recursos necesarios que incluyen personal, herramientas y equipamiento. El Plan de Gestión de Configuración contiene información que puede ser cubierta a una mayor o menor magnitud por otros planes. Los enfoques siguientes pueden ser usados para manejar esta potencial coincidencia:  Hacer referencias al contenido relacionado que se encuentre en otro plan.  Proveer la visión general en otro plan, suministrar los detalles más significativos en este plan y hacer referencias necesarias desde los otros planes hacia este plan.  Asegurar que las secciones de este artefacto cubran solamente las áreas que no han sido cubiertas anteriormente en otro lugar. 4.5.2 Definiciones, Acronimos y Abreviaturas Línea Base: Es una especificación o producto de trabajo que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, es de la versión 0 y que de ahí en adelante sirve como base para un desarrollo posterior y que
  39. 39. 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. 40. 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. 41. 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. 42. 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. 43. 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. 44. 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. 45. 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. 46. 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. 47. 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. 48. 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 Plandeaseguramientode lacalidad El proceso de aseguramiento de la calidad de proceso y producto evaluará objetivamente los procesos, los productos de trabajo y los servicios ejecutados frente a las descripciones de proceso, los estándares y los procedimientos aplicables. Identificar y documentar las inconformidades. Proporcionar retroalimentación al equipo del proyecto y a los gerentes sobre los resultados de las actividades de aseguramiento de la calidad. Asegurar que sean tratadas las inconformidades. Documentos que se analizan durante todo este proceso:  Estándares de la organización: políticas de calidad, lineamientos de la organización.
  49. 49. 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.ProporcionarunaVisión Objetiva Para cumplir este objetivo se tienen las siguientes prácticas, éstas se resumen a continuación:  Comunicar y asegurar la resolución de las inconformidades.  Establecer registros 4.6.2.2.Planificación deProceso El propósito de la planificación es establecer el nivel de detalle que se tendrá en la ejecución del aseguramiento de la calidad de procesos y productos. 4.6.2.2.1. Criterio deEntrada Se han identificado los estándares, procesos, herramientas y producto que se van a evaluar a lo largo del desarrollo del proyecto. 4.6.2.2.2. Recursos Los recursos para realizar el proceso serán:  Las plantillas provistas por el encargado de PPQA para evaluar los procesos y los productos.  Los documentos tales como plantillas, estándares y guías para realizar los procesos, productos o servicios que serán evaluados.  Material de oficina.
  50. 50. 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. 51. 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 PROCESODE SOFTWARE 6.1 Scampin CMMI-2: PA1: - Gestión de requisitos # NA # ? Valor P 1 SP 1.1 Se consigue la comprensión de los requisitos 9,00 9 SP 1.2 Se obtiene un compromiso basado en los requisitos 9,00 9 SP 1.3 Se gestionan las modificaciones de requisitos 8,00 8 SP 1.4 Se mantiene la trazabilidad bi-direccional de los requisitos 8,00 8 SP 1.5 Se identifican las inconsistencias entre el trabajo del proyecto y los requisitos 7,00 7
  52. 52. 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 Tot al 7,87 CMMI-2 - PA2: Planificación de proyecto # NA # ? Valor P 1 SP 1.1 Se estima el alcance del proyecto (relación de tareas) 9,00 9 SP 1.2 Se realizan estimaciones de los productos de trabajo y atributos de las tareas 8,00 8 SP 1.3 Se define el ciclo de vida del proyecto (fases) 9,00 9 SP 1.4 Se realizan estimaciones de esfuerzo y coste 8,00 8 SP 2.1 Se establece el presupuesto y calendario del proyecto 6,00 6 SP 2.2 Se identifican los riesgos del proyecto 7,00 7 SP 2.3 Se define un plan para administrar la información 7,00 7 SP 2.4 Se define un plan para administrar los recursos 8,00 8 SP 2.5 Se define un plan para administrar los recursos y las habilidades 8,00 8 SP 2.6 Se define un plan para involucrar a los interesados 9,00 9 SP 2.7 Se establece el plan general de proyecto 8,00 8 SP 3.1 Se revisan los planes que afectan al proyecto 6,00 6 SP 3.2 Se reconcilia el trabajo y el nivel de los recursos 8,00 8 SP 3.3 Se obtiene un compromiso de los implicados, con el plan del proyecto 7,00 7 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. 53. 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 Tot al 7,79 CMMI-2 - PA3: Seguimiento y control del proyecto # NA # ? Valor P 1 SP 1.1 Hay parámetros en la planificación para el seguimiento del proyecto 9,00 9 SP 1.2 Se realiza un seguimiento de las responsabilidades 8,00 8 SP 1.3 Se realiza un seguimiento de los riesgos del proyecto 6,00 6 SP 1.4 Se realiza un seguimiento de la gestión de la información 7,00 7 SP 1.5 Se realiza un seguimiento de la implicación de los actores 7,00 7 SP 1.6 Se realizan revisiones de seguimiento 6,00 6 SP 1.7 Se realizan revisiones de hitos 8,00 8 SP 2.1 Se analizan la casuística del proyecto 7,00 7 SP 2.2 Se toman acciones correctivas 9,00 9 SP 2.3 Se gestionan las acciones correctivas 8,00 8 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. 54. 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 Tot al 7,70 CMMI-2 - PA4: Gestión de acuerdo con proveedores # NA # ? Valor P1 SP 1.1 Se determina el tipo de adquisición 8,00 8 SP 1.2 Se realiza una selección de suministradores 7,00 7 SP 1.3 Se establece un acuerdo con el proveedor 8,00 8 SP 2.1 Se evalúan posibles productos estándar 8,00 8 SP 2.2 Se ejecuta el acuerdo con el proveedor 9,00 9 SP 2.3 Se realizan acciones de aceptación de los productos adquiridos 9,00 9 SP 2.3 Se planifica la integración de los productos adquiridos 8,00 8 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 Tot al 7,88 (*) No es necesario en el nivel 2 de madurez CMMI-2 - PA6: Aseguramiento de la calidad de producto y proceso # NA # ? Val or P1 SP 1.1 Se evalúan objetivamente los procesos 9,00 9 SP 1.2 Se evalúan objetivamente los productos de trabajo y los servicios 7,00 7 SP 2.1 Se comunican y se garantiza la resolución de las no-conformidades 8,00 8 SP 2.2 Hay establecidos registros 8,00 8 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. 55. 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 Tot al 8,21 CMMI-2 - PA7: Gestión de la configuración # NA # ? Va lor P1 SP 1.1 Se identifican los elementos de la configuración 9,0 0 9 SP 1.2 Hay establecido un sistema para gestionar la configuración 8,0 0 8 SP 1.3 Se crean o ponen en marcha las líneas base 9,0 0 9 SP 2.1 Se trazan las peticiones de cambios 9,0 0 9 SP 2.2 Se controlan los elementos de la configuración 9,0 0 9 SP 3.1 Hay un registro mantenido para los elementos de la configuración 9,0 0 9 SP 3.2 Se audita la integridad de las líneas base 9,0 0 9 GP 2.1 (CO 1) La organización tiene establecida una política 8,0 0 8 GP 2.2 (AB 1) Se planifica este proceso 8,0 0 8 GP 2.3 (AB 2) Se le proporcionan los recursos adecuados 8,0 0 8 GP 2.4 (AB 3) Tiene asignadas las responsabilidades 8,0 0 8 GP 2.5 (AB 4) Las personas implicadas reciben formación 7,0 0 7 GP 2.6 (DI 1) Se gestiona la configuración de los elementos de este proceso 8,0 0 8 GP 2.7 (DI 2) Se identifica a los actores importantes para el proceso 9,0 0 9 GP 2.8 (DI 3) Se monitoriza y controla el proceso 9,0 0 9
  56. 56. 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,0 0 8 GP 2.10 (VE2) Se revisa el proceso con los directivos responsables 8,0 0 8 GP 3.1 Está establecido como proceso definido de la organización (*) 7,0 0 7 GP 3.2 Se obtiene información para su mejora (*) 7,0 0 7 CMMI-2 - PA5: Medición y análisis # N A # ? Val or P 1 SP 1.1 Se establecen los objetivos de la medición 8,0 0 8 SP 1.2 Se especifican las métricas 8,0 0 8 SP 1.3 Se especifican los procedimientos de obtención y registro 8,0 0 8 SP 1.4 Se especifican los procedimientos de análisis 7,0 0 7 SP 2.1 Se obtienen datos de las mediciones 7,0 0 7 SP 2.2 Se analizan los resultados de las mediciones 6,0 0 6 SP 2.3 Se guardan los datos y los resultados de las mediciones 6,0 0 6 SP 2.3 Se comunican los resultados 7,0 0 7 GP 2.1 (CO 1) La organización tiene establecida una política 8,0 0 8 GP 2.2 (AB 1) Se planifica este proceso 6,0 0 6 GP 2.3 (AB 2) Se le proporcionan los recursos adecuados 8,0 0 8 GP 2.4 (AB 3) Tiene asignadas las responsabilidades 8,0 0 8 GP 2.5 (AB 4) Las personas implicadas reciben formación 8,0 0 8 GP 2.6 (DI 1) Se gestiona la configuración de los elementos de este proceso 7,0 0 7 GP 2.7 (DI 2) Se identifica a los actores importantes para el proceso 9,0 0 9 GP 2.8 (DI 3) Se monitoriza y controla el proceso 8,0 0 8 GP 2.9 (VE 1) Se evalúa objetivamente su cumplimiento 7,0 0 7 GP 2.10 (VE2) Se revisa el proceso con los directivos responsables 7,0 0 7 Tot al 8,41
  57. 57. 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,0 0 7 GP 3.2 Se obtiene información para su mejora (*) 7,0 0 7 Total 7,3 9 (*) No es necesario en el nivel 2 de madurez 6.2 Radar Áreasdeproceso Gestión de requisitos (REQM) 7,87 Planificación de proyecto (PP) 7,79 Seguimiento y control de proyecto (PMC) 7,70 Gestión de acuerdo con proveedores (SAM) 7,88 Medición y análisis (MA) 7,39 Aseguramiento de la calidad del producto y servicio (PPQA) 8,21 Gestión de la configuración (CM) 8,41 7 CASO DE ESTUDIO El presente caso de estudio tiene como base el modelo PSP que está siendo aplicado en el caso de uso GESTIONAR PRODUCTO. 7.1 Titulo del Proyecto Sistema de gestión para la compra, venta e inventario de La Librería y Papelería “LIBER”.
  58. 58. 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. 59. 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 deRequerimientos 7.2.1 Identificación de actores de Caso de Uso Administrador: Administra la librería, dirige a los empleados. Administrador Vendedor: Atiende al cliente y busca los productos que el cliente requiera. Vendedor Cliente: informa al vendedor que artículos desea comprar. Cliente
  60. 60. 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. 61. 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. 62. 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. 63. 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. 64. 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. 65. 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 FEC HA ST AR T STO P INTERR UPCION TIEMPO DELTA ACTIVIDAD COMENTARIO 08/07 /2013 17: 30 18:0 0 30 min Diseño Diseño logico de la base de datos en Postgres 08/07 /2013 18: 00 18:1 5 call phone 15 min Charla informativa Coordinacion con el Gestor de proyecto 08/07 /2013 18: 16 19:0 0 44min investigacion modelo Hibernate Investigacion para SQL Server y herramientas de ayuda 08/07 /2013 19: 01 19:3 0 29min Configuracion de hibernate Configuracion y Creacion de conexión SQL 08/07 /2013 19: 31 20:0 0 29min Configuracion de aplicación de modelo 3 capas Creacion de clases en modelo 3 capas 08/07 /2013 20: 01 20:4 5 44min Creacion de los ABMs implementacio n de las funciones Insertar, Modificar,Elim inar,Actualizar 08/07 /2013 20: 46 21:1 0 24min Test Test de funciones creadas Insertar, Modificar,Elim inar,Actualizar 08/07 /2013 21: 11 22:0 0 49min Diseño Presentacion Diseño de formularios Producto y marca 08/07 /2013 22: 01 22:2 0 19min Verificacion del proyecto Pruebas de la funcionalidad y integracion del proyecto
  66. 66. 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. 67. 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. 68. 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. 69. 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.

×