La depuración de errores atraerá tu atención tarde o temprano
Martes, Junio 29th, 2010
Pregunta a un ingeniero qué esta haciendo y habrá altas posibilidades de que su respuesta sea: “Estoy depurando errores”. Día sí y día no, proyecto tras proyecto, los ingenieros depuran errores; es parte de ser ingeniero. A veces, es sencillo y rápido, pero en ocasiones es duro, nada obvio, lleva tiempo y es impredecible. Todo el mundo sabe que la depuración da pavor, pero es necesaria como parte de los procesos de diseño y verificación. Una tendencia alarmante a la vez que innecesaria es el tiempo cada vez mayor que la depuración consume en el ciclo de diseño. A rasgos generales, la razón de esta tendencia es que las prácticas de depuración tradicionales no son apropiadas para los problemas de hoy en día.
Pulsa aquí para seguir leyendo este artículo en Embedded.com
Los resultados de encuestas realizadas en 2009 y 2010 muestran que los ingenieros de sistemas embebidos reconocen los prototipos como una metodología eficaz para acelerar la depuración de errores en sistemas embebidos, independientemente del tipo de sistema o su velocidad máxima.
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?
Los métodos ágiles se describen habitualmente como métodos de desarrollo de software. La mayoría de la documentación, como el Manifiesto Ágil, describe cómo se organizan los equipos ágiles y cómo deben trabajar, pero no describen el resto de aspectos que tienen lugar fuera del equipo de desarrollo.
¿Puede una organización grande adoptar métodos ágiles de desarrollo de software cuando la organización tiene la idea de que no todos los proyectos deben ser ágiles? En otras palabras, ¿puede haber una mezcla de proyectos tipo cascada y proyectos ágiles en la misma organización? La respuesta corta es sí, sin embargo hay un costo que se debe pagar por esta convivencia.
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.
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.
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.