Revista Internacional de Software e Informtica, ISSN 1673-7288

http://www.ijsi.org
2009 por el Instituto de Software de la Academia China de Ciencias. Todos los derechos
reservados. Tel: + 86-10-62661040
La Aplicacin de VDM a
Desarrollo Industrial de Firmware para
un chip de tarjeta inteligente IC *
Taro Kurita y Yasumasa Nakatsugawa
(Sony Corporation, Tokio, Japn)
Resumen
Hemos aplicado el lenguaje de especificacin formal en el desarrollo de la
firmware de la tarjeta inteligente chip IC para incrustar en el telfono mvil. Presentamos una
aplicacin industrial de mtodos formales para el desarrollo de un sistema complejo, a saber, el
firmware para el chip de tarjeta inteligente "Mobile FeliCa". El uso de tcnicas formales,
especficamente el Mtodo de Desarrollo de Viena (VDM), tena como objetivo elevar la
calidad de las especificaciones del sistema reduciendo la ambigedad y mejorando las
comunicaciones entre ingenieros. Los datos de desarrollo recopilados durante el ciclo de vida
confirman la efectividad de un mtodo formal ligero para contribuir a la calidad de los
resultados en etapas tempranas de desarrollo. Hasta la fecha, no se han reportado problemas de
especificacin de software desde el primer lanzamiento (ms de 100 millones de telfonos
mviles tienen el chip incorporado)

1. Introduccin
Este documento informa sobre una aplicacin del Mtodo de Desarrollo de Viena (VDM) [1] al
proyecto de desarrollo de chips FeliCa IC mvil por Sony Corporation [2]. El objetivo de este
trabajo fue poder producir especificaciones ms precisas de lo que permiten los mtodos
convencionales y, como es de esperar, como resultado, aumentar la calidad del firmware
desarrollado. Con el fin de evaluar la eficacia de VDM para este proyecto, varias mtricas de
desarrollo se reunieron. "FeliCa" es una tecnologa sin contacto de la tarjeta del IC ampliamente
utilizada en Japn, desarrollado y promovido por Sony Corporation [3]. Esta tecnologa se
utiliza en el chip mvil FeliCa IC que est incrustado en un telfono mvil. Los telfonos
mviles incrustados con el chip FeliCa IC son conocidos como "Osaifu Keitai" (literalmente
"cartera mvil") por NTT DOCOMO, Inc. [4], y hoy en da ms de 100 millones de telfonos
mviles tienen el chip integrado. El chip permite que los telfonos se utilicen como efectivo
electrnico, billetes de tren, identificacin personal, llaves de puerta, etc.
El sistema Mobile FeliCa (figura 1) est compuesto por telfonos mviles que
Chip FeliCa IC, servidores FeliCa conectados a la red de telecomunicaciones mviles y lectores
/ escritores FeliCa. El firmware del chip Mobile FeliCa IC ofrece: un sistema de archivos seguro
y un protocolo de comunicaciones, que son las bases de la tecnologa FeliCa; y las funciones del
cortafuego que permiten los servicios mltiples en el chip mvil de FeliCa del IC tales como
efectivo electrnico y boletos de tren. El firmware del chip IC y el propio hardware se
desarrollaron desde cero para el sistema FeliCa mvil de segunda generacin. Mltiples
fabricantes de semiconductores desarrollaron el hardware en colaboracin con Sony
Corporation, mientras que Sony Corporation era completamente responsable de todas las etapas
de desarrollo de firmware desde la definicin de requisitos hasta el despliegue y mantenimiento.

Figura 1. Sistema mvil de feliCa

El alto volumen significa que sera extremadamente costoso realizar un
uct recordar una vez que los chips integrados en los telfonos mviles. Por lo tanto, es esencial
garantizar la calidad extremadamente alta del software con el fin de evitar la grave
problemas de infraestructura que podran afectar a las partes interesadas si se presentaran
defectos.
Antes de iniciar este desarrollo, analizamos las dificultades que se haban
proyectos de desarrollo previos. Los temas clave que identificamos fueron la ambigedad en
las dificultades de comunicacin entre ingenieros. Los proyectos anteriores
definidas utilizando una combinacin de lenguaje natural y UML y, en general,
contenan ambigedades. Como consecuencia, la implementacin, pruebas, despliegue y
mantenimiento no se llevaron a cabo de manera correcta. Las ambigedades tambin causaron
una sobrecarga de comunicacin entre especificadores, desarrolladores y porque era necesario
identificar quin era el responsable de la aclaracin as como la aclaracin necesaria. Esto ha
contribuido a una insuficiente calidad de las mercancas y un desarrollo demasiado
ineficiente. Las tcnicas de especificacin formal reclaman ofrecer una reduccin de la
ambigedad de las especificaciones y proporcionar una base municacin entre los ingenieros, y
tienen un historial de uso de la industria Por lo tanto, vala la pena investigar el uso de un
[5].

lenguaje de especificacin formal para obtener el mejoras buscadas.

En el resto de este artculo, describimos los objetivos que tenamos antes de comenzar
esta aplicacin de VDM en la Seccin 2. La Seccin 3 da una breve introduccin a la
VDM seleccionada para este proyecto. En la seccin 4, el enfoque adoptado para
estructuracin de los equipos y procesos de desarrollo. Esto se sigue en
Seccin 5 con una presentacin y evaluacin de los resultados obtenidos del proyecto.
Taro Kurita, et al. : La aplicacin de VDM al desarrollo industrial de ...345
Por ltimo, las observaciones finales se presentan en la Seccin 6 y las cuestiones futuras
el siguiente proyecto que utiliza VDM se presenta en la Seccin 7.
2 Metas de Aplicacin de la Tecnologa VDM Despus de revisar las lecciones de los proyectos
anteriores y considerar el carcter Mobile FeliCa IC chip proyecto de desarrollo, hemos
decidido centrarse en hacer mejorar la fase de diseo del proceso de desarrollo de software, as
como la creacin de entendimiento mutuo entre ingenieros. Los objetivos especficos fueron los
siguientes:
Creacin de especificaciones precisas: Esta meta era eliminar las ambigedades, las omisiones
y la duplicacin en las especificaciones. El deseo era obtener una
especificacin para que la implementacin, el despliegue y el mantenimiento
sistemtica y eficientemente.
Mejorar la calidad de los entregables en la fase de diseo: La intencin aqu
era escribir las especificaciones funcionales de firmware en VDM en paralelo con pro-
una especificacin de lenguaje natural para los desarrolladores despus de la especi-
utilizando tcnicas formales. Se esperaba que esto mejorara la calidad
de los documentos de especificacin porque la produccin del modelo VDM
detectar errores que podran no detectarse en las formulaciones de lenguaje natural. En
haciendo esto esperbamos poder comprobar la satisfaciabilidad de los requisitos.
Mejorar los procesos de desarrollo: El objetivo aqu era mejorar los procesos existentes
para el desarrollo de especificaciones, la implementacin y las pruebas de firmware, sino para
hacer de forma evolutiva mediante la incorporacin de la construccin y validacin de
VDM, y explotndolos en la implementacin y pruebas posteriores ocupaciones. Pruebas a
fondo en diferentes niveles: Este objetivo fue aprovechar un preciso modelos VDM para
explotar las pruebas a lo largo de las fases de un ciclo de vida del proyecto y no slo al final de
un proyecto.
Mejorar las comunicaciones entre los ingenieros: Esta meta era tomar ventaja
de las especificaciones formales como base comn para la comunicacin entre
diferentes equipos de ingenieros durante el desarrollo de la especificacin, la implementacin,
pruebas, despliegue y mantenimiento. 3 Idiomas y herramientas de especificacin formal
Para el chip mvil FeliCa IC Decidimos utilizar la especificacin formal lan- guage VDM
++ y VDMTools
[6] ya que el apoyo describir y validar modelos a gran escala. VDM ++ es un
[7, 8],

lenguaje de especificacin formal multiuso que es principalmente una extensin orientada a

objetos de VDM-SL que es una especificacin formal el lenguaje normalizado de acuerdo con
[9],

la Organizacin Internacional para la Estandarizacin VDMTools es una herramienta

[10, 11].

integrada que soporta el anlisis de modelos VDM a travs de la sintaxis y comprobacin de

tipos, generacin de obligacin de prueba y pruebas. Implcita pre / post-condition)
especificacin y estilos de especificacin explcita ejecutable son soportado Las herramientas
poseen caractersticas para la gestin de especificaciones y de ida y vuelta ingeniera desde y
hacia los diagramas de clase UML. Un intrprete proporciona un servicio de puerto y el
posterior anlisis de cobertura de prueba para modelos VDM escritos en la gran subconjunto
ejecutable. VDMTools tambin contiene generadores de cdigo automtico para C ++ o
Java. Sin embargo, estos no fueron diseados para producir cdigo para sistemas embebidos
para seguro plataformas de tarjeta inteligente IC y por lo que esta caracterstica no se utiliz.
4 Enfoque
Los artefactos producidos en el proceso de desarrollo global se muestran en la Fig. 2.
Los productos desarrollados se muestran con lneas slidas y las herramientas utilizadas en
mostrado con lneas de trazos. Aunque las interfaces de hardware son todas iguales, el chip IC
conjuntos de instrucciones de hardware y compiladores son diferentes. Por lo tanto, necesitamos
desarrollar software por separado para cada objetivo.

Figura 2. Artefactos del proyecto

Desarrollamos y probamos especificaciones de comportamiento externo usando el mtodo
formal
especificacin. Todas las especificaciones funcionales se escribieron en VDM ++. los
principales componentes o funciones cubiertos por las especificaciones formales son los
siguientes:
La especificacin del sistema de archivos FeliCa que define la estructura de datos bsica.

Taro Kurita, et al. : La aplicacin de VDM al desarrollo industrial de ...347

Conexin inalmbrica y con cable de interfaz de la tarjeta inteligente mvil FeliCa.
El marco para describir y probar las especificaciones que se basa en la
estructura bsica de datos e interfaces.
especificaciones de los comandos que son la base de la tecnologa FeliCa.
Las especificaciones de seguridad combinadas con el sistema de archivos y especificaciones
de los comandos.
4.1 Descripcin y prueba de especificaciones
Diseamos un proceso de desarrollo basado en el "mtodo formal basado en
modelo de Discutimos y escribimos los requisitos con las partes interesadas y
formacin[12].

escribi las especificaciones de alto nivel en lenguaje natural con varios diagramas basados en
Notacin UML, como diagramas de transicin de estado y diagramas de secuencia.
A partir de estos requisitos, diseamos e implementamos una
marco de descripcin de la descripcin en VDM ++. Este marco sirvi como una
base para la especificacin formal del firmware. Debido a la gran variedad de
especificaciones y estilos de especificacin soportados por una especificacin formal flexible
un marco de referencia era deseable para garantizar la coherencia en un gran
y, por lo tanto, lograr un diseo viable y aplicable. Definicin de ter-
minologa, formato de datos, plantillas y un marco de pruebas crea una
para que los ingenieros involucrados en el diseo puedan concentrarse en describir
la especificacin Despus de haber desarrollado un marco, el siguiente paso fue describir las
el sistema de archivos FeliCa, interfaces, comandos y seguridad. Esto se hizo de forma no-
operativo implcito. Una especificacin implcita describe las caractersticas de
objetos como el formato y el estado de los datos, los invariantes, las condiciones previas
fying el estado de los datos antes de una operacin y postconditions que satisfacen el estado de
los datos despus. VDMTools proporciona sintaxis y comprobacin de tipos y generador de
documentos caractersticas de las especificaciones implcitas.

Figura 3. Proceso de desarrollo de especificaciones

Finalmente, desarrollamos un marco para escribir y probar ejecutable explcito
especificaciones y especificaciones explcitas y casos de prueba. Especificaciones explcitas
es capaz de probar y depurar mucho como el software. En el momento de la ejecucin, era
posible para verificar dinmicamente invariantes, precondiciones y postcondiciones. No
funcionales especificaciones como el rendimiento y la fiabilidad se escribieron en lenguaje
natural separadamente de las especificaciones formales. El proceso de desarrollo de la
especificacin se muestra en la Fig. 3.
4.2 Equipos, formacin y proceso de desarrollo
Los ingenieros del proyecto trabajaron en tres equipos que variaban en tamao: una
especificacin equipo de 5-20 miembros, un equipo de implementacin de firmware de 15-20 y
un equipo de pruebas de 25-35. Ningn miembro tena conocimientos previos o experiencia con
mtodos momento del lanzamiento del proyecto. No todos ellos estn bien familiarizados con la
ingeniera de software, y haba incluso miembros que no tenan experiencia en ingeniera de
software en absoluto. En cuanto al nivel de habilidad de los ingenieros, aunque todos haban
aprendido los fundamentos de la informacin, hubo una gran brecha en el nmero de aos de
experiencia en desarrollo de software. En el momento del lanzamiento del proyecto, algunos de
los miembros cinco das de entrenamiento de un especialista en mtodos formales. Otros
miembros recibieron sesiones de entrenamiento de la casa. Despus de la fase inicial de emplear
un mtodo formal, consultores especializados y examin otros casos prcticos de aplicacin
de mtodos formales Se utiliz un enfoque de desarrollo iterativo. Se puede describir una
[6, 13, 14].

sola iteracin como un ciclo de vida de desarrollo autnomo, empezando por describir
especificaciones a probando el firmware en una placa de desarrollo. Una iteracin consume unas
pocas semanas, y en total se realizaron 30 iteraciones.
El esquema de la iteracin simple del proceso de desarrollo se muestra en la Fig. 4.
 Figura 4. nica iteracin del proceso de desarrollo

El papel de los especificadores era investigar y negociar los requisitos con el planning divisin y
otras empresas como los usuarios de la plataforma de la cartera mvil. Ellos escribir y modificar
una especificacin de alto nivel utilizando lenguaje natural y UML, escriba una especificacin
formal utilizando el marco de descripcin de realizar las pruebas unitarias en las
especificaciones formales, como se muestra en las
Fig. 4.
Taro Kurita, et al. : La aplicacin de VDM al desarrollo industrial de ... 349
Al finalizar las pruebas unitarias, la especificacin se entreg a ambos
ingenieros de pruebas y ingenieros de pruebas. El papel de los ingenieros de implementacin
fue para ejecutar el diseo de firmware y la modificacin de acuerdo con la especificacin, y
llevar a cabo en diferentes plataformas de hardware que utilizan emuladores de chips IC dentro
de su entorno de desarrollo. El papel de los ingenieros de pruebas era idear casos de prueba
basados en la especificacin, desarrollar programas de software para la prueba, construir un
entorno de prueba incluyendo el ltimo emulador de chip IC, ejecutar pruebas en funcin de la
especificacin y ejecutar pruebas contra el software entregado por los ingenieros de
implementacin. Para probar la especificacin, los ingenieros de pruebas ejecutaron por primera
vez las pruebas de consistencia contra la especificacin usando programas de prueba basados en
casos de prueba. Al mismo tiempo, examin la suficiencia de los casos de prueba realizando un
anlisis de la cobertura frente a las especificacin formal ejecutable. En consecuencia, se
aadieron ms casos de prueba si era necesario.
En segundo lugar, ejecutaron programas de prueba que se verificaron como consistentes con los
firmware en hardware diferente con el fin de comprobar si el comportamiento fue como se
indica en la especificacin. Por ltimo, los ingenieros comprobaron que el ejecutable
especificacin y los programas almacenados en ROM de diferentes tipos de chips IC se
comportaro lo mismo. El esquema de prueba para el desarrollo global se muestra en la Fig. 5.

Figura 5. Esquema de prueba

Ejecutamos principalmente pruebas de caja negra. De las especificaciones formales,
gineers dise las especificaciones de la prueba funcional de la caja negra y luego implement
la prueba guiones. Especificaciones formales ejecutables, firmware en una placa de desarrollo e
IC los chips se probaron automticamente utilizando el entorno de prueba y los scripts de
prueba. De los resultados de las pruebas, pudimos confirmar si los casos de prueba y los guiones
eran compatibles con las especificaciones. Adems, a partir de la medicin de la las
especificaciones formales ejecutables, confirmamos que los casos de prueba cubran
las especificaciones definidas. Los ingenieros de prueba tambin disearon una herramienta de
"prueba aleatoria" para enviar continuamente comandos aleatorios al objetivo de prueba y
compruebe si el objetivo de prueba resultados correctos segn especificaciones. La herramienta
tena una caracterstica del emulador de la especificacin, que cre valores esperados basados en
la especificacin formal. La especificacin emulador incluye la emulacin del manejo de errores
cambiando el estado interno en adems de la emulacin en estados normales. El objetivo de
ensayo se prob comparando la los datos de prueba enviados de la herramienta "Prueba
aleatoria" y la del objetivo de prueba. Mediante la realizacin de alrededor de 7 000 casos de
prueba de caja negra y 100 millones de pruebas al azar casos, se logr un chip IC de alta
calidad.
5 Mtricas del Proyecto
La duracin del proyecto de firmware del Mobile FeliCa IC fue de 39 meses,
mantenimiento y atencin al cliente. Haba entre 50 y 60 miembros del equipo en este proyecto,
y la edad promedio era de unos 30 aos. Empleamos a varios fabricantes de reducir los riesgos
en la fabricacin y las ventas. Era necesario que el firmware debe comportarse exactamente de
la misma manera en diferentes ICs y desarrollo de firmware de modo que se mantuviera la
compatibilidad. Lenguajes C / C ++ y ensamblador se utilizaron en la implementacin del
firmware.
Los resultados de la especificacin fueron los siguientes:
383 pginas de un manual de protocolo escritos en lenguaje natural (manual del usuario para
otros departamentos dentro de la empresa y para clientes externos)
677 pginas de un documento de especificacin externa escritos en la especificacin formal
idioma
Slo las especificaciones son 140 251 lneas, incluyendo casos de prueba (66 412 lneas)
y comentarios escritos en lenguaje natural (34 460 lneas) Utilizando estas especificaciones,
implementamos el cdigo C / C ++ de unas 164 000 lneas, incluyendo encabezados y
comentarios (alrededor de 100 000 lneas), como firmware de dos CPUs IC.
En el momento de escribir este documento, no se han reportado problemas relacionados con el
software especificaciones desde el primer lanzamiento.

5.1 Pruebas y revisiones de especificaciones

Los resultados sobre la mejora de la calidad de las especificaciones mediante la
se muestran en esta seccin. La tasa de cobertura de lnea de las especificaciones formales por
pruebas unitarias (como Fig. 4) fue del 82%. Pudimos mejorar la tasa de cobertura de los casos
de prueba unitaria por el anlisis de cobertura soportado por las herramientas VDM. Como
resultado de las pruebas unitarias, fueron capaces, por ejemplo, de descubrir un camino
incorrecto en poscondiciones. Este tipo de la incoherencia es generalmente difcil de descubrir
por la revisin. Los errores de especificacin formal descubiertos durante el proceso de
La utilizacin de un mtodo formal contribuy a mejorar la calidad de los entregables en la fase
de diseo del proceso de debido a que la especificacin formal puede ser comprobada por
sintaxis, verificada y probada. En nuestra experiencia, es muy difcil lograr el mismo nivel de
calidad con especificaciones de lenguaje y UML que estn sujetas a controles ms
inspeccin. Es posible medir una tasa de cobertura de casos de prueba mediante la ejecucin de
caja negra prueba contra la especificacin ejecutable. La tasa de cobertura de la lnea de
especificaciones por la prueba de caja negra y la inspeccin visual fue del 100%.
Taro Kurita, et al. : La aplicacin de VDM al desarrollo industrial de ... 351
Tabla 1 Nmero de errores descubiertos antes de la prueba de integracin

5.2 Eficiencia del desarrollo de la especificacin

La productividad media para las especificaciones formales fue de alrededor de 1 900 lneas de
VDM por ingeniero por mes (aproximadamente 160 horas), incluyendo el tiempo consumido
para el examen de los requisitos, la redaccin de una especificacin de alto nivel y UML, y
probar una especificacin formal. Esto es igual a la tasa de incluyendo diseo de firmware y
pruebas unitarias, lo que sugiere que el la productividad no se reduce, especialmente si el VDM
es ms expresivo que el cdigo de destino. Teniendo en cuenta que se trataba tambin de una
primera aplicacin de la el equipo, se puede decir que no haba desventajas particulares en el
uso de un lenguaje de especificacin desde cero.
Incluso los especialistas en ingeniera no-software eran fcilmente capaces de leer, escribir y
probar una especificacin formal que slo recibi formacin a corto plazo por parte de un
especialista. Los las dificultades a veces atribuidas a los mtodos formales no constituan un
obstculo para un mtodo formal de peso ligero en nuestra experiencia. A pesar de no tener
[15, 13]

especialistas en mtodos formales dentro del proyecto, fue posible emplear un mtodo formal
con ayuda inicial de un especialista externo.
5.3 Porcentajes de errores en la implementacin del firmware
Los porcentajes de errores en la implementacin del firmware relacionados con las
el proyecto general son los que se muestran en la Tabla 2. El cuadro presenta errores en los
siguientes
Agrupaciones:
Los errores atribuibles a la actividad de especificacin. stos se desglosan en:
- Descripciones faltantes: los especificadores fallaron o no pudieron proporcionar una
para un caso particular.
- Descripciones errneas: un error de especificacin.
- Descripcin poco clara: la especificacin est presente pero no es rigurosa y / o
no entendido por los lectores.
Los errores atribuibles al firmware de diseo / implementacin y prueba (aunque stos
tambin son causados en parte por el hecho de que los especificadores no
son suficientemente fciles de leer):
- Supervisin: La especificacin ha sido descrita rigurosamente pero los lectores leen
errneamente o no pudieron leerla.
- Comprensin insuficiente: La especificacin ha sido descrita rigurosamente
pero no pudieron entenderlo completamente y los lectores y los especificadores no
no confirmar su entendimiento entre s.

Pgina 10
352 Revista Internacional de Software e Informtica, Vol. 3, No.2-3, Junio / Septiembre 2009
- Insuficiente Confirmacin: Un fallo de comunicacin entre los lectores
y los especificadores que conducen a una falta de confirmacin de la comprensin.
La falta de cambio de propagacin (una funcin de gestin de proyectos).
Otras causas.
Tabla 2 Porcentajes de errores en la implementacin del firmware

Era muy raro tener problemas en la implementacin y las pruebas causadas por ambiguedad en
la especificacin. Concluimos que los mtodos formales son tiles para encontrar errores en las
primeras etapas de desarrollo. Podramos decir que haba muy pocos errores hasta la ltima
etapa de desarrollo, para que pudiramos concentrarnos slo en el diseo, la implementacin y
las pruebas basadas en una especificacin precisa. El uso de VDM contribuy a mejorar tanto la
especificacin como el proceso de desarrollo y entregables.
Con base en los resultados anteriores, se puede decir que hemos descrito con xito la
especificaciones de una manera precisa. Por otra parte, el porcentaje total de "supervisin"
errores y errores de "insuficiente comprensin" fue del 16,3%. Esto se debi al hecho
que las separaciones entre las especificaciones reales y el cdigo requerido para ejecutar
las especificaciones no estaban claras. Nuestra tarea futura es lograr una especificacin que sea
fcil de leer y ejecutable. Es necesario prestar atencin no slo a las funciones ejecutables, sino
tambin la legibilidad de las especificaciones. Especificaciones a las que se refieren todos los
proyectos los miembros deben ser simples, para que puedan ser ledos sin estrs.
5.4 Comparacin con la estimacin de COCOMO
Estimamos el costo, esfuerzo y calendario requeridos para desarrollar con COCOMO
(Modelo COnstructive coste) antes de que comenzara el proyecto. Se calcula la estimacin
[16] [17]

basado en el tamao de la aplicacin es como se muestra en la Tabla 3.

El desarrollo real desde el desarrollo de la especificacin hasta la
tom unos 24 meses y 950 meses-persona. Es posible concluir que
nuestro desarrollo es considerablemente mejor que la estimacin del COCOMO y
la aplicacin del mtodo formal no retras el progreso del proyecto. Esta estimacin fue cal-
Sony Corporation y el personal que estim que COCOMO para el Comercio
Uno de los proyectos Aunque el dominio del desarrollo y las habilidades de los
[6].

diferente entre el proyecto de desarrollo de chips mviles FeliCa IC y el proyecto Trade One,
en ambos casos se logr un desarrollo ms efectivo y una mayor calidad de software
mediante la aplicacin de mtodos formales con menor costo que la estimacin de COCOMO
sugerida.
Taro Kurita, et al. : La aplicacin de VDM al desarrollo industrial de ... 353
Tabla 3 Parmetros y resultados del clculo de COCOMO

6.
Conclusin
La aplicacin de tcnicas formales ligeras fue vista como altamente exitosa
en mantener nuestro proyecto en el horario. El mtodo formal contribuy a la calidad de la
en la fase de diseo del proceso de desarrollo. Gracias a la mtodos, no ha habido problemas
relacionados con las especificaciones del software primer lanzamiento.
Considerando nuestros objetivos originales para aplicar un mtodo formal, examinamos su
eficacia. Es posible definir funciones utilizando especificaciones precisas y posibles para probar
especificaciones ejecutables. Desde esta perspectiva, se puede lograr una alta las primeras
etapas de desarrollo. Esto nos ayuda a lograr una implementacin correcta y en las pruebas. Al
escribir especificaciones formales con precisin, la calidad de la discusin y la comprensin en
el dominio relacionado y la especificacin puede ser mejorada. Esta hace posible comprobar si
los requisitos han sido adecuadamente cumplidos, y mejorar la calidad no slo de las
especificaciones formales, sino tambin de otras prestaciones acompaando la especificacin
formal en las primeras etapas de desarrollo. Los esfuerzos ms adelante en el ciclo de desarrollo
naturalmente se beneficiaron como resultado de la mejora aguas arriba. Con un proceso de
desarrollo basado en una especificacin formal, el sistema fue desarrollado con eficacia y con
alta calidad. Haciendo un buen uso de una especificacin precisa, la realizacin de diversos
mtodos de pruebas de varios puntos mejorar la calidad del software, y la prueba de regresin
de la especificacin confirm la misma calidad independientemente de los cambios.
Finalmente, es posible lograr un desarrollo efectivo y de alta calidad por los miembros del
proyecto que pudieron utilizar un vocabulario y un discutir de manera constructiva los objetivos
compartidos. Concluimos que los mtodos formales son adecuados para alcanzar una alta
Filosofa tradicional japonesa de "Kaizen" - mejora continua del proceso paso a paso, trabajando
en estrecha colaboracin con los miembros del equipo.
7 Temas futuros
La validacin exitosa de las especificaciones contra los requisitos es una parte importante
proceso de desarrollo que a menudo implica la negociacin con partes interesadas que
las habilidades para leer especificaciones formales. Comunicacin con las partes interesadas
actualmente debe hacerse a travs de especificaciones informales, por lo que los modelos
informales producido a un costo adicional e introducir un riesgo adicional de
malentendido. Nosotros preferira escribir una especificacin una vez y usarla en todas
partes. Para resolver esto, nos gustara encontrar maneras de presentar la especificacin formal a
las partes interesadas una notacin o interfaz fcil de entender. Las tcnicas de validacin que
tenemos aplicados hasta ahora slo son tan buenos como los conjuntos de prueba que se
desarrollan. Verificacin de propiedades de coherencia lgica, como los requisitos de seguridad,
podran tcnicas de verificacin ms avanzadas como prueba o comprobacin de modelos.
Hasta ahora, hemos aplicado tcnicas de especificacin formal slo al firmware. A
ampliar los beneficios de nuestro enfoque a todo el sistema (no slo las especificaciones
pero tambin la capa de abstraccin de hardware) nos beneficiaramos de las abstracciones
apropiada a la especificacin de sistemas embebidos Expresiones de gratitud
[18].

Quisiramos agradecer al Profesor Emrito Dines Bjrner del Technical Univer- de Dinamarca,
el profesor John Fitzgerald de la Universidad de Newcastle, el profesor Peter Gorm Larsen de la
Facultad de Ingeniera de Aarhus, el profesor Keijiro Araki de Kyushu Universidad, Shin
Sahara de CSK Systems Corporation, Hiroshi Sako de Designers ' Den Corporation, Miki Chiba
de Sony Corporation por su gran ayuda en la
aplicacin del mtodo formal.
Referencias
[1] Fitzgerald J, Larsen PG, Verhoef M. Mtodo de desarrollo de Viena. En Wah B (Ed), Wiley
Enciclopedia de Ciencias de la Computacin e Ingeniera, John Wiley & Sons, Inc, 2008.
[2] Kurita T, Chiba M, Nakatsugawa Y. Aplicacin de un lenguaje de especificacin formal en
el
Desarrollo del Firmware de Chip IC "Mobile FeliCa" para Incorporacin en Telfono Mvil. En
Cuellar J, Maibaum T., Sere K. Eds, FM 2008: Mtodos Formal, Notas de Lectura en la
Computadora
Science, Springer, 2008, 5014: 425 - 429.
[3] Sony Corporation. Sitio Web de FeliCa. http://www.sony.net/Products/felica/
[4] NTT DOCOMO, Inc .. "Osaifu-Keitai". http://www.nttdocomo.co.jp/english/service/osaifu/
[5] Woodcock J, Larsen PG, J Bicarregui, Fitzgerald J. Mtodos Formal: Prctica y Experiencia,
Taro Kurita, et al. : La aplicacin de VDM al desarrollo industrial de ...
355
Encuestas de Informtica ACM, 2009.
[6] Fitzgerald J, PG Larsen, Mukherjee P, Plat N, Verhoef M. Diseos validados para orientado
a objetos
Sistemas, Springer, 2005.
[7] Fitzgerald J, Larsen PG, Shara S. VDMTools: Avances en Apoyo al Modelado Formal en
VDM. ACM Sigplan Notices, 2008, 43 (2): 3-11.
[8] CSK SYSTEMS CORPORATION, sitio web de informacin de VDM,
http://www.vdmtools.jp/en/
[9] Fitzgerald J, Larsen PG. Modeling Systems: Practical Tools and Techniques in Software De-
desarrollo, 2 Edicin, Cambridge University Press, 2009.
[10] Organizacin Internacional de Normalizacin, Tecnologa de la informacin -
Programacin
guages, sus entornos y interfaces de software de sistema - Vienna Development Method -
Lenguaje de especificaciones - Parte 1: Lenguaje base, ISO / IEC 13817-1, diciembre de 1996.
[11] Plat N, Larsen PG. Una visin general de los Avisos ISO / VDM-SL Estndar, ACM
SIGPLAN, 1992,
27 (8): 76-82.
[12] Liu SY. Ingeniera formal para el desarrollo de software industrial: Mediante el mtodo
SOFL,
Springer, 2004.
[13] Sala A. El uso de mtodos formales para desarrollar un Sistema de Informacin de ATC,
IEEE Software, 1996,
13 (2): 66-76.
[14] Jones CB. Desarrollo de Software sistemtica Usando VDM, 2 edicin, Prentice Hall,
1990.
[15] Sala A. Siete mitos de los mtodos formales, IEEE Software, 1990, 7 (5): 11-19.
[16] Boehm BW. Software Economa Ingeniera, Prentice Hall, 1981.
[17] Universidad de California del Sur Centro de Sistemas e Ingeniera de Software, COCOMO
81
Intermedio modelo de implementacin, http://sunset.usc.edu/research/COCOMOII/cocomo81_
pgm / cocomo81.html
[18] Larsen PG, Fitzgerald J, Wolff S. mtodos para el desarrollo de Distributed Real-Time Em-
Sistemas con cama utilizando VDM, Revista Internacional de Software e Informtica, 2009, 3
(2-3).