Desde
el 2002, los Sistemas Empotrados (SE) están cada vez más presentes en
la sociedad [Solingen, 2002], abarcando diversas áreas, como el transporte, la electrónica de consumo, la distribución de energía, la medicina, el control industrial, las estaciones de red, entre otras [Noergaard, 2005]. De acuerdo a [Graaf, Lormans & Toetenel, 2002] y
[Noergaard, 2005], el campo de los SE es cada vez más amplio, variado
y complejo; por lo que las inversiones en la industria de las
tecnologías de Ingeniería de Software Empotrado para el desarrollo de
este tipo de sistemas tenderán a aumentar considerablemente.
Regularmente
es difícil describir a los SE ya que se encuentran en constante evolución por los avances tecnológicos, sin embargo, las descripciones coinciden en que se trata de “una mezcla de hardware y software
dedicado a una aplicación especifica” [Graaf, Lormans & Toetenel,
2002]; que además “implica un desarrollo paralelo de software y de
hardware” [Berger, 2002]. Su diseño se basa en los modelos clásicos de
la Ingeniería de Sistemas (Bing-bang model, cascada, espiral,
Code-and-fix model, etc.) y en dos elementos conceptuales: la
arquitectura de hardware y la arquitectura de software. Lo anterior
origina que el desarrollo de los SE sea interdisciplinario [Pearson,
Giuma & Harris, 2008], involucrando así a ingenieros y técnicos
especializados tanto en el diseño de hardware como en el diseño de
software.
Las necesidades de las sociedades actuales, han
ocasionado que los SE incrementen su complejidad y que por ende se
destine mayor importancia al tiempo de desarrollo de los mismos. Ahora
bien, durante el proceso de desarrollo es necesario considerar que los
requisitos de los SE son únicos e impactan directamente sobre los
métodos y herramientas utilizadas para su desarrollo [Ibrahim, Zhao
& Kinghorn, 2006], además de la importancia que el software tiene en
la funcionalidad del sistema [Liggesmeyer & Trapp, 2009].
El
cambio constante en los requisitos y la complejidad variante provocaron que las metodologías de diseño actuales ya no fueran suficientes [Sangiovanni & Martin, 2001], pues los sistemas modernos exigían
nuevos enfoques para su especificación, diseño y desarrollo. Debido a
esto, las organizaciones que participan en el diseño, desarrollo y
logística de los SE deben cambiar fundamentalmente la manera en que los
desarrollan, gestionando adecuadamente la complejidad operativa y
ambiental [Srinivasan, Dobrin & Lundqvist, 2009].
Con el
objetivo de aumentar la calidad del producto, reducir el tiempo de comercialización, y reducir los costos de desarrollo, en [Liggesmeyer
& Trapp, 2009] se recomienda que las metodologías empleadas para
el desarrollo de SE deben integrar correctamente los paradigmas
esenciales del diseño de software y hardware, evitando así los problemas
que actualmente se presentan durante la etapa de integración
[Srinivasan, Dobrin & Lundqvist, 2009].
De acuerdo a
[Srinivasan, Dobrin & Lundqvist, 2009], las metodologías utilizadas
actualmente en la industria de los SE no son específicas del dominio de
éstos y no se encuentran estandarizadas. Es decir, estos sistemas
carecen de una metodología eficaz por lo que en la industria, la sensación general es que la práctica actual de desarrollo de software y
SE es insatisfactoria.
En este sentido, Graaf, Lormans y Toetenel
estudiaron a siete empresas europeas en [Graaf, Lormans & Toetenel,
2003] para determinar el estado de la práctica de la Ingeniería de
Software Empotrado. Una de las conclusiones clave del estudio fue que
“los sistemas de decisión de ingeniería son en gran parte impulsados por
las limitaciones de hardware, que a su vez, impactan los esfuerzos de
software en dos etapas del ciclo de vida cuando se desarrollan los
requisitos de software a nivel componente”. A pesar de que el estudio no
indica de forma concisa cuáles son estas dos etapas del ciclo de vida
que son afectadas, los datos ofrecidos en el estudio permiten identificar que se refieren a la Especificación de Requisitos y Diseño.
Sin embargo, es claro que desde el 2000 han existido propuestas que
intentan agregar formalidad al proceso de desarrollo. Algunas de estas
propuestas han proporcionado metodologías para el desarrollo de SE,
tales como: PROFES [Birk et al., 1998], BOOTSTRAP [Kuvaja & Bicego,
1994], REMES [Seceleanu, Vulgarakis & Petterson, 2009], PECOS
[Genßler et. al., 2002], POLIS [Kang, Kwon & Lee, 2005], Métodos
Ágiles [Greene, 2004], entre otros.
Desafortunadamente, las
metodologías disponibles para el desarrollo de software (adaptadas al
desarrollo de SE) no consideran las necesidades específicas de este tipo
de sistemas [Srinivasan, Dobrin & Lundqvist, 2009].
Por todo
lo anteriormente expuesto, resulta evidente que el problema actual de
los SE no es la falta de normas o modelos para su desarrollo, sino la
falta de una estrategia eficaz para aplicarlas con éxito. Si a esto
le sumamos la extensa variedad de herramientas y métodos para
desarrollar los SE, el problema se dificulta todavía más. Por lo que
resulta necesario establecer una metodología de desarrollo propia para
los SE; que considere la estrecha relación que existe entre el software y
el hardware; que proporcione una fácil integración en el menor tiempo
posible, y que refleje la calidad adecuada.
Tesis de M.C., disponible en: jupiter.utm.mx/~tesis_dig/11487.pdf
