la ingenier a de software y los sistemas embebidos n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
La ingeniería de software y los sistemas embebidos PowerPoint Presentation
Download Presentation
La ingeniería de software y los sistemas embebidos

Loading in 2 Seconds...

play fullscreen
1 / 31

La ingeniería de software y los sistemas embebidos - PowerPoint PPT Presentation


  • 136 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'La ingeniería de software y los sistemas embebidos' - bambi


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
la ingenier a de software
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 software1
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
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

S

Q

A

RM

SCM

PT

&

O

Requerimientos

Desarrollode

Software

El proceso de desarrollo
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.

Ejemplo: Niveles CMM
actividades en el desarrollo de sistemas embebidos
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
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
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
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
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
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
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
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
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
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
¿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
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
Arquitectura de TVControl

Application

Action Routines

Automatic Routines

Command Interpreter

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

Test Driver

Your function

Stub

Stub

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
7 integraci n
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
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
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
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