Managing software projects with business-based requirements

For many organizations that are neither software product companies nor system integrators, the expense and cultural change required for full process rollout can be prohibitive. Proponents of agile processes/methods (such as extreme programming) suggest that these "lightweight" approaches are extremely effective. I would agree that there are many powerful aspects within these approaches. I suggest, however, that by taking an objective-based business requirements approach to project management, software projects have a high probability of running on time, and remaining in scope and within budget. Addressing requirement challenges, independent of adopting a full process, can offer many of the benefits of full process adoption while avoiding most of the expense and human issues involved with full process rollout. A business-based requirements approach is an easy-to-adopt, risk-free entry point that offers tangible quality improvements. This approach suits any project scope. Whether building a complex system for enterprise resource planning or customer relationship management, or developing small, single-user software programs, defining business requirements improves any system delivery.     

Using planning poker for combining expert estimates in software projects

When producing estimates in software projects, expert opinions are frequently combined. However, it is poorly understood whether, when, and how to combine expert estimates. In order to study the effects of a combination technique called planning poker, the technique was introduced in a software project for half of the tasks. The tasks estimated with planning poker provided: (1) group consensus estimates that were less optimistic than the statistical combination (mean) of individual estimates for the same tasks, and (2) group consensus estimates that were more accurate than the statistical combination of individual estimates for the same tasks. For tasks in the same project, individual experts who estimated a set of control tasks achieved estimation accuracy similar to that achieved by estimators who estimated tasks using planning poker. Moreover, for both planning poker and the control group, measures of the median estimation bias indicated that both groups had unbiased estimates, because the typical estimated task was perfectly on target. A code analysis revealed that for tasks estimated with planning poker, more effort was expended due to the complexity of the changes to be made, possibly caused by the information provided in group discussions.     

Successful requirements management

Conclusion By way of a conclusion, the preceding discussion has identified a relatively complex web of interrelationships that need to be managed. Too often the technical details are focused on to the detriment of the sponsoring business. However, if requirements are to be managed successfully, there is a need for adequate tool support. In my opinion, the requirements management tools which are currently available do not provide the sophisticated level of support needed to adequately manage the complexity of linking requirements, acceptance criteria, constraints, benefits and solutions.     

Obsolete software requirements

ContextCoping with rapid requirements change is crucial for staying competitive in the software business. Frequently changing customer needs and fierce competition are typical drivers of rapid requirements evolution resulting in requirements obsolescence even before project completion.ObjectiveAlthough the obsolete requirements phenomenon and the implications of not addressing them are known, there is a lack of empirical research dedicated to understanding the nature of obsolete software requirements and their role in requirements management.MethodIn this paper, we report results from an empirical investigation with 219 respondents aimed at investigating the phenomenon of obsolete software requirements.ResultsOur results contain, but are not limited to, defining the phenomenon of obsolete software requirements, investigating how they are handled in industry today and their potential impact.ConclusionWe conclude that obsolete software requirements constitute a significant challenge for companies developing software intensive products, in particular in large projects, and that companies rarely have processes for handling obsolete software requirements. Further, our results call for future research in creating automated methods for obsolete software requirements identification and management, methods that could enable efficient obsolete software requirements management in large projects.     

Landscape visualizations: Applications and requirements of 3D visualization software for environmental planning

This paper presents the findings of an investigation into the role and use of landscape visualization software for landscape and environmental planning in Germany. It examines the challenges and requirements of 3D visualization technology and its potential for application in landscape and environmental planning. Relevant literature and comparable surveys are reviewed in order to determine the current state of affairs, and the general and international relevance of the results is assessed.In 2000, a survey of user requirements for 3D landscape simulation software, including the demand for specific features, was conducted within the framework of a feasibility study for a visualization tool. As part of the German-wide survey, comprehensive questionnaires were sent to 1044 respondents from a pool of private landscape planning consultancies, freelance landscape architects, and public planning and environmental authorities.The survey showed that 3D landscape visualization has a positive image in Germany, both among user and non-user groups of visualization tools. Twenty-eight percent of private consultancies and freelance landscape architects, as well as 7% of public authorities, stated that they already used 3D simulation software. Those respondents who did not use 3D simulation software cited insufficient computer equipment, lack of technical expertise of planners and cost-related aspects as reasons for not yet having adopted the technology. “Ease of learning” and “interoperability” are deemed to be the most important features of 3D simulation software, whereas factors such as “high interactivity”, “representability of ecological processes” and “photo-realism” are, surprisingly, regarded as much less important.Users of 3D visualization software are particularly concerned by insufficient representation of plants and habitats in simulations. Looking to the future, the vast majority of respondents (91%) expect increased benefits for landscape planning from 3D visualization software, are convinced of the advantages of the technology, and are eager to integrate 3D landscape visualizations into their working practices.     

Predicting weekly defect inflow in large software projects based on project planning and test status

Defects discovered during the testing phase in software projects need to be removed before the software is shipped to the customers. The removal of defects can constitute a significant amount of effort in a project and project managers are faced with a decision whether to continue development or shift some resources to cope with defect removal. The goal of this research is to improve the practice of project management by providing a method for predicting the number of defects reported into the defect database in the project. In this paper we present a method for predicting the number of defects reported into the defect database in a large software project on a weekly basis. The method is based on using project progress data, in particular the information about the test progress, to predict defect inflow in the next three coming weeks. The results show that the prediction accuracy of our models is up to 72% (mean magnitude of relative error for predictions of 1 week in advance is 28%) when used in ongoing large software projects. The method is intended to support project managers in more accurate adjusting resources in the project, since they are notified in advance about the potentially large effort needed to correct defects.     

Preserving knowledge in software projects

Up-to-date preservation of project knowledge like developer communication and design documents is essential for the successful evolution of software systems. Ideally, all knowledge should be preserved, but since projects only have limited resources, and software systems continuously grow in scope and complexity, one needs to prioritize the subsystems and development periods for which knowledge preservation is more urgent. For example, core subsystems on which the majority of other subsystems build are obviously prime candidates for preservation, yet if these subsystems change continuously, picking a development period to start knowledge preservation and to maintain knowledge for over time become very hard. This paper exploits the time dependence between code changes to automatically determine for which subsystems and development periods of a software project knowledge preservation would be most valuable. A case study on two large open source projects (PostgreSQL and FreeBSD) shows that the most valuable subsystems to preserve knowledge for are large core subsystems. However, the majority of these subsystems (1) are continuously foundational, i.e., ideally for each development period knowledge should be preserved, and (2) experience substantial changes, i.e., preserving knowledge requires substantial effort.     

Risk management for software projects

There is little to instruct software project managers on how to handle risk in a way that ensures the success of contingency planning and avoids crisis. This seven-step procedure describes how to identify risk factors, calculate their probability and effect on a project, and plan for and conduct risk management     

Managing uncertainty in software projects

Although it is impossible to predict problems that will occur in software projects, project managers can employ strategies that imbue their projects with greater resilience. Throughout a software project, a series of practices can be established to manage uncertainties. This paper proposes an approach to managing uncertainty in software projects. The approach seems to improve project performance and success. This work is based on the principles of evidence-based software engineering. We conduct an exploratory literature search and a systematic literature review. In addition, we carry out action research in a software development project. Semi-structured interviews were conducted to evaluate and improve this approach. Finally, we held a focus group to evaluate the final proposed approach. The exploratory review helped to characterise the difference between risk and uncertainty. The systematic literature review revealed five methods and 18 practices for reducing uncertainties. The action research applied some of these techniques and investigated whether they contributed to a better uncertainty management. In the semi-structured interviews, practical points of view were added to the approach. This work defines an approach to uncertainty management and describes strategies that allow team members to explicitly formalise and manage uncertainty in software projects.     

Deriving engineering software from requirements

With the advent of intelligent computer aided design systems, companies such as Boeing are embarking on an era in which core competitive engineering knowledge and design rationale is being encoded in software systems. The promise of this technology is that this knowledge can be leveraged across many different designs, product families, and even different uses (e.g., generative process planning for manufacturing). The current state of the practice attempts to achieve this goal through the reuse of software components. A fundamental problem with this approach to knowledge sharing and reuse is that what we are trying to reuse is software—the end artifact in a long and complicated process that goes from requirement specifications, through a process of design, to implementations. Knowledge sharing and reuse can not easily and uniformly occur at the software level. So what can be done as an alternative? This paper describes a theory, methodology, language, and tool for the semi-automatic development and maintenance of engineering software from requirement specifications. In essence, this paradigm for software development and maintenance is one that explicitly captures requirement specifications, designs, implementations, and the refinement processes that lead from requirements all the way down to software. By recording this entire refinement history, we stand a better chance of leveraging knowledge for different uses.     

Acquiring COTS software selection requirements

Commercial off the shelf software can save development time and money if you can find a package that meets your customer's needs. The authors propose a model for matching COTS product features with user requirements. To support requirements acquisition for selecting commercial off the shelf products, we propose a method we used recently for selecting a complex COTS software system that had to comply with over 130 customer requirements. The lessons we learned from that experience refined our design of PORE (procurement oriented requirements engineering), a template based method for requirements acquisition. We report 11 of these lessons, with particular focus on the typical problems that arose and solutions to avoid them in the future. These solutions, we believe, extend state of the art requirements acquisition techniques to the component based software engineering process     

Monitoring and diagnosing software requirements

We propose a framework adapted from Artificial Intelligence theories of action and diagnosis for monitoring and diagnosing failures of software requirements. Software requirements are specified using goal models where they are associated with preconditions and postconditions. The monitoring component generates log data that contains the truth values of specified pre/post-conditions, as well as system action executions. Such data can be generated at different levels of granularity, depending on diagnostic feedback. The diagnostic component diagnoses the denial of requirements using the log data, and identifies problematic components. To support diagnostic reasoning, we transform the diagnostic problem into a propositional satisfiability (SAT) problem that can be solved by existing SAT solvers. The framework returns sound and complete diagnoses accounting for observed aberrant system behaviors. Our solution is illustrated with two medium-sized publicly available case studies: a Web-based email client and an ATM simulation. Our experimental results demonstrate the scalability of our approach.     

Using metrics to manage software projects

Five years ago, Bull's Enterprise Servers Operation in Phoenix, Arizona, used a software process that, although understandable, was unpredictable in terms of product quality and delivery schedule. The process generated products with unsatisfactory quality levels and required significant extra effort to avoid major schedule slips. All but the smallest software projects require metrics for effective project management. Hence, as part of a program designed to improve the quality, productivity, and predictability of software development projects, the Phoenix operation launched a series of improvements in 1989. One improvement based software project management on additional software measures. Another introduced an inspection program, since inspection data was essential to project management improvements. Project sizes varied from several thousand lines of code (KLOC) to more than 300 KLOC. The improvement projects enhanced quality and productivity. In essence, Bull now has a process that is repeatable and manageable, and that delivers higher quality products at lower cost. We describe the metrics we selected and implemented, illustrating with examples drawn from several development projects     

Curating GitHub for engineered software projects

Software forges like GitHub host millions of repositories. Software engineering researchers have been able to take advantage of such a large corpora of potential study subjects with the help of tools like GHTorrent and Boa. However, the simplicity in querying comes with a caveat: there are limited means of separating the signal (e.g. repositories containing engineered software projects) from the noise (e.g. repositories containing home work assignments). The proportion of noise in a random sample of repositories could skew the study and may lead to researchers reaching unrealistic, potentially inaccurate, conclusions. We argue that it is imperative to have the ability to sieve out the noise in such large repository forges. We propose a framework, and present a reference implementation of the framework as a tool called reaper, to enable researchers to select GitHub repositories that contain evidence of an engineered software project. We identify software engineering practices (called dimensions) and propose means for validating their existence in a GitHub repository. We used reaper to measure the dimensions of 1,857,423 GitHub repositories. We then used manually classified data sets of repositories to train classifiers capable of predicting if a given GitHub repository contains an engineered software project. The performance of the classifiers was evaluated using a set of 200 repositories with known ground truth classification. We also compared the performance of the classifiers to other approaches to classification (e.g. number of GitHub Stargazers) and found our classifiers to outperform existing approaches. We found stargazers-based classifier (with 10 as the threshold for number of stargazers) to exhibit high precision (97%) but an inversely proportional recall (32%). On the other hand, our best classifier exhibited a high precision (82%) and a high recall (86%). The stargazer-based criteria offers precision but fails to recall a significant portion of the population.     

Critical success factors in software projects

Software projects are still late, over budget, and unpredictable. Sometimes the entire project fails before ever delivering an application. The article presents a clear, commonsense review of fundamental project management techniques which reminds us that we still have a long way to go. It presents five essential factors to managing a successful software project: (1) start on the right foot; (2) maintain momentum; (3) track progress; (4) make smart decisions; (5) institutionalize post-mortem analyses