For a number of years, members of the Artificial Intelligence (AI) in Design community have studied Design Rationale (DR), the reasons behind decisions made while designing. DR is invaluable as an aid for revising, maintaining, documenting, evaluating, and learning the design. The presence of DR would be especially valuable for software maintenance. The rationale would provide insight into why the system is the way it is by giving the reasons behind the design decisions, could help to indicate where changes might be needed during maintenance if design goals change, and help the maintainer avoid repeating earlier mistakes by explicitly documenting alternatives that were tried earlier that did not work. Unfortunately, while everyone agrees that design rationale is useful, it is still not used enough in practice. Possible reasons for this are that the uses proposed for rationale are not compelling enough to justify the effort involved in its capture and that there are few systems available to support rationale use and capture. We have addressed this problem by developing and evaluating a system called SEURAT (Software Engineering Using RATionale) which integrates with a software development environment and goes beyond mere presentation of rationale by inferencing over it to check for completeness and consistency in the reasoning used while a software system is being developed and maintained. We feel that the SEURAT system will be invaluable during development and maintenance of software systems. During development, SEURAT will help the developers ensure that the systems they build are complete and consistent. During maintenance, SEURAT will provide insight into the reasons behind the choices made by the developers during design and implementation. The benefits of DR are clear but only with appropriate tool support, such as that provided by SEURAT, can DR live up to its full potential as an aid for revising, maintaining, and documenting the software design and implementation.

Context: Requirements change commonly occurs during the software development lifecycle. Requirements traceability is one of the important techniques to support requirement change management and analysis, ensure quality and keep requirements consistent during development. We find that existing research mentioned various issues and challenges during practicing requirements traceability, and the practitioners show certain obstacles on the subject. Major existing work of the area focuses on requirements traceability processes, frameworks, and techniques to address certain issues accordingly. And we want to focus on and investigate the existing challenges to practice requirements traceability systematically. Method: We investigate the requirements traceability and its challenges through a systematic literature review (SLR) of various concepts and existing challenges of requirements traceability, and a survey of 7 Chinese small-and-medium-sized enterprises (SMEs). With 7 interviews, we studied different traceability practices and situations with the surveyed companies under the possible impact of requirement change, development processes, tools, and other factors. And then we conducted conventional qualitative content analysis to identify and classify the challenges in practicing requirements traceability. Results: With the systematic literature review, we classified 14 categories of academic identified challenges. Through the collected data of the survey, we identified and discussed 6 categories of the requirement traceability challenges, involving costs, tools, awareness, documentation, etc. And we compared and discussed the connections and differences of the survey results with the literature for validation of our survey results and possible extension to the existing work. Through research, we may help the practitioners to deal with requirements change with traceability practice better by recognizing and preventing the obstacles. Our research may provide researchers with more information on practical situations. And in the future, researchers may study the traceability models more effectively aiming at addressing the existing problems.

As formigas são criaturas fascinantes que, além dos avanços na biologia também inspiraram pesquisas sobre teoria da informação. Em particular, o estudo resultou na criação da Teoria da Forragem de Informação, que descreve como os agentes de buscam informações em seu ambiente. Esta teoria também explica fenômenos recentes e bem-sucedidos, como crowd sourcing. Crowdsourcing tem sido aplicado a muitas atividades em engenharia de software, incluindo desenvolvimento, tradução e testes, mas uma atividade parece resistir: depuração. No entanto, os desenvolvedores sabem que a depuração pode exigir dedicação, esforço, longas horas de trabalho, por vezes, para mudar uma linha de código único. Nós introduzimos o conceito de Depuração em Enxame, para trazer crowd sourcing para a atividade de depuração. Através de crowd sourcing, pretendemos ajudar os desenvolvedores, capitalizando a sua dedicação, esforço e longas horas de trabalho para facilitar atividades de depuração. Mostramos que a depuração enxame requer uma abordagem específica para recolher informações relevantes, e descrevemos sua infra-estrutura. Mostramos também que a depuração em enxame pode reduzir o esforço desenvolvedores. Concluímos com as vantagens e limitações atuais de depuração enxame, e sugerir caminhos para superar estas limitações e ainda mais a adoção de crowd sourcing para atividades de depuração. / Ants are fascinating creatures that beyond the advances in biology have also inspired research on information theory. In particular, their study resulted in the creation of the Information Foraging Theory, which describes how agents forages for information in their environment. This theory also explains recent and fruitful phenomena, such as crowdsourcing. Many activities in software engineering have applied crowdsourcing, including development, translation, and testing, but one action seems to resist: debugging. Developers know that debugging can require dedication, effort, long hours of work, sometimes for changing one line of code only. We introduce the concept of Swarm Debugging, to bring crowdsourcing to the activity of debugging. Through crowdsourcing, we aim at helping developers by capitalizing on their dedication, effort, and long hours of work to ease debugging activities of their peers or theirs, on other bugs. We show that swarm debugging requires a particular approach to collect relevant information, and we describe the Swarm Debugging Infrastructure. We also show that swarm debugging minimizes developers effort. We conclude with the advantages and current limitations of swarm debugging and suggest directions to overcome these limitations and further the adoption of crowdsourcing for debugging activities.

Progress

Contemporary software engineering practice overemphasizes the distinction of software design from software implementation, and designer (“software architect”) from implementor (“computer programmer”). In this contemporary meme, software architects are concerned with large-grained system structures, quality attributes that arise from these structures (security, availability, performance, etc.) and quality attribute tradeoff to satisfy conflicting stakeholder needs; programmers are concerned with low–level algorithms and data structures, program functionality, and with satisfying architectural intent. However, software is unique in that design and implementation are not cleanly separable. While architect and programmer may have many different design concerns, they also have many complementary and interacting concerns; their respective design practices must be well–integrated. Instead, contemporary architecture and programming practices are diverging. Architects are likely to regard programming as a routine production activity, while programmers are likely to regard architecture as a routine management activity; communication is hindered by a lack of shared vocabulary or appreciation of mutual concerns. Instead of effective integration, a gap has opened in software architecture and programming practice. The research reported here defines the architecture/program seam (“the Seam”), a region of overlap in software architecture and programming practice. The Seam emphasizes design concerns centered on achieving predictable runtime behavior. For a behavior to be predictable it must be described in a theory that must ultimately be consistent with basic theories of computation, and each such theory must have objective evidence to demonstrate that theory observations correspond to system observations. The validity of a theory will likely depend on invariants that can be expressed, and enforced, by means of theory–induced design rules. A system that satisfies the design rules of a theory is then regarded as having behavior that is predictable by construction with respect to that theory. Predictability by construction reduces uncertainty, and hence risk in design, and helps designers explain complex design decisions. The research reported here also defines prediction–enabled component technology (PECT) as a foundation technology to support the Seam, and demonstrates a prototype on industrial problems in electric grid substation control, industrial robot control, and desktop streaming audio. The prototype PECT extends a basic component technology of pure assembly (“Pin”) with theory extension points (“reasoning frameworks”) that are used to achieve predictability by construction. Reasoning frameworks for real–time performance and temporal–logic model checking have been developed, with statistical confidence intervals providing evidence of predictive quality for the former, and code–embeddable proof certificates providing evidence for the latter. Finally, the research reported here defines the Seam itself as inducing a new kind of evolutionary design problem, whose solutions require the integration of programming language theory, design theory, specialized theories of system behavior and deep systems expertise.

A goal of runtime monitoring is to observe software execution to determine whether it complies with its intended behavior. Monitoring allows one to analyze and recover from detected faults, providing prevention activities against catastrophic failure. Although runtime monitoring has been in use for so many years, there is renewed interest in its application largely because of the increasing complexity and ubiquitous nature of software systems. To address such a demand for runtime monitoring and behavioral analysis of software systems, we present RUMBA framework. It utilizes a synergy between static and dynamic analyses to evaluate whether a program behavior complies with specified properties during its execution. The framework is comprised of three steps, namely: i) Extracting Architecture where reverse engineering techniques are used to extract two meta-models of a Java system by utilizing UML-compliant and graph representations of the system model, ii) Seeding Objectives in which information required for filtering runtime events is obtained based on properties that are defined in OCL (Object Constraint Language) as specifications for the behavioral analysis, and iii) Runtime Monitoring and Analysis where behavior of the system is monitored according to the output of the previous stages, and then is analyzed based on the objective properties. The first and the second stages are static while the third one is dynamic. A prototype of our framework has been developed in Java programming language. We have performed a set of empirical studies on the proposed framework to assess the techniques introduced in this thesis. We have also evaluated the efficiency of the RUMBA framework in terms of processor and memory utilization for the case study applications.

A formal specification language used during the requirements phase can reduce errors and rework, but formal specifications are regarded as expensive to maintain, discouraging their adoption. This work presents a single-subject experiment that explores the costs of modifying specifications written in two different languages: a tabular notation, Software Cost Reduction (SCR), and a state-of-the-practice notation, Real-time Unified Modeling Language (UML). The study records the person-hours required to write each specification, the number of defects made during each specification effort, and the amount of time repairing these defects. Two different problems are specified&mdash;a Bidirectional Formatter (BDF), and a Bicycle Computer (BC)&mdash;to balance a learning effect from specifying the same problem twice with different specification languages. During the experiment, an updated feature for each problem is sent to the subject and each specification is modified to reflect the changes. <br /><br /> The results show that the cost to modify a specification are highly dependent on both the problem and the language used. There is no evidence that a tabular notation is easier to modify than a state-of-the-practice notation. <br /><br /> A side-effect of the experiment indicates there is a strong learning effect, independent of the language: in the BDF problem, the second time specifying the problem required more time, but resulted in a better-quality specification than the first time; in the BC problem, the second time specifying the problem required less time and resulted in the same quality specification as the first time. <br /><br /> This work demonstrates also that single-subject experiments can add important information to the growing body of empirical data about the use of formal requirements specifications in software development.

A goal of runtime monitoring is to observe software execution to determine whether it complies with its intended behavior. Monitoring allows one to analyze and recover from detected faults, providing prevention activities against catastrophic failure. Although runtime monitoring has been in use for so many years, there is renewed interest in its application largely because of the increasing complexity and ubiquitous nature of software systems. To address such a demand for runtime monitoring and behavioral analysis of software systems, we present RUMBA framework. It utilizes a synergy between static and dynamic analyses to evaluate whether a program behavior complies with specified properties during its execution. The framework is comprised of three steps, namely: i) Extracting Architecture where reverse engineering techniques are used to extract two meta-models of a Java system by utilizing UML-compliant and graph representations of the system model, ii) Seeding Objectives in which information required for filtering runtime events is obtained based on properties that are defined in OCL (Object Constraint Language) as specifications for the behavioral analysis, and iii) Runtime Monitoring and Analysis where behavior of the system is monitored according to the output of the previous stages, and then is analyzed based on the objective properties. The first and the second stages are static while the third one is dynamic. A prototype of our framework has been developed in Java programming language. We have performed a set of empirical studies on the proposed framework to assess the techniques introduced in this thesis. We have also evaluated the efficiency of the RUMBA framework in terms of processor and memory utilization for the case study applications.

Software maintenance reportedly accounts for much of the total cost associated with developing software. These costs occur because modifying software is a highly error-prone task. Changing software to correct faults or add new functionality can cause existing functionality to regress, introducing new faults. To avoid such defects, one can re-test software after modifications, a task commonly known as regression testing. Regression testing typically involves the re-execution of test cases developed for previous versions. Re-running all existing test cases, however, is often costly and sometimes even infeasible due to time and resource constraints. Re-running test cases that do not exercise changed or change-impacted parts of the program carries extra cost and gives no benefit. The research community has thus sought ways to optimize regression testing by lowering the cost of test re-execution while preserving its effectiveness. To this end, researchers have proposed selecting a subset of test cases according to a variety of criteria (test case selection) and reordering test cases for execution to maximize a score function (test case prioritization). This dissertation presents a novel framework for optimizing regression testing activities, based on a probabilistic view of regression testing. The proposed framework is built around predicting the probability that each test case finds faults in the regression testing phase, and optimizing the test suites accordingly. To predict such probabilities, we model regression testing using a Bayesian Network (BN), a powerful probabilistic tool for modeling uncertainty in systems. We build this model using information measured directly from the software system. Our proposed framework builds upon the existing research in this area in many ways. First, our framework incorporates different information extracted from software into one model, which helps reduce uncertainty by using more of the available information, and enables better modeling of the system. Moreover, our framework provides flexibility by enabling a choice of which sources of information to use. Research in software measurement has proven that dealing with different systems requires different techniques and hence requires such flexibility. Using the proposed framework, engineers can customize their regression testing techniques to fit the characteristics of their systems using measurements most appropriate to their environment. We evaluate the performance of our proposed BN-based framework empirically. Although the framework can help both test case selection and prioritization, we propose using it primarily as a prioritization technique. We therefore compare our technique against other prioritization techniques from the literature. Our empirical evaluation examines a variety of objects and fault types. The results show that the proposed framework can outperform other techniques on some cases and performs comparably on the others. In sum, this thesis introduces a novel Bayesian framework for optimizing regression testing and shows that the proposed framework can help testers improve the cost effectiveness of their regression testing tasks.

A formal specification language used during the requirements phase can reduce errors and rework, but formal specifications are regarded as expensive to maintain, discouraging their adoption. This work presents a single-subject experiment that explores the costs of modifying specifications written in two different languages: a tabular notation, Software Cost Reduction (SCR), and a state-of-the-practice notation, Real-time Unified Modeling Language (UML). The study records the person-hours required to write each specification, the number of defects made during each specification effort, and the amount of time repairing these defects. Two different problems are specified&mdash;a Bidirectional Formatter (BDF), and a Bicycle Computer (BC)&mdash;to balance a learning effect from specifying the same problem twice with different specification languages. During the experiment, an updated feature for each problem is sent to the subject and each specification is modified to reflect the changes. <br /><br /> The results show that the cost to modify a specification are highly dependent on both the problem and the language used. There is no evidence that a tabular notation is easier to modify than a state-of-the-practice notation. <br /><br /> A side-effect of the experiment indicates there is a strong learning effect, independent of the language: in the BDF problem, the second time specifying the problem required more time, but resulted in a better-quality specification than the first time; in the BC problem, the second time specifying the problem required less time and resulted in the same quality specification as the first time. <br /><br /> This work demonstrates also that single-subject experiments can add important information to the growing body of empirical data about the use of formal requirements specifications in software development.