Gestion de Configuracion de Software

7/21/2019 Gestion de Configuracion de Software

1/29

1

ndiceIntroduccin......................................................................................................................................... 3

Captulo I: Ciclo de vida del Software.............................................................................................. 41.1.Evolucin del Software ............................................................................................................ 5

1.2.Ciclo de Vida y Modelos de Desarrollo ................................................................................... 5

1.2.1. Concepto de Ciclo de Vida ......................................................................................... 6

1.2.2. Procesos de Ciclo de Vida .......................................................................................... 6

1.2.2.1.Procesos Principales ............................................................................................ 6

1.2.2.2.Procesos de Soporte ............................................................................................ 7

1.2.2.3.Procesos generales .............................................................................................. 7

1.2.3.

Modelos de Desarrollo ............................................................................................... 8

1.2.3.1.Modelos Tradicionales ........................................................................................ 8

1.2.3.1.1. Modelo de Ciclo de Vida Clsico (o en Cascada) ....................................8

1.2.3.1.2. Prototipado evolutivo ......................................................................... 11

1.2.3.2.Modelos Alternativos ........................................................................................ 15

1.2.3.2.1. Modelos en Espiral ............................................................................. 15

Captulo II: Gestin de Configuracin del Software..................................................................... 17

2.1.La Configuracin del Software ............................................................................................... 17

2.2.Lnea base y Elementos de Configuracin del software(ECS) ............................................... 18

2.2.1. Lnea base .................................................................................................................... 18

2.2.2.

Elementos de Configuracin ....................................................................................... 19

Captulo 3: El Proceso de G.C.S...................................................................................................... 21

3.1Identificacin de Objetos en La Configuracin de Software .................................................. 21

3.2.Control de Versiones ............................................................................................................... 22

3.3.Control de Cambios ................................................................................................................ 23

3.4.Auditorias de Configuraciones ................................................................................................ 25

3.5.Informes de Estado .................................................................................................................. 26

Conclusiones...................................................................................................................................... 28

Referencias Bibliogrficas................................................................................................................ 29


2/29

2

ndice de FigurasFigura 1:Procesos de Ciclo de Vida ............................................................................................ 6

Figura 2: Procesos de Adaptacin ............................................................................................... 8

Figura 3: Ciclo de Vida Clsico.................................................................................................... 9Figura 4: Modelo de Prototipado Evolutivo .............................................................................. 12

Figura 5: Ciclo de Vida Espiral ................................................................................................. 16

Figura 6: Lneas Base de la Configuracin de Software ........................................................... 18

Figura 7: Lneas Base en el Ciclo de Vida Tradicional ............................................................. 19

Figura 8: Grafo de Evolucin ..................................................................................................... 23

Figura 9: Proceso de Control de Cambio .................................................................................. 25

Figura 10: Flujo de Informacin ................................................................................................ 27


3/29

3

Gestin de Configuracin de Software (GCS/SCM)

Introduccin

La Gestin de Configuracin de Software (GCS) es una de las actividades claves para que unaorganizacin de desarrollo pueda alcanzar el Nivel de Maduracin 2 establecido por el SoftwareEngineering Institute.

Desafortunadamente, la necesidad de implementar estas actividades surge como consecuencia de laaparicin de problemas en la calidad de los productos ya desarrollados o en etapas avanzadasdesarrollo, o por dificultades para mantener el ritmo de produccin, puesto que en estascircunstancias, el personal asignado a tareas de desarrollo debe tambin atender pedidos demantenimiento o mejoramiento de productos finalizados.

Otro factor que contribuye a detectar esta necesidad, es la aparicin gradual de programadores,analistas o especialistas, pertenecientes a los grupos de desarrollo, que, con el tiempo, se vanconvirtiendo en insustituibles, pues, ante la falta de una documentacin completa y coherente, sonlos nicos que se encuentran en capacidad de implementar cambios en los productos entregados o enetapa avanzada de implementacin.

Estas dificultades se corrigen mediante la adopcin de las tcnicas de Gestin de Configuracin quese encuentran ampliamente desarrolladas en los libros de texto relacionados con la Ingeniera deSoftware, pero en ninguno de ellos es posible encontrar una explicacin de cmo aplicarlas enproductos en proceso de desarrollo o que ya han sido entregados a los clientes.

En tal sentido, el objetivo del presente trabajo es introducir al lector en la problemtica de losmodelos de ciclo de vida de productos software ms utilizados y en las actividades relacionadas con

la Gestin de Configuracin; avanzando luego en una propuesta para obtener los Elementos deConfiguracin de Software (ECS) esenciales que permitan incorporar a los productos en desarrollo odesarrollados a las tcnicas de GCS tradicionales implementadas en la Organizacin.


4/29

4

Captulo I: Evolucin y Ciclo de Vida del Software

La Ingeniera de Software (IS) est constituida por tres componentes fundamentales que posibilitanuna eficiente gestin del proceso de desarrollo y suministran, a los que trabajan en esta rama de laingeniera, las bases para construir de forma eficiente software de alta calidad, ellos son:

o Los Mtodos.o Las Herramientas.o Los Procedimientos

Los Mtodos de IS indican como se debe construir el software tcnicamente, abarcando unaamplia variedad de tareas que incluyen, entre otras, la planificacin y estimacin de proyectossoftware, el anlisis de requisitos del sistema y del propio software, el diseo de estructuras dedatos, la arquitectura de programas, la codificacin, el programa de pruebas, y tambin lasprevisiones de mantenimiento.

Las Herramientas de IS proveen el apoyo a los Mtodos y constituyen un soporte al desarrollo. Estasherramientas pueden ser manuales, semiautomticas o totalmente automatizadas. La tendenciaactual es que este apoyo sea llevado a cabo por herramientas informticas que, integrando cada unode los Mtodos mencionados anteriormente, brinden una solucin integral al problema del desarrollodel software.Estas son las herramientas CASE (Computer Aided Sofware Engineering) que se puede traducircomo Ingeniera de Software Asistida por Computadora. Existen en el mercado diferentesherramientas de este tipo que permiten automatizar parte o todo el proceso de desarrollo.

Los Procedimientos de IS constituyen el vnculo de unin entre Mtodos y Herramientas, tienen porobjeto facilitar el desarrollo racional y oportuno del producto.Definen el orden en que se deben aplicar los Mtodos, establecen los documentos e informes que serequieren para asegurar un desarrollo preciso y una adecuada supervisin del avance del proyecto,fijan, adems, los controles a aplicar sobre el producto tendientes a asegurar su calidad e integridad.

Puede afirmarse entonces que la IS est compuesta por una serie de pasos que comprenden losMtodos, las Herramientas y los Procedimientos mencionados.Habitualmente estos pasos reciben el nombre deparadigmas de la Ingeniera de Software.Existen actualmente distintos paradigmas que pueden adoptarse para guiar el proceso de desarrollode un producto software, no obstante, todos ellos se basan en tres paradigmas bsicos:

o Paradigma de Ciclo de Vida Clsico (o en cascada).o

Paradigma de Prototipos Evolutivos.o Paradigma del Modelo en Espiral.

La seleccin del paradigma a utilizar en un proyecto de desarrollo de software est directamenterelacionada con la naturaleza del proyecto y de la aplicacin, los Mtodos y Herramientas a utilizary los controles e informes requeridos. [3]


5/29

5

1.1. Evolucin del Software

La necesidad de gestionar la configuracin surge del hecho de que el software evoluciona con eltiempo:

Durante el desarrolloEl desarrollo del software siempre es progresivo, incluso en el ciclo de vida en cascada.El desarrollo evolutivo consiste, precisamente, en una evolucin controlada (ciclo de vidaespiral, prototipos evolutivos).

Durante la explotacinDurante la fase de mantenimiento se realizan modificaciones sucesivas del producto.

En todos los casosSuele ser necesario recuperar versiones antiguas, aunque sea slo para consulta. Para ellohace falta tener organizado el almacenamiento de versiones anteriores.

1.2. Ciclo de vida y Modelos de Desarrollo

Como se ha mencionado, no existe un nico paradigma o modelo de Ciclo de Vida que puedadefinir todas las fases por las que deba pasar un producto software y que se adapte a todas lasnecesidades y problemas. [3]

Esto es as porque existe un amplio espectro de aplicaciones para las que deben desarrollarseproductos de diferente naturaleza.El carcter de estas aplicaciones hace que cada una de ellas requiera solucin particulares yespecficas, an ms, puede suceder que dentro de un mismo tipo existen necesidades diferentes.Por otra parte, los centros de desarrollo que debe implementarlas poseen, a su vez, estructurasorganizativas y modalidades de trabajo particulares.

Tambin forman parte de esta problemtica otros factores, entre los que pueden mencionarse:o El tipo de cliente o usuarios para el que se desarrollar el Sistema.o La volatilidad de requisitos.o La aversin al riesgo del cliente y de la organizacin de desarrollo.o El rea donde se utilizar la aplicacin.

Estos factores suelen combinarse, por lo que puede considerarse lgico pensar que exista lanecesidad de aplicar diferentes paradigmas para diferentes tipos de producto.

Por tal motivo, resulta indispensable realizar, previo al inicio de un proyecto de desarrollo, la

identificacin y anlisis de los diferentes modelos de ciclos de vida, adoptando aqul que ms seajuste a las necesidades del proyecto, del cliente y de la organizacin de desarrollo.

Cualquiera sea el modelo de ciclo de vida seleccionado, debe cumplir con los siguientesrequisitos:

o Determinar el orden en que deben llevarse a cabo las fases del proceso software.o Establecer claramente los criterios de transicin de una fase a la siguiente. [3]


6/29

6

1.2.1.

Concepto de ciclo de vida

Una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y elmantenimiento del software[IEEE 1074].[1]

Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas enel desarrollo, la explotacin y el mantenimiento de un producto de software, abarcando lavida del sistema desde la definicin de los requisitos hasta la finalizacin de su uso [ISO12207-1].[1]

1.2.2.

Procesos del ciclo de vida

Figura 1. Procesos del ciclo de vida [2]

1.2.2.1. Procesos Principales

Proceso de Adquisicin: Actividades y tareas que el comprador, cliente o usuariorealiza para adquirir un sistema o producto software.

Proceso de Suministro: Actividades y tareas que efecta el suministrador. Proceso de Desarrollo: Tenemos como al anlisis de requisitos del sistema, diseo de

la arquitectura del sistema, anlisis de los requisitos del software, diseo de laarquitectura del software, diseo detallado del software, codificacin y prueba delsoftware, integracin del software, prueba del software, integracin del sistema,prueba del sistema, instalacin del software, soporte del proceso de aceptacin delsoftware.

Proceso de Explotacin: Incluye la explotacin del software y el soporte operativo alos usuarios.

Proceso de Mantenimiento: Aparece cuando el software necesita modificaciones. Elobjetivo es modificar el software existente manteniendo su consistencia.


7/29

7

1.2.2.2.

Procesos de Soporte

Proceso de Documentacin: Registra la informacin producida por un proceso oactividad del ciclo de vida.

Proceso de Gestin de la Configuracin: Aplica ciertos procedimientosadministrativos y tcnicos durante todo el ciclo de vida relacionados con laconfiguracin del software y con las modificaciones y versiones de los documentos.

Proceso de Aseguramiento de la Calidad: Aporta confianza en que los procesos y losproductos software del ciclo de vida cumplen con los requisitos especificados y seajustan a los planes establecidos.

Proceso de Verificacin: Determina si los requisitos de un sistema o del softwareestn completos y son correctos, y si los productos software de cada fase del ciclo devida cumplen los requisitos y condiciones impuestos en fases previas.

Proceso de Validacin: Sirve para determinar si el sistema o software final cumplencon los requisitos previstos para su uso.

Proceso de Revisin Conjunta: Sirve para evaluar el estado del software y susproductos en una actividad del ciclo de vida o una fase de un proyecto. Proceso de Auditora: Permite determinar, en los hitos predeterminados, si se han

cumplido los requisitos, los planes y el contrato.

Proceso de Resolucin de Problemas: Permite analizar y eliminar los problemasdescubiertos durante el desarrollo, la explotacin, el mantenimiento u otro proceso.

1.2.2.3. Procesos Generales

Proceso de Gestin: Actividades y tareas genricas para gestionar los procesos. Proceso de Infraestructura: Infraestructura necesaria para cualquier otro proceso.

Proceso de Mejora: Para controlar y mejorar los procesos. Proceso de Formacin: Para proporcionar formacin y mantener al profesor formado.


8/29

8

Figura 2. Proceso de adaptacin [1]

1.2.3.Modelos de Desarrollo

1.2.3.1. Modelos Tradicionales

Estos modelos de evolucin del producto software son utilizados, en algunos casos,desde los inicios de la Ingeniera del Software y se encuentran ampliamentedesarrollados en la bibliografa existente, no obstante, a los efectos del presentetrabajo, se describen aquellos de mayor utilizacin: El ciclo de vida Clsico o enCascada y el ciclo de vida de Prototipado Evolutivo.

1.2.3.1.1.

Modelo de Ciclo de Vida Clsico (o en Cascada)

Es el paradigma ms antiguo y ampliamente difundido en la IS, fuepresentado por primera vez por Royce en 1970 y aplicado con xito paraestructurar y gestionar grandes proyectos de software en importantescompaas de desarrollo. [5]


9/29

9

Puede ser visto como un modelo con forma de cascada de agua de variossaltos, en la que cada salto representa cada una de las fases del ciclo devida.

LaFigura 3., permite visualizar la evolucin del producto software comouna secuencia ordenada de transiciones, de fase en fase, que evoluciona enforma lineal, exige un enfoque sistemtico y secuencial del desarrollo delproducto software y contempla las siguientes fases:

Figura 3. Ciclo de Vida Clsico [4]

a.

Ingeniera y Anlisis del Sistema Global

En esta fase se establecen los requisitos de todos los componentes del SistemaGlobal, asignando un subconjunto de esos requisitos al componente Software,determinando, asimismo, su factibilidad y superioridad con respecto a otrosproductos alternativos. [3]

b.Anlisis de Requisitos de Software

Bsicamente se definen los requisitos funcionales y de rendimiento. [6]En esta fase se profundiza el estudio de los Requisitos del Sistema Global en loque respecta al rea de Software en particular.Esta tarea establece una relacin entre la asignacin del Software a nivelSistema y el diseo del Software. [3]

c. Diseo de Software

Representacin de la aplicacin que sirve de gua a la implementacin. [6]


10/29

10

Este proceso traduce la especificacin de requisitos (qu hacer) en unarepresentacin que logre la calidad requerida antes de proceder a la codificacin(cmo hacerlo).El objetivo de esta fase es desarrollar una representacin coherente y

organizada del producto software que satisfaga la especificacin de requisitos.[3]Desde el punto de vista de gestin, la etapa de diseo se puede considerardividida en dos subetapas:

Diseo PreliminarSe centra en la transformacin de los requisitos en una descripcin dealto nivel de diseo de cada uno de los componentes software,incluyendo especificacin de datos, relaciones, restricciones ydefinicin de interfaces internas y externas. [3]

Diseo DetalladoSe ocupa del refinamiento de la representacin arquitectnica que

conduce a la definicin detallada de estructuras de datos,representaciones algortmicas, informacin de control e interfacesparticulares de cada componente software con el resto del Sistema. [3]

d.Codificacin

En esta fase se lleva a cabo la traduccin del diseo a un lenguaje deprogramacin que pueda ser luego interpretado por la mquina.Se pretende traducir el diseo en un cdigo fuente y cdigos de bases de datos(si es de aplicacin).

El cdigo fuente, luego de ser procesado por un compilador, generar un cdigoobjeto, dependiente de la mquina, ms tarde, la salida de ese compilador es, asu vez, traducido a cdigo de mquina.

El cdigo fuente debe estar acompaado de la documentacin correspondiente,que constituye la manifestacin fsica del diseo de acuerdo a los estndares ymetodologas adoptados para el proyecto.Para el caso que el Sistema est conformado por componentes Hardware ySoftware, en esta fase se debe planificar y ejecutar la integracin de amboscomponentes. [3]

e. Pruebas

Es la validacin e integracin de software y sistemas. [6]

Esta fase constituye la revisin final de las especificaciones, el diseo y lacodificacin y puede ser considerada crtica para asegurar la calidad delproducto generado.


11/29

1

En ella se ejecutar el software con determinados datos de entrada (juegos deensayo), para observar los resultados que se producen y compararlos con losque, tericamente y segn las especificaciones, el Sistema debera producir paradetectar posibles fallos. [3]

A la finalizacin de esta fase se obtienen los siguientes elementos: Especificacin de las pruebas. Informe resumen de pruebas.

f. Mantenimiento

Esta fase comprende las tareas de instalacin y operacin, soporte y remocindel Sistema.

Una vez superada satisfactoriamente la fase de pruebas, el Sistema est listo a

ser instalado en la mquina objetivo.Con el Sistema instalado, se inicia el perodo de operacin, donde se comienzaa realizar mantenimiento, el que se enfoca en los cambios que se producendebido a la correccin de errores, a las adaptaciones requeridas por la evolucindel entorno de software y a las modificaciones originadas en la variacin derequisitos del cliente dirigidos a reforzar o ampliar las prestaciones del Sistema.[3]

El proceso de mantenimiento vuelve a aplicar los pasos del ciclo de vida, perodentro de un contexto de software ya existente, de esta manera, se puede

considerar al proceso de mantenimiento como iteraciones del proceso dedesarrollo.Este ciclo contina hasta el momento en que el Sistema es retirado de operacinpara ser reemplazado por un nuevo Sistema. [3]

1.2.3.1.2.Prototipado evolutivo

Cuando un cliente siente la necesidad de requerir el desarrollo de unsistema para resolver un problema, habitualmente no posee una ideademasiado detallada de esta necesidad, slo percibe que tiene un problemaque demanda una solucin.

Por otra parte, tambin suele suceder que el ingeniero de software que debeatender a ese cliente, no siempre estar seguro de la viabilidad de lasolucin que tiene en mente para resolver el problema. [3]Es en esta situacin donde el paradigma de Prototipado Evolutivo adquieregran valor, ya que permite a ambos realizar una aproximacin gradual a lasolucin ptima del problema.


12/29

1

Prototipo evolutivo: El prototipo inicial se refina progresivamente hastaconvertirse en versin final. [6]. En esta clase de prototipos se desarrolla unmodelo de trabajo del Sistema propuesto que debe ser fcilmente

modificable y ampliable, permitiendo a los usuarios contar con unarepresentacin fsica inmediata de las partes claves del Sistema antes dearribar al producto definitivo. Una vez definidos todos los requisitos ycomprobada la viabilidad de la solucin propuesta, el prototipoevolucionar hacia el Sistema final. En este modelo se deben implementaren forma gradual aquellos requisitos y necesidades que vayan resultandoclaramente interpretados.

De ellos, el modelo ms difundido es el de Prototipos Evolutivos que sepuede visualizar en laFigura 4., ya que implica economa de esfuerzos y laposibilidad que el cliente cuente rpidamente con una modelo bsica que lepermita solucionar, aunque ms no sea, parte del problema. Por tal motivo,es el que estudiaremos con detenimiento.

Figura 4. Modelo de Prototipado Evolutivo [3]

Este paradigma reconoce las siguientes fases que conforman el Ciclo deVida:

a. Anlisis preliminar y especificacin de requisitos

Al igual que en el modelo Clsico, en el de Prototipado Evolutivo el Ciclo deVida comienza con la especificacin de requisitos.


13/29

1

El cliente, junto con el Ingeniero de Software, identifica las necesidades,formulan las soluciones potenciales y evalan la viabilidad de cada una de lassoluciones para seleccionar aquella que parezca ms eficiente a nivel deSistema.

Una vez establecidos los lmites de la futura aplicacin y considerando sloaquellos Requisitos Globales del Sistema que se han individualizadoperfectamente, el Ingeniero de Software analizan con detalle y, junto con elcliente, refinan aquellos requisitos que sern tratados mediante el software.

Tambin dejan claramente establecidas las funciones del hardware, delsoftware y de las interfaces, permitiendo, de esa manera, desarrollar laarquitectura bsica del prototipo a implementar.

b.

Diseo rpido del prototipo

Con la informacin recogida en la etapa anterior, el Ingeniero de Softwaredesarrolla una representacin coherente y organizada de aquellos aspectos delsistema software que cumplen con las especificaciones de los requisitos que sehan podido recoger y refinar en total acuerdo con el cliente.

Dado que esta fase requiere la obtencin de un diseo rpido para serposteriormente implementado, las etapas de diseo de alto nivel y diseodetallado vistas en el ciclo de vida tradicional, se funden en una sola etapa dediseo.

En ella, se focaliza con la misma profundidad en las funciones y estructuras delos componentes que conforman el sistema, como en la definicin detallada delos flujos datos y control.Tambin deben refinarse las representaciones algortmicas que se utilizan encada componente modular y las interfaces que requiere el prototipo adesarrollar, simulando, de resultar necesario, la presencia de otros mdulos odispositivos que a esta altura del proyecto an no han sido desarrolladas o seduda de su necesidad de implementacin.

Por tratarse de un prototipo evolutivo, debe prestarse especial atencin a lainterface hombre mquina, ya que, en la medida que el usuario se sientacmodo en la operacin del prototipo, ms disposicin y tiempo tendr para irmadurando sus reales necesidades y descubriendo nuevos requisitos que no semanifestaron en la definicin inicial.

c. Construccin e implantacinPruebas

En el modelo de Construccin de Prototipos, en esta fase se unifican las fasesde Construccin y Pruebas del modelo Clsico.


14/29

14

En lo que respecta a construccin, al igual que en el modelo Clsico, en estafase se traduce el diseo a un lenguaje de programacin que pueda ser luegointerpretado por la computadora.

El cdigo fuente debe estar acompaado de la documentacin correspondientede acuerdo a los estndares y metodologas adoptados para el proyecto.

Para el caso que el prototipo est conformado por componentes Hardware ySoftware, en esta fase tambin se debe planificar y ejecutar la integracin deambos componentes.

Esta fase contempla tambin la etapa de pruebas, que constituye la revisinfinal de las especificaciones, el diseo y la codificacin.Para las pruebas, se ejecutar el prototipo con datos de entrada prefijados paracomprobar si los resultados que el Sistema desarrollado produce son similaresa los que, tericamente y segn las especificaciones, el Sistema deberaproducir detectando as posibles errores.

d.Evaluacin y refinamiento interactivo del prototipo

Es en esta fase donde el cliente / usuario toma contacto con el prototipo para,mediante su utilizacin, evaluar su utilidad con datos reales, aunque slo seaen forma parcial, para resolver el problema.

Se produce aqu un proceso interactivo entre el cliente / usuario y eldesarrollador, en el cul, a partir de la experiencia en la utilizacin delprototipo, se depuren conceptos, surjan nuevas ideas o se detecten fallos deinterpretacin en requisitos o alcances de determinados servicios que debeprestar el futuro sistema.

e. Refinamiento de las especificaciones del prototipo

Con los elementos generados en la fase anterior, se realiza un refinamiento delas especificaciones que servirn como base de una nueva fase de diseorpido, con el objeto de generar un nuevo prototipo que contemplar mayoresprestaciones que el anterior.

f. Producto de Ingeniera - Implantacin del Sistema final

Esta fase constituye la etapa final del desarrollo del modelo de prototipadoevolutivo.

Comprende las tareas de consolidacin tcnica del producto, pruebas yrevisiones finales, instalacin y operacin, debindose adoptar las previsionesnecesarias para actividades de soporte y remocin del Producto.


15/29

1

Esta fase se contina hasta el momento en que el Sistema es retirado deoperacin para ser reemplazado por un nuevo Sistema.Los productos parciales de la fase b. y c. pasan a ser finales.

1.2.3.2. Modelos Alternativos

Existen al menos tres modelos de ciclo de vida que reciben el nombre de modelosalternativos, ya que focalizan su atencin en aspectos diferentes a los de los modelostradicionales.

Entre ellos se destaca el modelo de ciclo de vida en espiral que, resultando similar almodelo de prototipo evolutivo, incorpora en su desarrollo un factor sumamenteimportante en el mundo actual, altamente competitivo y cambiante: el anlisis deriesgo.

1.2.3.2.1.

Modelo en Espiral

Como se ha mencionado, este modelo, de relativamente recientesurgimiento (Bem 1986), incorpora mtodos de proceso que estninfluenciados por el control y gestin del riesgo para el anlisis yestructuracin del proceso de desarrollo.El modelo en espiral es bastante adecuado para la gestin de riesgos. [7]

Esta nueva filosofa se encuentra representada por ciclos de desarrolloevolutivo e iterativo en forma de espiral, cuyo avance angular representa elprogreso del desarrollo, en tanto que el desplazamiento radial desde elcentro hacia fuera indica el incremento de los costos de desarrollo en formaacumulativa.

La Figura 3. Permite visualizar grficamente el comportamiento de estetipo de ciclo de vida, en ella se pueden distinguir en sus cuatro cuadranteslas cuatro actividades principales del modelo:

Determinacin de Objetivos y Alternativas: Involucra la determinacinde objetivos del proyecto, alternativas y restricciones, y, en etapasposteriores, la valoracin de los resultados de las tareas de ingenieraprevias.

Anlisis de riesgo: Estas actividades permiten gestionar los riesgosasociados al proceso de desarrollo. Se materializan en el anlisis dealternativas e identificacin y resolucin de los riesgos que puedanhacer fracasar el proyecto o sobrepasar el presupuesto o plazo fijado.Producido el anlisis de riesgo, se toma la decisin de continuar o nocon el desarrollo.


16/29

1

Ingeniera: Abarca las actividades inherentes al desarrollo del productoy comprende la construccin de los prototipos de nivel cada vez msrefinados, a medida que se produce la evolucin del sistema, hasta llegaral producto final.

Planificacin: Involucra todo lo atinente a las tareas de planificacin yestimaciones del proyecto en las distintas etapas.

Figura 5. Ciclo de Vida Espiral [7]


17/29

1

Captulo II: Gestin de Configuracin de Software

2.1. La configuracin del software

El resultado del proceso de ingeniera del software es una informacin que se puede dividir tres

amplias categoras: [8]

1) Programas de computadora (tanto en forma de cdigo fuente como ejecutable).

2) Documentos que describen los programas (tanto tcnicos como de usuario).

3) Estructuras de datos (contenidas en el programa o externas a l).

Los elementos que componen toda la informacin producida como parte del proceso deingeniera del software se denominan colectivamente "configuracin del software". Dado que laconfiguracin software es la nica representacin tangible de un programa o sistema software,debe ser controlada para conservar su exactitud, mantener la informacin actualizada, y

asegurar una informacin clara y concisa conforme avanzamos paso tras paso en el proceso deIngeniera del Software. [8]

La causa de todas estas modificaciones se debe a que, a medida que pasa el tiempo, todo elmundo sabe ms (sabe lo que necesita, cmo aproximarse mejor al problema y cmo hacerloganando ms dinero). Este conocimiento adicional es la fuerza motriz de la mayora de loscambios. [9]

El cambio se puede producir en cualquier momento y por cualquier razn. Por ejemplo, segeneran cambios en las revisiones, que nos llevan a la modificacin de los elementos de laconfiguracin (ECSs); durante la fase de desarrollo, se pueden realizar adiciones en losdocumentos ya producidos; las pruebas a menudo nos llevan a cambios que se propagan a travsde la mayora de los ECSs. [9]

Sin embargo, hay cuatro fuentes fundamentales de cambios:

nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos delproducto o en las normas comerciales; [8]

nuevas necesidades del cliente que demandan la modificacin de los datos producidos porsistemas de informacin, funcionalidades entregadas por productos o servicios entregadospor un sistema basado en computadora; [8]

reorganizacin o crecimiento/reduccin del negocio que provoca cambios en las prioridadesdel proyecto o en la estructura del equipo de ingeniera del software; [8]

restricciones presupuestarias o de planificacin que provocan una redefinicin del sistema oproducto. [8]

La gestin de configuraciones del software(GCS) es un conjunto de actividades desarrolladaspara gestionar los cambios a lo largo del ciclo de vida. La GCS es una actividad de garanta decalidad de software que se aplica en todas las fases del proceso de ingeniera del software. [9]


18/29

18

2.2. Lneas Base y Elementos de Configuracin del Software (ECS)

2.2.1. Lnea Base

Una lnea base es un concepto de gestin de configuracin del software que nos ayuda acontrolar los cambios sin impedir seriamente los cambios justificados. La IEEE(Estndar IEEE 610.12-1990) define una lnea base como:

Una especificacin o producto que se ha revisadoformalmente 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 travs de

procedimientos formales de control de cambios.

Las lneas base de la Configuracin del software se muestran en la siguiente figura:

Figura 6. Lneas Base de la Configuracin de Software [9]

En el contexto de la ingeniera del software, definimos una lnea base como un punto dereferencia en el desarrollo del software que queda marcado por el envo de uno o mselementos de configuracin del software y la aprobacin del ECS obtenido medianteuna revisin tcnica formal.

Las Lneas Base pueden ser definidas con cualquier nivel de detalle, no obstante, las msdifundidas son las que se indican en la siguiente [3]Figura 7.:


19/29

19

Figura 7. Lneas Base en un Ciclo de Vida Tradicional [3]

2.2.2.

Elementos de configuracin de Software

Un elemento de configuracin del software (ECS) es la informacin creada comoparte del proceso de ingeniera del software. [9]Llevado al extremo, se puede considerarun ECS como una seccin individual de una gran especificacin o cada caso de pruebade un gran conjunto de pruebas. De forma ms realista, un ECS es un documento, unconjunto completo de casos de prueba o un componente de un programa dado. [8]

Los siguientes ECS son el objeto de las tcnicas de gestin de configuraciones y formanun conjunto de lneas base [3]:

Especificaciones del Sistema.

Estimaciones y Planes. Especificacin de requisitos software. Diseo arquitectnico. Diseo detallado. Prototipos generados. Cdigo fuente. Documentacin relacionada con la determinacin de los factores de riesgo y su

gestin a efectos de minimizar sus consecuencias. Programas ejecutables y libreras asociadas. Manuales del usuario, de operacin e instalacin. Documentacin relacionada con cursos de formacin en el uso del producto.

Plan de pruebas. Casos de Prueba y resultados obtenidos. Estndares y procedimientos de Ingeniera de Software utilizados.

Informes de incidencia. Pedidos de mantenimiento. Ordenes de cambio.


20/29

20

Documentacin del Software y Hardware utilizados como herramientas dedesarrollo.

Diseo de bases de datos. Bases de Datos.

Informacin del entorno de desarrollo y de implantacin. Contenidos iniciales de las bases de datos.


21/29

2

Captulo III: El proceso GCS

La GCS da respuesta a las siguientes cuestiones:

Cmo identifica y gestiona una organizacin las muchas versiones existentes de un

programa (y su documentacin) de forma que se puedan introducir cambioseficientemente?

Cmo controla la organizacin los cambios antes y despus de que el software seadistribuido al cliente?

Quin tiene la responsabilidad de aprobar y de asignar prioridades a los cambios? Cmo podemos asegurar que los cambios se han llevado a cabo adecuadamente? Qu mecanismos se usan para avisar a otros de los cambios realizados?

Estas cuestiones se resuelven en las cuatro tareas de las que consta la GCS:

1.Identificacin. Se trata de establecer estndares de documentacin y un esquema de

identificacin de documentos.2. Control de cambios. Consiste en la evaluacin y registro de todos los cambiosque se hagan de la configuracin software.

3. Auditoras de configuraciones. Sirven, junto con las revisiones tcnicas formalespara garantizar que el cambio se ha implementado correctamente.

4. Generacin de informes.

3.1. Identificacin de Objetos en la Configuracin del Software

Para controlar y gestionar los elementos de configuracin, se debe identificar cada uno deforma nica y luego organizarlos mediante un enfoque orientado a objetos.Se pueden identificar dos tipos de objetos [CH089]: objetos bsicos y objetos compuestos.Un objeto bsicoes una unidad de texto creado por un ingeniero de software durante elanlisis, diseo, codificacin o pruebas.Un objeto compuestoes una coleccin de objetos bsicos y de otros objetos compuestos.

El esquema de identificacin de los objetos de software debe tener en cuentaque los objetos evolucionan a lo largo del proceso de ingeniera del software.

Antes de que un objeto se convierta en una lnea base, puede cambiar variasveces,. e incluso cuando ya es una lnea base, los cambios se presentan conbastante frecuencia. Se puede crear un gafo de evolucinEl proceso de identificacin de la configuracin es el siguiente [9]:


22/29

2

La tarea de identificacin empieza con la definicin de los elementosde la configuracin software representativos de los productos en cada lneabase establecida.El formato, los contenidos y los mecanismos de control para toda ladocumentacin sondefinidos para enlazar la informacin cuando la jerarqua de laconfiguracin se despliega. Se asignan identificadores apropiados a todos los programas, documentos yperifricos,usando un esquema numerado que proporciona informacin sobre elelemento de la configuracin software. Finalmente, la identificacin debe facilitar el control de cambios, paraacomodar actualizaciones y modificaciones.

3.2.

Control de Versiones

La ingeniera de software recomienda realizar el desarrollo de manera disciplinada.Las herramientas de control de versiones no garantizan un desarrollo razonable sicualquier miembro del equipo puede realizar los cambios que quiera e integrarlos en elrepositorio sin ningn tipo de control.

El control de versiones combina procedimientos y herramientas para gestionar las versionesde los objetos de configuracin creados durante el proceso del software. Clemm [CLE89]describe el control de versiones en el contexto de la GCS [8]:

La gestin de configuracin permite a un usuario especificarconfiguraciones alternativas del sistema de software mediante la

seleccin de las versiones adecuadas. Esto se puede gestionar

asociando atributos a cada versin del software y permitiendo luegoespecificar [y construir] una configuracin describiendo el conjunto de

atributos deseado.

Los atributos que se mencionan pueden ser tan sencillos como un nmeroespecfico de versin asociado a cada objeto o tan complejos como una cadena devariables lgicas (indicadores) que especifiquen tipos de cambios funcionalesaplicados al sistema. [8]


23/29

2

Figura 8. Grafo de Evolucin[8]

En laFigura 8., una representacin de las diferentes versiones de un sistema es elgrafo de evolucin mostrado, donde cada nodo del grafo es un objeto compuesto,

es decir, una versin completa del software. Cada versin del software es unacoleccin de ECSs (cdigo fuente, documentos, datos) y cada versin puedeestar compuesta de diferentes variantes.

3.3. Control de Cambios

El proceso de control de cambios puede ser considerado como la actividad ms trascendentede la Gestin de Configuracin, ya que proporciona un mecanismo rgido para el control delos cambios a realizar sobre un producto a lo largo de todo su Ciclo de Vida. [3]

La realidad del control de cambioen un contexto moderno de ingeniera de software ha sido

bien resumida por James Bach [BAC98] [8]:

El control de cambio es vital. Pero las fuerzas que lo hacen

necesario tambin lo hacen molesto. Nos preocupamos por el

cambio porque una diminuta perturbacin en el cdigo puede crearun gran fallo en el producto. Pero tambin puede reparar un gran

fallo o habilitar excelentes capacidades nuevas. Nos preocupamos

por el cambio porque un desarrollador pcaro puede hacer fracasar

el proyecto; sin embargo las brillantes ideas nacidas en la mente deestos pcaros, y un pesado proceso de control de cambio pueden

disuadirle de hacer un trabajo creativo.

Bach reconoce que nos enfrentamos a una situacin a equilibrar. Mucho control de cambio ycrearemos problemas. Poco, y crearemos otros problemas.En un gran proyecto de ingeniera de software, el cambio incontrolado lleva rpidamente alcaos. [8]

Pueden establecerse tres distintos tipos de control [9]:


24/29

24

1) Control individual, antes de aprobarse un nuevo elemento.

2) Control de Gestin (u organizado), conduce a la aprobacin de un nuevoelemento.

3) Control formal, se realiza durante el mantenimiento.

1. Control individual (o informal)

Cuando un elemento de la configuracin est bajo control individual, eltcnico responsable cambia la documentacin como se requiere. Aunquese mantiene un registro informal de revisiones, tales registros no se ponengeneralmente en el documento. El control individual se aplica durante lasetapas ms importantes del desarrollo del documento y se caracteriza por loscambios frecuentes.

2. Control de gestin

Implica un procedimiento de revisin y aprobacin para cada cambiopropuesto en la configuracin. Como en el control individual, el control anivel de proyecto ocurre durante el proceso de desarrollo pero es usadodespus de que haya sido aprobado un elemento de la configuracinsoftware. Este nivel de control de cambios se caracteriza por tenermenos cambios que el control individual. Cada cambio es registradoformalmente y es visible para la gestin.

3.

Control de cambios formal

Ocurre durante la fase de mantenimiento del ciclo de vida software (elproducto ya est implantado). El impacto de cada tarea de mantenimiento seevala por un Comit de Control de Cambios (CCC), el cual aprueba lasmodificaciones de la configuracin software.

En un gran proyecto de desarrollo de software, el cambio incontrolado llevarpidamente al caos. El control de cambios combina los procedimientos humanos

y las herramientas automticas para proporcionar un mecanismo para el control decambio. El proceso de control de cambios est ilustrado esquemticamente en laFigura 9.


25/29

2

Figura 9. Proceso de Control de Cambio [8]

3.4. Auditoria de la Configuracin

A efectos de dar consistencia a todas las tareas de Gestin de Configuracin mencionadas,resulta necesario efectuar certificaciones de los cambios implementados en los diferentesproductos mediante la ejecucin de revisiones tcnicas formales.Con este fin, el proceso de Gestin de Configuracin prev la ejecucin de diferentesactividades de control de calidad denominadas Auditoras de Configuracin.Las auditoras que se realizan habitualmente son tres [3]:

-

Auditoria Funcional: Cuyo objetivo es comprobar que se han completado todas laspruebas necesarias para el / los ECS auditados, y que, teniendo en cuenta los resultadosde los tests, se puede afirmar que el / los ECS satisfacen los requisitos que se impusieronsobre l.

- Auditora fsica: Cuyo objetivo es verificar la adecuacin, integridad y precisin de loselementos fsicos de documentacin que constituyen la Lnea Base.

- Revisin formal de certificacin: Cuyo objetivo es certificar que el / los ECS secomportan correctamente en su entorno operativo.


26/29

2

Estas se centran en las siguientes cuestiones [9]:

1. Se ha hecho el cambio especificado en la orden de cambio de ingeniera (OCI)? Se han

incorporado modificaciones adicionales?2. Se ha realizado una revisin tcnica formal para comprobar la correccin tcnica?3. Se han seguido adecuadamente los estndares de ingeniera del software?4. Se han marcado los cambios en el ECS? Se han especificado la fecha y el autor delcambio? Refleja la identificacin del ECS los cambios?5. Se han seguido los procedimientos del GCS para sealar el cambio, registrarlo ydivulgarlo?6. Se han actualizado adecuadamente todos los ECS relacionados?

3.5. Informes de Estado

Esta actividad persigue como objetivo mantener actualizados de los cambios y su dinmicaa gestores y desarrolladores.El logro de este objetivo es responsabilidad del SCC quien deber registrar toda lainformacin necesaria para gestionar eficientemente los cambios y generar los informescorrespondientes. [3]

La generacin de informes de estado de la configuracin desempea un papel vital en elxito del proyecto de desarrollo de software. Cuando aparece involucrada mucha gente esmuy fcil que se d el sndrome de que la mano izquierda ignora lo que hace la manoderecha. Puede que dos programadores intenten modificar el mismo ECS con intencionesdiferentes y conflictivas. Un equipo de ingeniera del software puede emplear meses deesfuerzo en construir un software a partir de unas especificaciones de hardware obsoletas.Puede que la persona que descubra los efectos secundarios senos de un cambio propuesto noest enterada de que el cambio se est realizando. [8]

La generacin de informes de estado de la configuracin (GIEC) responde a las preguntas[9]:

1. Qu pas?2. Quin lo hizo?3. Cundo pas?4. Qu ms se vio afectado?

El flujo de informacin del proceso de GIEC se puede apreciar en la siguiente figura [9]:


27/29

2

Figura 10. Flujo de Informacin [9]

Esta actividad produce dos tipos de documentacin [3]:

Registros: Documentos o bases de datos donde se acumula informacin relacionadacon la Gestin de Configuracin de un determinado producto.

Informes: Formularios, generalmente prefijados, donde se vuelca informacin o datosreferidos a registros relacionados con la Gestin de Configuracin (Lneas Base,Solicitudes de Cambio, ECS, Control de Versiones, etc.)


28/29

28

Conclusiones

Luego de estudiar los ltimos tres captulos se puede llegar a la conclusin que cualquierasea el ciclo de vida seleccionado para un producto software, para su perodo de

mantenimiento, se debe contar, al menos, con los ECS propuestos en cada uno de los ltimoscasos que son para todos los modelos iguales, modelos que estn expuestos en el Captulo I.

Este Ciclo de Vida considerado no tradicional tiende a ser ampliamente utilizado por lagestin de riesgos que se implementa durante el proceso de desarrollo, los Elementos deConfiguracin de Software propuestos en el Captulo II, deben servir como gua al Jefe deProyecto para determinar qu productos intermedios son importantes para asegurar unaadecuada finalizacin de la fase de desarrollo y/o una apropiado transcurso de la fase demantenimiento. Esta situacin tiene sentido ya que, para todos los modelos, las necesidadesde informacin que plantea el perodo de mantenimiento es uniforme.

Durante el proceso de construccin de un software, los cambios son inevitables. Los cambiosprovocan confusin e incertidumbre, sobre todo cuando no se han analizado o pronosticadocorrectamente. La finalidad de la Gestin y configuracin del Software el conocer laestructura de procesos y herramientas para aplicar dentro de la construccin del software quenos ayudan a controlar los cambios. Es importante considerar ciertas modificaciones quepueden ocurrirle al software dentro de todo el proceso de ingeniera para asegurar su controly calidad.

La gestin de configuracin del software es una actividad de proteccin que se aplica a lolargo de todo el proceso del software. La GCS identifica, controla, audita e informa de lasmodificaciones que invariablemente se dan al desarrollar el software una vez que ha sido

distribuido a los clientes.

La configuracin del software est compuesta por un conjunto de objetos interrelacionados,tambin denominados elementos de configuracin del software, que se producen comoresultado de alguna actividad de ingeniera del software. Adems de los documentos, losprogramas y los datos, tambin se puede poner bajo control de configuracin el entorno dedesarrollo utilizado para crear el software.


29/29

Referencias Bibliogrficas

[1]. Universidad Rey Juan Carlos, Ingeniera del Software I, Gestin de Configuracin del Software.

[2]. Specificationsin Software Engineering, I. Horebeek. y J. Lewi., Springer-Verlag, 1989

[3]. Lic. Claudio Jorge Rancn, Gestin de Configuracin de Productos Software en etapa de Desarrollo,julio 2003.

[4]. Dr. Daniel Tapias, Proyectos de Desarrollo Software, Captulo 5, Escuela Politcnica Superior, 2013-14

[5]. Alejandra Virrueta Mndez, Investigacin Documental Metodologas de Desarrollo deSoftware Instituto Tecnolgico Superior de Apatzingn, Apatzingn Michoacn Diciembre 2010.

[6]. Gonzalo Mndez, Proceso Software y Ciclo de Vida, Universidad Complutense de Madrid,Facultad de Informtica, Dpto. de Ingeniera de Software e Inteligencia Artificial, 2008-2009.

[7]. Dr. Pedro Meja lvarez, Diseo, construccin y mantenimiento de sistemas de softwaregrandes, CINVESTAV-IPN, Mxico, Septiembre 2003.

[8]. Pressman, R. S. Ingeniera de Software. Un enfoque Prctico (5 Edicin). Espaa. McGrawHill.

[9]. Sr. D. Juan Antonio Buj PascuaL, Teniente Coronel Inspector del REA de InspeccionesIndustriales, Ministerio de Defensa ESPAA, Gestin de Configuracindurante el ciclo de vidadeun sistema, Jornada de Defensa Gestin de la Configuracin, AEC4 de Octubre del 2012.

[10]. Fuertes Castro, J.L. Gestin de Configuracin de Software X Reunin de Responsables deSistemas de Informacin, (pg. 16). La Antigua, Guatemala. [Distribucin Web]:

http://www.histaintl.com/soluciones/configuracion/configuracion.php

[11]. Antonio, A. d. (s.f.). Gestin, de Configuracin de Software. Recuperado el 16 de Noviembrede 2013 en: http://www.slideshare.net/JohanPrevotR/gestion-de-la-configuracion-del-software-10471407

Gestion de Configuracion de Software

Documents

Transcript of Gestion de Configuracion de Software