Colin J. Neill

Requirements engineering: the state of the practice

Little contemporary data exists for document actual practices of software professionals for software requirements elicitation, requirements specification, document development, and specification validation. This exploratory survey and its quantitative results offer opportunities for further interpretation and comparison.

Real-time Industrial Visual Inspection: A Review

Abstract This paper provides a review of state-of-the-art techniques and technologies associated with real-time automated visual inspection as applied in industrial situations. A survey of the most widely used machine vision algorithms is presented, with emphasis on those algorithms most suited to real-time application. Practical illumination schemes for real-time industrial inspection are also considered. The paper then focusses on areas which have received scant attention from the research community but which look set to become increasingly important in the next few years, namely system robustness and verification, including temporal verification.

The Demise of the Waterfall Model Is Imminent

We discovered this and other disappointing indicators about current software engineering practices in a recent survey of almost 200 software professionals. These discoveries raise questions about perception versus reality with respect to the nature of software engineers, software engineering practice, and the industry.

State of practice in requirements engineering: contemporary data

Little contemporary data exists that documents software requirements elicitation, requirements specification, document development, and specification validation practices. An exploratory survey of more than 3,000 software professionals was conducted and nearly 250 responses were obtained. Survey data obtained includes characteristics of projects, practices, organizations, and practitioners related to requirements engineering. Selected results are presented along with interpretations of this data.

Integrating a software architecture-centric method into object-oriented analysis and design

The choice of methodology for the development of the architecture for software systems has a direct effect on the suitability of that architecture. If the development process is driven by the users functional requirements, we would expect the architecture to appropriately reflect those requirements. We would also expect other aspects not captured in the functional specification to be absent from the architecture. The same phenomenon is true in development approaches that stress the importance of systemic quality attributes or other non-functional requirements; those requirements are prominent in the resulting architecture, while other requirement types not stressed by the approach are absent. In other words, the final architecture reflects the focus of the development approach. An ideal approach, therefore, is one that incorporates all goals, expectations, and requirements: both business and technical. To accomplish this we have incorporated, into a single architectural development process, generalized Object-Oriented Analysis and Design (OOAD) methodologies with the software architecture-centric method, the Quality Attribute Workshop (QAW) and Attribute Driven Design (ADD). OOAD, while relatively intuitive, focuses heavily on functional requirements and has the benefit of semantic closeness to the problem domain making it an intuitive process with comprehendible results. Architecture-centric approaches, on the other hand, provide explicit and methodical guidance to an architect in creating systems with desirable qualities and goals. They provide minimal guidance in determining fine-grained architecture, however. The integrated approach described in this paper maximizes the benefits of the respective processes while eliminating their flaws and was applied in a eight university, global development research project with great success. A case study from that experiment is included here to demonstrate the method.

A cognitive collaborative model to improve performance in engineering teams—A study of team outcomes and mental model sharing

Working collaboratively in teams is an essential element in systems engineering: Interdisciplinary teams are formed to tackle large-scale, heterogeneous problems requiring skill and knowledge across a wide array of engineering and technical disciplines. While this is widely accepted as necessary, little attention is given to the problem of ensuring effective collaboration across the diverse team. Attention is given to the processes that will be followed, and tools are provided to aid communication; but the critical cognitive aspects that ensure that the team works effectively and efficiently towards a common objective are frequently absent. Instead, managers and team members assume that their disparate mental models have no impact on their collaborative efforts, or that any cognitive dissonance will evaporate naturally and organically. In reality, neither assumption is true, and if these issues are not directly addressed, a team will fall into cooperative rather than collaborative work, which is less effective and efficient. We introduce a framework, the Cognitive Collaborative Model, that explicitly promotes the cognitive collaborative processes necessary for effective engineering teams, and demonstrate its effectiveness in controlled system design and development experiments. Further, we investigate whether this improvement is due to convergence of the individual team member mental models into a shared, or team, mental model, often cited as the basis for high-performing teams. Finally, we propose a novel multistage evaluation process for mental model convergence using concept maps and Pathfinder analysis.

Paying down design debt with strategic refactoring

Our studies indicate that strategic refactoring using design patterns is the most effective way to repair decaying code for object-oriented (OO) systems. However, applying a pattern-based approach to legacy system repair or even post-design pattern injection is often difficult and, in some cases if misapplied, detrimental

How Business Goals Drive Architectural Design

This paper illustrates how business goals can significantly impact a software management systems architecture without necessarily affecting its functionality. These goals include 1) supporting hardware devices from different manufacturers, 2) considering language, culture, and regulations of different markets, 3) assessing tradeoffs and risks to determine how the product should support these goals, 4) refining goals such as scaling back on intended markets, depending on the companys comfort level with the tradeoffs and risks. More importantly, these business goals correspond to quality attributes the end system must exhibit. The system must be modifiable to support a multitude of hardware devices and consider different languages and cultures. Supporting different regulations in different geographic markets requires the system to respond to life-threatening events in a timely manner performance requirement.

Modeling uncertainty in software engineering using rough sets

Abstract.Uncertainty casts a shadow over all facets of software engineering. This negative meta-property is found in every aspect of software including requirement specifications, design, and code. It can also manifest itself in the tools and engineering practices employed, and in the off-the-shelf software incorporated into the final product. Unfortunately, it is often the case that software engineers ignore these sources of uncertainty or abstract them away. Perhaps this is because there is insufficient understanding of this uncertainty, and no universal techniques for handling its many forms. This paper focuses on the issues of uncertainty in software engineering. It further describes a rough set framework for making decisions in the face of such uncertainty and inconsistency. In particular, we show how to induce rule-based decision making from uncertain information in software engineering applications. Moreover, a freely available tool, Rosetta, is employed to automate the decision-making process. NASA has mandated the use of commercial off-the-shelf (COTS) solutions where possible. But in commercial real-time operating systems certain attributes are uncertain, even where published information is available. Therefore, the selection of a commercial real-time operating system for an embedded system is the software engineering problem with which we explain the rough set decision-making process.

The extreme programming bandwagon: revolution or just revolting?

The software development field is constantly advancing; all programmers know that and most of us embrace it. Indeed, proponents of extreme programming (XP) must embrace change vehemently. While the papers title suggests cynicism, thus leading to possible confusion over its thesis, the author likes the software industrys evolution and maturation. Still, he is concerned about some aspects of the new agile methodologies. He concludes that there are a multitude of development scenarios where agile approaches can excel, but at least an equal number where it is destined to fail. For example, XPs proponents openly admit that XP does not tend itself to mission- or safety-critical applications, and large teams will find the oral communication mechanism difficult to implement. The key here is to know your options and understand when you should use one over another.