IEEE 828 APLICADO A SÍLABA MANÍA

INTEGRANTES: Iza Dennys - Navarrete Mario

TUTOR: Ing. Gilma Toaza

INGENIERÍA DE SOFTWARE I

2018
 INDICE

INTRODUCCIÓN A LA GUÍA DE SCMP 3

1. INTRODUCCIÓN 3
1.1. Propósito 3
1.2. Alcance 3
1.3. Definiciones 3
1.4. Referencias 3
2. GESTIÓN DE CONFIGURACIÓN DEL SOFTWARE (SCM) 3
2.1. Organización de SCM 4
2.2. Responsabilidades de SCM 4
3. ACTIVIDADES DE LA GESTIÓN DE CONFIGURACIÓN DEL SOFTWARE (SCM) 4
3.1. Identificación de la configuración 4
3.1.1. Identificación de los ítems de configuración 4
3.1.2. Denominación de los items de configuración 4
3.1.3. Recuperación de los items de configuración 6
3.2. Control de configuración 6
3.2.1. Solicitud de cambios 6
3.2.2. Evaluación de cambios 7
3.2.3. Aprobación o desaprobación de cambios 7
3.2.4. Implementación de los cambios 7
3.3. Estado de la configuración 7
3.4. Auditorías de configuración 7
3.5. Control de interfaces 7
3.6. Control de subcontratos y vendedores 7
4. AGENDA DE SCM 7
5. RECURSOS DE SCM 7
6. REFERENCIAS DE ESTA GUÍA 8

Página 2 de 14
Introducción a la Guía de SCMP

En este documento se brinda una guía sobre el contenido de las secciones que determina el IEEE Std.
828 para el Plan de Gestión de Configuración. Está basado en la aplicación de disciplinas de SCM a
proyectos de ingeniería de software que establece el IEEE Std. 1042, indicando en algunos casos las
secciones de este estándar que aportan la información requerida.

El objetivo de esta guía es brindar una base para la adaptación del estándar al modelo de proceso que
se aplica en el curso 2001 de la asignatura Proyecto de Ingeniería de Software, destacando por ejemplo,
la nomenclatura para los entregables definidos en el modelo de proceso y la definición de líneas base.

En cada sección se indica entre <> una descripción de lo que establece el IEEE Std. 828 para la misma,
y en algunas secciones se incluye por fuera de esta descripción la interpretación que corresponde al
curso, con la intención de que sea una base para que entre ambas descripciones puedan definir el
contenido de la sección.

1. Introducción

1.1. Propósito

​El propósito de presente plan es definir la organización, las actividades y responsabilidades asociadas
al proceso de SCM durante el proyecto Silabamanía.

Por lo tanto, el plan de SCM está dirigido al jefe de proyectos, los desarrolladores y al responsable de
SCM, responsable de la elaboración, actualización y monitoreo del plan.

Además se desea establecer los elementos necesarios para administrar los documentos y los fuentes
que son elaborados por el equipo del proyecto.

1.2. Alcance
El presente documento establece, de acuerdo a la política organizacional, las responsabilidades de
SCM durante el ciclo de vida del software definido para el ​proyecto Silabamanía. El ciclo de vida
comprende las etapas de planificación, especificación de requerimientos, diseño, implementación,
integración y pruebas, aceptación y entrega, y mantención.

El objetivo de SCM es controlar los cambios en la configuración a través de las actividades de

identificación, control de cambios, auditorías e informe sobre el estado de la configuración.

1.3. Definiciones

Base de Datos.- Conjunto de datos estructurados y definidos a través de un proceso específica que
busca evitar la redundancia y se almacenará en un medio de almacenamiento masivo como un disco.

Requisitos.-​ Un requisito es una circunstancia o condición necesaria para algo

Administrador.- Persona que estará a cargo de manejar la información importante y privada del
negocio, este será el único en tener acceso a la misma.

Software.-​ Conjunto de programas que permiten a un dispositivo realizar determinadas tareas.

Prototipo.-​ Ejemplar o primer molde del software a desarrollar.

Fonema.-​ Abstracción de los sonidos del habla humana.

SRS.-​ Software Requirements Specification

Línea Base.- ​Conjunto de componentes con una determinada versión que en forma conjunta permite
el funcionamiento de la aplicación.

Página 3 de 14
1.4. Referencias
[1] Issues to consider in Planning
[2] Marco Vetter, Markus Müller, Fatima Hamlaoui, Graharn Neubig, Satoshi Nakamura, Sebastian
Stüker, and Alex Waibel, "Unsupervised Phoneme Segmentation of Previously Unseen Languages," in
Proceedings of the Interspeech, 2016.
[3] Procedimiento de Gestión de la Configuración.
[4] Procedimiento de Planificación de Proyectos.

2. Gestión de Configuración del Software (SCM)

El presente documento establece que el proyecto se divide en 2 fases y cada una en dos iteraciones. Se
debe mantener el control de cada fase e iteración. La herramienta a utilizar para la gestión de
configuración es CVS (​Concurrent Versioning System​).

1.1. Organización de SCM

Entidad Función

Administrador de Sistema de Debe mantener el repositorio, debe analizar los pros y contras del proyecto
Gestión de la Configuración para realizar una gestión correcta y mantener un Versionamiento unificado
por parte de todos los subalternos.

Líder de equipo técnico Es el supervisor, ergo, jefe inmediato del equipo de desarrollo, por lo que
debe estar consciente en todo momento de la validez y calidad del producto
que se está desarrollando.

Miembro del equipo de Se encargan de codificar la aplicación, crear y utilizar documentación

desarrollo necesaria basada en los requerimientos y consejos que se han otorgado
durante el proceso de desarrollo.

Página 4 de 14
1.2. Responsabilidades de SCM

Miembros/Rol Responsabilidades Apellido y Nombre

Administrador de Sistema de Este rol tiene asociado las tareas de Mario Navarrete
Gestión de la Configuración administración y mantenimiento del
repositorio unificado de versionado.

Líder de equipo técnico Rol encargado de supervisar que el Dennys Iza

equipo de desarrollo utilice el repositorio
durante el ciclo de vida del proyecto.
Asimismo, se coordinará con el
administrador de sistema para la
creación y puesta en marcha del
versionado.

Miembro del equipo de Este rol interactúa con el repositorio Equipo de desarrolladores
desarrollo haciendo operaciones sobre los ítems
de configuración generados durante un
proyecto. Serán los principales
productores/consumidores de los datos
puestos bajo control de versión.

Página 5 de 14
2. Actividades de la Gestión de Configuración del Software (SCM)

● Gestión del Código Fuente: Se analiza la estructura del código fuente del proyecto, los
roles, la plataforma donde es alojado el código, etc…
● Gestión de la Construcción: Se indica las herramientas utilizadas para la construcción del
proyecto, cómo se utilizan, etc…
● Gestión de los Entregables: Qué entregables se contemplan en el proyecto y cómo se
realiza su entrega. Estos son el propio código fuente, liberado como entregable con cada
nueva versión, y la documentación que no sigue una política establecida más allá de su
dependencia con el código fuente.
● Gestión del Despliegue: Como se realiza el despliegue, que herramientas se utiliza, cuando
se realiza.
● Gestión de Incidencias y Depuración: Se explica el proceso de reporte de incidencias y
cómo se realiza la depuración.
● Gestión de la Variabilidad
● Integración y Despliegue Continuos: A modo de facilitar las tareas de pruebas se recurre a
herramientas de integración y despliegue continuo. Estas herramientas nos proporciona
mecanismo para recopilar los distintos proyectos involucrados, dependencias, incorporar los
cambios realizados, etc. Una vez reunido se construye el proyecto y ejecutan las pruebas
incorporadas, si pasa las pruebas se puede publicar de manera automática o desplegar
directamente en un servidor.
● Las Pruebas: Se describen los tipos de pruebas que se realizan en el proyecto y el
procedimiento para ejecutarlas.
● Mapa de Herramientas: Se describen las herramientas necesarias para trabajar con el
proyecto en las diferentes actividades de la Gestión de la Configuración, y la relación que
tienen entre ellas.

2.1.1 Elementos de la configuración

Página 6 de 14
 2.1.2 Nomenclatura de elementos

Para facilitar la comprensión de la norma, se utilizarán “elementos”. Los nombres de los documentos
se compondrán de elementos, cada uno de los cuales tiene un significado, unas normas y una lista
de valores posibles. Adicionalmente se establecen una serie de reglas a aplicar de forma general en
todos los documentos.
El nombre de todos los documentos se formará del siguiente modo:
<tipo>_<proyecto>_[<módulo>]_[<versionProducto>]_<textoIdent>
A continuación, se define cada elemento, sus normas de aplicación y posibles valores.

Página 7 de 14
 Línea Momento Ítems de configuración
Base

Planificación y Luego que se acepta el Plan de desarrollo de Planes

Cronograma software propuesto. El objetivo es fijar la línea base Cronograma de desarrollo
de alcance para el proyecto, su estimación y Lista de riesgos
planificación.
Se genera una línea base por cada fase, y se
modificará ante cada cambio crítico en la
planificación del proyecto.

Requerimientos Al fin de la Inspección, cuando se tenga aprobado el Versión

SRS, y se haya acordado el documento de visión se SRS
generará la línea base. Especificación de Casos de Uso
Prototipo de Pantalla
Diagrama de Navegación
Modelos de clase

Sistema Por cada entrega a Administrador de calidad o al Aplicación

Cliente, se generará una línea base. Una vez el Pruebas Unitarias
producto esté terminado, probado y validad con el
cliente, se tendrá la línea base final.

Nombre de Descripción
Lanzamiento

Entrega a Testing Este lanzamiento será creado cuando exista un conjunto de código
desarrollado en estado estable para comenzar las pruebas y acordada la
planificación con el área de Testing.

Aceptado Este lanzamiento será creado cuando se ejecuten exitosamente todos los
casos de prueba para el usuario. El resultado de éste será utilizado como
lanzamiento de producción.

Producción Se creará una vez que se haya recibido la aceptación por parte del sector
usuario después que haya iniciado la fase de mantenimiento.

1.1.1. Denominación de los ítems de configuración

En el caso de el desarrollo de la aplicación Silabamanía, la numeración de las versiones de cada

item de la configuración serán dadas en forma automática por la herramienta CVS. Si existieran
entregables que no son puestos bajo control de versiones, se deberá identificar a que Fase e

Página 8 de 14
 iteración corresponden en forma manual, por ejemplo agregando al final del nombre un identificador
de la misma y también serán almacenados en forma central.
Se indica la siguiente nomenclatura para cada entregable en el modelo de proceso, según la Línea
de Trabajo:

​Requerimientos:

Nomenclatura Entregable
RQALS Alcance del Sistema
RQDRQ Documento de Requerimientos
RQDVC Documento de validación con el Cliente
RQGL Glosario
RQMOD Modelo de Casos de Uso
RQMD Modelo de Dominio
RQRRQ Resumen de las reuniones de requerimientos

Análisis:

Nomenclatura Entregable
ANERQ Documento de Especificación de Requerimientos
ANMOD Modelo de Análisis

​Diseño:

Nomenclatura Entregable
DSMOD Modelo de Diseño
DSDIST Modelo de Distribución

​Implementación:

Nomenclatura Entregable
IMDT Documentación técnica
IMELBA Ejecutable de la Línea Base de la Arquitectura
IMES Ejecutable del Sistema
IMESF Ejecutable Final del Sistema
IMEDT Estándar de documentación técnica
IMEIM Estándar de implementación
IMMTP Manual técnico del prototipo
IMMOD Modelo de Implementación
IMPINT Plan de Integración
IMPROT Prototipo
IMRREP Reporte de revisión por pares
IMRVEP Reporte de verificación por pares

Para los nombres de los archivos de código fuente se debe definir el procedimiento que permita
su identificación.

​De todas las anteriores:

Nomenclatura Entregable
DESARQ Descripción de la Arquitectura

Página 9 de 14
 ​Verificación:

Nomenclatura Entregable
VRCPRU Casos de Prueba
VREVRIT Evaluación de la verificación de la iteración
VRIFVR Informe final de verificación
VRMOD Modelo de Testeo
VRPRUP Plan de Pruebas
VRPRUPPR Plan de Pruebas del Prototipo
VRPLAN Plan de Verificación
VRREPU Reporte de Pruebas unitarias
VRREPIS Reporte de Pruebas de integración
VRREPUIS Reporte de Pruebas del Sistema
VRREVDOC Reporte de verificación de documentos
VRREPRUPR Reporte de pruebas del Prototipo

Gestión de Configuración (SCM):

Nomenclatura Entregable
SCMIAUD Informe de la auditoría a la gestión de configuración
SCMPLAN Plan de SCM

​Gestión de Calidad (SQA):

Nomenclatura Entregable
SQADEVP Documento de evaluación y ajustes al Plan de SQA
SQAENS Entrega semanal de SQA
SQAINRV Informe de revisión de SQA
SQAINRTF Informe de Revisión Técnica Formal (RTF)
SQAINF Informe final de SQA
SQAPLAN Plan de SQA

​Gestión del Proyecto (GP):

Nomenclatura Entregable
GPACQ Acta de la Reunión Quincenal
GPDES Documento de Estimaciones
GPDEVP Documento de evaluación y ajustes del Plan del Proyecto
GPDRIES Documento de riesgos
GPICONF Informe de conclusiones de la Fase
GPISITP Informe de Situación del Proyecto
GPIFAD Informe final del Administrador
GPITERP Plan de la iteración
GPPLAN Plan del Proyecto
GPREGAC Registros de Actividad

1.1.2. Recuperación de los ítems de configuración

Documentación

Página 10 de 14
Se utilizará google Doc para la elaboración de documentos, ya que es útil a la hora de compartir, además
permite colaborar e interactuar entre participantes. Luego que los documentos son verificados y entregados,
pasan a almacenarse, los que correspondan según la planificación, a un repositorio Git en Github. Para este
repositorio sólo tendrán permisos de lectura todos los integrantes excepto el Administrador y SCMR. que
tendrán todos los privilegios.

Codigo fuente

Se utilizará otro repositorio Git en Github, donde mediante la utilización de ramas se mantendrá la línea de
desarrollo por un lado y por otro la línea estable o también denominado master que lo crea por default. Se
definirá y detalla más claramente el flujo de trabajo en la posteridad. Tendrán acceso a este repositorio
todos los integrantes del grupo. Se evaluará en una etapa posterior si resulta necesario mantener la línea
base del código fuente en un repositorio aparte con otros permisos de acceso.

1.2. Control de configuración

En esta sección se detallan las actividades de solicitud, evaluación, aprobación e implementación de

cambios a los elementos de la línea base. Los cambios apuntan tanto a la corrección como al mejoramiento.
El procedimiento que se describe a continuación es el que se utilizará cada vez que se precise introducir un
cambio al sistema. Se entiende por cambio al sistema, las modificaciones que afecten a la línea base del
sistema como ser:

● Cambios en los Requerimientos.

● Cambios en el Diseño.
● Cambios en la Arquitectura.
● Cambios en las herramientas de desarrollo.
● Cambios en la documentación del proyecto. (agregar nuevos documentos o modificar la estructura
de los existentes)

1.2.1. Solicitud de cambios

Para el proceso de desarrollo de la aplicación Silabamanía, se tendrá en cuenta que cerrada una
iteración, la línea base correspondiente pasa a ser la de la iteración siguiente. Toda modificación
debe quedar registrada (agregados y cambios) con una nota de la causa (comentario de CVS). Los
cambios a una línea base de una iteración surgen de agregados y modificaciones a lo ya hecho para
generar un nuevo incremento/iteración.
Los productos que requieren aprobaciones especiales y que se modifican, deben pasar por los
procedimientos de aprobación requeridos (ej: Requerimientos aprobados por el cliente que se
modifican, las modificaciones deben ser aprobadas por el cliente).
Formato: ​https://drive.google.com/open?id=1R2ib4Cq9hIH5iOqfH9gS4KnvPtcIj680

1.2.2. Evaluación de cambios

La evaluación del cambio involucra determinar qué es necesario hacer para implementar el cambio y
la estimación de sus costos y plazos. Se realiza en 2 pasos: 1. Planificación de la evaluación del
cambio que involucra:

● Revisar la solicitud de cambio para entender su alcance. (Si es necesario se discute con el
originador para aclarar el alcance de lo propuesto y los motivos de la solicitud.

Página 11 de 14
 ● Determinar las personas del proyecto que deben realizar el análisis de evaluación del cambio e
involucrarse.

● Desarrollar un Plan para la evaluación del cambio.

● Si el cambio involucra al Cliente, obtener el acuerdo de éste con el Plan.

2. Evaluar el cambio Dependiendo de las características del cambio, la evaluación del cambio
puede ser realizado por el administrador o ser delegado a otras personas del proyecto. Se debe
determinar el impacto en:

● Los productos técnicos.

● Los Planes de proyecto.
● Los acuerdos con el Cliente.
● Los Riesgos del proyecto.

1.2.3. Aprobación o desaprobación de cambios

Se debe formar el “Comité de Control de Configuración” y determinar su autoridad para la

aprobación de cambios. La composición de este comité puede variar según el tipo de cambio y las
líneas de trabajo involucradas en él. Se sugieren como posibles integrantes:

● Administrador (obligatorio)

● Arquitecto (opcional)

● Analista (opcional)

● Implementador (opcional)

● SCM (obligatorio)

● Cliente (opcional)

Se define un comité de Control de Configuración de nivel superior, compuesto por el Gerente de

proyecto, al cual se elevarán las solicitudes de cambios cuya aprobación o desaprobación no se
pueda resolver por el primer comité.

1.2.4. Implementación de los cambios

Una vez realizada la evaluación del cambio, se decide en qué momento implementarlo. Esta etapa
involucra los procesos necesarios para implementar la solicitud y monitorear el progreso del trabajo.

Además se especificará el momento de liberación del cambio; así como también los responsables
de las actividades que involucra el cambio. Recordando que nos basamos en un proceso de
desarrollo incremental e iterativo, donde en cada iteración se realizan tareas de Análisis de
requerimientos, Diseño, Implementación y Verificación; se debe introducir el cambio en el área que
lo originó y continuar con las actividades del ciclo (Requerimientos, Análisis, Diseño,
Implementación, Verificación) que impactarán los elementos de la línea base correspondientes a
cada actividad.

Página 12 de 14
1.3. Estado de la configuración

Las actividades de control de estado son para reunir información y reportar el estado de los
elementos de configuración. Se debe especificar lo siguiente:

● Qué elementos serán revisados de la línea base y por cambios a realizarse.

● Qué tipos de reportes de estado serán generados y con qué frecuencia.

● Como la información será obtenida, guardada, procesada, y reportada.

● Como será controlado el acceso a los datos de estado.

Si se utiliza una herramienta automática deberá ser especificada su funcionalidad y modo de uso
explícitamente o por referencia. En los reportes de estado de los elementos de configuración se
debe incluir como mínimo la siguiente información:

● Su primer versión aprobada.

● El estado de los cambios solicitados.

● El estado de implementación de los cambios aprobados.

1.4. Auditorías de configuración

Se realizarán auditorías de la línea base antes de una liberación de ésta o de una actualización de
la versión de un componente prioritario de ésta. Estas auditorías incluirán:

● Objetivo: el objetivo de todas las auditorías es verificar que en un momento dado la línea base se
compone de una colección consistente y bien definida de productos.

● Elementos de configuración bajo auditoría: se elegirán uno o más elementos de configuración de

mayor prioridad en la línea base

● Agenda de auditorías: antes de la liberación o actualización.

● Conducción: las auditorías serán dirigidas por el SCMR.

● Participantes: SCMR y los autores de los elementos de configuración a auditar.

● Documentos Requeridos: Documentos de SCR y reportes de estado de la configuración

generados.

● Reportes de Deficiencias y Acciones Correctivas: determinadas por los participantes.

● Criterio de Aprobación: lo determina el SCMR.

1.5. Control de interfaces

Las actividades de Control de Interfaces controlan los cambios a los elementos de configuración del
proyecto, que modifican las interfaces con elementos fuera del alcance del Plan. Este control será
llevado por el SCMR como parte del control de la configuración.

1.6. Control de subcontratos y vendedores

No aplica

Página 13 de 14
2. Agenda de SCM

Para el proceso de desarrollo de la aplicación Silabamanía, las actividades de SCM definidas en el

modelo de proceso son:

Actividad Entregable Asociado

Elaboración del Plan de SCM Plan de SCM
Definición de ambientes controlados Plan de SCM
Mantenimiento de la línea base del SW Informe de la auditoría a la gestión

3. Recursos de SCM

Recurso ID Nombre Propósito

1 Subversión Repositorio de Almacenamiento

2 MS Agents Agentes de Microsoft para interacción con el usuario

3 Peedy Agente de Microsoft con forma de ave

4 Visual Studio IDE de desarrollo

5 Microsof Access Gestor de Base de Datos local

6 Microsoft OLDB Controlador de la Base de Datos

7 Paquete de Microsoft Administrar la documentación generada

Office

8 Mario Navarrete Equipo de desarrollo

9 Dennys Iza Equipo de desarrollo

4. Referencias de esta guía

IEEE Std. 828 – 1990 Standard for Software Configuration Management Plans

IEEE Std. 1042 – 1987 IEEE Guide to Software Configuration Management

Documento de Actividades de Gestión de Configuración–Taller V–A.Delgado&B.Pérez 2000.

CMPLAN Exp. 2000 – Darío Sande Grupo 1 - para la sección 3.1.1

Página 14 de 14