El cliente se equivoca a menudo.  La habitual costumbre de solicitar feedback a los clientes e incorporara esos comentarios en los productos es una forma brillante de producir prototipos. Los prototipos son, por supuesto,  esqueletos mal implementados en ese espejo un producto real. Su función es minimizar de forma rápida el riesgo que surge de vagas obligaciones, cuestiones que la ciencia desconoce o de otras inceridumbres. Los prototipos son inestimables cuando son necesarios, pero no son necesarios para cada producto. Al menos, no la mayoría.

Por ello, los equipos de ingenieros necesitan protección ante los clientes a la hora de desarrollar el producto real.
Pulsa aquí para leer el artículo completo en EE Times.

En las mejores estimaciones, el esfuerzo de desarrollo de software detrás del diseño de chips de 90 nm, ya ha superado el esfuerzo de desarrollo de hardware. El pronóstico para 2011 es que menos del 40 por ciento del costo global de desarrollo de chips se gastará en el hardware. Ahora mismo, el software ahora domina los ciclos del proyecto y establece cuándo un chip puede entrar en producción. Como resultado, se ha incrementado la importancia de la verificación de software, y a su vez, el software ha asumido un papel fundamental en el proceso de verificación de hardware.

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

La inspección interna no destructiva de sistemas microelectromécanicos (MEMS) a través de grupos de micro  imágenes acústicas es muy útil en la búsqueda, caracterización y eliminación de anomalías y defectos.
Durante el desarrollo de un producto, la inspección acústica es de gran ayuda a la hora de modificar procesos para evitar posibles defectos. Durante la producción, la inspección acústica permite localizar los puntos de rechazo y detectar la deriva del proceso.

El transductor ultrasónico que escanea los circuitos envía ultrasonidos UHF a la superficie y registra los ecos que devuelve. Cada pulso de un eco ocurre miles de veces por segundo a medida que el transductor se mueve por la superficie. Cada escaneo de coordenadas x-y produce un pixel en la imagen acústica, que en la resolución utilizada para circuitos MEMS, supone millones de píxeles.

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

A algunos equipos de testing les puede confundir cómo hacer la transición a ágil. Si formas parte de un equipo, probablemente tengáis pruebas manuales para la regresión, bien porque nunca habéis tenido tiempo para automatizarlas o bien porque habéis estado testeando desde la interfaz gráfica y no tiene sentido automatizarlas. En tu equipo habrá estupendos testers que puedan encontrar problemas en aplicaciones complejas pero que, sin embargo, no tienden a automatizar sus pruebas y necesitan un producto final antes de empezar a testearlo. Entonces, ¿cómo se puede equiparar el ritmo de trabajo de los testers al de los desarrolladores?

Este es un problema bastante común. En muchas empresas y organizaciones, los desarrolladores creen que han evolucionado a ágil mientras que los testers siguen atascados en pruebas manuales y no pueden mantener el ritmo. El problema no es que los testers sean demasiado lentos, sino que el equipo debe trabajar de forma paralela y, hasta que no lo consiga, los testers parecerán demasiado lentos.

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

Las pruebas unitarias surgen tan pronto como el desarrollo de software en si mismo. Tiene sentido coger cada bloque de desarrollo de aplicaciones, desarrollarlo de forma aislada y ejecutarlo para asegurarse de que hace exactamente lo que debe sin interferir con el resto de la aplicación.

Hace unos años, el problema radicaba en no poder separar cada bloque de desarrollo de su entorno, compilarlo y ejecutarlo de forma unitaria. Para solucionarlo, es necesario un programa que ejecute las pruebas unitarias y que facilite una inicialización de secuencias para preparar las estructuras de datos para las pruebas unitarias que se van a realizar.

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

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.

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.

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.