Índice. Configuración de Sistemas Informáticos. 2.1 Elementos de la configuración Planificación de un Departamento de Informática

Transcripción

1 Índice Configuración de Sistemas Informáticos Tema 2 - Configuración del Software 2.!CONFIGURACIÓN DEL SOFTWARE 2.1.! ELEMENTOS DE LA CONFIGURACIÓN ! PLANIFICACIÓN DE UN DEPARTAMENTO DE INFORMÁTICA. PLANES ! RIESGOS DE UNA PLANIFICACIÓN INADECUADA ! SELECCIÓN DE HARDWARE ! SELECCIÓN DE SOFTWARE ! SELECCIÓN Y GESTIÓN DE RRHH 2.2.! CONFIGURACIÓN DEL SOFTWARE ! VISIÓN GENERAL ! GESTIÓN DE PROYECTOS ! GESTIÓN DE LA CONFIGURACIÓN SOFTWARE (GCS) " LINEAS BASE ! ELEMENTOS DE LA CONFIGURACIÓN (ECS) " PROCESO DE GCS E ID. DE OBJETOS " CONTROL DE VERSIONES " CONTROL DE CAMBIOS Planificación de un Departamento de Informática Planificación de un Departamento de Informática La planificación de un departamento de Informática contribuye a proteger la rentabilidad y a evitar la infrautilización de los recursos disponibles, forzando a que la toma de decisiones que involucren estos recursos, se efectúe de un modo consistente con los objetivos generales de la Organización. En esta primera aproximación es conveniente resaltar la dependencia con una Organización mayor (el sistema informático como subsistema). La planificación en el ámbito del servicio informático se puede dividir en niveles o jerarquías diferentes, pudiendo hablarse de los tres componentes fundamentales de un plan: plan estratégico táctico y operacional Toda planificación, una vez hecha y puesta en marcha, debe controlarse: Es necesario evaluar la efectividad del plan y su incidencia en el rendimiento de la Organización. 3 4

2 2.1.1 Planificación de un Departamento de Informática Planificación de un Departamento de Informática a) Plan Estratégico Es un documento que comprenderá fundamentalmente problemas de asignación de recursos, describiendo los siguientes aspectos: Relativos al entorno empresarial A las exigencias de información detectadas A prioridades y relaciones coste/beneficio A la arquitectura de datos y aplicaciones Al modo en que se soporta actualmente la actividad del negocio Se detallarán además elementos de futuro como son: Programa de evolución hacia la nueva situación o método Estructura y recursos necesarios para la realización y dirección de tal evolución Mecanismo de control con que garantizar en el futuro la actualización del plan del Sistema de Información Importante: naturaleza dinámica de estos últimos apartados Planificación de un Departamento de Informática Planificación de un Departamento de Informática b) Plan Táctico Tiene por objetivo el desarrollar un plan de proyectos ordenados por prioridades, que cubra las necesidades de previsión de aplicaciones, datos y sistemas. Los elementos más importantes que debe contener son: La estimación de los tiempos y recursos que se necesitan por proyecto Fijación de los costes Viabilidad de cada uno de los proyectos Importante: plan táctico afecta a todo tipo de actividades y a distintos niveles c) Plan Operacional No existe un único plan operacional, sino que debemos hablar de planes operacionales. No van a ser únicos (como los dos anteriores) sino que cada uno de ellos vendrá a asegurar la realización de las tareas contenidas en los planes anteriores. Consiste en la puesta en marcha o ejecución de los definido y en acuerdo con los planes anteriores. 7 8

3 2.1.2 Riesgos de una planificación inadecuada Riesgos de una planificación inadecuada a) Desarrollo de aplicaciones inconexas: de no efectuarse la adecuada planificación de la cartera de aplicaciones, se podrán: desarrollar aplicaciones de un modo independiente entre ellas sin interrelación lógica con la consiguiente pérdida de rendimiento. b) Información Redundante: este problema puede tener su origen en una consecuencia directa del problema anterior. La falta conexión entre aplicaciones suele llevar generalmente a la aparición de informaciones redundantes e inconexas. c) Sensación de Informática caótica: de tener un importante número de grupos de trabajo dedicados a labores sin conexión entre ellas, puede derivarse en una situación de difícil gobernabilidad de todos ellos, consecuencia directa de la ineficiente o nula planificación de trabajos y recursos. La sensación de desorientación puede ser importante, dada la inexistencia de un objetivo claramente definido. Lógicamente es difícil cumplir un objetivo que no se conoce de antemano, porque no ha sido establecido o al menos no con claridad. En una situación de desconcierto se empiezan muchas cosas y se acaban pocas, de las cuales los usuarios utilizan poco eficientemente. Una situación de este tipo puede provocar una desconexión del departamento de informática con el resto de la empresa Selección de Hardware Selección de Hardware Las tres principales opciones para la adquisición de un equipo incluyen la compra, el alquiler y el alquiler con opción a compra (leasing). Hay ventajas e inconvenientes a considerar en cada una de las opciones. Dentro de los factores que influyen en la decisión están los siguientes: a) costes iniciales frente los costes a largo plazo b) si se puede invertir capital en la operación c) si se desea control y responsabilidad total sobre el equipo Compra Implica que la empresa sea la propietaria del mismo. Vida proyectada del sistema: si va a ser utilizado por más de cuatro o cinco años (si otros factores se mantienen constantes) la decisión es comprar. Conforme los equipos se vuelven más pequeños y los sistemas distribuidos son más populares, a las empresas les resulta más rentable la compra

4 2.1.3 Selección de Hardware Selección de Hardware Alquiler con opción a compra (leasing) Alquiler Es más práctico si la vida del sistema es menor a cuatro años. Si se prevé un cambio en la tecnología. Permite a la empresa colocar dinero en otra inversión. No es la mejor opción a largo plazo. Sólo se debe contemplar como una alternativa a corto plazo para resolver necesidades limitadas o cuando hay cambios tecnológicos frecuentes. Normalmente se incluye el mantenimiento y el seguro en el contrato Selección de Hardware Selección de Hardware ventajas inconvenientes COMPRA ALQUILER CON OPCIÓN A COMPRA ALQUILER A largo plazo más económico que alquilar. Posibilidad de cambiar el sistema. Ofrece ventajas fiscales para amortización. Control total. El capital no queda atado. No se requiere financiación. El pago es menor que el alquiler. El capital no queda atado. No se requiere financiación. Facilidad de cambio de sistema. Suele incluir el mantenimiento y seguros. El coste inicial es elevado. Riesgo de obsolescencia. Riesgo de atarse a una elección errónea. Plena responsabilidad. La compañía no es dueña del sistema cuando expira el contrato de alquiler. Por lo general hay penalización alta por cancelar anticipadamente el contrato. La empresa no es dueña del equipo. Los costos son muy altos por asumir el proveedor el riesgo (es la alternativa más cara). Evaluación del vendedor 1. Soporte del equipo i. Linea completa de productos ii. Productos de calidad iii. Garantía 2. Soporte del software i. Todas las necesidades del software ii. Programación personalizada iii. Garantía 15 16

5 2.1.3 Selección de Hardware Otros criterios de selección La selección de hardware no es tan sencilla como comparar costes y elegir la opción menos costosa. Hay otras eventualidades que la empresa debe considerar como podrían ser las siguientes: La posibilidad de expandir el sistema si las necesidades aumentan en el futuro. La posibilidad de conectar el equipo con otras marcas si el sistema llegara a crecer. El ahorro a futuro que pueda suponer comprar un sistema con capacidad de expansión Selección de Software Podemos identificar tres posibilidades: Desarrollo propio de todo el software. Contratación a empresas de servicios el desarrollo del software necesario. Compra de paquetes de software. En muchos casos se da una mezcla de las tres posibilidades (realmente en casi todos). La estabilidad corporativa del vendedor Selección de Software Desarrollo propio: las ventajas son: Posibilidad por parte de la empresa de desarrollar un producto a la medida de sus necesidades. Mantenimiento de la reserva con respecto a los datos y modos de funcionamiento (Know-How). Esto es fundamental en situaciones en que los servicios informáticos son el fundamento de cómo decide competir la empresa. No depender de nadie. Se evitan daños ante la diversa fortuna en los negocios suministradores externos. Facilidad de adaptación del software creado a las necesidades cambiantes del negocio, sin coordinarse con otras empresas para conseguirlo (caso de software común) Selección de Software Contratación y compra: las ventajas son: Posibilidad de acceso a tecnología puntera y personal especializado que, o bien no puede retenerse, o bien no se necesita en la medida de lo suficiente como para tenerlo disponible continuamente. Coste. La posibilidad de distribuir una parte del desarrollo entre un número de empresas permite mantener los gastos a un nivel aceptable, fundamentalmente para aplicaciones estándar. Utilización del personal. Se pueden emplear los recursos propios en aplicaciones específicas o confidenciales de la compañía o aplicarlo a otras actividades del negocio. Estar abierto a un mercado con gran variedad de servicios de información. 20

6 2.1.4 Selección de Software Selección de Software Caso especial: OUTSOURCING (subcontratación). Una de las tareas más difíciles una vez que se conocen los requerimientos, es el determinar si un cierto paquete de software cumple con ellos. Para resolver este problema podemos apoyarnos en el conocimiento de los propios proveedores, pudiendo solicitar la prueba del mismo durante un período determinado y significativo para nosotros. Véase: trial versión, proveedores comunes entre comp.(lista clientes) 21 Últimamente hay un gran aumento de la confianza de las empresas en contratar a fuentes externas los desarrollos software como alternativa al desarrollo propio (outsourcing, subcontratación). Véase: características de estos casos (Inet, contab,..) Esta opción viene originada como respuesta a la pregunta : Existe alguna forma por la que podamos conseguir a bajo precio el software y los sistemas que necesitamos?. Una de las razones de decantarse por esta opción (y posiblemente la principal) podría ser la ventaja y necesidad de las empresas en concentrarse únicamente en las actividades de su propio negocio Selección de Software Selección de Software Caso especial: OUTSOURCING (subcontratación). Caso especial: OUTSOURCING (subcontratación). Otras razones pueden ser: El aumento de costes de desarrollo de grandes sistemas. La disponibilidad de bases de datos industriales privadas. Aumento asombroso en el número de aplicaciones posibles. Estas afirmaciones anteriores inciden más en el punto de vista teórico que práctico, ya que la decisión de elegir outsourcing es a menudo financiera. 23 Desde el punto de vista financiero, los ahorros de coste se pueden lograr reduciendo el número de personas y las instalaciones que los apoyan. En el lado negativo, una compañía pierde control sobre el software que necesita; y esto aumenta el riesgo de poner su destino en manos de un tercero. La decisión de contratar fuentes externas puede ser estratégica o táctica. A nivel estratégico, los gestores tienen en consideración si una parte importante de todo el trabajo del software lo pueden realizar otros (por diferentes motivos). En el nivel táctico, un jefe de proyecto determina las partes o el todo que sea aconsejable subcontratarse. 24

7 2.1.4 Selección de Software Caso especial: OUTSOURCING (subcontratación). Desde el punto de vista financiero, los ahorros de coste se pueden lograr reduciendo el número de personas y las instalaciones que los apoyan. En el lado negativo, una compañía pierde control sobre el software que necesita; y esto aumenta el riesgo de poner su destino en manos de un tercero. La decisión de contratar fuentes externas puede ser estratégica o táctica. A nivel estratégico, los gestores tienen en consideración si una parte importante de todo el trabajo del software lo pueden realizar otros (por diferentes motivos). En el nivel táctico, un jefe de proyecto determina las partes o el todo que sea aconsejable subcontratarse. 25 La necesidad de contar con personal para el desarrollo de software altamente preparado y motivado se discute desde los años 60. Es un aspecto de tanta importancia que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP con el objetivo de aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software. 26 Este modelo define las siguientes áreas prácticas clave para el personal que desarrolla software: Reclutamiento Selección Gestión de rendimiento Entrenamiento Retribución Desarrollo de la carrera Diseño de la organización y del trabajo Desarrollo cultural y de espíritu de equipo A la hora de planificar un proyecto, dentro del apartado de estimación de recursos, el personal se configura como el primario y más importante. Cuando se gestiona la planificación se comienza elevando el ámbito y seleccionando las habilidades técnicas que se requieren para llevar a cabo el desarrollo. Hay que especificar la posición dentro de la organización (IS, junior, progr,..) y la especialidad (telecomunicaciones, BD,..). Para proyectos pequeños una sola persona puede llevar a cabo todos los pasos de ingeniería del software, consultando con especialistas. El número de personas que se requieren para un proyecto de software sólo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo

8 a) Participantes en un proyecto de software Gestores superiores: definen aspectos de negocios que a menudo tienen una significativa influencia en el proyecto. Gestores (técnicos) del proyecto: planifican, motivan, organizan y controlan a los profesionales que realizan el trabajo de software. Profesionales: proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación. Clientes: especifican los requisitos para los desarrollos. b) Jefe del equipo La gestión de un proyecto es una actividad intensamente humana, y por esta razón, los componentes profesionales del software, a menudo no son buenos jefes de equipo. Qué es lo que buscamos cuando seleccionamos a alguien para dirigir un proyecto de software? Una respuesta posible puede ser el modelo MOI sugerido por Jerry Weinberg: Usuarios finales: interaccionan con el software desarrollado. Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Ése es el trabajo del jefe del equipo Motivación: la habilidad para motivar (con un tira y afloja ) al personal técnico para que produzca conforme a sus mejores capacidades. Organización: la habilidad para moldear procesos existentes que permita la transformación de un concepto inicial en proyecto final. Ideas o innovación: la habilidad para motivar al personal para crear y sentirse creativos incluso cuando deban de trabajar dentro de los límites establecidos para un producto o aplicación de software particular. El ÉXITO DE LOS GESTORES de proyecto se basa en aplicar un estilo de gestión en la resolución de problemas, es decir, concentrarse en entender el problema que hay que resolver. Otro punto de vista de las características que definen un gestor de proyecto eficiente resalta cuatro apartados clave: Resolución del problema. Estructurar soluciones de manera sistemática o motivar a otros profesionales a que las consigan. Dotes de Gestión. Tener la suficiente confianza para asumir el control cuando sea necesario y la garantía de que los técnicos le sigan. Incentivo de los logros. Debe recompensar la iniciativa y los logros, y demostrar a través de sus acciones que no se penalizará si se corren riesgos controlados. Influencia y construcción de espíritu de equipo. Debe ser capaz de leer a la gente, capaz de entender mensajes verbales y no verbales y reaccionar ante las necesidades de las personas que mandan esas señales. El gestor debe mantener el control en situaciones de gran estrés

9 a) Equipo de software Existen tantas estructuras de organización de personal para desarrollo como organizaciones que se dedican a ello. Para bien o para mal, el organigrama no puede cambiarse fácilmente. Las consecuencias prácticas y políticas de un cambio de organización no están dentro del alcance de las responsabilidades del gestor de un proyecto, sin embargo sí la organización del personal directamente involucrado en un nuevo proyecto de software. La mejor estructura de equipo depende de: Estilo de gestión de la organización Número de personas que compondrá el equipo Sus niveles de preparación Dificultad del problema Mantei sugiere tres organigramas de equipo genéricos: Descentralizado democrático (DD). No tiene un jefe permanente. Se nombran coordinadores de tareas a corto plazo y se sustituyen para diferentes tareas. Las decisiones sobre problemas se hacen por consenso del grupo. Descentralizado controlado (DC). Tiene un jefe definido que coordina tareas específicas y jefes secundarios que tienen responsabilidades sobre subtareas. La resolución de problemas es una actividad de grupo pero la implementación se reparte entre subgrupos por el jefe del equipo. Centralizado controlado (CC). El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo Otros conceptos y factores sobre Organización de equipos Reglas básicas que no deben olvidarse en la descomposición del equipo de proyecto: Factores que deben aplicarse en materia de elección: Cada entidad o equipo debe ser lo suficientemente pequeño para ser manejable y controlable. Se recomienda no dirigir a más de 7 u 8 personas en línea directa. Cada entidad o equipo tendrá que efectuar las tareas que conduzcan a un nivel de interacción con los otros equipos. Tipo de actividad Estilo de gestión del jefe del proyecto Especialidad de las personas Afectividad de las personas (origen de muchos fracasos) Etapa del ciclo de vida de un proyecto Estatutos del personal Cada entidad o equipo debe realizar las tareas que constituyan una gran cohesión y/o que se correspondan con una sola función. La experiencia dice que todo tipo de gestión de empresa que no esté fundado en la motivación y en la competencia de personas está condenado al fracaso

10 2.2.1 Visión general Perturbaciones en equipos de desarrollo Más frecuentes o preocupantes son: Absentismo (en cualquiera de sus formas). Aplazamientos relacionados con el material. Subestimación de tiempos asignados a actividades (a menudo fruto de mala estimación de las competencias de los recursos implicados en su realización). Mala coordinación entre responsables, que dará lugar a retrasos. Para llevar a cabo o desarrollar una gestión de la configuración de software es preciso definir previamente cada uno de sus términos: a) qué entendemos por Gestión? Se puede definir como la disciplina administrativa utilizada para identificar y documentar las características funcionales y físicas de cada elemento de la configuración software. Además, se deben: Controlar los cambios de esas características Registrar y listar el estado del proceso del cambio e implementación Verificar y validar las características del software Y lo adecuada y completa que es la documentación Visión general Visión general b) qué entendemos por configuración? Conjunto de items o elementos entregados que resultan de las tareas llevadas a cabo durante el desarrollo por fases de un sistema. Observación: configuración implica orden, método, organización, documentación La configuración incluye: Programas del sistema operativo como respuesta a un programa de aplicación BD almacenados de forma que puedan ser procesados y operados por computador Especificación de sistemas y subsistemas que definen requerimientos Documentación de software básico Programas de ordenador que están sujetos a cambios Códigos fuente de programas (véase propiedad del código en I+D) Software de soporte para desarrollo, mantenimiento y modificación. (véase decompilers) Software de prueba utilizado en programas Herramientas de gestión de librerías de software 39 c) a qué nos referimos con el término software? El software incluye: programas procedimientos rutinas todos los documentos asociados con el análisis, diseño, programación y conversión de un sistema asociado con un computador. 40

11 2.2.1 Visión general Por lo tanto, ya estamos en posición de emitir las siguientes definiciones: > Gestión de la Configuración Software: proceso de llevar a cabo el control y seguimiento administrativo del conjunto de la plataforma hardware, software y toda la documentación asociada. Para llevarla a cabo, es necesario seguir una metodología: > Metodología de la Gestión de la Configuración Software: es la disciplina que lleva a cabo o aplica control técnico y administrativo a un proyecto software en desarrollo. >La puesta en funcionamiento de esta metodología (software configuration management, SCM) debe estar integrada con una: Metodología de desarrollo de sistemas y una Metodología de gestión de proyectos (i+d Rem, gantt, c++) Visión general Metodología de desarrollo de sistemas (SDM) Divide el proceso de desarrollo de un sistema en una serie de fases que se pueden gestionar. Esta serie de fases están definidas por una serie de tareas o pasos. Cada una de estas tareas o grupos de tareas resultan en uno o más items definibles que son entregados al fichero de proyecto. SDM = fases tareas items líneas base Aunque el modelo SDM puede diferir (y claro que difiere) entre empresas, la mayor parte de las metodologías se compone de cinco funciones superiores: Definir especificaciones funcionales Asignar las especificaciones funcionales a los subsistemas Preparar las especificaciones de diseño Programar el diseño Mantener el sistema Visión general Metodología de gestión de proyectos Establece el marco para gestionar cambios en la configuración software. Descompone el ciclo del desarrollo de un proyecto en cinco funciones básicas: Planificación Control de Proyecto Evaluación Control de cambios Gestión del fichero del proyecto cinco funciones básicas: Planificación Control de Proyecto Evaluación Control de cambios Gestión del fichero del proyecto Dentro de cada área funcional existen una serie de tareas que deben ser documentadas adecuadamente

12 a) Planificación Debe definir lo siguiente: La estructura del trabajo Requerimientos de documentación Estándares para desarrollo del proyecto Puntos para gestión del proyecto y control El resultado final del proceso de planificación es el desarrollo de un plan de proyecto que describirá la forma en la que el director del proyecto conducirá el desarrollo del mismo. Este plan de proyecto contendrá: Documentos que identifican puntos de control Definición de las tareas a entregar Especificaciones de quién revisa el proyecto, cuando y con qué propósito Items que identifiquen personas y departamentos asociados con el proyecto La planificación es un proceso continuo e interactivo a lo largo de la vida del proyecto. La metodología de control de proyectos sugiere tipos específicos de revisión a lo largo de esta vida. Cada punto de revisión debe ser un mecanismo de detección para el director del proyecto que le ayude a identificar desviaciones en el plan b) control del proyecto Esta función de la metodología de gestión de proyectos se encarga de ayudar a los directores de proyecto en: definir procedimientos para iniciar un proyecto seguimiento y comunicación revisión del progreso del proyecto Es una especie de control continuo de lo planificado frente a las características actuales. Para que sea efectivo, al menos se deben cumplir tres condiciones: Procedimientos: establecen protocolos para revisar y aprobar el plan del proyecto y obtener conformidad de costes y fechas. Distinguimos, por ejemplo: Procedimientos para seguimiento y comunicación: explican las funciones de comunicaciones de trabajo hecho, de uso de computador e incidencias. Procedimientos de comunicación de progreso: utilizan PERT, diagramas de Gantt y gráficos, como los medios para plasmarlo. debe existir un plan de proyecto el equipo debe conocer a que nivel está trabajando con relación al plan sus miembros deben conocer y comprender en todo momento los objetivos del proyecto y el trabajo que suponga cada fase de desarrollo. (muy importante, ocultismo) 47 48

13 c) evaluación Se encarga de ayudar a los directores de proyecto a definir procedimientos para evaluar tanto el producto como el proyecto. Provee de una serie de guías para llevar a cabo los análisis de: Funciones del análisis del riesgo Riesgo de duración; analiza el impacto de retrasos en la fecha de terminación. coste/beneficio y riesgo Riesgo de producto: evalúa el riesgo de obtener un producto deficiente. Análisis de coste: estudios para tratar de obtener un coste mínimo. Análisis de beneficio: evalúa beneficios tangibles e intangibles y cuantifica objetivos. Riego de proyecto: evalúa la capacidad total del departamento para obtener los resultados dentro de presupuesto y tiempo. Estos estudios se llevan a cabo apoyándose en las teorías de decisiones (economía de la empresa). Una vez concluidos estos estudios, se deben relacionar los dos factores para obtener el coste final del proyecto. Análisis de riesgo: lleva a cabo tres funciones diferentes: d) Control de cambios Establece procedimientos para dos categorías de cambios: Cambios de producto Cambios de proyecto Procedimientos para control de cambios de producto: deben estar coordinados con aquellos elementos del plan de gestión de configuración que definen los requerimientos de: Identificación de la configuración Control Auditoría Y deben establecer los métodos para controlar cambios en código fuente, módulos, procedimientos y datos de prueba, documentación, parámetros,... Procedimientos para control de cambios de proyecto: deben estar coordinados con aquellos elementos del plan, que definen las responsabilidades de cada unidad de la empresa que está involucrada en el proyecto. Sin controles adecuados, el impacto de los cambios puede crear serios problemas y costes crecientes. Algunas de estas consecuencias son las siguientes: Cambios que no son identificables Cambios que son muy difíciles de eliminar Cambios mal documentados Cambios hechos a versiones erróneas Cambios no autorizados que pueden crear pérdidas de la empresa Conflictos durante la conversión, implementación o durante pruebas en paralelo Pérdida completa del control del proyecto (como consecuencia de lo anterior) 51 52

14 El primer paso en el proceso de gestión de cambios es definir procedimientos para controlar la forma en que estos cambios se introducen y procesan. Estos procedimientos deben ser publicados por cada uno de los siguientes elementos que comprenden el proceso de gestión de cambios: Inicio del cambio Aprobación técnica Aprobación administrativa Aprobación de gestión Seguimiento de prueba Seguimiento de instalación e) Gestión del fichero del proyecto Esta función de la metodología de gestión de proyectos debe combinar las funciones de una librería de referencia técnica, una librería de documentación de sistemas y una librería de mantenimiento de programas. Debe proveer guías para definir funciones relativas a: adquisición, catalogación, organización, circulación y disposición Gestión de la configuración software Gestión de la configuración software cambios = inevitables aumentan grado de confusión entre ingenieros, fruto de no analizarlos antes de realizarlos misión de la GC: coordinar el desarrollo de software para minimizar la confusión la GCS es una actividad de autoprotección que se aplica a lo largo de todo el proceso de IS y gestiona el cambio el cambio se puede producir en cualquier momento, y las actividades de GCS nos sirven para: identificar el cambio controlar el cambio garantizar que se implementa adecuadamente informar del cambio 55 56

15 2.2.3 Gestión de la configuración software Gestión de la configuración software fuentes fundamentales de los cambios: fallos nuevos negocios o condiciones comerciales > dictan cambios en los requisitos nuevas necesidades del cliente reducciones presupuestarias o de planificación resumen: todos pueden ser necesarios y estar justificados!! mantenimiento software # GCS mantenimiento: conjunto de actividades de IS que se producen después de que el SW se ha entregado al cliente y está operativo GCS: conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo de SW y termina sólo cuando el SW queda fuera de circulación Gestión de la configuración software Gestión de la configuración software categorías de la información en el proceso de IS (a grandes rasgos): programas (fuentes + ejecutables) documentos de programas (técnicos y formales) datos (contenidos en el programa o externos) una configuración es una colección de estos elementos en un momento determinado ECS y líneas base ECS: elementos que componen toda la información producida por parte del proceso de IS. A medida que progresa el proceso de IS crece rápidamente el número de ECS LÍNEA BASE: concepto de GCS que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados IEEE: especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios ver gráfico de líneas base más comunes 59 60

16 2.2.3 Gestión de la configuración software Gestión de la configuración software Concepto de configuración Un sistema software comprende distintos componentes, que evolucionan individualmente (ECS) Hay que garantizar la consistencia del conjunto del sistema Una configuración es una combinación de versiones particulares de los componentes que forman un sistema consistente Desde el punto de vista de evolución, es el conjunto de las versiones de los objetos componentes en un instante dado 61 Línea base línea base es una configuración operativa del sistema software La evolución del sistema puede verse como evolución de la línea base así: Un cambio es el paso de una versión de la línea base a la siguiente Puede incluir modificaciones del contenido de algún componente, y/o modificaciones de la estructura del sistema, añadiendo o eliminando componentes Proceso de GCS e identificación de objetos Proceso de GCS e identificación de objetos la GCS usa líneas base, que están formadas por un conjunto de ECS Responsabilidad principal de GCS: control de cambios más: Identificación de los ECS individuales Distintas versiones del software (cómo y quién) Generación de informes sobre cambios (mecanismo) Auditorias de la configuración (garantizan la corrección) Por lo tanto, las cinco tareas de GCS son: Identificación Control de Versiones Control de Cambios Auditoria de la Configuración Generación de Informes cómo se realiza el proceso de GCS? ver figura

17 2.2.4 Proceso de GCS e identificación de objetos Proceso de GCS e identificación de objetos La identificación debe ser de forma única y la organización debe ser mediante un enfoque orientado a objetos. Los objetos pueden ser: listados fuente,...) Básicos: unidades de texto (sección de especif. Req., Compuestos: colección de objetos básicos y otros compuestos. (Especif. Diseño). Todo OBJETO tiene: Nombre (sin ambiguedades) Descripción: tipo de ECS (datos,proc,prog), id. Versión e información. Lista de recursos: entidades que proporciona, procesa, referencia o son requeridas por el objeto. Realización: referencia a la unidad de texto (obj. Básicos) y nulo para objetos compuestos Proceso de GCS e identificación de objetos Proceso de GCS e identificación de objetos Relaciones que se producen entre objetos Un objeto puede estar identificado como <parte-de> un objeto compuesto, dando lugar a una jerarquía de objetos. Diagrama de E/R 1.4 <parte-de> modelo de datos; Modelo de datos <parte-de> especificación de diseño; También se producen relaciones entre las ramas del árbol: Modelo de datos <interrelacionado> modelo de flujo de datos; (OC) Modelo de datos <interrelacionado> casos de prueba de uso; (OS) Estas relaciones se pueden representar con un LIM (lenguaje de interconexión de modelos), que describe las interdependencias entre objetos de la configuración y permite construir automáticamente cualquier versión de un sistema. Grafos de evolución: representan la evolución de los objetos y describen la historia de cambios de un objeto. cuántos clientes tengo de la versión 2.1?, cómo nos aseguramos que los cambios de la 1.3 están reflejados en el diseño?,

18 2.2.5 Control de versiones Control de versiones Combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creadas durante el proceso de IS. Se realiza asociando atributos a cada versión del software y permitiendo luego especificar una configuración describiendo el conjunto de atributos deseado (nº de versión asociados a objetos o cadena de variables lógicas que especifican cambios funcionales aplicados al sistema) Cada versión puede tener variantes. SW con componentes 1,2,3,4 y 5 4 sólo para monitores color y 5 sólo para monocromo Variantes de la versión: a) 1,2,3,4 b) 1,2,3,5 Variantes: colección diferente de objetos del mismo nivel de revisión y que coexiste en paralelo con otras variantes. Representan configuraciones alternativas y evolucionan por separado. Representan también una variación espacial, mientras que las revisiones representan una variación temporal. Nueva versión: cuando se realizan cambios significativos en uno o más objetos Control de versiones Almacenamiento de versiones (REPOSITORIO) Centraliza el almacenamiento de los componentes de un mismo sistema, incluyendo las distintas versiones de cada componente El repositorio permite ahorrar espacio de almacenamiento, evitando guardar por duplicado elementos comunes a varias versiones o configuraciones El repositorio facilita el almacenar información de la evolución del sistema (historia), y no sólo de los componentes en sí No confundir el término 'repositorio' con el de 'línea base' Control de cambios Procedimientos y herramientas automáticas para proporcionar un mecanismo para el control del cambio. cómo es el Proceso de Control de Cambios? > ver gráfico Los procesos de ALTA y BAJA implementan dos elementos importantes del control de cambios: control de acceso y control de sincronización Control de acceso: gobiernan los derechos de los IS a acceder y modificar objetos de CS Control de sincronización: asegura que los cambios en paralelo, realizados por personas diferentes, no se sobreescriben mutuamente. Lógica de funcionamiento > ver gráfico 72

19 2.2.6 Control de cambios Mucha burocracia, por lo que: Antes de que un ECS se convierta en línea base sólo es necesario aplicar un control de cambios informal >> una vez aprobada pasa a línea base >> aparece el control de cambios a nivel de proyecto >> para hacer un cambio lo debe aprobar el gestor, o la ACC si impacta en otros ECS >> cuando se distribuye el software a los clientes se instituye el control de cambios formal (ver gráfico) ACC (Autoridad de Control de Cambios): una o varias personas que deben tener una visión clara y evaluar el impacto fuera del ECS en cuestión Control de cambios AUDITORÍA DE LA CONFIGURACIÓN La auditoria pretende, junto con las RTF, asegurar que el cambio se va implementando correctamente. Complementa la RTF al comprobar características que no se tienen en cuenta en ésta última. Se lleva a cabo independientemente por el grupo de garantía de calidad, y debe responder a cuestiones como: se ha hecho el cambio especificado en la OCI? Se ha hecho un RTF? se han seguido los estándares de IS? se han recalcado los cambios en el ECS? se han seguido procedimientos de GCS para señalar, registrar y divulgar el cambio? se han actualizado adecuadamente todos los ECS relacionados? Control de cambios INFORMES DE ESTADO La generación de informes de estado de la configuración o contabilidad de estado, debe responder a: qué pasó? quién lo hizo? cuándo pasó? qué más se vio afectado? Ocupan un papel vital cuando hay mucha gente involucrada, sobre todo porque facilitan mucho la comunicación. 75