1

S. W. Yataco Irrazbal, Alumno de la Universidad Nacional Mayor de San Marcos, Escuela Acadmico Profesional
De Ingeniera de Software.

Modelos de Procesos de Software para Sistemas

Embebidos
Abstracto Las implementacin de soluciones basadas
en Sistemas Embebidos va en aumento, encontrndose
en el transporte (con en los torniquetes de la Lnea 1 del
Metro de Lima o en el Metropolitano), aparatos
electrnicos de uso cotidiano, la distribucin de energa,
la medicina, el control industrial, entre otras [Soligen,
2002]. As mismo, los requisitos no funcionales que estos
sistemas deben satisfacer (como costo, funcionalidad,
confiabilidad y rendimiento) son los que se necesitan
priorizar para un buen performance del sistema. Debido
a esto, es necesaria una metodologa que facilite el
desarrollo de Sistemas Embebidos, y con esta, los
procesos que se deben seguir para obtener un software
confiable.
El presente explica algunos de los procesos de software
que se dan cuando se modela un Sistema Embebido, las
caractersticas de stos y las principales diferencias que
hay entre s.
Palabras clave Sistemas Embebidos, Proceso de
Software.
I. QU ES UN SISTEMA EMBEBIDO?

XISTEN una gran variedad de definiciones para los

Sistemas Embebidos. Algunas de stas son:

1.

2.

Un Sistema Embebido mezcla de hardware y

software que est dedicada a una aplicacin
especfica, y que forma parte de un sistema fsico
mayor unido por, al menos, una conexin lgica
[Graaf, Lormans & Toetenel, 2002].
Un Sistema Embebido es un circuito electrnico
computarizado que est diseado para cumplir un
labor especfica de un producto [Galeano, 2009].

As, la palabra embebido refleja el hecho de que estos

sistemas se incorporan a un sistema de Ingeniera ms
general, en el que se han realizado funciones de control,
procesamiento y/o monitorizacin [Berger, 2002]. A partir
de las definiciones anteriores, se definen a los Sistemas
Embebidos como:
3.

Combinacin de software, hardware y algunas

otras partes, mecnicas o de otro tipo, destinada a
desempear una funcin especfica; cuyo objetivo
es optimizar el producto final reduciendo su
tamao o costo, o mejorando caractersticas
relacionadas con su funcionalidad (eficiencia,
disponibilidad, etc.). Estos sistemas se incrustan en
un producto ms grande y normalmente no son

visibles para el usuario. Siendo el Software

Embebido el componente que convierte al
producto en un Sistema de Procesamiento de
Informacin.
Con base a estas definiciones se puede afirmar que el
desarrollo de un Sistema Embebido comprende tanto la
parte del hardware con la del software, siendo ste
ltimo un factor limitante; por lo tanto el uso de
tcnicas adecuadas de desarrollo de software puede
contribuir en gran medida a la calidad de los Sistemas
Embebidos.
II. EL MODELO DE PROCESOS DE SOFTWARE EN EL
DESARROLLO DE SOFTWARE PARA SISTEMAS EMBEBIDOS
El desarrollo de los Sistemas Embebidos es
multidisciplinario, pues se trabaja tanto el software
como el hardware en paralelo, centrndose en la
arquitectura de cada uno.
En cuanto al software, su desarrollo adecuado es un
aval de que el producto que se obtendr es de
confianza. Para esto, una vez capturados los requisitos,
se debe tener en cuenta el tipo de Proceso de Software
adecuado para cada sistema.
La mayora de Sistemas Embebidos basan su diseo en
los modelos clsicos como: el modelo en espiral, el
modelo de cascada, el modelo de codificacin y
correccin, etc. [Pearson, Giuma & Harris, 2008].
A continuacin se detallarn algunos modelos de
Procesos de Software, enmarcando sus ventajas y
desventajas para el diseo y desarrollo de Software
Embebido que limitar el uso del sistema en cuestin.
A. Codificar y corregir (Code-and-Fix)
Es un modelo poco til, pero sin embargo bastante
comn. Se puede tener una especificacin formal o no
tenerla. Si no se ha utilizado formalmente un mtodo,
probablemente ya se est usando el mtodo codificar y
corregir en forma intuitiva.
Cuando se utiliza este mtodo se empieza con una idea
general de lo que se necesita construir. Se utiliza cualquier
combinacin de diseo, cdigo, depuracin y mtodos de
prueba no formales que sirven hasta que se tiene el producto
listo para entregar.

TABLA I
VENTAJAS Y DESVENTAJAS DEL PROCESO DE SOFTWARE
CODIFICAR Y CORREGIR
Ventajas

No conlleva ninguna
gestin, no se pierde
tiempo en la planificacin,
ni en la documentacin, en
el control de calidad, en el
cumplimiento
de
los
estndares, o en cualquier
otra actividad que no sea
codificacin pura.

Como
se
pasa
directamente a codificar, se
pueden
mostrar
inmediatamente indicios
del progreso.
Requiere poca
experiencia.
Cualquier
persona que haya escrito
alguna vez un programa
est familiarizada con este
modelo. Para proyectos
pequeos que se intentan
liquidar en un tiempo
breve, o para modelos
como
programas
de
demostracin o prototipos
desechables, el modelo
codificar y corregir puede
ser til.

Desventajas

Es un modelo peligroso
para otro tipo de proyectos
que no sean pequeos.
Puede que no suponga
gestin
alguna,
pero
tampoco ofrece medios de
evaluacin del progreso.

No proporciona medios de
evaluacin de calidad o de
identificacin de riesgos.

Si al llevar tres cuartas

partes de la codificacin
descubre que el diseo es
incorrecto, no hay otra
solucin que desechar el
trabajo y comenzar de
nuevo.

B. Cascada (Waterfall)
El mtodo ideado por Royce constituye uno de los
primeros modelos de ciclo de vida publicados, por lo que
tambin recibe el nombre de modelo de ciclo de vida
clsico.
Este mtodo modelo el ciclo de vida convencional de la
Ingeniera de software, aplicando un enfoque sistemtico y
secuencial de desarrollo que comienza con la ingeniera del
sistema y progresa a travs del anlisis, diseo,
codificacin, pruebas y mantenimiento.

Fig. 1 Ciclo de vida o Proceso de Software en Cascada (I.

Sommerville, Ingeniera de Software, 7ma. Edicin).
Como sugiere el esquema del modelo en cascada, antes
de poder avanzar a la siguiente etapa, es necesario haber
finalizado completamente la etapa anterior. Asociada con
cada etapa del proceso existen hitos y documentos, de tal
forma que se pueden utilizar el modelo para comprobar los
avances del proyecto y para estimar cunto falta para su
finalizacin. Tambin tiene una retroalimentacin con el fin
de corregir las deficiencias detectadas durante las distintas
etapas, o para completar o aumentar las funcionalidades del
sistema en desarrollo, resultando un diagrama de fases y
etapas. De esta manera , durante cualquiera de las fases se
puede retroceder momentneamente a una fase previa para
solucionar el problema que se pudiera haber encontrado.
TABLA II
VENTAJAS Y DESVENTAJAS DEL PROCESO DE SOFTWARE
CASCADA
Ventajas
Es un modelo sencillo y
disciplinado.
Es fcil de aprender a
utilizarlo y comprender su
funcionamiento.
Est dirigido por lo tipos
de
documentos
y
resultados
que
deben
obtenerse al final de cada
etapa.
Ha sido muy usado y, por
tanto, est ampliamente
contrastado.
Ayuda a detectar errores en
las primeras etapas a bajo
costo.
Ayuda a minimizar los
gastos de planificacin, pues
se realiza sin problemas.

Desventajas
Los proyectos raramente
siguen el proceso lineal tal
como
se
defina
originalmente el proceso
cascada.
Es difcil que el cliente
exponga
explcitamente
todos los requisitos al
principio del proceso.
El cliente debe tener
paciencia pues obtendr el
producto al final del ciclo
de vida.
No refleja exactamente
cmo
se
programa
realmente el sistema, en el
que suele haber un gran
componente iterativo.
Puede resultar complicado
regresar a etapas anteriores
(ya acabados) para realizar

correcciones.
El producto final obtenido
puede que no refleje todos
los requisitos del usuario.

C. Espiral de Boehm (Boehms Spiral)

En 1988 Boehm public un modelo de ciclo de vida en
espiral que sustituye a la solucin en fases del modelo en
cascada con ciclos de experimentacin y aprendizaje. El
modelo incorpora un nuevo elemento en el desarrollo de
software como es el anlisis de riesgos y define cuatro
actividades principales representadas por cuatro cuadrantes:
Planificacin: determina objetivos, alternativas y
restricciones.
Anlisis de riesgo: evala alternativas, identifica y
resuelve riesgos.
Ingeniera: desarrollo y verificacin del producto del
siguiente nivel.
Evaluacin del cliente: valoracin de los resultados y
planificacin de la siguiente fase.

En el tercer cuadrante (inferior derecho) se incorporan

incrementalmente las etapas del ciclo de vida tradicional en
cada ciclo de la espiral. En el cuarto cuadrante (inferior
izquierdo) el cliente evala el trabajo de ingeniera de esa
espiral y sugiere modificaciones. Basndose en los
comentarios del cliente, se produce la siguiente fase de
planificacin y anlisis de riesgos. En cada bucle alrededor
de la espiral, al finalizar el anlisis de riesgo, se debe tomar
la decisin de seguir adelante o no con el proyecto. Si se
sigue avanzando, cada vuelta alrededor de la espiral
conduce ms hacia fuera, hacia un modelo ms completo
del sistema, y al final al propio sistema operacional. Cada
vuelta requiere ms desarrollo de ingeniera de software, y
el nmero de actividades del tercer cuadrante aumenta al
alejarse del centro de la espiral.
Este enfoque es el ms realista en la ingeniera de
software tradicional para sistemas grandes, ya que utiliza un
enfoque evolutivo que permite al ingeniero y al cliente
entender y reaccionar a los riesgos que se detectan en cada
espiral. Utiliza la creacin de prototipos como un
mecanismo de reduccin del riesgo y mantiene el enfoque
del ciclo de vida clsico, pero incorporndolo dentro de un
proceso iterativo ms cercano al mundo real. No se
disponen de cifras comparativas de su bondad con respecto
a otros ciclos de vida, pero indudablemente sus resultados
parecen superiores ya que engloba a los ciclos clsicos y de
prototipos.
TABLA III
VENTAJAS Y DESVENTAJAS DEL PROCESO DE SOFTWARE
ESPIRAL DE BOEHM
Ventajas
Incorpora muchas de las
ventajas de los otros ciclos
de vida.

Fig. 2 Ciclo de vida o Proceso de Software en Espiral (I.

Sommerville, Ingeniera de Software, 7ma. Edicin).
Con cada iteracin alrededor de la espiral (comenzando
en el centro y siguiendo hacia el exterior), se van
construyendo sucesivas versiones del software, cada vez
ms completas. Durante la primera vuelta de la espiral, en el
primer cuadrante (superior izquierdo) se determinan
objetivos, alternativas y restricciones; y en el segundo
cuadrante (superior derecho) se analizan e identifican los
riesgos (se dispone de personal?, est preparado?, existe
mercado para el producto?, etc.). Si el anlisis de los riesgos
indica que existe incertidumbre en los requisitos se puede
desarrollar un prototipo para su valoracin, y tambin se
puede usar simulaciones y otros modelos para definir ms el
problema y refinar los requisitos.

Conjuga la naturaleza
iterativa de los prototipos
con
los
aspectos
controlados y sistemticos
del modelo clsico.

Proporciona el potencial
para el desarrollo rpido de
versiones incrementales.
Puede adaptarse y aplicarse
a lo largo de la vida del
software.
Es un enfoque realista del
desarrollo del software.
Permite aplicar el enfoque
de
construccin
de
prototipos en cualquier
momento para reducir

Desventajas
Puede resultar difcil
convencer
a
algunos
clientes de que el enfoque
evolutivo es controlable.
Slo resulta aplicable para
proyectos de gran tamao.
Supone una carga de
trabajo
adicional,
no
presente en otros ciclos de
vida.
Requiere una considerable
habilidad
para
la
evaluacin y resolucin
del riesgo, y se basa en
esta habilidad para el xito.
Si un riesgo importante no
es
descubierto
y
gestionado,
indudablemente surgirn
problemas.

Sistema Embebido. Sin embargo, el Software Embebido

debe desarrollarse en el menor tiempo y con la mejor
calidad para atender las metas que se persigue en el sistema.

riesgos.
Reduce los riesgos antes de
que se conviertan en
problemticos.
Controla muy bien los
riesgos y mientras ms
iteraciones se realicen,
menos riesgos habr.
Monitoriza y controla los
riesgos continuamente.

Es bastante complicado de
realizar y su complejidad
puede incrementarse hasta
hacerlo impracticable.

Una herramienta de suma importancia y ventaja es el uso

de una Metodologa de Software que, dentro de ella, poseen
Procesos de Software que son los que se deben de tomar en
cuenta para la obtencin de un producto de software ptimo.

El modelo no se ha
utilizado tanto como otros,
por lo que tendrn que pasar
aos antes de que determine
con certeza la eficacia de
este modelo.

Este trabajo compar tres Modelos de Procesos de

Software usados en el desarrollo de Sistemas Embebidos y,
de acuerdo a sus caractersticas, se usar el Proceso
adecuado al fin del Sistema en desarrollo. Siendo el Proceso
en Espiral de Boehm el ms conveniente en el desarrollo.
El desarrollo y/o diseo de los Sistemas Embebidos
basado en modelos permite la generacin automtica de
software para sistemas de gran produccin. Para llevarlo a
cabo, es necesario contar con la estructura de Ingeniera de
Software capaz de apoyarlo.

opiado para proyectos

ble corregir algn error

proceso?
le tener una idea de la
nal antes de culminar el

resuelve los riesgos que

n producir durante el
ida/proceso?
sita conocer todos los
?
saria la documentacin
y/o hitos para el
ento de los productos en
del proceso?
nde y es necesaria la fase
nimiento?

ESPIRAL DE

MA

CASCADA

CODIFICAR Y
CORREGIR

III. CUADRO COMPARATIVO ENTRE LOS PREGUNTAS MS

FRECUENTES EN EL PROCESO DE SOFTWARE DE SISTEMAS
EMPOTRADOS.

NO

SI

SI

NO

NO

SI

SI

NO

SI

NO

NO

SI

NO

SI

NO

V. BIBLIOGRAFA
1.

2.
3.
4.
5.

NO

SI

SI

NO

SI

SI

6.
7.
IV. CONCLUSIONES

Un producto embebido exitoso empieza con un diseo del

sistema flexible, el cual requiere de herramientas adecuadas
para construir el software, siendo este en la pieza central del

8.

Baskerville, R., Pries-Heje, J. & Ramesh, B. The

Enduring Contradictions of New Software
Development Approaches: A Response to
Persistent Problems and Practices in ISD
Information Systems Journal, 47(3): 241-245,
2007.
Berger, A. Embedded Systems Design: An
Introduction to Process, Tools, and Techniques. 1st
Edition, CMP Books. 2002.
Calero, C., Moraga, M. A. & Piattini, M. Calidad
del Producto y Proceso Software. 1ra Edicin, RaMa Editorial. 2010.
Galeano, G. Programacin de Sistemas Embebidos
en C. 1era Edicin, Alfaomega Grupo Editor. 2009.
Graaf, B., Lormans, M. & Toetenel, H. Embedded
Software Engineering: The State of the Practice
IEE Software, 20(6): 61-69, 2003.
Noergaard, T. Embedded Systems Architecture. A
Comprehensive Guide for Engineers and
Programmers. 1st Edition, Newnes. 2005.
Pearson, C., Giuma, T. & Harris, A.
Tranbnsparent Connectivity for Embedded
System Design, Proc. Of the Third International
Multi-Conference on Computing in the Global
Information Technology (ICCGI 08), IEEE
Computer Societ, pp. 68-74, 2008.
Sommerville, I., Software Enineering. 9th Edition,
Addison Wesley. 2010.