Gerardo LeónPágina 1 La ingeniería de software y los sistemas embebidos Gerardo León.

Gerardo LeónPágina 1

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 calidadCalidad = 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

Desarrollode

Software

RM

SQA

SCM

Requerimientos

PT&O


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.


Actividades en el Desarrollo de Sistemas Embebidos

Determinación de requisitosAnálisis de hardware (*)Arquitectura o diseño de alto nivelAnálisis de rendimiento (*)Diseño detalladoCodificación y pruebas unitariasIntegraciónPruebas 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 VEntregas incrementalesEntregas incrementales con prototiposEvolutivoEspiralTodo ahoraExploratorio


Modelo de Ciclo de Vida de Cascada

Requisitos

Diseño

Codificación y pruebas

Integración

Entrega

Pruebas de sistema

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ónUsa realimentación del uso de las versiones anterioresPuede 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

RequisitosRequisitos de interfacesRequisitos de desarrollo

Requisitos funcionalesRequisitos de prueba (*)Matriz de requisitos de

prueba versus funcionalesRequisitos de calidad (*)


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:costoplazorecursosnivel de satisfacción de requisitosetc.

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 embebidoIncluir las componentes principales y sus interaccionesPuede 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

TV Set Hardware

ControlPanel

OSDClosedcaption

TimeBase

I2C

Scheduler

Command Interpreter Action Routines Automatic Routines

Device Drivers

Application

Fonts

State Machine Screens Texts

RemoteControl

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ónAnálisis del sistema: Determinar uso de recursos

compartidos entre escenariosPlanificació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ñosNo 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 expandible

Nodo inicial

Control de flujo simple

Llamado a función

Nodo repetición

Nodos identificaciónde estado


Modelo simple de sistema

Análisis basado en uso de recursosBusesDiscosMemoriaCPU

Identificar los distintos recursos de nuestro sistema.


5-Diseño de Componentes

Propósito: Tomar y registrar decisiones sobreResponsabilidades de cada móduloInterfaces de funciones y APIsAlgoritmos y/o máquinas de estadoEstructuras de datosVariables y constantesUso 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 detalladoEs más bien una transcripción del diseño al lenguaje

de programaciónSólo te preocupas del lenguaje y las herramientasTambié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

Requisitos

Arquitectura

Diseño detallado

Pruebas unitarias

Codificación

Pruebas de integración

Pruebas de sistema

Certificació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:LlamarlaTener subfunciones para

llamar

Test Driver

Your function

Stub 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 comunesConcurrencia (semáforos, tareas, dependencias)Tiempo realHardware inestable


8-Pruebas de sistema

Propósito: Asegurar que se cumplen los requisitos

Este es un proceso muy formalPlanificado en el Plan de Pruebas de SistemaCasos de prueba en la Especificación de Pruebas de

SistemaResultados en el Acta de Pruebas de Sistema

Cada error encontrado se describe y clasifica en un Informe de ErrorLa 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 hardwareCreciente complejidad y tamaño en el softwareDistribución y composición de equipos de trabajo

Gerardo LeónPágina 1 La ingeniería de software y los sistemas embebidos Gerardo León.

Documents

Transcript of Gerardo LeónPágina 1 La ingeniería de software y los sistemas embebidos Gerardo León.