IngSW//Cliente-Servidor

INGENIERIA DEL SOFTWARE

ARQUITECTURA CLIENTE SERVIDOR

DEFINICIÓN:

Sistema distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan. Separa los servicios situando cada uno en su plataforma más adecuada.

EL MODELO CLIENTE – SERVIDOR

Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente aún en entornos multiplataforma.

En el modelo cliente servidor, el cliente envía un mensaje solicitando un determinado servicio a un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el servicio).

En un sistema distribuido cada máquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras.

La idea es tratar a una computadora como un instrumento, que por sí sola pueda realizar muchas tareas, pero con la consideración de que realice aquellas que son mas adecuadas a sus características.

Si esto se aplica tanto a clientes como servidores se entiende que la forma más estándar de aplicación y uso de sistemas Cliente/Servidor es mediante la explotación de las PC’s a través de interfaces gráficas de usuario; mientras que la administración de datos y su seguridad e integridad se deja a cargo de computadoras centrales tipo mainframe. Usualmente la mayoría del trabajo pesado se hace en el proceso llamado servidor y el o los procesos cliente sólo se ocupan de la interacción con el usuario (aunque esto puede variar).

En otras palabras la arquitectura Cliente/Servidor es una extensión de programación modular en la que la base fundamental es separar una gran pieza de software en módulos con el fin de hacer más fácil el desarrollo y mejorar su mantenimiento.

Esta arquitectura permite distribuir físicamente los procesos y los datos en forma más eficiente lo que en computación distribuida afecta directamente el tráfico de la red, reduciéndolo grandemente.

CLIENTE / SERVIDOR

Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.

Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.

La red Cliente/Servidor es aquella red de comunicaciones en la que todos los clientes están conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposición de los clientes cada vez que estos son solicitados. Esto significa que todas las gestiones que se realizan se concentran en el servidor, de manera que en él se disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso público y los que son de uso restringido, los archivos que son de sólo lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se esté utilizando en una red mixta.

¿CUÁNDO IMPLANTAR CLIENTE/SERVIDOR?

1. Cambios estructurales y organizativos.

2. Cambios en organigramas.

3. Respuesta dinámica de mercado.

4. Cambio en procesos de negocio.

¿QUÉ AYUDA A LA IMPLEMENTACIÓN?

1. La demanda de sistemas fáciles.

2. Precio/rendimiento de estaciones y servidores.

3. Creciente acceso a la información para decisiones:

A.                 Separación datos-programas.

B.                 Programas flexibles.

4. Nuevas tecnologías de alta productividad.

.

CLIENTE

Es el que inicia un requerimiento de servicio. El requerimiento inicial puede convertirse en múltiples requerimientos de trabajo a través de redes LAN o WAN. La ubicación de los datos o de las aplicaciones es totalmente transparente para el cliente. En la arquitectura C/S el remitente de una solicitud es conocido como cliente.

CARACTERÍSTICAS DEL CLIENTE:

1.                  Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).

2.                  Espera y recibe las respuestas del servidor.

3.                  Por lo general, puede conectarse a varios servidores a la vez.

4.                  Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.

5.                  5. Al contratar un servicio de redes , se tiene que tener en la velocidad de conexión que le otorga al cliente y el tipo de cable que utiliza , por ejemplo : cable de cobre ronda entre 1 ms y 50 ms.

SERVIDOR

Es cualquier recurso de cómputo dedicado a responder a los requerimientos del cliente. Los servidores pueden estar conectados a los clientes a través de redes, para proveer de múltiples servicios a los clientes y ciudadanos tales como impresión, acceso a bases de datos, fax, procesamiento de imágenes, etc. Al receptor de la solicitud enviada por cliente se conoce como servidor.

CARACTERÍSTICAS DEL SERVIDOR:

1. Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).

2. Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.

3. Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado).

4. No es frecuente que interactúen directamente con los usuarios finales.

FUNCIONES

CLIENTE:

El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor, se le conoce con el término front-end.

El Cliente normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas de usuario (GUI), además de acceder a los servicios distribuidos en cualquier parte de una red.

Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:

• Administrar la interfaz de usuario.

• Interactuar con el usuario.

• Procesar la lógica de la aplicación y hacer validaciones locales.

• Generar requerimientos de bases de datos.

• Recibir resultados del servidor.

• Formatear resultados.

SERVIDOR:

Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso servidor se le conoce con el término back-end.

El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos.

 Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes puntos:

• Aceptar los requerimientos de bases de datos que hacen los clientes.

• Procesar requerimientos de bases de datos.

• Formatear datos para trasmitirlos a los clientes.

• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.

IngSw//Sala Limpia

INGENIERIA DEL SOFTWARE

SALA LIMPIA

Definición 

La ingeniería del Software de sala limpia es un enfoque formal para el desarrollo del Software, que pueda dar lugar a un Software que posea una calidad notablemente alta. Emplea la especificación de estructura de cajas (o métodos formales) para el modelado de análisis y diseño, y hace hincapié en la verificación de la corrección, más que en la comprobación, como mecanismo fundamental para hallar y eliminar errores. Se aplica una comprobación estadística de utilización para desarrollar la información de tasa de fallos necesaria para certificar la fiabilidad del Software proporcionado.

La filosofía de sala limpia es un enfoque riguroso de la ingeniería del Software. Se trata de un modelo de proceso del Software que hace hincapié en la verificación matemática de la corrección, y en la certificación de la fiabilidad del Software. El resultado final son unas tasas de fallo extremadamente bajas, que sería difícil o imposible de conseguir empleando unos métodos menos formales.

Tareas de Sala Limpia

La sucesión de tareas de sala limpia para cada incremento, se manifiesta mediante unos requisitos globales del sistema o producto que se van desarrollando empleando los métodos de ingeniería de sistemas. Una vez que se han asignado una funcionalidad al elemento de Software del sistema el tubo de la sala limpia comienza sus incrementos y se producen las siguientes tareas.

- Planificación de Incrementos. La planificación incremental permite calidad temprana y continua interacción con el usuario. Facilita mejoras de proceso mientras el desarrollo progresa. El acercamiento incremental evita los riesgos inherentes integración tardía en el ciclo de desarrollo.

- Recolección de requisitos. El propósito del proceso del análisis de requisitos es 1) definir requisitos para el producto de software, incluyendo función, uso, ambiente, y funcionamiento, y 2) obtener un acuerdo con el cliente en los requisitos como la base para la función y especificación del uso.

- Especificación de la estructura de cajas. Tres tipos especiales de funciones matemáticas son importantes en el desarrollo a Sala limpia, debido a su correspondencia y correlación en el proceso de descomposición y verificación. Estas funciones son conocidas como la caja negra, la caja de estado y caja limpia. En la estructura de las cajas se pueden aplicar una variedad de estrategias de descomposición, además se puede incluir funcionabilidad y orientación a objeto.

- Diseño Formal. Mediante el uso del enfoque de estructura de cajas, el diseño de sala limpia es una extensión natural y sin discontinuidades de la especificación. Dan los objetivos, los participantes, los criterios de entrada, las tareas, la verificación, las medidas y los criterios comunes de la salida en los procesos, así como elementos de proceso común.

- Verificación de Corrección. El equipo de sala limpia lleva a cabo una serie de rigurosas actividades de verificación de corrección aplicadas primero al diseño y después al código. El propósito del proceso de la verificación de la corrección, es verificar la corrección del incremento del software usando técnicas matemáticas.

- Generación de Código, inspección y verificación. Las especificaciones de estructura de caja que se representan mediante un lenguaje especializado se traducen la lengua de programación mas adecuado. 

- Planificación de la comprobación estadística, Comprobación estadística de utilización y Certificación. El propósito del proceso estadístico de prueba y de certificación es demostrar la aptitud del software para el uso en un experimento estadístico formal. La "aptitud para el uso" se define con respecto a los modelos de uso y a las metas de la certificación empleados en el proceso de prueba. Las metas de certificación, primero establecidas en el plan de medida y refinadas en el plan de prueba de incremento, se pueden expresar en términos tales como índice de confiabilidad del software.

Cajas de Sala Limpia 

Una caja encapsula el sistema con un cierto grado de detalle. Mediante un proceso de refinamiento progresivo, se van refinando las cajas para formar una jerarquía en la cual cada caja tiene una transferencia. Para esto se utilizan tres tipos de cajas:

- Caja Negra. Especifica el comportamiento del sistema, o de una parte de un sistema.

- Caja de Estado. Esta caja encapsula los datos de estados y de servicios (operaciones) de forma análoga a los objetos. En esta vista de especificación, se representan las entradas de la caja de estados y sus salidas.

- Caja Transparente. Las funciones de transición que están implicadas en la caja de estados se definen en la caja transparente.

 Verificación de diseño 

El diseño que se utiliza en la ingeniería del Software de sala limpia hace mucho uso de la filosofía de programación estructurada. Son realmente las funciones básicas de procesamiento, se refinan ahora utilizando una expansión progresiva de funciones matemáticas en estructuras de conectivas lógicas.

 Comprobación de la sala limpia 

La técnica y estrategia de la comprobación de la sala limpia es algún fundamentalmente distinto de los enfoques convencionales de comprobación. Los métodos convencionales derivan de un conjunto de casos de prueba para descubrir errores de diseño y codificación.

 Diferenciar de Sala Limpia 

Existen diversos métodos o paradigmas que nos reflejan la diferencia notoria de que sea sala limpia. 

- Hace uso explícito del control estadístico de calidad.

- Verifica la especificación del diseño empleando una demostración de corrección basada en las matemáticas. 

- Hace mucho uso de la comprobación estadística de utilización para descubrir errores de especial incidencia.

INGENIERIA DEL SOFTWARE

INGENIERIA EN SISTEMAS

Cuestionario:

1.   ¿Cuál es el origen de la ingeniería de sistemas?

2.   ¿En qué consiste cada elemento del sistema basado en computadoras?

3.   Explique cada una de las restricciones que el equipo de trabajo puede encontrar para construir un modelo de sistemas

4.   ¿En qué consiste la ingeniería de procesos de negocios?

5.   ¿En qué consiste la ingeniería de negocios?

Respuestas

1.   Hace casi 500 años, Maquiavelo dijo: c... no hay nada más difícil de llevar a cabo, más peligroso de realizar o de éxito más incierto que tomar el liderazgo en la introducción de un nuevo orden de cosas». Durante los Últimos 50 años, los sistemas basados en computadora han introducido un nuevo orden. Aunque la tecnología ha conseguido grandes avances desde que habló Maquiavelo, sus palabras siguen sonando a verdad

La ingeniería del software aparece como consecuencia de un proceso denominado ingeniería de sistemas. En lugar de centrarse únicamente en el software, la ingeniería de sistemas se centra en diversos elementos, analizando, diseñando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la transformación de información o control de información.

2.      Para conseguir el objetivo, un sistema basado en computadora hace uso de varios elementos del sistema:

·         Software. Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido.

·         Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo y dispositivos electromecánicos (p.ej.: sensores, motores, bombas) que proporcionan una función externa.

·         Personas. Usuarios y operadores del hardware y software.

·         Bases de Datos. Una gran colección de información organizada a la que se accede por medio del software.

·         Documentación. Manuales, formularios y otra información descriptiva que retrata el empleo y/o operación del sistema.

·         Procedimientos. Los pasos que definen el empleo especifico de cada elemento del sistema o el contexto procedimental en que reside el sistema. 

3.   Para construir un modelo de sistema, el ingeniero debería considerar algunas                                                             restricciones:

o   Supuestos que reducen el número de permutaciones y variaciones posibles, permitiendo así al modelo reflejar el problema de manera razonable. Por ejemplo, considere un producto de representación en tres dimensiones usado por la industria de entretenimiento para crear animaciones realistas. Un dominio del producto permite la representación de formas humanas en 3D. Las entradas a este dominio comprenden la habilidad de introducir movimiento de un "actor" humano vivo, desde vídeo o creando modelos gráficos. El ingeniero de sistemas hace ciertos supuestos sobre el rango de movimientos humanos permitidos (p.ej.: las piernas no pueden enrollarse alrededor del tronco) de manera que puede limitarse el proceso y el rango de entradas.

o    Simplificaciones que permiten crear el modelo a tiempo. Para ilustrarlo, considere una compañía de productos de oficina que vende y suministra una amplia variedad de fotocopiadoras, faxes y equipos similares. El ingeniero de sistemas está modelando las necesidades de la organización suministradora y está trabajando para entender el flujo de información que engendra una orden de suministro. Aunque una orden de suministro puede generarse desde muchos orígenes, el ingeniero categoriza solamente dos fuentes: demanda interna o petición externa. Esto permite una partición simplificada de entradas necesaria para generar una orden de trabajo.

o   Limitaciones que ayudan a delimitar el sistema. Por ejemplo, se está modelando un sistema de aviónica para un avión de próxima generación. Como el avión tendrá un diseño de dos motores, todos los dominios de supervisión de la propulsión se modelarán para albergar un máximo de dos motores y sus sistemas redundantes asociados.

o   Restricciones que guían la manera de crear el modelo y el enfoque que se toma al implementar el modelo. Por ejemplo, la infraestructura tecnológica para el sistema de representación en tres dimensiones descrita anteriormente es un solo procesador basado en un Power-PC. La complejidad de cálculo de los problemas deben restringirse para encajar en los límites de proceso impuestos por el procesador.

o   Preferencias que indican la arquitectura preferida para toda la información, funciones y tecnología. La solución preferida entra a veces en conflicto con otros factores restrictivos. Aunque, la satisfacción del cliente es a menudo tomada en cuenta hasta el punto de realizar su enfoque preferido. 

Los procesos de negocio pueden ser controlados y administrados de forma manual o por un sistema de software, la Ingeniería de Procesos (conocida también como Automatización de Procesos), es la práctica de analizar el flujo operativo y/o administrativo de una compañía para descubrir elementos que pueden optimizarse, a fin de implementar la mejor manera de llevar a cabo dicho flujo o proceso.

4.   INGENIERIA DEL PRODUCTO

El objetivo de producto es traducir el deseo del cliente de un conjunto de capacidades a un producto operativo.

Se establece una infraestructura se soporte e incluye la tecnología requerida

Esta ingeniería debe crear una arquitectura y una infraestructura

La visión global se consigue a través de la ingeniería de requisitos

Los requisitos generales del producto se obtienen del cliente

Luego de conocido los requisitos, la misión del análisis de sistemas es asignar funcionalidad y comportamiento de cada uno de los cuatro elementos.

INGENIERÍA DEL SOFTWARE

2DO CUESTIONARIO

1. Realizar un pequeño mural con recortes periodísticos acerca de lo que las empresas están requiriendo en el área de la informática.

 2. Análisis y Diseño estructurado de nuestro proyecto

D.E.R

DIAGRAMA DE COMPONENTES

DIAGRAMA DE CLASES

DIAGRAMAS DE CASOS DE USOS

DIAGRAMA DE ESTADO

3. Calcule las métricas orientadas al tamaño, punto de función y ampliadas, así como las métricas de calidad.

PSEUDOCODIGO FARMACIA JERUSALÉN

Main()

{

Int opción;

Do{

Print(“MENU”);

Print(“1. Ingresar producto”);

Print(“2. Ingresar Proveedor”);

Print(“3. Devolución Producto”);

Print(“4. Salir);

read(opción);

switch(opcion)

{

Case 1:IngresarProducto();

             Break;

Case 2:IngresarProveedor();

             Break;

Case 3:devolucion();

             Break;

Default: print(“OPCION INVALIDA”);

             Break;

}

While(opcion !=4);

}

IngresarProducto() {

Int id,cantidad;

String nombre;

Print (“ID Producto:”);

Read (id);

Print (“Nombre del producto:”);

Read (nombre);

Print (“Cantidad:”);

Read (cantidad);

Guardar(id,nombre,cantidad);

}

IngresarProveedor()

{

Int id;

String nombre;

String dirección;

String  telefono;

Print (“id de Proveedor:”);

Read (id);

Print (“Nombre:”);

Read (nombre);

Print (“Direccion:”);

Read (direccion);

Print (“Telefono:”);

Read (telefono);

Guardar(id,nombre,dirección,telefono);

}

Devolucion()

{

Int idprod, idprv , cantidad;

Time fecha;

Print (“ID Producto:”);

Read (idprod);

Print (“ID Proveedor:”);

Read (idprv);

Print (“Cantidad devuelta:”);

Read (cantidad);

Print (“Fecha de devolucion:”);

Read (fecha);

Guardar(id,nombre,cantidad);

}

 POSIBLES RIESGOS DEL SW GENERICOS

4. Preparar material Didáctico acerca de la garantía de calidad y gestión de configuración del software.

GARANTIA DE CALIDAD DEL SOFTWARE (SQA/GCS)

La tendencia de la calidad

La tendencia de la calidad se ha utilizado desde los años cuarenta con el objetivo de obtener una alta calidad del producto tanto en ahorro de costes y en una mejora general, para ello se basa en la terminología de GTC (gestión de calidad total) normalmente se encuentra una progresión básica de cuatro pasos que constituye el fundamento de cualquier programa de GTC.

Los dos primeros pasos se centran en la mejora del proceso, el tercer paso se centra en el usuario del producto y finalmente el cuarto paso va más allá del producto se centra en la utilización del producto en el mercado.

Garantía de calidad del software

Para tener una garantía de calidad del software debe existir una concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo claramente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente.

Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.

Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.

Muchas de las veces existe un conjunto de requisitos implícitos que a menudo no se mencionan por ejemplo: el deseo por facilitar el uso y un buen mantenimiento. Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software no se logra.

Puntos importantes:

1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.

2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.

3.Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo: el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.

Problemas de fondo

La historia de la garantía de calidad en el desarrollo de software es paralela a la historia de la calidad en la creación de hardware. Durante los primeros años de la informática (los años cincuenta y sesenta), la calidad era responsabilidad únicamente del programador. Durante los años setenta se introdujeron estándares de garantía de calidad para el software en los contratos militares para desarrollo de software y se han extendido rápidamente a los desarrollos de software en el mundo comercial

Ampliando la definición presentada anteriormente, la garantía de calidad del software (SQA) es un «patrón de acciones planificado y sistemático» que se requiere para asegurar la calidad del software.

El grupo de SQA sirve como representación del cliente en casa. Es decir, la gente que lleva a cabo la SQA debe mirar el software desde el punto de vista del cliente.

Actividades de SQA

La garantía de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes los ingenieros de software que realizan trabajo técnico y un grupo de SQA que tiene la responsabilidad de la Planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes-.

Los ingenieros de software afrontan la calidad (y realizan garantía de calidad) aplicando métodos técnicos sólidos y medidas, realizando revisiones técnicas formales y llevando a cabo pruebas de software bien planificadas.

Las reglas del grupo de SQA tratan de ayudar al equipo de ingeniería del software en la consecución de un producto final de alta calidad. El Instituto de Ingeniería del Software recomienda un conjunto de actividades de SQA que se enfrentan con la planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes. Éstas son las actividades que realizan(o facilitan) un grupo independiente de SQA:

Establecimiento de un plan de SQA para un proyecto.

El plan se desarrolla durante la planificación del proyecto y es revisado por todas las partes interesadas. Las actividades de garantía de calidad realizadas por el equipo de ingeniería del software y el grupo SQA son gobernadas por el plan. El plan identifica:

evaluaciones a realizar,

auditorias y revisiones a realizar,

estándares que se pueden aplicar al proyecto,

procedimientos para información y seguimiento de errores

documentos producidos por el grupo SQA,

realimentación de información proporcionada al equipo de proyecto del software.

Cuál es el papel de un grupo de SQA

Participación en el desarrollo de la descripción del proceso de software del proyecto. El equipo de ingeniería del software selecciona un proceso para el trabajo que se va a realizar. El grupo de SQA revisa la descripción del proceso para ajustarse a la política de la empresa, los estándares internos del software, los estándares impuestos externamente (por ejemplo: 1SO 9001), y a otras partes del plan de proyecto del software.

Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido. El grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso y verifica que se han hecho las correcciones.

Auditoria de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software. El grupo de SQA revisa los productos seleccionados; identifica, documenta y sigue la pista de las desviaciones; verifica que se han hecho las correcciones, e informa periódicamente de los resultados de su trabajo al gestor del proyecto.

Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido. Las desviaciones se pueden encontrar en el plan del proyecto, en la descripción del proceso, en los estándares aplicables o en los productos técnicos.

Registrar lo que no se ajuste a los requisitos e informar a sus superiores. Los elementos que no se ajustan a los requisitos están bajo seguimiento hasta que se resuelven.

GESTION DE LA CONFIGURACION DEL SOFTWARE (GCS/SCM)

LINEA BASE.

•          Especificación o producto que se ha revisado “formalmente” y sobre la que se ha llegado a un acuerdo y, que de ahí en adelante, sirve como base para un desarrollo posterior y que puede cambiarse sólo a través de procedimientos formales de control de cambios.

Elementos de configuración del software

• Es un documento completo de casos de prueba o un componente de un programa dado.
• Estos se organizan como objetos de configuración.
• Especificacion de diseño.
• Diseño arquitectonico.
• Diseño de datos.
• Diseño de modulos.

Diseño de interfaces

El proceso de GCS.

• Garantiza la calidad del software, su responsabilidad principal es el control de cambios.
• También es importante de las distintas versiones del software, de las auditorias de la configuración  del software para asegurar que se desarrollen adecuadamente y de la generación de informe sobre los cambios realizados en la configuración.

La GCS llevan a la definición de 5 preguntas

(1). Identificación de objetos en la configuración del software

• Se identifican 2 tipos de objetos.
• Objeto básico.

Es una unidad de texto creada por el ingeniero de software durante el análisis, diseño, codificación o pruebas.

• Objeto compuesto.

Es una colección de objetos básicos.

(2). Control de versiones.

• Combina procedimientos y herramientos para gestionar las versiones de los objetos de configuración creados durante el proceso del software.

(3). Control de cambios.

• Para cada cambio aprobado se genera una orden de cambio de ingenieria (OCI), que describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisión y de auditoria.

(4). Auditoria de la configuración.

• La identificación, el control de versiones y el control de cambios ayudan al equipo de desarrollo de software a mantener un orden.
• Se plantea las siguientes preguntas.

Ø  Se ha hecho el cambio especificado en la OCI?

Ø  Se han especificado la fecha del cambio y el autor?

Ø  Se han seguido procedimientos de GCS para señalar el cambio, registrarlo y divulgarlo?

Ø  Se han actualizados adecuadamente todos los ECS relacionados?

(5). Informe de estado.

• Llamada también contabilidad de estado.
• Que pasó?
• Quién lo hizo?
• Cuándo pasó?
• Qué mas se vio afectado?

Resumen.

La GCS es una actividad de protección que se aplica a lo largo de todo el proceso del software. Una vez se ha desarrollado y revisado un objeto de configuración, se convierte en una línea base. El control de versiones es un conjunto de procedimientos y herramientas que se usan para gestionar el uso de los objetos. El control de cambios es una actividad procedimental que aseguran la calidad y la consistencia a medida que se realizan cambios en los objetos de la configuración.