Formal Methods in Collaborative Projects

Anna Zamansky

, Guillermo Rodriguez-Navas

, Mark Adams

and Maria Spichkova

Information Systems Department, University of Haifa, Carmel Mountain, 31905, Haifa, Israel

School of Innovation, Design and Engineering, Malardalen University, H

ogskoleplan 1, 72218 V

asteras, Sweden

Proof Technologies Ltd, 119 Comer Rd, Worcester WR2 5JD, U.K.

School of Science, RMIT University, 414-418 Swanston Street, 3001, Melbourne, Australia

Keywords:

Formal Methods, Collaboration, Industrial Applications.

Abstract:

In this paper we address particular aspects of integration of formal methods in large-scale industrial projects,

namely collaborative aspects. We review recent works addressing such aspects, identify some current trends

and discuss directions for further research.

1 INTRODUCTION

The discussion on the feasibility and usefulness of

formal methods (FM) in practice has been going on

for over four decades. For all this time formal meth-

ods have been perceived as “difﬁcult, expensive and

not widely useful” despite their widely acknowledged

advantages. Their understandability, comprehensibil-

ity and scalability have been hypothesized as hinder-

ing factors for FM adoption in industry. In “40 years

of formal methods” (Bjørner and Havelund, 2014) ad-

mit that despite numerous books, publications, con-

ferences and user groups, the gap between academic

research in FM and its integration in large indus-

trial projects is yet to be bridged. Moreover, de-

spite that fact that FM are encouraged by safety stan-

dards, this encouragement does not provide any con-

crete methodology for application of FM. And yet, as

stated by Abrial, adopting formal methods in a soft-

ware company is more a strategical and methodologi-

cal issue than a technical one (Abrial et al., 1991).

This leads to the consideration of an important as-

pect of integration of FM in industrial projects, which

has received less attention thus far. Development of

complex software products is a collaborative effort.

Collaboration in software engineering is usually un-

derstood as artifact-based or model-based collabora-

tion, where the focus of activity is on the produc-

tion of new models, the creation of shared meaning

around the models, and elimintation of error and am-

biguity within the models (Whitehead et al., 2010).

Collaboration involves communication of many dif-

ferent stakeholders, as well as the use of different de-

scriptions with a large range of levels of formality.

This leads to the natural question what is the role of

FM with respect to collaboration? Does collabora-

tion make applying FM more difﬁcult? Are there im-

plicit collaboration models in the existing FM? Is the

lack of support of collaborative aspects of FM an ad-

ditional hindrance to the adoption of FM in industry?

How can FM support these interactions?

The aim of this paper is to make a ﬁrst step to-

wards answering the above questions by highlight-

ing collaborative aspects of FM in large-scale indus-

trial software projects. We start by brieﬂy reviewing

some recent large-scale industrial projects in which

FM have been successfully applied. Then we discuss

some particular aspects of large-scale projects which

are directly related to collaboration. We ﬁnish with

a summary, highlighting also potential directions for

future research.

2 FORMAL METHODS IN

LARGE-SCALE PROJECTS

Industrial adoption of formal methods (or lack of

thereof) has been a major concern in the FM com-

munity for decades and numerous works have been

written on the topic. Several papers in the nineties dis-

cussed common myths of FM (Hall, 1990; Bowen and

Hinchey, 1995a) and FM commandments (Bowen and

Hinchey, 1995b; Bowen and Hinchey, 2006; Bowen

and Hinchey, 2005). Numerous surveys on indus-

trial use of FM have been published, among the most

396

Zamansky, A., Rodriguez-Navas, G., Adams, M. and Spichkova, M.

Formal Methods in Collaborative Projects.

In Proceedings of the 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering (ENASE 2016), pages 396-402

ISBN: 978-989-758-189-2

recent ones (Craigen et al., 1993; Bloomﬁeld et al.,

2000; Woodcock et al., 2009).

Understandability and comprehensibility of FM

have been hypothesized for years as hindering fac-

tors of industry takeup of FM. Interestingly, empiri-

cal studies show no decisive evidence for this hypoth-

esis. (Zimmerman et al., 2002) investigated how vari-

ous factors of state-based requirements speciﬁcation

language design affect readability using aerospace

applications: no decisive conclusions were reached.

(Snook and Harrison, 2001) presents an empirical

study of practitioners’ views related to understand-

ability and usability of formal methods. In contrast

to popular opinions, all the experienced interviewees

agreed that typical software engineers have no real

difﬁculties with understanding formal notations.

The more difﬁcult thing, in most opinions, was

ﬁnding useful abstractions from which models can be

created. (Andronick et al., 2012; Fitzgerald et al.,

1995) also agree that FM capabilities is readily ac-

quired by technical experts; in particular, it may be

easier to train domain experts in formal methods than

formal methods practitioners in the domain.

Scalability of FM in large-scale projects is con-

sidered another important concern. The challenges

in managing large-scale proofs were discussed in

(Bourke et al., 2012). The authors draw on expe-

riences from two large-scale projects involving for-

mal proofs: the pervasive system-level veriﬁcation of

Verisoft (Alkassar et al., 2009), and the operating sys-

tem microkernel veriﬁcation in the L4.veriﬁed project

(Klein et al., 2009).

Lightweight formal methods (Jones et al., 1996;

Jackson, 2001) seem a particularly promising ap-

proach in this respect. The idea is to concentrate just

on the areas of biggest risk, and aim to establish just

partial properties, or even just ﬁnd errors missed by

conventional software testing, rather than establish to-

tal absence of error. (Atzeni et al., 2014) report on

experiences from applying model checking to the au-

thentication system of a large scale security-oriented

project. One of the lessons learnt is that lightweight

veriﬁcation does not necessarily require special ex-

perts and can be assigned to the testing team, who

have an extensive knowledge of the system and priori-

tising errors. Similar insights are described in (Ben-

nion and Habli, 2014), where model checking was ap-

plied to aero-engine monitoring software.

One of the recent successes in formal speciﬁcation

is reported in (Zave, 2012), where Alloy was applied

to model and analyze a ring-maintenance protocol. A

more expressive language, TLA

has recently begun

to be employed for checking correctness of Amazon

Web Services (Newcombe et al., 2015). The use of a

lightweight formal technique of Analytical Software

Design is reported in (Osaiweran et al., 2015) report

on the experiences with the embedding of ASD into

the development processes.

Large-scale projects usually involve not a single

representation level, but a stack of methods and tools,

where the transition between them might be very chal-

lenging. Several approaches attempted to overcome

this obstacle. For instance, the Ptolemy approach

introduces a general way to combine heterogeneous

models of embedded systems, cf. (Eker et al., 2003).

To our best knowledge, the ﬁrst work on achieving

a pervasive formal development process for embed-

ded applications starting with informal textual spec-

iﬁcation and leading to veriﬁed machine-code was

done within the Verisoft-Automotive project (a part of

Verisoft), cf. (Botaschanjan et al., 2008), covering the

entire seamless pervasive development process. This

project was done in collaboration between TU Mu-

nich, Saarland University and BMW Group.

The ﬁrst steps towards a methodology for devel-

opment of veriﬁed embedded system have been done

in (Botaschanjan et al., 2006; Botaschanjan et al.,

2005). For example, a typical setting found in the

automotive domain, a time-triggered operating and

communication bus system, has been veriﬁed (K

uhnel

and Spichkova, 2007). Earlier results of the Verisoft

project have shown the methodology for later veriﬁ-

cation phases, in particular the relation between the

application model and its execution environment, e.g.

the operating system. The successor project, Verisoft-

XT (Spichkova et al., 2012) was done in collabora-

tion between TU Munich and Robert Bosch GmbH.

Its core part developing a Cruise Control System with

focus on system architecture and system veriﬁcation.

Verisoft-XT led to a development methodology for

safety-critical systems with focus on the tool chain,

which is employed in the design, implementation and

veriﬁcation phases of the methodology.

Another two projects on embedding formal and

semi-formal methods in the automotive industrial de-

velopment cycle were done in collaboration between

TU Munich and DENSO Corporation, cf. (Feilkas

et al., 2009; Feilkas et al., 2011). The core of both

projects was elaboration of top-down methodologies

for the development of automotive software systems

and adapting them to the case studies provided by

DENSO Corporation: an Adaptive Cruise Control

system with Pre-Crash Safety functionality, and a

keyless-entry system for smart vehicles.

Formal Methods in Collaborative Projects

397

3 EXISTING WORK ON

COLLABORATIVE SOFTWARE

DEVELOPMENT

Collaboration in software engineering is attracting in-

creasing attention as projects relying on distributed

development of software artifacts are becoming more

popular. There is a wide recognition for the need of

tools and methodologies to support collaborative de-

velopment (De Jonge et al., 2001; Whitehead et al.,

2010). The term groupware has been recently coined

(Bani-Salameh and Jeffery, 2014) in order to refer to

toolsets that support not only the technical aspects of

distributed software engineering, but also the human

and social activities inherent to any collaborative soft-

ware project.

The relevance of groupware has been particularly

recognized in the area of Global Software Engineer-

ing (GSE), in which development teams can be lo-

cated in different countries, typically different con-

tinents, potentially raising cultural and communica-

tion difﬁculties that may have strong impact on the

product quality and ﬁnal cost. These challenges were

reported in several surveys and systematic literature

studies, which include discussions on existing tool

support.

The most comprehensive review is probably

(Portillo-Rodr

ıguez et al., 2012), which reports a

number of central activities for GSE: support to in-

formal communication (e.g. screen sharing, video-

conference, chat), visualization of project evolution,

knowledge sharing (e.g. document sharing, require-

ments peer review, wiki) , distributed design (e.g. sce-

nario creation, annotation of diagrams, CASE tool for

UML models), distributed code review and code man-

agement. Other studies reporting similar results are

(Lee et al., 2006) and (Trkman et al., 2013).

Interestingly, none of the consulted surveys makes

any reference to any formal method or tool, and

the two activities that are in principle more prone

to formalization (knowledge sharing and distributed

design) seem to be implemented at best with semi-

formal approaches such as, for example, scenario cre-

ation and UML designs. Particularly, we noticed that

the term “formal” is often used in contraposition to

“colloquial”. For instance, (Lee et al., 2006) encour-

ages the use of formal communication, meaning ei-

ther exchange of formal (i.e. written) text documents

or formal meetings (i.e. with agenda and minutes)

instead of informal communication (casual conversa-

tions). This observation is a good indicator of the little

penetration that FM has had in this research area.

There are, however, some papers that report, or at

least suggest, utilization of FM in the context of GSE.

(Kuhrmann et al., 2013) suggests the use of software

process metamodels (like SPEM) in order to specify

the artifacts and data exchanged by each software pro-

cess, thus abstracting away from local software pro-

cesses and allowing composability and consistency

analysis. (Cheng et al., 2009) proposes development

of a new requirements vocabulary for self-adaptive

systems that would introduce ﬂexibility in the require-

ments speciﬁcation, capturing uncertainty and mak-

ing it easier for distributed implementation. (Zhim-

ing et al., 2014) proposed an interesting scheme of

modeling agents, which would monitor and assess the

quality of the cooperation and assist the agents to ﬁnd

out better solutions, for instance reassigning roles.

4 COLLABORATIVE ASPECTS

OF FORMAL METHODS

Given the relatively small interest that the application

of FM has generated in this research ﬁeld, there is an

urgent need to address questions related to how social,

cognitive, economic and managerial aspects of FM

can be adapted to better support collaborative work.

In particular,

• The use of FM in a collaborative project implies

communication between an FM expert (or team

of experts) with other stakeholders with different

backgrounds. How can such communication be

supported and improved?

• FM applications involve tasks and artifacts differ-

ent than those in traditional software engineering.

How can we evaluate and increase productivity,

and what tool support is needed?

• Management of FM projects plays a crucial role

in bridging the gap between academic stand-alone

projects and large-scale collaborative projects.

What managerial factors should be addressed in

the context of FM?

In what follows we brieﬂy review existing works

that are relevant to the points mentioned above.

4.1 Communication

Application of FM in collaborative projects requires

an interplay between formal and informal methods,

which use different levels of formality in descriptions.

For example, in the SACEM project (Guiho and Hen-

nebert, 1990) a difﬁculty was reported in in commu-

nication between the veriﬁers and other engineers,

who were not familiar with the formal speciﬁcation

method. This had to be overcome by providing the

COLAFORM 2016 - Special Session on Collaborative Aspects of Formal Methods

398

engineers with a natural language description derived

manually from the formal speciﬁcation.

Informal descriptions are easier to understand by

non-expert stakeholders, but they may give rise to

ambiguity, incompleteness or inconsistency; formal

ones are more difﬁcult to learn and require extensive

mathematical training, but they provide mathematical

rigor. Semi-formal approaches using diagrammatic

or other visual notations, such as UML, fall some-

where in the middle of this range. There are numerous

works that focus on formalizing a given type of infor-

mal or semi-formal descriptions. In what follows we

mention some approaches with a particular focus on

improving communication between stakeholders with

different backgrounds.

(Knight et al., 2001) addresses the need to inte-

grate both natural language text and formal language

descriptions during the process of speciﬁcation and

provides a toolset suitable for industrial development,

in which natural language is viewed as an integral and

essential part of a speciﬁcation.

(Maier and Hess, 2014) highlights this need in the

context of interaction design: formal models are cru-

cial for analyzing elicited requirements and design-

ing a product that satisﬁed these requirements. Non-

formal methods, like an open requirements elicitation

in form of workshops or interviews may fail gaining

all necessary information if there is no formal model

which builds the basis for the non-formal methods. In

this work non-formal methods, based on a conceptual

formal model are developed that are easy to apply by

non-experts.

(Schuts and Hooman, 2015) describe another ap-

proach to improve communication between stake-

holders by proposing a formal modelling approach for

the concept phase, using a light-weight modelling tool

to formalize system behaviour, decomposition and in-

terfaces and evaluating it Philips HealthTech.

Industrial data show that about 50 percent of prod-

uct defects result from ﬂawed requirements and up to

80 percent of rework efforts can be traced back to re-

quirement defects (Wiegers, 2001). It would be inter-

esting to investigate how many of these requirement

defects are in fact communication problems/mistakes,

which can be potentially reduced by applying FM.

4.2 Productivity

Considerations of time- and cost-effectiveness of ap-

plying FM are crucial in large-scale collaborative

projects. This leads to the need for evaluation and, ul-

timately, reduction of the cost of FM efforts in terms

of time and money. (Andronick et al., 2012) points

out the lack of good understanding of what to mea-

sure in projects using formal methods. (Jeffery et al.,

2015) proposes a concrete research agenda on met-

rics, cost models and estimation methods for large-

scale projects employing FM.

The study in (Staples et al., 2014) addresses the

issue of proof productivity: data on size of proofs and

human effort was extracted from the history of the de-

velopment of nine projects associated with seL4 mi-

crokernel; lines of proof were found to be very highly

correlated with human effort, the limitations of this

measure are also discussed.

(Freitas and Whiteside, 2014) introduce proof pat-

terns, which aimed to provide a common vocabulary

for solving formal methods proof obligations by cap-

turing and describing solutions to common patterns of

proof. The aim is to enable less experiences proof en-

gineers to identify common situations and tackle them

using proof patterns.

Another issue which is directly related to increas-

ing effectiveness of FM use in collaborative projects

is proof reuse. Several techniques have been consid-

ered, such as incremental proof reuse (Beckert and

Klebanov, 2004), global abstraction methods (Huang

et al., 1994), constructive methods (such as ones used

in KIV (Balser et al., 2000)), and similarity-based

methods (Melis and Schairer, 1998).

4.3 Tool Support

For FM to be beneﬁciary for software development

projects, they must be fully integrated into the soft-

ware lifecycle. This means that appropriate tool sup-

port is a crucial factor. Lack of appropriate tool sup-

port was indeed hypothesized as one of the main

obstacles for a wider adoptions of FM in industry.

As noted in (Bjørner and Havelund, 2014), in their

early usage the ﬁrst formal speciﬁcation languages,

VDM and Z, did not provide even the simplest syntax

checker, so that “the mere thought that three or more

programmers need collaborate on code development

occurred much too late in those circles”. Means are

now ﬁnally being taken to remedy this situation. For

instance, the VSTTE (Veriﬁed Software: Theories,

Tools and Experiments) initiative aims to advance the

state of the art in the science and technology of soft-

ware veriﬁcation through the interaction of theory de-

velopment, tool evolution, and experimental valida-

tion.

Although empirical data shows that the majority

of product defects result from problems traced to re-

quirements (Wiegers, 2001), tool support for the spec-

iﬁcation phase has so far been scarce. Recent spec-

iﬁcation development tools are IBMs RuleBase PE

(RuleBase, 2015), and the academic tool RAT (Bloem

Formal Methods in Collaborative Projects

399

et al., 2007). These tools enable the designer to ex-

plore a speciﬁcation’s properties. (Knight et al., 2001)

describes another toolset developed with the intent of

providing comprehensive facilities for creating formal

speciﬁcations in production software development.

A crucial lesson learnt in the veriﬁcation expe-

rience of (Bourke et al., 2012) is the importance of

proof automation, because it decreases the cognitive

load on the analyst as well as shortening proof scripts

and thus reducing maintenance costs. Both projects

used Isabelle/HOL prover, which can be soundly ex-

tended with customised automation. Another ﬁnding

is that automated support to help analysts ﬁnd theo-

rems to use in their proof scripts can greatly increase

productivity.

A recent line of research of human factors in FM

aims to support the human expert in applying FM,

producing methodologies and tools for making FM

more comprehensible, easy to use, readable, while

hiding complexity and reducing errors.(Spichkova,

2013), e.g., introduced the idea of applying ideas from

engineering psychology at the speciﬁcation phase of

system development, aiming to increase readability

and reduce chances of errors. These ideas can be ex-

tended to the domain of collaborative FM by develop-

ing intuitive and easy-to-use technological platforms

for collaborative speﬁciation and veriﬁcation efforts.

4.4 Management

(Mandrioli, 2015) points out to too little attention to

the managerial and political aspects as one of the main

factors hindering adoption of FM in industry. Indeed,

information on managerial factors of FM in collab-

orative projects is scarce. (Stidolph and Whitehead,

2003) provides guidelines in deciding whether a par-

ticular project is a good candidate for the use of FM

and describes some of the management issues to be

considered when running such projects.

(Andronick et al., 2012) reports on process and

management aspects of a recent landmark formal ver-

iﬁcation project of the microkernel seL4. To the best

of our knowledge, this is the only report to provide a

full descriptive model of the veriﬁcation process. The

paper further stresses the need for decision-making

tools for FM project management, which are currently

not available.

5 SUMMARY

In this position paper we have reviewed some recent

large-scale projects which applied FM, and discussed

some important collaborative aspects of such projects.

It is our hope that this paper will stimulate discus-

sion on research agenda to better address collabora-

tive aspects of FM, pointing out gaps that can be ﬁlled

through collaboration between academy and industry.

ACKNOWLEDGEMENTS

This work was partially funded by the Israel Science

Foundation under grant agreement no. 817/15 and

by the Swedish Governmental Agency for Innovation

Systems (VINNOVA) under project 2013-01299.

REFERENCES

Abrial, J.-R., Lee, M. K., Neilson, D., Scharbach, P., and

Sørensen, I. H. (1991). The b-method. In VDM’91

Formal Software Development Methods, pages 398–

405. Springer.

Alkassar, E., Hillebrand, M. A., Leinenbach, D. C.,

Schirmer, N. W., Starostin, A., and Tsyban, A. (2009).

Balancing the load: Leveraging semantics stack for

systems veriﬁcation. Journal of Automated Reason-

ing: Special Issue on Operating Systems Veriﬁcation,

42, Numbers 2-4:389–454.

Andronick, J., Jeffery, R., Klein, G., Kolanski, R., Staples,

M., Zhang, H., and Zhu, L. (2012). Large-scale for-

mal veriﬁcation in practice: A process perspective.

In Software Engineering (ICSE), 2012 34th Interna-

tional Conference on, pages 1002–1011. IEEE.

Atzeni, A., Su, T., and Montanaro, T. (2014). Lightweight

formal veriﬁcation in real world, a case study. In Ad-

vanced Information Systems Engineering Workshops,

pages 335–342. Springer.

Balser, M., Reif, W., Schellhorn, G., Stenzel, K., and

Thums, A. (2000). Formal system development with

kiv. In Fundamental approaches to software engineer-

ing, pages 363–366. Springer.

Bani-Salameh, H. and Jeffery, C. (2014). Collaborative and

social development environments: A literature review.

Int. J. Comput. Appl. Technol., 49(2):89–103.

Beckert, B. and Klebanov, V. (2004). Proof reuse for de-

ductive program veriﬁcation. In Software Engineering

and Formal Methods, 2004. SEFM 2004. Proceedings

of the Second International Conference on, pages 77–

86. IEEE.

Bennion, M. and Habli, I. (2014). A candid industrial

evaluation of formal software veriﬁcation using model

checking. In Companion Proceedings of the 36th

International Conference on Software Engineering,

pages 175–184. ACM.

Bjørner, D. and Havelund, K. (2014). 40 years of formal

methods. In FM 2014: Formal Methods, pages 42–

61. Springer.

Bloem, R., Cavada, R., Pill, I., Roveri, M., and Tchalt-

sev, A. (2007). Rat: A tool for the formal analysis of

COLAFORM 2016 - Special Session on Collaborative Aspects of Formal Methods

400

requirements. In Computer aided veriﬁcation, pages

263–267. Springer.

Bloomﬁeld, R., Craigen, D., Koob, F., Ullmann, M., and

Wittmann, S. (2000). Formal methods diffusion: Past

lessons and future prospects. In Computer Safety, Re-

liability and Security, pages 211–226. Springer.

Botaschanjan, J., Broy, M., Gruler, A., Harhurin, A.,

Knapp, S., Kof, L., Paul, W., and Spichkova, M.

(2008). On the correctness of upper layers of au-

tomotive systems. Formal aspects of computing,

20(6):637–662.

Botaschanjan, J., Gruler, A., Harhurin, A., Kof, L.,

Spichkova, M., and Trachtenherz, D. (2006). To-

wards Modularized Veriﬁcation of Distributed Time-

Triggered Systems. In FM 2006: Formal Methods,

pages 163–178. Springer.

Botaschanjan, J., Kof, L., K

uhnel, C., and Spichkova, M.

(2005). Towards Veriﬁed Automotive Software. In

2nd International ICSE workshop on Software. ACM.

Bourke, T., Daum, M., Klein, G., and Kolanski, R. (2012).

Challenges and experiences in managing large-scale

proofs. In AISC/MKM/Calculemus, pages 32–48.

Bowen, J. P. and Hinchey, M. G. (1995a). Seven more

myths of formal methods. IEEE software, 12(4):34–

41.

Bowen, J. P. and Hinchey, M. G. (1995b). Ten command-

ments of formal methods. Computer, 28(4):56–63.

Bowen, J. P. and Hinchey, M. G. (2005). Ten command-

ments revisited: a ten-year perspective on the indus-

trial application of formal methods. In Proceedings of

the 10th international workshop on Formal methods

for industrial critical systems, pages 8–16. ACM.

Bowen, J. P. and Hinchey, M. G. (2006). Ten command-

ments of formal methods... ten years later. Computer,

39(1):40–48.

Cheng, B. H., Lemos, R., Giese, H., Inverardi, P., Magee,

J., Andersson, J., Becker, B., Bencomo, N., Brun, Y.,

Cukic, B., Marzo Serugendo, G., Dustdar, S., Finkel-

stein, A., Gacek, C., Geihs, K., Grassi, V., Karsai, G.,

Kienle, H. M., Kramer, J., Litoiu, M., Malek, S., Mi-

randola, R., M

uller, H. A., Park, S., Shaw, M., Tichy,

M., Tivoli, M., Weyns, D., and Whittle, J. (2009).

Software engineering for self-adaptive systems: A re-

search roadmap. In Cheng, B. H., Lemos, R., Giese,

H., Inverardi, P., and Magee, J., editors, Software

Engineering for Self-Adaptive Systems, pages 1–26.

Springer-Verlag, Berlin, Heidelberg.

Craigen, D., Gerhart, S., and Ralston, T. (1993). An in-

ternational survey of industrial applications of formal

methods. In Z User Workshop, London 1992, pages

1–5. Springer.

De Jonge, M., Visser, E., and Visser, J. M. (2001). Collab-

orative software development. Citeseer.

Eker, J., Janneck, J. W., Lee, E. A., Liu, J., Liu, X., Ludvig,

J., Neuendorffer, S., Sachs, S., and Xiong, Y. (2003).

Taming heterogeneity - the ptolemy approach. In Pro-

ceedings of the IEEE, pages 127–144.

Feilkas, M., Fleischmann, A., H

olzl, F., Pfaller, C.,

Rittmann, S., Scheidemann, K., Spichkova, M., and

Trachtenherz, D. (2009). A Top-Down Methodology

for the Development of Automotive Software. Tech-

nical Report TUM-I0902, TU M

unchen.

Feilkas, M., Hlzl, F., Pfaller, C., Rittmann, S., Schtz, B.,

Schwitzer, W., Sitou, W., Spichkova, M., and Tra-

chtenherz, D. (2011). A Reﬁned Top-Down Method-

ology for the Development of Automotive Software

Systems - The KeylessEntry-System Case Study.

Technical Report TUM-I1103, TU M

unchen.

Fitzgerald, J. S., Larsen, P. G., and Larsen, P. (1995). For-

mal speciﬁcation techniques in the commercial devel-

opment process. In Position Papers from the Work-

shop on Formal Methods Application in Software En-

gineering Practice, International Conference on Soft-

ware Engineering (ICSE-17), Seattle.

Freitas, L. and Whiteside, I. (2014). Proof patterns for for-

mal methods. Springer.

Guiho, G. and Hennebert, C. (1990). Sacem software val-

idation. In Software Engineering, 1990. Proceed-

ings., 12th International Conference on, pages 186–

191. IEEE.

Hall, A. (1990). Seven myths of formal methods. Software,

IEEE, 7(5):11–19.

Huang, X., Kerber, M., Richts, J., and Sehn, A. (1994).

Planning mathematical proofs with methods. Elek-

tronische Informationsverarbeitung und Kybernetik,

30(5/6):277–291.

Jackson, D. (2001). Lightweight formal methods. In FME

2001: Formal Methods for Increasing Software Pro-

ductivity, pages 1–1. Springer.

Jeffery, R., Staples, M., Andronick, J., Klein, G., and Mur-

ray, T. (2015). An empirical research agenda for un-

derstanding formal methods productivity. Information

and Software Technology, 60:102–112.

Jones, C. B., Jackson, D., and Wing, J. (1996). Formal

methods light. Computer, 28(4):20–22.

Klein, G., Elphinstone, K., Heiser, G., Andronick, J., Cock,

D., Derrin, P., Elkaduwe, D., Engelhardt, K., Kolan-

ski, R., Norrish, M., Sewell, T., Tuch, H., and Win-

wood, S. (2009). sel4: Formal veriﬁcation of an os

kernel. In Proceedings of the ACM SIGOPS 22Nd

Symposium on Operating Systems Principles, SOSP

’09, pages 207–220, New York, NY, USA. ACM.

Knight, J. C., Hanks, K. S., and Travis, S. R. (2001). Tool

support for production use of formal techniques. In

Software Reliability Engineering, 2001. ISSRE 2001.

Proceedings. 12th International Symposium on, pages

242–251. IEEE.

uhnel, C. and Spichkova, M. (2007). Fault-Tolerant Com-

munication for Distributed Embedded Systems. In

Software Engineering and Fault Tolerance, Series on

Software Engineering and Knowledge Engineering.

Kuhrmann, M., Fern

andez, D. M., and Gr

ober, M. (2013).

Towards artifact models as process interfaces in dis-

tributed software projects. In Proceedings of the 2013

IEEE 8th International Conference on Global Soft-

ware Engineering, ICGSE ’13, pages 11–20, Wash-

ington, DC, USA. IEEE Computer Society.

Lee, G., DeLone, W., and Espinosa, J. A. (2006). Ambidex-

trous coping strategies in globally distributed software

development projects. Commun. ACM, 49(10):35–40.

Formal Methods in Collaborative Projects

401

Maier, A. and Hess, S. (2014). We need non-formal meth-

ods based on formal models in interaction design.

In Building Bridges: HCI, Visualization, and Non-

formal Modeling, pages 150–164. Springer.

Mandrioli, D. (2015). On the heroism of really pursu-

ing formal methods. In Formal Methods in Software

Engineering (FormaliSE), 2015 IEEE/ACM 3rd FME

Workshop on, pages 1–5. IEEE.

Melis, E. and Schairer, A. (1998). Similarities and reuse of

proofs in formal software veriﬁcation. In Advances in

Case-Based Reasoning, pages 76–87. Springer.

Newcombe, C., Rath, T., Zhang, F., Munteanu, B., Brooker,

M., and Deardeuff, M. (2015). How amazon web ser-

vices uses formal methods. Communications of the

ACM, 58(4):66–73.

Osaiweran, A., Schuts, M., Hooman, J., Groote, J. F., and

van Rijnsoever, B. (2015). Evaluating the effect of

a lightweight formal technique in industry. Inter-

national Journal on Software Tools for Technology

Transfer, pages 1–16.

Portillo-Rodr

ıguez, J., Vizca

ıno, A., Piattini, M., and

Beecham, S. (2012). Tools used in global software

engineering: A systematic mapping review. Inf. Softw.

Technol., 54(7):663–685.

RuleBase, I. (2015). Ibm rulebase homepage.

Schuts, M. and Hooman, J. (2015). Formalizing the concept

phase of product development. In FM 2015: Formal

Methods, pages 605–608. Springer.

Snook, C. and Harrison, R. (2001). Practitioners’ views

on the use of formal methods: an industrial survey by

structured interview. Information and Software Tech-

nology, 43(4):275–283.

Spichkova, M. (2013). Design of formal languages and

interfaces:formal does not mean unreadable. IGI

Global.

Spichkova, M., H

olzl, F., and Trachtenherz, D. (2012). Ver-

iﬁed System Development with the AutoFocus Tool

Chain. In 2nd Workshop on Formal Methods in the

Development of Software, WS-FMDS.

Staples, M., Jeffery, R., Andronick, J., Murray, T., Klein,

G., and Kolanski, R. (2014). Productivity for proof

engineering. In Proceedings of the 8th ACM/IEEE In-

ternational Symposium on Empirical Software Engi-

neering and Measurement, page 15. ACM.

Stidolph, D. C. and Whitehead, J. (2003). Managerial is-

sues for the consideration and use of formal meth-

ods. In FME 2003: Formal Methods, pages 170–186.

Springer.

Trkman, M., Vrhovec, S., Vavpoti?, D., and Krisper, M.

(2013). Defending the need for a new global soft-

ware approach: A literature review. In Informa-

tion Communication Technology Electronics Micro-

electronics (MIPRO), 2013 36th International Con-

vention on, pages 199–202.

Whitehead, J., Mistr

ık, I., Grundy, J., and van der Hoek, A.

(2010). Collaborative software engineering: Concepts

and techniques. In Collaborative Software Engineer-

ing, pages 1–30. Springer.

Wiegers, K. E. (2001). Inspecting requirements. Sticky-

Minds. com.

Woodcock, J., Larsen, P. G., Bicarregui, J., and Fitzgerald,

J. (2009). Formal methods: Practice and experience.

ACM Computing Surveys (CSUR), 41(4):19.

Zave, P. (2012). Using lightweight modeling to understand

chord. ACM SIGCOMM Computer Communication

Review, 42(2):49–57.

Zhiming, C., Zhe, Y., Menghan, W., and Jiangling, Y.

(2014). The agents coordination and templates aggre-

gation in distributed modeling. International Journal

of Hybrid Information Technology, 7(2):369–378.

Zimmerman, M. K., Lundqvist, K., and Leveson, N. (2002).

Investigating the readability of state-based formal re-

quirements speciﬁcation languages. In Proceedings of

the 24th International Conference on Software engi-

neering, pages 33–43. ACM.

COLAFORM 2016 - Special Session on Collaborative Aspects of Formal Methods

402