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