7 FINDINGS OF FACTOR ANALYSIS
8.5 The regression model and explaination of turnover intention
8.5.2 Assessment of the different models/ blocks of variables at different steps:
Todos los estándares que se han presentado en las secciones anteriores están enfocados a la creación de una documentación que cumpla con los siguientes criterios básicos:
Los objetivos de la documentación del proyecto se satisfacen adecuadamente.
Se proporciona una descripción clara de la gestión del software, la ingeniería y el aseguramiento de procesos y productos.
Se mantiene la consistencia del formato de los documentos a lo largo del proyecto.
Se mantiene la trazabilidad con respecto a los elementos originales del estándar.
Se mantiene la trazabilidad entre productos de cada fase del ciclo de vida de desarrollo.
En el caso de ISO existe un proceso de apoyo para la documentación. Sin embargo, se trata de la gestión de la documentación, no de su creación. La gestión de la documentación también aparece de forma implícita en la organización por “carpetas” en el caso de la Agencia Espacial Europea.
Todos los estándares proponen estructuras de plantillas para sus documentos y los relacionan con las fases, actividades y tareas del ciclo de vida. También proponen guías de adaptación para la documentación.
En cualquier caso, se sigue manteniendo el punto de vista de realizar las tareas de un determinado proceso y documentarlas, como una actividad más del proceso. Esto nos lleva a los problemas de documentación que hemos estudiado en el capítulo de introducción: la producción de la documentación como una tarea que retrasa el progreso del proyecto y que tiende a estar relegada.
Los estándares de documentación son una excelente entrada de información para la definición de una metodología de desarrollo centrada en documentos: aportan la estructura de los mismos, las actividades y tareas asociadas a la creación de los
Capítulo 2 2-13 documentos (aunque no con el detalle deseable), las relaciones entre documentos y las personas o roles involucrados.
La Tabla 2-2 muestra un resumen comparativo de los distintos estándares. Como se ha comentado, todos presentan unas características muy similares que no hacen destacar especialmente a ninguno en particular.
Criterios evaluados ISO IEEE ECSS NASA RUP
Adhesión a ISO
12207
●
●
◑
○
○
Proceso de
documentación
●
●
○
◑
○
Alienación con los procesos de la organización
◑
◑
●
◑
●
Trazabilidad●
●
●
●
●
Gestión de configuración●
●
●
●
●
Definición de estructura de documentos◑
●
●
●
●
Indica qué se debe hacer con cada
documento
●
●
●
●
●
Indica cómo se debe cumplimentar cada documento
◑
◑
◑
●
●
Leyenda: ● si, ◑ parcialmente, ○ no
Tabla 2-2. Comparativa de estándares de documentación 2.2 Metamodelos para la definición de metodologías
Los procesos y metodologías de desarrollo de software siempre se han descrito de forma adaptable para ser usadas por los desarrolladores. Tratan qué tareas y técnicas deberían usarse, qué clase de ciclo de vida es el apropiado y cómo estos elementos de proceso se deberían organizar en el tiempo y su asignación al personal de desarrollo. A menudo se describen en un manual que el director de proyecto y su equipo deben seguir. Con la llegada de las herramientas CASE, se hizo necesaria la creación de unas reglas básicas para que estas herramientas pudiesen soportar estos procesos. Estas reglas mostrarían cuando son apropiadas, por ejemplo, secuenciar dos actividades, tres técnicas y después cuatro roles (algo que no debe ocurrir, ya que no tiene sentido alguno). Estas reglas están contempladas comúnmente en un metamodelo.
Los metamodelos son útiles para la especificación de conceptos, reglas y relaciones usadas para definir una familia de metodologías. Aunque es posible definir una metodología sin un metamodelo explícito, la posibilidad de definir los conceptos de
2-14 Capítulo 2
una metodología de manera formal es importante a la hora de comprobar la consistencia de la metodología definida o cuando se modifica o extiende la misma. Un buen metamodelo debe tener en cuenta todos los diferentes aspectos de las metodologías, por ejemplo, los procesos a seguir y los productos a generar. A cambio, la especificación de los productos que van a ser desarrollados implica la definición de los bloques básicos de modelado a partir de los que van a ser construidos.
Los metamodelos se usan con frecuencia por parte de los metodologistas para construir o modificar metodologías. A cambio, las metodologías son utilizadas por equipos de desarrollo software para construir productos software dentro del contexto de sus proyectos software. Metamodelo, metodología y proyecto constituyen tres áreas diferentes de conocimiento que, al mismo tiempo, corresponden con tres niveles de abstracción diferentes y tres conjuntos diferentes de conceptos fundamentales. Así como el trabajo realizado por el equipo de desarrollo a nivel de proyecto está restringido y dirigido por la metodología usada, el trabajo que realiza el metodologista a nivel de metodología está restringido y dirigido por el metamodelo elegido. Tradicionalmente, estas relaciones entre “niveles de modelado” se han visto como relaciones de instanciación en las que los elementos de un nivel corresponden con instancias de elementos del nivel superior.
Con respecto al nivel de proyecto, hay que tener en cuenta que hay muchas actividades que se realizan en este nivel conceptual, pero que no están relacionadas directamente con un proyecto en concreto, tales como actividades relacionadas con las infraestructuras o la organización en general. Aunque el término “proyecto” se utiliza para nombrar este nivel conceptual, incluye actividades que no tienen que estar necesariamente asociadas a un proyecto en particular.
La mayoría de las aproximaciones a metamodelos orientados a objetos definen un metamodelo como un modelo de una metodología que un equipo de desarrollo de software puede utilizar. Según esta aproximación convencional, los metodologistas utilizan las clases en el metamodelo para crear instancias en el nivel de metodología y, por consiguiente, generar una metodología. Sin embargo, estos objetos del nivel de metodología se utilizan con frecuencia por el equipo de desarrollo como clases para
Capítulo 2 2-15 crear elementos en el nivel de proyecto durante la ejecución (enactment) de la metodología (Figura 2-6). Esta es una aparente contradicción que sólo aparece resuelta en uno de los metamodelos estudiados: ISO 24744.
La utilización de metamodelos para la definición de procesos orientados a objetos se inició a mediados de los años 90 con el OPEN Consortium (http://www.open.org.au) llegando a la versión actual del OPEN Process Framemework (OPF) (Firesmith & Henderson-Sellers, 2002). El Object Management Group lanzó una petición de propuestas de la que surgió el Software Processing Engineering Metamodel (SPEM) (Anon., 2002) . En paralelo, la comunidad de madurez del software, bajo los auspicios de la Unión Europea, fundó un proyecto llamado OOSPICE, que también desarrolló un metamodelo dirigido a dar soporte a la posibilidad de generar metodologías de distinto nivel de madurez (Henderson-Sellers, 2004). La investigación dentro de la comunidad de Computer Support for Colaborative Work (CSCW) dio como resultado un metamodelo llamado LiveNet (Hawryszkiewycz, 2000). En Febrero de 2007, ISO publica el estándar 24744 “Software Engineering - Metamodel for Development Methodologies”, un metamodelo que trabaja con los conceptos de powertypes y clabjects.
Debido a que muchos de los autores de estos distintos metamodelos pertenecen a más de un grupo, aparecen ideas repetidas en ellos. No obstante, es importante realizar una comparación de estos cinco metamodelos.