1.
UNIDAD 2
PLANIFICACION DEL
SISTEMAS
Objetivo: Realizará la planificación de
un proyecto de software de una
organización

2. UNIDAD II / PLANIFICACION DEL SISTEMA
2.1. PLANIFICACIÓN DEL TIEMPO
Uno de los factores más conocidos por los participantes de un proyecto es el del tiempo.
Podrán no conocer el costo financiero, podrán no conocer que recursos (que también
integran los costos, porque al final también se traducen en gastos) se utilizan en dicho
proyecto, pero lo que si se suele saber es para cuando el proyecto debe estar concluido.
Por lo tanto, el tiempo es la delimitación más conocida. Todo proyecto está
sujeto al tiempo, a una duración. La mayoría de los proyectos tienen una fecha límite
para la que el proyecto deberá estar concluido. Además, el proyecto posiblemente
disponga de una serie actividades que se deben cumplir.La duración de las tareas es el
periodo de tiempo que transcurre entre la fecha de comienzo de una tarea y su fecha de
finalización.
¿Como podemos establecer la duración de una tarea?
¿Existe alguna técnica que nos ayude a definirla?
LA DURACIÓN DE LAS TAREAS SE ESTABLECE APLICANDO ALGUNO DE
ESTOS FACTORES:
• La Historia: Consiste en establecer una consultoría sobre similares proyectos
realizados con anterioridad y recoger datos históricos. Como se hicieron, cuanto duraron
sus tareas. etc.
• La Participación: Consiste en contar con personas que tengan experiencia en
proyectos idénticos (mismo) aunque sean bajo otras circunstancias.
• La Intuición: Contar con personas que hayan realizado un proyecto con similares
características.
• La Indeterminación.: Hacer una estimación, a veces no basada en nada
concreto. (por impulsos).
2.2. EVALUACION DEL COSTO BENEFICIO
FACTORES EN EL COSTO DEL SOFTWARE
Existen muchos factores que influyen en el costo de un producto de programación. El
efecto de estos factores es difícil de estimar y, por ende también lo es el costo del
esfuerzo en el desarrollo o en el mantenimiento.
38

3. UNIDAD II / PLANIFICACION DEL SISTEMA
Entre los factores que afectan se observan, en forma primordial, las capacidades
individuales del personal asignado al proyecto y su familiaridad con el área de aplicación,
la complejidad del producto, el tamaño de éste, el tiempo asignado, el nivel de
confiabilidad, el nivel tecnológico utilizado; la disponibilidad, familiaridad y estabilidad del
sistema donde se desarrolla el producto.
ESTIMACIÓN DE COSTOS
Al principio, el costo del software constituía un pequeño porcentaje del costo total de los
sistemas basados en computadora. Un error considerable en las estimaciones del costo
del software tenía relativamente poco impacto. Hoy en día, el software es el elemento
más caro de la mayoría de los sistemas informáticos. Un gran error en la estimación del
costo puede ser lo que marque la diferencia entre beneficios y pérdidas. Sobrepasarse
en el costo puede ser desastroso para el equipo de desarrollo.
La estimación del costo y del esfuerzo del software nunca será una ciencia
exacta. Son demasiadas las variables humanas, técnicas, de entorno, políticas que
pueden afectar al costo final del software y al esfuerzo aplicado para desarrollarlo. Sin
embargo, la estimación del proyecto de software puede dejar de ser un oscuro arte para
convertirse en una serie de pasos sistemáticos que proporcionen estimaciones con un
grado de riesgo aceptable.
PARA REALIZAR ESTIMACIONES SEGURAS DE COSTOS Y ESFUERZOS
TENEMOS VARIAS OPCIONES POSIBLES:
• Dejar la estimación para más adelante (obviamente, ¡podemos realizar una
estimación al cien por cien fiable tras haber terminado el proyecto!).
• Basar las estimaciones en proyectos similares ya terminados.
• Utilizar «técnicas de descomposición» relativamente sencillas para generar las
estimaciones de costo y de esfuerzo del proyecto.
• Desarrollar un modelo empírico para el cálculo de costos y esfuerzos del
software.
Desafortunadamente, la primera opción, aunque atractiva, no es práctica. Las
estimaciones de costos han de ser proporcionadas a priori. Sin embargo, hay que
reconocer que cuanto más tiempo esperemos, más cosas sabremos, y cuanto más
sepamos, menor será la probabilidad de cometer serios errores en nuestras
estimaciones.
39

4. UNIDAD II / PLANIFICACION DEL SISTEMA
La segunda opción puede funcionar razonablemente bien si el proyecto actual es
bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares.
Desafortunadamente. La experiencia anterior no ha sido siempre un buen indicador de
futuros resultados.
Las opciones restantes son métodos viables para la estimación del proyecto de
software. Desde un punto de vista ideal, se deben aplicar conjuntamente las técnicas
indicadas. Usando cada una de ellas como comprobación de las otras.
Las técnicas de descomposición utilizan un enfoque de «divide y vencerás» para
la estimación del proyecto de software.
Dentro de la mayor parte de las organizaciones, la estimación de costos de la
programación se basa en las experiencias pasadas. Los datos históricos se usan para
identificar los factores de costo y determinar la importancia relativa de los diversos
factores dentro de la organización. Lo anterior, por supuesto, significa que los datos de
costos y productividad de los proyectos actuales deben ser centralizados y almacenados
para un empleo posterior. La estimación de costos puede llevarse acabo en forma
jerárquica hacia abajo o en forma jerárquica hacia arriba (Bottom-Up).
La estimación jerárquica hacia abajo
Se enfoca primero a los costos del nivel del sistema, así como a los costos de manejo
de la configuración, del control de calidad, de la integración del sistema, del
entrenamiento y de las publicaciones de documentación. Los costos del personal
relacionado se estiman mediante el examen del costo de proyectos anteriores que
resulten similares.
La estimación jerárquica hacia arriba
Primero se estima el costo del desarrollo de cada módulo o subsistema; tales costos se
integran para obtener un costo total.
Esta técnica tiene la ventaja de enfocarse directamente a los costos del sistema,
pero se corre el riesgo de despreciar diversos factores técnicos relacionados con
algunos módulos que se desarrollarán. La técnica subraya los costos asociados con el
desarrollo independiente de cada módulo o componente individual del sistema, aunque
puede fallar al no considerar los costos del manejo de la configuración o del control de
calidad.
40

5. UNIDAD II / PLANIFICACION DEL SISTEMA
En la práctica, ambas técnicas deben desarrollarse y compararse para que
iterativamente se eliminen las diferencias obtenidas.
PARA ANALIZAR UN ANÁLISIS DE COSTO-BENEFICIO SE DEBE TOMAR EN
CUENTA LAS SIGUIENTES RECOMENDACIONES:
Para obtener el costo.
1.-Identificar primeramente el costo de la inversión más importante de acuerdo a su
monto.
2.-Identificar los costos complementarios consecuencia del punto1.
Para obtener el beneficio
Es necesario que los beneficios que genere un proyecto sean traducidas al mismo tipo
de unidad que se manejan en los costos para que estos puedan ser comparados y por lo
tanto se facilite la toma de decisiones.
PARA OBTENER ESTA INFORMACIÓN SE RECOMIENDA LO SIGUIENTE:
• Identificar todo el problema que se pretenda resolver con la implantación del
proyecto.
• Cada problema debe ser traducido a la unidad de referencia del costo y
referenciado a una cierta unidad de tiempo, por ej. Costo por día, por hora, etc.
2.3. ESTUDIO DE VIABILIDAD
Todos los proyectos son posibles: ¡si se tiene infinitos recursos y tiempo!
Desgraciadamente, el desarrollo de un sistema o producto basado en
computadora es muy probable que esté plagado de escaséese de recursos y de fechas
de entrega difíciles (o totalmente no realistas). Es necesario y prudente evaluar la
viabilidad de un proyecto cuanto antes. Se pueden evitar meses o años de esfuerzo,
miles o millones de dólares y un bochorno profesional indecible si se reconoce un
sistema mal concebido en la pronta fase de definición. La viabilidad y el análisis de
riesgo están relacionados de muchas maneras. Si el riesgo del proyecto es alto la
viabilidad de producir software de calidad se reduce. Durante la ingeniería de producto,
sin embargo, concentramos nuestra atención en cuatro áreas principales de interés:
41

6. UNIDAD II / PLANIFICACION DEL SISTEMA
Viabilidad económica.
Una evaluación del costo de desarrollo sopesado con los ingresos netos o beneficios
obtenidos del sistema o producto desarrollado.
Viabilidad técnica.
Un estudio de función, rendimiento y restricciones que puedan afectar a la consecución
de un sistema aceptable.
Viabilidad legal.
Determinar cualquier infracción, violación o responsabilidad legal en que se podría
incurrir por el desarrollo del sistema.
Viabilidad alternativa.
Una evaluación de los enfoques alternativos al desarrollo del sistema o producto.
No es necesario un estudio de viabilidad para sistemas en que la justificación
económica es obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no
existe ninguna alternativa razonable.
Sin embargo, si falla alguna de las condiciones anteriores, se debería hacer un
estudio del área en cuestión.
La justificación económica incluye una amplia gama de aspectos a tener en
cuenta como son el análisis de costes/beneficios, las estrategias de ingresos de la
empresa a largo plazo, el impacto en otros productos o centros de beneficios, coste de
recursos necesarios para el desarrollo y crecimiento potencial del mercado.
La viabilidad tecnológica es frecuentemente el área más difícil de valorar en esta
etapa del proceso de ingeniería del producto. Como los objetivos, funciones y
rendimiento son poco claros, cualquier cosa parece posible si se hacen las suposiciones
correctas. Es esencial que el proceso de análisis y definición se realice en paralelo con
una valoración de la viabilidad técnica. De esta manera se pueden juzgar
especificaciones concretas a medida que se establecen.
42

7. UNIDAD II / PLANIFICACION DEL SISTEMA
2.4. PLANIFICACION DE LA DOCUMENTACION
Plan de documentación. Su función es definir y controlar la documentación asociada
con el proyecto.
La buena documentación proporciona una explicación de la forma en que opera
el sistema y qué características tienen los modelos y algoritmos utilizados en él. Muchos
paquetes de hoja de cálculo y de ayuda para la toma de decisiones guardan todos estos
detalles en forma automática a medida que se van especificando.
Aunque esta información es transparente para el usuario, se puede recuperar cuando
sea necesario ya sea en forma impresa o a través de una pantalla. Muchos lenguajes de
cuarta generación son auto-documentados, lo que significa que los propios programas
son tan fáciles de entender que ellos se convierten en su propia documentación. La
lectura del código explica lo que hace el programa.
IMPORTANCIA DE LA DOCUMENTACION
La documentación de los programas es un aspecto sumamente importante, tanto
en el desarrollo de la aplicación como en el mantenimiento de la misma.
Mucha gente no lo hace parte del desarrollo y no se da cuenta de que pierde la
posibilidad de la reutilización de parte del programa en otras aplicaciones, sin necesidad
de conocerse el código al dedillo. La documentación de un programa empieza a la vez
que la construcción del mismo y finaliza justo antes de la entrega del programa o
aplicación al cliente. Así mismo, la documentación que se entrega al cliente tendrá que
coincidir con la versión final de los programas que componen la aplicación. Una vez
concluido el programa, los documentos que se deben entregar son una guía técnica, una
guía de uso y de instalación.
TIPOS DE DOCUMENTACIÓN:
La documentación que se entrega al cliente se divide claramente en dos categorías:
Interna: Es aquella que se crea en el mismo código, ya puede ser en forma de
comentarios o de archivos de información dentro de la aplicación.
Externa: Es aquella que se escribe en cuadernos o libros, totalmente ajena a la
aplicación en si. Dentro de esta categoría también se encuentra la ayuda electrónica.
43

8. UNIDAD II / PLANIFICACION DEL SISTEMA
La guía técnica
En la guía técnica o manual técnico se reflejan el diseño del proyecto, la codificación de
la aplicación y las pruebas realizadas para su correcto funcionamiento.
Generalmente este documento esta diseñado para personas con conocimientos de
informática, generalmente programadores. El principal objetivo es el de facilitar el
desarrollo, corrección y futuro mantenimiento de la aplicación de una forma rápida y fácil.
ESTA GUÍA ESTA COMPUESTA POR TRES APARTADOS CLARAMENTE
DIFERENCIADOS:
• Cuaderno de carga: Es donde queda reflejada la solución o diseño de la
aplicación.
Esta parte de la guía es únicamente destinada a los programadores. Debe estar
realizado de tal forma que permita la división del trabajo
• Programa fuente: Es donde se incluye la codificación realizada por los
programadores. Este documento puede tener, a su vez, otra documentación para su
mejor comprensión y puede ser de gran ayuda para el mantenimiento o desarrollo
mejorado de la aplicación. Este documento debe tener una gran claridad en su escritura
para su fácil comprensión.
• Pruebas: Es el documento donde se especifican el tipo de pruebas realizadas a
lo largo de todo el proyecto y los resultados obtenidos.
La guía de uso
Es lo que comúnmente llamamos el manual del usuario. Contiene la información
necesaria para que los usuarios utilicen correctamente la aplicación. Este documento se
hace desde la guía técnica pero se suprimen los tecnicismos y se presenta de forma que
sea entendible para el usuario que no sea experto en informática. Un punto a tener en
cuenta en su creación es que no debe hacer referencia a ningún apartado de la guía
técnica y en el caso de que se haga uso de algún tecnicismo debe ir acompañado de un
glosario al final de la misma para su fácil comprensión.
La guía de instalación
Es la guía que contiene la información necesaria para implementar dicha aplicación.
Dentro de este documento se encuentran las instrucciones para la puesta en marcha del
sistema y las normas de utilización del mismo. Dentro de las normas de utilización se
incluyen también las normas de seguridad, tanto las físicas como las referentes al
acceso a la información.
44

9. UNIDAD II / PLANIFICACION DEL SISTEMA
GUIA PARA ELABORAR UN REPORTE
Formato del reporte escrito
El formato del escrito depende de la cantidad de información disponible, la complejidad
del asunto, la naturaleza del trabajo y otros factores que se toman en cuenta para la
preparación de bosquejos. Puede estar determinada por los reglamentos de la
institución, organización o empresa.
A CONTINUACIÓN SE MUESTRA EL FORMATO PARA LA ELABORACIÓN DEL
REPORTE DE UN PROYECTO:
1. Portada.
2. Índice.
3. Introducción.
4. Justificación.
5. Objetivos generales y específicos.
6. Problemas resueltos.
7. Alcances y limitaciones de las soluciones.
8. Procedimientos y descripción de las actividades realizadas.
9. Resultados (planos, gráficas, prototipos, programas, etc.).
10. Conclusiones y recomendaciones.
11. Referencias bibliográficas.
2.5. GESTION DE LA CONFIGURACION DE SOFTWARE
Se denomina Gestión de la Configuración el conjunto de procesos destinados a asegurar
la validez que todo producto obtenido durante cualquiera de las etapas del desarrollo de
un Sistema de Información (S.I.), a través del estricto control de los cambios realizados
sobre los mismos y de la disponibilidad constante de una versión estable de cada
elemento para toda persona involucrada en el citado desarrollo. Estos dos elementos
(control de cambios y control de versiones de todos los elementos del S.I.) facilitan
también el mantenimiento de los sistemas al proporcionar una imagen detallada del
sistema en cada etapa del desarrollo.
45

10. UNIDAD II / PLANIFICACION DEL SISTEMA
La gestión de la configuración se realiza durante todas las fases del desarrollo de un
sistema de información, incluyendo el mantenimiento y control de cambios, una vez
realizada la puesta en producción.
La gestión de la configuración del software es uno de los procesos clave para
toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor
organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos
de producción. Durante el proceso de construcción de un software, los cambios son
inevitables.
Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han
analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones
que pueden ocurrirle al software dentro de todo el proceso de ingeniería.
“El arte de coordinar el desarrollo de software para minimizar…la confusión, se
denomina gestión de la configuración. La gestión es el arte de identificar, organizar y
controlar las modificaciones que sufre el software…la meta es maximizar la productividad
minimizando errores.”
LOS CAMBIOS DENTRO DEL DESARROLLO DEL SOFTWARE PUEDEN OCURRIR
EN CUALQUIER MOMENTO POR LO TANTO DEBEMOS ESTAR PREPARADOS,
LAS ACTIVIDADES DE CGS SIRVEN PARA:
• Identificar el cambio de nuestro software.
• Controlar ese cambio.
• Garantizar que el cambio quede bien implantado.
• Informar el cambio.
La gestión de configuración del software no es un mantenimiento del software, el
mantenimiento es la etapa final de la ingeniería hasta que se retire el producto del
equipo, la CGS es un conjunto de actividades de seguimiento y control que comienzan
cuando se inicia el proyecto de desarrollo del software y termina sólo una vez que el
software queda fuera de circulación.
Desgraciadamente, en el proceso de ingeniería del software existe una variable
importantísima que entra en juego, el cambio.
46

11. UNIDAD II / PLANIFICACION DEL SISTEMA
La primera Ley de la ingeniería de sistemas establece: “Sin importar en que momento del
ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo
persistirá a lo largo de todo el ciclo de vida”.
Entonces nos hacemos diferentes preguntas: ¿Por qué cambiar el sistema?
¿Que produce los en el sistema cambios? La respuesta a estas interrogantes se puede
encontrar en cuatro aspectos fundamentales y a menudo muy tradicionales dentro del
desarrollo del software:
• Nuevos requisitos del negocio o condiciones que dictan los cambios en las
condiciones del producto o en las normas comerciales.
• Nuevas necesidades del los clientes que demandan la modificación de los datos
producidos por un sistema basado en computadora.
• Reorganización y/o reducción del volumen comercial que provoca cambios en las
prioridades del proyecto o en la estructura del equipo de ingeniería del software.
• Restricciones presupuestarias o de planificaciones que provocan una redefinición
del sistema o del producto.
La gestión de configuración del software realiza un conjunto de actividades
desarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida del
software de computadora.
La GCS es una actividad de garantía de calidad del software que se aplica en todas las
fases del proceso de ingeniería del software.
LINEAS BASE
Una línea base es un concepto de gestión de configuración del software que nos ayuda a
controlar los cambios sin impedir seriamente los cambios justificados. La IEEE define
una línea base como: Una especificación o producto que se ha revisado formalmente y
sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base
para un desarrollo posterior y que puede cambiarse solamente a través de
procedimientos formales de control de cambios.
En el contexto de la ingeniería del software definimos una línea base como un
punto de referencia en el desarrollo del software y que queda marcado por el envío de
uno o más elementos de configuración del software (ECS) y la aprobación de ECS
obtenido mediante una revisión técnica formal.
47

12. UNIDAD II / PLANIFICACION DEL SISTEMA
Por ejemplo, los elementos de una especificación de diseño se documentan y se revisan.
Se encuentran errores y se corrigen cuando todas las partes de las especificaciones se
han revisado corregido y aprobado, la especificación de diseño se convierte en línea
base. Solo se pueden realizar cambios futuros en la arquitectura del software
(contenidos en la especificación del diseño) tras haber sido evaluados y aprobados.
ELEMENTO DE CONFIGURACIÓN DE SOFTWARE
Un elemento de la configuración del software es la información creada como parte del
proceso de ingeniería un ECS (elemento de configuración de software) es un
documento, un conjunto completo de casos de prueba o un componente de un programa
dado.
Los siguientes ECS son el objetivo de las técnicas de gestión de configuración y forman
un conjunto de líneas base:
1) Especificación del sistema
2) Plan de proyecto
3) Especificación de requisitos
4) Prototipo ejecutable o “en papel”
5) Manual de usuario preliminar
6) Especificación de diseños
7) Descripción del diseño de datos
8). Descripción del diseño arquitectónico
9) Descripciones del diseño de los módulos
10) Descripciones del diseño de interfaces
11) Descripciones de los objetos (si se utilizan técnicas de P.O.O)
12) Listados del código fuente
13). Plan y procedimiento de pruebas
48

13. UNIDAD II / PLANIFICACION DEL SISTEMA
14) Casos de prueba y resultados registrados
15) Manuales de operación de y de instalación
16) Programas ejecutables
17) Módulos, código ejecutable
18) Módulos enlazados
19) Descripción de la base de datos
20) Esquema y estructura de archivos
21) contenido inicial
22) Manual del usuario final
23) Documentos de mantenimiento
24). Informes de problemas del software
25) Peticiones de mantenimiento
26). Ordenes de cambios e ingeniería
Es importante considerar poner las herramientas de desarrollo de software bajo control
de configuración. Es decir congelar la versiones de editores, compiladores y otras
herramientas CASE utilizadas durante el desarrollo, un cambio en las versiones
utilizadas puede que produzca resultados diferentes que la versión original.
Los ECS se organizan como objetos de configuración que deben ser catalogados
por la base de datos del proyecto con un nombre único. Un ECS tiene un nombre y
atributos, y está conectado a otros objetos mediante relaciones.
49

14. UNIDAD II / PLANIFICACION DEL SISTEMA
La figura se muestra el modelo de datos de los elementos de al configuración,
cada objeto esta relacionado con otro, si se lleva a cabo un cambio sobre un objeto la
interrelaciones señalan a que otros objetos afectará.
EL PROCESO DE GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
La GCS es un elemento importante de garantía de calidad es responsable de controlar
los cambios. Sin embargo también se debe identificar los ECS individuales.
El proceso se puede definir en cinco tareas de CGS:
• Identificación
• Control de versiones
• Control de cambios
• Auditorias de configuración
• Generación de informes
AUDITORIA DE LA CONFIGURACION
¿Cómo podemos asegurar que el cambio se ha implementado correctamente?
La respuesta es doble:
1) Revisiones técnicas formales
2)Aauditorias de configuración del software.
50

15. UNIDAD II / PLANIFICACION DEL SISTEMA
Las revisiones técnicas formales se centran en la corrección técnica del elemento de
configuración que ha sido modificado. Los revisores evalúan el ECS para determinar la
consistencia con otros ECS, las omisiones o los posibles efectos secundarios.
Una auditoria de configuración del software complementa la revisión técnica
formal al comprobar características que generalmente no tiene en cuenta la revisión.
La auditoria se plantea y responde con las siguientes preguntas:
• ¿Se ha hecho el cambio especificado en la OCI? ¿Se han incorporado
modificaciones adicionales?
• ¿Se ha llevado a cabo una revisión técnica formal para evaluar la corrección
técnica?
• ¿Se han seguido adecuadamente los estándares de ingeniería de software?
• ¿Se han "recalcado" los cambios en el ECS?¿Se han especificado la fecha del
cambio y el autor?¿Reflejan los cambios los atributos del objeto de configuración?
• ¿Se han seguido procedimientos del GCS para señalar el cambio, registrarlo y
divulgarlo?
• ¿Se han actualizado adecuadamente todos los ECS relacionados?
INFORMES DE ESTADO
La generación de informes de estado de la configuración es una tarea de GCS que
responde a las siguientes preguntas:
1) ¿Qué pasó?
2) ¿Quién lo hizo?
3) ¿Cuándo pasó?
4) ¿Que más se vio afectado?
La generación de informes de estado de la configuración desempeña un papel
vital en el éxito del proyecto de desarrollo de software. Cuando aparece involucrada
mucha gente es muy fácil que no exista una buena comunicación.
51

16. UNIDAD II / PLANIFICACION DEL SISTEMA
Pueden darse errores entre las personas desarrolladoras del software. El IEC ayuda a
eliminar esos problemas, mejorando la comunicación entre todas las personas
involucradas.
La gestión y configuración del software identifica, controla audita e informa de las
modificaciones que invariablemente se dan al desarrollar el software una vez que ha sido
distribuido a los clientes. La configuración se organiza de tal forma que sea posible un
control organizado de los cambios. La configuración del software está compuesta por un
conjunto objetos interrelacionados, denominados elementos de configuración del
software, que son provocados par la actividades del desarrollo, de la ingeniería del
software.
Las líneas base nos permiten guiarnos para desarrollar los cambios, los objetos
forman un asociación que refleja las variantes y relaciones creadas, el control de
versiones son procedimientos y herramientas que ayudan a gestionar el uso de los
objetos. El control de cambios es una actividad procedimental que asegura la calidad en
los cambios del los ECS. La auditoria de configuración es una actividad de SQA
(Aseguramiento de la calidad del software) para asegurar la calidad durante los cambios.
Durante el proceso de construcción de un software, los cambios son inevitables.
Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han
analizado o pronosticado correctamente. La finalidad de la Gestión y configuración del
Software el conocer la estructura de procesos y herramientas para aplicar dentro de la
construcción del software que nos ayudan a controlar los cambios. Es importante
considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el
proceso de ingeniería para asegurar su control y calidad.
52