Unidad 2 planificacion y modelado
Upcoming SlideShare
Loading in...5
×
 

Unidad 2 planificacion y modelado

on

  • 1,730 views

Unidad desarrollada de la materia de "Planificacion y Modelado" para la carrera de Ingenieria en Sistemas Computacionales

Unidad desarrollada de la materia de "Planificacion y Modelado" para la carrera de Ingenieria en Sistemas Computacionales

Statistics

Views

Total Views
1,730
Views on SlideShare
1,730
Embed Views
0

Actions

Likes
0
Downloads
69
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Unidad 2 planificacion y modelado Unidad 2 planificacion y modelado Document Transcript

  •      UNIDAD 2    PLANIFICACION DEL  SISTEMAS   Objetivo: Realizará la planificación de  un proyecto de software de una  organización                  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  2.1. PLANIFICACIÓN DEL TIEMPOUno 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énintegran los costos, porque al final también se traducen en gastos) se utilizan en dichoproyecto, 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ímitepara la que el proyecto deberá estar concluido. Además, el proyecto posiblementedisponga de una serie actividades que se deben cumplir.La duración de las tareas es elperiodo de tiempo que transcurre entre la fecha de comienzo de una tarea y su fecha definalizació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 DEESTOS FACTORES:• La Historia: Consiste en establecer una consultoría sobre similares proyectosrealizados con anterioridad y recoger datos históricos. Como se hicieron, cuanto duraronsus tareas. etc.• La Participación: Consiste en contar con personas que tengan experiencia enproyectos idénticos (mismo) aunque sean bajo otras circunstancias.• La Intuición: Contar con personas que hayan realizado un proyecto con similarescaracterísticas.• La Indeterminación.: Hacer una estimación, a veces no basada en nadaconcreto. (por impulsos).2.2. EVALUACION DEL COSTO BENEFICIOFACTORES EN EL COSTO DEL SOFTWAREExisten muchos factores que influyen en el costo de un producto de programación. Elefecto de estos factores es difícil de estimar y, por ende también lo es el costo delesfuerzo en el desarrollo o en el mantenimiento. 38  
  • UNIDAD II / PLANIFICACION DEL SISTEMA   Entre los factores que afectan se observan, en forma primordial, las capacidadesindividuales 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 deconfiabilidad, el nivel tecnológico utilizado; la disponibilidad, familiaridad y estabilidad delsistema donde se desarrolla el producto.ESTIMACIÓN DE COSTOSAl principio, el costo del software constituía un pequeño porcentaje del costo total de lossistemas basados en computadora. Un error considerable en las estimaciones del costodel software tenía relativamente poco impacto. Hoy en día, el software es el elementomás caro de la mayoría de los sistemas informáticos. Un gran error en la estimación delcosto puede ser lo que marque la diferencia entre beneficios y pérdidas. Sobrepasarseen el costo puede ser desastroso para el equipo de desarrollo. La estimación del costo y del esfuerzo del software nunca será una cienciaexacta. Son demasiadas las variables humanas, técnicas, de entorno, políticas quepueden afectar al costo final del software y al esfuerzo aplicado para desarrollarlo. Sinembargo, la estimación del proyecto de software puede dejar de ser un oscuro arte paraconvertirse en una serie de pasos sistemáticos que proporcionen estimaciones con ungrado de riesgo aceptable.PARA REALIZAR ESTIMACIONES SEGURAS DE COSTOS Y ESFUERZOSTENEMOS VARIAS OPCIONES POSIBLES:• Dejar la estimación para más adelante (obviamente, ¡podemos realizar unaestimació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 lasestimaciones de costo y de esfuerzo del proyecto.• Desarrollar un modelo empírico para el cálculo de costos y esfuerzos delsoftware. Desafortunadamente, la primera opción, aunque atractiva, no es práctica. Lasestimaciones de costos han de ser proporcionadas a priori. Sin embargo, hay quereconocer que cuanto más tiempo esperemos, más cosas sabremos, y cuanto mássepamos, menor será la probabilidad de cometer serios errores en nuestrasestimaciones. 39  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  La segunda opción puede funcionar razonablemente bien si el proyecto actual esbastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares.Desafortunadamente. La experiencia anterior no ha sido siempre un buen indicador defuturos resultados. Las opciones restantes son métodos viables para la estimación del proyecto desoftware. Desde un punto de vista ideal, se deben aplicar conjuntamente las técnicasindicadas. 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» parala estimación del proyecto de software. Dentro de la mayor parte de las organizaciones, la estimación de costos de laprogramación se basa en las experiencias pasadas. Los datos históricos se usan paraidentificar los factores de costo y determinar la importancia relativa de los diversosfactores dentro de la organización. Lo anterior, por supuesto, significa que los datos decostos y productividad de los proyectos actuales deben ser centralizados y almacenadospara un empleo posterior. La estimación de costos puede llevarse acabo en formajerá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 manejode la configuración, del control de calidad, de la integración del sistema, delentrenamiento y de las publicaciones de documentación. Los costos del personalrelacionado se estiman mediante el examen del costo de proyectos anteriores queresulten similares.La estimación jerárquica hacia arribaPrimero se estima el costo del desarrollo de cada módulo o subsistema; tales costos seintegran 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 conalgunos módulos que se desarrollarán. La técnica subraya los costos asociados con eldesarrollo independiente de cada módulo o componente individual del sistema, aunquepuede fallar al no considerar los costos del manejo de la configuración o del control decalidad. 40  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  En la práctica, ambas técnicas deben desarrollarse y compararse para queiterativamente se eliminen las diferencias obtenidas.PARA ANALIZAR UN ANÁLISIS DE COSTO-BENEFICIO SE DEBE TOMAR ENCUENTA LAS SIGUIENTES RECOMENDACIONES:Para obtener el costo.1.-Identificar primeramente el costo de la inversión más importante de acuerdo a sumonto.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 tipode unidad que se manejan en los costos para que estos puedan ser comparados y por lotanto 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 VIABILIDADTodos los proyectos son posibles: ¡si se tiene infinitos recursos y tiempo! Desgraciadamente, el desarrollo de un sistema o producto basado encomputadora es muy probable que esté plagado de escaséese de recursos y de fechasde entrega difíciles (o totalmente no realistas). Es necesario y prudente evaluar laviabilidad 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 unsistema mal concebido en la pronta fase de definición. La viabilidad y el análisis deriesgo están relacionados de muchas maneras. Si el riesgo del proyecto es alto laviabilidad 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  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  Viabilidad económica. Una evaluación del costo de desarrollo sopesado con los ingresos netos o beneficiosobtenidos del sistema o producto desarrollado.Viabilidad técnica.Un estudio de función, rendimiento y restricciones que puedan afectar a la consecuciónde un sistema aceptable.Viabilidad legal.Determinar cualquier infracción, violación o responsabilidad legal en que se podríaincurrir 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óneconómica es obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y noexiste ninguna alternativa razonable. Sin embargo, si falla alguna de las condiciones anteriores, se debería hacer unestudio del área en cuestión. La justificación económica incluye una amplia gama de aspectos a tener encuenta como son el análisis de costes/beneficios, las estrategias de ingresos de laempresa a largo plazo, el impacto en otros productos o centros de beneficios, coste derecursos necesarios para el desarrollo y crecimiento potencial del mercado. La viabilidad tecnológica es frecuentemente el área más difícil de valorar en estaetapa del proceso de ingeniería del producto. Como los objetivos, funciones yrendimiento son poco claros, cualquier cosa parece posible si se hacen las suposicionescorrectas. Es esencial que el proceso de análisis y definición se realice en paralelo conuna valoración de la viabilidad técnica. De esta manera se pueden juzgarespecificaciones concretas a medida que se establecen. 42  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  2.4. PLANIFICACION DE LA DOCUMENTACIONPlan de documentación. Su función es definir y controlar la documentación asociadacon el proyecto. La buena documentación proporciona una explicación de la forma en que operael sistema y qué características tienen los modelos y algoritmos utilizados en él. Muchospaquetes de hoja de cálculo y de ayuda para la toma de decisiones guardan todos estosdetalles en forma automática a medida que se van especificando.Aunque esta información es transparente para el usuario, se puede recuperar cuandosea necesario ya sea en forma impresa o a través de una pantalla. Muchos lenguajes decuarta generación son auto-documentados, lo que significa que los propios programasson tan fáciles de entender que ellos se convierten en su propia documentación. Lalectura del código explica lo que hace el programa.IMPORTANCIA DE LA DOCUMENTACION La documentación de los programas es un aspecto sumamente importante, tantoen 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 laposibilidad de la reutilización de parte del programa en otras aplicaciones, sin necesidadde conocerse el código al dedillo. La documentación de un programa empieza a la vezque la construcción del mismo y finaliza justo antes de la entrega del programa oaplicación al cliente. Así mismo, la documentación que se entrega al cliente tendrá quecoincidir con la versión final de los programas que componen la aplicación. Una vezconcluido el programa, los documentos que se deben entregar son una guía técnica, unaguí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 decomentarios o de archivos de información dentro de la aplicación.Externa: Es aquella que se escribe en cuadernos o libros, totalmente ajena a laaplicación en si. Dentro de esta categoría también se encuentra la ayuda electrónica. 43  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  La guía técnicaEn la guía técnica o manual técnico se reflejan el diseño del proyecto, la codificación dela aplicación y las pruebas realizadas para su correcto funcionamiento.Generalmente este documento esta diseñado para personas con conocimientos deinformática, generalmente programadores. El principal objetivo es el de facilitar eldesarrollo, 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 CLARAMENTEDIFERENCIADOS:• Cuaderno de carga: Es donde queda reflejada la solución o diseño de laaplicación.Esta parte de la guía es únicamente destinada a los programadores. Debe estarrealizado de tal forma que permita la división del trabajo• Programa fuente: Es donde se incluye la codificación realizada por losprogramadores. Este documento puede tener, a su vez, otra documentación para sumejor comprensión y puede ser de gran ayuda para el mantenimiento o desarrollomejorado de la aplicación. Este documento debe tener una gran claridad en su escriturapara su fácil comprensión.• Pruebas: Es el documento donde se especifican el tipo de pruebas realizadas alo largo de todo el proyecto y los resultados obtenidos.La guía de usoEs lo que comúnmente llamamos el manual del usuario. Contiene la informaciónnecesaria para que los usuarios utilicen correctamente la aplicación. Este documento sehace desde la guía técnica pero se suprimen los tecnicismos y se presenta de forma quesea entendible para el usuario que no sea experto en informática. Un punto a tener encuenta en su creación es que no debe hacer referencia a ningún apartado de la guíatécnica y en el caso de que se haga uso de algún tecnicismo debe ir acompañado de unglosario al final de la misma para su fácil comprensión.La guía de instalaciónEs 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 delsistema y las normas de utilización del mismo. Dentro de las normas de utilización seincluyen también las normas de seguridad, tanto las físicas como las referentes alacceso a la información. 44  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  GUIA PARA ELABORAR UN REPORTEFormato del reporte escritoEl formato del escrito depende de la cantidad de información disponible, la complejidaddel asunto, la naturaleza del trabajo y otros factores que se toman en cuenta para lapreparación de bosquejos. Puede estar determinada por los reglamentos de lainstitución, organización o empresa.A CONTINUACIÓN SE MUESTRA EL FORMATO PARA LA ELABORACIÓN DELREPORTE 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 SOFTWARESe denomina Gestión de la Configuración el conjunto de procesos destinados a asegurarla validez que todo producto obtenido durante cualquiera de las etapas del desarrollo deun Sistema de Información (S.I.), a través del estricto control de los cambios realizadossobre los mismos y de la disponibilidad constante de una versión estable de cadaelemento 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.) facilitantambién el mantenimiento de los sistemas al proporcionar una imagen detallada delsistema en cada etapa del desarrollo. 45  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  La gestión de la configuración se realiza durante todas las fases del desarrollo de unsistema de información, incluyendo el mantenimiento y control de cambios, una vezrealizada la puesta en producción. La gestión de la configuración del software es uno de los procesos clave paratoda organización dedicada a la Ingeniería del Software, ya que posibilita una mejororganización del desarrollo y mantenimiento, producto, facilitando el resto de procesosde producción. Durante el proceso de construcción de un software, los cambios soninevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se hananalizado o pronosticado correctamente. Es importante considerar ciertas modificacionesque 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, sedenomina gestión de la configuración. La gestión es el arte de identificar, organizar ycontrolar las modificaciones que sufre el software…la meta es maximizar la productividadminimizando errores.”LOS CAMBIOS DENTRO DEL DESARROLLO DEL SOFTWARE PUEDEN OCURRIREN 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, elmantenimiento es la etapa final de la ingeniería hasta que se retire el producto delequipo, la CGS es un conjunto de actividades de seguimiento y control que comienzancuando se inicia el proyecto de desarrollo del software y termina sólo una vez que elsoftware queda fuera de circulación. Desgraciadamente, en el proceso de ingeniería del software existe una variableimportantísima que entra en juego, el cambio. 46  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  La primera Ley de la ingeniería de sistemas establece: “Sin importar en que momento delciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlopersistirá 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 puedeencontrar en cuatro aspectos fundamentales y a menudo muy tradicionales dentro deldesarrollo del software:• Nuevos requisitos del negocio o condiciones que dictan los cambios en lascondiciones del producto o en las normas comerciales.• Nuevas necesidades del los clientes que demandan la modificación de los datosproducidos por un sistema basado en computadora.• Reorganización y/o reducción del volumen comercial que provoca cambios en lasprioridades del proyecto o en la estructura del equipo de ingeniería del software.• Restricciones presupuestarias o de planificaciones que provocan una redefinicióndel sistema o del producto. La gestión de configuración del software realiza un conjunto de actividadesdesarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida delsoftware de computadora.La GCS es una actividad de garantía de calidad del software que se aplica en todas lasfases del proceso de ingeniería del software.LINEAS BASEUna línea base es un concepto de gestión de configuración del software que nos ayuda acontrolar los cambios sin impedir seriamente los cambios justificados. La IEEE defineuna línea base como: Una especificación o producto que se ha revisado formalmente ysobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como basepara un desarrollo posterior y que puede cambiarse solamente a través deprocedimientos formales de control de cambios. En el contexto de la ingeniería del software definimos una línea base como unpunto de referencia en el desarrollo del software y que queda marcado por el envío deuno o más elementos de configuración del software (ECS) y la aprobación de ECSobtenido mediante una revisión técnica formal. 47  
  • 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 sehan revisado corregido y aprobado, la especificación de diseño se convierte en líneabase. 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 SOFTWAREUn elemento de la configuración del software es la información creada como parte delproceso de ingeniería un ECS (elemento de configuración de software) es undocumento, un conjunto completo de casos de prueba o un componente de un programadado. Los siguientes ECS son el objetivo de las técnicas de gestión de configuración y formanun conjunto de líneas base:1) Especificación del sistema2) Plan de proyecto3) Especificación de requisitos4) Prototipo ejecutable o “en papel”5) Manual de usuario preliminar6) Especificación de diseños7) Descripción del diseño de datos8). Descripción del diseño arquitectónico9) Descripciones del diseño de los módulos10) Descripciones del diseño de interfaces11) Descripciones de los objetos (si se utilizan técnicas de P.O.O)12) Listados del código fuente13). Plan y procedimiento de pruebas 48  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  14) Casos de prueba y resultados registrados15) Manuales de operación de y de instalación16) Programas ejecutables17) Módulos, código ejecutable18) Módulos enlazados19) Descripción de la base de datos20) Esquema y estructura de archivos21) contenido inicial22) Manual del usuario final23) Documentos de mantenimiento24). Informes de problemas del software25) Peticiones de mantenimiento26). Ordenes de cambios e ingenieríaEs importante considerar poner las herramientas de desarrollo de software bajo controlde configuración. Es decir congelar la versiones de editores, compiladores y otrasherramientas CASE utilizadas durante el desarrollo, un cambio en las versionesutilizadas puede que produzca resultados diferentes que la versión original. Los ECS se organizan como objetos de configuración que deben ser catalogadospor la base de datos del proyecto con un nombre único. Un ECS tiene un nombre yatributos, y está conectado a otros objetos mediante relaciones.    49  
  • 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 lainterrelaciones señalan a que otros objetos afectará.EL PROCESO DE GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARELa GCS es un elemento importante de garantía de calidad es responsable de controlarlos 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 informesAUDITORIA 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  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  Las revisiones técnicas formales se centran en la corrección técnica del elemento deconfiguración que ha sido modificado. Los revisores evalúan el ECS para determinar laconsistencia con otros ECS, las omisiones o los posibles efectos secundarios. Una auditoria de configuración del software complementa la revisión técnicaformal 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 incorporadomodificaciones adicionales?• ¿Se ha llevado a cabo una revisión técnica formal para evaluar la correcciónté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 delcambio 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 ydivulgarlo?• ¿Se han actualizado adecuadamente todos los ECS relacionados?INFORMES DE ESTADOLa generación de informes de estado de la configuración es una tarea de GCS queresponde 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 papelvital en el éxito del proyecto de desarrollo de software. Cuando aparece involucradamucha gente es muy fácil que no exista una buena comunicación. 51  
  • UNIDAD II / PLANIFICACION DEL SISTEMA  Pueden darse errores entre las personas desarrolladoras del software. El IEC ayuda aeliminar esos problemas, mejorando la comunicación entre todas las personasinvolucradas. La gestión y configuración del software identifica, controla audita e informa de lasmodificaciones que invariablemente se dan al desarrollar el software una vez que ha sidodistribuido a los clientes. La configuración se organiza de tal forma que sea posible uncontrol organizado de los cambios. La configuración del software está compuesta por unconjunto objetos interrelacionados, denominados elementos de configuración delsoftware, que son provocados par la actividades del desarrollo, de la ingeniería delsoftware. Las líneas base nos permiten guiarnos para desarrollar los cambios, los objetosforman un asociación que refleja las variantes y relaciones creadas, el control deversiones son procedimientos y herramientas que ayudan a gestionar el uso de losobjetos. El control de cambios es una actividad procedimental que asegura la calidad enlos 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 hananalizado o pronosticado correctamente. La finalidad de la Gestión y configuración delSoftware el conocer la estructura de procesos y herramientas para aplicar dentro de laconstrucción del software que nos ayudan a controlar los cambios. Es importanteconsiderar ciertas modificaciones que pueden ocurrirle al software dentro de todo elproceso de ingeniería para asegurar su control y calidad.   52