Sizing up today's lightweight software processes

There is a buzz about the new lightweight software development processes. These processes are certainly capable of creating successful software systems faster. As a software developer, which one should you choose for your project? Indeed, today's software development processes bring interesting dynamics to the projects to which developers apply them. But should process drive the project or should the project determine the process? I examine one characteristic of these processes, scalability, which can help you decide what process is best for you     

The top risk of requirements engineering

The worst thing that can happen in requirements engineering is that your set of requirements, however expressed, doesn't accurately represent your users' needs and consequently leads your team down the wrong development path. The whole point of requirements engineering is to steer your development toward producing the right software. If you don't get the requirements right, how well you execute the rest of the project doesn't matter because it will fail. The article looks at how we can be led astray     

软件开发中变更管理的研究

随着软件规模的不断扩大,变更会在软件开发生命周期的各个阶段不可避免地频繁出现,如何有效地进行变更管理成为提高软件质量的关键。目前变更管理的工具很多,可以满足各种层次的需求,对于规模较大的项目,IBM公司的Rational ClearQuest是一个较好的选择。该系统功能非常强大,能够提供有效变更管理,投入实践能够较大提高项目质量。     

Usability Testing: A Journey, Not a Destination

Usability testing for interfaces can fit into a design project in several ways. The author looks at how good testing techniques can make projects run better and faster, and produce an improved result. The primary point is that there's no incompatibility between usability testing and a rational product process. We can think of usability testing as simply another aspect of quality assurance, and can fold it into the product process in much the same way as software quality assurance (QA). By having usability people involved from the beginning, big problems get found earlier, and small problems get found in time. The fear of losing control of a project to a usability person who finds a last-minute interface design problem is therefore a red herring. You can indeed find usability problems that might affect project completion late in the development process, just like you can find system architecture problems. But the way to keep this from happening is to test your system and your ideas during each stage of development, gathering the kind of information you need at each of those stages. That's why usability testing is a journey, not a destination     

CMM4中量化管理的解决方案

量化管理（QPM,SQM）是CMM4的一个关键过程域,是软件过程中一个关键的因素,对软件产品的开发过程和产品品质实施定量的管理。结合CMM4的评审要求,介绍了量化管理的发展、前提、要素、具体实施方法,并举例说明了如何应用量化管理方法进行项目管理。分析表明,量化管理在CMM4过程中有很重要的作用。     

WebSphere Portal 6.1: an agile development success story

Agile software development techniques are promising to deliver software faster, in better quality, and at a lower cost. Most examples relate to small, co-located teams working on a completely new project, with no legacy. This article focuses on applying Agile methods to a world-wide project with hundreds of developers delivering a market-leading product.In contrast to projects starting from scratch, existing customers have natural demands for support, bug fixes, and new features that focus on their particular needs.This article provides an overview of the most important Agile software development methods in addition to presenting ideas and solutions on how to apply Agile ideas to a large, existing product or solution. Important aspects that should be considered while deciding on what the Agile setup for your next software project should look like are explained.     

The importance of branching models in SCM

To improve software quality, you must first understand your software. If you do not understand your code base, your odds of updating it without breaking something are poor. Often, a fundamental misunderstanding of software configuration management (SCM) as it applies to real-world application development is at fault. Branching is integral to version management, software build correctness, and release management. Good decisions about when and why to branch can make it much easier for developers and release engineers to coordinate software product changes. The right branching strategy makes it easier to deliver the right code, re-create past releases, and-if necessary roll back to a previous release. The authors consider how adopting the right SCM branching model facilitates rapid development, increases overall product quality and process efficiency, reduces the incidence of software failures, and improves organizational performance.     

The project scoping gamble

A discussion is given on how to get people and technology to work together. The authors argue that software project managers can learn important lessons from the gambler. Software development is a gamble. Its a risky game-not unlike high stakes poker. And, like a gambler who must try to figure the best bet, when we're put on the spot trying to “scope” a software project we feel in need of some advice. Judging the timing and resources for a project is difficult when there's not much to go on. And yet, if you fail to estimate correctly, developers, management, and customers will all be unhappy. Defining a proper scope for your project won't guarantee its success, but a poor and especially an overly restricted scope may doom your project to failure. A gambler playing poker uses a variety of strategies to improve the odds of winning     

Guidelines for applying research results

The software engineering literature is full of research reports that relate the conclusions of case studies, surveys, and formal experiments. But it is not always easy to tell which results apply to you. When results conflict, how do you know which study to believe? To understand how to sort through these studies, and decide if you should perform your own study, the author has put together the Non-Trivial Pursuits game board, that tells you when you have enough information to draw a valid conclusion about a relationship between factors. To begin, suppose your project team is interested in improving the quality of the code it produces. You want to determine what factors improve quality so that your team can use appropriate techniques or tools to generate better code. Your first attempt to find out what affects code quality is to examine population studies, in which characteristics of a large developer population are examined for associations among variables     

The impact of tools on software productivity

It is common knowledge that to stay competitive, your software organization must continuously improve product quality and customer satisfaction, as well as lower software development costs and shorten delivery time. The paper considers how software tools are an effective way to improve software development variables such as productivity and product quality. It considers software tool selection and process improvement costs     

Software quality: the elusive target [special issues section]

If you are a software developer, manager, or maintainer, quality is often on your mind. But what do you really mean by software quality? Is your definition adequate? Is the software you produce better or worse than you would like it to be? We put software quality on trial, examining both the definition and evaluation of our software products and processes     

Risk management is project management for adults

Too often in the software industry, organizations approach project management in the same way a desperate gambler approaches the tables at Las Vegas or Monaco-with only one thought in mind: roll the dice. In a dice-tossing project, there is nothing you can do to improve your odds. Of course, that is not true for your software projects, but nothing you can do will make your risks go away completely. You can ignore them or you can deal with them explicitly. If you ignore your project's risks, all your other efforts will be for naught. Your project's success is based on opportunity and benefit, on cost and risk. Opportunity and benefit address the value of the delivered software. Cost and risk address the minimum and variable costs-in units of money, time and effort-that are necessary to deliver that product. Any form of risk management is better than none. If you have project management responsibilities, who should be dealing with the inherent risks of your project if not you?     

Safe and simple software cost analysis

Simple software cost-analysis methods are readily available, but they aren't always safe. The simplest method is to base your cost estimate on the typical costs or productivity rates of your previous projects. That approach will work well if your new project doesn't have any cost-critical differences from those previous projects, but it won't be safe if some critical cost driver has degraded. Simple history-based software cost-analysis methods would be safer if you could identify which cost driver factors were likely to cause critical cost differences and estimate how much cost difference would result if a critical cost driver changed by a given degree. In this article, I provide a safe and simple method for doing both of these by using some cost-estimating relationships. COCOMO II is an updated and re-calibrated version of COCOMO (COnstructive COst MOdel). I also show how the COCOMO II cost drivers let you perform cost sensitivity and tradeoff analyses, and discuss how you can use similar methods with other software cost-estimation models     

Measurement based process improvement

Used together, the two relatively young concepts of measurement and process improvement are more than the sum of their parts. Careful measurement helps you draw an objective process model. Thoughtful application of improvement techniques improves your ability to measure quality. Leveraging one with the other can take your organization to new heights. The article shows how software process modeling, tool development, measurement strategies, and other methods are combined to create real change on important software projects     

An Empirical Study of the Complex Relationships between Requirements Engineering Processes and Other Processes that Lead to Payoffs in Productivity, Quality, and Risk Management

Requirements engineering is an important component of effective software engineering, yet more research is needed to demonstrate the benefits to development organizations. While the existing literature suggests that effective requirements engineering can lead to improved productivity, quality, and risk management, there is little evidence to support this. We present empirical evidence showing how requirements engineering practice relates to these claims. This evidence was collected over the course of a 30-month case study of a large software development project undergoing requirements process improvement. Our findings add to the scarce evidence on RE payoffs and, more importantly, represent an in-depth explanation of the role of requirements engineering processes in contributing to these benefits. In particular, the results of our case study show that an effective requirements process at the beginning of the project had positive outcomes throughout the project lifecycle, improving the efficacy of other project processes, ultimately leading to improvements in project negotiation, project planning, and managing feature creep, testing, defects, rework, and product quality. Finally, we consider the role collaboration had in producing the effects we observed and the implications of this work to both research and practice.     

A cost-value approach for prioritizing requirements

Developing software systems that meet stakeholders' needs and expectations is the ultimate goal of any software provider seeking a competitive edge. To achieve this, you must effectively and accurately manage your stakeholders' system requirements: the features, functions, and attributes they need in their software system. Once you agree on these requirements, you can use them as a focal point for the development process and produce a software system that meets the expectations of both customers and users. However, in real world software development, there are usually more requirements than you can implement given stakeholders' time and resource constraints. Thus, project managers face a dilemma: how do you select a subset of the customers' requirements and still produce a system that meets their needs? The authors developed a cost-value approach for prioritizing requirements and applied it to two commercial projects     

Understanding the characteristics of quality for software engineering processes: A Grounded Theory investigation

ContextSoftware engineering organizations routinely define and implement processes to support, guide and control project execution. An assumption underlying this process-centric approach to business improvement is that the quality of the process will influence the quality, cost and time-to-release of the software produced. A critical question thus arises of what constitutes quality for software engineering processes.ObjectiveTo identify criteria used by experienced practitioners to judge the quality of software engineering processes and to understand how knowledge of these criteria and their relationships may be useful for those undertaking software process improvement activities.MethodInterviews were conducted with 17 experienced software engineering practitioners from a range of geographies, roles and industry sectors. Published reports from 30 software process improvement case-studies were selected from multiple peer-reviewed software journals. A qualitative Grounded Theory-based methodology was employed to systematically analyze the collected data to synthesize a model of quality for software engineering processes.ResultsThe synthesized model suggests that practitioners perceive the overall quality of a software engineering process based on four quality attributes: suitability, usability, manageability and evolvability. Furthermore, these judgments are influenced by key properties related to the semantic content, structure, representation and enactment of that process. The model indicates that these attributes correspond to particular organizational perspectives and that these differing views may explain role-based conflicts in the judgement of process quality.ConclusionConsensus exists amongst practitioners about which characteristics of software engineering process quality most influence project outcomes. The model presented provides a terminological framework that can facilitate precise discussion of software engineering process issues and a set of criteria that can support activities for software process definition, evaluation and improvement. The potential exists for further development of this model to facilitate optimization of process properties to match organizational needs.     

What can happen when metrics make the call

The software development discipline uses many well-intended metrics in ways that can be detrimental to a company's financial well-being. The most dangerous are the derived metrics-measures produced from some sort of equation that purport to show progress toward a goal. These are dangerous precisely because they are goal-oriented: they try to measure the goodness of a product or process. Derived metrics are built from feature metrics-they measure readily identifiable and relatively unambiguous features of a product or process. In isolation, feature metrics don't describe goodness, but they can be used in a derived metric to judge the quality. Bogus software metrics are an almost unavoidable side-effect of trying to understand and manage software products and processes. Yet managers and metrics groups can take one important lesson to heart: listen to your developers and listen very carefully. If you have seen why a metric is bogus, don't just leave it at that or treat it as a secondary issue. Root out the problem and figure out how to do it right or, at the very least, better than you did it before     

Primavera gets agile: a successful transition to agile development

Primavera Systems provides enterprise project portfolio management solutions that help customers manage their projects, programs, and resources. When we decided to improve how we build software and increase the quality of life for everyone on the team, we found our answer in agile software development. Adopting agile practices is a process of continuous learning and improvement. Primavera's development team is a model for others looking to adopt agile processes.     

Successfully applying software metrics

The word success is very powerful. It creates strong, but widely varied, images that may range from the final seconds of an athletic contest to a graduation ceremony to the loss of 10 pounds. Success makes us feel good; it's cause for celebration. All these examples of success are marked by a measurable end point, whether externally or self-created. Most of us who create software approach projects with some similar idea of success. Our feelings from project start to end are often strongly influenced by whether we spent any early time describing this success and how we might measure progress. Software metrics measure specific attributes of a software product or a software development process. In other words, they are measures of success. It's convenient to group the ways that we apply metrics to measure success into four areas. What do you need to measure and analyze to make your project a success? We show examples from many projects and Hewlett Packard divisions which may help you chart your course