Using problem frames with distributed architectures: a case for cardinality on interfaces

Certain classes of problems amenable to description using Problem Frames, in particular ones intended to be implemented using a distributed architecture, can benefit by the addition of a cardinality specification on the domain interfaces. This paper presents an example of such a problem, demonstrates the need for relationship cardinality, and proposes a notation to represent cardinality on domain interfaces

The significance of participant experience when evaluating software inspection techniques

Software inspections have been used to improve software quality for 30 years. The Checklist Based Reading strategy has traditionally been the most prevalent reading strategy. Increased Object Oriented usage has raised questions regarding this techniques efficacy, given issues such as delocalisation. This study compared two inspection techniques: Use-Case Reading and Usage-Based Reading, with Checklist Based Reading. Students and industry professionals were recruited to participate in the study. The effectiveness of each reading strategy was analysed, and the effect experience had on inspection efficacy. The results showed no significant difference between inspection techniques,whether used by student or professional developers but a significant difference was identified between student and professional developers in applying the different techniques. Qualitative results highlighted the differences in ability between industry and students with respect to what each group considered important when inspecting and writing code. These results highlight the differences between student and industry professionals when applying inspections. Therefore, when selecting participants for empirical software engineering studies, participant experience level must be accounted for within the reporting of results

Going on-line on a shoestring: An experiment in concurrent development of requirements and architecture

A number of on-line applications were built for a small university using a micro-sized development team. Four ideas were tested during the project: the Twin Peaks development model, using fully functional prototypes in the requirements elicitation process, some core practices of Extreme Programming, and the use of open-source software in a production environment. Certain project management techniques and their application to a micro-sized development effort were also explored. These ideas and techniques proved effective in developing many significant Internet and networked applications in a short time and at very low cost

Tool support for statistical testing of software components

We describe the "STSC" prototype tool that supports the statistical testing of software components. The tool supports a wide range of operational profiles and test oracles for test case generation and output evaluation. The tool also generates appropriate values for different types of input parameters of operations. STSC automatically generates a test driver from an operational profile. This test driver invokes a test oracle that is implemented as a behaviour-checking version of the implementation. To evaluate the flexibility and usability of the tool, it has been applied to several case studies using different types of operational profiles and test oracles

Some rules to transform sequence diagrams into coloured Petri nets

This paper presents a set of rules that allows software engineers to transform the behavior described by a UML 2.0 Sequence Diagram (SD) into a Colored Petri Net (CPN). SDs in UML 2.0 are much richer than in UML 1.x, namely by allowing several traces to be combined in a unique diagram, using high-level operators over interactions. The main purpose of the transformation is to allow the development team to construct animations based on the CPN that can be shown to the users or the clients in order to reproduce the expected scenarios and thus validate them. Thus, non-technical stakeholders are able to discuss and validate the captured requirements. The usage of animation is an important topic in this context, since it permits the user to discuss the system behavior using the problem domain language. A small control application from industry is used to show the applicability of the suggested rules

Understanding the Benefits of Agile Software Development in Regulated Environments

Agile software development has become increasingly popular in recent years. Applying agile methods, companies expect flexible planning, early delivery of the software product, and a continuous improvement of the development process itself. However, in regulated environments the use of agile development is not yet common practice. In such environments, various regulatory requirements apply which affect the software development process. This paper examines the use of agile software development in the regulated medical device industry and explores reasons for using agile methods although their use is limited. We interviewed agile software development teams in three different companies using semi-structured interviews. Using grounded theory methodology, we identify reasons why companies are using agile methods, even though problems and barriers exist. Our main achievement is the development of four categories, which describe the benefit of agile software development in regulated environments. These categories are master complexity, reduce effort, improve usability, and promote collaboration

Clustering and its Application in Requirements Engineering

Large scale software systems challenge almost every activity in the software development life-cycle, including tasks related to eliciting, analyzing, and specifying requirements. Fortunately many of these complexities can be addressed through clustering the requirements in order to create abstractions that are meaningful to human stakeholders. For example, the requirements elicitation process can be supported through dynamically clustering incoming stakeholders’ requests into themes. Cross-cutting concerns, which have a significant impact on the architectural design, can be identified through the use of fuzzy clustering techniques and metrics designed to detect when a theme cross-cuts the dominant decomposition of the system. Finally, traceability techniques, required in critical software projects by many regulatory bodies, can be automated and enhanced by the use of cluster-based information retrieval methods. Unfortunately, despite a significant body of work describing document clustering techniques, there is almost no prior work which directly addresses the challenges, constraints, and nuances of requirements clustering. As a result, the effectiveness of software engineering tools and processes that depend on requirements clustering is severely limited. This report directly addresses the problem of clustering requirements through surveying standard clustering techniques and discussing their application to the requirements clustering process

Assisting software architects in architectural decision-making using Quark

Non-Functional Requirements (NFRs) and constraints are among the principal drivers of architectural decision-making. NFRs are improved or damaged by architectural decisions (ADs), while constraints directly include or exclude parts of the architecture (e.g., logical components or technologies). We may determine the impact of an AD, or which parts of the architecture are affected by a constraint, but at the end it is hard to know if we are respecting the NFRs and the imposed constraints with all the ADs made. In the usual approach, architects use their own experience to produce software architectures that comply with the NFRs and imposed constraints, but at the end, especially for crucial decisions, the architect has to deal with complex trade-offs between NFRs and juggle with possible incompatibilities raised by the imposed constraints. In this paper we present Quark, a method to assist software architects in architectural decision-making, and the conceptualization of the relationship between NFRs and ADs defined in Arteon, an ontology to represent and manage architectural knowledge. Finally, we provide an overview of the Quark and Arteon implementation, the ArchiTech tool.Peer ReviewedPostprint (published version