La ingenier

1
La ingeniería de software y los sistemas embebidos

• Gerardo León

2
La ingeniería de software

• Ingeniería es la aplicación de conocimiento
  científico, técnico y práctico para resolver
  problemas humanos.
• Problema
• Requerimientos
• Restricciones
• Solución
• Diseño adecuado
• Predicción de resultados
• Pruebas

3
La ingeniería de software

• La ingeniería produce calidad
• Calidad satisfacción de expectativas
• Requisitos imprecisos
• Defectos en el proceso
• Ejemplos pavimentación de la Alameda
• Artesanía o ingeniería de software?
• Depende de las expectativas

4
Los sistemas embebidos

• Características especiales
• Hardware variable y desconocido
• Tiempo real
• Estricto o permisivo
• Dificultad de pruebas
• Predicibilidad y variabilidad!
• Además cada vez más común
• Tamaño importante del software y del equipo
• Equipo multidisciplinario
• Equipo distribuido
• Es importante hablar de ingeniería de software!

5
El proceso de desarrollo
6
Ejemplo Niveles CMM

1. El proceso de software es una caja negra.
2. Los requerimientos del cliente están controlados
   y prácticas de gestión de proyectos han sido
   establecidas.
3. Las tareas del proceso de desarrollo de software
   han sido definidas y son visibles.
4. El proceso de desarrollo de software definido
   está instrumentalizado y es controlados
   cuantitativamente.
5. Nuevas maneras y mejores maneras de desarrollar
   software son probadas continuamente, de forma
   controlada para mejorar la productividad y la
   calidad.

7
Actividades en el Desarrollo de Sistemas Embebidos

• Determinación de requisitos
• Análisis de hardware ()
• Arquitectura o diseño de alto nivel
• Análisis de rendimiento ()
• Diseño detallado
• Codificación y pruebas unitarias
• Integración
• Pruebas de sistema, pruebas de aceptación

8
Cómo se organizan las actividades

• Un ciclo de vida de software es la serie de
  etapas de un producto de software
• Hay muchos modelos de ciclo de vida
• Cascada y V
• Entregas incrementales
• Entregas incrementales con prototipos
• Evolutivo
• Espiral
• Todo ahora
• Exploratorio

9
Modelo de Ciclo de Vida de Cascada
Requisitos
Diseño
Codificación y pruebas
Integración
Pruebas de sistema
Entrega
Evolución
10
La Madre de Todos los Ciclos de Vida

• El ciclo de vida de cascada es sentido común
• Define lo que quieres
• Determina un método para lograrlo
• Ejecuta tu método
• Prueba los resultados
• Entrega
• Repite si quieres más

11
Modelo de Entregas Incrementales

• Una serie planificada de cascadas que entregan
  más y más funcionalidad
• Se puede usar un sistema limitado antes de
  terminar el proyecto
• No es útil para productos basados en Rom, pero
  útil en familias de productos basados en ROM

12
Modelo de Ciclo de Vida Evolutivo

• Parecido a las entregas incrementales, pero sólo
  se planifica la próxima entrega
• Con-funde el desarrollo con la evolución
• Usa realimentación del uso de las versiones
  anteriores
• Puede ser usado en un ambiente cambiante

13
1-Determinación de requisitos

• Propósito Tener un entendimiento común sobre qué
  es el sistema y qué hace
• Los requisitos sirven de base para construir y
  evaluar un sistema
• Requisitos

• Requisitos de interfaces
• Requisitos de desarrollo

• Requisitos funcionales
• Requisitos de prueba ()
• Matriz de requisitos de prueba versus funcionales
• Requisitos de calidad ()

14
El problema de la ingeniería de software
Falta de claridad en los objetivos

• Si queremos tener éxito debemos definir
  claramente qué es el éxito
• costo
• plazo
• recursos
• nivel de satisfacción de requisitos
• etc.
• Si los objetivos no son claros, no los
  alcanzaremos claramente

15
Ejemplo requisito de calidad Tiempo de cambio de
canal digital

• Si queremos que los datos sean consistentes
  podemos especificar el grado de consistencia
• Escala Probabilidad de que el cambio de canal
  digital sea menor a 2 segundos
• Prueba Tomar 100 medidas en milisegundos
• Actual
• Peor 98
• Plan 99.5
• Autoridad Minuta del 25/8/99

16
2-Organización del conocimiento ()

• Propósito Conocer y comprender el hardware y
  estándares a usar
• Es muy frecuente que usemos sistemas,
  herramientas interfaces o estándares, con los que
  no estamos familiarizados
• No podemos diseñar bien sin conocer a fondo las
  capacidades y limitaciones con que vamos a
  trabajar
• Pretender que vamos a aprender durante los
  tiempos libres es ingenuo

17
Por qué detalles ahora?

• Va en contra del diseño de arriba hacia abajo
  (top-down)
• En realidad es más bien de abajo hacia arriba
  (bottom-up)
• Después de esto volvemos al diseño top-down
• La razones principales son
• Hay una fuerte dependencia en el bajo nivel,
  incluyendo las capacidades del hardware
• Nuestro diseño debe adaptarse al hardware y RTOS
  disponibles
• Debemos aprender lo básico antes de diseñar

18
3-Arquitectura o diseño de alto nivel

• Propósito Crear un modelo del sistema embebido
• Incluir las componentes principales y sus
  interacciones
• Puede ser incluido en el documento de requisitos
• La arquitectura es la decisión de diseño más
  crítica
• Una arquitectura flexible es la base del
  desarrollo evolutivo
• Las arquitecturas son difíciles de inventar de la
  nada, pero se pueden reusar de proyectos
  anteriores o de libros

19
Arquitectura de TVControl
Application
Action Routines
Automatic Routines
Command Interpreter
State Machine
Screens
Texts
Scheduler
Device Drivers
OSD
Control Panel
Closed caption
Time Base
Remote Control
I2C
Fonts
TV Set Hardware
Estratos
20
4-Análisis de rendimiento ()

• Propósito Asegurar que el sistema tendrá el
  rendimiento adecuado
• Actividades
• Análisis de escenarios Determinar operaciones a
  ejecutar y consumo de recursos por operación
• Análisis del sistema Determinar uso de recursos
  compartidos entre escenarios
• Planificación de tareas Determinar qué
  componentes son tareas y cómo secuenciarlas
  (scheduler).

21
De qué se trata

• Mirar al diseño en términos de rendimiento
• No pasar mucho tiempo aquí pues
• No hay información detallada
• Mayor parte de problemas de rendimiento debidos a
  malos diseños
• No se trata de arreglarlos en la codificación.
• La idea es ver donde poner esfuerzos de
  optimización

22
Desarrollar escenario de uso

• Usar notación del tipo diagrama de flujo

Nodo básico
Nodo repetición
Nodos identificación de estado
Nodo expandible
Nodo inicial
Control de flujo simple
Llamado a función
23
Modelo simple de sistema

• Análisis basado en uso de recursos
• Buses
• Discos
• Memoria
• CPU
• Identificar los distintos recursos de nuestro
  sistema.

24
5-Diseño de Componentes

• Propósito Tomar y registrar decisiones sobre
• Responsabilidades de cada módulo
• Interfaces de funciones y APIs
• Algoritmos y/o máquinas de estado
• Estructuras de datos
• Variables y constantes
• Uso de semáforos, interrupciones, polling
• El resultado es una descripción detallada de cada
  móludo del sistema en uno o varios documentos

25
6-Codificación y pruebas unitarias

• Propósito Transformar el diseño en código
  ejecutable
• La codificación es una actividad poco creativa si
  el diseño es muy detallado
• Es más bien una transcripción del diseño al
  lenguaje de programación
• Sólo te preocupas del lenguaje y las herramientas
• También te preocupas de encontrar errores de
  diseño
• La codificación de un módulo termina cuando se
  ejecutan con éxito las llamadas pruebas unitarias

26
Modelo de ciclo de vida en V
Necesidades
Certificación
Requisitos
Pruebas de sistema
Arquitectura
Pruebas de integración
Diseño detallado
Pruebas unitarias
Codificación
27
Pruebas Unitarias

• Propósito Encontrar defectos en el módulo o
  función.
• Normalmente las pruebas unitarias son hechas por
  el programador del módulo.
• Para probar una función debes
• Llamarla
• Tener subfunciones para llamar

28
7-Integración

• Propósito Asegurar que no hay errores de
  interfaces encontrar defectos en el sistema
• La integración debe hacerse lo antes posible
  apenas tengamos algunos pedazos de código
• Es un proceso formal y planificado
• En los sistemas embebidos la integración suele
  ser más compleja que en los sistemas comunes
• Concurrencia (semáforos, tareas, dependencias)
• Tiempo real
• Hardware inestable

29
8-Pruebas de sistema

• Propósito Asegurar que se cumplen los requisitos
• Este es un proceso muy formal
• Planificado en el Plan de Pruebas de Sistema
• Casos de prueba en la Especificación de Pruebas
  de Sistema
• Resultados en el Acta de Pruebas de Sistema
• Cada error encontrado se describe y clasifica en
  un Informe de Error
• La base de datos de errores sirve para aprender

30
9-Pruebas de aceptación

• Propósito Certificar que los requisitos del
  cliente se han cumplido satisfactoriamente y por
  lo tanto se puede iniciar la producción
• Esta etapa también llamada qualification
  debe hacerse por un equipo independiente del
  desarrollo
• Si hay un cliente específico, él puede ejecutar
  las pruebas
• Si el producto es para el mercado, debe haber un
  equipo en la organización o subcontratado para
  hacerlas

31
Conclusiones

• La ingeniería de software porporciona técnicas y
  procedimientos que permiten ayudar a asegurar un
  software de calidad
• Cada vez más la ingeniería de software es
  necesaria en el desarrollo de sistemas embebidos
  de calidad debido a
• Crecientes posibilidades del hardware
• Creciente complejidad y tamaño en el software
• Distribución y composición de equipos de trabajo