Abstract Blockchain has attracted broad interests to build decentralised applications. A typical class of applications uses blockchain for the management of cross‐organisational business processes as well as assets. However, developing such applications without introducing vulnerabilities is hard for developers, not the least because the deployed code is immutable and can be called by anyone with access to the network. Model‐driven engineering (MDE) helps to reduce those risks, by combining proven code snippets as per the model specification, which is easier to understand than source code. Therefore, in this article, we present an approach for integrated MDE across business processes and asset management (e.g., for settlement). Our approach includes methods for fungible/non‐fungible asset registration, escrow for conditional payment, and asset swap. The proposed MDE approach is implemented in a smart contract generation tool called Lorikeet, and evaluated in terms of feasibility, functional correctness, and cost effectiveness.

Formal verification can provide the highest degree of software assurance. Demand for it is growing, but there are still few projects that have successfully applied it to sizeable, real-world systems. This lack of experience makes it hard to predict the size, effort and duration of verification projects. In this paper, we aim to better understand possible leading indicators of proof size. We present an empirical analysis of proofs from the landmark formal verification of the seL4 microkernel and the two largest software verification proof developments in the Archive of Formal Proofs. Together, these comprise 15,018 individual lemmas and approximately 215,000 lines of proof script. We find a consistent quadratic relationship between the size of the formal statement of a property, and the final size of its formal proof in the interactive theorem prover Isabelle. Combined with our prior work, which has indicated that there is a strong linear relationship between proof effort and proof size, these results pave the way for effort estimation models to support the management of large-scale formal verification projects.

Context: Recent projects such as L4.verified (the verification of the seL4 microkernel) have demonstrated that large-scale formal program verification is now becoming practical.

Size and effort estimation is a significant challenge for the management of large-scale formal verification projects. We report on an initial study of relationships between the sizes of artefacts from the development of seL4, a formally-verified embedded systems microkernel. For each API function we first determined its COSMIC Function Point (CFP) count (based on the seL4 user manual), then sliced the formal specifications and source code, and performed a normalised line count on these artefact slices. We found strong and significant relationships between the sizes of the artefact slices, but no significant relationships between them and the CFP counts. Our finding that CFP is poorly correlated with lines of code is based on just one system, but is largely consistent with prior literature. We find CFP is also poorly correlated with the size of formal specifications. Nonetheless, lines of formal specification correlate with lines of source code, and this may provide a basis for size prediction in future formal verification projects. In future work we will investigate proof sizing.

Background- Risks associated with a software project have the potential to affect all stakeholders. Today much software makes use of off-the-shelf (OTS) components. A better understanding of OTS-derived software risks will help to define responsibilities for these risks, and also to avoid them. Aim- Our objective is to identify, classify and compare risks of OTS-based software projects from both a software development and a software acquisition perspective. Method- To identify and classify the risks, we performed a systematic mapping study. In order to compare risks of OTS-based software development and acquisition in the real world setting, we used the mapping study results to survey occurrences of 11 shared risks in OTS-based software, in 35 OTS-based software developments and 34 OT-Sbased software acquisitions of Indonesian background. The survey is a partial replication of a previous study. Results- We identified 133 risks associated with OTS-based software development and 36 risks associated with OTS-based software acquisition. These risks are grouped into 17 risk categories. Risks occurred more frequently in software acquisition than in software development. In addition, two risks, insufficient OTS component documents and lack of provider technical support and training, frequently occurred only in the software development. Conclusions- In OTS-based projects, most risks for acquisition and development are similar. Technical-related risks are found less often in acquisition and project management related risks are found less often in development. Shared risks are perceived differently by developers and acquirers. Better understanding of actual and perceived risk in OTS-based software projects will improve risk management. Further work to validate these results is ongoing.

Background: Change propagation analysis helps predict the parts of the software that may be affected if a change is made. Existing research on change propagation focuses on design and code level changes. However, as a software evolves, the requirements that drive these changes also have intricate dependencies. Understanding the effect of these requirement dependencies on change prorogation is useful but not trivial. More than twenty requirements dependency types have been identified in the literature, however there still lacks an evaluation of the applicability of these dependency types in requirements and change propagation analysis. Aim: We aim to investigate whether these dependency types are useful for change propagation analysis. Method: We conducted a case study in a real-world industry project. This case study evaluates two representative dependency models covering twenty five types of dependencies. Results: Our initial evaluation has found that five dependency types are particularly useful in change propagation analysis and practitioners with different backgrounds have various viewpoints on change propagation. Thus change impact analysis should involve a wide range of stakeholders including project managers, requirements engineers, designers and developers. Conclusions: Our case study provides insights into requirements dependencies and their effects on change propagation analysis for both research and practice.

Background: Software systems must evolve in order to adapt in a timely fashion to the rapid changes of stakeholder needs, technologies, business environment and society regulations. Numerous studies have shown that cost, schedule or defect density of a software project may escalate as the requirements evolve. Requirements evolution management has become one important topic in requirements engineering research. Aim: To depict a holistic state-of-the-art of requirement evolution management. Method: We undertook a systematic review on requirements evolution management. Results: 125 relevant studies were identified and reviewed. This paper reports the preliminary results from this review: (1) the terminology and definition of requirements evolution; (2) fourteen key activities in requirements evolution management; (3) twenty-eight metrics of requirements evolution for three measurement goals. Conclusions: Requirements evolution is a process of continuous change of requirements in a certain direction. Most existing studies focus on how to deal with evolution after it happens. In the future, more research attention on exploring the evolution laws and predicting evolution is encouraged.

Project stakeholders can have different perceptions of risks and how they should be mitigated, but these differences are not always well understood and managed. This general issue occurs in Off-the-shelf (OTS)-based custom software development projects, which use and integrate OTS software in the development of specialized software for an individual customer. We report on a study of risk perceptions for developers and acquirers in OTS-based custom software development projects. The study used an online questionnaire-based survey. We compared stakeholders' perceptions about their level of control over and exposure to 11 shared risks in OTS-based software, in 35 OTS-based software developments and 34 OTS-based software acquisitions of Indonesian background. We found that both stakeholders can best control, and are most impacted by, risks about requirements negotiation. In general stakeholders agree who can best control risks (usually the developer), but there were different perceptions about who is most impacted by risks (the developer reported either themselves or both stakeholders; while usually the acquirer reported both stakeholders). In addition, both stakeholders agree that the acquirer is most impacted by the risk of reduced control of future evolution of the system. We also found disagreement about who is most impacted by the risk of lack of support (usually each stakeholder reported themselves). This paper makes two main contributions. First, the paper presents a method based on stakeholder analysis to compare perceptions of the respondents about which stakeholder is affected by and can control risks. Second, knowing stakeholder agreement on which stakeholder has high risk control should be helpful to rationalize responsibility for risks.

The L4.verified project was a rare success in large-scale, formal verification: it provided a formal, machine-checked, code-level proof of the full functional correctness of the seL4 microkernel. In this paper we report on the development process and management issues of this project, highlighting key success factors. We formulate a detailed descriptive model of its middle-out development process, and analyze the evolution and dependencies of code and proof artifacts. We compare our key findings on verification and re-verification with insights from other verification efforts in the literature. Our analysis of the project is based on complete access to project logs, meeting notes, and version control data over its entire history, including its long-term, ongoing maintenance phase. The aim of this work is to aid understanding of how to successfully run large-scale formal software verification projects.

SUMMARY Software process modeling and simulation have become effective tools for support of software process management and improvement over the past two decades. They have recently been integrated into the Trustworthy Process Management Framework (TPMF) as the infrastructural components to facilitate the delivery of trustworthy software products. This paper proposes the concept of Trustworthy Software Process Models as inputs to TPMF and introduces transformable process modeling for supporting effective and productive development of trustworthy process models. Furthermore, this paper undertakes an exploratory study on process model transformation by investigating and comparing process modeling semantics between quantitative (e.g., System Dynamics, SD) and qualitative forms of modeling and simulation. By following the model transformation scheme, a quantitative continuous (SD) software evolution process model is successfully transformed into its qualitative form for simulation. The results present the different capabilities and performance between these two modeling paradigms, as well as the possible benefits and interesting perspectives of transformable process modeling. Copyright © 2010 John Wiley & Sons, Ltd.

Process simulation has become a powerful technology in support of software project management and process improvement over the past decades. This research, inspired by the Impact Project, intends to investigate the technology transfer of software process simulation to the use in industrial settings, and further identify the best practices to release its full potential in software practice. We collected the reported applications of process simulation in software industry, and identified its wide adoption in the organizations delivering various software intensive systems. This paper, as an initial report of the research, briefs a historical perspective of the impact upon practice based on the documented evidence, and also elaborates the research-practice transition by examining one detailed case study. It is shown that research has a significant impact on practice in this area. The analysis of impact trace also reveals that the success of software process simulation in practice highly relies on the association with other software process techniques or practices and the close collaboration between researchers and practitioners.

There is growing interest in applying Scrum practices in Global Software Development to leverage the advantages of both. However, the effective use of Scrum practices largely depends on close interactions between project stakeholders. The distribution of project stakeholders in GSD provides significant challenges related to project collaboration processes that may limit the use of Scrum. However, project managers increasingly seek to use the Scrum model in their distributed projects. While there is an emerging body of industrial experience, there are limited empirical studies that discuss Scrum tailoring in GSD. The paper reports a multi-case study that investigates the impact of key project contextual factors on the use of Scrum practices in GSD. This study is relevant to researchers and practitioners who are seeking ways to use Scrum in GSD and improve project effectiveness.

This talk reflects on different types of research into process carried out within the software and systems engineering community in recent years. For example, work in the domains of business process, medical systems, electrical systems and software development is considered. Extensive research at NICTA on business processes in the LIXI project as well as activities with the Australian Department of Defence, amongst others, are used to provide substantial experience and insight into both the opportunities for software and systems engineering research and the insalubrious temptations that may face researchers working in this area.

Software cost estimation is a crucial yet very difficult task for a project manager at the very beginning of a new project. Since software projects are always different in nature, past projects may not necessarily cover all aspects of a new project when used as a basis for cost estimation. The CoBRA hybrid cost estimation technique uses expert knowledge to build a causal model of context-specific cost factors and past project data to predict costs in terms of effort as well as to assess the risks of a project. Further practical advantages of CoBRA are its high level of interpretability and its transparency. While our previous studies have shown that a modified CoBRA called Web-CoBRA produces higher prediction accuracy, the method was not fully adopted by our industry partner because of its complex application steps when it is manually performed. In this paper, we report on our experiences with further automating Web-CoBRA based software cost estimation for a software company. It supports group decision-making processes by utilizing a wideband Delphi technique. We identify a range of problems when applying Web-CoBRA in the context of a software company and describe the approaches we used to solve these problems in our new tool called EffortWatch. Furthermore, we report on the evaluation and the effectiveness of EffortWatch using a technology acceptance model (TAM) questionnaire. The result is then compared with a previous study, showing EffortWatch drastically improves the use of the Web-CoBRA technique.

Abstract Data-intensive analogy has been proposed as a means of software cost estimation as an alternative to other data intensive methods such as linear regression. Unfortunately, there are drawbacks to the method. There is no mechanism to assess its appropriateness for a specific dataset. In addition, heuristic algorithms are necessary to select the best set of variables and identify abnormal project cases. We introduce a solution to these problems based upon the use of the Mantel correlation randomization test called Analogy-X. We use the strength of correlation between the distance matrix of project features and the distance matrix of known effort values of the dataset. The method is demonstrated using the Desharnais dataset and two random datasets, showing (1) the use of Mantel's correlation to identify whether analogy is appropriate, (2) a stepwise procedure for feature selection, as well as (3) the use of a leverage statistic for sensitivity analysis that detects abnormal data points. Analogy-X, thus, provides a sound statistical basis for analogy, removes the need for heuristic search and greatly improves its algorithmic performance.

Software process improvement has been a focus of industry for many years. To assist the procedure and implementation of process improvement we provide a software process recovery method based on mining project enactment data. The goal of the method is to uncover the actual process used in order to provide input to improve the quality of a defined software process. The recovered model (or patterns) is at the same level of abstraction as the predefined process model. This provides an easy and clear way to identify the gap between the planned process model and the real enactment. We investigate the enactment of a defined software process from the view of understanding the appropriateness and fitness for purpose of the process model from the viewpoint of the project managers in the context of a small software development organization. We collected data from organizations and applied our method to a pilot case study. The main contribution of our work is to provide a software process model recovery method which supports software process change and improvement.

This paper presents the lessons learnt during the analysis of the corporate databases developed by IBM Global Services (Australia). IBM is rated as CMM level 5. Following CMM level 4 and above practices, IBM designed several software metrics databases with associated data collection and reporting systems to manage its corporate goals. However, IBM quality staff believed the data were not as useful as they had expected. NICTA staff undertook a review of IBM's statistical process control procedures and found problems with the databases mainly due to a lack of links between the different data tables. Such problems might be avoided by using M3P variant of the GQM paradigm to define a hierarchy of goals, with project goals at the lowest level, then process goals and corporate goals at the highest level. We propose using E-R models to identify problems with existing databases and to design databases once goals have been defined.

Software architecture evaluation is an effective means of addressing quality related issues early in the software development lifecycle. Scenario-based approaches to evaluate architecture usually involve a large number of stakeholders, who need to be collocated for face-to-face evaluation meetings. Collocating a large number of stakeholders is an expensive and time-consuming exercise, which may prove to be a hurdle in the wide-spread adoption of disciplined architectural evaluation practices. Drawing upon the successful introduction of groupware applications to support geographically distributed teams in software inspection, and requirements engineering disciplines, we propose the concept of distributed architectural evaluation using Internet-based collaborative technologies. This paper presents a pilot study used to assess the viability of a larger experiment intended to investigate the feasibility of groupware support for distributed software architecture evaluation. In addition, the results of the pilot study provide some preliminary findings on the viability of groupware-supported software architectural evaluation process.

In this paper, we present an approach to improve the software architecture evaluation process by systematically extracting and appropriately documenting architecturally significant information from software architecture and design patterns; we are interested in only two pieces of information found in software patterns: general scenarios and architectural tactics. General scenarios distilled from patterns not only assist stakeholders in developing concrete scenarios during a scenario-based architecture evaluation, but can also help an architect select and calibrate a quality attribute reasoning framework. Architectural tactics in patterns are used as a means of manipulating independent parameters in the reasoning framework to achieve the desired quality. Moreover, we believe if we use general scenarios and tactics extracted from patterns in an architectural evaluation, the results of that evaluation can be used as an evidence to validate the pattern's claim with respect to the quality attributes. We demonstrate our approach by using EJB architecture usage patterns. We contend that this approach can be used to analyze and validate any architecture pattern.

In the original theory of group performance in software development technical reviews there was no consideration given to the influence of the inspection process, inspection performance, or the inspected artifact, on the structure of the theoretical model. We present an extended theoretical model, along with discussion and justification for components of the new model. These extensions include consideration of the software product quality attributes, the prescriptive processes now developed for reviews, and a more detailed consideration of the technical and nontechnical characteristics of the inspectors. We present both the structure of the model and the nature of the interactions between elements in the model. Consideration is also given to the opportunity for increased formalism in the technical review process. We show that opportunity exists to both improve industrial practice and extend research-based knowledge of the technical review process and context.

In this paper, we investigate the application of the COBRA/spl trade/ method (Cost Estimation, Benchmarking, and Risk Assessment) in a new application domain, the area of web development. COBRA combines expert knowledge with data on a small number of projects to develop cost estimation models, which can also be used for risk analysis and benchmarking purposes. We modified and applied the method to the web applications of a small Australian company, specializing in web development. In this paper we present the modifications made to the COBRA method and results of applying the method In our study, using data on twelve web applications, the estimates derived from our Web-COBRA model showed a Mean Magnitude of Relative Error (MMRE) of 0.17. This result significantly outperformed expert estimates from Allette Systems (MMRE 0.37). A result comparable to Web-COBRA was obtained when applying ordinary least squares regression with size in terms of Web Objects as an independent variable (MMRE 0.23).

Our activities in software engineering typically fall into one of three categories, (1) to invent new phenomena, (2) to understand existing phenomena, and (3) to facilitate inspirational education. This paper explores the place of empirical software engineering in the first two of these activities. In this exploration evidence is drawn from the empirical literature in the areas of software inspections and software cost modelling and estimation. This research is then compared with the literature published in the Journal of Empirical Software Engineering. This evidence throws light on aspects of theory derivation, experimental methods and analysis, and also the challenges that we face as empirical software engineering evolves into the future.

This paper presents the design, implementation and evaluation of an experience repository in a small software organisation. The experience repository was developed and installed as part of an ongoing software process improvement effort and uses software process to structure experience and make it available for reuse. The experience repository is accessed through a web-based process guide with experiences related to particular tasks linked directly to the pages describing those tasks. This way experiences, including examples of documents, checklists or unstructured experiences such as anecdotes and lessons learnt can be easily entered and retrieved by users when required. This paper presents the design of the repository, the implementation and preliminary results regarding its acceptance and use.

Software engineers use a number of different types of software development technical review (SDTR) for the purpose of detecting defects in software products. This paper applies the behavioral theory of group performance to explain the outcomes of software reviews. A program of empirical research is developed, including propositions to both explain review performance and identify ways of improving review performance based on the specific strengths of individuals and groups. Its contributions are to clarify our understanding of what drives defect detection performance in SDTRs and to set an agenda for future research. In identifying individuals' task expertise as the primary driver of review performance, the research program suggests specific points of leverage for substantially improving review performance. It points to the importance of understanding software reading expertise and implies the need for a reconsideration of existing approaches to managing reviews.

Effective management of the software development process requires that management be able to estimate total development effort and cost. One of the fundamental problems associated with effort and cost estimation is the a priori estimation of software size. Function point analysis has emerged over the last decade as a popular tool for this task. Criticisms of the method that relate to the way in which function counts are calculated and the impact of the processing complexity adjustment on the function point count have arisen. SPQR/20 function points among others are claimed to overcome some of these criticisms. The SPQR/20 function point method is compared to traditional function point analysis as a measure of software size in an empirical study of MIS environments. In a study of 64 projects in one organization it was found that both methods would appear equally satisfactory. However consistent use of one method should occur since the individual counts differ considerably.>

The authors report the results of an empirical research project on the consistency and limitations of the number of function points as an a priori measure of system size rather than the traditional lines-of-code measure. They conclude that function points are a more consistent a priori measure of system size. The results also indicate that the function-point estimate of size is lower for analysts experienced both in software development and in function-point estimation.>

Current time-sensitive cost models suggest a significant impact on project effort if elapsed time compression or expansion is implemented. This paper reports an empirical study into the applicability of these models in the management information systems environment. It is found that elapsed time variation does not consistently affect project effort. This result is analyzed in terms of the theory supporting such a relationship, and an alternate relationship is suggested.