QA&TEST Blog

La pregunta “¿qué son los sistemas embebidos?” nos persigue en el día a día, incluso a aquellos que están inmersos en la tecnología más avanzada. A veces es más sencillo plantear la pregunta al revés: “¿es posible un mundo sin tecnología embebida?”. Probablemente, no. Si así fuera, tendríamos que vivir sin ordenadores, aviones, coches, teléfonos móviles, Internet y un sinfín de cosas más.
De hecho, la mayoría de las industrias tendrían que cambiar su modelo de negocio actual si no dispusieran de tecnología embebida. Y aún así, una amplia mayoría de la población se queda atónita al preguntarle si sabe qué son los sistemas embebidos.

Pulsa aquí para leer el artículo completo en Embedded.com.

La virtualización, un concepto fundamental en la informática y las empresas del mundo de las nuevas tecnologías, ha dejado de ser una tecnología restringida a los grandes centros de informática y los entornos de negocios. Los programadores y desarrolladores de sistemas embebidos confían cada vez más en las técnicas de virtualización, enfrentados a la obligación de establecer comunicaciones entre empresas de informática y de integrar complejos entornos de procesamiento.

Pulsa aquí para seguir leyendo el artículo en Embedded Europe.

Los riesgos de requisitos se encuentran entre los riesgos más insidiosos que amenazan los proyectos de software. Tanto si se trata de requisitos que no se han definido correctamente, como de la falta de participación del cliente en las necesidades de desarrollo o incluso de requisitos defectuosos, se encuentran entre las principales razones por las que los proyectos fracasan. Un equipo de un proyecto puede marcar la diferencia mediante la adopción y aplicación de prácticas ágiles. Cuando se aplican correctamente,  las prácticas ágiles pueden mitigar los riesgos más comunes asociados con los requisitos en proyectos de desarrollo de software.

Pulsa aquí para leer el artículo completo en Sticky Minds.

Cuando un desarrollador de software se hace con un compilador, es primordial tener en cuenta la calidad del código producido por el compilador. Sin embargo, otras características que no están  requeridas por la descripción del lenguaje ANSI (que se adaptan a las necesidades de los desarrolladores de software embebido) pueden hacer que el trabajo del desarrollador sea  más sencillo de mantener.

Pulsa aquí para seguir leyendo en Embedded Computing Design acerca de las características deseables de los compiladores utilizados en el desarrollo de aplicaciones embebidas, y algunas técnicas para hacer un mejor uso de estas características.

El tema de la codificación de los estándares es algo muy recurrente entre desarrolladores de software, cuyas opiniones divergentes plantean cuestiones que van desde por qué necesitamos estas restricciones a cómo podríamos trabajar sin ellas.

Los ingenieros de software siempre han luchado con los estándares, y el desarrollo de lenguajes de programación C y C++ supone que tengan que dedicar todavía más atención. Estos lenguajes, flexibles y potentes, están profundamente arraigados en entornos industriales y embebidos. En los últimos diez años, los desarrolladores han aceptado la necesidad de controlar y limitar C y C++ para fines industriales, comerciales y de seguridad.

Haz click aquí para seguir leyendo este artículo en Embedded.com

¿Has oído alguna de estas frases últimamente?
“Los testers han encontrado demasiados errores, por lo que hay que retrasar el proyecto.”
“Cualquiera puede ser tester; solo tenemos que darle los pasos a seguir”
“Nuestros casos de prueba proporcionarán cobertura completa del sistema“.
Ni una sola de estas comunes afirmaciones acerca del testing es cierta; al menos ninguna podría haber sido dicho por un tester.

Es imprescindible promover la precisión en la información acerca de las pruebas y los resultados para el trabajo de los testers y el responsable del equipo de testeo. Es fundamental acabar con los mitos y conceptos erróneos acerca del testing y lo que se puede y no se puede hacer. También debemos estar alerta y preparados para hacer frente a las posibles versiones que se puedan dar de un mismo mensaje acerca del testeo, incluso si esas versiones vienen de nosotros mismos o de nuestro equipo.

Si quieres seguir leyendo este artículo en Sticky Minds, pulsa aquí.

La virtualización es una tecnología establecida desde hace largo tiempo en el mundo de los servidores. Durante décadas se han utilizado diversas fórmulas para establecer el uso de esta plataforma, y en los últimos años, ha adquirido un creciente interés público al poder utilizarse en ordenadores personales. El hecho de que la virtualización pueda aportar un elevado nivel de aislamiento, y que se pueda adquirir con una capa básica de código, ha incrementado también el interés por la seguridad relacionada con las aplicaciones.

La posibilidad de integrar múltiples sistemas independientes en una única máquina, podría ser muy beneficiosa para muchas de las aplicaciones de seguridad crítica. Sin embargo, además del especial aislamiento que ofrece la virtualización, muchas de esas aplicaciones necesitan un nivel temporal de determinación: cada subsistema interactúa con un componente técnico, y en consecuencia, tiene que tener en consideración las propiedades de sincronización de estos componentes.

Haz click aquí para seguir leyendo este artículo en Embedded Control Europe.

La importancia de los sistemas embebidos aumenta cada día, y el horario de desarrollo de productos disminuye, por eso desde diferentes organizaciones se están impulsando una serie de iniciativas de mejora de los sistemas embebidos.
Desde una perspectiva empresarial, un sistema embebido ofrece un montón de oportunidades. Sin embargo, el proceso de desarrollo de estos sistemas puede estar lleno de retos. Requisitos poco especificados, plazos de entrega ajustados, disponibilidad tardía del hardware, y la falta de visibilidad de la interacción  de los sistemas acaban por hacer todavía más complejo ese desarrollo.

¿Qué podemos hacer? Haz click aquí para leer el artículo completo en Embedded Now.

Si tenemos en cuenta la cantidad de información disponible en los archivos de registro, cualquiera pensaría que las empresas debería dedicarles más atención. Los equipos, servidores, firewalls, dispositivos de red y otros dispositivos generan archivos de registro cada día, pero a menudo las empresas los ignoran.
Aunque sea un fallo grave de seguridad, es comprensible. En primer lugar, los registros pueden contener infinidad de eventos irrelevantes, de hecho, la mayoría no son más que ruido. Excepto raras excepciones, la mayoría de los registros son inútiles. En un cliente medio, con 1000 ordenadores con un firewall, se generan 25GB de archivos de registro diariamente, de los cuales, en una semana típica, ni un solo caso es un problema de seguridad que requiera una respuesta inmediata. Sí, a veces hay algunos problemas graves de seguridad, pero normalmente pasan desapercibidos entre un mar de ruido sin importancia.

Pulsa aquí para seguir leyendo este artículo en Infoworld

Aunque la implementación de un nuevo sistema suele ir acompañada de una formación rigurosa y una minuciosa documentación, suele quedarse obsoleta en cuando se lanza la siguiente versión. La mayoría del software de negocio (como oposición a las herramientas de escritorio, como procesadores de texto u hojas de cálculo), está en un estado constante de cambio, igual que el mundo de los negocios se adapta a las nuevas tecnologías para ser más competitivo y satisfacer las demandas de los clientes.

Lamentablemente, la formación del personal de la empresa no puede justificarse sólo porque haya dos nuevas funciones en un sistema, y los plazos de entrega no siempre permiten actualizar la documentación y materiales formativos. Se opta por el boca a boca para aprender a utilizar las nuevas funcionalidades del sistema, y el resultado final es la distorsión del proceso: es el juego del teléfono escacharrado.
Pero, ¿y si en lugar de documentar los procesos y formar a los usuarios, automatizamos los procesos que deben seguir los usuarios? En otras palabras, ¿y si formamos al software y no a la persona?

Pulse aquí para leer el artículo completo en Sticky Minds.