Missing Requirements Information and its Impact on Software Architectures: A Case Study

[Context & motivation] In the development of large, software-intensive systems, the system’s requirements are seldom, if ever, concluded upon prior to commencing with systems architecture. Research shows that, in order to manage development and domain complexities, instances of requirements engineering (RE) and systems architecting (SA) processes tend to inter-weave. [Question/problem] However, missing requirements information can cause one to create (or recreate) the needed information during different SA activities. While backtracking in the software development process is known to be costly, the costs associated with missing requirements in the SA process have not been investigated empirically. [Principal ideas/results] We thus conducted a case study where we investigated to what extent requirements or requirements attributes’ information found missing during the SA process and impact of those missing information on SA in terms of effort. The study involved five architecting teams that involve final year undergraduate and graduate students enrolled in the university course on SA, working on architecting a system falls under “banking” domain. Our result shows that, architects did find requirements and requirements attributes’ information missing while architecting. Among requirements information, architects found that, system functionality information, constraints information and system interaction (users/systems) information are missing in requirements at higher percentages. Within requirements’ attributes, architects found requirements priority, dependency and rationale missing at higher percentages. It is also found that, out of total time spent on architecting the system, effort given to recreate missing requirements information is higher for group3 (21.5%), group1 (18%), and group2 (17%) other than group4 (12.37%) and group5(10.18%). [Contribution] The anticipated benefits of the findings are, it can motivate researchers to venture into other areas of software engineering (such as coding, testing, maintenance, etc.) from the view point of missing requirements information and its impact on those areas. This knowledge could help software practitioners to decide what kind of information need to take care of, during RE process, that could possibly ease SA process and later development phases. To the best of my knowledge, this is the first work which focuses on, to what extent requirements and requirements’ attributes information found missing during SA; characteristics and impact of those requirements missing information on SA process in terms of effort

Evaluating the Graph-based Visualization Technique: A Controlled Experiment

Many researchers have highlighted the scarcity of empirical studies that systematically examine the advantages and disadvantages of the use of visualization techniques for software understanding activities. Such studies are crucial for gathering and analyzing objective and quantifiable evidence about the usefulness of proposed visualization techniques and tools, and ultimately, for guiding the research in software visualization. This paper presents a controlled experiment aimed at assessing the impact of a graph-based visualization technique on comprehension tasks. Six common comprehension tasks were performed by 20 undergraduate software engineering students. The completion time and the accuracy of the participants’ responses were measured. The results indicate that on one hand the use of the graph-based visualization increases the correctness (by 21.45% in average) but on the other hand it does not reduce the completion time in program comprehension tasks

New Technologies for Space Avionics, 1993

The report reviews a 1993 effort that investigated issues associated with the development of requirements, with the practice of concurrent engineering and with rapid prototyping, in the development of a next-generation Reaction Jet Drive Controller. This report details lessons learned, the current status of the prototype, and suggestions for future work. The report concludes with a discussion of the vision of future avionics architectures based on the principles associated with open architectures and integrated vehicle health management

Innovation in Ship Design

What is innovation in ship design? Is it a capability that is inherent in all naval architects? Is it the result of the application of a certain set of tools, or of operation within a certain organizational structure? Can innovation be taught? Innovation is a creative act that results in a new and game-changing product. The emergence of an innovative product creates an asymmetric market. The emergence of an innovative weapon creates an asymmetric battlefield. It is clearly in the economic and military interest of the United States to be able to develop and deploy innovative products, including innovative ships. But the process of ship design is usually one of incremental development and slow evolution. Engineers are taught to develop their product by paying close attention to previous developments. This approach is viewed by some people as anti-innovative. And yet the author has made a career of innovation in ship design. How has this been possible? This dissertation will answer the four questions posed above. It will show what innovation in ship design is, and where innovative naval architecture lies in the taxonomy of human creative endeavor. It will then describe those human attributes which have been found to be essential to successful innovation. It will also describe some of the many tools that innovators use. Some of those tools are used unconsciously. Some of those tools are formal products supported by research institutes and teaching academies. Finally, given the fact that innovation in ship design is a component of engineering – which is a subject taught in Universities – and that it is facilitated by the use of tools – and tool use can be taught – the author will conclude that innovation itself can be taught. Whether it can be mastered will depend upon the individual, just as with most other creative skills

Using product architecture to maximize environmental performance

None provided

Understanding enterprise behavior using hybrid simulation of enterprise architecture

Thesis (Ph. D.)--Massachusetts Institute of Technology, Engineering Systems Division, 2009.Cataloged from PDF version of thesis.Includes bibliographical references (p. [301]-314).Today, the design of business enterprises is much more art than science. The complex structure and behavior of enterprises makes it difficult to untangle cause and effect amidst its components and their relationships. In order for managers to understand how an enterprise's architecture affects its behavior, they need tools and techniques to help them to manage the complexity of the enterprise. The practice of enterprise architecting continues to make advances in this area with reference frameworks that can be used to guide the decomposition and communication of enterprise architectures, but it does not provide tools to analyze the potential behavior of a proposed enterprise architecture. This research seeks to extend the practice of enterprise architecting by developing an approach for creating simulation models of enterprise architectures that can be used for analyzing the architectural factors affecting enterprise behavior and performance. This approach matches the content of each of the "views" of an enterprise architecture framework with a suitable simulation methodology such as discrete event modeling, agent based modeling, or system dynamics, and then integrates these individual simulations into a single hybrid simulation model. The resulting model is a powerful analysis tool that can be used for "what-if" behavioral analysis of enterprise architectures. This approach was applied to create a hybrid simulation model of the enterprise architecture of a real-world, large-scale aerospace enterprise.(cont.) Simulation model analysis revealed potential misalignments between the current enterprise architecture and the established strategy of the enterprise. The simulation model was used to analyze enterprise behavior and suggest relatively minor changes to the enterprise architecture that could produce up to a 20% improvement in enterprise profitability without increasing resources to the enterprise.by Christopher Garrett Glazner.Ph.D