GCS_Modelo de Transformación Formal

GCS + Modelo de Transformación Formal
1. Índice
Auditoría en la Gestion de Configuración ..............21
Indice .........................................................................1
Informes de estado .................................................18
Introducción ..............................................................4
Bibliografía ..............................................................23
Como aplicar la GCS al Modelo de Transformación
Formal ...................................................................7
Como implementar una configuración adecuada ..10
Definición de Bibliotecas ........................................13
Marco Teórico ...........................................................5
Modelo de Transformación Formal ..........................6
Propósito ...................................................................2
Esquema de Almacenamiento de Datos ................16
Selección de Líneas Base ...........................................7
Selección de los Elementos de Configuración de
Software (ECS) ......................................................8
Gestión de cambios.................................................14
Términos y abreviaciones .........................................3
Identificar los ECS ....................................................10
Bondar M., Buono M., Larreta L.
1
GCS + Modelo de Transformación Formal
2. Propósito
El presente documento describe el proceso de gestión de configuración del software (GCS) para
procesos que adopten el Modelo de Transformación Formal con el propósito de visualizar
rápidamente cómo una adecuada gestión de configuración puede complementar de la mejor
manera posible este modelo en particular. El mismo está compuesto por una introducción teórica
para comprender tanto el modelo de transformación formal como la gestión de configuración.
Finalmente se expone una gestión de configuración adecuada brindando una solución práctica para
este modelo.
Bondar M., Buono M., Larreta L.
2
GCS + Modelo de Transformación Formal
3. Términos y abreviaturas
Término o
acrónimo
Descripción
GCS
Gestión de Configuración de Software
ECS
Elemento de Configuración de Software
CCC
Comité de Control de Cambio
IEEE
Institute of Electrical and Electronics Engineers
LB
Línea Base
Bondar M., Buono M., Larreta L.
3
GCS + Modelo de Transformación Formal
4. Introducción
Tanto la gestión de la configuración de software (GCS) como el modelo de transformación formal
son conceptos que están claramente definidos por diversos autores, no existe tan claramente una
técnica o metodología de combinar ambos conceptos.
Durante el transcurso de este documento haremos hincapié en el análisis de cómo implementar de
manera adecuada la gestión de configuración de software al modelo de transformación formal. En
este documento se definirá:
1. Cómo implementar las líneas base.
2. Cómo seleccionar los Elementos de configuración de software (ECS) para cada línea base
definida.
3. Cómo aplicar la gestión de cambios de forma práctica para este modelo de ciclo de vida.
4. Método adecuado de cómo aplicar la GCS al modelo de transformación formal.
5. Auditorías de la configuración.
6. Una conclusión general sobre el documento.
7. Las referencias bibliográficas.
Bondar M., Buono M., Larreta L.
4
GCS + Modelo de Transformación Formal
5. Marco Teórico
a. La Gestión de Configuración de Software (GCS)
Cuando se construye software, los cambios, debidos a modificaciones en los requisitos o fallos, son
inevitables. Debido a esto, necesitamos controlarlos eficazmente. Normalmente se trabaja en
equipo por lo que es preciso llevar un control y registro de los cambios con el fin de reducir errores,
aumentar la calidad y evitar los problemas que pueda acarrear una incorrecta sincronización en
dichos cambios, al afectar a otros elementos del sistema o a las tareas realizadas por otros
miembros del equipo de proyecto.
La gestión de configuración del software (GCS) es una actividad que se aplica durante el proceso del
software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven
para:
1.
2.
3.
4.
Identificar el cambio,
Controlar el cambio,
Garantizar que el cambio se implementa adecuadamente e
Informar del cambio a todos aquellos que puedan estar interesados.
Según Babich [BAB86], “El arte de coordinar el desarrollo de software para minimizar la confusión,
se denomina gestión de configuración. La gestión de configuración es el arte de identificar,
organizar y controlar las modificaciones que sufre el software que construye un equipo de
programación. El objetivo es maximizar la productividad minimizando los errores”.[1]
Según el Standard de la IEEE [2] la GCS cuenta con cuatro tareas fundamentales:
1. La Identificación de la configuración
Tarea en la cual debe obtenerse la información y los futuros productos que el proceso
generará, denominados Elementos de configuración del software (ECS)
2. El Control de los cambios
La cual especificará como los distintos ECS serán gestionados durante su evolución
3. La Generación de Informes de Estado
Para comunicar el estado del proyecto
4. La Auditoría de la Configuración
Con la cual se validará que se cumplan con los objetivos deseados.
Con Gestión, nos referiremos al control de la evolución y los cambios de la configuración del
software. Y con Configuración del Software nos referiremos al conjunto de toda la información
utilizada, y todos los productos generados por un proyecto. A ésta información y productos los
Bondar M., Buono M., Larreta L.
5
GCS + Modelo de Transformación Formal
llamaremos Elementos de Configuración del Software (ECS), y serán nuestra unidad de trabajo
durante el proceso.
b. Modelo de Transformación Formal
El modelo de transformación formal (ver Figura 1), propuesto por Robert Balzer en 1983, aplica una
serie de transformaciones usando un soporte automatizado para convertir una especificación
formal (modelo matemático) en un sistema implementable (ejecutable). Es decir, este paradigma
intenta automatizar las etapas de diseño e implementación utilizando el concepto de
transformación. También se denomina a este paradigma Síntesis Automática de Software.
Fases:




Análisis de requisitos
Especificación formal
Transformación
Integración y prueba del sistema final
Requisitos Informales
Análisis de
requisitos
Especificación Formal
Transformar
Sistema final
Validación
Mantenimiento
Refinado
Figura 1 - Proceso de Transformación formal de Robert Balzer[3]
La especificación formal se convierte en forma sistemática en una representación más detallada del
sistema, matemáticamente correcta. Cada paso agrega detalle hasta que la especificación formal se
convierte en un programa equivalente. Como hay muchos caminos a seguir desde la especificación
hasta el sistema final, la secuencia de transformaciones y su justificación se reflejan en un registro
formal de desarrollo. Se utilizan técnicas de validación del modelo matemático, como la Simulación.
La especificación de requisitos se refina en una especificación formal detallada, expresada en
notación matemática. Los procesos de diseño, implementación y prueba de unidades se reemplaza
por un proceso de transformaciones donde la especificación formal se refina hasta llegar a un
Software.
Bondar M., Buono M., Larreta L.
6
GCS + Modelo de Transformación Formal
6. Cómo aplicar la GCS al Modelo de Transformación Formal
a. Selección de Líneas Base
Consideramos solo 2 líneas bases (ver Figura 2) y no un número excesivo de las mismas ya que
resulta contraproducente para el proyecto, dado que cada una de ellas implica un costo de
mantenimiento importante. El hecho de que cada una de ellas, para ser modificada, requiera un
procedimiento formal, puede derivar en pérdida de flexibilidad del proyecto ante las solicitudes de
cambios del usuario final, volviéndose demasiado rígido.
Las 2 líneas base identificadas son las siguientes:
Líneas Base
LBFunc: Línea base funcional (Especificación Formal)
La línea base LBFunc, se fija una vez finalizada la especificación formal ya que este será el punto de
partida del resto del proceso de transformación formal, por lo tanto, cualquier revisión o cambio
sobre la especificación formal, deberá ser solicitada y aprobada o rechazada mediante un
procedimiento formal de solicitud de cambios. Cabe aclarar que, dado el grado de certeza y libre de
ambigüedades que se busca al realizar una especificación formal debería estar minimizada o
fuertemente acotada la posibilidad de cambios en la especificación de requisitos, sumando otro
motivo al establecimiento de la línea base en este punto.
LBProd: Línea base de producto (Sistema Final)
La línea base LBProd se propone una vez validado con el usuario final el sistema final. La
importancia de esta línea base es servir de punto de partida para futuras entregas y para diferentes
versiones del sistema final.
LBFunc
Requisitos Informales
Análisis de
requisitos
Especificación Formal
LBProd
Transformar
Sistema final
Validación
Mantenimiento
Refinado
Figura 2 – Líneas base del modelo de transformación formal
Bondar M., Buono M., Larreta L.
7
GCS + Modelo de Transformación Formal
b. Selección de los Elementos de Configuración de
Software (ECS)
A continuación se listaran los elementos de configuración de software (ECS) que se consideraron
adecuados para este modelo de ciclo de vida. La cantidad de elementos no es elevada para evitar
costos en la mantención de los elementos de configuración y para tener controlado y administrarlos
de manera efectiva a los mismos.
Línea base funcional – LBFunc
a. Especificación Formal
b. Documento de Mantenimiento
Línea base de producto – LBProd
a.
b.
c.
d.
e.
f.
g.
Sistema Final
Compilador Automático 2
Código fuente del compilador automático
Registro formal de desarrollo
Manual de usuario
Manual de instalación
Manual de operación
Hemos seleccionado estos elementos de configuración, ya que los mismos representan una unidad
crítica para el desarrollo exitoso del proyecto. Los mismos conforman una entrada para la
generación de otro elemento de configuración. Estos elementos van a ir cambiando a medida que
pasa el tiempo y es importante e interesante administrar la evolución de los mismos, para poder
identificar falencias y poder revertirlas, por eso decidimos que estos elementos deben estar bajo la
gestión de configuración de Software.
Línea base funcional – LBFunc
a. Especificación Formal: identifica de manera formal lo que el usuario requiere y está casi a un
paso de convertirse en un ejecutable, es importante mantener este elemento ya que
proviene de los requisitos informales.
b. Documento de Mantenimiento: registra las modificaciones que se llevan a cabo en la
especificación formal. Con lo cual, resulta crítico llevar un control sobre los cambios que se
van realizando sobre la especificación.
Línea base de producto – LBProd
Bondar M., Buono M., Larreta L.
8
GCS + Modelo de Transformación Formal
a. Sistema Final: es el sistema que utiliza el usuario, y es importante controlar el mismo, para
evitar que el mismo se convierta en un elemento inmanejable.
b. Compilador Automático 2: es el elemento que aplica las transformaciones sobre la
especificación formal, para obtener el sistema final. Se debe administrar, ya que el mismo
dará como resultado el producto que usa el usuario final.
c. Código fuente del compilador automático: el mismo conforma el Compilador Automático 2,
y es necesario saber cómo funciona y que transformaciones realiza.
d. Registro formal de desarrollo: en el mismo se registran cada una de las transformaciones
que se aplican sobre la especificación formal, con lo cual, es importante identificar las
transformaciones que se fueron llevando y dieron como resultado al sistema final.
e. Manual de usuario: muestra al usuario las funcionalidades del sistema final, y lleva en el
mismo las mejoras que se fueron realizando progresivamente sobre el sistema. Le indica
cómo debe usar el sistema.
f. Manual de instalación: indica cómo debe instalarse el sistema final e identifica diferentes
cambios que pudieron llevarse a cabo, debido a las modificaciones del sistema final.
g. Manual de operación: identifica de que manera configurar el sistema final para luego ser
utilizado, o sea, las operaciones que hay que llevar a cabo antes de que el usuario pueda
utilizar el sistema final.
Aclaraciones: En la LBFunc no hemos elegido a los requisitos informales, porque, como su
denominación lo indica son informales y no tienen un registro formal el cual impide que se tome
como base para futuras implementaciones y no se puede controlar sus cambios.
Bondar M., Buono M., Larreta L.
9
GCS + Modelo de Transformación Formal
7. Cómo implementar una configuración adecuada
Las actividades que se realizaran durante esta etapa tienen como principal objetivo establecer y
mantener la integridad de los productos generados durante el proyecto de desarrollo de software y
a lo largo de todo el ciclo de vida del producto así como también evaluar y controlar los cambios
sobre ellos.
a. Identificar los ECS
Consiste en identificar inequívocamente a cada uno de los ECS así como también hacer referencia al
proyecto, la versión, la etapa del ciclo de vida a la cual se corresponde.
Hemos decidido identificar de manera diferente a los ECS dependiendo de la línea base donde se
encuentran. Como los ECS de la LBProd están relacionados con transformaciones la forma de
identificar las diferentes versiones de los ECS será a través del número de transformación por el
cual se está transitando. Por otro lado, a aquellos ECS que pertenecen a la LBFunc serán
identificados con el número de versión.
Identificación por Versiones
Requisitos Informales
Análisis de
requisitos
Identificación por Transformaciones
Especificación Formal
Transformar
Sistema final
Validación
Mantenimiento
Refinado
Tomando en cuenta esto decidimos que una forma adecuada de hacer la identificación es como se
muestra en la figura 3.a para los ECS de la LBFunc y la figura 3.b para los ECS de la LBProd.
Bondar M., Buono M., Larreta L.
10
GCS + Modelo de Transformación Formal
Identificador por Versiones
Proyecto
ProyectoY
Tipo de ECS
+
EF
Versión
+
1.4
ProyectoY_EF_1.4
Figura 3.a – Identificación de los ECS de la LBFunc
Identificador por Transformaciones
Proyecto
ProyectoY
Tipo de ECS
+
SF
Transformación
+
6
ProyectoY_SF_6
Figura 3.b – Identificación de los ECS de la LBProd
Bondar M., Buono M., Larreta L.
11
GCS + Modelo de Transformación Formal
En la siguiente tabla se podrá ver el listado de los elementos de configuración de software y su
código correspondiente.
Línea Base
LBFunc
LBProd
Identificación
Tipo de ECS
EF
Versiones
DM
SF
CA
CF
Transformaciones RD
MU
MI
MO
Bondar M., Buono M., Larreta L.
Elemento de Configuración (ECS)
Especificación Formal
Documento de Mantenimiento
Sistema Final
Compilador Automático 2
Código fuente del compilador automático
Registro formal de desarrollo
Manual de usuario
Manual de instalación
Manual de operación
12
GCS + Modelo de Transformación Formal
b. Definición de Bibliotecas
Al iniciar cada proyecto se creará una biblioteca particular para el mismo, que consistirá en un
directorio de trabajo, identificado con un conjunto de caracteres formado por el nombre del
proyecto, el tipo de biblioteca y el año de inicio, en el que el grupo de desarrollo realizará sus
tareas.
En la presente propuesta creímos conveniente la utilización de las siguientes bibliotecas de
software:
Biblioteca Maestra: Este es el repositorio que almacenará las distintas versiones releases de los ECS.
Los elementos de esta biblioteca se encuentran sujetos a un control de cambios formal y estricto.
Todos los ECS deberán pertenecer a la biblioteca maestra.
Biblioteca de backups: el contenido de esta biblioteca no está sujeto a la gestión de configuración,
por lo que no están permitidos los cambios en este repositorio.
Biblioteca de trabajo: Esta es el área de trabajo local para desarrollo donde se realiza la codificación
del compilador automático y del sistema final, y la generación de la especificación formal, por ende
aquí los cambios son informales y no requieren ningún tipo de aprobación formal.
En esta biblioteca, los ECS involucrados serán los siguientes:
 Especificación formal
 Código Fuente del Compilador automático
 Sistema Final
Biblioteca de Auditoría: Aquí se almacenaran los ECS aprobados y transferidos desde cada una de
las bibliotecas de trabajo. En esta biblioteca estarán los ECS que serán auditados.
En esta biblioteca, los ECS involucrados serán los siguientes:
 Especificación formal
 Sistema Final
Bondar M., Buono M., Larreta L.
13
GCS + Modelo de Transformación Formal
c. Gestión de cambios
En la presente propuesta el mecanismo sugerido para realizar el control de cambios, es el siguiente:
El nivel de cambios informal se aplicará de acuerdo a lo establecido en la Gestión de Configuración
tradicional. Dichas modificaciones se gestionarán de la forma habitual, mediante herramientas de
registración de incidentes y versionado de software, no requiriendo evaluaciones ni aprobaciones
formales.
Este tipo de cambios se realizaran sobre los ECS que aun no formen parte de una línea base
preestablecida, por ejemplo la Especificación Formal antes de que forme parte de la línea
base funcional
El nivel de cambios semiformal, implicará una registración de las solicitudes en un documento
específico, debiendo ser las mismas evaluadas y eventualmente aprobadas por el Project leader
Los cambios semiformales se efectuaran sobre los ECS que ya pasaron por una revisión
técnica formal y forman parte de una línea base.
Para la aplicación del control de cambios formal (ver Figura 4) deberá utilizarse el siguiente
proceso:
Se presenta una Solicitud de Cambio ante el Comité de Control de Cambios (CCC). La misma debe
contener obligatoriamente el motivo del cambio, qué es lo que debe cambiarse, quién lo solicita y
una descripción clara del problema.
Un integrante del Comité de Control de Cambios decide si se acepta o rechaza la solicitud.
En caso de ser aceptada, se procede a evaluar su impacto, esfuerzo estimado, costo, y se emite un
Informe de Cambios.
Se presenta el Informe al Comité de Control de Cambios.
Si es aceptado se genera una Orden de Cambio, la cual describe el cambio a realizar, las
restricciones que deben respetarse, y los criterios de revisión y auditoría.
Se realiza el cambio, para ello se toma la última versión del/los elemento/s de configuración
involucrados, es decir, la de la línea base correspondiente y se generan nuevas versiones de los
mismos.
Una vez finalizado el cambio, se certifica que el mismo haya sido efectuado correctamente de
acuerdo a las normas y estándares establecidos, pasando el mismo a integrar la línea base
correspondiente.
Los cambios formales se aplican sobre los ECS que forman parte de la Biblioteca Maestra.
Bondar M., Buono M., Larreta L.
14
Figura 4 – Control de Cambios Formales por parte del CCC
GCS + Modelo de Transformación Formal
Solicitud de
Cambio
¿Se acepta
solicitud?
No
Si
Informe de
Cambios
Cancela el
Cambio
¿Se acepta
Informe?
Si
No
Orden de
Cambio
Cancela el
Cambio
Se realiza el
cambio
Valida e
Incorpora a
Línea Base
Bondar M., Buono M., Larreta L.
15
GCS + Modelo de Transformación Formal
El Comité de Control de Cambios estará formado por personas pertenecientes a todas la partes
interesadas en el desarrollo del proyecto. En proyectos pequeños el CCC está integrado por el
Software Architect y/o el Project Manager junto con un Representante del Cliente. En proyectos
grandes, el número de integrantes suele elevarse, incluyendo a responsables de QA, Project
Leaders, Analistas de Riesgo, Implementadores.
Solicitud de Cambio
Proyecto: ProyectoY
Id: ProYSF.12a
Titulo: Nuevo régimen AEO098
Responsable: Guzmán, Juan
Ubicación: Módulo A74
Mail contacto: [email protected]
Fecha: 7/11/2011
Estado: Pendiente
Prioridad:
Crítica X Alta
Media
Baja
Descripción: Cambio Sistema Final
Motivo: Se adjunta el nuevo régimen AEO098 en la empresa, el mismo
debe ser implementado antes de fin de año.
Figura 5 – Solicitud de Cambio
Bondar M., Buono M., Larreta L.
16
GCS + Modelo de Transformación Formal
d. Esquema de Almacenamiento de Datos
En el siguiente esquema (ver Esquema 1) se puede visualizar la manera en la que almacenaremos
los datos relacionados a la Gestión de Configuración se Software para el Modelo de Transformación
Formal.
Esquema 1 – Esquema de los datos a almacenar.
Bondar M., Buono M., Larreta L.
17
GCS + Modelo de Transformación Formal
e. Informes de estado
El objetivo de la generación de informes de estado es mantener a los gestores y a los
desarrolladores al tanto de los cambios más importantes que se produzcan en el software.
La generación de los informes depende de la organización, así como su periodicidad y nivel de
detalle. Los productos de esta actividad son los registros e informes. Los mínimos exigidos por el
presente enfoque serán los siguientes:
Registro de solicitudes de cambio (Documento de Solicitud de Cambios): el mismo servirá como
base para la posterior generación de informes. Incluirá, al menos, la siguiente información,
quedando librado a criterio de la organización el resguardo de contenido extra (ver Figura 6):
1. Id Solicitud de Cambio
2. Descripción
3. Motivo
4. Fecha
5. Ubicación
6. Estado
Informe de estado de los cambios: resumen del estado en que se encuentran todas las solicitudes
de cambio registradas durante un determinado período de tiempo (Ver Figura 7). El mismo se
generará a pedido del usuario final, o del Project manager en el momento que se desee. No tiene
previsto una frecuencia predefinida.
Informe de elementos de configuración: su objetivo es ofrecer visibilidad sobre el contenido de los
ECS, permitiendo ver en que versión se encuentran actualmente, fecha de última modificación,
usuario responsable, etc. En la siguiente Figura 5 se puede ver un ejemplo.
Informe de los ECS
Proyecto: ProyectoY
Fecha: 7/11/2011
Código Descripción
SF
CA
Versión Línea Base Transformación
Sistema Final
Compilador Automático 2
Código fuente del
CF
compilador automático
Registro formal de
RD
desarrollo
EF
Especificación Formal
2.3
Documento de
DM
Mantenimiento
1.4
Figura 5 – Informe de Estado – Informe de los ECS
Bondar M., Buono M., Larreta L.
2
2
2
2
2
2
2
1
2
1
18
GCS + Modelo de Transformación Formal
Informe de Solicitudes de Cambios
Proyecto: ProyectoY
Fecha Inicio: 7/11/2011
Fecha Fin: 14/02/2012
Id
Solicitud
Descripción
Motivo
Fecha
Ubicación
Estado
7/11/2011
\\Repositorio\Cambios\
Pendiente
ProYSF.12a
Cambio Sistema
Final
ProYCA.1b
Cambio Compilador Parche P34 para
transformación 2
Automático
10/11/2011
\\Repositorio\Cambios\
Completo
ProYCF.5c
Cambio Código
Falla de ejecución
Fuente Compilador
12/11/2011
\\Repositorio\Cambios\
Hold
ProYEF.1b
Cambio en
Especificación
Formal
Nuevos requisitos
14/01/2012
\\Repositorio\Cambios\ Suspendido
ProYDM.4a
Cambio en
Documento de
Mantenimiento
Nuevos requisitos
7/1/2012
\\Repositorio\Cambios\ En Progreso
Nuevo régimen
AEO098
Figura 6 – Informe de Estados - Registro de Solicitud de Cambios
Bondar M., Buono M., Larreta L.
19
GCS + Modelo de Transformación Formal
Informe de Estado de los Cambios
Proyecto: ProyectoY
Fecha Inicio: 7/11/2011
Fecha Fin: 14/02/2012
Id Solicitud
Descripción
1
Transformación
Cambio Sistema Final
2
Cambio Compilador
2
2
Automático
Cambio Código Fuente
3
3
Compilador
Cambio en Especificación
5
4
Formal
Cambio en Documento
6
4
de Mantenimiento
Figura 7 – Informe de Estados – Informe de Estado de los Cambios
Bondar M., Buono M., Larreta L.
Estado
Implementado
Implementado
Implementado
Implementado
En Implementación
20
GCS + Modelo de Transformación Formal
f. Auditoría en la Gestión de Configuración
Para validar la completitud de un producto, y la consistencia entre sus componentes se
realizarán auditorías sobre todas las líneas base, además de revisiones técnicas formales que se
llevarán a cabo en las diferentes etapas del Modelo de Transformación Formal. Estas revisiones
estarán a cargo de un grupo ajeno al equipo de desarrollo, a fin de garantizar la objetividad que
sería imposible de mantener si quienes desarrollan tuvieran que auditar fueran quienes
realizaron el trabajo.
En el marco del modelo de transformación formal, contamos con dos grupos de tareas bastante
diferentes entre sí, la primera está relacionado con el análisis de requisitos cuyo resultado es la
Especificación Formal y la segunda está más relacionada con las transformaciones realizadas
por el compilador automático cuyo resultado es el sistema final. La manera de auditar las 2
líneas bases resultantes, también será diferente.
Especificación Formal:
Para el caso de la especificación formal, la idea es auditarlo si se está registrando sus
versiones de manera correcta, si pertenece a la biblioteca correspondiente y si está dentro del a
línea base a la cual pertenece.
Si en la Auditoría se encuentran errores en la especificación formal, se llenará un formulario
indicando cuál es problema encontrado. Luego se enviará la Especificación Formal junto con
dichos formularios, para que el equipo de Analistas de Sistemas pueda corregir los errores
detectados.
En caso de que no se encuentren errores, la Especificación Formal se aprueba y se almacena en
la biblioteca maestra.
Sistema Final:
Para el Sistema final, se auditará si se están registrando las diferentes transformaciones
por las que va pasando, si pertenece a las bibliotecas correspondientes y si está dentro de la
línea base a la cual pertenece.
Si en la Auditoría se encuentran errores en el sistema final, se llenará un formulario indicando
cuál es problema encontrado y se lo transmitirá a los desarrolladores que se encargarán de
realizar las modificaciones correspondientes.
En caso de que no se encuentren errores, el sistema final se aprueba y se almacena en la
biblioteca maestra.
Bondar M., Buono M., Larreta L.
21
GCS + Modelo de Transformación Formal
Planilla Auditoría ECS
Proyecto: ProyectoY
Usuario Auditor: Usuario X
Fecha Auditoría: 08/11/2011
ECS Auditado: Sistema Final
Identificado por: Versiones o Transformaciones
Código ECS
Nombre ECS Transf./Versión
SF
ProyectoY_SF_4.exe Transformación 3
Error
Estado
Se ha detectado un
error en la
funcionalidad X24.
La alarma no
utilizar el descriptor
led de la pantalla.
Identificado
Ubicación ECS: \\Repositorio\Auditoría\ECS
Formulario 1 – Auditoría – Planilla de auditoría de un ECS
Bondar M., Buono M., Larreta L.
22
GCS + Modelo de Transformación Formal
8. Conclusión
El modelo de transformación formal se aplica principalmente a proyectos donde la seguridad es
crítica, y los cambios que pueden llevarse a cabo deben ser gestionados de manera confiable y
precisa. Además el acceso a la información debe ser clara y fácil. Con lo cual establecemos una
Línea Base funcional que nos permitirá establecer un punto de confianza sobre los requisitos
informales que el usuario final nos brinda y porque también es el punto de comienzo de la
etapa de desarrollo y otra línea base del producto para establecer un punto de confianza sobre
el sistema final.
Como desventaja de implementar la Gestión de Configuración al modelo de transformación
Formal podemos citar la complejidad y el costo de gestionar dicha metodología, pero haciendo
una comparación del costo beneficio entre las ventajas y desventajas, este modelo nos brinda
mayor cantidad de ventajas y nos ayuda a poder llevar a cabo con éxito tanto el desarrollo
como el mantenimiento de los sistemas software.
Para finalizar llegamos a la conclusión de que ambas metodologías compatibles, lo que significa
que es posible usarlas dentro de un mismo proyecto para gozar las ventajas que ambas ofrecen
a los involucrados en la construcción del software. La GCS es costosa y quizás dificil (engorrosa),
pero para este modelo donde la seguridad está en juego, la GCS es vital para el éxito.
Bondar M., Buono M., Larreta L.
23
GCS + Modelo de Transformación Formal
9. Bibliografía
[1] Babich W.A., Software Configuration Management, Addison – Wesley, 1986
[2] ANSI/IEEE 1042-1987 IEEE Guide to Software Configuration Management, 1987
[3] Balzer, R., Cheatham, T.E,, Green, C., "Software technology in the 1990s: using a new
paradigm", IEEE Computer, 1983
Pressman, Roger S, Ingeniería del software. Un enfoque practico - Quinta Edición, McGraw - Hill,
2002
Bondar M., Buono M., Larreta L.
24