2019

Universidad Politécnica del Estado de Morelos

Ingeniería de Software

Evidencia de producto 1: Plan de gestión

de la configuración de
software.

Profesora: Rosario Eloísa Huerta.

Alumno: Cesar Felipe Torres Jaimez.
Grado y grupo: 5° B.
Carrera: IIF.
 Cuestionario
1. ¿En qué consiste la gestión de la configuración del software
(GCS)?

Un plan de gestión de configuraciones realiza la descripción de los estándares y

procedimientos utilizados para la gestión de la configuración [3]. La Gestión de
Configuración se podría describir como un área de la Ingeniería de Software cuyo
objetivo es controlar la evolución de un producto desarrollado, involucrando un
conjunto de técnicas para gestionar con eficiencia los cambios que se realicen sobre
ese producto a lo largo de su ciclo de vida [2]. Los proyectos necesitan administrarse
porque la ingeniería de software profesional está sujeta siempre a restricciones
organizacionales de presupuesto y fecha [4].

2. Lista y explica en qué consisten cada uno los estándares que se

consideran en la gestión de configuración del software.
Estándar Sección Descripción
IEEE 828 IEEE Planes de gestión de
configuración de
software.
IEEE 1042 IEEE Gestión de configuración
del software.
ISO 10007-1995 ISO Gestión de calidad,
lineamientos para GC.
ISO/IEC 12207 ISO Tecnología de la
información, procesos de
ciclo de vida de software.
ISO/IEC TR 15271 ISO Guía para ISO/IEC 12207
ISO/IEC TR 15271 ISO Ingeniería de software;
Procesos de ciclo de vida
de software; Gestión de
configuración para
software.
EIA 649 EIA Estándar de consenso
nacional para gestión de
configuración.
EIA CMB4-1A EIA Definiciones de gestión
de configuración para
1
 programas de
computadoras digitales.
EIA CMB4-2 EIA Identificación de
configuración para
programas de
computadoras digitales.
EIA CMB4-3 EIA Librerías de software de
computadora.
EIA CMB4-4 EIA Control de cambio de
configuración para
programas de
computadoras digitales.
EIA CMB6-1C EIA Referencias de gestión de
configuración y datos
EIA CMB6-3 EIA Identificación de
configuración
EIA CMB6-4 EIA Control de configuración
EIA CMB6-5 EIA Libro de texto para
contabilidad del estado
de configuración.
EIA CMB67-1 EIA Intercambio electrónico
de datos de gestión de
configuración.

3. Los elementos o productos (artefactos) que se generan en el plan

de GCS son los listados a continuación, describe en qué consiste
cada uno de ellos.

a) Plan de proyecto.
El plan de proyecto establece los recursos, divide el trabajo y crea una
calendarización del trabajo. En algunas empresas, el plan del proyecto es un único
documento que incluye todos los diferentes tipos de planes.

Muchos planes pueden incluir las siguientes secciones:

1. Introducción: Descripción breve de los objetivos del proyecto y las

restricciones que afectan la gestión del proyecto.
2. Organización del proyecto: Describe la manera en la que el equipo
desarrollador está organizado, la gente que participa y sus roles.
2
 3. Análisis de riesgo: Descripción de los posibles riesgos, la probabilidad de que
surjan estos riesgos y las estrategias de reducción de riesgos propuestas.
4. Requerimientos de recursos de hardware y software: Descripción del hardware
y software de ayuda requerido para llevar a cabo el desarrollo.
5. División del trabajo: Descripción de la división del proyecto en actividades e
identifica los hitos y productos entregados en cada actividad.
6. Programa del proyecto: Descripción de las dependencias entre actividades, el
tiempo estimado requerido para alcanzar cada hito y la asignación del equipo
de trabajo a las actividades.
7. Mecanismos de supervisión e informe: Descripción de gestión de informes y la
fecha en que deben generarse.

b) Plan de gestión de la configuración.

Un plan de gestión de configuraciones se encarga de realizar la descripción de los
estándares y procedimientos utilizados para la gestión de la configuración. El punto
de Inicio para desarrollar el plan es un conjunto de estándares generales de gestión
de la configuración de toda la compañía adaptables a cada proyecto específico.

El plan de gestión de la configuración está organizado en distintos capítulos del que

incluyen:

 Especificación de los elementos de la configuración y el esquema forma para

identificar estás entidades.
 Un enunciado de que integrante del equipo de trabajo toma la
responsabilidad de los procedimientos de gestión de configuraciones y quién
envía las entidades controladas al equipo de gestión de configuraciones.
 Las políticas de gestión de configuraciones utilizadas para gestionar el control
de los cambios y versiones.
 Descripción de las herramientas que se van a utilizar en la gestión de
configuraciones.
 Una definición de la base de datos de la configuración que se va a utilizar para
el registro de la información de la configuración.

Una parte esencial del plan de gestión de configuración es la definición de las

responsabilidades.

c) Documento de definición de requerimientos.

3
El documento de requerimientos del software es la declaración oficial de que deben
implementar desarrolladores del sistema. Este documento es necesario que incluya
tanto los requerimientos del usuario para el sistema como una especificación
detallada de los requerimientos del sistema. Para realizar los requerimientos del
usuario, se definen en la introducción a la especificación de requerimientos del
sistema.

Este documento tiene una gran diversidad de usuarios que va desde los altos cargos
de la organización que pagan por el sistema y también los ingenieros que desarrollan
el software. Este documento contiene las siguientes fases:

 Introducción: Está fase enfoca el propósito del documento, alcance del

producto y la descripción del resto del documento.
 Descripción general: Se enfoca principalmente en la perspectiva del producto,
funciones del producto, características del usuario, restricciones generales,
suposiciones y dependencias.
 Requerimientos específicos: Incluye los requerimientos funcionales, no
funcionales y de interfaz.
 Apéndices e índice.

d) Estándares de análisis, diseño, codificación, pruebas y

auditorías.

e) Documentos de análisis del sistema.

El documento de análisis del sistema ofrece las descripciones del servicio y
restricciones del sistema, estás descripciones y restricciones son los requerimientos
del sistema. Por medio de la especificación de requerimientos se obtiene el análisis
detallado de las necesidades y funciones del sistema. En otras palabras, se decide
que es lo que se quiere hacer.

f) Documentos de diseño del sistema.

Son documentos técnicos que funcionan como una guía para la codificación e
implementación de los sistemas que pueden ser desarrollados para una empresa u
organización.

Este documento técnico describe todos los detalles de diseño de la arquitectura y

de todos los componentes que la conforman, proporciona los detalles técnicos

4
requeridos por el grupo de programación para programar o producir cada uno de
los componentes de software del sistema, sirve de insumo para la planificación y
ejecución de las pruebas de unidad, integración y aceptación.

g) Prototipos.
Para empezar un prototipo es la versión inicial de un sistema de software que se usa
para la demostración de conceptos, tratar las opciones de diseño y encontrar más
soluciones para el problema y ver más acerca del problema. El desarrollo de un
prototipo es muy esencial, gracias a esto se pueden llegar a controlar costos.

Un prototipo de software se usa en un proceso de desarrollo de software para

contribuir a anticipar los cambios que se requieran [3].

En el proceso de ingeniería de requerimientos, un prototipo ayuda con la selección

y validación de los requerimientos. Permiten desarrollar ideas nuevas para
requerimientos y descubrir áreas de fortalezas y debilidades en el software.

h) Documentos de diseño de alto nivel.

Un documento de diseño de alto nivel da al analista la posibilidad de crear y
modificar el diseño del sistema. Toda la información relacionada con el proyecto se
almacena en una enciclopedia denominada depósito CASE, una enorme colección
de registros, elementos, diagramas, pantallas, informes e información diversa. Con la
información del depósito se podrían generar informes que muestren dónde está
incompleto el diseño o dónde contiene errores.

Los documentos de diseño de alto nivel también pueden apoyar la modelación de

los requerimientos funcionales de una organización, ayudar a los analistas y usuarios
a definir el alcance de un proyecto determinado y a visualizar la forma en que el
proyecto se combina con otras partes de la organización.

i) Documentos de diseño de bajo nivel.

Diseño de bajo nivel también conocido como diseño detallado, se utiliza
para diseñar las partes internas de los módulos individuales identificados
durante el diseño de alto nivel, mejor dicho, las estructuras de datos y los
algoritmos de los módulos están diseñados y documentados.

5
 Los diagramas de clases con todos los métodos y las relaciones entre
clases se clasifican en diseño de bajo nivel. Las especificaciones del
programa están cubiertas por este diseño. El documento de bajo nivel
describe todos y cada uno de los módulos de una manera elaborada para
que el programador pueda codificar directamente el programa en función
de ello. Habrá al menos 1 documento para cada módulo.

j) Especificaciones de prueba del sistema.

Es un conjunto de actividades que se planean con anticipación y se realizan de
manera sistemática. Estás especificaciones contienen las siguientes características
genéricas:

 El equipo de software debe efectuar revisiones técnicas formales y efectivas.

Esto puede eliminar muchos errores antes de que empiece la prueba.
 Diferentes técnicas de prueba son apropiadas en diferentes momentos.
 La prueba y la depuración son actividades diferentes, pero la segunda debe
incluirse en cualquier estrategia de prueba.

Las pruebas son un elemento de un tema amplio que suele denominarse

verificación y validación [1].

k) Plan de pruebas del sistema.

En cualquier proyecto de software se presenta un conflicto de interés cuando
comienzan las pruebas. Ahora se pide a las personas que han desarrollado el
software que lo prueben.

Roger S. Pressman en su libro “Ingeniería de software, un enfoque practico” nos dice:

“El optimismo es el peligro ocupacional de la programación, la prueba, el

tratamiento”.

A continuación, se presentan una lista de las fases del plan de pruebas:

 Especificar los requisitos del producto de manera cuantificable mucho antes

que empiecen las pruebas.
 Estableces explícitamente los objetivos de la prueba.

6
  Comprender cuales son los usuarios del software y desarrollar un perfil para
cada categoría de usuario.
 Construir un software “robusto” diseñado para probarse así mismo.
 Usar revisiones técnicas formales y efectivas como filtro previo a la prueba.

l) Código fuente del programa.

El código fuente es texto simple, capaz de ser leído por cualquier editor de textos y
lo que es más importante, comprensible por cualquier programador que conozca el
''idioma'' utilizado. En él están escritas las instrucciones que deberá realizar la
computadora, según la sintaxis de un lenguaje de programación.

m) Código objeto y ejecutable.

El código objeto es el resultado de compilar el código fuente. Podría decirse que es
un conjunto de instrucciones y datos escritos en un lenguaje que es capaz de
entender el ordenador directamente: binario. Provienen de la traducción de cierto
código fuente, es un fragmento del programa final y es específico de la plataforma
de ejecución.

El código ejecutable es el resultante de enlazar los archivos del código de objeto con
ciertas rutinas y bibliotecas necesarias. Es decir que el sistema operativo es el
encargado de cargar el código ejecutable en memoria RAM y proceder a ejecutarlo.

n) Especificaciones de pruebas de unidad.

La prueba de unidad enfoca los esfuerzos de verificación en la unidad más pequeña
del diseño de software. Las pruebas de unidad son el proceso de probar
componentes del programa, como métodos o clases de objetos. Las funciones o los
métodos individuales son el tipo más simple de componente. Las pruebas deben
llamarse para dichas rutinas con diferentes parámetros de entrada. La interfaz del
módulo se prueba para garantizar que la información fluya de manera adecuada
hacia y desde la unidad de software que se está probando.

7
o) Planes de pruebas de unidad.
Los planes de prueba de unidad se aplican para cada clase. El diseño de pruebas para
una clase usa varios planes: prueba basada en fallo, prueba aleatoria y prueba de
partición. Cada uno de éstos ejercita las operaciones encapsuladas por la clase. Las
secuencias de prueba se diseñan para garantizar que se ejercitan las operaciones
relevantes. El estado de la clase, representado por los valores de sus atributos, se
examina para determinar si existen errores.

p) Documentos de diseño de base de datos.

Sin importar su organización lógica y su estructura física, los documentos de base
datos permiten definir los objetos de datos y soportar algún método para establecer
relaciones entre los objetos. El documento de diseño de base datos contiene:

 Modelo de objeto inicial.

 Determinar claves candidatas para denominar las llaves primarias.
 Refinar las clases tentativas.
 Definir generalizaciones.

q) Datos de prueba.
La revisión de la información del diseño proporciona una guía para establecer datos
de prueba que es probable que descubran errores en cada una de las categorías
analizadas anteriormente. Cada dato de prueba debe acoplarse con un conjunto de
resultados esperados.

r) Datos del proyecto.

Un equipo auto dirigido tiene la comprensión consistente de sus metas y objetivos
generales; define el papel y responsabilidad de cada miembro del equipo; da
seguimiento cuantitativo a los datos del proyecto (sobre la productividad y calidad);
identifica un proceso de equipo que sea apropiado para el proyecto y una estrategia
para implementarlo; define estándares locales aplicables al trabajo de ingeniería de
software del equipo; evalúa en forma continua el riesgo y reacciona en consecuencia;
y da seguimiento, administra y reporta el estado del proyecto.

s) Manuales de usuario.
Un manual de usuario se trata de una guía que ayuda a entender el funcionamiento
de algo sin la necesidad de que el usuario conozco temas centralizados en la

8
programación, está más enfocado a brindar el conocimiento de uso del sistema,
describiendo las funciones de este. Es un documento de comunicación técnica que
busca brindar asistencia a los sujetos que usan un sistema o servicio.

4. En la gestión de configuración se utiliza el término “línea base”,

explica en qué consiste.

Una línea base es la colección de versiones de componente con las que es construido
un sistema. Las líneas base están controladas, lo que explica que las versiones de los
componentes que conforman el sistema no pueden ser cambiadas.

Las líneas base pueden especificarse mediante un lenguaje de configuración, esto

permite especificar cuáles componentes se incluyen en una versión de un sistema en
particular.

Esta información nos da a conocer que las líneas base son importantes porque la
mayoría de las veces puede ser necesario volver a crear una versión especifica de
un sistema completo [3].

5. Durante el desarrollo del software existe más de una línea base,

por ejemplo, la línea base de planificación. ¿Qué otras líneas base
se consideran durante el desarrollo del software?

Las Líneas Base pueden ser definidas con cualquier nivel de detalle, no obstante, las
más difundidas son las siguientes:

 Línea Base de Sistema: Se lleva a cabo al finalizar la fase de Especificación de

Requisitos del sistema global, y comprende todos aquellos documentos en
los que se define el problema a resolver a nivel sistema, el plan de tiempos
del proyecto y estimaciones, los modelos de la situación y del dominio, el
estudio de viabilidad y las especificaciones del sistema.

 Línea Base Funcional: Se establece al finalizar la fase de Análisis de Requisitos

y esta contiene los documentos donde se ha establecido la Especificación
formal de Requisitos de Software, el Plan de Pruebas y la conformidad del
cliente sobre la especificación formal de requisitos.

9
 Línea Base de Diseño: Es establecida al finalizar la fase de Diseño Detallado y
comprende la documentación relacionada con las descripciones de diseño del
software, de la arquitectura, de los flujos de información, de las bases de datos
(sí es de aplicación), etc.

 Línea Base de Producto: Se establece al finalizar las fases de Codificación y

Pruebas y contiene no sólo la documentación relacionada con estas fases.

 Línea Base Operativa: Se establece al finalizar la fase de Instalación o

Implantación, comprende la documentación relacionada con las tareas de
operación y mantenimiento, plan de formación, recomendaciones de
mantenimiento y Plan de Retiro.

6. ¿Qué temas debe integrar el plan de gestión de configuración de

software? Lístalos y explica cada uno de ellos, por ejemplo,
Panorama general del proyecto.
En el plan de gestión de configuración de software se fijan los recursos que
van a estar disponibles para el proyecto, la división del trabajo y un calendario
para realizar cada actividad.
Aunque los detalles específicos de los planes de proyecto varían dependiendo
del tipo de proyecto y organización, los planes regularmente incluyen los
siguientes temas:
 Introducción: Es una descripción breve de los objetivos del proyecto y
establece las restricciones que afectan la gestión del proyecto.

 Organización del proyecto: Ésta etapa hace referencia a la forma en que

está organizado el equipo de desarrollo, las personas implicadas y sus
roles de trabajo en el equipo.

 Análisis de riesgo: Especifica los posibles riesgos del proyecto, la

probabilidad de que surjan dichos riesgos y las estrategias propuestas
para reducir el riesgo.

10
  Requerimientos de recursos de hardware y software: Detallan el
hardware y el software de soporte requeridos para realizar el
desarrollo.

 División del trabajo: Establece la división del proyecto en actividades e

identifica los plazos de tiempo y las entregas asociados con cada
actividad a desarrollar. Los plazos son las etapas clave del proyecto
donde puede valorarse el avance; las entregas son productos de
trabajo que se proporcionan al cliente.

 Calendario del proyecto: Indica las dependencias entre las actividades,

el tiempo estimado requerido para alcanzar cada plazo y la asignación
de personal a las actividades.

 Mecanismos de monitorización y reporte: Esta sección define los

informes administrativos que deben producirse, cuándo tienen que
elaborarse y los mecanismos de monitorización del proyecto que se
usarán.

7. ¿Qué productos (artefactos) del plan de gestión de la

configuración del software se elaboran durante el desarrollo del
software? Lístalos y descríbelos.
 Plan de proyecto.

El plan de proyecto establece los recursos, divide el trabajo y crea una

calendarización del trabajo. En algunas empresas, el plan del proyecto es un único
documento que incluye todos los diferentes tipos de planes.

Muchos planes pueden incluir las siguientes secciones:

1. Introducción: Descripción breve de los objetivos del proyecto y las

restricciones que afectan la gestión del proyecto.

2. Organización del proyecto: Describe la manera en la que el equipo

desarrollador está organizado, la gente que participa y sus roles.

11
3. Análisis de riesgo: Descripción de los posibles riesgos, la probabilidad de que
surjan estos riesgos y las estrategias de reducción de riesgos propuestas.

4. Requerimientos de recursos de hardware y software: Descripción del hardware

y software de ayuda requerido para llevar a cabo el desarrollo.

5. División del trabajo: Descripción de la división del proyecto en actividades e

identifica los hitos y productos entregados en cada actividad.

6. Programa del proyecto: Descripción de las dependencias entre actividades, el

tiempo estimado requerido para alcanzar cada hito y la asignación del equipo de
trabajo a las actividades.

7. Mecanismos de supervisión e informe: Descripción de gestión de informes y

la fecha en que deben generarse.

 Documentos de análisis del sistema.

El documento de análisis del sistema ofrece las descripciones del servicio y

restricciones del sistema, estás descripciones y restricciones son los requerimientos
del sistema. Por medio de la especificación de requerimientos se obtiene el análisis
detallado de las necesidades y funciones del sistema. En otras palabras, se decide
que es lo que se quiere hacer.

 Documentos de diseño del sistema.

Son documentos técnicos que funcionan como una guía para la codificación e
implementación de los sistemas que pueden ser desarrollados para una empresa u
organización.

Este documento técnico describe todos los detalles de diseño de la arquitectura y

de todos los componentes que la conforman, proporciona los detalles técnicos
requeridos por el grupo de programación para programar o producir cada uno de
los componentes de software del sistema, sirve de insumo para la planificación y
ejecución de las pruebas de unidad, integración y aceptación.

 Código fuente del programa.

El código fuente es texto simple, capaz de ser leído por cualquier editor de textos y
lo que es más importante, comprensible por cualquier programador que conozca el
''idioma'' utilizado. En él están escritas las instrucciones que deberá realizar la
computadora, según la sintaxis de un lenguaje de programación.

12
  Planes de pruebas de unidad.

Los planes de prueba de unidad se aplican para cada clase. El diseño de pruebas
para una clase usa varios planes: prueba basada en fallo, prueba aleatoria y prueba
de partición. Cada uno de éstos ejercita las operaciones encapsuladas por la clase.
Las secuencias de prueba se diseñan para garantizar que se ejercitan las
operaciones relevantes. El estado de la clase, representado por los valores de sus
atributos, se examina para determinar si existen errores.

 Manuales de usuario.

Un manual de usuario se trata de una guía que ayuda a entender el

funcionamiento de algo sin la necesidad de que el usuario conozco temas
centralizados en la programación, está más enfocado a brindar el conocimiento de
uso del sistema, describiendo las funciones de este. Es un documento de
comunicación técnica que busca brindar asistencia a los sujetos que usan un
sistema o servicio.

 Manual técnico

Un manual técnico es aquel que va dirigido a un público con conocimientos

técnicos sobre algún área. La documentación de proyectos es importante para
identificar más fácilmente los aspectos y características que forman parte de un
proyecto. La finalidad de todo manual técnico es la de proporcionar al lector la
lógica con lo que ha desarrollado un software, la cual se sabe que es propia de
cada programador; por lo que se considera ser documentada.

13
Referencias Bibliográficas
[1] Pressman, R. S. (2005). Ingeniería de software. Un enfoque practico. México:
MCGRAW-HILL.

[2] Rancán, C. J. (2003). Gestión de configuración de productos en etapa de

desarrollo de software. TRABAJO FINAL ESPECIALIDAD EN CONTROL Y
GESTION DE SOFTWARE, 173.

[3] Sommerville, I. (2005). Ingeniería del software. Madrid: Pearson Educación.

[4] Sommerville, I. (2011). Ingeniería de software. México: Pearson Educación.

14