Managing assumptions during agile development

The assumptions that underlie software development often go unrecorded and form part of the implicit rationale on which design and implementation decisions are based. These assumptions can fail at any time, with serious consequences. This paper presents a lightweight approach to assumption management (AM) designed to suit agile development. Assumptions were monitored for three months within a small agile team. Two key indicators were proposed for measuring AM success but only one was detected in the research results. A number of strong correlations were found between properties of assumptions. Data collection largely depended on the subjective judgements of the first author, but they were validated with some success by his colleagues. In some ways, assumption management was found to complement agile development. However, AM was not fully integrated into the team's development process, due to difficulty in adopting an 'assumption-aware' way of thinking. Suggestions are offered on how this transition may be eased, and on how others might wish to build on this research

Models, Techniques, and Metrics for Managing Risk in Software Engineering

The field of Software Engineering (SE) is the study of systematic and quantifiable approaches to software development, operation, and maintenance. This thesis presents a set of scalable and easily implemented techniques for quantifying and mitigating risks associated with the SE process. The thesis comprises six papers corresponding to SE knowledge areas such as software requirements, testing, and management. The techniques for risk management are drawn from stochastic modeling and operational research. The first two papers relate to software testing and maintenance. The first paper describes and validates novel iterative-unfolding technique for filtering a set of execution traces relevant to a specific task. The second paper analyzes and validates the applicability of some entropy measures to the trace classification described in the previous paper. The techniques in these two papers can speed up problem determination of defects encountered by customers, leading to improved organizational response and thus increased customer satisfaction and to easing of resource constraints. The third and fourth papers are applicable to maintenance, overall software quality and SE management. The third paper uses Extreme Value Theory and Queuing Theory tools to derive and validate metrics based on defect rediscovery data. The metrics can aid the allocation of resources to service and maintenance teams, highlight gaps in quality assurance processes, and help assess the risk of using a given software product. The fourth paper characterizes and validates a technique for automatic selection and prioritization of a minimal set of customers for profiling. The minimal set is obtained using Binary Integer Programming and prioritized using a greedy heuristic. Profiling the resulting customer set leads to enhanced comprehension of user behaviour, leading to improved test specifications and clearer quality assurance policies, hence reducing risks associated with unsatisfactory product quality. The fifth and sixth papers pertain to software requirements. The fifth paper both models the relation between requirements and their underlying assumptions and measures the risk associated with failure of the assumptions using Boolean networks and stochastic modeling. The sixth paper models the risk associated with injection of requirements late in development cycle with the help of stochastic processes

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