La ingeniería de software y los sistemas embebidos Gerardo León

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

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

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!

El proceso de desarrollo Desarrollo de Software R M S Q A S C M Requerimientos P T & O

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

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

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

Modelo de Ciclo de Vida de Cascada Requisitos Diseño Codificación y pruebas Integración Pruebas de sistema Entrega Evolución

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

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

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

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 funcionales Requisitos de prueba (*) Matriz de requisitos de prueba versus funcionales Requisitos de calidad (*) Requisitos de interfaces Requisitos de desarrollo

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

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

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

¿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

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

Arquitectura de TVControl Application Command Interpreter Action Routines Automatic Routines State Machine Screens Texts Scheduler Device Drivers OSD Remote Control Control Panel Closed caption Time Base I2C Fonts TV Set Hardware Estratos

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).

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

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

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

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

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

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

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 Test Driver Your function Stub

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

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

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

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