Ing. del Software 2012

   1- El Producto Software

• Características

• Aplicaciones 

• Mitos / Realidades 

• Capas 

• Fases Genéricas

• Marco Común de Trabajo

2- Modelo de Desarrollo de Software





3- El Espectro de Gestión

• Personal Calificado 

• Marcador a Nivel de País (Oferta Vs Demanda)

4- Métrica

5- Planificación

6- Gestión de Riesgo

7- Gestión de Garantía de Calidad

8- Gestión de Configuración del Software

Cuestionario I

1- Mediante las técnicas (Cuadro Sinoptico) explique las características del software

2- Ejemplifique cada una de las Aplicaciones del Software

3- Mediante un dibujo establezca los escenarios donde se reflejen los mitos y realidades del software en cuanto a gestión  cliente y equipo de desarrollador.

Gestión: Planificación y Herramientas para el Desarrollo del     prototipo

Del Cliente: Entrega de documentos de contrato y requerimientos del cliente para la elaboración del software.

Equipo de Desarrollo: Revisión técnica de la calidad de las etapas de desarrollo del software

4- Ejemplifique las capas de desarrollo de software (Dibujo Pastel)

5- Identifique en cuales situaciones ha aplicado los modelos de desarrollo de software

Cuando se trata de un sistema grande y participan varias personas en su desarrollo cumpliendo un las necesidades especificadas por el cliente, es necesario aplicar uno de los modelos mas adecuados al caso como el Modelo Lineal Secuencial porque su elaboración es detalladamente y paso por paso hasta la culminación del prototipo.

Cuestionario II

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

2- Del proyecto realizado a nivel de análisis y diseño estructurado (Diagrama de Contexto, DFD, Fichero Físico  a orientado a objetos(Diagramas de Casos de Uso, de Actividad, de Iteracion) calcule las métricas orientado el tamaño, punto de función y aplicados así como los métricos de calidad

Métrica Orientadas al tamaño

Nuestro sistema cuenta con:

· Costo: 5000

· LDC : 12000

· Equipo: 4

· Periodo : 1 año

Se emplearon 120 hojas de papel para documentar y se detectaron 80 errores

Calculamos los recursos necesarios para implementar el mantenimiento de nuestros sistema en 2 meses

Cálculos indicadores

· Indice productividad = 12000/3*12 = 333.33 LDC por cada error

· Indice de calidad = 12000/80 = 150 LDC para cometer un error
· Indice de documentación = 120/12000 = 0.01 Paginas por cada 100 LDC

· Indice de costo = 5000/12000 =0.416 córdoba por cada linea de   código.

Métricas Orientadas a la función

Tablas y Calculo de la métrica orientada a la función en base al diagrama de flujo de datos del sistema de vuelos del aeropuerto A.C. Sandino

3- Dela tabla de Análisis de Riesgo (Modificada a nuestra realidad económica) establezca ejemplos de cada categoría

4- Material didáctico acerca de la Garantía de Calidad y Gestión de Configuración de Software 

Gestión de la Calidad del Software

La Gestión de la Calidad de Software es un conjunto de actividades de la función general de la Dirección que determina la calidad, los objetivos y las responsabilidades. Se basa en la determinación y aplicación de las políticas de calidad de la empresa. La Gestión o Administración de la Calidad se aplica normalmente a nivel empresa o dentro de la gestión de cada proyecto. El propósito de la Gestión de la Calidad del Software es entender las expectativas del cliente en términos de calidad, y poner en práctica un plan proactivo para satisfacer esas expectativas.

Desde el punto de vista de la calidad, la Gestión de la Calidad del Software (CS) está formada por 4 partes, las cuales son: (1) Planificación de la CS, (2) Control de la CS, (3) Aseguramiento de la CS y (4) Mejora de la CS.

La Planificación de la Calidad del Software (1) es la parte de la Gestión de la Calidad encargada de realizar el proceso administrativo de desarrollar y mantener una relación entre los objetivos y recursos de la organización; y las oportunidades cambiantes del mercado. El objetivo es modelar y remodelar los negocios y productos de la empresa, de manera que se combinen para producir un desarrollo y utilidades satisfactorias.

Los aspectos a considerar en la Planificación de la CS son: Modelos/Estándares de CS a utilizar, Costos de la CS, Recursos humanos y materiales necesarios, etc. El plan de calidad define los atributos de calidad más importantes del producto a ser desarrollado y define el proceso de evaluación de la calidad. En la Planificación de la CS se debe determinar: (1) Rol de la Planificación, (2) Requerimientos de la CS, (3) Preparación de un Plan de CS, (4) Implementación de un Plan de CS y (5) Preparar un Manual de Calidad.

El Control de la Calidad del Software (2) son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradas en 2 objetivos fundamentales: (1) mantener bajo control un proceso y (2) eliminar las causas de los defectos en las diferentes fases del ciclo de vida. Está formado por actividades que permiten evaluar la calidad de los productos de software desarrollados. El aspecto a considerar en el Control de la CS es la “Prueba del Software”.

La prueba es el proceso de ejecutar un programa con intención de encontrar defectos. Es un proceso destructivo que determina el diseño de los casos de prueba y la asignación de responsabilidades. La prueba exitosa es aquella que descubre defectos. El “caso de prueba bueno” es aquel que tiene alta probabilidad de detectar un defecto aún no descubierto. El “caso de prueba exitoso” es aquel que detecta un defecto aún no descubierto.

La prueba no es: (1) demostración que no hay errores, (2) demostración que el software desempeña correctamente sus funciones y (3) establecimiento de confianza que un programa hace lo que debe hacer.

La prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la confiabilidad del software e indican la calidad del software como un todo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.

Una estrategia Tradicional de prueba del software debe incluir pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente, así como pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente. Una estrategia proporciona un conjunto de hitos.

Inicialmente, la prueba se centra en cada módulo individualmente, asegurando que funciona adecuadamente como una unidad. La prueba de unidad hace un uso intensivo de las técnicas de prueba de caja blanca, ejercitando caminos específicos de la estructura de control del módulo para asegurar un alcance completo y una detección máxima de errores. La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software: el componente de software o módulo. Se prueba la interfaz del módulo para asegurar que la información fluye de forma adecuada hacia y desde la unidad de programa que está siendo probada. Se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservan su integridad durante todos los pasos de ejecución del algoritmo. Se prueban las condiciones límite para asegurar que el módulo funciona correctamente en los límites establecidos. Se ejercitan todos los caminos independientes de la estructura de control con el fin de asegurar que todas las sentencias del módulo se ejecutan por lo menos una vez. Y, finalmente, se prueban todos los caminos de manejo de errores. Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del módulo. Si los datos no entran correctamente, todas las demás pruebas no tienen sentido. Además de las estructuras de datos locales, durante la prueba de unidad se debe comprobar el impacto de los datos globales sobre el módulo.

A continuación, se deben ensamblar o integrar los módulos para formar el paquete de software completo. La prueba de integración es una técnica sistemática que permite construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción. El objetivo es juntar los módulos probados mediante la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño. Se combinan todos los módulos por anticipado. Se prueba todo el programa en conjunto. Se encuentra un gran conjunto de errores. Una vez que se corrigen esos errores aparecen otros nuevos y el proceso continúa en lo que parece ser un ciclo sin fin.

Después que el software se ha integrado, se dirigen un conjunto de pruebas de alto nivel. Se deben comprobar los criterios de validación establecidos durante el análisis de requisitos. La prueba de validación proporciona una seguridad final que el software satisface todos los requisitos funcionales, de comportamiento y de rendimiento. Durante la validación se usan exclusivamente técnicas de prueba de caja negra.

El software, una vez validado, se debe combinar con otros elementos del sistema. La prueba del sistema verifica que cada elemento se ajusta de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propósito diferente, todas trabajan para verificar que se ha integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.

La prueba de regresión es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse que los cambios no han propagado efectos colaterales no deseados. Este tipo de prueba es la actividad que ayuda a asegurar que los cambios no introduzcan un comportamiento no deseado o errores adicionales. A medida que progresa la prueba de regresión, el número de pruebas de regresión puede crecer demasiado. Por lo tanto, el conjunto de pruebas de regresión debería diseñarse para incluir sólo aquellas pruebas que traten una o más clases de errores en cada una de las funciones principales del programa. No es práctico ni eficiente volver a ejecutar cada prueba de cada función del problema después de un cambio.

Cuando se construye un software a medida para un cliente, se llevan a cabo una serie de pruebas de aceptación para permitir que el cliente valide todos los requisitos. Estas pruebas las realiza el usuario final en lugar del responsable del desarrollo de sistema. Una prueba de aceptación puede ir desde un informal paso de prueba hasta la ejecución sistemática de una serie de pruebas bien planificadas.

El diseño de casos de prueba para el software o para otros productos de ingeniería puede requerir tanto esfuerzo como el propio diseño inicial del producto. Sin embargo, los Ingenieros de Software tratan las pruebas como algo sin importancia, desarrollando casos de prueba que “parezcan adecuados”, pero que tienen poca garantía de ser completos. Se deben diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y tiempo posible. Cualquier producto de ingeniería puede probarse de una de estas 2 formas: (1) prueba de caja negra y (2) prueba de caja blanca.

Cuando se considera el software de computadora, la prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. Los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, así como que la integridad de la información externa se mantiene.

La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el estado del programa en varios puntos para determinar si el estado real coincide con el esperado o mencionado. Para este tipo de prueba, se deben definir todos los caminos lógicos y desarrollar casos de prueba que ejerciten la lógica del programa.

El Aseguramiento de Calidad del Software (3) es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza que el software satisfará los requisitos dados de calidad. Este aseguramiento se diseña para cada aplicación antes de comenzar a desarrollarla y no después. El aseguramiento de la calidad del software engloba: (1) un enfoque de gestión de calidad, (2) métodos y herramientas de Ingeniería del Software, (3) revisiones técnicas formales aplicables en el proceso de software, (4) una estrategia de prueba multiescala, (5) el control de la documentación del software y de los cambios realizados, (6) procedimientos para ajustarse a los estándares de desarrollo del software y (7) mecanismos de medición y de generación de informes.

Este aseguramiento tiene asociado 2 constitutivos diferentes: los Ingenieros de Software que realizan el trabajo técnico y un grupo de SQA (Software Quality Assurance) que tiene la responsabilidad de la planificación de aseguramiento de la calidad, supervisión, mantenimiento de registros, análisis e informes.

Las Actividades del grupo de SQA son: (1) Establecimiento de un plan de SQA para un proyecto, (2) Participación en el desarrollo de la descripción del proceso de software del proyecto, (3) Revisión de las actividades de Ingeniería del Software para verificar su ajuste al proceso de software definido, (4) Auditoria de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software, (5) Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido, y (6) Registrar lo que no se ajuste a los requisitos e informar a sus superiores.

Además de estas actividades, el grupo de SQA coordina el control y la gestión de cambios y; ayuda a recopilar y analizar las métricas del software. Las métricas son escalas de unidades sobre las cuales puede medirse un atributo cuantificable. Cuando se habla de software nos referimos a la disciplina de recopilar y analizar datos basándonos en mediciones reales de software, así como a las escalas de medición. Los atributos son características observables del producto o del proceso de software, que proporciona alguna información útil sobre el estado del producto o sobre el progreso del proyecto. El término producto se utiliza para referirse a las especificaciones, a los diseños y a los listados del código. Los valores de las métricas no se obtienen sólo por mediciones. Algunos valores de métricas se derivan de los requisitos del cliente o de los usuarios y, por lo tanto, actúan como restricciones dentro del proyecto.

Las medidas de Calidad del Software deben comenzar desde la especificación y terminar con la implementación, implantación y mantenimiento o post-implantación. Debe aplicarse a lo largo de todo el proceso de Ingeniería de Software. Básicamente, la medición es una fase normal de cualquier actividad industrial Sin mediciones es imposible perseguir objetivos comerciales normales de una manera racional.

Existen métricas a nivel Proyecto, Proceso y Producto respectivamente. Las métricas a recabar dependen de los objetivos del negocio en particular. Los desarrolladores tienen a la vez objetivos comunes como, respetar el presupuesto y respetar los plazos, minimizar las tasas de defectos antes y después de la entrega del producto e intentar mejorar la calidad y la productividad. Las métricas deben ayudar a la evaluación de las representaciones del modelo lógico y físico, deben tener la capacidad de intuir sobre la complejidad del diseño y construcción; y deben ayudar en el diseño de casos de prueba.

La Mejora de la Calidad del Software (4) es la parte de la Gestión de la Calidad que contribuye, por medio de las mediciones, a los análisis de los datos y auditorias, a efectuar mejoras en la calidad del software.

Una Auditoria de Calidad tiene como objetivo mostrar la situación real para aportar confianza y destacar las áreas que pueden afectar adversamente esa confianza. Otro objetivo consiste en suministrar una evaluación objetiva de los productos y procesos para corroborar la conformidad con los estándares, las guías, las especificaciones y los procedimientos.

Los resultados de la auditoria son documentados y remitidos al director de la organización auditada, a la entidad auditora, y cualquier organización externa identificada en el plan de auditoria. El informe incluye la lista de elementos no conformes u otros aspectos para las posteriores revisiones y acciones. Cuando se realiza el plan de auditoria, las recomendaciones son informadas e incluidas en los resultados de la auditoria.

Para implementar un programa de mejoras es necesario definir procesos, decidir qué se quiere mejorar, definir qué medidas serán necesarias recoger, cómo y dónde tomarlas, gestionarlas mediante herramientas, utilizarlas para la toma de decisiones y reconocer las mejoras. Cuando el proceso a mejorar es el de desarrollo del software, es importante definir qué objetivos se quieren alcanzar, para reducir el número de medidas y, en consecuencia, el coste de recopilarlas y el impacto sobre la actividad de producción de software.

La calidad ha dejado de ser un tópico y es necesario que forme parte de los productos o servicios que comercializamos para nuestros clientes. El cliente es el mejor auditor de la calidad, él exige el nivel que está dispuesto a pagar por ella, pero no más. Por tanto, debemos de cuantificar cuál es el nivel de calidad que nos exige para poder planificar la calidad de los productos que se generen a lo largo de la producción del producto o servicio final. Al analizar las necesidades de nuestros clientes, deberemos tener en cuenta la previsible evolución de sus necesidades y tendencias en cuanto a características. Deberemos tener en cuenta la evolución tecnológica del entorno de producción de nuestros productos para suministrarlos con el nivel tecnológico adecuado. No debemos olvidar el nivel de calidad de nuestros competidores, debiendo elaborar productos cuyas características y funcionalidades sean competitivas con las de nuestros competidores.

La Calidad de Software es resultado del movimiento global dentro del proceso de mejoramiento continuo de los modelos y/o estándares de producción en todos los sectores industriales, en particular, cuando éste se concentra en la producción de sistemas de información y software especializado.

Gestión de la Configuración del Software

Generalidades

A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción del mismo, y posteriormente desde el inicio del mantenimiento hasta su retiro, se van realizando una serie de cambios, tanto en el código como en la documentación asociada. La Gestión de Configuración del Software es una disciplina encargada del control de la evolución de los productos de software.

Como todo proceso, la Gestión de Configuración también puede ser sistematizada y automatizada, lo que se denomina un Sistema de Gestión de Configuración (SGC). Actualmente existen en el mercado diversas herramientas que permiten apoyar una o más actividades de la Gestión de Configuración. 

Definiciones

Gestión de Configuración es el proceso de identificar y definir los elementos en el sistema, controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el estado de los elementos y las solicitudes de cambio, y verificando que los elementos estén completos y que sean los correctos.

El propósito de la Gestión de Configuración del Software es establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software. 

La Gestión de Configuración del Software implica la identificación de la Configuración del software en puntos dados en el tiempo, el control sistemático de los cambios en la Configuración y el mantenimiento de la integridad y trazabilidad de la Configuración a través del ciclo de vida del software. Los productos incluidos son:

Software distribuido al cliente.

Documentos de requerimientos del software.

Código.

Elementos requeridos para crearlos (ejemplo: el compilador)

Aspectos Funcionales 

1. Identificación: Se necesita definir un esquema de identificación para reflejar la estructura del producto, esto involucra identificar la estructura y clases de componentes, dando a cada uno un nombre, una identificación de versión y una identificación de Configuración.

2. Control: Se deben controlar los cambios que se le hacen a través del ciclo de vida, asegurando que el software sea consistente a través de la creación de una línea base del producto.

3. Estado: Se debe registrar y reportar el estado de los componentes y solicitudes de cambio.

4. Auditoria y revisión: Se debe validar que el producto este completo y se asi mantener la consistencia entre los componentes, asegurando que estén en un estado apropiado a través de todo el ciclo de vida del producto y que el mismo sea una colección bien definida de componentes.

Algunos conceptos presentes en la Disciplina Configuración

Las características funcionales y físicas de una versión especifica de hardware y elementos de software que combinados de acuerdo a procedimientos de construcción específicos cumplen un propósito particular. 

Elementos de configuración de software

Definimos como un elemento de Configuración a una unidad física y/o lógica parte de un conjunto mayor de elementos, producida o adquirida, que por sus características es distinguible de las demás y cuya evolución interesa administrar.

Son elementos de Configuración en un proyecto de software: 

01. El plan de proyecto.

02. El plan de Gestión de Configuración.

03. El documento de definición de requerimientos.

04. Estándares de análisis, diseño, codificación, pruebas, y auditoria.

05. Documentos de análisis del sistema.

06. Documentos de diseño del sistema.

07. Prototipos.

08. Documentos de diseño de alto nivel.

09. Documentos de diseño de bajo nivel.

10. Especificaciones de prueba del sistema.

11. El plan de pruebas del sistema.

12. El Código fuente del programa.

13. Código objeto y ejecutable.

14. Especificaciones de pruebas de unidad.

15. Planes de pruebas de unidad.

16. Documentos de diseño de base de datos.

17. Datos de prueba.

18. Datos del proyecto.

19 .Manuales de usuario. 

Cuestionarios Elaborados por:      

           MBA Tania Sequeira 

          Docente Universitaria

      Escuela de Ingenieria UPOLI

Respuestas Elaboradas por:     

     Ing. Enoc Misael Ramirez Godinez

¿QUE ES LA INGENIERIA EN SISTEMAS?

La ingeniería de sistemas es un modo de enfoque interdisciplinario que permite estudiar y comprender la realidad, con el propósito de implementar u optimizar sistemas complejos. Puede verse como la aplicación tecnologica de la teoria del a los esfuerzos de la ingeniria, adoptando en todo este trabajo el paradigma sistemico. La ingeniería de sistemas integra otras disciplinas y grupos de especialidad en un esfuerzo de equipo, formando un proceso de desarrollo centrado.Una de las principales diferencias de la ingeniería de sistemas respecto a otras disciplinas de ingeniería tradicionales, consiste en que la ingeniería de sistemas no construye productos tangibles. Mientras que los ingenieros civiles podrían diseñar edificios o puentes, los ingenieros electrónicos podrían diseñar circuitos, los ingenieros de sistemas tratan con sistemas abstractos con ayuda de las metodologias de la ciencias de sistemas, y confían además en otras disciplinas para diseñar y entregar los productos tangibles que son la realización de esos sistemas.

Otro ámbito que caracteriza a la ingeniería de sistemas es la interrelación con otras disciplinas en un trabajo transdisciplinario. La ingeniería de sistemas es la aplicación de las ciencias matemáticas y físicas para desarrollar sistemas que utilicen económicamente los materiales y fuerzas de la naturaleza para el beneficio de la humanidad.

Una definición especialmente completa -y que data de 1974- nos la ofrece un estándar militar de las fuerzas aéreas estadounidenses sobre gestión de la ingeniería (MIL-STD-499B Systems Engineering). Ingeniería de sistemas es la aplicación de esfuerzos científicos y de ingeniería para:

transformar una necesidad de operación en una descripción de parámetros de rendimiento del sistema y una configuración del sistema a través del uso de un proceso interactivo de definición, síntesis, análisis, diseño, prueba y evaluación;
integrar parámetros técnicos relacionados para asegurar la compatibilidad de todas las interfaces de programa y funcionales de manera que optimice la definición y diseño del sistema total;
integrarse factores de fiabilidad, mantenibilidad, seguridad, supervivencia, humanos y otros en el esfuerzo de ingeniería total a fin de cumplir los objetivos de coste, planificación y rendimiento técnico.Ingeniería de Sistemas es un conjunto de metodologías para la resolución de problemas mediante el análisis, diseño y gestión de sistemas.
Es el conjunto de recursos humanos y materiales a través de los cuales se recolectan, almacenan, recuperan, procesan y comunican datos e información con el objetivo de lograr una gestión eficiente de las operaciones de una organización.


Campos relacionadosMuchos de los campos relacionados podrían ser considerados con estrechas vinculaciones a la ingeniería de sistemas. Muchas de estas áreas han contribuido al desarrollo de la ingeniería de sistemas como área independiente.

Sistemas de InformaciónUn sistemas de informacion o (SI) es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. No siempre un Sistema de Información debe estar automatizado (en cuyo caso se trataría de un sistema informatico), y es válido hablar de Sistemas de Información Manuales. Normalmente se desarrollan siguiendo Metodologías de Desarrollo de Sistemas de Información....
El equipo computacional: el hardware necesario para que el sistema de información pueda operar. El recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas que utilizan el sistema. Un sistema de información realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y salida de información. es la actualización de datos reales y específicos para la agilizacion de operaciones en una empresa.

Investigación de operaciones La investigación de operaciones o (IO) se enseña a veces en los departamentos de ingeniería industrial o de matemática aplicada, pero las herramientas de la IO son enseñadas en un curso de estudio en Ingeniería de Sistemas. La IO trata de la optimización de un proceso arbitrario bajo múltiples restricciones.

  

¿Que hace un ingeniero de sistemas?

La tarea del ingeniero afecta a todos los aspectos de la producción de un software de calidad. Participa de la creación, producción, racionalización, diseño y control de sistemas, equipos e instalaciones informáticos. Tiene en cuenta todas las entidades que integran un sistema de computación (hardware, software, servicios y clientes) para apoyar los procesos de una organización.

Su propósito consiste en la aplicación de la tecnología a la construcción de equipos capaces de procesar y almacenar la información de manera automática.

Una de las principales diferencias de la ingeniería de sistemas respecto a otras disciplinas de ingeniería tradicionales, consiste en que la ingeniería de sistemas no construye productos tangibles. Mientras que los ingenieros civiles podrían diseñar edificios o puentes, los ingenieros de sistemas trabajan con elementos abstractos, con ayuda de las metodologías de la ciencia de sistemas, y confían además en otras disciplinas para diseñar y entregar los productos tangibles que son la realización de esos sistemas.

El ingeniero de sistemas es capaz de:

- Desarrollar, evaluar y optimizar software.

- Diseñar recursos computacionales.

- Crear modelos matemáticos, estadísticos y de simulación.

- Realizar investigaciones científicas, culturales y tecnológicas.

- Dirigir y coordinar grupos de trabajo.

- Evaluar e instalar equipos.

- Desarrollar la organización y arquitectura de equipos.

- Seleccionar y administrar el personal y el equipo de unidades de servicios de computación.

Ingeniería del Software de Sala Limpia

La Ingeniería del Software designa el conjunto de técnicas destinadas a la producción de un producto software, más allá de la sola actividad de programación. A su vez el software es el conjunto de instrucciones que permite al hardware de la computadora desempeñar trabajo útil. En los primeros años del presente siglo, las reducciones de costo en hardware llevaron a que el software fuera un componente que participa en muchos de los dispositivos usados por las sociedades industrializadas. Asimismo, se considera parte del software a la documentación generada durante el desarrollo del proyecto.

El modelo de métodos formales acompaña a un conjunto de actividades que conducen a la especificación matemática del software. Los métodos formales permiten que un Ingeniero especifique, desarrolle y verifique un sistema aplicando una notación rigurosa y matemática. Hay una variación, que se utiliza por algunos ingenieros del software conocida como:  Ingeniería del Software de sala limpia”. Cuando se utilizan métodos formales, se eliminan muchos de los problemas que son difíciles de superar con las metodologías habituales: la ambigüedad, la completitud y la inconsistencia se descubren y se corrigen de manera más sencilla, mediante la aplicación del análisis matemático.

La tecnología de dotación lógica de sala limpia es un acercamiento al desarrollo del software lógico, que mejora calidad y reduce costos. El acercamiento toma su nombre de los cuartos limpios usados en la fabricación de la precisión, donde las técnicas estadísticas del control de calidad acentúan la prevención del defecto concluido el retiro del defecto. Las mismas prácticas se pueden aplicar al desarrollo del producto software. En la tecnología de dotación lógica de sala limpia, el desarrollo incremental permite la mejora continua del proceso. Los equipos de diseño aplican el desarrollo y las técnicas de revisión basadas en métodos formales a los sistemas, obteniendo productos que son casi sin defecto incluso antes de realizar las respectivas pruebas. Los equipos de la prueba utilizan control de calidad estadístico para certificar la calidad del sistema, en términos significativos para el cliente.

La ingeniería del software de sala limpia es un enfoque formal para el desarrollo del software, que pueda dar lugar a un software con una calidad notablemente alta. Emplea la especificación de estructura de cajas para el modelado de análisis y diseño, haciendo hincapié en la erificación de la corrección, más que en la comprobación, como mecanismo fundamental para encontrar y eliminar errores. Se aplica una comprobación estadística de uso para desarrollar la información relativa a la tasa de fallos necesaria para certificar la fiabilidad del producto software. El resultado final es una tasa de fallo extremadamente baja, que sería difícil o imposible de conseguir empleando métodos menos formales.

Una vez asignada la 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.-Permite la calidad temprana y continua interacción con el usuario. Facilita mejoras de proceso mientras progresa el desarrollo. El acercamiento incremental evita los riesgos inherentes a la integración tardía en el ciclo de desarrollo.  Recolección de requisitos.- Define requisitos para el producto software, incluyendo función, uso, ambiente, y funcionamiento; la parte complementaria constituye el obtener un acuerdo con el cliente en los requisitos como base para la función y especificación de uso.

Especificación de la estructura de cajas.- Tres tipos especiales de funciones matemáticas son importantes en el desarrollo de 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 funcionalidad 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. Los participantes proporcionan los objetivos, 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, las cuales se aplican primero al diseño y después al código. El propósito del proceso de verificación de la corrección, es verificar la corrección del incremento asociado al producto de software utilizando 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 en un lenguaje de programación adecuado.

Planificación de la comprobación estadística.- El propósito es demostrar la aptitud del software para el uso en un experimento estadístico formal. Se la 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 el índice de confiabilidad del software.

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, al interior de la ingeniería del software de sala limpia, 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 de forma análoga a los objetos. En esta vista de especificación, se representan las entradas a 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.

La ingeniería del software de sala limpia se diferencia de otros métodos o paradigmas por las siguientes razones:

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.

INFORMÁTICA CLIENTE-SERVIDOR

---

 En el modelo cliente-servidor, los usuarios trabajan en computadoras denominadas sistemas frontales (front-end) e interaccionan con sistemas servidores denominados posteriores (back-end), que proporcionan servicios tales como el acceso a una base de datos, la gestión de red y el almacenamiento centralizado de archivos. Una red de computadoras ofrece la plataforma de comunicación en la que numerosos clientes pueden interactuar con uno o más servidores. La interacción entre la aplicación que ejecutan los usuarios en sus sistemas frontales y el programa (generalmente una base de datos o un sistema operativo de red) en el servidor posterior se denomina relación cliente-servidor. Esto implica que el usuario dispone de una computadora con su propia capacidad de procesamiento, que ejecuta un programa que puede efectuar la interacción con el usuario y la presentación de la información. Así, el modelo cliente-servidor reemplaza al paradigma de informática centralizada.

En el modelo de informática centralizada, los usuarios situados en terminales no inteligentes se comunican con computadoras anfitrionas (hosts). Todo el procesamiento tiene lugar en el anfitrión, y los usuarios únicamente escriben órdenes que envían a dicho anfitrión y observan el resultado en su monitor.· En el modelo de informática cliente-servidor, el sistema cliente ejecuta una aplicación que interacciona con otro programa que se ejecuta en el servidor.

 

El modelo cliente-servidor se aplica en sistemas operativos y aplicaciones. Los sistemas operativos de red, tales como NetWare de Novell están orientados a este modelo puesto que los usuarios situados en las estaciones de trabajo realizan peticiones a los servidores NetWare. El cliente ejecuta un programa que redirecciona las peticiones de obtención de los servicios de la red al servidor adecuado, además de enviar las peticiones de servicios locales al sistema operativo local. En los sistemas gestores de bases de datos que siguen el modelo cliente-servidor, los clientes realizan las consultas a través de una aplicación frontal que atienden los servidores.

En una relación cliente-servidor el procesamiento se divide entre las dos partes. El sistema cliente ejecuta una aplicación que muestra una interfaz de usuario. Da formato a las peticiones de los servicios de la red y muestra la información o los mensajes enviados por el servidor. El servidor realiza el procesamiento posterior, como por ejemplo una clasificación de datos o la realización de un informe. Debido a que los datos se encuentran perfectamente accesibles, el cliente realiza este proceso de forma eficiente. Después de la clasificación, realización del informe o de cualquier otra tarea solicitada por un usuario, el servidor envía los resultados al cliente. El tráfico en la red se reduce debido a que el cliente únicamente obtiene la información que solicitó, no todo el conjunto de datos para clasificar, según el ejemplo anterior.

Los servidores en un entorno cliente-servidor son a menudo potentes sistemas superservidores, minicomputadoras o computadoras centrales, capaces de gestionar adecuadamente las múltiples y simultáneas peticiones que reciben de los clientes, además de realizar tareas de seguridad y gestión de red. Algunas organizaciones han reemplazado sus computadoras centrales, que proporcionaban cinco millones de instrucciones por segundo (MIPS, million instructions-per-second), por un grupo de servidores capaces de ejecutar 1.000 MIPS. Las diversas estrategias cliente-servidor ofrecen una forma de crear plataformas informáticas relativamente asequibles y fáciles de configurar según las necesidades específicas de las aplicaciones.

El software de un sistema cliente-servidor habitualmente consiste en un sistema gestor de bases de datos (DBMS, database management system) instalado en un servidor posterior, hacia el que los clientes dirigen sus peticiones a través de un lenguaje de consulta estructurado (SQL, Structured Query Language). Es particularmente deseable disponer de un sistema de procesamiento de transacciones interactivo (OLTP, On-Line Transaction Processing) en el modelo cliente-servidor. Mientras que los servidores de archivo y los servidores de bases de datos son más comunes, un servidor posterior también puede proporcionar comunicaciones dedicadas y servicios de impresión.

 

 

Arquitectura cliente-servidor

La arquitectura cliente-servidor define una relación entre el usuario de una estación de trabajo (el cliente frontal) y un servidor posterior de archivos, impresión, comunicaciones o fax, u otro tipo de sistema proveedor de servicios. El cliente debe ser un sistema inteligente con su propia capacidad de procesamiento para descargar en parte al sistema posterior (ésta es la base del modelo cliente-servidor). Esta relación consiste en una secuencia de llamadas seguidas de respuestas. Situar servicios de archivos (u otro tipo de servicios) en sistemas posteriores dedicados tiene muchas ventajas. Es más sencillo realizar el mantenimiento y la seguridad de unos servidores situados en un mismo lugar, y más simple el proceso de realización de copias de seguridad, siempre que los datos se encuentren en una única ubicación y una misma autoridad los gestione.

Existen numerosas configuraciones cliente-servidor posibles. En la Figura 3.1, varios clientes acceden a un único servidor. Esta es la configuración usual de una pequeña red de área local (LAN, Local Area Network). La Figura 3.2 muestra un modelo de base de datos distribuida en el que los clientes acceden a los datos ubicados en varios servidores.

 

 En un entorno de red par a par, tal como Windows para trabajo en grupos de Microsoft, NetWare Lite, LANtastic de Artisoft o NFS (Network File System), las estaciones de trabajo pueden ser tanto clientes como servidores, según muestra la Figura 3.3. Un usuario puede compartir los archivos ubicados en su disco duro con otros usuarios de la red. Así, la estación de trabajo de dicho usuario se convierte en un servidor de otro cliente. Al mismo tiempo, nuestro usuario puede acceder como cliente a los archivos compartidos de otras estaciones de trabajo.

 

Estudiemos algo más estos modelos para observar las tendencias tanto actuales como futuras del modelo cliente-servidor. En la parte izquierda de la Figura 3.4 se representa la reproducción de una base de datos en un sistema remoto de modo que los usuarios de dicho sistema puedan acceder a los datos sin necesidad de establecer un enlace a través de una red de área extensa (WAN). Los dos servidores se sincronizan periódicamente entre ellos para asegurarse de que los usuarios trabajan con información actualizada. En la parte derecha de la misma figura se representa el almacenamiento de grandes volúmenes de información de una empresa en un «almacén de datos». Los grupos de trabajo normalmente no acceden directamente a dicho almacén aunque esto sea posible. En lugar de ello, existe un sistema de apoyo que accede y almacena los bloques de datos usados más comúnmente por los usuarios del grupo de trabajo. Esta acción produce una reducción del tráfico en la red corporativa y garantiza el acceso del grupo de trabajo a los datos utilizados más frecuentemente. Al mismo tiempo, el almacén de datos proporciona la gestión, realización de copias de seguridad y otras de las ventajas del almacenamiento centralizado. 

 La exposición anterior asumía que el cliente es compatible a nivel de aplicaciones con el servidor, aunque ésta no es la única posibilidad si se tiene en cuenta la construcción de una red corporativa sobre LANs departamentales ya existentes. Existen dos modelos de compartición de datos dentro de un entorno corporativo, según se muestra en la Figura 3.5.

 

 En la parte izquierda se representa la utilización de una pasarela, que realiza la conversión de las peticiones de una serie de clientes a los formatos reconocidos por servidores no compatibles.· En la parte derecha se ilustra la instalación de un nivel de protocolo común normalizado que actúa de interfaz entre los clientes no compatibles con los servidores. Numerosos fabricantes adoptan este enfoque.

   

Internamente, el cliente y el servidor se dividen en varios procesos, representados en la Figura 3.6. Hay que tener en cuenta que el software de redirección de los clientes determina si las peticiones de los clientes van dirigidas hacia un servicio local o hacia un servidor de la red. En función del sistema operativo y/o de la aplicación, existen variaciones en la cantidad de trabajo que realiza el servidor. En algunos casos, el servidor realiza el menor trabajo posible con objeto de optimizar sus prestaciones hacia un grupo de clientes en aumento continuo. En otros casos, el servidor trabaja con toda su potencia y gestiona la mayor parte de la carga de procesamiento.

 

En la mayoría de las configuraciones, la comunicación se efectúa sobre la LAN. Los servidores pueden formar parte de un departamento o grupo de trabajo local, o bien localizarse en una zona centralizada de acceso de la organización completa. Estos servidores de acceso centralizado se denominan servidores de empresa. Los servidores también pueden situarse en lugares remotos de modo que los usuarios deben acceder a ellos a través de un enlace de telecomunicaciones. En función del tipo de enlace utilizado, el tiempo de respuesta entre el cliente y el servidor remoto puede ser considerable, lo que necesitarán tener en cuenta los responsables del sistema. Si no se necesita acceso en tiempo real, pueden utilizarse técnicas de mensajería, a través de las cuales un usuario envía su petición al servidor y éste último responde en forma de un mensaje que se deposita en el buzón del cliente. La respuesta puede llegar en segundos, minutos o incluso horas, en función del tipo de conexión y de las restricciones impuestas por los diseñadores del sistema.

 

 

Ventajas de la arquitectura cliente-servidor

A continuación se enumeran algunas de las ventajas del modelo cliente-servidor:

· El modelo cliente-servidor ayuda a las organizaciones a redimensionarse a partir de sus computadoras centrales y minicomputadoras hacia servidores y estaciones de trabajo sobre LANs, que se constituyen así como plataforma de comunicaciones corporativa.

·La carga de trabajo asociada a las aplicaciones se divide entre las distintas computadoras. Los sistemas cliente realizan parte del procesamiento, que se distribuye sobre todos los sistemas de escritorio.

· Los sistemas servidores realizan la distribución de la información centralizada hacia unidades de almacenamiento conectadas directamente a ellos, reduciéndose así la información enviada a través de la red.

· Un porcentaje importante de información se ubica directamente en la memoria del servidor, no en la memoria de cada estación de trabajo que lo necesite.

· El tráfico en la red se reduce, ya que el servidor envía al cliente únicamente la información solicitada, no grandes bloques de información que deba procesar.

· Los grandes sistemas servidores pueden descargarse de aplicaciones que se gestionan mejor en estaciones de trabajo personales.

· Los datos están más seguros si su ubicación es única. Los sistemas de almacenamiento de datos proporcionan una forma de suministrar datos específicos a servidores de grupos de trabajo, al mismo tiempo que mantienen control sobre aquéllos.

· En un almacenamiento centralizado de datos, los administradores pueden aplicar controles de seguridad para restringir el acceso a los mismos y utilizar mecanismos de supervisión de dicho acceso.

· El entorno cliente-servidor favorece el procesamiento paralelo múltiple. En este esquema, numerosas computadoras cooperan para realizar una tarea de procesamiento de forma conjunta. Cada sistema realiza una parte de la tarea, combinándose los resultados. La tarea se completa más rápidamente que si fuera realizada por un sistema autónomo. 

El modelo cliente-servidor en sistemas operativos autónomos

Así como el modelo cliente-servidor se trata habitualmente en términos de sistemas frontales y posteriores conectados a una red, puede aplicarse además al diseño arquitectural de la mayoría de sistemas operativos modernos. Por ejemplo, Windows NT de Microsoft implanta el modelo cliente-servidor como método estándar de interacción entre el usuario y el sistema operativo. El proceso servidor consiste en un núcleo en segundo término que trabaja con funciones de bajo nivel, como la planificación de tareas y la sincronización de procesos. El sistema frontal constituye la interfaz de usuario, el sistema de archivos y la aplicación que ejecuta el usuario. Esta estrategia proporciona un enfoque modular de los sistemas operativos. Por ejemplo, permite la conexión a un sistema de archivos DOS, Windows u OS/2, según las necesidades o preferencias. El núcleo posterior no depende de un sistema operativo concreto, ya que posee una interfaz común a través de la que ofrece sus servicios.

 

 

Implantación de aplicaciones cliente-servidor

En un entorno distribuido de red, el objetivo es proporcionar datos de forma compartida a todos los usuarios de la organización. Los datos almacenados en numerosos sistemas diferentes se hacen accesibles a los clientes, de forma que idealmente adoptan el aspecto de una única base de datos lógica. La realización de un entorno compartido de datos engloba normalmente las siguientes funciones:

· Medidas de seguridad necesarias para el control del acceso a los datos.

· Medidas de integridad, requeridas para asegurar que las transacciones se realizan o no en función de su corrección.

· Medidas de concurrencia y disponibilidad, necesarias para permitir a los usuarios acceder y actualizar los datos.

· Necesidad de seguridad y recuperabilidad de los datos, mediante copias de seguridad y utilidades de tolerancia a fallos. 

Se debe realizar cada una de estas funciones si se trata de compartir datos entre muchos usuarios en la organización. Considérense las siguientes situaciones:

· ¿Qué clientes realizan una simple lectura de los datos en un servidor, y cuáles realizan lectura y escritura?

· Si dos usuarios acceden a los mismos datos de forma simultánea y uno de ellos efectúa modificaciones sobre aquéllos, ¿debería obtener el otro usuario una actualización? ¿Esto es factible?

· Cuando varios usuarios manipulan los mismos datos, ¿cuál es la operación de escritura que debe tener prioridad?   

Las soluciones a estos problemas se encuentran realizadas en la mayoría de los sistemas cliente-servidor, aunque la distribución de los datos entre un grupo numeroso de servidores dentro de una empresa plantea problemas insuperables de logística que hacen impracticable en muchos sistemas el acceso en tiempo real a los mismos datos por varios usuarios de forma simultánea. Los mecanismos de bloqueo pueden impedir el acceso de un usuario a un bloque de registros hasta que otro usuario haya finalizado la realización de cambios, si bien esta solución introduce sus propios problemas. Por ejemplo, dentro de un entorno sensible al tiempo, esperar que otro usuario libere un bloque de registros es impracticable. Una serie de actualizaciones parciales puede ayudar al servidor a mantener una traza de las modificaciones efectuadas. Si existe un grupo numeroso de usuarios que trabajan con el mismo bloque de datos, se necesitan métodos para que los clientes sepan cuándo otro usuario ha modificado los datos. Existen dos técnicas:

· Los clientes comprueban periódicamente con el servidor si los datos ubicados en su memoria se han modificado por otro usuario. Este método crea un tráfico excesivo en la red.

· El servidor envía actualizaciones a los clientes cuando los datos a los que éstos tienen acceso se modifican por uno de ellos. 

 

Los servidores deben proporcionar acceso a los datos paro también preocuparse de la concurrencia en dicho acceso. En los sistemas distribuidos, estos problemas se multiplican si existen bases de datos interdependientes sobre varios sistemas. Pueden utilizarse varios métodos para mantener sincronizados los sistemas, aunque esto puede añadir retardos. ¿Qué sucede si uno de los servidores sufre una caída durante una operación de escritura? La información que contiene dicho servidor debe actualizarse durante el proceso de arranque del mismo. Además, las transacciones incompletas deben volver atrás, no únicamente en el servidor afectado por la caída, sino en todos aquellos que hubieran recibido la transacción para mantener la sincronización. 

  

 Métodos de conexión y comunicaciones

El mecanismo actual de transmisión de la información entre sistemas cliente y servidor en entornos distribuidos multiproveedor se denominamiddleware. Existe una amplia variedad de estos productos, como por ejemplo sistemas de mensajería de almacenamiento y reenvío y llamadas a procedimientos remotos (RPCs, remote procedure calís):

· Una llamada a un procedimiento remoto (RPC) consiste en una llamada que conecta dos computadoras a través de una conexión síncrona. Esta conexión se mantiene para asegurar la integridad de los datos entre los dos sistemas en tiempo real. Este tipo de conexión es esencial en aplicaciones tales como las transacciones bancarias.

· En un sistema de paso de mensajes, la información y las peticiones se envían entre las computadoras de la misma forma que los mensajes de correo electrónico entre usuarios. El mensaje se almacena y reenvía a lo largo de todo un trayecto hasta su destino. Aunque los sistemas de mensajes no son adecuados para la actualización de bases de datos en tiempo real, proporcionan servicios de lectura de información eficientes.

La Arquitectura de sistemas abiertos de Windows (WOSA, Windows Open System Architecture) de Microsoft constituye una estrategia de construcción de middleware directamente dentro de los sistemas operativos de Microsoft, de modo tal que la información fluya más fácilmente a través de una compañía. Los sistemas clientes pueden conectarse a diversos servicios posteriores, tales como bases de datos, comunicaciones, aplicaciones y servidores de correo. En Windows NT de Microsoft, las RPCs se incorporan directamente dentro del sistema operativo.IBM y otros fabricantes cuentan con el Entorno de informática distribuida (DCE, Distributed Computing Environment) de la Fundación de software abierto (OSF, Open Software Foundation) para apoyar la integración de aplicaciones distribuidas multiproveedor. DCE proporciona un extenso conjunto de servicios a través de los cuales las aplicaciones pueden comunicarse y los usuarios pueden conectarse a los diversos servicios de datos disponibles en una red corporativa.

 

 

LLAMADA A PROCEDIMIENTO REMOTO (RPC)

La comunicación entre procesos (IPC, Interprocess Communications) es una técnica que usan los programas y procesos que se ejecutan sobre sistemas operativos multitarea o sobre dos computadores en red. Hay dos tipos de IPCs:

· Llamada a procedimiento local (LPC, Local Procedure Call). Las LPCs se usan en sistemas operativos multitarea para permitir la ejecución concurrente de tareas que se pasan información. Así pueden compartir espacios de memoria, sincronizar tareas y enviar mensajes de una a otra.

· Llamada a procedimiento remoto (RPC, Remote Procedure Call). La RPC es similar a la LPC, pero trabaja sobre redes. Las primeras RPCs aparecieron en las computadoras de Sun Microsystems, Inc. y Hewlett-Packard, y se ejecutaban bajo el sistema operativo UNIX. 

Con las IPCs y las RPCs, los programas pueden beneficiarse de procesos manejados por otros programas o computadoras. La informática de cliente-servidor usa las RPCs como un mecanismo de comunicación entre sistemas, junto con otras técnicas como la mensajería. Los clientes realizan algunas tareas por sí mismos, pero delegan en servidores el acceso a archivos posteriores (back-end). Las RPCs proporcionan el mecanismo de comunicación para que el cliente requiera los servicios del servidor posterior (back-end), como se ve en la Figura 3.7. Si se piensa en una aplicación cliente-servidor como en un programa que ha sido escindido, el servidor podría realizar la parte de acceso a los datos porque está más próximo a ellos y el cliente podría ejecutar la parte frontal (front-end) de presentar los datos e interactuar con el usuario. Desde este punto de vista, se puede considerar a la RPC como la componente que reintegra a través de la red las partes divididas del programa. En ocasiones las RPCs reciben el nombre de mecanismos de acoplamiento.

 

Mediante este tipo de división de un programa, se evita el tener que copiar toda la base de datos, o la mayor parte de ella, al sistema del usuario cada vez que éste necesita acceder a los datos. En vez de eso, el servidor puede simplemente procesar la petición, e incluso realizar algunos cálculos sobre los datos, y luego enviar el producto final al usuario. Además, este proceso permite que más de un usuario acceda a los mismos datos a la vez, puesto que la sincronización con la base de datos se hace más sencilla si el dato se gestiona en una única localización.

Los entornos de informática distribuida son colecciones de computadoras conectadas mediante un sistema de comunicación la red. Es fácil ver esta red como una plataforma de computación, en la cual cualquiera de las computadoras presentes puede ser un cliente o un servidor, dentro de un acuerdo entre pares. Los programas individuales podrían enviarse a computadores que estuviesen más capacitados para ejecutarlos, mientras que el procesamiento de algunas tareas podría separarse en rutinas, que se ejecutarían en paralelo en varios computadores diferentes de la red. Esta estrategia emplea los recursos de las computadoras que están desocupadas y es un motivo más para invertir en una red. Una típica red extendida por una corporación, consta de muchos sistemas de computadoras distintas que ejecutan diferentes sistemas operativos.

Como las redes corporativas ya son una realidad, los programadores deben crear software ejecutable en una extensa gama de computadores y con distintos protocolos de comunicación de red. Esto significa que los programadores no necesitan preocuparse por la red subyacente o del protocolo usado para transportar los datos por dicha red. La siguiente sección describe las RPCs, en relación con el modo en que las implementa el Entorno de informática distribuida(DCE, Distributed Computing Environment) de la Fundación de software abierto (OSF, Open Software Foundation). Las RPC de la OSF están diseñadas para que operen en entornos heterogéneos de informática distribuida.

Está muy difundido el uso del protocolo Informática de red abierta (ONC, Open Network Computing) Llamada a procedimiento remoto/Representación de los datos externos (RPC/XDR, Remote Procedure Call/External Data Representation). De los 31 millones de sistemas que ejecutan el Sistema de archivos en red (NFS, Network File System), cerca de 28 millones también usan la biblioteca ONC RPC y pueden actuar como clientes o servidores de aplicaciones distribuidas. Todos los sistemas operativos de IBM excepto el OS/400 soportan ONC RPC. Los laboratorios UNIX System incluyen RPC/XDR como una parte normalizada del UNIX System V Release 4. Novell soporta la tecnología de nueva generación ONC + Llamada a procedimiento remoto independiente del transporte (TI-RPC, Transport Independent Remote Procedure). TI-RPC usa el Interfaz de nivel de transporte (TLI) para transportar las interdependencias. TLI proporciona un modo muy extendido de acceso a los servicios de transporte orientados o no a conexión.

 

Las RPC de la Fundac¡ón de software abierto (0SF)

Las herramientas RPC proporcionan un lenguaje de programación y un compilador para el desarrollo de aplicaciones modulares que se ejecutan tanto en sistemas clientes como en sistemas servidores del mismo modo que si fuesen procedimientos locales. Una facilidad en tiempo de ejecución permite que aplicaciones distribuidas se ejecuten en múltiples, heterogéneos sistemas, debido a que hace que las arquitecturas subyacentes y los protocolos sean transparentes a la aplicación.

El programador crea una definición de interfaz mediante un Lenguaje de definición de interfaces (IDL). IDL es una herramienta que usan los programadores para especificar procedimientos diseñados para que se ejecuten de forma remota. El compilador del IDL traduce la definición que se ha hecho en IDL del interfaz a fragmentos que están ligados tanto al cliente como al servidor. En la posición del cliente, el fragmento «permanece a la espera» del procedimiento servidor, y en la posición del servidor, el fragmento «permanece a la espera» del procedimiento cliente. Una facilidad en tiempo de ejecución de las RPCs, es que localizan al cliente y al servidor para que trabajen de acuerdo con los fragmentos para la realización de operaciones de RPC.

Uno de los problemas que se plantean con el uso de las RPCs en entornos heterogéneos, es que las diferentes máquinas representan los datos de forma diferente. Las OSF RPC evitan en cierto modo este problema mediante el etiquetado de las llamadas con la descripción de la representación de datos básica de la máquina que realiza la llamada. Cuando se recibe una llamada, y si la etiqueta indica que las dos máquinas representan de manera diferente los datos, el receptor convierte los datos.

La facilidad en tiempo de ejecución de las RPCs proporciona el mecanismo necesario para la transferencia de peticiones de los clientes a los servidores y para la recepción de respuestas a través de la red. La facilidad en tiempo de ejecución de las DCE RPCs también interactúa con otros servicios DCE de la red, como los servicios de nomenclatura, seguridad y tiempo. Dicha facilidad tiene las siguientes características:

·Se puede ejecutar en muchas redes diferentes. Los programadores no tienen que reescribir las aplicaciones para cada red.

· Proporciona recuperación de fallos tanto en la parte del cliente como en la del servidor, así como en la red. Soporta sistemas de archivos, bases de datos y otros servicios que transmiten datos de longitud variable.

·Proporciona un método basado en nombres para la localización de servidores, que es independiente de cualquier servicio de directorios en particular.

·Proporciona un interfaz para una facilidad de seguridad que protege la comunicación RPC de las intromisiones. El servicio de seguridad garantiza la privacidad de la información confidencial y protege la integridad de la comunicación mediante autentificación.

·Soporta el multihilado para el procesamiento concurrente o paralelo en la red, de manera que una aplicación puede realizar muchas acciones simultáneamente.

· Proporciona portabilidad e interoperabilidad con entornos de diferentes vendedores. 

Ingeniería Web

       El área actualmente desarrolla tres líneas de investigación:

• Modelado Conceptual de Aplicaciones Web 
• Personalización
• PKI y Firma Digital 

Modelado Conceptual de Aplicaciones Web

Uno de los principales problemas con los que se encuentran actualmente las empresas de desarrollo de software y los departamentos de informática de grandes empresas (como bancos, construcción, comercio electrónico, ...)  es que disponen de un parque complejo de programas software ya instalados y en funcionamiento que están restringidos por aspectos relacionados con la plataforma (hardware), sistema operativo, etc. para ser utilizados on-line. En este contexto, cualquier intento de ofrecer la funcionalidad de estos programas a través de Internet es claramente inviable. Además es también impensable que las empresas vuelvan a desarrollar de cero sus aplicaciones para adecuarlas a las nuevas tecnologías debido principalmente a la gran inversión ya realizada previamente en estos programas y los esfuerzos ya realizados en mejorar la robustez de los mismos. Sin embargo, las empresas cada día son más conscientes de la influencia de la red Internet en el modelo de aplicación software. Las tendencias indican que el antiguo modelo de vender software va en detrimento, mientras que el concepto de ofrecer aplicaciones software como servicios en la red, está tomando mayor relevancia.

Para que este cambio pueda producirse de una forma escalonada y preservando la funcionalidad ya desarrollada en las empresas hacen falta métodos y herramientas que permitan ‘adaptar’ lasaplicaciones existentes a Internet. De esta manera las empresas podrán utilizarlas y tendrán plena disponibilidad de ellas en la red, preservando por tanto las inversiones previamente realizadas en software.

El método OO-H (Object-Oriented Hypermedia) y su herramientaCAWE (Computer-Aided Web Engineering) asociada, es nuestra respuesta en esta área de investigación. Mas detalles...

Personalización 

La mayoría de los métodos, técnicas y procesos ingenieriles que pertenecen a la Ingeniería Web intentan hacer más sencilla la comprensión, desarrollo, evolución y mantenimiento de una aplicación web. Esto ha supuesto en muchos casos la extensión de técnicas aplicadas en la ingeniería del software ’tradicional’ con nuevos constructores y vistas hipermediales que abordan el problema de la navegación/presentaci´on del usuario a través del espacio de información.

En este contexto, una de las características que más interés está suscitando en la comunidad científica es cómo tratar adecuadamente nuevas necesidades web, como la identificación de perfiles que modelan los distintos tipos de usuarios, incluyendo estrategias tanto estáticas como dinámicas. La mayoría de los trabajos en este campo han estado centrados en proporcionar soluciones de implementación ad-hoc para dominios muy concretos. A nivel de modelado conceptual sólo las características de personalización estática han sido tratadas por algunos métodos mediante la incorporación de perfiles de usuario en diagramas de navegación.

En esta línea de investigación trabajamos en extensiones sobre OO-H para modelar las aplicaciones web con soporte de personalización dinámica. Más detalles...

PKI y Firma Digital

El carácter abierto de Internet  constituye su principal fortaleza como medio de explotación de la nueva generación de aplicaciones software. Sin embargo, tal fortaleza es también su principal vulnerabilidad: al ser una red abierta, las comunicaciones son más difíciles de proteger. Por ello resulta fundamental desarrollar los mecanismos que garanticen un nivel adecuado de seguridad, y generen las condiciones de confianza suficientes para alcanzar un alto grado de aceptación así como la validez legal necesaria.

Para conseguir una seguridad efectiva, necesitamos de métodos y herramientas que combinen adecuadamente las tareas de modelado conceptual de aplicaciones web con los fundamentos sobre los se basa la infraestructura de clave pública (PKI a partir de ahora). Estas son:

• La autenticación: Debemos asegurarnos que los emisores y receptores de la información (en nuestro caso todos los datos y la documentación relativos a la aplicación) son, efectivamente, quienes dicen ser.

• La integridad de la información: Que asegure que la información remitida llega realmente a su destino previsto, y que durante la transmisión no haya sido alterada accidental o intencionadamente

• La privacidad: Que garantice que la información enviada sólo pueda ser leída o utilizada por quien esté legitimado para ello.

• El no repudio: Que pueda asegurar al remitente que su información ha llegado a su destino, y al receptor la identidad del remitente, de forma que resulte imposible a cada parte negar posteriormente su participación en la comunicación entre ambas.

• La datación: Para poder demostrar que la transacción ocurrió en la fecha y hora en que  realmente sucedió.

• El acceso: Para impedir que personas no autorizadas accedan a la información.

Actualmente, ya existen en España varias empresas y Administraciones que proveen de servicios de PKI sobre los que desarrollar aplicaciones de Comercio Electrónico.

Nuestros trabajos en esta línea están enfocados a integrar dentro de OO-H  extensiones que permitan obtener aplicaciones web compatibles con los estándarés del PKI actuales. Más detalles...