I El ciclo de vida para software de tiempo real



Descargar 334,77 Kb.
Página1/8
Fecha de conversión12.01.2017
Tamaño334,77 Kb.
  1   2   3   4   5   6   7   8
UNIDAD Nº4: DISEÑO DE SISTEMAS EN TIEMPO REAL

i) El ciclo de vida para software de tiempo real


Cumple básicamente las siguientes etapas por las que pasa el producto (sistema); es una visión orientada al producto. El proceso de construcción del sistema pasa por las siguientes etapas:

Ciclo de vida del producto



Necesidades

Especif. de Requerimientos

Sistema Software



Diseño

Codificación



Análisis de Requerim.

Diseño

Codificación

Implantación

Identif. de necesidades

Mantenimiento



Etapas


  1. Análisis de requerimientos: El propósito de esta fase es asegurar que todo el mundo entienda qué es lo que se quiere construir. Para esto se debe escribir la especificación de los requerimientos del software, el cual probablemente sea el documento más difícil de escribir, debido a la diversidad de personas a la que está destinado. Las siguientes personas están involucradas:

  1. Los usuarios, clientes: Su objetivo es asegurarse de que el software va a satisfacer sus requerimientos.

  2. Desarrolladores de software: Su meta es asegurarse de que puedan implementar el software requerido.

  3. Desarrolladores de hardware: Su objetivo es asegurarse de que el hardware que desarrollen soportará los requerimientos del software.

  4. Ingenieros de prueba: Deben asegurar que los requerimientos sean entendibles desde el punto de vista de la funcionalidad y deben ser capaces de probar el software y verificar que trabaja como se requiere que trabaje.

  5. Escritores de la Documentación: Deben asegurarse de entender los requerimientos lo suficientemente bien como para escribir los manuales de los usuarios.

  6. Administradores de proyectos: Deben asegurarse de que los requerimientos sean especificados de manera que ellos puedan estimar los esfuerzos de desarrollo y controlar los cambios.

Las especificaciones de los requerimientos del software deberían ser escritos en 2 partes:



  • La primera destinada a los clientes y usuarios, especificando claramente las limitaciones de lo que se va a construir, y para hacer el primer análisis de factibilidad (es decir, considerando las distintas opiniones de los desarrolladores de software). También se debe especificar lo que se asume como hardware disponible y hardware requerido.

  • La segunda está destinada a los desarrolladores de software y a los organizadores de las pruebas. Se utiliza como base para el diseño y la planificación de las pruebas. Se repasa la primera parte como un requisito esencial, y se escribe el resto del documento. Una vez que el documento pasó una 1ra revisión, se realiza la Revisión Formal del proyecto, en donde se consideran los siguientes asuntos:

    • La especificación de los requerimientos del software.

    • El plan de prueba y aceptación del software.

    • Los recursos.

    • Los riesgos.

    • Los beneficios.




  1. Fase de Diseño: El propósito de esta fase es desarrollar un esqueleto sólido antes de escribir el código. Al final debería tener la seguridad de que el sistema trabajará y las piezas podrán funcionar juntas.

    1. Organización del conocimiento: Cuando se desarrollan sistemas en tiempo real embebidos, el diseño será muy influenciado por las interfaces de hardware con las que se debe trabajar. Por lo que la primera parte en la fase de diseño estará destinada a organizar el conocimiento con respecto a las interfaces de hardware, interrupciones, servicios del sistema operativo, etc. Y a asegurar que se entiende la secuencia de eventos requeridos para crear un software que haga lo que se necesita que haga. Los resultados de esta actividad serán notas de ingeniería. Al final de esta actividad se debería realizar otra revisión general apoyada por un ingeniero de hardware que asegure que lo que se propone sea válido.

    2. Arquitectura de nivel superior: Se determinan los principales componentes del sistema y cómo ellos van a interactuar con cada uno de los otros. Los productos de esta actividad son: una vista concurrente / funcional (con una descripción de los procesos de comunicación), contenido / formato de los comandos y otras interfaces, descripción de los objetos (si se trata de un diseño orientado a objetos). Al final de esta actividad se debería realizar otra revisión general apoyada por un ingeniero de hardware que asegure que lo que se propone sea válido.




  1. Análisis del rendimiento: Se deben considerar 3 aspectos (no todos pueden ser aplicables al sistema que se esté desarrollando, pero cada uno provee una perspectiva diferente):

    1. Analizando escenarios: Esta actividad pone atención en un escenario (secuencia de procesamiento típica del sistema) y evalúa el tiempo que trascurre entre un evento y la respuesta del sistema a ese evento. Se utilizan seudo operaciones (llamada a procedimientos, declaraciones en lenguaje de alto nivel o una operación de entrada / salida sobre un archivo). Cada seudo operación se describe en términos de los recursos primitivos que utiliza (CPU, un dispositivo de salida o un bus). Luego se estima el tiempo de uso de cada recurso por primitiva. Usando toda esta información se calcula el tiempo trascurrido según el escenario que se ha descrito. Los productos de esta actividad son las descripciones de los escenarios y sus resultados, los que son utilizados en el siguiente análisis.

    2. Analizando el sistema: En esta etapa se utiliza la información derivada de los distintos escenarios y se aplican fórmulas derivadas de la teoría de colas para determinar cuantos eventos diferentes pueden ser manejados en un período de tiempo dado. Aquí se debería:

  • Obtener un juicio de dónde se realizan la mayoría de las tareas de procesamiento.

  • Cuáles son los principales factores que afectan al rendimiento.

  • Determinar dónde ocurren los cuellos de botella.

  • Preocuparse por las tareas que bloquean a otras tareas.

El producto de esta actividad también debe ser un reporte, que deberá ser revisado y si no es válido, se debe rediseñar y reanalizar.

    1. Planificando las tareas y seleccionando el algoritmo de planificación: Tiene en cuenta las tareas del sistema operativo y determina la factibilidad de encontrar un hardware para tiempo real que no sea imposible de construir. No se utiliza en sistemas que no se escriban como aplicaciones multitarea. Se debe determinar el tipo de tareas involucradas, periódicas o manejadas por eventos, cuál algoritmo de planificación se utilizará, el tiempo aproximado de ejecución de cada tarea y el tratamiento de semáforos. La salida de esta actividad es una posible redefinición de las tareas, y el diseño de los algoritmos de planificación para el sistema.




  1. Especificación de los componentes: En esta etapa se logra un entendimiento claro de lo que cada componente debe hacer. Después de completar esta etapa, se puede codificar cada componente, con una seguridad razonable de que cada pieza encajará.

Lo primero que se debe hacer es describir las responsabilidades de cada componente, para clarificar lo que debe hacer cada uno en relación con los otros.

Se debe describir el proceso por el que cada componente maneja cada entrada, describiendo cada componente como una “máquina de estado” si fuera necesario.

Luego se determina los servicios adicionales que deben proveer los objetos definidos previamente.

Finalmente, se debe actualizar la vista Funcional / Concurrente.



Los resultados del trabajo en esta etapa son:

  • Diagrama de Comunicación de Tareas.

  • Diagramas de Transición de Estados (DTE).

  • Descripción de componentes.

  • Descripción del manejo de excepciones.

  • Servicios de objetos.




  1. Codificación: Se codifican todas las unidades. Si se han revisado los requerimientos y el diseño, no deberían surgir mayores problemas aquí, pero siempre deben existir puntos de revisión. Todo lo que se ha logrado debe traducirse en una forma legible para la computadora.




  1. Chequeo del desarrollo: Está constituido por 2 actividades: la Prueba de Unidad y la Prueba de Integración.

Prueba de Unidad: Se desarrollan casos de prueba por cada unidad a testear, los cuales se documentan en un Plan de Prueba de Unidad que acompañará al código para hacer la revisión.

Prueba de Integración: Comenzará a medida que finaliza el diseño. Se debe desarrollar el software de acuerdo al plan de integración. El producto de esta actividad es el Plan de Prueba de Integración del Software que incluye la matriz de planes de pruebas, también utilizada en la fase de mantenimiento.

  1. Chequeo o prueba de aceptación del software: Requiere de un estudio de la especificación de requerimientos y de los manuales de usuario para construir el plan de prueba. También se utiliza en la elaboración de este plan las descripciones de los escenarios desarrolladas para estudiar el rendimiento. La meta del chequeo es encontrar errores. Al final de esta actividad, los administradores deberían comprender el estado del software para que puedan decidir si el software marcha o no marcha.




  1. Mantenimiento: Esta actividad tiene lugar una vez que el software ha sido entregado al usuario, ya que indudablemente sufrirá cambios debido a que se hayan encontrado errores, a que deba adaptarse a cambios en el entorno, o debido a que el cliente quiera ampliaciones funcionales o de rendimiento.
  1   2   3   4   5   6   7   8


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal