Date post: | 24-Jan-2016 |
Category: |
Documents |
Upload: | rosario-soriano-ponce |
View: | 217 times |
Download: | 0 times |
Gerardo LeónPágina 1
La ingeniería de software y los sistemas embebidos
Gerardo León
Gerardo LeónPágina 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
Gerardo LeónPágina 3
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
Gerardo LeónPágina 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!
Gerardo LeónPágina 5
El proceso de desarrollo
Desarrollode
Software
RM
SQA
SCM
Requerimientos
PT&O
Gerardo LeónPágina 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.
Gerardo LeónPágina 7
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
Gerardo LeónPágina 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 VEntregas incrementalesEntregas incrementales con prototiposEvolutivoEspiralTodo ahoraExploratorio
Gerardo LeónPágina 9
Modelo de Ciclo de Vida de Cascada
Requisitos
Diseño
Codificación y pruebas
Integración
Entrega
Pruebas de sistema
Evolución
Gerardo LeónPágina 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
Gerardo LeónPágina 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
Gerardo LeónPágina 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ónUsa realimentación del uso de las versiones anterioresPuede ser usado en un ambiente cambiante
Gerardo LeónPágina 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
RequisitosRequisitos de interfacesRequisitos de desarrollo
Requisitos funcionalesRequisitos de prueba (*)Matriz de requisitos de
prueba versus funcionalesRequisitos de calidad (*)
Gerardo LeónPágina 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:costoplazorecursosnivel de satisfacción de requisitosetc.
Si los objetivos no son claros, no los alcanzaremos claramente
Gerardo LeónPágina 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
Gerardo LeónPágina 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
Gerardo LeónPágina 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
Gerardo LeónPágina 18
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
Gerardo LeónPágina 19
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
Gerardo LeónPágina 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ónAnálisis del sistema: Determinar uso de recursos
compartidos entre escenariosPlanificación de tareas: Determinar qué componentes
son tareas y cómo secuenciarlas (scheduler).
Gerardo LeónPágina 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ñosNo se trata de arreglarlos en la codificación.
La idea es ver donde poner esfuerzos de optimización
Gerardo LeónPágina 22
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
Gerardo LeónPágina 23
Modelo simple de sistema
Análisis basado en uso de recursosBusesDiscosMemoriaCPU
Identificar los distintos recursos de nuestro sistema.
Gerardo LeónPágina 24
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
Gerardo LeónPágina 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 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
Gerardo LeónPágina 26
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
Gerardo LeónPágina 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:LlamarlaTener subfunciones para
llamar
Test Driver
Your function
Stub Stub
Gerardo LeónPágina 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 comunesConcurrencia (semáforos, tareas, dependencias)Tiempo realHardware inestable
Gerardo LeónPágina 29
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
Gerardo LeónPágina 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
Gerardo LeónPágina 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 hardwareCreciente complejidad y tamaño en el softwareDistribución y composición de equipos de trabajo