Sistemas operativos de tiempo real

Los Sistemas Operativos de tiempo real son aquellos en los cuales no tiene importancia el
usuario, sino los procesos. Por lo general, estn subutilizados sus recursos con la finalidad de
prestar atencin a los procesos en el momento que lo requieran. Se utilizan en entornos donde
son procesados un gran nmero de sucesos o eventos.
Muchos Sistemas Operativos de tiempo real son construidos para aplicaciones muy especficas
como control de trfico areo, bolsas de valores, control de refineras, control de laminadores.
Tambin en el ramo automovilstico y de la electrnica de consumo, las aplicaciones de tiempo
real estn creciendo muy rpidamente. Otros campos de aplicacin de los Sistemas Operativos de
tiempo real son los siguientes:
1.

Control de trenes.

2.

Telecomunicaciones.

3.

Sistemas de fabricacin integrada.

4.

Produccin y distribucin de energa elctrica.

5.

Control de edificios.

6.

Sistemas multimedia.

Clasificacin de los sistemas en tiempo real

Tiempo Real Firme: tiempo real suave, y adems el sistema no obtiene beneficios de la prdida
ocasional de especificaciones temporales.
Tiempo Real Real: tiempo real duro y adems los tiempos de respuesta deben ser muy cortos.
Tiempo Real Suave: se permite que se pierdan ocasionalmente algunas especificaciones
temporales, aunque debe cumplirlas normalmente. Se especifican valores probabilsticos (medias,
etc.).
Tiempo Real Duro: es absolutamente imperativo que la respuesta del sistema a eventos externos
ocurra dentro del tiempo especificado. Si no, catstrofe (muertes, accidentes graves, etc.)
No-Distribuidos (una sola mquina) o Distribuidos (mltiples mquinas interconectadas).

Caractersticas de los sistemas en tiempo real

1) Concurrencia: se componen de un conjunto de actividades realizndose en paralelo: el mundo
real es concurrente, as que los S.T.R. deben serlo. Adems, es necesaria para tratar con mltiples
bucles de control simultneamente.
2) Dependencia del Tiempo: se ejecutan tareas en respuesta a seales externas, o peridicamente.

3) Fiabilidad y Tolerancia a Fallos: deben funcionar an en presencia de fallos o averas parciales

(normalmente mediante elementos redundantes), ya que es imposible prever completamente el
comportamiento del mundo real.
4) Interaccin con el Hardware: para la conexin de la CPU con el exterior. Interacciones activas y
pasivas:
Activa, el sistema decide cundo accede al exterior o cundo el exterior puede devolver
informacin. A travs de Interfaces de Entrada y Salida.
Pasiva, el sistema es interrumpido en el momento en que el exterior tenga algo que decir. A travs
de interrupciones, que pueden ser Simples o Mltiples.

5) Manipulacin de Nmeros Reales: adquiridos del exterior mediante interfaces.

6) Eficiencia: es deseable una implementacin eficiente (que consuma pocos recursos), sobretodo
en sistemas empotrados, debido al pequeo tamao y al deseable ahorro de costes.
7) Complejidad: suelen ser complejos y por lo tanto es deseable usar tcnicas modulares. Entra en
conflicto con la eficiencia.
8) Involucran todos los aspectos de la Ingeniera Informtica: el tiempo real debe estar
contemplado en el Hw (CPU, circuitera, redes) y en el Sw (S.O., lenguajes, aplicaciones).
-Tolerancia a Fallos (excepciones, multiproceso, etc.)
-Proteccin de Memoria para Concurrencia
-Relojes de Tiempo Real y Temporizadores
-Proceso en Coma Flotante (Nmeros Reales)
Requisitos Generales del Hardware: Controladores de Interrupciones
-Interfaces de E/S
-Tolerancia a Fallos (excepciones, redundancia, etc.

Calidad del software

La calidad del software es una preocupacin a la que se dedican muchos esfuerzos. Sin
embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir
software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los
usuarios.
En el desarrollo de software, la calidad de diseo acompaa a la calidad de los requisitos,
especificaciones y diseo del sistema. La calidad de concordancia es un aspecto centrado
principalmente en la implementacin; Si la implementacin sigue al diseo, y el sistema resultante
cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.
El software es un producto inmaterial que no se fabrica, tampoco se degradan fsicamente, sino
que se desarrolla. El software puede tener errores, incidencias pero no son similares a lo que
cualquier equipo de carcter fsico.
La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente detrs
debido a que la calidad tradicional tiene varias dcadas de historia, mientras que la calidad de
software tiene entre 50 y 30 aos de haber surgido.

Confiabilidad
Es la probabilidad de operacin libre de fallas de un programa de computadora en un
entorno determinado y durante un tiempo especfico, el fallo es cualquier no concordancia con los
requerimientos del software. Hay distintos grados de fallos, estos pueden ser simplemente
desconcertantes o catastrficos.
La confiabilidad del software se encuentra en un etapa de formacin de desarrollo y es la
caracterstica de rendimiento ms costosa de conseguir y difcil de conseguir y de difcil de
garantizar. La naturaleza del proyecto ayuda para la formulacin de estimaciones de costo y el
esfuerzo que asegure la confiabilidad requerida.
Los modelos de confiabilidad del software se usan para caracterizar y predecir el comportamiento
importante para directores e ingenieros.
La generacin de fallos depende del cdigo desarrollado, tales como tamao y las caractersticas
del proceso de desarrollado tales como las tecnologas y herramientas de ingeniera de software
usadas.
La eliminacin de fallos depende del tiempo y del perfil operativo. Los modelos de confiabilidad
del software son generalmente procesos aleatorios. Estos modelos se pueden dividir en 2 grandes
categoras:
1- modelos que predicen la confiabilidad como una funcin cronolgica del tiempo

2- modelos que predicen la confiabilidad como una funcin del tiempo de procesamiento
transcurrido

Control de Calidad

El costo de corregir y detectar errores producidos en las primeras fases de desarrollo de

software es mayor a medida que nos encontramos ms alejados de stas. A causa de esto, la
propuesta de control de calidad es empujar las tareas relacionadas con la calidad desde las
primeras fases del proyecto. Esto permite encontrar los errores en forma temprana sin que se
sigan propagando en las siguientes fases.
Otro motivo para el control de calidad es que la prueba de software no puede garantizar que
encuentre todos los errores. Los programadores profesionales pueden y deben producir software
el cual est libre de errores desde el comienzo. Esto puede ser llevado a cabo a travs del control
de calidad.
La garanta de calidad de software engloba:
1- mtodos y herramientas de anlisis, diseo, codificacin y prueba
2- revisiones y tcnicas formales que se aplican en cada fase de la ingeniera de software
3- una estrategia de prueba multiescalada
4- el control de la documentacin del software y de los cambios efectuados
5- un procedimiento que asegure un ajuste a los estndares de desarrollo
6- mecanismos a medida y de informacin
Revisiones de tcnicas formales:
- Objetivos
1- descubrir errores en la funcin, la lgica o la implementacin del software
2- verificar que el software bajo revisin alcanza sus requerimientos
3- garantizar el uso de estndares predefinidos
4- conseguir que el software se desarrolle de forma uniforme
5- hacer que los proyectos sean ms manejables
Directrices de la revisin:
1- revisar el producto no productor
2- fijar agenda y mantenerla
3- enunciar problemas no resueltos

4- limitar el debate y las impugnaciones

5- tomar notas
6- limitar el nmero de participantes
7- desarrollar una lista de comprobaciones para cada producto que pueda ser revisado
8- disponer de recursos y planificacin de tiempos
9- entrenar los participantes
10- reparar las revisiones anteriores

Planificacin y estndares de la garanta de calidad de software

Tareas que se deben llevar a cabo en un plan de GCS:
1- revisin del diseo del sistema
2- revisin de requerimientos de software
3- revisin del diseo preliminar
4- revisin del diseo detallado (a nivel mdulos)
5- revisin del plan de prueba de integracin
6- revisin del cdigo
7- revisin de los procedimientos
8- auditoras de los estndares de documentacin
9- auditoras del control de configuracin
10- auditoras de prueba

Ingeniera del software orientada a objetos

Este mtodo proporciona un soporte para el diseo creativo de productos de software, inclusive a
escala industrial. El autor plantea el problema del diseo y construccin de software haciendo una
comparacin con la industria de la construccin, contemplando las siguientes fases:
Herramientas. Soportan todos los aspectos de la empresa, explcitamente las actividades de
arquitectura, mtodos y procesos.
Procesos. Permite el escalamiento de los mtodos, de tal forma que puedan ser aplicados a
proyectos de forma interactiva y en partes.
Mtodos. Establece de manera explcita los procedimientos etapa por etapa que deben seguirse
para aplicar la arquitectura al proyecto.
Arquitectura. Una buena estructura del sistema es fcil de entender, de cambiar y realizar
pruebas y mantenimiento. Las propiedades del sistema determinan como la arquitectura debe ser
tratada durante el tiempo de vida. Las propiedades de la arquitectura son extremadamente
importantes y forman la base del mtodo.

Diseo creativo
Las actividades creativas de un desarrollo, consisten en la transformacin de un conjunto
de requerimientos y nociones vagas, en un plan estructurado de construccin y un plan de accin
para su implementacin.
El diseo creativo tomando como referencia una base arquitectnica es seguir paso a
paso los mtodos y procesos con la asistencia de herramientas, para convertir los requerimientos
dentro de una arquitectura viable para la construccin de un proyecto incluyendo la creacin de
prototipos.

El ciclo de vida del sistema

Un aspecto importante durante el desarrollo del sistema, es considerar explcitamente el proceso
de cambio.

Sistema de desarrollo y metodologa

Cuando se desarrolla un sistema grande es importante conocer como cada uno de los
pasos del mtodo interacta y como ellos compiten dentro del desarrollo del proceso. Se hace
hincapi en la discusin entre el proceso de desarrollo y las ideas bsicas que hay detrs del
mtodo lo que determina la seleccin de una arquitectura de un universo de arquitecturas.

Finalmente se agregan pocos comentarios acerca de cmo las herramientas CASE deberan ser
diseadas para soportar el desarrollo, iniciando desde las propiedades fundamentales de la
arquitectura, mtodos y procesos.