analisis de diseÑo de informacion software … · configuración de software identificación,...

ANALISIS DE DISEÑO DE INFORMACION LINDA YASMIN OVALLES LOPEZ

ANALISIS DE DISEÑO DE INFORMACION

SOFTWARE CONFIGURATION MANAGEMENT

LINDA YASMIN OVALES LOPEZ

1090488060

OLVANI

UNIVERSIDAD DE PAMPLONA

FACULTAD DE CIENCIAS ECONOMICAS Y EMPRESARIALES

2016


CAPÍTULO 6

SOFTWARE CONFIGURATION MANAGEMENT

CCB Gestión de la Configuración de Software

CM Gestión de la configuración

FCA Auditoría de Configuración Funcional

PCA Auditoría de Configuración física

SCCB Control de Configuración de Software Tablero

SCI Software Elemento de Configuración

SCM Configuración del software administración

SCMP Configuración del software Plan de gestión

SCR Solicitud de cambio de software

SCSA Estado de la configuración de software Contabilidad

SDD Documento de Diseño de Software

SEI/CMMI Instituto de Ingeniería de Software de Modelo de Capacidad de Madurez Integración

SQA Calidad de Software

SRS Requisito de software Especificación

INTRODUCCIÓN

Un sistema puede ser definido como la combinación de elementos que interactúan organizados para lograr uno o propósitos declarados más. La configuración de un sistema es las características funcionales y físicas de hardware o software como se establece en técnica documentación o se alcance en un producto; eso También puede ser pensado como una colección de concreto versiones de los elementos de hardware, firmware o software combinado de acuerdo con los procedimientos de construcción específicos para servir a un propósito particular. gestión de la configuración (CM), entonces, es la disciplina de identificar la configuración de un sistema en puntos distintos a tiempo para el propósito de controlar sistemáticamente cambios en la configuración y el mantenimiento de la integridad y la trazabilidad de la configuración durante todo el ciclo de vida del sistema. Es formalmente definido como: Una disciplina aplicación técnica y administrativa dirección y vigilancia para: identificar y documentar el funcional y física características de un elemento de configuración, controlar los cambios en esas características, registro y el cambio procesamiento y reporte situación de la aplicación y el cumplimiento de verificar con los requisitos especificados.


Gestión de configuración de software (SCM) es un proceso de ciclo de vida del software de apoyo que beneficios de gestión de proyectos, desarrollo y las actividades de mantenimiento, actividades de aseguramiento de la calidad, así como los clientes y usuarios de final producto. Los conceptos de gestión de la configuración aplicar a todos los elementos a controlar, aunque hay algunas diferencias en la aplicación entre las CM hardware y software CM. SMC está estrechamente relacionado con la calidad del software aseguramiento de la actividad (SQA). Tal como se define en el Software área de conocimiento de la Calidad (KA), SQA procesos garantizan que el software productos y procesos en el ciclo de vida del proyecto ajustarse a sus requisitos especificados por la planificación, promulgación, y la realización de un conjunto de actividades para proporcionar la debida seguridad de que la calidad es siendo incorporado en el software. actividades de la SCM ayudan en el cumplimiento de estos objetivos SQA. En algún proyecto contextos, los requisitos específicos prescriben SQA ciertas actividades de la SCM


Las actividades de la SCM son la gestión y planificación del proceso de SMC, configuración de software identificación, control de configuración de software, Determinación del estado de configuración de software, software auditoría de configuración, y la versión de software gestión y prestación. El software de configuración KA Gestión se relaciona con todos los otros KA, ya que el objeto de gestión de la configuración es el artefacto producido y se utiliza en toda la ingeniería de software proceso.

DISTRIBUCIÓN DE TEMAS PARA CONFIGURACIÓN DEL SOFTWARE ADMINISTRACIÓN El desglose de los temas para la Configuración de Software Gestión de KA se muestra en la Figura

1. Gestión del Proceso de SMC

SMC controla la evolución y la integridad de un producto mediante la

identificación de sus elementos; la gestión y el control del cambio; y

verificación, registro e informar sobre la información de configuración. Desde la

perspectiva del ingeniero de software, SCM facilita desarrollo y aplicación de

los cambios actividades. Una implementación exitosa requiere SMC

planificación y gestión cuidadosa. Esto a su vez, requiere una comprensión de

la organización contexto para, y las limitaciones impuestas a la diseño e

implementación del proceso de SMC.

1.1 Contexto de organización de SMC

Para planificar un proceso de SMC para un proyecto, es necesario para

entender el contexto de la organización y las relaciones entre los elementos de

la organización. SMC interactúa con otras actividades o elementos de la

organización.

Los elementos de la organización responsable de los procesos de apoyo de

ingeniería de software pueden ser estructurado de varias maneras. Aunque la

responsabilidad para llevar a cabo ciertas tareas podría ser SCM asignados a

otras partes de la organización (por ejemplo, la organización de desarrollo), la

responsabilidad general para SMC menudo recae en una organización distinta

elemento o persona designada.

El software se desarrolla con frecuencia como parte de un sistema más grande

que contiene hardware y firmware elementos. En este caso, las actividades

tienen lugar SCM en paralelo con las actividades de CM de hardware y

firmware y deben ser compatibles con el sistema de nivel CM.

Tenga en cuenta que firmware contiene hardware y software; Por lo tanto, tanto de hardware como de software CM conceptos son aplicables. SMC puede interconectar con una organización de Actividad de control de calidad sobre


cuestiones tales como gestión de documentos y elementos no conformes. Respecto al primero, algunos artículos debajo de SMC control también podría ser registros del proyecto sujeto a disposiciones de la garantía de calidad de la organización programa. La gestión de elementos no conformes es por lo general la responsabilidad de la garantía de calidad actividad; sin embargo, SCM podría ayudar con seguimiento e informar sobre los elementos de configuración de software caer en esta categoría. Tal vez la relación más estrecha es con el de desarrollo de software y mantenimiento organizaciones. Es dentro de este contexto que muchos de se llevan a cabo las tareas de control de la configuración del software. Con frecuencia, las mismas herramientas de apoyo al desarrollo, mantenimiento, y SCM propósitos

1.2. Limitaciones y orientación para el SMC Proceso Limitaciones que afectan, y orientación para el SMC proceso provienen de un número de fuentes. Políticas y procedimientos establecidos en la empresa u otra los niveles de organización pueden influir o prescribir el diseño e implementación del proceso de SMC para un proyecto determinado. Además, el contrato entre el comprador y el proveedor puede contener disposiciones que inciden en el proceso de SMC. Por ejemplo, ciertas auditorías de configuración podrían ser requiere, o puede especificar que ciertos artículos ser colocado bajo CM. Cuando los productos de software a ser desarrollados tienen el potencial de afectar pública la seguridad, los organismos reguladores externos pueden imponer restricciones. Por último, la vida de software en particular proceso del ciclo elegido para un proyecto de software y el nivel de formalismo seleccionado para implementar el software afecta al diseño e implementación del proceso SMC. Orientación para diseñar e implementar un proceso SMC también se puede obtener de "mejor practicar ", como se refleja en las normas sobre el software ingeniería promulgado por los diversos organismos de normalización (Véase el Apéndice B de las normas). 1.3. La planificación de SMC La planificación de un proceso de SMC para un determinado proyecto debe ser coherente con la organización contexto, las limitaciones aplicables, comúnmente orientación aceptada, y la naturaleza de la proyecto (por ejemplo, el tamaño, la criticidad de seguridad, y seguridad). Las principales actividades cubiertas son de software identificación de la configuración, configuración de software control, de estado de configuración de software contabilidad, software de configuración de auditoría, y gestión de versiones de software y entrega. En, Además, cuestiones como la organización y responsabilidades, los recursos y los horarios, la selección de herramientas y la aplicación, los proveedores y subcontratistas el control y la interfaz de control por lo general se consideran. Los resultados de la actividad de planificación son


registrados en un Plan de SCM (SCMP), que es típicamente sujeta a revisión y auditoría de SQA. Ramificación y las estrategias que se fusionen cuidadosamente planeado y comunicado, ya que impactar muchas actividades de la SCM. Desde un punto de vista SMC, una rama se define como un conjunto de fuente de evolución versiones de los archivos. La fusión consiste en la combinación de diferentes cambios en el mismo archivo. esto normalmente se produce cuando más de una persona cambia un elemento de configuración. Hay mucha ramificación y la fusión de las estrategias de uso común (véase la ulterior sección de lecturas para la discusión adicional). El modelo de ciclo de vida de desarrollo de software (Ver Software Modelos de Ciclo de Vida del Software Ingeniería de Procesos KA) también afecta SCM actividades y SMC planificación debe tomar este en cuenta. Por ejemplo, la integración continua Es una práctica común en muchas de desarrollo de software enfoques. Por lo general se caracteriza por ciclos de desarrollo-prueba-de desplegar frecuentes. actividades de la SCM debe planificarse en consecuencia.

1.3.1. Organización y Responsabilidades SMC

Para evitar la confusión sobre quién desarrollará dada actividad de SCM o tareas, la organización papeles para participar en el proceso de necesidad SMC sin riesgo de confusión. Las responsabilidades específicas para las actividades o tareas SMC, habida cuenta también necesitan ser asignado a las entidades de organización, ya sea por título o por el elemento de la organización. La autoridad general y canales de información para SMC también debe ser identificado, aunque esto podría lograrse en la gestión de proyectos o la garantía de calidad etapa de planificación.

1.3.2. Recursos SCM y horarios

La planificación de SMC identifica el personal y herramientas involucrados en la realización de actividades de la SCM y tareas. Se abordan cuestiones de planificación mediante el establecimiento de secuencias necesarias tareas de identificación y SCM sus relaciones con los programas de proyectos y los hitos establecidos en la gestión de proyectos etapa de planificación. Los requisitos de formación necesarios para la aplicación de los planes y la formación nuevos miembros del personal también se especifican. 1.3.3. Herramienta de selección e implementación

En cuanto a cualquier área de la ingeniería de software, la la selección y aplicación de las herramientas de SCM debe ser cuidadosamente planificada. Las siguientes preguntas debería ser considerado:


• Organización: lo que motiva la adquisición de herramientas desde un punto de vista organizativo? • Herramientas: podemos usar herramientas comerciales o desarrollarlas nosotros mismos? • Medio ambiente: ¿cuáles son las limitaciones impuesta por la organización y su técnico ¿contexto? • Herencia: cómo utilizarán los proyectos (o no) el nuevas herramientas? • Financiación: ¿quién va a pagar por las herramientas ' adquisición, mantenimiento, formación, y personalización? • Alcance: ¿cómo las nuevas herramientas que por ejemplo, a través de toda la organización o sólo en proyectos específicos? • Propiedad: ¿quién es el responsable de la introducción de nuevas herramientas? • Futuro: ¿cuál es el plan para el uso de las herramientas 'en ¿el futuro? • Cambio: su capacidad de adaptación son las herramientas? • Dividir y agrupar: son las capacidades de las herramientas ' compatible con la ramificación previsto y la fusión de las estrategias? • Integración: hacer las diversas herramientas de SCM se integran ¿entre ellos? Con otras herramientas en utilizar en la organización? • Migración: ¿puede el repositorio mantenido por la herramienta de control de versiones ser portado a otro herramienta de control de versiones, manteniendo completa historia de los elementos de configuración que contiene?

SMC por lo general requiere un conjunto de herramientas , como se en

oposición a una sola herramienta. Tales conjuntos de herramientas son a veces

referido como bancos de trabajo . En este contexto, otra consideración

importante en la planificación para la selección de la herramienta es determinar

si el SMC banco de trabajo estará abierto (en otras palabras , las herramientas

de diferentes proveedores será utilizado en diferentes actividades del proceso

SMC ) o integrado (Donde están diseñados elementos del banco de trabajo

trabajar juntos). El tamaño de la organización y el tipo de proyectos

involucrados también puede afectar a la selección de herramientas ( Véase el

tema 7 , Gestión de la Configuración de Software Herramientas).

1.3.4. Proveedor / subcontratista de Control


Un proyecto de software podría adquirir o hacer uso de productos de software

adquirido, tales como compiladores u otras herramientas . planificación SCM

considera si y cómo se tomarán estos elementos en Configuración control ( por

ejemplo, integrado en el proyecto bibliotecas ) y cómo serán los cambios o

actualizaciones evaluados y gestionados. Consideraciones similares se aplican

a subcontratado software. Al utilizar el software de subcontratación , tanto los

requisitos de SCM que se impongan a SMC proceso del subcontratista como

parte de la subcontrato y los medios de control del cumplimiento necesitar ser

establecida. Este último incluye consideración de lo que debe ser una

información SMC disponible para la vigilancia del cumplimiento efectivo.

1.3.5. control de interfaz Cuando un elemento de software de interfaz con otro elemento de software o hardware, un cambio ya sea artículo puede afectar a la otra. La planificación de ¿el proceso SMC considera cómo la interconexión Se identificarán los elementos y cómo los cambios en el los artículos serán manejados y comunicados. Los papel SCM puede ser parte de un sistema de nivel más grande proceso para la especificación y control de la interfaz; puede tratarse de especificaciones de la interfaz, la interfaz planes de control, y los documentos de control de interfaz. En este caso, la planificación de SCM control de la interfaz se lleva a cabo dentro del contexto del proceso. 1.4. plan de SMC Los resultados de la planificación SMC para un determinado proyecto se registran en una gestión de configuración de software Plan (SCMP), un "documento vivo", que sirve como una referencia para el proceso de SMC. Es mantenida (es decir, actualizada y aprobada) como necesario durante el ciclo de vida del software. En la implementación PGCS, normalmente es necesario desarrollar una serie de más detallada, subordinada procedimientos de definición de los requisitos específicos de cómo se llevará a cabo durante actividades- del día a día por ejemplo, que las estrategias de ramificación serán utilizado y con qué frecuencia se producen las composiciones y automatizado pruebas de todo tipo se ejecutan. Orientaciones sobre la creación y el mantenimiento de un SCMP, basado en la información producida por la actividad de planificación, está disponible en un número de fuentes, tales como. Esta referencia proporciona requisitos para la información que deben contener en un SCMP; también define y describe seis categorías de información SCM para ser incluido en una PGCS • Introducción ( objetivo, el alcance , los términos utilizados )

• Gestión de SMC (organización , las responsabilidades, las autoridades , las

políticas aplicables , directivas y procedimientos)


• Las actividades de SCM ( identificación de la configuración , control de la

configuración, etc. )

• Horarios de SCM ( coordinación con otros actividades del proyecto)

• Recursos SCM (herramientas , recursos físicos, y recursos humanos)

• Mantenimiento PGCS.

1.5. La vigilancia de la Configuración del Software administración

Después del proceso de SMC se ha implementado, un cierto grado de

vigilancia puede ser necesario para garantizar que las disposiciones de la

PGCS son lleva a cabo correctamente. No es probable que sean específicos

SQA requisitos para garantizar el cumplimiento con los procesos y

procedimientos especificados SCM. La persona responsable de SMC asegura

que los que tienen la responsabilidad asignada realizar SCM las tareas

definidas correctamente. El software la autoridad de control de calidad, como

parte de un cumplimiento actividad de auditoría, también puede realizar esta

vigilancia.

El uso de herramientas de SCM integrados a los procesos capacidad de control

puede hacer que la vigilancia tarea más fácil. Algunas herramientas facilitan la

conformidad del proceso mientras que proporciona flexibilidad para el software

ingeniería para adaptar los procedimientos. Otras herramientas cumplir

proceso, dejando el ingeniero de software con menos flexibilidad. requisitos de

vigilancia y el nivel de flexibilidad que debe proporcionarse a la ingeniero de

software son consideraciones importantes en la selección de herramientas.

1.5.1. Medidas de SCM y Medición

Medidas SCM pueden ser diseñados para proporcionar específica información sobre el producto en evolución o para proporcionar información sobre el funcionamiento del SCM proceso. Uno de los objetivos relacionados con la vigilancia de la SMC proceso es descubrir oportunidades para el proceso de mejora. Las mediciones de los procesos SCM proporcionar un buen medio para el seguimiento de la eficacia de las actividades de SCM de manera continua . Estas mediciones son útiles en la caracterización el estado actual del proceso , así como en proporcionando una base para hacer comparaciones en él hora. El análisis de las mediciones puede producir ideas que conduce a cambios en el proceso y que corresponde cambios a la SCMP . Bibliotecas de software y los diversos herramienta de SMC capacidades proporcionan fuentes para extraer información sobre las características de la SMC proceso ( así como proporcionar y gestión de proyectos información). Por ejemplo , la información sobre el tiempo requerido para llevar a cabo diversos tipos de cambios serían útiles en una evaluación de los criterios para


determinar qué niveles de autoridad son óptimas para la autorización de ciertos tipos de los cambios y para estimar los cambios futuros . Se debe tener cuidado de mantener la atención de la vigilancia de los puntos de vista que se puede ganar de las mediciones , no en las mediciones sí mismos. La discusión de los procesos de software y medida del producto se presenta en el Software Ingeniería de Procesos KA . la medición del software programas se describen en el Software Ingeniería KA Gestión . 1.5.2. En - Proceso de Auditorías de SMC Las auditorías pueden ser llevadas a cabo durante el software proceso de ingeniería para investigar el estado actual elementos de específicos de la configuración o de evaluar la aplicación del proceso de SMC. En proceso de auditoría de SMC proporciona una más formal mecanismo para aspectos de seguimiento seleccionado del proceso y se pueden coordinar con el función SQA ( véase el tema 5, Configuración de Software Revisión de cuentas ) 2.. Identificación Configuración del software Software identifica la configuración de identificación elementos para ser controlados, establece la identificación esquemas de los elementos y sus versiones, y establece las herramientas y técnicas que se utilizan en adquisición y gestión de artículos controlados. Estas actividades proporcionan la base para el otro SCM ocupaciones. 2.1. Los productos que identificar que hay que controlar Uno de los primeros pasos en el cambio de control es la identificación de los elementos de software que se desea controlar. Esto implica la comprensión de la configuración de software en el contexto de la configuración del sistema, la selección de los elementos de configuración de software, desarrollo de una estrategia para los elementos de software de etiquetado y la descripción de sus relaciones, y la identificación de tanto las líneas de base a utilizar y el procedimiento de para la adquisición de una línea de base de los artículos. 2.1.1. Configuración del software configuración de software es el funcional y física características de hardware o software como conjunto indica en la documentación técnica o se alcance en un producto. Puede ser visto como parte de un conjunto configuración del sistema. 2.1.2. Software Elemento de Configuración Un elemento de configuración (CI) es una partida o grupo de hardware o software o ambos que es diseñado para ser manejado como una sola entidad. Un software elemento de configuración (SCI) es una entidad de software que se ha establecido como un elemento de configuración. El SMC normalmente controla una variedad de artículos Además del propio código. con los


elementos de software potencial para convertirse en SCIs incluyen planos, especificaciones y la documentación de diseño, ensayos de materiales, herramientas de software, la fuente y el código ejecutable, librerías de código, datos y diccionarios de datos, y documentación para la instalación, mantenimiento, operaciones, y el uso de software. La selección de los SCIs es un proceso importante en el que debe alcanzarse un equilibrio entre el suministro visibilidad adecuada para los propósitos de control de proyectos y proporcionar un número manejable de artículos controlados. 2.1.3. Software Elemento de Configuración relaciones Las relaciones estructurales entre los seleccionados SCIs, y sus partes constituyentes, afectar a otra actividades o tareas SCM, como el software construir o analizar el impacto de la propuesta cambios. el seguimiento adecuado de estas relaciones También es importante para apoyar la trazabilidad. El diseño del esquema de identificación de los SCIs debe considerar la necesidad de asignar elementos identificados a la estructura de software , así como la necesidad de apoyar la evolución de los elementos de software y sus relaciones.

Imagen 6.2

2.1.4. Versión del software


los elementos de software evolucionan a medida que avanza un proyecto de software. Una versión de un elemento de software es una identificó instancia de un elemento. Se puede considerar como una estado de un elemento en evolución. Una variante es una versión de un programa resultante de la aplicación de software diversidad. 2.1.5. Base Una línea de base del software es una versión aprobada formalmente de un elemento de configuración (con independencia de los medios de comunicación) que está designado formalmente y se fija a una específica tiempo durante el ciclo de vida del elemento de configuración. El término también se utiliza para referirse a una versión particular de un elemento de configuración de software que tiene han acordado. En cualquier caso, la línea de base puede sólo se puede cambiar a través del control de cambios formal procedimientos. Una línea de base, junto con todos cambios en la línea de base aprobados, representa la configuración actual aprobado. líneas de base utilizados comúnmente incluyen funcional, asignado, de desarrollo, y el producto líneas de base. Los corresponde basales funcionales a los requisitos del sistema revisados. la asignado la línea de base corresponde a la revisado especificación de requisitos de software y el software especificación de requisitos de la interfaz. Los la línea de base del desarrollo representa la evolución configuración de software a la hora seleccionada durante el ciclo de vida del software. Cambio de autoridad esta línea de base normalmente recae principalmente en el organización de desarrollo, pero puede ser compartido con otra organizaciones (por ejemplo, SMC o Prueba). La línea de base producto corresponde a la producto de software para el sistema completado entregado integración. Las líneas de base que se utilizan para una dado proyecto, junto con los niveles asociados de autoridad necesaria para aprobar el cambio, son típicamente identificado en el SCMP. 2.1.6. La adquisición de elementos de configuración de software los elementos de configuración de software se colocan debajo control de SMC en diferentes momentos; es decir, que son incorporado en una línea de base en particular en un determinado punto en el ciclo de vida del software. La activación evento es la realización de algún tipo de oficial tarea aceptación, tales como una revisión formal. caracteriza el crecimiento de artículos como El ciclo de vida avanza. Esta cifra se basa en el modelo de cascada para los propósitos de la ilustración solamente; los subíndices usados en la figura indican versiones de los elementos cambiantes. La solicitud de cambio de software (SCR) se describe en la sección 3.1. En la adquisición de un SCI, su origen y la integridad inicial debe ser establecido. Tras la adquisición de un SCI, cambios en el elemento debe ser formalmente aprobado como adecuado para el SCI y la línea de base implicado, tal como se define en el PGCS. Tras la aprobación, el elemento se incorpora en la línea de base software de acuerdo con la apropiada procedimiento.


2.2. Biblioteca de software Una biblioteca de software es una colección controlada del software y la documentación relacionada diseñado para ayuda en el desarrollo de software, uso o mantenimiento. También es fundamental en la gestión de versiones de software y las actividades de entrega. Varios tipos de bibliotecas pueden ser utilizados, cada uno correspondiente a la determinado nivel de elemento de software de madurez. Por ejemplo, una biblioteca de trabajo podría apoyar codificación y una biblioteca de apoyo al proyecto podría apoyar las pruebas, mientras que una biblioteca principal podría ser utilizado para acabado productos. Un nivel adecuado de control de SMC (Línea de base y nivel de autoridad para los asociados modificar) está asociado con cada biblioteca. Seguridad, en términos de control de acceso y los mecanismos de seguridad informática, es un aspecto clave de la gestión de la biblioteca. La herramienta (s) que se utiliza para cada biblioteca debe soportar las necesidades de control de SMC para esa biblioteca, tanto en cuanto al control de los LIC y controlar el acceso a la biblioteca. A nivel biblioteca de trabajo, esto es una capacidad de gestión de código que sirve a los desarrolladores, mantenedores y SMC. Se centra en la gestión las versiones de los elementos de software mientras que apoya las actividades de múltiples desarrolladores. A los niveles más altos de control, el acceso es más restringido y SCM es el usuario principal. Estas bibliotecas son también una fuente importante de la información para las mediciones de trabajo y Progreso. 3. Control de Configuración de Software

control de la configuración de software se refiere con la gestión de los cambios en el software ciclo vital. Cubre el proceso para determinar qué cambios hacer, la autoridad de aprobar ciertos cambios, el apoyo a la puesta en práctica de esos cambios, y el concepto de la educación formal desviaciones de los requisitos del proyecto, así como renuncias de ellos. La información derivada de estos actividades es útil para medir el tráfico de cambio y la rotura, así como aspectos de la reanudación. 3.1. Solicitando, Evaluación y Aprobación Cambios en el software El primer paso en la gestión de cambios para controlada artículos es determinar qué cambios hacer. Los software de proceso de solicitud de cambio (ver un típico de flujo de un proceso de solicitud de cambio en la figura proporciona procedimientos formales para la entrega y grabación de las solicitudes de cambio, la evaluación del potencial coste y el impacto de un cambio propuesto, y aceptar, modificar, aplazar o rechazar el cambio propuesto. Una petición de cambio (CR) es una solicitud para ampliar o reducir el alcance del proyecto; modificar las políticas, procesos, planes o procedimientos; modificar los costos o presupuestos; o revisar los horarios. Las solicitudes de cambios en la configuración del software artículos pueden ser originados por cualquier persona en cualquier punto en el ciclo de vida del


software y puede incluir una propuesta de solución y la prioridad requerida. Uno fuente de un CR es el inicio de la corrección medidas en respuesta a los informes de problemas. Independientemente de la fuente, el tipo de cambio (por ejemplo, defecto o mejora) que se registra en el CR Software (SCR). Esto proporciona una oportunidad para el seguimiento defectos y que recogen las medidas de actividad de cambio según el tipo de cambio. Una vez que un SCR sea recibido , una evaluación técnica (también conocido como un impacto análisis) se lleva a cabo para determinar la extensión de las modificaciones que serían necesarias deberían aceptarse la solicitud de cambio . Una buena comprensión de las relaciones entre software (Y , posiblemente , de hardware ) es importante para los artículos esta tarea. Por último , una autoridad - acorde establecida con la línea de base afectada, el SCI involucrados , y la naturaleza de la variación de la voluntad evaluar los aspectos técnicos y de gestión de la solicitud de cambio y aceptar , modificar, rechazar o aplazar el cambio propuesto.

Imagen 6.3

3.1.1. Junta de Control de Configuración de Software La autoridad para aceptar o rechazar propuesta cambios descansa con una entidad típicamente conocido como Configuración Control Board (CCB). en menor proyectos, esta autoridad pueden residir de manera efectiva con el líder o una persona asignada en lugar de una tablero con varias personas. Puede haber varios niveles de la autoridad cambio dependiendo de una variedad de criterios- tales como la criticidad de mercancía, la naturaleza del cambio (por ejemplo, impacto en presupuesto y el calendario), o la corriente del proyecto punto en el ciclo de vida. La composición de la CCBs se utilizan para un sistema dado varía dependiendo en estos criterios (un representante de SMC


siempre estar presente). Todas las partes interesadas, apropiada al nivel de la CCB, están representados. Cuando el alcance de la autoridad de un CCB es estrictamente de software, se le conoce como una configuración de software Control Board (SCCE). Las actividades de la CCB suelen ser objeto de una auditoría de calidad de software o revisión. 3.1.2. Software Proceso de Solicitud de Cambio Una solicitud de cambio de software efectivo proceso (SCR) requiere el uso de herramientas y procedimientos de apoyo para originar las solicitudes de cambio, la aplicación del flujo del proceso de cambio, la captura decisiones CCB, y la presentación de informes proceso de cambio información. Un vínculo entre esta capacidad herramienta y el sistema de informe de problema puede facilitar el seguimiento de las soluciones para los problemas reportados. 3.2. Cambios en el software de aplicación SCR aprobadas se implementan utilizando la los procedimientos de software definidos de acuerdo con los requisitos de planificación aplicables. Desde un número de SCR aprobados podría implementarse simultáneamente, es necesario proporcionar un medio para el seguimiento de los cuales se incorporan en SCRs en particular las versiones de software y líneas de base. Como parte del cierre del proceso de cambio, completado cambios pueden someterse a auditorías de configuración y la verificación en esta calidad de software incluye asegurando que los cambios sólo han sido aprobados hecho. El proceso de solicitud de cambio de software descrito anteriormente típicamente documentar la SMC (y otros) para la información de aprobación cambio. Los cambios pueden ser compatibles con la versión de código fuente herramientas de control. Estas herramientas permiten a un equipo de ingenieros de software, o un solo ingeniero de software, para realizar un seguimiento y documentar los cambios en el código fuente. Estas herramientas proporcionan un único repositorio para almacenar El código fuente, puede evitar más de un software ingeniero de la edición del mismo módulo en Al mismo tiempo, y registrar todos los cambios realizados en el código fuente. Los ingenieros de software de verificación módulos fuera del repositorio, hacer cambios, el documento los cambios y, a continuación, guarde los módulos editados en el repositorio. Si es necesario, los cambios pueden ser también descartado, la restauración de una línea de base anterior. Más poderosas herramientas pueden apoyar el desarrollo paralelo y entornos distribuidos geográficamente. Estas herramientas pueden manifestarse como algo separado, aplicaciones especializadas bajo el control de una SMC grupo independiente. También pueden aparecer como una parte integrada de la ingeniería de software ambiente. Por último, pueden ser tan elemental como un sistema de control de cambios rudimentaria proporcionado con un sistema operativo. 3.3. Las desviaciones y exenciones


Las restricciones impuestas a una ingeniería de software esfuerzo o las especificaciones producidas durante el actividades de desarrollo podrían contener disposiciones que no pueden ser satisfechas en el punto designado en el ciclo de vida. Una desviación es una autorización por escrito, concedidas con anterioridad a la fabricación de una artículo, se aparte de la presentación del intérprete o requisito de diseño para un número determinado de unidades o un período específico de tiempo. La renuncia es un escrito la autorización para aceptar un elemento de configuración u otro elemento designado que se encuentra, durante la producción o después de haber sido sometido a inspección, para apartarse de los requisitos especificados, pero es sin embargo considerado adecuado para su uso como está o después de reelaborar por un método aprobado. En estos casos, una proceso formal se utiliza para la obtención de la aprobación de desviaciones con respecto a, o renuncias de, las disposiciones. 4. Configuración de software de contabilidad Estado Software de contabilidad de estado de configuración ( SCSA) es un elemento de gestión de la configuración que consiste del registro y la comunicación de la información necesaria para administrar una configuración efectiva. 4.1. Software de información de estado de configuración La actividad SCSA diseña y opera un sistema de Para la captura y presentación de informes de los necesarios la información a medida que avanza el ciclo de vida. Como en cualquier sistema de información, la información de estado de configuración ser gestionados por las configuraciones cambiantes deben ser identificados, recogido y mantenido. Se necesitan diversa información y mediciones para apoyar el proceso de SMC y para cumplir con la configuración informes de estado necesidades de gestión, ingeniería de software, y otras actividades relacionadas. Los tipos de información disponibles incluyen la identificación de la configuración aprobada, así como la identificación y el estado actual de implementación de cambios, desviaciones, y renuncias. Algún tipo de soporte de la herramienta automatizada es necesario para llevar a cabo la recogida de datos y SCSA informes tareas; esto podría ser una capacidad de base de datos, una herramienta independiente, o una capacidad de una más grande, entorno de herramientas integrado. 4.2. Software de informes de estado de Configuración

la información registrada puede ser utilizada por varios organizativos y de proyectos, incluyendo elementos el equipo de desarrollo, el equipo de mantenimiento, gestión de proyectos y actividades de calidad de software. Informes pueden tomar la forma de consultas para responder a preguntas específicas o el periódico producción de informes prediseñados. Alguna información producido por la actividad de registro del estado durante el curso del ciclo de vida podría convertirse los registros de control de calidad.


Además de informar el estado actual de la configuración, la información obtenida por la SCSA puede servir como base de diferentes mediciones. Los ejemplos incluyen el número de cambio solicitudes por SCI y el tiempo medio necesario para aplicar una solicitud de cambio 5. Auditoría Configuración del software Una auditoría de software es un examen independiente de un producto de trabajo o conjunto de productos de trabajo a evaluar el cumplimiento de las especificaciones, normas , acuerdos contractuales u otros criterios. Las auditorías se llevan a cabo de acuerdo con un bien definido proceso que consta de varias funciones de auditoría, así responsabilidades. En consecuencia , cada auditoría debe ser cuidadosamente planificada . Una auditoría puede requerir un número de las personas para realizar una variedad de tareas durante un período relativamente corto de tiempo. Herramientas de apoyo la planificación y realización de una auditoría puede ser de gran facilitar el proceso. auditoría determina la configuración del software el grado en que un elemento satisface la necesaria características funcionales y físicas. Informal auditorías de este tipo puede llevarse a cabo en puntos clave en el ciclo de vida. Hay dos tipos de auditorías formales podría ser requerido por el contrato de gobierno (por ejemplo, en los contratos que garanticen software crítico): la Auditoría de Configuración Funcional (FCA) y la Auditoría de Configuración física (PCA). Exitoso realización de estas auditorías puede ser un requisito previo para el establecimiento de la línea de base del producto. 5.1. Software de Auditoría de Configuración Funcional El propósito de la FCA software es asegurar que el elemento de software auditado es coherente con su que regula las especificaciones. La salida del software actividades de verificación y validación (véase Verificación y validación de la calidad de software KA) es un insumo clave para esta auditoría. 5.2. Auditoría de Configuración física de software El propósito de la configuración física software auditoría (PCA) es asegurar que el diseño y documentación de referencia es consistente con la como construido producto de software. 5.3. En-Proceso de Auditorías de una línea de base del software Como se mencionó anteriormente, las auditorías pueden llevarse a cabo durante el proceso de desarrollo para investigar el estado actual de los elementos específicos de la configuración. En este caso, una auditoría podría aplicarse a los elementos de línea de base de la muestra para asegurar que el rendimiento es consistente con las especificaciones o para asegurar que la


documentación que sigue evolucionando ser coherente con el elemento de línea de base en desarrollo. 6. Software de Gestión de Emisiones y Entrega

En este contexto, la liberación se refiere a la distribución de un elemento de configuración de software fuera la actividad de desarrollo; esto incluye interna comunicados así como la distribución a los clientes. Cuando diferentes versiones de un elemento de software están disponibles para la entrega (por ejemplo, versiones para diferentes plataformas o versiones con capacidades diferentes), es con frecuencia necesario volver a crear versiones específicas y empaquetar los materiales correctos para la entrega de la versión. La biblioteca de software es un elemento clave en el cumplimiento de las tareas de rescate y entrega. 6.1. Edificio de software construcción de software es la actividad de la combinación de la versiones correctas de los elementos de configuración de software, utilizando los datos de configuración apropiados, en una programa ejecutable para su entrega a un cliente u otro receptor, tal como la actividad de prueba. por sistemas con hardware o firmware, el ejecutable programa se entrega a la actividad de construcción de sistema. Construir instrucciones de asegurar que la acumulación adecuada se toman medidas en la secuencia correcta. en adición a la creación de software para los nuevos lanzamientos, por lo general es También es necesario que SMC para tener la capacidad de reproducir las versiones anteriores para la recuperación, las pruebas, mantenimiento, o con fines de liberación adicionales. El software se construye a partir de versiones particulares de herramientas de apoyo, tales como compiladores (véase el compilador Conceptos básicos en los Fundamentos de computación KA). Puede ser que sea necesario reconstruir una copia exacta de un elemento de configuración de software previamente construida. En este caso, herramientas de apoyo y la acumulación asociada instrucciones deben estar bajo el control de SMC asegurar la disponibilidad de las versiones correctas de la herramientas. Una capacidad de herramienta es útil para la selección de la correcta versiones de los elementos de software para un objetivo determinado medio ambiente y para la automatización del proceso de la construcción del software desde las versiones seleccionadas y los datos de configuración apropiados. para los proyectos con entornos de desarrollo paralelos o distribuidos, esta capacidad herramienta es necesaria. Más entornos de ingeniería de software proporcionan esta capacidad. Estas herramientas varían en complejidad desde que requiere el ingeniero de software para aprender una especializada lenguaje de programación orientado a gráficos de enfoques que ocultan la mayor parte de la complejidad de una instalación de acumulación "inteligente".


El proceso de construcción y productos están a menudo sujetos a la verificación de la calidad del software. Las salidas del proceso de construcción

podría ser necesaria para futuras referencias y puede convertirse en los registros de control de calidad.

6.2. Gestión de la Entrega de Software

gestión de versiones de software abarca el identificación, empaque y entrega de la elementos de un producto, por ejemplo, un archivo ejecutable programa, la documentación, notas de la versión, y datos de configuración. Teniendo en cuenta que los cambios de productos puede ocurrir sobre una base continua, una preocupación por gestión de la liberación es determinar cuándo deben emitir un comunicado. La gravedad de los problemas abordados por la liberación y las medidas de las densidades de fallo de las versiones anteriores afectan a esta decisión. los tareas de envasado debe identificar los elementos que productos han de ser entregadas y luego seleccionar la correcta variantes de esos elementos, teniendo en cuenta la aplicación prevista del producto. La información que documenta el contenido físico de un comunicado que se conoce como un documento de descripción de la versión. La liberación notas suelen describir nuevas capacidades, conocida problemas y requisitos de plataforma necesarios para un funcionamiento correcto del producto. El paquete sea lanzado también contiene la instalación o la actualización instrucciones. Este último puede ser complicado por la hecho de que algunos usuarios podrían tener versiones actuales que son varias versiones antiguas. En algunos casos, la liberación gestión podría ser necesaria con el fin de realizar un seguimiento la distribución del producto a diversos clientes o sistemas de destino; por ejemplo, en un caso en el que Se requiere que el proveedor que notifique a un cliente de se acaba de informar problemas. Por último, un mecanismo para garantizar la integridad del elemento puede ser liberado implementado, por ejemplo mediante la liberación de un convertidor digital firma con él. Se necesita una capacidad de herramienta de apoyo estas funciones de gestión de versiones. Es útil tener una conexión con la capacidad de la herramienta apoyar el proceso de solicitud de cambio con el fin de contenidos de liberación mapa a los SCR que han sido recibido. Esta capacidad herramienta también podría mantener información sobre diversas

plataformas de destino y en diversos entornos de clientes.

7. herramientas de Software Cuando se habla de gestión de configuración de software herramientas, es útil para clasificarlos. SMC herramientas se pueden dividir en tres clases en términos del ámbito en el que se proporcionan apoyo: individuo el apoyo, el apoyo relacionados con el proyecto, y soporte de procesos. herramientas de apoyo individuales son apropiadas y típicamente suficiente para las organizaciones pequeñas o grupos de desarrollo sin variantes de su productos de software u otros requisitos SCM complejos. Incluyen:


• Las herramientas de control de versiones: pista, documentar y almacenar los elementos de configuración individuales, tales como código fuente y la documentación externa. • herramientas de manejo de la creación: en su forma más simple, este tipo de herramientas de compilación y enlace un ejecutable versión del software. Más avanzado herramientas de construcción de extraer la última versión desde el software de control de versiones, realice la calidad cheques, ejecutar pruebas de regresión, y producen diversas formas de informes, entre otras tareas. • Herramientas de control de cambios: apoyar sobre todo la el control de las solicitudes y los eventos de cambio de notificación (Por ejemplo, la solicitud de cambio de estado cambios, hitos alcanzados). herramientas de apoyo relacionados con el proyecto, principalmente de apoyo gestión de espacio de trabajo para los equipos de desarrollo e integradores; por lo general son capaces de soportar entornos de desarrollo distribuidos. Tal herramientas son apropiadas para medianas y grandes organizaciones con variantes de sus productos de software y el desarrollo paralelo, pero sin certificación requisitos. herramientas de apoyo en procesos en toda la empresa puede normalmente automatizar las partes de un proceso de toda la compañía, brindar apoyo a gestiones de flujo de trabajo, funciones y responsabilidades. Ellos pueden para manejar muchos artículos, datos y ciclos de vida. Tal herramientas se suman a la ayuda relacionada con el proyecto mediante el apoyo un proceso más formal de desarrollo, incluyendo requisitos de certificación

IEEE 828-2012 [ 2 *]

Hass 2003 [3*]

Moore 2006 [5*]

Sommerville 2011 [4*]

1. Gestión del SMC Proceso

1.1 Contexto de organización de SMC

C6, ann.D Introducción C29

1.2. Limitaciones y orientación para el SMC Proceso

C6, ann.D, ann.E

C2 C19s2.2 C29 introducción

1.3. La planificación de SMC

C6, ann.D, ann.E

C23 C29

1.3.1. Organización y Responsabilidades SMC

Ann.Ds5-6

C10-11 C29 introducción

1.3.2. Recursos SCM y horarios

Ann.Ds8 C23

1.3.3. Herramienta de selección e implementación

C26s2; s6 C29s5

1.3.4. Proveedor / C13 C13s9-


subcontratista de Control c14s2

1.3.5. control de interfaz

C12 C24s4

1.4. plan de SMC Ann.D C23 C29s1

1.5. La vigilancia de la Configuración del Software administración

C11s3

1.5.1. Medidas de SCM y Medición

C9s2; c25s2-s3

1.5.2. En - Proceso de Auditorías de SMC

C1s1

2.. Identificación Configuración del software

C29s1.1

2.1. Los productos que identificar que hay que controlar

C8s2.2 C29s1.1

2.1.1. Configuración del software

2.1.2. Software Elemento de Configuración

C29s1.1

2.1.3. Software Elemento de Configuración relaciones

C7s4

2.1.4. Versión del software

C29s3

2.1.5. Base

2.1.6. La adquisición de elementos de configuración de software

C18

2.2. Biblioteca de software C1s3 C29s1.2

3. Control de Configuración de Software

C9 C29s2

3.1. Solicitando, Evaluación y Aprobación Cambios en el software

C9s2.2 C29s2

3.1.1. Junta de Control de Configuración de Software

C9s2.2 C11s1 C29s2

3.1.2. Software Proceso de Solicitud de Cambio

C1s4, c8s4

3.2. Cambios en el software de aplicación

C29

3.3. Las desviaciones y exenciones

4. Configuración de C10


software de contabilidad Estado

4.1. Software de información de estado de configuración

C10s2.1

4.2. Software de informes de estado de Configuración

C10s2.4 C1s5, c9s1, c17

5. Auditoría Configuración del software

C11

5.1. Software de Auditoría de Configuración Funcional

C11s2.1

5.2. Auditoría de Configuración física de software

C11s2.2

5.3. En-Proceso de Auditorías de una línea de base del software

C11s2.3

6. Software de Gestión de Emisiones y Entrega

C14 C8s2 C29s3

6.1. Edificio de software C29s4 6.2. Gestión de la Entrega de Software

C29s3.2

7. herramientas de Software

C26s1

LECTURAS Stephen P. Berczuk y Brad Appleton, Gestión de la Configuración de Software Patrones: El trabajo en equipo eficaz, práctica Integración [6]. Este libro expresa prácticas útiles y SCM estrategias como patrones. Los patrones pueden ser implementadas utilizando diversas herramientas, sino que se expresa de una manera independiente del instrumento. "CMMI para el Desarrollo", versión 1.3, pp. 137-147 [7]. Este modelo presenta una recopilación de las mejores prácticas para ayudar a las organizaciones de desarrollo de software mejorar sus procesos. En el nivel de madurez 2, se sugiere actividades de gestión de configuración. REFERENCIAS [1] ISO / IEC / IEEE 24765: 2010 Sistemas y Ingeniería de Software-Vocabulario, ISO / IEC / IEEE 2010.


[2 *] IEEE Std. 828-2012, Norma para Gestión de la configuración de los sistemas y Ingeniería de Software, IEEE 2012. [3 *] A.M.J. Hass, Gestión de la Configuración Principios y Prácticas, 1ª ed., Addison Wesley, 2003. [4 *] I. Sommerville, Ingeniería de Software, 9 ed., Addison-Wesley, 2011. [5 *] J.W. Moore, La Hoja de Ruta de Software Ingeniería: Una guía basada en estándares, Wiley-IEEE Computer Society Press, 2006. [6] S. P. Berczuk y B. Appleton, Software Patrones de Gestión de la Configuración: El trabajo en equipo eficaz, la integración práctica, Addison-Wesley Professional 2003. [7] CMMI equipo de productos, "CMMI para El desarrollo de software, versión 1.3, " Instituto de Ingeniería, 2010; http: // resources.sei.cmu.edu/library/asset-view. cfm? assetId = 9661.

analisis de diseÑo de informacion software … · configuración de software identificación,...

Documents