Implementing the Verified Software Initiative Benchmarks using Perfect Developer

This paper describes research on the Perfect Developer tool and its associated programming language, Perfect. We focus on verification benchmarks that have been presented as part of the Verified Software Initiative (VSI), proposing their specification, implementation and verification in the Perfect language and the Perfect Developer tools. To the best of our knowledge this is the first attempt to meet these benchmarks using the Perfect Developer tools. Our aim is to implement the benchmarks and analyze how well the Perfect language can be used to express these benchmarks. In this paper we present the first benchmark, its specification and its verification in the Perfect Developer tool suite

Implementing the Verified Software Initiative Benchmarks using Perfect Developer

This paper describes research on the Perfect Developer tool and its associated programming language, Perfect. We focus on seven verification benchmarks that have been presented as part of the Verified Software Initiative (VSI), proposing their specification, implementation and verification in the Perfect language and the Perfect Developer tools. To the best of our knowledge this is the first attempt to meet these benchmarks using the Perfect Developer tools and the first full presentation of solutions to these benchmarks in any verification support tool. Our aim is to implement the benchmarks and analyse how well the Perfect language can be used to express these benchmarks. Furthermore, we provide suggestions on how to make the Perfect language and Perfect Developer better

Requirements analysis of the VoD application using the tools in TRADE

This report contains a specification of requirements for a video-on-demand (VoD) application developed at Belgacom, used as a trial application in the 2RARE project. The specification contains three parts: an informal specification in natural language; a semiformal specification consisting of a number of diagrams intended to illustrate the informal specification; and a formal specification that makes the requiremants on the desired software system precise. The informal specification is structured in such a way that it resembles official specification documents conforming to standards such as that of IEEE or ESA. The semiformal specification uses some of the tools in from a requirements engineering toolkit called TRADE (Toolkit for Requirements And Design Engineering). The purpose of TRADE is to combine the best ideas in current structured and object-oriented analysis and design methods within a traditional systems engineering framework. In the case of the VoD system, the systems engineering framework is useful because it provides techniques for allocation and flowdown of system functions to components. TRADE consists of semiformal techniques taken from structured and object-oriented analysis as well as a formal specification langyage, which provides constructs that correspond to the semiformal constructs. The formal specification used in TRADE is LCM (Language for Conceptual Modeling), which is a syntactically sugared version of order-sorted dynamic logic with equality. The purpose of this report is to illustrate and validate the TRADE/LCM approach in the specification of distributed, communication-intensive systems

Analysing Process Models Quantitatively

Over the years, there has been much interest in modelling processes. Processes include those associated with the development of software and those business processes that make use of software systems. Recent research in Systems Engineering for Business Process Change highlights the importance of modelling business processes in order to evolve and maintain the legacy systems that support those processes. Business processes are typically described with static (diagrammatic) models. This paper illustrates how quantitative techniques can facilitate analysis of such models. This is illustrated with reference to the process modelling notation Role Activity Diagrams (RADs). An example process, taken from an investigation of the bidding process of a large telecommunications systems supplier, is used to show how a quantitative approach can be used to highlight features in RADs that are useful to the process modeller. We show how simple measures reveal high levels of role coupling and discrepancies between different perspectives. Since the models are non-trivial — there are 101 roles and almost 300 activities — we argue that quantitative analysis can be a useful adjunct for the modeller

Role clarity deficiencies can wreck agile teams

Background One of the twelve agile principles is to build projects around motivated individuals and trust them to get the job done. Such agile teams must self-organize, but this involves conflict, making self-organization difficult. One area of difficulty is agreeing on everybody’s role. Background What dynamics arise in a self-organizing team from the negotiation of everybody’s role? Method We conceptualize observations from five agile teams (work observations, interviews) by Charmazian Grounded Theory Methodology. Results We define role as something transient and implicit, not fixed and named. The roles are characterized by the responsibilities and expectations of each team member. Every team member must understand and accept their own roles (Local role clarity) and everbody else’s roles (Team-wide role clarity). Role clarity allows a team to work smoothly and effectively and to develop its members’ skills fast. Lack of role clarity creates friction that not only hampers the day-to-day work, but also appears to lead to high employee turnover. Agile coaches are critical to create and maintain role clarity. Conclusions Agile teams should pay close attention to the levels of Local role clarity of each member and Team-wide role clarity overall, because role clarity deficits are highly detrimental