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

UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO

FACULTAD DE CIENCIAS DE LA COMPUTACION Y TELECOMUNICACIONES

UNIDAD DE POSTGRADO

DOCUMENTACION

Propuesta para la Preparación de la Certificación CMMI Nivel 2 de

Pymes Desarrolladoras de Software

Por:

Eliana Mancilla Vargas

Heydi Barja Bravo

Betty Chaca Flores

Joshep Lujan Pardo

Patricia Juchani Roman

Dirigido por:

Ing. Karen Infanta Soto

Santa Cruz – Bolivia

2 | P á g i n a

Santa Cruz – Bolivia 22/07/2013

Grupo de Trabajo: SC Software Developers

Propuesta para la Preparación

de la Certificación CMMI Nivel 2

de Pymes Desarrolladoras de

Software

3 | P á g i n a



Tabla de Contenido

1 Presentación De La Empresa ................................................................................... 9

1.1 Misión................................................................................................................ 9

1.2 Visión ................................................................................................................ 9

1.3 Organigrama general de la empresa ............................................................... 9

1.4 Políticas de la Empresa ................................................................................... 9

2 Descripción de roles ............................................................................................... 10

3 Ciclo de vida del Proyecto ...................................................................................... 11

3.1 Fases del ciclo de vida .................................................................................. 12

3.1.1 Artefactos que se generan en cada fase del ciclo de vida ....................... 12

4 Áreas del Procesos del CMMI nivel 2 .................................................................... 14

4.1 Gestión de Requerimientos ........................................................................... 14

4.1.1 Acta de Reunión de Requerimientos ........................................................ 15

4.1.2 Lista de Requerimientos ............................................................................... 15

4.1.3 Especificación de requerimiento ................................................................... 19

4.1.4 Documento de validación de requerimientos ............................................... 19

Control de cambios ................................................................................................. 21

4.2 Planificación del Proyecto PP .................................................................... 21

4.2.1 Definir Estrategia de desarrollo ..................................................................... 21

4.2.2 Elaborar plan de proyecto ............................................................................ 22

4.2.3 Presupuesto del Proyecto .......................................................................... 22

4.2.4 Calendario del Proyecto ............................................................................. 23

4.2.5 Identificar Riesgos del Proyecto ................................................................. 27

4.2.3 Elaborar plan de desarrollo ....................................................................... 28

4.2.4 Definir Responsables por área .................................................................. 28

4.2.5 Informe de situación del proyecto ............................................................. 29

4.3 Monitoreo y Control de proyecto PMC ...................................................... 29

4.3.1. Responsables ................................................................................................. 29

4.3.3. Registro de actividades .............................................................................. 30

4.3.4. Evaluación y ajuste del plan de proyecto ................................................... 33

4.4 Gestión de Proveedores ...................................................................................... 33

4.4.1 Planifica y Elaborar Adquisición .................................................................. 33

Propuesta para la Preparación de la Certificación

CMMI Nivel 2 de Pymes Desarrolladoras de Software

4 | P á g i n a



4.4.2 Seleccionar Proveedor ................................................................................... 35

4.4.4 Contratar Proveedores ............................................................................... 35

4.4.5 Realizar Control y Seguimiento .................................................................. 36

4.4.6 Aceptar Producto Adquirido ......................................................................... 37

4.4.7 Documentos de aceptación o rechazo de productos o servicios .......... 37

4.5 Gestión de la Configuración .......................................................................... 38

4.5.1 Plan de Gestión de la Configuración del Software ..................................... 38

4.5.2 Definiciones, Acronimos y Abreviaturas ..................................................... 38

4.5.3 Roles ............................................................................................................... 39

4.5.4 Guia de Proceso en la Gestion de Configuracion ........................................ 39

4.5.4.1 Entradas ................................................................................................... 39

4.5.4.2 Proceso ..................................................................................................... 40

4.5.5 Planeacion ................................................................................................... 40

4.5.5.1 Proposito .................................................................................................. 40

4.5.6 Responsables.............................................................................................. 40

4.5.6.1 Entradas ................................................................................................... 40

4.5.6.2 Actividades .............................................................................................. 41

4.5.2.3 Salidas ...................................................................................................... 41

4.5.3 Identificar Elementos de la Configuración ................................................... 41

4.5.3.1 Propósito .................................................................................................. 41

4.5.3.2 Responsables .......................................................................................... 41

4.5.3.3 Criterio de Entrada ................................................................................... 41

4.5.3.4 Entradas ................................................................................................. 42

4.5.3.5 Actividades .............................................................................................. 42

4.5.3.6 Salidas ...................................................................................................... 42

4.5.7 Establecer un Sistema de Administración de Configuración .................. 42

4.5.7.1 Propósito............................................................................................... 42

4.5.7.2 Responsables ....................................................................................... 42

4.5.7.3 Criterio de Entrada ............................................................................... 43

4.5.7.4 Entradas ................................................................................................ 43

4.5.7.5 Actividades ........................................................................................... 43

5 | P á g i n a



4.5.7.6 Salidas ................................................................................................... 44

4.5.8 Crear o Liberar las líneas Bases ................................................................ 44

4.5.8.1 Propósito............................................................................................... 44

4.5.8.1.1 Responsables ..................................................................................... 44

4.5.8.1.2 Criterios de entrada ............................................................................ 44

4.5.8.1.3 Entradas .............................................................................................. 44

4.5.8.2 Actividades ........................................................................................... 44

4.5.8.3 . Salidas ................................................................................................. 45

4.5.9 Seguir las peticiones de Cambios .......................................................... 45

4.5.9.1.1 Propósito ............................................................................................. 45

4.5.9.1.2 Responsables ..................................................................................... 45

4.5.9.1.3 Criterios de entrada ............................................................................ 45

4.5.9.1.4 Entradas .............................................................................................. 45

4.5.9.1.5 Actividades.......................................................................................... 45

4.5.9.2 Salidas ................................................................................................... 46

4.5.10 Realizar Auditorías de Configuración ................................................. 46

4.5.10.1.1 Propósitos ......................................................................................... 46

4.5.10.2 Responsables ...................................................................................... 46

4.5.10.3 Criterios de entrada ............................................................................. 46

4.5.10.4 Entradas ............................................................................................... 47

4.5.10.5 Actividades .......................................................................................... 47

4.5.10.6 Salidas .................................................................................................. 47

4.5.11 Verificaciones ....................................................................................... 47

4.5.11.1 Propósito .............................................................................................. 47

4.5.11.2 Responsable ........................................................................................ 47

4.5.11.3 Criterios de entrada ............................................................................. 47

4.5.11.4 Entradas ............................................................................................... 47

4.5.11.5 Actividades .......................................................................................... 47

6 | P á g i n a



4.5.11.6 Salidas .................................................................................................. 48

4.5.11.7 Métricas ................................................................................................ 48

4.6 Plan de aseguramiento de la calidad ............................................................ 48

4.6.2. Proceso ........................................................................................................... 49

4.6.2.1. Proporcionar una Visión Objetiva ................................................................. 49

4.6.2.2. Planificación de Proceso ............................................................................... 49

4.6.2.2.1. Criterio de Entrada .................................................................................. 49

4.6.2.2.2. Recursos .................................................................................................. 49

4.6.2.2.3. Responsables .......................................................................................... 50

4.6.2.2.4. Practicas................................................................................................... 50

4.6.2.2.5. Verificación .............................................................................................. 51

4.6.2.2.6. Métricas .................................................................................................... 51

6 Madurez del Proceso de Software.......................................................................... 51

6.1 Scampin .......................................................................................................... 51

6.2 Radar ............................................................................................................... 57

7 Caso de estudio ....................................................................................................... 57

7.1 Titulo del Proyecto ............................................................................................... 57

7.1.1 Introducción .................................................................................................... 58

7.1.2 Objetivo Especifico ........................................................................................ 58

7.1.3 Objetivo General ............................................................................................. 58

7.2 Definición de Requerimientos .............................................................................. 59

7.2.1 Identificación de actores de Caso de Uso .................................................. 59

7.2.2 Detalle de caso de uso ................................................................................. 60

7.2.3 Modelo Físico de la base de datos ................................................................ 61

7.3 Implementación ................................................................................................... 61

7.3.1 Estándar de Codificación del Caso de Uso Gestionar Producto ................ 61

7.3.2 Postmorten .................................................................................................. 65

7.3.3 Métricas en Cuanto a Defectos ...................................................................... 65

7.3.4 Requerimientos no funcionales del sistema ................................................ 66

8 Conclusiones. .......................................................................................................... 66

Anexos. ........................................................................................................................... 67

Informe de avance del Proyecto ............................................................................. 67

Acta de la reunión del Equipo ................................................................................ 67

GC1. Lista de criterios para identificar los elementos de Configuración............ 81

7 | P á g i n a



GC. Lista de pasos para asignar los identificadores únicos los elementos de

Configuración. ......................................................................................................... 83

GC3. Lista de criterios para identificar cada cuándo un elemento de

configuración se colocara bajo la administración de configuración. ................. 83

GC5.Lista de características a considerar para la Elección de una Herramienta

para el control de los elementos de configuración del software. ........................ 85

GC6.Formulario para el registro de la Herramienta de Gestión de la

Configuración. ......................................................................................................... 86

GC7. Proceso para obtener autorización de la tarjeta de control de

configuración (CCB) antes de crear o liberar líneas de base de los elementos de

configuración........................................................................................................... 88

GC8. Plantilla para la solicitud de creación o liberación de un elemento de

configuración del software. .................................................................................... 89

Solicitud de elementos de configuración del software ............................................... 89

GC9. Plantilla para la Petición de Cambio. ............................................................ 90

Petición de Cambio (RFC).............................................................................................. 90

GC10. Proceso para la Petición de Cambio. .......................................................... 91

GC13. Plantilla para la auditoría de Gestión de la Configuración. ....................... 94

8 | P á g i n a



Prefacio.

Este proyecto fue realizado durante el período que va desde el mes de julio. El desarrollo

del mismo surgió a partir de la investigación del modelo CMMI.

Somos una empresa de desarrollo de software y nuestra meta es lograr la satisfacción del

cliente ofreciendo un producto de calidad. Para lograr un producto de calidad debemos de

mejorar nuestros procesos ya que depende de ello nuestro éxito.

CMMI nos ayuda a identificar las mejores prácticas para cada proceso definido en nuestra

empresa. En transcurso de este documento iremos detallando cada proceso y sus prácticas

de tal forma que nos permitirá acreditarnos como una empresa madura en base a sus

procesos.

9 | P á g i n a



1 PRESENTACIÓN DE LA EMPRESA

1.1 Misión

Satisfacer las necesidades de nuestros clientes en Desarrollo de Software con los mayores niveles de calidad, confiabilidad, rapidez con un equipo de trabajo motivado y capacitado.

1.2 Visión

Convertirnos en un referente dentro del mercado Boliviano en el desarrollo de Software para la industria de Software.

1.3 Organigrama general de la empresa

1.4 Políticas de la Empresa

La norma ISO 9004:2000 establece que las políticas de calidad son

competencia directa de la gerencia de la empresa.

Santa Cruz Software Developers aplica las siguientes normas de calidad:

Producir un producto de calidad que satisfaga, y si es posible supere

las expectativas del cliente.

Proporcionar nuestros servicios acordes en calidad y precio.

Trabajar en la mejora continua de nuestros procesos, procurando que

resulten más efectivos y eficientes

Proporcionar a los empleados toda la información relevante y el

entrenamiento y formación apropiada en relación con la calidad.

10 | P á g i n a



Facilitar a los empleados el desarrollo de sus habilidades y

conocimientos, para beneficio tanto de los empleados, como de la

propia empresa.

Mantener un sistema que satisfaga los requisitos de la norma ISO

9001 y facilite la realización de productos software de calidad.

Proporcionar un entorno seguro a sus empleados.

Establecer objetivos de calidad medibles.

Esforzarse continuamente para mejorar el funcionamiento en relación

con la calidad.

Consideramos la calidad como una responsabilidad dentro de nuestras

áreas de trabajo, comprometidos con el estricto cumplimiento de las normas

de calidad establecidas.

2 DESCRIPCIÓN DE ROLES

Tabla de roles de acuerdo a las áreas de proceso establecidos en CMMI nivel 2

Área de proceso Responsable

Roles involucrados

Categoría y Comentarios

Gestión de Requerimientos REQM

Ing. Eliana Mancilla

Gestor de requerimientos

Función básicamente de gestión a nivel de proyecto que involucra a cliente y patrocinador de proyecto

Plan del proyecto PP

Ing. Eliana Mancilla

Gestor de planificación

Función desarrollar el plan del proyecto, estimar esfuerzo y costo y lograr compromiso con el plan.

Monitoreo y Control de proyecto PMC

Ing. Joshep Lujan

Líder o jefe de proyecto

Supervisa y hace seguimiento

11 | P á g i n a



Gestión de Proveedores SAM

Ing. Betty Chaca

Área de compras o adquisiciones

Actividades de gestión de proyectos que según la estructura de la organización se gestiona por el mismo proyecto o existe un área de adquisición que ejecuta la mayoría de las actividades

Gestión de Aseguramiento de la Calidad PPQA

Ing. Heydi Barja

Personal de aseguramiento de calidad

Función de apoyo a proyectos establecidos en SQA, Eje.: un responsable de realizar una revisión objetiva del cumplimiento del proceso y los productos de trabajo

Gestión de la Configuración CM

Ing. Patricia Juchani

Responsable de configuración

Actividad de apoyo que se puede llevar por cada proyecto, principalmente cuando son desarrollos independientes.

Gestión de desarrollo

Ing. Betty Chaca

Gestor de desarrollo

Actividad de desarrollo de software según establecido en los requerimientos y el plan de proyecto.

3 CICLO DE VIDA DEL PROYECTO

SC Software Developers utiliza el ciclo de vida AUP (Agile unified process). Este

describe de una manera simple y fácil de entender la forma de desarrollar

aplicaciones de software de negocio usando técnicas ágiles y conceptos que

aún se mantienen válidos en RUP. El AUP aplica técnicas ágiles incluyendo

Desarrollo Dirigido por Pruebas (test driven development - TDD), Modelado Ágil,

12 | P á g i n a



Gestión de Cambios Ágil, y Refactorización de Base de Datos para mejorar la

productividad.

3.1 Fases del ciclo de vida

Incepción (Concepción): El objetivo de esta fase es obtener una

comprensión común cliente- equipo de desarrollo del alcance del

nuevo sistema y definir una o varias arquitecturas candidatas para

el mismo.

Elaboración: El objetivo es que el equipo de desarrollo profundice en

la comprensión de los requisitos del sistema y en validar la

arquitectura.

Construcción: Durante la fase de construcción el sistema es

desarrollado y probado al completo en el ambiente de desarrollo.

Transición: el sistema se lleva a los entornos de preproducción

donde se somete a pruebas de validación y aceptación y finalmente

se despliega en los sistemas de producción.

3.1.1 Artefactos que se generan en cada fase del ciclo de vida

FASE ACTIVIDADES ARTEFACTO QUE

SE GENERA RESPONSABL

E

INICIO

Modelado

Modelo de Casos de Uso del Negocio

Diagrama de casos de uso

Gestor de Requerimiento

13 | P á g i n a



s

Estimación de costos y riesgos

Documento del plan de proyecto

Gestor de Requerimiento

s

Definición de riesgos

Documento del plan de proyecto

Gestor de Requerimientos

Implementación

Prototipo de interfaz de usuario

Documento Gestión de Requisitos


Prueba

Revisión inicial de modelos

Documento del plan del proyecto


Gestión del proyecto

Administre el riesgo Documento del plan del proyecto


Ambiente

Establecer el ambiente de capacitación

Documento de Plan de Aseguramiento de la calidad

Gestos de aseguramiento de la calidad

ELABORACION

Modelado

Modelo de Casos de Uso



Especificaciones de Casos de Uso



Prototipos de Interfaces de Usuario



Modelo de Análisis / Diseño



Modelo de Componentes



Pruebas

Validar la arquitectura




14 | P á g i n a



Manejo de riesgo Documento del plan del proyecto


Actualice su plan de proyecto



Ambiente



Gestos de aseguramiento de la calidad

CONSTRUCCIÓN E IMPLEMENTACIÓN

Implementación

Implementación/Codificación

Documento del plan de configuración

Gestor de configuración

Despliegue

Desplegar el script de instalación

Documento del Plan del Proyecto


Desplegar documentación inicial




Manejo del riesgo Documento del Plan del Proyecto


Actualizar su plan de proyecto



Ambiente



Gestor de aseguramiento de la calidad

4 ÁREAS DEL PROCESOS DEL CMMI NIVEL 2

SC Software Developers va rumbo a la certificación CMMI nivel 2 para lo

cual está implantando procesos definidos en áreas claves que se

describirán a continuación.

4.1 Gestión de Requerimientos

El propósito del proceso de gestión de requerimientos es controlar la

documentación referente a los requerimientos del producto, los cambios

que ocurran y también identificar inconsistencias entre los

15 | P á g i n a



requerimientos y los productos (documentos y componentes de

software) del proyecto generados en cada fase del ciclo de desarrollo.

4.1.1 Acta de Reunión de Requerimientos

Se establecerán actas de requerimientos para obtener una comprensión de los requerimientos y el compromiso sobre los requerimientos acordados.

Dicha información se registrara en un formulario Acta de reuniones, favor remitirse al los anexos para ver el formulario.

4.1.2 Lista de Requerimientos

Enumerar todos los requerimientos establecidos en el compromiso de

requerimientos acordados. Este registro se lleva a cabo en los

siguientes formularios:

16 | P á g i n a



17 | P á g i n a



18 | P á g i n a



Finalmente:

LISTA DE REQUERMIENTOS

Empresa: No.

Cliente: Fecha:

Id Requisito Descripción

19 | P á g i n a



4.1.3 Especificación de requerimiento

Detallar y documentar cada uno de los requisitos siendo lo más

explícitos posibles, definir responsables y tiempo de desarrollo.

Esta información queda detallada en el siguiente formulario:

REGISTRO DE REQUERMIENTOS

Empresa:

No.

Cliente: Fecha:

Id Prioridad Estado Responsable Tiempo de

desarrollo

4.1.4 Documento de validación de requerimientos

Gestión de cambios de los requerimientos, Los cambios ocurren

conforme avanza el trabajo o incluso se derivan requerimientos

adicionales. Es por eso que es necesario gestionar estas acciones de

manera eficiente y eficaz. Analizar el impacto del cambio conociendo la

fuente del requerimiento y la razón del cambio debe estar documentado.

Mantener la trazabilidad bidireccional entre los requerimientos desde su

fuente hasta sus requerimientos derivados y la asignación a las

funciones, a las interfaces, a los objetos, a la gente, a los procesos y a

los productos.

20 | P á g i n a



21 | P á g i n a



Control de cambios

4.2 Planificación del Proyecto PP

El objetivo de este proceso es establecer y mantener planes que definan las actividades a realizar en el proyecto, y en base a las mismas, establecer el presupuesto y los cronogramas del proyecto.

4.2.1 Definir Estrategia de desarrollo

A continuación se desglosan las metas a conseguir con este proceso, y las prácticas que se requieren para conseguir estas metas:

22 | P á g i n a



Establecer estimaciones

Desarrollar el plan del proyecto

Obtener un compromiso para realizar el plan

4.2.2 Elaborar plan de proyecto

El plan de proyecto es un documento formal que se utilizará para manejar y controlar la ejecución del proyecto. Este documento estará basado en los requisitos del proyecto y en las estimaciones anteriores. Para conseguir esta meta hay que:

Establecer el presupuesto y calendario del proyecto.

Identificar riesgos del proyecto.

Definir plan para administrar recursos.

Definir un plan para administrar los conocimientos y habilidades.

Definir un plan para involucrar a los interesados.

4.2.3 Presupuesto del Proyecto

El presupuesto del proyecto se detalla a continuación:

RECURSOS CANTIDAD COSTO

UNITARIO %

DEPRECIACION

COSTO UNITARIO

NETO

COSTO TOTAL EN

($US)

MODALIDAD ADQUIRIR

HARDWARE

COMPUTADORA 4 658 25 164.50 2,632.00 COMPRAR

IMPRESORA 1 60 25 15.00 60.00 COMPRAR

SOFTWARE

S.O. 4 199.9 50 99.95 0.00 FREE

NETBEANS 1 0 40 0.00 0.00 FREE

GESTOR DE BASE DE DATOS 1 0 40 0.00 0.00 FREE

HERRAMIENTA CASE 1 200 30 60.00 200.00 COMPRAR

PERSONAL

GESTOR 1 800 0 0.00 800.00 CONTRATAR

ANALISTA 1 600 0 0.00 600.00 CONTRATAR

DISEÑADOR 1 600 0 0.00 600.00 CONTRATAR

GESTORES DE PRUEBAS 2 500 0 0.00 1,000.00 CONTRATAR

DESARROLLADOR 4 400 0 0.00 1,600.00 CONTRATAR

INFRAESTRUCTURA

23 | P á g i n a



ENERGIA ELECTRICA 30 0 0.00 300.00 SERVICIOS

AGUA POTABLE 20 0 0.00 200.00 SERVICIOS

INTERNET 30 0 0.00 300.00 SERVICIOS

OTROS

MATERIAL DE ESCRITORIO 50 25 12.50 50.00 COMPRAR

MATERIAL DE LIMPIEZA 50 0 0.00 50.00 SERVICIOS

COSTO TOTAL MARGEN DE UTILIDAD 25% IMPUESTOS IVA

8,392.00 2,098.00 1,090.96 209.80

4.2.4 Calendario del Proyecto

A continuación se presenta un calendario de las principales tareas del proyecto. Como se ha comentado, el proceso iterativo e incremental de AUP (Proceso Unificado Ágil) está caracterizado por la realización en paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la mayoría de los artefactos son generados muy tempranamente en el proyecto pero van desarrollándose en mayor o menor grado de acuerdo a la fase e iteración del proyecto Para este proyecto se ha establecido el siguiente calendario. La fecha de aprobación indica cuándo el artefacto en cuestión tiene un estado de completitud suficiente para someterse a revisión y aprobación, pero esto no quita la posibilidad de su posterior refinamiento y cambios.

Inicio

Disciplinas / Artefactos generados o modificados

durante las Fase de AUP Comienzo Aprobación

Modelado

Modelo de Casos de Uso del Negocio Dia 1 Dia 1

Estimación de costos y riesgos Dia 1 Dia 1

Definición de riesgos Dia 1 Dia 2

Implementación

24 | P á g i n a



Prototipo de interfaz de usuario Dia 2 Dia 2

Prueba

Revisión inicial de modelos Dia 2 Dia 2


Inicia la creación del equipo Dia 3 Dia 3

Administre el riesgo Dia 3 Dia 3

Ambiente

Establecer el entorno de trabajo Dia 3 siguiente iteración / fase

Elaboración



Modelado

Modelo de Casos de Uso Dia 1 Dia 1

Especificaciones de Casos de Uso Dia 1 Dia 1

Prototipos de Interfaces de Usuario Dia 2 Dia 2

Modelo de Análisis / Diseño Dia 3 Dia 3

Implementación

Modelo de Componentes Dia 4 Dia 4

Pruebas

Validar la arquitectura Dia 4 Dia 4


Maneje el riego Dia 5 Dia 5

Actualice su plan de proyecto Dia 5 Dia 5

Ambiente

Ajuste los materiales de procesos Dia 5 siguiente iteración / fase

25 | P á g i n a



Construcción



Modelado

Abordaje del Análisis del Modelado Dia 1 Dia 1

Implementación

Implementación/Codificación Dia 1 Dia 2

Primeras pruebas Dia 1 Dia 2

Pruebas

Pruebas de software Dia 3 Dia 3

Despliegue

Desplegar el script de instalación Dia 3 Dia 3

Desplegar documentación inicial


Manejo del riesgo Dia 3 Dia 3

Actualizar su plan de proyecto Dia 3 Dia 3

Ambiente

Establecer el ambiente de capacitación Dia 3 siguiente iteración / fase

Transición

Disciplinas / Artefactos generados o modificados durante las Fase de AUP

Comienzo Aprobación

Modelado

Finalice la documentación general del sistema.

Dia 1 Dia 1

Implementación

Corrija defectos Dia 1 Dia 1

26 | P á g i n a



Pruebas

Valide el sistema Dia 1 Dia 1

Valide la documentación Dia 2 Dia 3

Finalice su modelo de pruebas Dia 3 Dia 3

Despliegue

Finalice el paquete de entrega o liberación. Dia 4 Dia 4

Capacite el personal Dia 5 Dia 5

Libere el sistema en producción. Dia 5 Dia 5


Material de Apoyo al Usuario Final Semana 2 Semana 2

Manual de Instalación Semana 2 Semana 2

Ambiente

Establezca las operaciones y / o el ambiente de soporte

Semana 2 siguiente iteración / fase

Para este proyecto se ha establecido el siguiente calendario. La fecha

de aprobación indica cuándo el artefacto en cuestión tiene un estado

de completitud suficiente para someterse a revisión y aprobación,

pero esto no quita la posibilidad de su posterior refinamiento y

cambios.


durante la Fase de Inicio Comienzo Aprobación

Documento de visión general Inicio fase de

inicio

Fin fase de

inicio

Modelo de casos de uso / requerimientos funcionales

Inicio fase de

elaboración

fin fase de

elaboración

Software con descripción del reléase actual Inicio

iteración de

fin iteración

de

27 | P á g i n a



construcción construcción

Pruebas de Aceptación Inicio fase de

transición

Fin fase de

transición

4.2.5 Identificar Riesgos del Proyecto

A partir de la fase de Inicio se mantendrá una lista de riesgos asociados

al proyecto y de las acciones establecidas como estrategia para

mitigarlos o acciones de contingencia. Esta lista será evaluada al menos

una vez en cada iteración.

Riesgo Tipo Descripción

Rotación del personal

Proyecto Personal con experiencia abandona el proyecto antes de que finalice.

Cambio de gestión

Proyecto Habrá un cambio de gestión organizacional con diferentes prioridades.

No disponibilidad de hardware

Proyecto El hardware esencial para el proyecto no será entregado a tiempo.

Cambio de requerimientos

Proyecto y producto

Habrá un cambio en el requerimiento de lo esperado.

Retrasos en la especificación

Proyecto y producto

Las especificaciones de las interfaces esenciales no estarán a tiempo.

Subestimación del tamaño

Proyecto y producto

El tamaño del proyecto se ha subestimado.

Bajo rendimiento de la herramienta case

Producto Las herramientas case estimados en el proyecto no tienen el rendimiento esperado.

Cambio de tecnología

Negocio Un producto competitivo se pone en venta antes de que sistema se complete.

Competencia del producto

Negocio La tecnología fundamental sobre la que se construirá el sistema se sustituye por una nueva.

28 | P á g i n a



Formulario de roles para responsables de riesgos

4.2.3 Elaborar plan de desarrollo

Este documento esta detallado en el apartado ANEXOS.

4.2.4 Definir Responsables por área

La autoridad y responsabilidad de la ejecución del proceso y de establecer

los roles estará a cargo del gestor del proyecto

Para la definición de responsabilidades se utilizará el formato RACI-V, que

consiste en utilizar una de las 5 siglas (R, A, C, I o V) en función de:

R: Responsible (Responsable). Encargado de ejecutar o de que se

ejecute la tarea.

A: Accountable (Aprobador). Responsable de aprobar y cerrar una

tarea.

C: Consult (Consultado). Persona a la que se debe consultar y que

debe proporcionar información necesaria para la ejecución de la

tarea.

I: Inform (Informado). Persona a la que se debe informar del resultado

o de la completitud de la ejecución de la tarea.

29 | P á g i n a



V: Verify (Verificador). Persona que debe validar o verificar la

ejecución de una tarea (normalmente sus productos) generalmente

como paso previo a la aprobación formal por parte del aprobador. Personas

Actividades

Joshep Lujan Eliana

Mancilla

Heydi Barja Patricia

Juchani

Betty

Chaca

Verificar cumplimiento de

actividades

R V

Desarrollo del plan del

proyecto

C R V I

Actividades de

Aseguramiento de calidad

C A R I

Administración de la

configuración.

C A V R

Requerimientos, análisis,

diseño, codificación,

testing, y documentación, e

informes técnicos.

C A V I R

4.2.5 Informe de situación del proyecto

Se realizaran reportes para indicar el estado actual del proyecto. Esta información quedara registrada en el formulario informe de avance. Favor remitirse a los anexos para verificar formulario.

4.3 Monitoreo y Control de proyecto PMC

El propósito del monitoreo y control del proyecto es proporcionar una comprensión del avance del proyecto para que se puedan tomar las acciones correctivas apropiadas, cuando el rendimiento del proyecto se desvíe significativamente del plan.

Un plan de proyecto documentado es la base para el monitoreo de las actividades, la comunicación del estado del proyecto y la ejecución de acciones correctivas. El avance se determina principalmente comparando los atributos de los productos de trabajo y de las tareas, el esfuerzo, el coste y el calendario reales, con el plan en los hitos establecidos dentro del calendario del proyecto o de la estructura de descomposición del trabajo. El conocimiento apropiado del avance del proyecto permite que las acciones correctivas sean llevadas a cabo de manera oportuna cuando el avance se desvía significativamente del plan. Una desviación es significativa, sí, cuando se deja sin resolver, impide al proyecto cumplir sus objetivos.

4.3.1. Responsables

Administrador del proyecto

Equipo de revisiones

30 | P á g i n a



Administrador de la configuración

4.3.2. Entradas

Plan del proyecto.

Plantilla de monitoreo y control del proyecto

Calendario del proyecto.

Lista de compromisos identificados en el plan del proyecto.

Plantilla de monitoreo y control de compromisos.

Plan de administración de riesgos.

Plantilla de monitoreo y control de riesgos.

Plantilla de monitoreo y control de los datos.

Lista de stakeholders que tendrán participación dentro del proyecto.

Plantilla de monitoreo y control de la participación de los stakeholders.

Plantilla de monitoreo y control del avance del proyecto.

Plantilla de monitoreo y control de hitos.

Plantilla de monitoreo y control de acciones correctivas

Productos de trabajo

Elementos de configuración

Documentos de procesos que generen el producto de trabajo.

Documentos de contratos o compromisos pertinentes.

4.3.3. Registro de actividades

Monitorear los valores reales de los parámetros de planificación del proyecto frente al plan del proyecto.

Los parámetros de la planificación del proyecto constituyen indicadores típicos del avance y del rendimiento del proyecto, e incluyen atributos de los productos de trabajo y tareas, coste, esfuerzo y calendario. Los atributos de los productos de trabajo y de las tareas incluyen elementos tales como tamaño, complejidad, peso, forma, ajuste o función.

31 | P á g i n a



El monitoreo normalmente involucra la medición de los valores reales de los parámetros de la planificación del proyecto, la comparación de los valores reales con los estimados en el plan del proyecto, y la identificación de desviaciones significativas. Registrar los valores reales de los parámetros de planificación del proyecto incluye el registro de la información contextual asociada que ayuda a comprender las medidas. En la segunda meta específica y sus prácticas específicas de este área de proceso, se maneja un análisis del impacto que tienen las desviaciones significativas para determinar qué acciones correctivas tomar.

4.3.3.1 Comparar el avance actual del proyecto con el plan o calendario del mismo.

El monitoreo del progreso del proyecto incluye lo siguiente:

Establecer en el plan de proyecto fechas para medir el porcentaje completado de hitos y actividades.

Comparar el porcentaje actual de la realización de los hitos y actividades con el calendario documentado en el plan de proyecto según las fechas establecidas en el plan del proyecto.

Identificar desviaciones significativas de las estimaciones calendarizadas en el plan del proyecto. Las desviaciones significativas serán aquellas que de no ser corregidas garanticen que no se cumplirá con alguna fecha de entrega o finalización de actividad o poder alcanzar un hito establecidos en el plan del proyecto.

4.3.3.2. Monitorear el costo del proyecto y el esfuerzo utilizado.

El monitoreo del costo y esfuerzo incluye lo siguiente:

Establecer en el plan del proyecto las fechas en las cuales se medirá el esfuerzo actual y el dinero usado en el personal asignado.

Comparar el esfuerzo, los costes, el personal y la formación reales con las estimaciones y el presupuesto documentados en el plan de proyecto.

Identificar las desviaciones significativas del presupuesto en el plan de proyecto, es decir que se esté usando significativamente más o menos capital de acuerdo a lo planeado.

4.3.3.3. Monitorear los atributos de los productos de trabajo y de las tareas.

Para información sobre los atributos de los productos de trabajo y de las tareas, consúltese el área de proceso de Planificación de proyecto.

32 | P á g i n a



El monitoreo de los atributos de los productos de trabajo y de las tareas incluye:

Establecer en el plan de proyecto las fechas en las cuales se medirán los atributos reales de los productos de trabajo y de las tareas (y los cambios a los atributos), tales como el tamaño o la complejidad.

Comparar los atributos reales de los productos de trabajo y de las tareas (y los cambios a los atributos) con las estimaciones documentadas en el plan del proyecto.

Identificar las desviaciones significativas de las estimaciones en el plan del proyecto.

4.3.3.4. Monitorear los recursos proporcionados y los usados.

Para información sobre los recursos planificados, consúltese el área de proceso de Planificación del proyecto.

Algunos ejemplos de recursos son:

Instalaciones físicas.

Computadoras, periféricos y software usados en el diseño, fabricación, pruebas y operación.

Redes

Entornos de seguridad.

Personal del proyecto

Procesos.

4.3.3.5. Monitorear el conocimiento y las habilidades del personal del proyecto.

Para información sobre la planificación del conocimiento y de las habilidades necesarias para la ejecución del proyecto, consúltese el área de proceso de Planificación de proyecto.

El monitoreo del conocimiento y de las habilidades del personal del proyecto incluye:

Periódicamente medir según lo establecido en el plan del proyecto la adquisición del conocimiento y habilidades del personal del proyecto.

Comparar según lo establecido en el plan del proyecto el entrenamiento actual obtenido con el documentado en el plan de proyecto.

33 | P á g i n a



Identificar desviaciones significantes de las estimadas en el plan de proyecto.

Todas las tareas mencionadas anteriormente serán documentadas en el documento de monitoreo del proyecto.

Documentar las desviaciones significativas en los parámetros de la planificación del proyecto.

4.3.4. Evaluación y ajuste del plan de proyecto

Determinar y documentar en la plantilla de monitoreo y control de acciones correctivas las acciones apropiadas para corregir desviaciones obtenidas de lo planeado con respecto a los resultados de las acciones correctivas.

Las lecciones aprendidas como resultado de realizar acciones correctivas pueden ser entradas para el proceso de planeación y administración de riesgos.

Una vez realizadas todas estas medidas y con las respectivas

autorizaciones se realizaran la actualización del plan de proyecto

corrigiendo todas las desviaciones y asumiendo e implementando todas las

acciones correctivas que se han determinado y aprobado durante este

proceso.

4.4 Gestión de Proveedores

El presente documento ilustra el proceso a ser seguido con el objeto de

desarrollar y sostener las capacidades de la organización para seleccionar

proveedores calificados y manejarlos en forma eficiente, de manera tal de

cumplir con los objetivos planteados en el proyecto.

4.4.1 Planifica y Elaborar Adquisición

Propósito: En principio cubre la adquisición de productos o servicios que

serán entregados al cliente o que se requieren para su desarrollo. Elaborar

el pedido de tercerización, estableciendo los criterios de evaluación de los

productos, servicios y proveedores postulados.

Entradas: SRS, Criterio de evaluación del producto, Template de Pedido de

Cotización, Template de Matriz de Evaluación.

Salidas: Pedido de Cotización, Criterio de evaluación del producto, Matriz de

Evaluación | Actividad | Descripción |

Responsable

34 | P á g i n a



Elaborar Pedido de

Cotización

El PM analiza el proyecto, a partir de los

requerimientos especificados en el SRS, elabora el

Pedido de Cotización, especificando:

Productos a entregar y servicios a prestar por el proveedor.

Requerimientos funcionales y técnicos del producto o servicio a contratar.

Criterios de Aceptación de los productos y servicios.

Obligaciones a cumplir por ambas partes. Mecanismos de control y seguimiento del

proveedor. Acción a tomar por incumplimientos en la

calidad de los productos y los plazos establecidos (multas, cancelaciones).

Condiciones de confidencialidad de información.

Propiedad intelectual de los productos o en su defecto, la correspondiente autorización para poder comercializar los mismos.

Cuestiones formales de presentación (lugar, fecha límite, formato, etc.).

Requerimientos no técnicos (términos contractuales, costos, tiempos, etc.).

Adjuntar

Documentación

Complementaria

El PM obtiene la documentación complementaria

necesaria para adjuntar al Pedido de Cotización. Esta

depende del motivo de la contratación, pero puede

contener entre otras: * SRS

Normas y Estándares de Diseño y Programación.

Templates de documentación a ser presentada.

Completar Matriz

de Evaluación

El PM completa la Matriz de Evaluación, especificando

los criterios (o factores) sobre los cuales se basará la

evaluación de las propuestas, ponderando los mismos

según su importancia en el proyecto. Los factores que

35 | P á g i n a



siempre se evaluarán en una propuesta son: Precio y

Servicio Post-Venta o Mantenimiento, garantía y

fechas de entrega.

El PM de acuerdo a los documentos decide la alternativa más conveniente,

establece y documenta el criterio de evaluación del producto a adquirir.

4.4.2 Seleccionar Proveedor

Propósito: Refinar la evaluación de los proveedores y productos candidatos.

Elegir la solución y el proveedor definitivo (definir requerimientos de

personalización, si corresponde).

Entradas: Propuestas del Proveedores, Matriz de Evaluación

Salidas: SDP [Anexo de Proveedores] | Actividad | Descripción |

Responsable |

Seleccionar al

Proveedor

Cuando se termina la fecha de presentación de las

propuestas y han sido recibidas todas, se procede a

hacer la evaluación.

El PM analiza cada Propuesta de Proveedor a la que se

envió el Pedido de Cotización, y refina la evaluación

sobre los proveedores y/o productos candidatos.

Posteriormente, el PM refiere a la Matriz de Evaluación

para tomar la decisión de a quién contratar.

Completar SDP

con Información

de Proveedor

El PM completa el Anexo Proveedores del Plan de

Proyecto, donde se especifican los mecanismos de

control, los criterios de aceptación condiciones y

supuestos que enmarcarán la relación con el proveedor

durante todo le ciclo de vida del proyecto.

Acordar detalles

con Proveedor

El PM negocia con el Proveedor elegido, si es necesario,

cuestiones técnicas y no técnicas pendientes de

resolución antes de la firma del contrato (por ejemplo,

complementar información pendiente, ajustar

compromisos de fechas, costo del proyecto, cronograma

de pagos).

4.4.4 Contratar Proveedores

Propósito: Redactar y firmar el contrato entre ambas partes.

Entradas: Template de Contrato, Propuesta del Proveedor, SDP,

Cronograma, Lista de Riesgos

36 | P á g i n a



Salidas: SDP [Actualizado], Contrato [Firmado], Cronograma [Actualizado],

Lista de Riesgos [Actualizada] | Actividad | Descripción | Responsable |

Armar el

Contrato

El PM, si considera necesario, ajusta la propuesta del

proveedor plasmándolo en un contrato o documento que

sirva a tal efecto.

Revisar y

Aprobar el

Contrato

El PM revisa con la Gerencia y el Área Comercial dicho

documento antes de su aprobación. Pueden intervenir,

cuando se lo considere necesario, el Gerente General o

algún otro responsable de la contratación.

El Proveedor y la empresa aprueban el documento.

Ajustar

Artefactos de

Planificación

El PM ajusta el SDP (Roles y Responsabilidades del

Proveedor, Cronograma) y el Anexo Proveedores, si fuera

necesario.

El PM actualiza la Lista de Riesgos identificando aquellos

relacionados con la tercerización acordada.

4.4.5 Realizar Control y Seguimiento

Propósito: Realizar el control del progreso, los resultados y el desempeño

del proveedor. Controlar el cumplimiento de los compromisos acordados en

el Contrato, tomando las acciones preventivas y correctivas necesarias para

cumplir con los objetivos.

Entradas: SDP, Cronograma, Lista de Riesgos

Salidas: Cronograma [Actualizado], Lista de Riesgos [Actualizada] |

Actividad | Descripción | Responsable |

Organizar y Controlar

Actividades del

Proveedor

El PM organiza las actividades en conjunto a

realizar por el Proveedor y su equipo de proyecto.

El PM realiza periódicamente el control de las

actividades del proveedor, a través de las

siguientes actividades: * Control del cumplimiento

de las fechas e hitos definidos en el cronograma

del proyecto.

Control del cumplimiento del contrato. Control del cumplimiento de las

condiciones de aceptación de los productos entregados o servicios brindados.

Control de pedidos de modificaciones solicitadas y pendientes de realización por

37 | P á g i n a



el proveedor.

Reportar

Incumplimientos

El PM informa a la Gerencia correspondiente los

incumplimientos incurridos por el proveedor, y le

solicita que tome las acciones pertinentes.

Identificar y Mitigar

Riesgos

El PM administra los riesgos relacionados con el

proveedor, detectando la aparición de nuevos

riesgos, evaluando los ya considerados y

tomando las acciones preventivas y correctivas

pertinentes.

PM

4.4.6 Aceptar Producto Adquirido

Propósito: Dar conformidad de los productos/servicios entregados y de la

participación del proveedor en el proyecto.

Entradas: Criterios de Aceptación

Salidas: Minuta de Aceptación del Cliente | Actividad | Descripción |

Responsable |

Verificar

Entrega del

Proveedor

Ante la entrega de un producto o subproducto

por parte del Proveedor, se realizan las

siguientes pruebas:

a) El Analista Funcional realiza las

revisiones de los artefactos asociados al

producto entregado.

b) El Tester realiza el testing del producto

entregado.

c) El PM realiza un testing de aceptación,

verificando que el producto cumpla con los

requerimientos solicitados y con las

condiciones de aceptación definidas.

PM /

Analista

Funcional /

Tester

Aprobación

del Cliente

En aquellos casos en que no agregara valor al

producto final a entregar al Cliente mediante la

modificación, agregado de software, o

integración del software provisto con otro, el

PM obtiene la conformidad del producto

recibido por parte del Cliente.

PM

4.4.7 Documentos de aceptación o rechazo de productos o servicios

El proceso de aseguramiento de la calidad de proceso y producto evaluará

objetivamente los procesos, los productos de trabajo y los servicios

ejecutados frente a las descripciones de proceso, los estándares y los

38 | P á g i n a



procedimientos aplicables. Identificar y documentar las inconformidades.

Proporcionar retroalimentación al equipo del proyecto y a los gerentes

sobre los resultados de las actividades de aseguramiento de la calidad.

Asegurar que sean tratadas las inconformidades.

4.5 Gestión de la Configuración

El proceso de Gestión de la Configuración, controlara la integridad, que es

la corrección y completitud de todos los elementos de trabajo que sean el

resultado de alguno de los procesos de desarrollo del sistema, es decir cada

elemento que se encuentre bajo el resguardo de la gestión no solo se

encuentre ahí por simple mecanización, sino que se asegure que dicho

elemento cumple con lo establecido en los lineamientos de nombramiento,

así como permitir identificar que dicho elemento cumple con su objetivo

dentro del sistema (p. e. Un código fuente que se encuentre nombrado

adecuadamente y que realice lo que en su especificación dicta y que al

mismo tiempo se puede encontrar a partir de él al requisito del cual fue

origen).

Lo anterior con el objetivo de no solo tener un control adecuado de los

elementos, sino también un histórico de cambios y versiones en caso de

contingencias y errores de acoplamiento o de cualquier otra índole

4.5.1 Plan de Gestión de la Configuración del Software

Describimos todas las actividades de Gestión de Configuración y Cambios que serán realizadas durante todo el ciclo de vida del proyecto. Brindando planificaciones detalladas de las actividades, responsabilidades asignadas, recursos necesarios que incluyen personal, herramientas y equipamiento.

El Plan de Gestión de Configuración contiene información que puede ser cubierta a una mayor o menor magnitud por otros planes. Los enfoques siguientes pueden ser usados para manejar esta potencial coincidencia:

Hacer referencias al contenido relacionado que se encuentre en otro plan.

Proveer la visión general en otro plan, suministrar los detalles más significativos en este plan y hacer referencias necesarias desde los otros planes hacia este plan.

Asegurar que las secciones de este artefacto cubran solamente las áreas que no han sido cubiertas anteriormente en otro lugar.

4.5.2 Definiciones, Acronimos y Abreviaturas

Línea Base: Es una especificación o producto de trabajo que se ha revisado

formalmente y sobre los que se ha llegado a un acuerdo, es de la versión 0 y

que de ahí en adelante sirve como base para un desarrollo posterior y que

39 | P á g i n a



puede cambiarse solamente a través de procedimientos formales de control

de cambios.

Configuration Control Board o Junta de Control de Cambios: Es el conjunto

de personas que se encargan de analizar peticiones de cambio y las cuales

designan al gestor y a todos los involucrados dentro del proceso de gestión

de la configuración.

Cuestión: Una solicitud que alguien ha presentado al sistema de control de

cambio que describe un problema de software, una mejora solicitada, una

propuesta de cambio en los requisitos de un producto en fase de desarrollo,

o un nuevo proyecto que se propone.

Stakeholder: Persona que directa o indirectamente se ve afectada por el

sistema y que puede afectar el proyecto.

CCB: Configuration Control Board

CM: Control Management

GCS: Gestión de la Configuración del Software

ECS: Elementos de la Configuración de Software

4.5.3 Roles

CCB.- Junta de Control de Cambios que decide aprobar o rechazar un

cambio y que designa los otros roles del proceso integrada por 2

personas del equipo.

Originador de cambios.- Es aquella persona que haya realizado la

petición de cambio ante la CCB.

Gestor de la Configuración de Software.- Es el encargo de mantener el

control de los ECS.

Líder de Proyecto.- Es el encargado de administrar y controlar todo lo

referente al proyecto al cual es asignado.

4.5.4 Guia de Proceso en la Gestion de Configuracion

4.5.4.1 Entradas

Las entradas del proceso son las siguientes:

Planes, calendarios, reportes y revisiones del Proyecto

Especificaciones, requerimientos, diseño, código y documentación

del Proyecto

40 | P á g i n a



Procesos del proyecto

4.5.4.2 Proceso

Para llevar a cabo este proceso se tienen los siguientes objetivos

Objetivo 1. Establecer líneas base.

Para cumplir este objetivo se tienen las siguientes prácticas:

Identificar elementos de configuración.

Establecer un sistema de administración de configuración.

Crear o liberar las líneas base.

Hemos definido como línea base en nuestro proyecto la versión 0

Objetivo 2. Seguir y controlar los cambios.


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.


Realizar auditorías de configuración.

Para cumplir la auditoria utilizamos los formularios y las plantillas que hemos definido

4.5.5 Planeacion

4.5.5.1 Proposito

Realizar la planeación de cada una de las tareas que deben de realizarse

para llevar a cabo el proceso de gestión de la configuración.

4.5.6 Responsables

Administrador del Proyecto

4.5.6.1 Entradas

Tener un Sistema en desarrollo.

41 | P á g i n a



Todos los involucrados en el desarrollo del sistema deben de

estar informados que la planeación del proceso será llevada a

cabo.

Una agenda de trabajo.

Un equipo de trabajo informado.

4.5.6.2 Actividades

El administrador de proyectos, con base al conjunto de lineamientos

para la selección de la CCB, nombrara a las personas que formaran

parte de la misma. (Ver Apéndice A11).

La nueva CCB, deberá asignar al gestor de la configuración.

El gestor de la configuración deberá determinar el tiempo estimado

que le llevara identificar todos los elementos de Gestión con base a

un conjunto coherente de requisitos.

Por otra parte la CCB deberá determinar el tiempo estimado que le

tomara

la selección del sistema de administración.

Por último y con base al calendario del proyecto, el gestor en

conjunto con la CCB, deberán determinar los días para las auditorias

de la gestión

4.5.2.3 Salidas

Una nueva CCB.

Un Gestor de la configuración.

Un Plan para la Gestión de la configuración.

4.5.3 Identificar Elementos de la Configuración

4.5.3.1 Propósito

Identificar los ECS, permitiendo tener un control de todos aquellos

productos de trabajo que deben de ser considerados como ECS dentro del

sistema.

4.5.3.2 Responsables

Gestor de la Configuración de Software

4.5.3.3 Criterio de Entrada


Tener un conjunto coherente de requisitos.

42 | P á g i n a



4.5.3.4 Entradas

La EDT del sistema.

El plan de Gestión de la Configuración

4.5.3.5 Actividades

El gestor de la configuración de software seleccionará los elementos

de configuración y productos de trabajo que los componen sobre la

base de criterios documentados.(Ver Apéndice GC1)

El gestor de la configuración de software asignará identificadores

únicos a los elementos de configuración.(Ver Apéndice GC2)

El gestor de la configuración de software agregará los elementos a las

plantillas de registro de elementos de configuración(Ver Apéndice

GC4)

El gestor de la configuración de software identificará el momento

adecuado cuando un elemento de configuración de software deberá

ser colocado bajo administración en base a los criterios

establecidos.(Ver Apéndice GC3)

Al finalizar la practica el Gestor de la configuración deberá colocar los

tipos de ECS que haya identificado dentro del plan de Gestión de la

Configuración

4.5.3.6 Salidas

Tipos de ECS identificados. (Ver Apéndice GC4)

Plan de gestión de configuración Actualizando con los tipos de ECS

4.5.7 Establecer un Sistema de Administración de Configuración

4.5.7.1 Propósito

Permitir establecer un sistema en el cual serán colocados todos los ECS

con el propósito de ser un punto de acceso para el Gestor de la

Configuración del Software e interesados para poder liberar o ingresar un

ECS del sistema en desarrollo con el fin de ser modificado o utilizado.


Gestor de la Configuración de Software.

CCB.

43 | P á g i n a



4.5.7.3 Criterio de Entrada

Tener un Sistema en desarrollo

4.5.7.4 Entradas

Tipos de ECS identificados (Ver Apéndice GC4)

4.5.7.5 Actividades

El gestor de la configuración de software definirá los puntos que deberá

cumplir la herramienta, identificando las características más

significativas para la empresa, por ejemplo, la capacidad de acceso

mediante web es una característica importante, decida si quiere

continuar almacenando los elementos de configuración en documentos

o prefiere almacenarlos en una base de datos.

Así mismo el Gestor de la Configuración de Software deberá de

establecer la estructura de almacenamiento con la cual contara el

sistema. (Ver Apéndice GC12)

El gestor de la configuración de software deberá listar de 10 a 15

factores que pueden influenciar en su decisión, incluyendo factores

subjetivos como adaptabilidad (en la empresa), eficiencia, y efectividad

de la interfaz de usuario. El costo debe ser un factor, pero evalué las

herramientas sin considerarlo en una primera instancia tome en

consideración los siguientes puntos (Ver apéndice GC5).

El Gestor de la Configuración de Software distribuirá 100 puntos entre

los factores listados anteriormente, y asignará más puntos a los

factores más importantes.

La CCB obtendrá información acerca de las herramientas con base en

opiniones en foros, revistas especializadas, páginas web, etc.

La CCB obtendrá una versión de prueba para evaluar los factores

subjetivos.

La CCB evaluará la herramienta en un proyecto real, y no sólo el

proyecto tutorial del producto.

La CCB asignará las calificaciones pertinentes.

El Gestor de la Configuración de Software tomará una decisión sobre la

elección de la herramienta y llenará el siguiente formulario. (Ver

Apéndice GC6).

44 | P á g i n a



Por último el Gestor de la Configuración de Software deberá informar a

todos los involucrados en el proyecto sobre el sistema que ha sido

seleccionado para la gestión de la configuración.

4.5.7.6 Salidas

Sistema de gestión de configuración con productos de trabajo

controlados. (Ver Apéndice GC6).

4.5.8 Crear o Liberar las líneas Bases

4.5.8.1 Propósito

Permitir el control de las líneas Base de los ECS que son utilizados dentro

del sistema, lo cual permitirá comprender el estado actual de cada uno de

los elementos, así como poder tener un control histórico de las líneas base

para su uso en caso de conflictos.

4.5.8.1.1 Responsables


CCB

4.5.8.1.2 Criterios de entrada


Haber seleccionado un sistema para la gestión de la

configuración.


estar informados sobre el sistema de gestión de la configuración.

4.5.8.1.3 Entradas

ECS identificados. (Ver Apéndice A4)

Sistema de gestión de configuración con productos de trabajo

controlados. (Ver Apéndice GC6).

4.5.8.2 Actividades

Cualquier persona interesada en la creación o liberación de líneas

base debe obtener la autorización de la CCB, siguiendo el

45 | P á g i n a



procedimiento establecido y haciendo una petición a través del

formato correspondiente.(Ver Apéndice A7)(Ver Apéndice A8)

Si la petición de liberación fue aprobada por el CCB, el Gestor de la

Configuración de Software deberá de liberar los elementos de línea

base que se le soliciten y deberá de registrar la salida de dichos

elementos de la línea base en el formato de historial de emisiones de

líneas base. (Ver Apéndice A13)

El CCB informará qué el conjunto actual de líneas base esté

disponible a los interesados.

4.5.8.3 . Salidas

Líneas base creadas o liberadas.

4.5.9 Seguir las peticiones de Cambios

4.5.9.1.1 Propósito

El seguimiento de las peticiones de cambio permite tener una idea del

impacto y del costo que tendrá un cambio solicitado hacía algún ECS,

además de conocer el historial de cambios que se han realizado sobre algún

ECS.

4.5.9.1.2 Responsables


Evaluador.

Modificador.

Verificador.

4.5.9.1.3 Criterios de entrada


Tener liberadas líneas base.

4.5.9.1.4 Entradas

Solicitud de Cambio(Ver Apéndice A9)

4.5.9.1.5 Actividades

El interesado en el cambio envía su solicitud de cambio a la CCB.

El CCB asignará un evaluador para realizar el análisis de impacto

sobre la solicitud de cambio.

El evaluador dará su resultado al CCB, esta última tomara la decisión

de aceptar o rechazar la petición.

46 | P á g i n a



En caso de que la solicitud fuera aceptada, al CCB asignará un

modificador, el cual realizara el cambio solicitado.

Con forme a lo especificado en la Práctica de Liberación de Líneas

Base, el modificador realizara la petición de los elementos de línea

base para su modificación.

Una vez realizados los cambios, el CCB nombrara un verificador quien

realizara la inspección de las modificaciones del modificador,

mediante técnicas como pruebas de regresión y caminatas.

Una vez terminada la inspección, el verificador dará su reporte a la

CCB.

Con base al reporte del verificador, la CCB podrá optar por cancelar la

modificación y notificar al modificador los detalles encontrados

durante la verificación, así mismo si la CCB nota que el cambio es

más grande de lo previsto puede optar por cancelar la solicitud de

cambio, tras lo cual el originador de la misma deberá de ser

notificado sobre el estado de su solicitud.

Después de que la CCB apruebe el cambio realizado con base al

reporte del verificador, el modificador deberá entregar los elementos

de línea base que le fueron liberados ya modificados y el Gestor de la

Configuración de Software deberá colocar en el formato de historial

de emisiones de líneas base, los datos de ingreso de dichos

elementos de nuevo al sistema de gestión de la configuración.

4.5.9.2 Salidas

Peticiones de Cambio. (Ver Apéndice A9)

Líneas Base Actualizadas si es que el cambio fue aprobado.

Actualización de los historiales de peticiones del sistema de

gestión de la configuración, si es que la petición procede.

4.5.10 Realizar Auditorías de Configuración

4.5.10.1.1 Propósitos

Permitir identificar que tan consistente es la información que se encuentra

en los historiales de la Gestión de la Configuración del Software, así como

mostrar en qué punto del tiempo se suscitaron las inconsistencias.



Evaluador

4.5.10.3 Criterios de entrada

Tener un Sistema en desarrollo

47 | P á g i n a




estar informados

4.5.10.4 Entradas

Solicitud de auditoría(Ver Apéndice A12)

4.5.10.5 Actividades

El gestor de la configuración de software realiza una petición para

realizar una auditoría sobre los ECS

El evaluador evaluara la integridad de las líneas de base.

El evaluador confirmara que la gestión de configuración de los

registros identifican correctamente los elementos de configuración,

revisa la estructura y la integridad de los ECS, esto a través de un

checklist.(Ver Apéndice A13)

El evaluador se encargara de dar seguimiento a los puntos de acción

desde la auditoría al cierre.

4.5.10.6 Salidas

Resultados de la auditoria de configuración. (Ver Apéndice A13)

4.5.11 Verificaciones

4.5.11.1 Propósito

Las verificaciones permitirán al Gestor de la Configuración de Software el

ver cuál es el estado actual de la gestión y detectar de manera pronta

cualquier inconsistencia o detalle sobre saliente durante el proceso.

4.5.11.2 Responsable


4.5.11.3 Criterios de entrada


Todos los involucrados en el desarrollo del sistema deben de estar

informados.

4.5.11.4 Entradas

Sistema de Gestión con elementos dentro de él.

4.5.11.5 Actividades

El gestor deberá revisar los historiales generados hasta la fecha por

EGC.

48 | P á g i n a



El gestor deberá identificar a los elementos que no sufrieron cambio

alguno hasta la fecha.

El gestor deberá de realizar pruebas de acoplamiento y regresión de

los EGC que hayan tenido una incidencia de peticiones mayores a 2

durante un mes.

El gestor deberá de colocar todas las observaciones encontradas en

el registro de Observaciones de Revisión. (Ver Apéndice GC14)

Posterior a ello, el gestor deberá notificar a los responsables de los

EGC que se encuentren en estado corrupto, es decir que no son

consistentes con sus requisitos origen o que no realizan la función

que describen.

Una vez hecho esto el Gestor notificara de esto a la CCB pidiendo la

autorización de regresar a la versión inmediata estable y consistente

de los EGC que se encuentren corruptos.

Si el CCB acepta dicho cambio se llevara a cabo y se notificara a

todos aquellos que tengan en uso la versión del EGC corrupto que lo

actualicen a la versión actual mediante la práctica de liberación de

líneas base.

4.5.11.6 Salidas

Reportes de verificación del gestor.

Un sistema de gestión estable.

4.5.11.7 Métricas

Número de Inconsistencias encontradas en auditorias por

EGS.

Número de Solicitudes de liberación por EGS

4.6 Plan de aseguramiento de la calidad

El proceso de aseguramiento de la calidad de proceso y producto evaluará

objetivamente los procesos, los productos de trabajo y los servicios

ejecutados frente a las descripciones de proceso, los estándares y los

procedimientos aplicables. Identificar y documentar las inconformidades.

Proporcionar retroalimentación al equipo del proyecto y a los gerentes

sobre los resultados de las actividades de aseguramiento de la calidad.

Asegurar que sean tratadas las inconformidades.

Documentos que se analizan durante todo este proceso:

Estándares de la organización: políticas de calidad, lineamientos

de la organización.

49 | P á g i n a



Documentación producida a lo largo del proyecto tales como

documentación de requisitos, planes de pruebas etc.

Productos generados a lo largo del proyecto.

Plantillas que serán empleadas para las evaluaciones de éste

proceso.

4.6.1. Responsables

Líder del proyecto.

Encargado de PPQA.

Cualquier participante del proyecto.

4.6.2. Proceso

4.6.2.1. Proporcionar una Visión Objetiva

Para cumplir este objetivo se tienen las siguientes prácticas, éstas se

resumen a continuación:

Comunicar y asegurar la resolución de las inconformidades.

Establecer registros

4.6.2.2. Planificación de Proceso

El propósito de la planificación es establecer el nivel de detalle que se

tendrá en la ejecución del aseguramiento de la calidad de procesos y

productos.

4.6.2.2.1. Criterio de Entrada

Se han identificado los estándares, procesos, herramientas y producto que

se van a evaluar a lo largo del desarrollo del proyecto.

4.6.2.2.2. Recursos

Los recursos para realizar el proceso serán:

Las plantillas provistas por el encargado de PPQA para

evaluar los procesos y los productos.

Los documentos tales como plantillas, estándares y guías

para realizar los procesos, productos o servicios que serán

evaluados.

Material de oficina.

50 | P á g i n a



4.6.2.2.2.1. Responsables

La autoridad y responsabilidad de la ejecución del proceso estará a cargo

de:

Ing. Heydi Anel Barja Bravo.

4.6.2.2.3. Practicas

Teniendo como criterio de documentación tales como los estándares, las

especificaciones de los procesos, los planes etc., y conforme se vaya

desarrollando el proyecto, Evaluar los procesos que se ejecuten al igual que

los productos que generen se llevarán a cabo las siguientes actividades:

EVALUAR OBJETIVAMENTE LOS PROCESOS.

Verificar que los procesos cumplen las condiciones

establecidas en el apéndice A1. Esto para asegurar que la

aplicación del proceso sigue los estándares y

documentaciones establecidas.

Documentar las inconformidades y las acciones para

corregirlas llenando los campos descritos en el apéndice A2.

De ser necesario modificar los documentos de la línea base

para corregir las posibles fuentes de inconformidades.

EVALUAR OBJETIVAMENTE LOS PROCESOS DE TRABAJO Y LOS

SERVICIOS.

Verificar que los productos o servicios cumplen las condiciones

establecidas en el apéndice A3. Esto es para asegurar que en la

generación del producto o servicio se siguieron los estándares,

guías, plantillas y demás documentación establecida, también

para asegurar que el producto cumple con las especificaciones

del cliente antes de llegar a sus manos.

Documentar las inconformidades y las acciones para

corregirlas llenando los campos descritos en el apéndice A2.

De ser necesario modificar los documentos de la línea base

para corregir las posibles fuentes de inconformidades

COMUNICAR Y ASEGURAR LA RESOLUCION DE LAS

INCONFORMIDADES

Debe contarse tanto con los reportes de inconformidades del

apéndice A2 como con las plantillas de seguimiento del

apéndice A4 para contar con un control y seguimiento de las

mismas.

51 | P á g i n a



Resolver las inconformidades con los responsables

establecidos y en caso de no resolverlas escalar la

responsabilidad al siguiente en la jerarquía de mando.

ESTABLECER REGISTROS.

Se crean registros de las actividades de aseguramiento de la

calidad en los procesos o áreas y se lleva un seguimiento de su

estado mediante la plantilla de actividades de aseguramiento de

la calidad en el apéndice A5.

4.6.2.2.4. Verificación

El grupo de aseguramiento de la calidad debe verificar que los

procedimientos, formatos y del proceso se llenan según las

instrucciones.

Si algún elemento del proceso necesita modificarse ya sea para la

mejora o adaptación, esta modificación deberá especificarse en el

control de la versión del presente documento.

Las verificaciones por parte de las inconformidades deben ser

revisadas por el administrador y cualquier miembro del equipo que se

vea involucrado con dicha inconformidad.

4.6.2.2.5. Métricas

Las siguientes métricas buscan la mejora del proceso, son las siguientes:

Número de inconformidades detectadas por evaluación.

Frecuencia de la evaluación de productos o procesos.

Tiempo de resolución de la inconformidad

6 MADUREZ DEL PROCESO DE SOFTWARE

6.1 Scampin

CMMI-2: PA1: - Gestión de requisitos #

NA # ? Valor

P1

SP 1.1 Se consigue la comprensión de los requisitos

9,00 9 SP 1.2 Se obtiene un compromiso basado en los requisitos

9,00 9

SP 1.3 Se gestionan las modificaciones de requisitos

8,00 8 SP 1.4 Se mantiene la trazabilidad bi-direccional de los requisitos

8,00 8

SP 1.5 Se identifican las inconsistencias entre el trabajo del proyecto y los requisitos

7,00 7

52 | P á g i n a



GP 2.1 (CO 1) La organización tiene establecida una política

7,00 7

GP 2.2 (AB 1) Se planifica este proceso

8,00 8 GP 2.3 (AB 2) Se le proporcionan los recursos adecuados

7,00 7

GP 2.4 (AB 3) Tiene asignadas las responsabilidades

8,00 8 GP 2.5 (AB 4) Las personas implicadas reciben formación

8,00 8

GP 2.6 (DI 1) Se gestiona la configuración de los elementos de este proceso

8,00 8

GP 2.7 (DI 2) Se identifica a los actores importantes para el proceso

7,00 7

GP 2.8 (DI 3) Se monitoriza y controla el proceso

8,00 8 GP 2.9 (VE 1) Se evalúa objetivamente su cumplimiento

8,00 8

GP 2.10 (VE2) Se revisa el proceso con los directivos responsables

8,00 8

GP 3.1 Está establecido como proceso definido de la organización (*)

9,00 9

GP 3.2 Se obtiene información para su mejora (*)

9,00 9

Total 7,87

CMMI-2 - PA2: Planificación de proyecto #

NA # ? Valor

P1

SP 1.1 Se estima el alcance del proyecto (relación de tareas)

9,00 9

SP 1.2 Se realizan estimaciones de los productos de trabajo y atributos de las tareas

8,00 8

SP 1.3 Se define el ciclo de vida del proyecto (fases)

9,00 9 SP 1.4 Se realizan estimaciones de esfuerzo y coste

8,00 8

SP 2.1 Se establece el presupuesto y calendario del proyecto

6,00 6

SP 2.2 Se identifican los riesgos del proyecto

7,00 7 SP 2.3 Se define un plan para administrar la información

7,00 7

SP 2.4 Se define un plan para administrar los recursos

8,00 8 SP 2.5 Se define un plan para administrar los recursos y las habilidades

8,00 8

SP 2.6 Se define un plan para involucrar a los interesados

9,00 9

SP 2.7 Se establece el plan general de proyecto

8,00 8 SP 3.1 Se revisan los planes que afectan al proyecto

6,00 6

SP 3.2 Se reconcilia el trabajo y el nivel de los recursos

8,00 8 SP 3.3 Se obtiene un compromiso de los implicados, con el plan del proyecto

7,00 7


8,00 8



7,00 7


7,00 7

53 | P á g i n a



GP 2.5 (AB 4) Las personas implicadas reciben formación

9,00 9


8,00 8


7,00 7



8,00 8


7,00 7


7,00 7


7,00 7

Total 7,79

CMMI-2 - PA3: Seguimiento y control del proyecto #

NA # ? Valor

P1

SP 1.1 Hay parámetros en la planificación para el seguimiento del proyecto

9,00 9

SP 1.2 Se realiza un seguimiento de las responsabilidades

8,00 8

SP 1.3 Se realiza un seguimiento de los riesgos del proyecto

6,00 6

SP 1.4 Se realiza un seguimiento de la gestión de la información

7,00 7

SP 1.5 Se realiza un seguimiento de la implicación de los actores

7,00 7

SP 1.6 Se realizan revisiones de seguimiento

6,00 6 SP 1.7 Se realizan revisiones de hitos

8,00 8

SP 2.1 Se analizan la casuística del proyecto

7,00 7 SP 2.2 Se toman acciones correctivas

9,00 9

SP 2.3 Se gestionan las acciones correctivas

8,00 8 GP 2.1 (CO 1) La organización tiene establecida una política

7,00 7



7,00 7



8,00 8


9,00 9


8,00 8



9,00 9


8,00 8

GP 3.1 Está establecido como proceso definido de la

7,00 7

54 | P á g i n a



organización (*) GP 3.2 Se obtiene información para su mejora (*)

6,00 6

Total 7,70

CMMI-2 - PA4: Gestión de acuerdo con proveedores #

NA # ? Valor P1

SP 1.1 Se determina el tipo de adquisición

8,00 8 SP 1.2 Se realiza una selección de suministradores

7,00 7

SP 1.3 Se establece un acuerdo con el proveedor

8,00 8 SP 2.1 Se evalúan posibles productos estándar

8,00 8

SP 2.2 Se ejecuta el acuerdo con el proveedor

9,00 9 SP 2.3 Se realizan acciones de aceptación de los productos adquiridos

9,00 9

SP 2.3 Se planifica la integración de los productos adquiridos

8,00 8


8,00 8



7,00 7



9,00 9


7,00 7


7,00 7



9,00 9


7,00 7


7,00 7


7,00 7

Total 7,88

(*) No es necesario en el nivel 2 de madurez CMMI-2 - PA6: Aseguramiento de la calidad de producto y

proceso #

NA # ?

Valor P1

SP 1.1 Se evalúan objetivamente los procesos

9,00 9 SP 1.2 Se evalúan objetivamente los productos de trabajo y los servicios

7,00 7

SP 2.1 Se comunican y se garantiza la resolución de las no-conformidades

8,00 8

SP 2.2 Hay establecidos registros

8,00 8 GP 2.1 (CO 1) La organización tiene establecida una política

7,00 7


8,00 8 GP 2.3 (AB 2) Se le proporcionan los recursos

8,00 8

55 | P á g i n a



adecuados GP 2.4 (AB 3) Tiene asignadas las responsabilidades

8,00 8


8,00 8


9,00 9


9,00 9



9,00 9


8,00 8


7,00 7


7,00 7

Total 8,21

CMMI-2 - PA7: Gestión de la configuración #

NA # ?

Valor P1

SP 1.1 Se identifican los elementos de la configuración

9,00 9

SP 1.2 Hay establecido un sistema para gestionar la configuración

8,00 8

SP 1.3 Se crean o ponen en marcha las líneas base

9,00 9

SP 2.1 Se trazan las peticiones de cambios

9,00 9

SP 2.2 Se controlan los elementos de la configuración

9,00 9

SP 3.1 Hay un registro mantenido para los elementos de la configuración

9,00 9

SP 3.2 Se audita la integridad de las líneas base

9,00 9


8,00 8


8,00 8

GP 2.3 (AB 2) Se le proporcionan los recursos adecuados

8,00 8


8,00 8


7,00 7


8,00 8


9,00 9


9,00 9

56 | P á g i n a



GP 2.9 (VE 1) Se evalúa objetivamente su cumplimiento

8,00 8


8,00 8


7,00 7


7,00 7

CMMI-2 - PA5: Medición y análisis

# NA

# ?

Valor

P1

SP 1.1 Se establecen los objetivos de la medición

8,00 8

SP 1.2 Se especifican las métricas

8,00 8

SP 1.3 Se especifican los procedimientos de obtención y registro

8,00 8

SP 1.4 Se especifican los procedimientos de análisis

7,00 7

SP 2.1 Se obtienen datos de las mediciones

7,00 7

SP 2.2 Se analizan los resultados de las mediciones

6,00 6

SP 2.3 Se guardan los datos y los resultados de las mediciones

6,00 6

SP 2.3 Se comunican los resultados

7,00 7


8,00 8


6,00 6

GP 2.3 (AB 2) Se le proporcionan los recursos adecuados

8,00 8


8,00 8


8,00 8


7,00 7


9,00 9


8,00 8

GP 2.9 (VE 1) Se evalúa objetivamente su cumplimiento

7,00 7


7,00 7

Total 8,41

57 | P á g i n a




7,00 7


7,00 7

Total 7,39

(*) No es necesario en el nivel 2 de madurez

6.2 Radar

Áre

as d

e p

roceso

Gestión de requisitos (REQM) 7,87

Planificación de proyecto (PP) 7,79

Seguimiento y control de proyecto (PMC) 7,70

Gestión de acuerdo con proveedores (SAM) 7,88

Medición y análisis (MA) 7,39

Aseguramiento de la calidad del producto y servicio (PPQA) 8,21 Gestión de la configuración (CM)

8,41

7 CASO DE ESTUDIO

El presente caso de estudio tiene como base el modelo PSP que está

siendo aplicado en el caso de uso GESTIONAR PRODUCTO.

7.1 Titulo del Proyecto

Sistema de gestión para la compra, venta e inventario de La Librería y

Papelería “LIBER”.

58 | P á g i n a



7.1.1 Introducción

En la actualidad la mayoría de las empresas, grandes y pequeñas,

cuentan con la ayuda de un Sistema Informático que les permite

manejar su información de una manera cómoda y eficiente, y así

aumentar su productividad pero también hay algunas empresas u

organizaciones que aun manejan parte o todos sus datos de forma

manual, lo cual le ocasiona una serie de contratiempos e incluso serios

problemas a la hora de procesar sus datos para obtener la información

requerida, tal es el caso de La Librería y Papelería “LIBER” la cual es

una empresa que se dedica a la compra, venta de material de escritorio y

material escolar, además de la fabricación y distribución de tableros

melamínicos, tableros de vidrio, pizarras acrílicas, ranuradas y de

corcho.

Por esta razón, el proyecto a desarrollar consistirá en automatizar y

gestionar las transacciones de comercialización de los productos, tener

una mejor organización de los mismos y un inventario actualizado.

7.1.2 Objetivo Especifico

Desarrollar un Sistema de Información para la compra, venta e inventario

de la Librería y Papelería “LIBER”.

7.1.3 Objetivo General

A continuación se detallan cada uno de los objetivos específicos:

Recolectar la información necesaria para el desarrollo del

Sistema mediante entrevistas con los funcionarios de la

Librería.

Observar en forma detallada todos los movimientos de la

empresa que nos interesen para la elaboración de este

proyecto.

Modelar los requisitos del Sistema para obtener el modelo de

negocio de la empresa.

Realizar un análisis de los requerimientos obtenidos en las

entrevistas para desarrollar modelos utilizando casos de uso.

59 | P á g i n a



Realizar el diseño del Sistema, a través de un modelo

conceptual para obtener una base de datos apropiada.

Implementar el producto, en un lenguaje de programación

adecuado a partir del diseño del Software.

Diseñar las interfaces del Sistema de forma iterativa con la

ayuda de los usuarios finales, para obtener interfaces

sencillas y fáciles de manejar.

Realizar las pruebas del Sistema con datos reales y ficticios

con la intención de descubrir algún error no detectado hasta

entonces y proceder a su respectiva corrección.

Asignar privilegios y poner restricciones al sistema de

acuerdo al cargo que tenga el usuario.

7.2 Definición de Requerimientos

7.2.1 Identificación de actores de Caso de Uso

Administrador: Administra la librería, dirige a los empleados.

Administrador

Vendedor: Atiende al cliente y busca los productos que el cliente

requiera.

Vendedor

Cliente: informa al vendedor que artículos desea comprar.

Cliente

60 | P á g i n a



7.2.2 Detalle de caso de uso

Ilustración 1. CU Gestionar Producto

Nro. CU1

Descripción Gestionar Producto

Actores Administrador

Iniciador Administrador

PRE- Condición Ninguna

POST- Condición Ninguna

Curso Básico

Acciones del Actor Respuestas del Sistema

1.-Registrar 1.2.- Ingresar la descripción del producto 1.3.- Seleccionar la marca 1.4.- Seleccionar la Unidad de medida 1.5.- Seleccionar el grupo al que pertenecerá el producto 2.-Modificar 2.2.- Seleccionar el articulo a modificar 2.3.- Realizar las modificaciones respectivas 3.-Eliminar 3.2.-Seleccionar el articulo o introducir solamente el código 3.4.-Confirmar Solicitud

1.1.- Generar el código para el nuevo producto 1.6.- Guardar datos del Producto 2.1.- Obtener todos los productos existentes 2.4- Registrar las modificaciones 3.1.- Obtener todos los productos existentes 3.3.- Obtener producto 3.5-Eliminar Producto

61 | P á g i n a



Prototipo Gestionar Producto

7.2.3 Modelo Físico de la base de datos

Producto

Id_Producto descripción precio_venta costo_promedio stock_minimo stock_actual

int string float float int int

Marca Id_marca marca

int string

Medida

id_medida medida int string Categoría

id_categoria categoria int string

7.3 Implementación

7.3.1 Estándar de Codificación del Caso de Uso Gestionar Producto

/*

62 | P á g i n a



* Clase que define gestión de marca de producto

* @author Betty Chaca

* @author Eliana Mancilla

* @version 1.0, 12/07/2013

* @since 1.4

*/

package Negocio; //Import all packege Negocio

import Datos.Conexion; //import class conection

import Datos.Marca; //import class Marca

import java.sql.ResultSet;

public class GestionarMarca {

prívate Conexión conex; // Crea una instancia a la clase conexión a la

base de datos

private Marca marca; // Crea una instancia a la clase marca

publicGestionarMarca() {

conex = new Conexion();

marca = new Marca();

}

/** Envia el código generado */

publicResultSetgenerarCodigo() {

return marca.generarCodigo();

}

/** Obtiene el identificador de esta unidad organizativa */

publicvoidsetDatos(intcodigo,String nombre) {

marca.setCodMarca(codigo);

marca.setMarca(nombre);

}

/** Agrega una marca a la base de datos **/

63 | P á g i n a



public void adicionar(intcodigo,String nombre) {

setDatos(codigo,nombre);

marca.Adicionar(marca);

}

/**Actualiza los datos a la tabla marca de la base de datos **/

public void actualizar(intcodigo,String nombre) {

setDatos(codigo,nombre);

marca.actualizar(marca);

}

/** Obtiene la marca del producto**/

public ResultSetObtenerMarca() {

return marca.obtenerMarca();

}

/** Obtiene el identificador de la marca de un producto*/

public int codigoMarca(String dato) {

return marca.codigoMarca(dato);

}

}

//********************class GestionarProducto *************************

public class GestionarProducto {

private Conexión conex; //Instancia a la clase conexión a la base de datos

prívate Producto prod; //Instancia a la clase producto a la base de datos

public GestionarProducto() {

conex = new Conexion(); // inicializacion de variables conex

prod = new Producto(); //inicializacion de variablr prod

}

64 | P á g i n a



/** Obtiene el código generado del producto */

public ResultSet generarCodigo() {

return prod.generarCodigo();

}

/** Envia los datos a la Clase Producto */

public void

setDatos(intcodigo,Stringnombre,intstock,intprecio_venta,intprecio_compra

, String ubicacion, intmarca) {

prod.setcodigo(codigo);

prod.setNombre(nombre);

prod.setStock(stock);

prod.setPrecioVenta(precio_venta);

prod.setPrecioCompra(precio_compra);

prod.setUbicacion(ubicacion);

prod.setCodMarca(marca);

}

/** Adiciona un producto a la base de datos*/

public void adicionar(intcodigo, String nombre, int stock, int precio_venta,

int precio_compra, String ubicacion, int marca) {

setDatos(codigo,nombre,stock,precio_venta,precio_compra,ubicacion,

marca);

prod.adicionar(prod);

}

/** Obtiene el producto del la tabla producto */

public ResultSet obtenerProducto() {

return prod.obtenerProducto();

}

}

65 | P á g i n a



7.3.2 Postmorten

7.3.3 Métricas en Cuanto a Defectos

Alumno : Betty Chaca Flores Fecha:8/7

FECHA

START

STOP

INTERRUPCION

TIEMPO DELTA

ACTIVIDAD COMENTARIO

08/07/2013

17:30

18:00 30 min Diseño

Diseño logico de la base de

datos en Postgres

08/07/2013

18:00

18:15

call phone 15 min Charla informativa

Coordinacion con el Gestor de proyecto

08/07/2013

18:16

19:00 44min

investigacion modelo Hibernate

Investigacion para SQL Server y

herramientas de ayuda

08/07/2013

19:01

19:30 29min

Configuracion de hibernate

Configuracion y Creacion de conexión SQL

08/07/2013

19:31

20:00 29min

Configuracion de aplicación de modelo 3 capas

Creacion de clases en modelo 3

capas

08/07/2013

20:01

20:45 44min Creacion de los ABMs

implementacion de las

funciones Insertar,

Modificar,Eliminar,Actualizar

08/07/2013

20:46

21:10 24min Test

Test de funciones creadas Insertar,

Modificar,Eliminar,Actualizar

08/07/2013

21:11

22:00 49min Diseño Presentacion

Diseño de formularios Producto y

marca

08/07/2013

22:01

22:20 19min

Verificacion del proyecto

Pruebas de la funcionalidad y integracion del proyecto

66 | P á g i n a



7.3.4 Requerimientos no funcionales del sistema

Gestor de base de datos Mysql

ID de desarrollo JAVA 7.0 y Netbeans 7.2

8 CONCLUSIONES.

La presente documentación es una propuesta para certificación CMMI Nivel

2 de nuestra empresa SC software developers

67 | P á g i n a



ANEXOS.

Informe de avance del Proyecto

Acta de la reunión del Equipo

ACTA DE REUNIÓN

Comité o Grupo: Acta N°:

68 | P á g i n a



Citada por: Fecha:

Coordinador: Hora inicio: Fin:

Secretario: Lugar:

PARTICIPANTES

No. Nombre Cargo Teléfono

1

2

3

PUNTOS DE DISCUSION

1

2

3

DESARROLLO DE LA REUNIÓN

Observaciones.

69 | P á g i n a



CONCLUSIONES

Nº Tarea Responsable Periodo de

cumplimiento

Responsable

A1. Lista de criterios para distinguir proveedores de requerimientos.

Gestión de Requerimientos Lista de Criterios para distinguir proveedores de Requerimientos.

Guía

Lo enlistado son los posibles proveedores de requerimientos con los cuales podrán ser seleccionados y clasificados según la importancia de la información que pudieren proporcional. Es importante distinguir cual será la fuente de requisitos para evitar información innecesaria.

La siguiente lista se usa de referencia para los criterios empleados para la selección del originador de requerimientos para el proyecto.

Criterio Descripción

El cargo que tiene en la empresa.

o Se tomará en cuenta el cargo o lugar que ocupa el sujeto en la jerarquía de la empresa.

El conocimiento que tiene sobre la problemática presentada.

Que tanto sabe el sujeto sobre el problema al que se debe dar solución.

El tiempo que lleva en la empresa

Mientras más tiempo lleve el sujeto en la organización, mayor es su conocimiento acerca del funcionamiento de la misma.

El grado en que empleará el producto a desarrollar

Si el sujeto es el que más empleará u operará el producto entonces también es una fuente importante de requerimientos.

Su trabajo no se verá perjudicado por el producto

Si lo que se desea es automatizar una función llevada a cabo por uno o varios sujetos entonces habrá cierta resistencia a ayudar en el desarrollo o bien puede resultar perjudicial.

70 | P á g i n a



A2. Lista de Criterios para la evaluación y aceptación de Requerimientos.

Gestión de Requerimientos Lista de Criterios para Evaluar y Aceptar los Requerimientos.

Guía:

La lista de criterios para la evaluación y aceptación de requerimientos son preguntas a realizarse para evaluar el grado de confiabilidad de los requisitos elicitados. Pueden verse como condiciones para proceder en el proyecto con los requisitos actuales o si deben continuar en la elicitación.

La siguiente lista se usa de referencia para evaluar y aceptar los requerimientos del sistema por parte del analista de los requerimientos.

Criterio Preguntas sobre los criterios.

1. Requisitos ambiguos Los requisitos se pueden leer e interpretar de distinta forma por personas diferentes?

2. Requisitos realistas Son los requisitos realistas, dada la tecnología que se utilizará para la implementación del sistema?

3. Requisitos comprobables Se pueden comprobar los requisitos? Es decir, los testers pueden diseñar pruebas que permitan mostrar que el sistema cumple con los requisitos?

4. Requisitos combinados La descripción de los requisitos incluye requisitos únicos o pueden ser divididos en varios requisitos?

5. Requisitos innecesarios Hay requisitos como agregados “cosméticos” para el sistema, los cuales no son realmente necesarios?

6. Uso de hardware no estandarizado

Se utilizará hardware que no cumpla con las especificaciones del sistema?

7. Requisitos identificados de forma única.

Los requisitos son plenamente identificados unos de otros?

8. Requisitos Rastreables. Los requisitos pueden seguirse a través de las fases de desarrollo del sistema?

A3. Forma de Reporte del análisis de los criterios.

Gestión de Requerimientos Reporte del Análisis de los Criterios de Aceptación de los Requisitos.

Guía:

En la primera sección del documento se coloca la fecha en que se lleva a cabo el análisis, el nombre del proyecto y la lista de participantes en el análisis. En la segunda sección se enlistan el conjunto de documentos de requisitos que se revisarán así como su versión o estado. La tercera y última sección consiste en un checklist con características q deben cumplir los requisitos con un espacio para colocar observaciones o análisis

71 | P á g i n a



sobre los requisitos.

Versión: 1.0

Fecha:

Nombre del Proyecto:

Participantes del análisis:

Documentos de Requisitos analizados:

Titulo del Documento Versión o Revisión.

Criterios Analizados:

Núm.

Criterio Análisis Aprobado

1 Requisitos ambiguos

2 Requisitos realistas

3 Requisitos comprobables

4 Requisitos combinados

5 Requisitos innecesarios

6 Uso de hardware no estandarizado

7 Requisitos identificados de forma única

8 Requisitos Rastreables

72 | P á g i n a



A4. Forma de Acuerdos del conjunto de requerimientos.

Gestión de Requerimientos Acuerdo del conjunto de Requerimientos.

Guía:

En la primera sección del documento se coloca la fecha en que se lleva a cabo el análisis, el nombre del proyecto y la lista de participantes en el análisis. En la segunda sección se registran los requisitos clasificándolos en funcionales, no funcionales y otro tipo de requisitos, se les asigna una ID y algún documento en el que se referencie el requisito, y se marcará si se está de acuerdo con el requisito. En la tercera sección se coloca la lista de los participantes en los acuerdos, su cargo en el proyecto y su firma. En la última sección se coloca el nombre de la persona que aprobará el conjunto de requisitos, la fecha y su firma.

Versión: 1.0

Fecha: Nombre del Proyecto:

Participantes del acuerdo

Conjunto de Requisitos del Sistema:

ID Referencia

Requisitos Funcionales Acordado

ID Referencia

Requisitos No Funcionales Acordado

ID Referencia

Otros Requisitos Acordado

Participantes del acuerdo: Nombre:

Cargo:

Firma:

Nombre:

Cargo:

Firma:

73 | P á g i n a



Nombre:

Cargo:

Firma:

Aprobado por:

Nombre:

Fecha:

Firma:

A5. Forma de Evaluación de impacto de los Requerimientos.

Gestión de Requerimientos Forma de Evaluación de impacto de los Requerimientos.

Guía:

Se coloca un número asignado a la petición de cambio para mantener un control. Se coloca el título para identificar la petición de cambio. Se proporciona una descripción sobre el cambio que se desea realizar. Se coloca el nombre del analista responsable de la petición. La fecha. Se coloca una breve descripción acerca de beneficios, penalizaciones, riesgos y costos provocados por la realización del cambio. Se calcula una prioridad para el cambio a realizar. Estimaciones de esfuerzos, impactos en el calendario y costos adicionales para la realización del cambio. Finalmente se enlistan los requisitos y tareas que pudieran afectarse por el cambio al requerimiento. Se escribe el nombre de la persona que aprobó la petición de cambio, la fecha y la firma.

Versión: 1.0

Petición de Cambio No:

Titulo:

Descripción:

Analista:

Fecha:

Estimaciones de Priorización

Beneficio Relativo:

Penalización Relativa:

Costo Relativo:

Riesgo Relativo:

Calculo de la prioridad:

Estimación del Esfuerzo Total: (Horas)

Estimación del Esfuerzo Perdido: (Horas)

Estimación del impacto en el calendario: (Días)

Impacto de Costos Adicionales:(Pesos)

Otros Requisitos Afectados:

Otras Tareas Afectadas:

Aprovado por:

74 | P á g i n a



Nombre:

Fecha:

Firma:

Gestión de Requerimientos Forma de Estimación del Esfuerzo en los Cambios de los Requerimientos

Versión: 1.0

Fecha:


Encargado del documento:

Guía: 1. Identificar el subconjunto de las tareas antes mencionadas que tendrán que

hacer. 2. Asignar recursos a las tareas. 3. Estimar el esfuerzo necesario para las tareas pertinentes, sobre la base de

los recursos asignados. 4. Estimar el Total el esfuerzo. 5. Secuenciarlas tareas e identificar predecesores. 6. Determine si el cambio está en la ruta crítica del proyecto. 7. Estimar el calendario y el costo del impacto

Llenar la siguiente tabla usando el procedimiento:

Esfuerzo

(Horas

laborares)

Tarea

Actualizar el SRS o requisitos de base de datos con

el nuevo requisito

Desarrollo y evaluación de prototipos

Crear componentes de nuevo diseño

Modificar los componentes existentes de diseño

Desarrollar nuevos componentes de interfaz de

usuario

Modificar los componentes de interfaz de usuario

existente

Desarrollar publicaciones nuevo usuario y pantallas

de ayuda

Modificar las publicaciones existentes del usuario y

las pantallas de ayuda

75 | P á g i n a



Desarrollar nuevas fuentes de código

Modificar el código fuente existentes

Compra e integrar software de terceros

Determinar los componentes, la compra, e integrar

hardware, y califica de proveedores

Modificar los ficheros de construcción

Desarrollar nuevas pruebas unitarias y de

integración

Modificar la unidad e integración existentes pruebas

Realizar las pruebas de integración y unidad

después de la aplicación

Escribir nuevo sistema y los casos las pruebas de

aceptación

Modificar actual sistema y los casos las pruebas de

aceptación

Modificar los pilotos de pruebas automatizadas

Realizar las pruebas de regresión en la unidad, la

integración, y el sistema de niveles

Desarrollar nuevos informes

Modificar los informes actuales de

Desarrollar nuevos elementos de base de datos

Modificar los elementos existentes de base de datos

Desarrollar nuevos archivos de datos

Modificar datos de los archivos existentes

Modificar varios planes de proyecto

Actualización de la documentación de otros

Requisitos de la actualización de la matriz de

trazabilidad

Examen de los productos modificados trabajo

76 | P á g i n a



reproceso Realizar siguientes revisiones y pruebas

Recertificar producto como seguros, seguro y

compatible con las normas.

Otras tareas adicionales

ESFUERZO TOTAL ESTIMADO

Realizó:

Fecha: Firma:

Aprobado por:

Nombre:

Fecha: Firma:

A6. Reporte de Estado de los Requerimientos.

Gestión de Requerimientos Reporte del estado de los Requerimientos.

Guía:

En la primera sección se coloca la fecha de la última actualización, el nombre del proyecto y el nombre del encargado de llenar el documento. En la segunda sección se enlistan los requisitos con su ID, los documentos que les hacen referencia y su estado. En la tercera sección se coloca un conjunto de estados con su descripción para los requisitos enlistados en la segunda sección. Por último se coloca el nombre de la persona encargada del seguimiento, la fecha y la firma, y posteriormente el nombre de la persona que aprobará el documento, su firma y la fecha.

Reporte del estado de los Requerimientos Versión: 1.0

Ultima Actualización:



Conjunto de Requisitos del Sistema:

ID Referencia Requisitos Funcionales Estado*

ID Referencia Requisitos No Funcionales

77 | P á g i n a



ID Referencia Otros Requisitos

*Estados:

Estado Descripción

Propuesto El requisito es pedido por una fuente autorizada.

Aprobado El requisito ha sido analizado y puesto a disposición en la línea base del proyecto y el equipo de desarrollo se ha comprometido a implementarlo.

Implementado El código que implementa el requisito ha sido diseñado, codificado y probado. También ha sido seguido a través de la matriz de trazabilidad.

Verificado El correcto funcionamiento del requisito implementado ha sido confirmado en el producto y el requerimiento es considerado como completado.

Borrado Un requisito aprobado es quitado de la línea base del proyecto.

Rechazado Un requisito que es propuesto pero su implementación no está dentro los planes del proyecto.

Datos del encargado del seguimiento:

Nombre:

Fecha:

Firma:

Aprobado por: Nombre:

Fecha:

Firma:

A7. Elección de una Herramienta para el manejo de la base de datos de los

Requerimientos.

Gestión de Requerimientos Procedimiento para la Elección de una Herramienta para el manejo de la base de datos de los Requerimientos.

Versión: 1.0 Última Revisión:



Guía:

Guía para la elección de la herramienta: Seleccione una herramienta basada en una combinación de la plataforma, precio, modos de acceso y paradigma—centrado en documentos o centrado en una base de datos— que mejor se ajusten al entono de desarrollo y cultura de la compañía. Realice el siguiente procedimiento antes de tomar una elección:

78 | P á g i n a



1. Defina los requerimientos de la empresa que deberá cumplir la herramienta, identifique las características más significativas para la empresa, por ejemplo, la capacidad de acceso mediante web es una característica importante, decida si quiere continuar almacenando los requerimientos en documentos o prefiere almacenarlos en una base de datos.

2. Liste 10 o 15 factores que pueden influenciar en su decisión, incluyendo factores subjetivos como adaptabilidad (en la empresa), eficiencia, y efectividad de la interfaz de usuario. El costo debe ser un factor, pero evalué las herramientas sin considerarlo en una primera instancia.

3. Distribuya 100 puntos entre los factores listados anteriormente, y asígnele más puntos a los factores más importantes.

4. Obtenga información acerca de las herramientas con base en opiniones en foros, revistas especializadas, páginas web, etc.

5. Obtenga una versión de prueba para evaluar los factores subjetivos. 6. Evalué la herramienta en un proyecto real, y no solo el proyecto tutorial del

producto. 7. Asigne las calificaciones pertinentes y tome una decisión y llene el

siguiente formulario.

Plantilla de Elección de herramienta para la gestión de requisitos

Herramienta elegida:

Fecha:

Razones de la elección:

Histórico de elecciones


Fecha:


Razones de la sustitución:

Nombre:

Fecha:

Firma:


Fecha:

Firma:

Guía: Procedimiento para la Elección de una Herramienta para el manejo de

la base de datos de los Requerimientos.

En la primera sección se coloca la fecha de la última revisión, el nombre del

proyecto y el nombre del encargado de llenar el documento.

En la segunda sección se documenta una guía para elegir una herramienta

de almacenamiento de los requisitos.

79 | P á g i n a



En la tercera sección se escribe el nombre de la herramienta elegida, la

fecha y una justificación del porqué de la elección de la herramienta.

En la última sección se lleva a cabo el nombre de la nueva herramienta, la

fecha, las razones de la elección, y las razones por las que se sustituyó la

herramienta.

Por último se coloca el nombre de la persona encargada del seguimiento, la

fecha y la firma, y posteriormente el nombre de la persona que aprobará el

documento, su firma y la fecha.

A8. Procedimiento para el Sistema de Seguimiento de los Requerimientos.

Gestión de Requerimientos Procedimiento para el Sistema de Seguimiento de los Requerimientos.

Versión: 1.0 Ultima Actualización:



Guía:

Es posible rastrear los requerimientos manualmente para aplicaciones de menos de 100 requerimientos aproximadamente, pero para sistemas más grandes es necesario elegir una herramienta de gestión de requerimientos. Considere la siguiente secuencia de pasos cuando deba implementar la trazabilidad de los requerimientos en un proyecto:

1. Seleccione las relaciones o enlaces que desea definir como posibilidades de trazabilidad, de acuerdo a la siguiente figura:

80 | P á g i n a



Requerimientos de

Negocio.

Requerimientos de

Sistema, caso de uso,

atributo de calidad,

requisito de interface.

Petición de

CambioRegla de Negocio

Requerimiento

funcional del

software

Prueba del

Sistema

Planeación de las

Tareas del Proyecto de

Arquitectura,

interfaz de

usuario, diseño

funcional

Prueba de

IntegraciónCódigo

Pruebas de

unidad

Modifica

Modifica

Modifica

Modifica

2. Seleccione la forma de almacenar la información: una tabla en un

documento, una hoja de cálculo, o una herramienta de gestión de requerimientos.

3. Identifique las partes del producto de las cuales desea mantener información de rastreo. Inicie con las funciones críticas, las de más riesgo, o las porciones que requerirán mayor mantenimiento y cambios durante la vida del producto.

4. Modifique sus procedimientos de desarrollo y sus listas de verificación para poner al pendiente a los desarrolladores de actualizar la matriz de trazabilidad una vez que se implementa o aprueba un cambio en un requerimiento.

5. Defina como convenciones para identificar a cada componente del sistema que será enlazado. Por ejemplo CU-1, para caso de uso uno.

6. Defina sus matrices de trazabilidad con base en la siguiente plantilla del apéndice A8

Nombre:

Fecha:

Firma:


Fecha:

Firma:

81 | P á g i n a



Guía: Procedimiento para el Sistema de Seguimiento de los

Requerimientos.

En la primera sección se coloca la fecha de la última actualización, el

nombre del proyecto y el nombre del encargado de llenar el documento.

En la segunda sección se coloca una guía para diagramar los

requerimientos e inclusive su implementación de modo que su seguimiento

sea más sencillo.

Por último se coloca el nombre de la persona encargada del seguimiento, la

fecha y la firma, y posteriormente el nombre de la persona que aprobará el

documento, su firma y la fecha.

GC1. Lista de criterios para identificar los elementos de Configuración.

Sistema de Control de

Seguridad y Personal

Lista de Criterios para identificar los Elementos de

Configuración.

La siguiente lista se usa de referencia para la identificación de elementos de

configuración.

Para su uso el gestor deberá de tomar en cuenta las descripciones descritas por

cada fuente y considerar en que categoría se encuentra cada elemento descrito

en la EDT.

Fuente Descripción

Documentos usados por

un grupo.

Tomar en cuenta productos de trabajo que serán

usados por dos o más grupos de personas.

Documentos que se use

durante el ciclo de vida del

proyecto.

Tomar en cuenta productos de trabajo que se

espera que cambien con el tiempo.

Tomar en cuenta productos de trabajo que se

trabajen durante el ciclo de vida del proyecto.

Documentos que tienen

dependencia con otros

Tomar en cuenta productos de trabajo que son

dependientes de otro de manera que un cambio

82 | P á g i n a



documentos. en uno dicte cambios en otros documentos.

Documentos críticos. Tomar en cuenta productos de trabajo que son

críticos para el proyecto.

83 | P á g i n a



GC. Lista de pasos para asignar los identificadores únicos los elementos de Configuración.



Lista de Pasos para asignar los identificadores

únicos a los Elementos de Configuración.

El siguiente proceso se usa para asignar los identificadores únicos los

elementos de Configuración.

Paso Descripción

Paso 1. Utilizar la siguiente nomenclatura para los

siguientes tipo de elementos:

Planes: Plan_Proceso del cual se realiza el

plan_

ERS: ERS_

Historial de Cambios de EGC:

Historial_Cambios_Nombre del EGC_

Código: Modulo_Nombre del Código

¿Ahora sí que no sé qué más hay?

Paso 2. Al final del cada elemento, excepto código agregar

el número “Ver-0.1” precedido por un guion bajo.

En caso de ser un cambio que se considera de

importancia alta, se incrementara el identificador

numérico al siguiente entero, en caso de ser un

cambio medio o bajo solo se aumentara un

decimal.

GC3. Lista de criterios para identificar cada cuándo un elemento de configuración se colocara bajo la administración de configuración.



Lista de criterios para identificar cada cuándo un

elemento de configuración se colocara bajo la

administración de la configuración

84 | P á g i n a



La siguiente lista de criterios para identificarcadacuándoun elemento de

configuración se colocara bajo la administración de configuración.

Fuente Descripción

Ciclo de vida del proyecto. Un elemento de configuración puede ser puesto

bajo administración dependiendo de la fase de

ciclo de vida del software en la que se encuentre

el proyecto.

Listo para pruebas. Un elemento de configuración puede ser puesto

bajo administración cuando éste se encuentre

listo para las pruebas.

Costo y calendario. Un elemento de configuración puede ser puesto

bajo administración dependiendo de las

limitaciones de costo y calendario.

Requisitos del cliente. Un elemento de configuración puede ser puesto

bajo administración dependiendo de las

necesidades o requisitos del cliente.

2.7.9 A4. Plantilla para el Registro de Elementos de Configuración.



Registro de Elemento de Configuración.

Autor: Cliente:

Propósito:

Identificador del

Proyecto

Tipo de Producto

Identificador del

Elemento

85 | P á g i n a



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.



Lista de características a considerar para la

elección de una herramienta para el control de

los elementos de la configuración del

software.

La siguiente lista presenta alguna de las características que deberían ser

consideradas para la elección de una herramienta para el control de los

elementos de configuración del software.

Característica Descripción

Control de acceso. Permite el manejo de múltiples usuarios y

control de permisos sobre el mismo de tal

manera que sea posible restringir

operaciones sobre los elementos de

configuración.

Recuperación de

elementos de

configuración.

Permite recuperar elementos de

configuración de versiones anteriores.

ÚltimaVersión

Fecha para colocar

bajo administración

de la configuración

Características

Importantes

Propietario

Responsable

Productos

Relacionados

Estatus

Comentarios

86 | P á g i n a



Costo. Contemplar aspectos de costo de la

herramienta.

Usabilidad Es fácil usar la herramienta

Accesibilidad Es posible consultar los elementos de

configuración desde cualquier lugar con

acceso a internet.

GC6.Formulario para el registro de la Herramienta de Gestión de la Configuración.

Sistema de

Control de

Seguridad y

Personal

Formulario para el registro de la herramienta de gestión

de la configuración.

Formulario para el registro de la herramienta de gestión de la configuración.

Versión: 1.0

Última

Revisió

n:

Nombre del

Proyecto:

Encargado del

documento:

Plantilla de Elección de herramienta para la gestión de la configuración


Fecha:



Fecha:


87 | P á g i n a



Razones de la sustitución:

N

o

m

br

e:

Fecha

: Firma:

Aprobado por:

N

o

m

br

e:

Fecha: Firma:

88 | P á g i n a



GC7. Proceso para obtener autorización de la tarjeta de control de configuración (CCB) antes de crear o liberar líneas de base de los elementos de configuración.

89 | P á g i n a



GC8. Plantilla para la solicitud de creación o liberación de un elemento de configuración del software.

SOLICITUD DE ELEMENTOS DE CONFIGURACIÓN DEL SOFTWARE

Solicitante: Nombre del Proyecto:

Fecha de Solicitud: Jefe de Proyecto:

Nombre del ECS: Estado:

Descripción de motivos para la solicitud del elemento de configuración del

software:

Documentación Auxiliar:

Firma del Solicitante:

90 | P á g i n a



GC9. Plantilla para la Petición de Cambio.

PETICIÓN DE CAMBIO (RFC)

Petición Cambio No:

Solicitante: Nombre del Proyecto:

Fecha de Solicitud: Jefe de Proyecto:

Prioridad de Petición: Estado:

Descripción del Cambio:

Impacto en el Negocio: Impacto en el Sistema:

Beneficios del Cambio:

Costos del cambio:

Documentación Auxiliar:

91 | P á g i n a




GC10. Proceso para la Petición de Cambio.

Presentado

Evaluado Rechazado

Aprobado

Cambio Hecho

Verificado

Cerrado

El verificador confirma el cambio

El modificador instala el producto modificado

Falla la verificación

Modificador realiza el cambio y pide la verificación

No se requiere

verificación

CCB decide realizar el cambio

CCB decide no realizar el cambio

Evaluador realiza un

análisis de impacto

Se presenta un elemento

Cancelado

El cambio se cancela; se

elimina las modificaciones





92 | P á g i n a



GC11. Plantilla para el Historial de Cambios. (Obtenido desde Assemblla)

*A - AÑADIDO M - MODIFICADO D - BORRADO

NUMERODE VERSION FECHA *AMD DESCRIPCION NUMERO DE PETICION DE

CAMBIO

93 | P á g i n a



GC12. Plantilla para la solicitud de auditoría de los elementos de

configuración del software.

Plantilla de Petición de Auditoria

Fecha de Petición:

Responsable de la Petición:

Motivo de la Petición:

Resultado de la Auditoria:


Firma del Gestor de la Configuración:

94 | P á g i n a



GC13. Plantilla para la auditoría de Gestión de la Configuración.

Plantilla de Auditoria de Gestión de la Configuración

Nombre del Auditor:

Fecha de la Auditoria:

Si No Notas

1.- ¿Existen ECS con más de 3 peticiones de salida para modificación durante el mes?

2.- ¿Se encontró inconsistencia a algún ECS?

3.- ¿Las versiones en el sistema de gestión son las últimas de cada ECS?

4.- ¿La estructura de almacenamiento se mantiene integra?

5.- ¿Existe algún conflicto con los niveles de acceso del sistema de gestión?

6.- ¿Existen más de 10 modificaciones de líneas base en el mes?

95 | P á g i n a



MC1. Plantilla para el registro del responsable de monitor del proyecto.

Proceso de

Monitoreo y

Control de

Proyectos

Plantilla para el registro del responsable de monitor del

proyecto.

La siguiente plantilla es un documento para el registro del responsable de

desempeñar el rol de monitor de proyecto.

Fecha: / /

Monitor del

proyecto

___________________________________________________

Nombre y firma

Líder del

proyecto

___________________________________________________

Nombre y firma

MC2. Plantilla para el registro de las desviaciones significativas encontradas

en la monitorización.

Proceso de Monitoreo y

Control de Proyectos

Plantilla para el registro de las desviaciones

significativas encontradas en las actividades

de monitoreo y control del proyecto.

En la siguiente tabla se registraran las desviaciones significativas

encontradas en las actividades de monitoreo y control del proyecto

identificando de manera correcta la fuente la cual puede ser:

Parámetro de planeación, compromisos, riesgos, datos, partes

interesadas, progreso, hitos

identificador Descripción Fuente Prioridad

96 | P á g i n a



97 | P á g i n a



MC3. Plantilla para el registro de problemas identificados en el proyecto a

través de la monitorización del proyecto.

Proceso de Monitoreo y

Control de Proyectos

Plantilla para el registro de problemas

identificados en el proyecto de configuración

se colocara bajo la administración de la

configuración

La siguiente lista presenta los problemas identificados en el proyecto a

través PMC así como también las acciones correctivas que se tomaran

para dicho problema y el responsable de ejecutar estas acciones

Nombre Descripción Acciones correctivas Responsa

ble

98 | P á g i n a



Bibliografía

Documentos Electrónicos

“Guía de gestión pequeñas empresas basadas en cmmi”, Comité de

sistemas informáticos< www.inteco.es/file/jnPE0gHNH7k>

CMMI <www-03.ibm.com/press/es/es/pressrelease/35889.wss> ,

www.sei.cmu.edu/cmmi/ , CMMI v0.1

Calidad del Software <Generaknow.com/moodle>

PSP <Generaknow.com/moodle>

Base y Conocimiento del PSP <Generaknow.com/moodle>

Materia para el PSP0 <Generaknow.com/moodle>

Libros

Pressman, Roger. Ingenieria de Software: Un enfoque Practico.

España: Editorial McGraw-Hill, 2002.

Ponencia Diego Jodar y Anna Casals.pdf : PMBOK-PMI

http://www.inteco.es/file/jnPE0gHNH7k

Technology

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