ABSTRACTO

Hemos aplicado el lenguaje de especificación formal en el desarrollo de la firmware del chip IC de la tarjeta inteligente
para incrustar en un teléfono móvil. Informamos sobre un
aplicación industrial de métodos formales para el desarrollo de un sistema complejo, a saber,firmware para el chip IC de
tarjeta inteligente "Mobile FeliCa". El uso de técnicas formales, específicas
icamente el Método de Desarrollo de Viena (VDM) tenía como objetivo elevar la calidad del sistema especificaciones
reduciendo la ambigüedad y mejorando las comunicaciones entre ingenieros. Delaware-
los datos de desarrollo recopilados durante el ciclo de vida confirman la efectividad de un formulario liviano método
para contribuir a la calidad de los entregables en las primeras etapas de desarrollo. No
Los problemas de especificación de software se han informado, hasta la fecha, desde la primera versión (más de 100
millones de teléfonos móviles tienen el chip incrustado).

INTRODUCCION
Este documento informa sobre una aplicación del Método de Desarrollo de Viena (VDM) [1] al proyecto de desarrollo de
chip Mobile FeliCa IC por Sony Corporation [2] El objetivo de este trabajo fue poder producir especificaciones más
precisas de lo que permiten los métodos convencionales y, con suerte, como resultado, aumentar la calidad del
firmware desarrollado. Con el fin de evaluar la eficacia de VDM para este proyecto, se recopilaron varias métricas de
desarrollo.
"FeliCa" es una tecnología de tarjetas IC sin contacto ampliamente utilizada en Japón, desarrollada y promovido por
Sony Corporation [3]. Esta tecnología se utiliza en el Mobile FeliCa IC chip que está incrustado en un teléfono móvil.
Teléfonos móviles integrados con FeliCa IC chip se conoce como "Osaifu Keitai" (literalmente "billetera móvil") por NTT
DOCOMO, y hasta el día de hoy más de 100 millones de teléfonos celulares tienen integrado el chip. los el chip permite
que los teléfonos se usen como efectivo electrónico, boletos de tren, identificación personal, llaves de la puerta, etc.

El sistema Mobile FeliCa (figura 1) está compuesto por teléfonos móviles que contienen Chip FeliCa IC, servidores FeliCa
conectados a la red de telecomunicaciones móviles y lectores / escritores FeliCa. El firmware del chip Mobile FeliCa IC
proporciona: un archivo seguro sistema y protocolo de comunicaciones, que son las bases de la tecnología FeliCa; y
funciones de firewall que habilitan los múltiples servicios en el chip Mobile FeliCa IC tales como efectivo electrónico y
boletos de tren. El firmware del chip IC y el hardware mismo se desarrollaron desde cero para el sistema Mobile FeliCa
de segunda generación. Multi Los fabricantes de semiconductores desarrollados desarrollaron el hardware en
colaboración con Sony Corporation, mientras que Sony Corporation fue totalmente responsable de todas las etapas de
firmware desarrollo desde la definición de requisitos hasta la implementación y el mantenimiento.

El alto volumen significa que sería extremadamente costoso realizar un Recordar una vez que los chips integrados en los
teléfonos móviles. Por lo tanto, era esencial garantizar la extremadamente alta calidad del software para evitar los
problemas serios de infraestructura que podrían afectar a las partes interesadas si los defectos estuvieran presentes.
Antes de comenzar este desarrollo, analizamos las dificultades que habían surgido en proyectos de desarrollo previos.
Los problemas clave que identificamos fueron ambigüedad en las especificaciones, también dificultades de
comunicación entre ingenieros.

Los proyectos anteriores tenían especificaciones definidas utilizando una combinación de lenguaje natural y UML y, en
general, contenían ambigüedades. Como consecuencia, la implementación, prueba, la implementación y el
mantenimiento no se llevaron a cabo de manera correcta. Las ambigüedades también causaron una sobrecarga de
comunicación entre especificadores, desarrolladores y probadores porque era necesario identificar quién era
responsable de la aclaración, así como la aclaración necesaria en sí misma. Esto ha contribuido a la insuficiencia de
calidad de software y desarrollo demasiado ineficiente. Reclamo de técnicas de especificación formal ofrecer una
reducción en la ambigüedad de las especificaciones y proporcionar una base sólida para comunicación entre ingenieros,
y tienen un registro del uso de la industria [5].

Por lo tanto, fue consideró que valía la pena investigar el uso de un lenguaje de especificación formal para obtener la
mejor búsqueda.
En el resto de este documento, describimos los objetivos que teníamos antes de comenzar esta aplicación de VDM en la
Sección 2. La Sección 3 brinda una breve introducción al Tecnología VDM seleccionada para este proyecto. En la Sección
4, el enfoque adoptado para estructurar los equipos y procesos de desarrollo se presenta. Esto es seguido en Sección 5
con una presentación y evaluación de los resultados recopilados del proyecto.
Finalmente, las observaciones finales se proporcionan en la Sección 6 y en las futuras cuestiones consideradas el
próximo proyecto que usa VDM se presenta en la Sección 7.

METAS DE APLICACION DE TECNOLOGIA VDM

Después de revisar las lecciones de proyectos pasados y considerar el carácter del Proyecto de desarrollo de chip Mobile
FeliCa IC, decidimos enfocarnos en mejorar a la fase de diseño del proceso de desarrollo del software, así como a la
creación entendimiento mutuo entre ingenieros. Los objetivos específicos fueron los siguientes:

 Creando especificaciones precisas:

Este objetivo fue eliminar ambigüedades, omisiones y duplicaciones en las especificaciones.

El deseo era obtener una especificación definida con precisión para que la implementación, el despliegue y el
mantenimiento pudieran ser sistemáticamente desarrollados.

 Mejorando la calidad de los entregables en la fase de diseño:

La intención aquí era escribir las especificaciones funcionales de firmware en VDM en paralelo con la producción de una
especificación de lenguaje natural para los desarrolladores posteriores a la especificación.
fiers utilizando técnicas formales. Se esperaba que esto mejorara la calidad de los documentos de especificación porque
la producción del modelo de VDM detectaría errores que podrían no haber sido detectados en las formulaciones de
lenguaje natural. Al hacer esto, esperamos poder verificar la satisfacibilidad de los requisitos.

 Mejora los procesos de desarrollo:

El objetivo aquí era mejorar los procesos existentes para el desarrollo de especificaciones, la implementación y prueba
de firmware, pero hacerlo de una manera evolutiva incorporando la construcción y validación de modelos VDM, y
explotándolos en posteriores actividades de implementación y prueba.

 Prueba exhaustiva en diferentes niveles:

Este objetivo fue aprovechar una modelos de VDM para explotar las pruebas a lo largo de las fases del ciclo de vida de
un proyecto y no solo al final de un proyecto.
Mejorando las comunicaciones entre ingenieros:

Este objetivo fue aprovechar las especificaciones formales como una base común para la comunicación entre los
diferentes equipos de ingenieros durante el desarrollo de las especificaciones, la implementación, las pruebas, la
implementación y el mantenimiento.

3 Lenguajes de Especificacion forma y herramientas

Para el chip Mobile FeliCa IC Decidimos usar la especificación formal de calibre VDM ++ [6] y VDMTools [7, 8], ya que
admiten la descripción y validación de modelos a gran escala. VDM ++ es un lenguaje de especificación formal
multipropósito que es principalmente una extensión orientada a objetos de VDM-SL [9] que es una especificación
formal lenguaje estandarizado bajo la Organización Internacional de Normalización [10,11] .

VDMTools es una herramienta integrada que admite el análisis del modelo VDM a través de la sintaxis y verificación de
tipos, prueba de generación y prueba de obligación. Implícito (contractual pre / post-condition) especificación y
especificación explícita ejecutable portado.

Las herramientas poseen características para la gestión de las especificaciones y el viaje de ida y vuelta ingeniería hacia
y desde diagramas de clase UML.
Un intérprete proporciona una depuración superior el puerto y el análisis de cobertura de prueba posterior para los
modelos VDM escritos en el idioma gran subconjunto ejecutable. VDMTools también contiene generadores de códigos
automáticos para C ++ o Java.
Sin embargo, estos no fueron diseñados para producir código para sistemas integrados para Asegure las plataformas de
tarjetas IC inteligentes y esta característica no se usó.

Enfoque
Los artefactos producidos en el proceso de desarrollo general se muestran en la Fig. 2.
Los productos desarrollados se muestran con líneas sólidas y las herramientas utilizadas en el desarrollo son
se muestra con líneas discontinuas. Aunque las interfaces de hardware son todas iguales, chip IC los conjuntos de
instrucciones de hardware y los compiladores son diferentes. Por lo tanto, necesitamos desarrollar software por
separado para cada objetivo

Desarrollamos y probamos las especificaciones del comportamiento externo utilizando el lenguaje de especificación.
Todas las especificaciones funcionales fueron escritas en VDM ++. Los Los principales componentes o funciones
cubiertos por las especificaciones formales son los siguientes:
• La especificación del sistema de archivos FeliCa que define la estructura de datos básicos.
Taro Kurita, et al.
: La aplicación de VDM al desarrollo industrial de
• Interfaces inalámbricas y por cable de la tarjeta inteligente Mobile FeliCa.
• El marco para describir y probar las especificaciones que se basan en
estructura de datos básicos e interfaces.
• Especificaciones de comando que son la base de la tecnología FeliCa.
• Especificaciones de seguridad combinadas con sistema de archivos y especificaciones de comando

4.1 Descripción y prueba de especificaciones

Diseñamos un proceso de desarrollo basado en el "método formal basado en el modelo de formación " [12].
Discutimos y escribimos requisitos con las partes interesadas y escribió especificaciones de alto nivel en lenguaje natural
con varios diagramas basados en Notación UML, como diagramas de transición de estado y diagramas de secuencia.
A partir de estos requisitos, diseñamos e implementamos una especificación formal común marco de descripción de ID
en VDM ++. Este marco sirvió como un común base para la especificación formal del firmware. Debido a la gran variedad
de especificaciones y estilos de especificación respaldados por una especificación formal flexible un marco de referencia
era deseable para garantizar la coherencia en un gran escalar el proyecto y, por lo tanto, lograr un diseño viable y viable.

Definiendo términos básicos minología, formato de datos, plantillas y un marco de prueba crea un fácil de leer
especificación, para que los ingenieros involucrados en el diseño puedan concentrarse ing y prueba la especificación.
Habiendo desarrollado un marco, el próximo paso fue describir las especificaciones de el sistema de archivos FeliCa,
interfaces, comandos y seguridad. Esto se hizo de una manera no estilo implícito operacional. Una especificación
implícita describe las características de objetos que se expresarán como formato de datos y estado, invariantes,
precondiciones satisfacen el estado de los datos antes de una operación y las postcondiciones que satisfacen el estado
de los datos después. VDMTools proporciona sintaxis y verificación de tipos y generador de documentos
características de las especificaciones implícitas.

Finalmente, desarrollamos un marco para escribir y probar ejecutables explícitos especificaciones, y escribió
especificaciones explícitas y casos de prueba. Especificaciones explícitas son capaces de probar y depurar tanto como el
software. En el momento de la ejecución, era posible para verificar dinámicamente invariantes, precondiciones y
postcondiciones. Las especificaciones tales como el rendimiento y la fiabilidad se escribieron en lenguaje natural
por separado de las especificaciones formales.
El proceso de desarrollo de especificación se muestra en la Fig. 3.

4.2 Equipos, capacitación y proceso de desarrollo

Los ingenieros del proyecto trabajaron en tres equipos que variaban en tamaño: una especificación equipo de 5-20
miembros, un equipo de implementación de firmware de 15-20 y un equipo de prueba de 25-35.
Ningún miembro tenía conocimiento previo o experiencia con métodos formales en el hora del lanzamiento del
proyecto.

No todos están familiarizados con la ingeniería de software, e incluso hubo miembros que no tenían experiencia en
ingeniería de software en absoluto.
En cuanto al nivel de habilidad de los ingenieros, aunque había aprendido los conceptos básicos de la tecnología de
formación, había una gran brecha en la cantidad de años de experiencia en desarrollo de software. En el momento del
lanzamiento del proyecto, algunos de los miembros recibieron Cinco días de entrenamiento de un especialista en
métodos formales.

Otros miembros recibidos en sesiones de entrenamiento en casa. Después de la fase inicial de emplear un método
formal, continuó reteniendo consultores especializados y examinó otros casos de estudio de aplicación de métodos
formales [6, 13, 14].
Usamos un enfoque de desarrollo iterativo. Se puede describir una única iteración como un ciclo de vida de desarrollo
autónomo, comenzando desde la descripción de las especificaciones hasta probando el firmware en una placa de
desarrollo. Una iteración consume algunas semanas, y en total se llevaron a cabo 30 iteraciones.
El esquema de la única iteración del proceso de desarrollo se muestra en la Fig. 4.

La función de los especificadores era investigar y negociar los requisitos con el plan.Ninguna división y otras compañías
como los usuarios de la plataforma de monedero móvil. Ellos escribiría y modificaría a la especificación de alto nivel
usando lenguaje natural y UML, escriba en la especificación formal usando el marco de descripción de especificación y
realizar pruebas unitarias en las especificaciones formales, como se muestra en las fases iniciales en Fig. 4

Una vez completadas las pruebas unitarias, la especificación se entregó a los ingenieros de implementación y a los
ingenieros de prueba. El rol de los ingenieros de implementación fue ejecutar el diseño y la modificación del firmware
de acuerdo con la especificación, y llevar a cabo pruebas unitarias en diferentes plataformas de hardware utilizando
emuladores de chips IC dentro de su entorno de desarrollo. El papel de los ingenieros de prueba fue idear casos de
prueba basados en la especificación, desarrollar programas de software para probar, construir un entorno de prueba
incluyendo el último emulador de chip IC, ejecutar pruebas en contra de la especificación y ejecutar pruebas contra el
software entregado por los ingenieros de implementación.

Para probar la especificación, los ingenieros de prueba primero prueban las pruebas de consistencia contra la
especificación utilizando programas de prueba basados en casos de prueba. Al mismo tiempo, ellos examinó la
suficiencia de los casos de prueba mediante la realización de un análisis de cobertura especificación formal ejecutable.
En consecuencia, se agregaron más casos de prueba si es necesario. En segundo lugar, ejecutaron programas de prueba
que se verificaron para ser consistentes con las especificaciones contra el firmware en hardware diferente para verificar
si el comportamiento fue como lo establece la especificación. Por último, los ingenieros comprobaron que el ejecutable
,la especificación y los programas almacenados en ROM de diferentes tipos de chips IC se comportaron lo mismo. El
esquema de prueba para el desarrollo general se muestra en la Fig. 5.

Ejecutamos principalmente pruebas de caja negra. A partir de las especificaciones formales, prueba Ginebra diseñó las
especificaciones de la prueba funcional de la caja negra y luego implementó la prueba scripts Especificaciones formales
ejecutables, firmware en una placa de desarrollo e IC los chips se probaron automáticamente utilizando el entorno de
prueba y los scripts de prueba. desde los resultados de las pruebas, pudimos confirmar si los casos de prueba y las
secuencias de comandos fueron consistentes con las especificaciones. Además, de medir la cobertura de
las especificaciones formales ejecutables, confirmamos que los casos de prueba cubrieron todas las especificaciones
definidas.

Los ingenieros de prueba también diseñaron la herramienta "Prueba Aleatoria" para enviar continuamente comandos
aleatorios para el objetivo de prueba y comprobar si el objetivo de prueba enviado de vuelta resultados correctos según
las especificaciones. La herramienta tenía una función de emulador de especificación, que creó valores esperados
basados en la especificación formal. La especificación 350 Revista Internacional de Software e Informática
emulador incluye emulación de manejo de errores cambiando el estado interno .

Además de la emulación en estados normales. El objetivo de la prueba se probó comparando los datos de prueba
enviados desde la herramienta "Prueba aleatoria" y desde el objetivo de prueba.
Realizando aproximadamente 7,000 casos de prueba de caja negra y 100 millones de prueba aleatoria casos, se logró un
chip IC de alta calidad
5 métricas del proyecto

La duración del proyecto de firmware Mobile FeliCa IC fue de 39 meses, incluidos los principales tenencia y atención al
cliente. Hubo 50-60 miembros del equipo en este proyecto, y la edad promedio fue de aproximadamente 30 años.
Empleamos varios fabricantes de chips en para reducir los riesgos en la fabricación y las ventas. Era necesario que el
firmware debería comportarse exactamente de la misma manera en diferentes circuitos integrados y desarrollo de
firmware entornos para que se conserve la compatibilidad. C / C ++ y lenguajes ensambladores fueron utilizados en la
implementación del firmware.
Los resultados de las especificaciones fueron los siguientes:
• 383 páginas de un manual de protocolo escrito en lenguaje natural (manual de usuario para
otros departamentos dentro de la compañía y para clientes externos)
• 677 páginas de un documento de especificación externo escrito en una especificación formal
idioma
• Nuestras especificaciones formales son 140 251 líneas que incluyen casos de prueba (66 412 líneas)
y comentarios escritos en lenguaje natural (34 460 líneas).

Usando estas especificaciones, implementamos el código C / C ++ de aproximadamente 164,000 líneas, incluyendo

encabezados y comentarios (alrededor de 100 000 líneas), como firmware de dos CPU IC. Al momento de escribir, no se
han reportado problemas relacionados con el software especificaciones desde la primera versión.

5.1 Pruebas y revisiones de especificaciones

Los resultados para mejorar la calidad de la especificación probando y revisando las especificaciones se muestran en
esta sección.
La tasa de cobertura de línea de las especificaciones formales por unidad de prueba (como se muestra en Fig. 4) fue del
82%. Pudimos mejorar la tasa de cobertura de casos de prueba unitarios mediante un análisis de cobertura respaldado
por las herramientas de VDM. Como resultado de las pruebas unitarias, pudimos, por ejemplo, descubrir una ruta
incorrecta en las postcondiciones. Este tipo de la inconsistencia es generalmente difícil de descubrir mediante una
revisión. Errores formales de especificación descubiertos durante el proceso de proceso antes de la prueba de
integración se muestran en la Tabla 1. El uso de un método formal contribuyó a mejorar la calidad de los entregables en
la fase de diseño del proceso de desarrollo porque la especificación formal puede verificarse con sintaxis, verificarse y
probarse. En nuestra experiencia, es muy difícil lograr el mismo nivel de calidad con natura las especificaciones de
lenguaje y UML que están sujetas a controles más limitados e inspección.
Es posible medir una tasa de cobertura de casos de prueba mediante la ejecución de la caja negra prueba contra la
especificación ejecutable. La tasa de cobertura de línea del especificaciones por pruebas de caja negra e inspección
visual fue 100%.

5.2 Eficiencia del desarrollo de especificaciones

La productividad promedio para las especificaciones formales fue de aproximadamente 1,900 líneas de
VDM por ingeniero por mes (aproximadamente 160 horas), incluido el tiempo consumido para el examen de los
requisitos, escribiendo una especificación de alto nivel usando lenguaje natural lenguaje y UML, y prueba a
especificación formal. Esto es igual a la tasa de implementación incluyendo el diseño de firmware y las pruebas
unitarias, sugiriendo que el desarrollador la productividad ciertamente no se reduce, especialmente si el VDM es más
expresivo que el código objetivo Dado que esta era también una primera aplicación de especificación formal por
el equipo, se puede decir que no hubo inconvenientes particulares al uso de un lenguaje de especificación desde cero.
Incluso los especialistas en ingeniería ajenos al software podían leer, escribir y probar fácilmente una especificación
formal que ha recibido solo entrenamiento a corto plazo por parte de un especialista. Las dificultades a veces atribuidas
a los métodos formales no fueron obstáculo un método formal ligero [quince , 13] en nuestra experiencia A pesar de no
tener especialistas en métodos formales dentro del proyecto, fue posible emplear un método formal con
ayuda inicial de un especialista externo.

5.3 Porcentajes de errores en la implementación del firmware

Los porcentajes de errores en la implementación de firmware relacionados con las especificaciones de l proyecto global
es como se muestra en la Tabla 2. La tabla presenta errores en el siguiente agrupaciones:
• Errores atribuibles a la actividad de especificación. Estos se dividen en:
- Descripciones faltantes: los especificadores fallaron o no pudieron proporcionar una especificación para un caso
particular.
- Descripciones erróneas: un error de especificación.
- Descripción poco clara: la especificación está presente pero no fue rigurosa y / o no entendido por los lectores.
•Errores atribuibles al diseño / implementación y prueba del firmware (aunque estos también se deben en parte a la
falla de los especificadores para proporcionar especificaciones que son lo suficientemente fáciles de leer):

- Supervisión: la especificación ha sido descrita rigurosamente pero los lectores leen fue erróneo o no pudo
leerlo.
- Insuficiente comprensión: la especificación ha sido descrita rigurosamente pero no pudieron entenderlo
completamente y los lectores y especificadores no confirman su entendimiento el uno con el otro.
-Confirmación insuficiente: una falla de comunicación entre los lectores y los especificadores que conducen a una
falta de confirmación de la comprensión.
• Fallo en la propagación del cambio (una función de la gestión del proyecto).
• Otras causas
Era muy raro tener problemas en la implementación y las pruebas causadas por ambiguidad en la especificación.
Concluimos que los métodos formales son útiles para encontrar errores en las primeras etapas de desarrollo. Podríamos
decir que hubo muy pocos errores que quedan hasta la última etapa de desarrollo, de modo que podamos
concentrarnos solo en el diseño, la implementación y las pruebas se basan en una especificación precisa. El uso de
VDM contribuyó a mejorar tanto la especificación como el proceso de desarrollo y entregables.

En base a los resultados anteriores, se puede decir que hemos descrito con éxito las especificaciones de manera precisa
Por otro lado, el porcentaje total de "supervisión" los errores y los errores de "comprensión insuficiente" fueron del
16.3%. Esto fue debido al hecho que las separaciones entre las especificaciones actuales y el código requerido para
ejecutar las especificaciones no estaban claras. Nuestra tarea futura es lograr una especificación que sea fácil de leer y
ejecutable Es necesario prestar atención no solo a las características ejecutables sino también a la legibilidad de las
especificaciones. Especificaciones a las que se hace referencia en todos los proyectos los miembros deben ser simples,
para que puedan leerse sin estrés.

5.4 Comparación con la estimación de COCOMO

Estimamos el costo, el esfuerzo y el cronograma requeridos para desarrollar con COCOMO (COsttructive COst MOdel)
[dieciséis] antes de que el proyecto comenzara La estimación se calcula [17] basado en el tamaño de la aplicación se
muestra en la Tabla 3.

El desarrollo real desde el desarrollo de la especificación hasta los implementos de firmware tomó aproximadamente 24
meses y 950 meses persona. Es posible concluir que nuestro desarrollo es considerablemente mejor que la estimación
de COCOMO y la aplicación del método formal no retrasó el progreso del proyecto. Esta estimación fue calculado por
Sony Corporation y el personal que estimó COCOMO para el Comercio un proyecto [6].

Aunque el dominio de desarrollo y las habilidades de los ingenieros eran diferentes entre el proyecto de desarrollo de
chip Mobile FeliCa IC y el proyecto Trade One, en ambos casos se logró un desarrollo más eficaz y una mayor calidad del
software aplicando métodos formales con un costo menor que lo sugerido por la estimación de COCOMO.

6. Conclusión
La aplicación de técnicas formales ligeras fue vista como altamente exitosa para mantener nuestro proyecto dentro del
cronograma. El método formal contribuyó a la calidad de entregables en la fase de diseño del proceso de desarrollo.
Gracias a la los métodos formales, no ha habido problemas relacionados con las especificaciones del software ya que
primer lanzamiento teniendo en cuenta nuestros objetivos originales para aplicar al método formal, examinamos su
eficacia y productividad . Es posible definir funciones usando especificaciones precisas y posibles para probar las
especificaciones ejecutables. Desde esta perspectiva, la alta calidad se puede lograr en las primeras etapas de
desarrollo. Esto nos ayuda a lograr una implementación correcta y en las pruebas. Al escribir especificaciones formales
con precisión, la calidad de la discusión y la comprensión en el dominio relacionado y la especificación se puede
mejorar. Este permite verificar si los requisitos se han cumplido adecuadamente, y para mejorar la calidad no solo de las
especificaciones formales sino también de otros productos acompañando la especificación formal en las primeras
etapas de desarrollo.
Esfuerzos posteriores en el ciclo de desarrollo se beneficiaron naturalmente como resultado de una mejora
calidad upstream. Con un proceso de desarrollo basado en una especificación formal, el sistema fue desarrollado de
manera efectiva y con alta calidad. Haciendo un buen uso de una especificación precisa, llevando a cabo varios métodos
de prueba desde varios puntos de vista mejoró la calidad del software y las pruebas de regresión de la especificación
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 usar
un vocabulario y marco común para discutir constructivamente los objetivos compartidos.
Concluimos que los métodos formales son adecuados para alcanzar alta calidad dentro de filosofía tradicional japonesa
de "Kaizen" - mejorando continuamente el proceso paso a paso, trabajando en estrecha colaboración con los miembros
del equipo.

7 Problemas futuros

La validación exitosa de las especificaciones con respecto a los requisitos es una parte importante del proceso de
desarrollo que a menudo implica la negociación con las partes interesadas que carecen de las habilidades para leer las
especificaciones formales. Comunicación con los interesados actualmente tiene que hacerse a través de
especificaciones informales, por lo que los modelos informales tienen que ser producido a un costo adicional e
introduce un riesgo adicional de malentendido. Nosotros preferiría escribir una especificación una vez y usarla en todas
partes. Para resolver esto, nos gustaría encontrar formas de presentar la especificación formal a las partes interesadas a
través de una notación o interfaz fácilmente comprensible. Las técnicas de validación que tenemos aplicados hasta
ahora son solo tan buenos como los conjuntos de prueba que se desarrollan. Verificación de las propiedades de
coherencia lógica, como los requisitos de seguridad, podrían abordarse técnicas de verificación más avanzadas, como
verificación de pruebas o modelos.
Hasta ahora, hemos aplicado técnicas de especificación formal solo al firmware. A extender los beneficios de nuestro
enfoque a todo el sistema (no solo las características funcionales) verificación, sino también la capa de abstracción de
hardware) nos beneficiaríamos de las abstracciones apropiado para la especificación de sistemas integrados[18].

Expresiones de gratitud
Queremos agradecer al Profesor Emérito Dines Bjørner de Technical UniverSity de Dinamarca, Profesor John Fitzgerald
de la Universidad de Newcastle, Profesor Peter Gorm Larsen del Colegio de Ingeniería de Aarhus, 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 aplicación del método formal.