Ingeniería del Software embebido (página 2)

Aspectos de gestión económica y de SE La produccion de software = mantenimiento + desarrollo (evolución) Costes de mantenimiento > 60% de todos los costs de desarrollo 20% correctivo 30% adaptativo 50% perfectivo Desarrollo más rápido no siempre es preferible Mayores costos por adelantado pueden sufragar los costos aguas abajo. Software mal diseñado / implementado es un factor de coste crítico. 12

Componentes típicos de software embebido 13 of 13 Casi idéntico a los sistemas generales informáticos Software de aplicación Controlador de dispositivo

Componentes típicos de software embebido (cont.) 14 of 14 Middleware – ¿Qué es? Middleware es un software que ha sido extraído de la capa de aplicación por una variedad de razones. Una de las razones es que ya puede ser incluido como parte del paquete del Sistema operativo fuera de la plataforma OS. Otras razones para eliminarlo de la capa de aplicación son: permitir la reutilización en otras aplicaciones, para reducir costes o el tiempo de desarrollo mediante la compra off-the-shelf a través de un proveedor de terceros, o para simplificar el código de la aplicación. En los términos más generales, el software middleware es el software del Sistema que no es el núcleo OS del Sistema operativo, controladores de dispositivos, o software de aplicación. A continuación se muestra el middleware en el Modelo de Sistemas Embebidos (ver más en http://www.eetimes.com/document.asp?doc_id=1276764

(Gp:) Bus de datos (Gp:) Memoria De datos (Gp:) Memoriade programa (Gp:) interrupciones (Gp:) Digital o/p (Gp:) Analog o/p (Gp:) Digital i/p (Gp:) Analog i/p (Gp:) ENTRADAS (Gp:) SALIDAS (Gp:) Links A otros sistemas (Gp:) Interfaz de Usuario (Gp:) Bus de direcciones (Gp:) CPU (Gp:) AnalógicoFront End (Gp:) Digitali/p Ports (Gp:) Módulos Interfaz Usuario (Gp:) Digitalo/p Puertos (Gp:) D/A, Aislamiento (Gp:) Comms: ASC, SSC,USB, IIC, IrDA, etc. (Gp:) Soporte: Temporizador de guarda

15 of 15

Desarrollo del ciclo de vida de software. Modelo Cascada Requisitos Diseño Implementación Integración Validación Despliegue 16

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