Desarrollo de ciclo de vida de software. Modelo espiral
17
Determinar objetivos, alternativas, limitaciones
Evaluar alternativas, identificar, solucionar riesgos, desarrollar prototipos
Planificar las siguientes fases
Desarrollar, verificar los productos del siguiente nivel
18
Hardware-Software Co-Diseño de Sistemas Embebidos
El Software que basa su funcionalidad en los productos embebidos de hoy causan retrasos en la completitud de los proyectos si se tiene que esperar al prototipo de hardware para empezar el desarrollo de software y su depuración.
Diseño concurrente y verificación de hardware y software es una tendencia que reduce el tiempo de lanzamiento al mercado.
(ver más en [4, 5] )
Requisitos
Problema de definición ? Especificación de requisitos
Determinar exactamente qué quiere el cliente y el usuario.
Desarrollar un contrato con el cliente
Especificar qué va a hacer el software de producto
Dificultades
El cliente solicita el producto que no es adecuado
El cliente no conoce el software
Las especificaciones son ambiguas, inconsistentes e incompletas.
19
Arquitectura/Diseño
Especificación de requisitos? Arquitectura/Diseño
Arquitectura: descomponer el software en módulos con interfaces
diseño: desarrollo de las especificaciones del módulo (algoritmos, tipos de datos)
Mantener un registro de las decisiones de diseño y trazabilidad
Especifica cómo el product de software hace sus tareas.
Dificultades
La falta de comunicación entre los diseñadores de módulos
El diseño puede ser incoherente, incompleto y ambiguo.
20
Arquitectura vs. Diseño[Perry & Wolf 1992]
La Arquitectura tiene que ver con la selección de los elementos arquitectónicos, sus interacciones y las limitaciones de los elementos y sus interacciones necesarias para proporcionar un marco en el que se cumplan los requisites y que sirva como base para el diseño.
El diseño se ocupa de la modularización y las interfaces detalladas de los elementos de diseño, sus algoritmos y procedimientos, y los tipos de datos necesarios para apoyar la arquitectura y para satisfacer los requisitos.
21
Implementación e Integración
Diseño ? Implementación
Implementar módulos; verificar que cumplen con sus especificaciones
Combinar módulos de acuerdo con el diseño
Especifica cómo el product de software realiza sus tareas
Dificultades
Errores de interacción del módulo
Orden de integración puede influir en la calidad y la productividad
22
Desarrollo basado en componentes
Desarrollar components generalmente aplicables de un tamaño razonable y reutilizarlos a través de sistemas.
Asegurarse de que son adaptables a los diferentes contextos
Extender la idea más allá del código en el desarrollo de otros artefactos
Pregunta: ¿Qué viene primero?
Integración, a continuación despliegue
Despliegue, a continuación integración
23
Diferentes componentes
Software de terceros “piezas”
Los Plug-ins de efectos/ complementos
Applets
Frameworks
Sistemas abiertos
Infraestructuras de objetos distribuidos.
Documentos compuestos
Los sistemas heredados
24
Verificación y validación
¿Qué es verificación y validación?
VerificaciónLa verificación confirma que el trabajo de los productos reflejan adecuadamente los requisitos prescritos para los mismos. En otras palabras, la verificación asegura que “el product se ha construido correctamente”
ValidaciónLa validación confirma que el product, según lo previsto, cumplirá con su uso previsto. En otras palabras, la validación asegura que “has construido lo correcto”.
25
Verificación y validación ¿Cómo actúa?
26
Modelo de desarrollo de sistema
Calidades de Software
Exactitud
Óptima calidad
establecido w.r.t., la especificación de los requisitos
absoluta
Confiabilidad
Propiedad estadística
Probabilidad de que el software funcionará como se esperaba durante un período de tiempo dado
Relativo
Robustez
Comportamiento “razonable” en circunstancias imprevistas
subjectiva
Un requisito especificado es un problema de la corrección;un requisito no especificado es un problema de robustez.
27
Usabilidad
Capacidad de que los usuarios finales puedan utilizer fácilmente el software
Extremadamente subjetivo.
Comprensibilidad
Capacidad de los desarrolladores a entender fácilmente los artefactos producidos
La calidad interna del producto
subjetivo
Verificabilidad
La facilidad de establecer las propiedades deseadas
Realizado por análisis formal o pruebas
Calidad interna
Rendimiento
Equiparado con la eficiencia
Evaluables mediante la medición, el análisis y simulación.
Calidades de software (cont.)
28
Desarrollo
Posibilidad de añadir o modificar la funcionalidad
Aborda el mantenimiento adaptativo y perfectivo.
problema: La evolución de la implementación es muy fácil
La evolución debe comenzar en los requisitos o en el diseño
Reutilización
Capacidad de construir un Nuevo software a partir de piezas existentes
Debe ser planificado
Ocurre a todos los niveles: desde la gente a los procesos, desde los requisitos hasta el código.
Interoperabilidad
Capacidad de los (sub)sistemas de software a cooperar con los demás
Fácilmente integrable en sistemas más grandes.
Técnicas communes que incluyen APIs, protocolos plug-in, etc.
Calidades de Software (cont.)
29
Calidad de software (cont.)
Escalabilidad
Capacidad de un Sistema de software para crecer en tamaño, mientras que mantiene sus propiedades y cualidades.
Asume el mantenimiento y la capacidad de evolucionar
Objetivo de desarrollo basado en componentes
Heterogeneidad
Capacidad de componer un Sistema de piezas desarrolladas en varios lenguajes de programación, en multiples plataformas, por multiples desarrolladores, etc.
Necesario para la reutilización.
Objetivo de desarrollo basado en componentes
Portabilidad
Capacidad de ejecución en entornos nuevos con un mínimo esfuerzo.
Puede ser planeado mediante el aislamiento de componentes dependientes del entorno.
Necesarios para la aparición de los sistemas altamente distribuidos (por ejemplo, Internet)
30
Evaluar calidades del software
Las calidades deben ser medibles
La medición require que las calidades sean definidas de forma precisa
La mejora requiere una medición precisa
Actualmente la mayoría de las calidades se definen de manera informal y son difíciles de evaluar
Ingeniería del Software “Axiomas”
La adición de desarrolladores a un proyecto probablemente resultará en más retrasos y acumulación de costes.
Tensión básica de la ingeniería de software
Mejor, más barato, más rápido – elegir cualquiera de los dos¡
Funcionalidad, escalabilidad, rendimiento – elegir cualquiera de los dos¡
Cuanto más dura un fallo en el software
Mayores son los costes de la detección y corrección del fallo
Menos probable es que sea debidamente corregido
Hasta el 70% de todos los fallos detectados en los proyectos de software a gran escala se introducen en los requerimientos y el diseño
La detección temprana de las causas de los fallos puede reducir sus costos resultantes por un factor de 100 o más.
Despliegue y evolución
Operación ? Cambio
Mantener el software durante / después de la operación del usuario
Determinar si el product todavía funciona correctamente
Dificultades
Diseño rígido
Falta de documentación
Rotación de personal
33
Principios de la Ingeniería del Software
Rigor y formalidad
La separación de los asuntos de interés
Modularidad y descomposición
Abstracción
Anticipación del cambio
Generalidad
Incrementalidad
Escalabilidad
Composicionalidad
Heterogeneidad
34
35
Arquitectura del Software
Arquitectura del Software es la organización fundamental de un Sistema, dentro de sus componentes, las relaciones entre sí y con el entorno, y los principios que rigen su diseño y evolución.
La arquitectura del Software abarca el conjunto de decisiones importantes sobre la organización de un Sistema de software
Selección de los elementos estructurales y sus interfaces por los que se compone un Sistema.
Comportamiento como se especifica en las colaboraciones entre esos elementos.
Composición de estos elementos estructurales y de comportamiento en subsistemas más grandes.
El estilo arquitectónico que guía esta organización
36
Arquitectura del software Embebido
Estructura de Software y la complejidad de un Sistema embebido pueden variar significativamente según la aplicación
Las arquitecturas de software de uso general incluyen:
Lazos de control simples
Interrupción del Sistema controlado
Sistema multitarea no preferente
La multitarea preventive o multi-threading (incluye los sistemas operativos en tiempo real – RTOS)
Microkernels – micronúcleos (un paso adelante respecto a un RTOS para incluir la asignación de memoria, sistemas de archivos, etc)
Kernel Monolitico (un relativo gran kernel con capacidades sofisticadas, se adaptan a un entorno embebido). Linux embebido y Windows CE Móviles y embebidos son algunos ejemplos.
37
Sistemas operativos embebidos
Tradicional OS
Grandes requerimientos de memoria
Arquitectura multiamenazas
Modelo I/O (entrada/salida)
Núcleo y separación de usuario
No hay restricciones de energía
Amplios recursos disponibles
Características deseadas para EOS
Huella de memoria pequeña
Computo eficiente
Protocolos de comunicación
Interfaz fácil de exponer datos
Apoyar el diseño de aplicaciones diversas
Forma fácil de programar, actualizar y depurar aplicaciones de red.
38
Algunos sistemas operativos integrados
RTOSs
pSOS
VxWorks
VRTX (Versátil en tiempo real)
uC/OS-II
Java RTS etc.
Palm OS (fuente: Wikipedia)
Sistema operative embebido desarrollado inicialmente por U.S. Robotics-owned Palm Computing, Inc. para asistentes digitales personales (PDAs) en 1996
SymbianOS (fuente: Wikipedia)
Sistema operativo diseñado para dispositivos móviles por SymbianLtd. (se ejecuta generalmente en OMAP (Plataforma de aplicaciones multimedia abierta) procesadores, los cuales generalmente incluyen un propósito general de arquitectura en el núcleo del procesador ARM más uno o más coprocesadores especializados.
Android
Projecto abierto Handset Alliance
Basado en núcleo Linux 2.6 (http://code.google.com/android/)
39
Algunos sistemas operativos embebidos (cont.)
Windows CE (WinCE) (fuente: Wikipedia)
Sistema operativo de Microsoft para ordenadores minimalistas y sistemas embebidos
WinCE es un Sistema operative muy diferente, en lugar de una version abreviada del escritorio de Windows
Linux embebido (uClinux, ELKS, ThinLinux) (fuente: Wikipedia)
El uso de un Sistema operativo Linux en sistemas informáticos integrados
Según la encuesta realizada por Venture Development Corporation, Linux fue utilizada por el 18% de los ingenieros
Versiones embebidas de Linux están diseñados para dispositivos con recursos relativamente limitados, tales como teléfonos móviles y decodificadores
Dado que los dispositivos integrados se utilizan para fines específicos en lugar de fines generales, los desarrolladores optimizan sus distribuciones de Linux embebido para conseguir las configuraciones de hardware específicas y las situaciones de uso.
40
Sistemas embebidos de tiempo Real
Los sucesos de procesos de sistemas de tiempo real.
Los eventos ocurridos en las entradas externas provocan el que otros eventos tengan lugar como salidas (outputs)
Minimizar el tiempo de respuesta suele ser un objetivo principal, o de lo contrario todo el Sistema puede dejar de funcionar correctamente.
Los tipos de sistemas embebidos en tiempo real
Tiempo real Estricto (Hard) — por ejemplo, sistemas de control de vuelos
Tiempo real Flexibles (Soft) — por ejemplo, Sistema de adquisición de datos.
Tiempo real (Real) — por ejemplo Sistema de guía de misiles
Tiempo real firmes (Firm)
 Página anterior | Volver al principio del trabajo | Página siguiente  |