In methods we trust?

The degree to which you trust your environment-including co-workers, software tools and systems-has a dramatic impact on the performance of your entire software development team. If you can't trust someone during a code review, what are the chances the code review will be any good? I've become increasingly aware of another aspect of trust: the trust of a method. A method is a disciplined approach to problem solving that produces one or more well-defined outcomes. There appear to be two philosophies when it comes to trust and methods. One camp soundly rejects methods as a basis for trust: the only valid approach to problem solving is to identify specific problems systematically in their environment and solve these problems, one by one. The other camp takes the opposite approach, performing every process step by preparing all of the models (and other outcomes) defined by their method. The question is not whether you build software according to a process, but whether you trust the process you use. Do you trust your development process to generate accurate schedules? Do you trust it to generate high-quality, easily maintainable source code? Do you trust that your process will generate highly usable systems?     

Collecting data for comparability: benchmarking softwaredevelopment productivity

Whether you are benchmarking an organization or simply a project, it all boils down to one thing-data. Do you have the necessary data in your company, and is that data valid and comparable? How can you access data from other organizations? To help you answer these questions and avoid some common serious mistakes in the benchmarking process, the author has summarized her practical real-life experiences with software project data collection and benchmarking efforts in the guidelines     

Managing process diversity while improving your practices

In recent years, the software industry has gradually moved toward implementing standard processes across large organizations. The benefits of doing so include simplified accounting, measuring, and managing. Implementing organization-wide processes also makes it easier to judge the capabilities of an organization as a whole, which is important in large scale software development where organizational structures can have a profound impact on success. The article describes a project in which localized software practice improvements led to process diversity. It describes certain problems that were encountered and resolved during the effort. It also presents some simple techniques that any project, small or large, can use for managing diversity. The techniques discusses in the article evolved in the course of one multiyear project. If you do not carefully plan and manage process diversity, it quickly becomes unmanageable. The author used to advocate process uniformity, warning against the management problems caused by diversity, but recent experiences have suggested more effective ways to address these problems. The article explores these alternative strategies, which include adopting a basic set of practices that are uniformly enforced across all development steps, using risk analysis as a technique for selecting targets for software process improvement, and planning for process diversity     

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?     

软件过程的比较框架研究

软件过程在软件开发中占有非常重要的地位。根据项目的需求和特点，选择一个合适的软件过程可以使项目的开发事半功倍。为了指导软件过程的选择，本文给出了一个简明的软件过程比较框架，并依据这个比较框架，对几个典型的软件过程进行了分析和比较。     

Preparing the raw material

Any construction project begins with raw material, and as Confucius suggests, the nature of the raw material is critical to success-so much so that you shouldn't even begin if the "wood" is poor. Even if you have sharp, finely honed tools, your project will still fail if the raw material isn't sound. And what, might you ask, is the raw material of software development? Us. People. We are the only raw material of consequence in software development. Oh sure, the process will involve a few keyboards and mice, some compilers, database products, and myriad office supplies, but they're all completely secondary. Contrary to popular myth, we don't write software on computers. We don't write software in programming languages, integrated development environments or case tools, whiteboards, or 3/spl times/5 cards. We write software in our heads.     

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     

Measuring Agility and Architectural Integrity

Most organizations that depend on software are pursuing more flexible architectures and more agile life-cycle processes to increase business flexibility. What does agility look like, and how do we measure it? A truly agile project or organization should experience changes that are more straightforward and more predictable. Consequently, improvements are best measured by gauging the change trends in software baselines. A well-accepted tenet of software engineering states, "The later you are in the life cycle, the more expensive things are to fix." This iron law, an artifact of a waterfall culture, should not apply if you have transformed to agile software delivery with a well-architected system. This bold assertion is the root of the metric patterns presented in this paper.     

Fear of trying: the plight of rookie project managers

Most software engineers do not want the hassle of project management. Poor project management is the number one cause of software project failure. How do we grow good project managers? What do we teach the rookies who have just been appointed to lead their first software project? Regardless of the training or mentoring approach you use, I suggest focusing on four major attributes, which I describe in their order of importance: communication, negotiation, organization and facilitation     

Successfully implementing configuration management

To increase product quality, development efficiency, and enterprise profitability, many organizations are striving to achieve repeatable, engineered software development processes. Effective configuration management is essential to reaching this goal. CM can organize project components and streamline and control software development processes. A fully deployed and integrated CM solution consists of several tools. By carefully designing how CM components fit your processes and how your processes will change as a result of using CM, you can significantly enhance your software quality. We suggest an approach and provide planning and implementation guidelines for a pilot client-server software development project     

基于风险管理的软件开发过程模型

所谓软件开发过程中的风险,指的是在软件的开发过程中,可能会遇到的关于进度和预算方面的问题,或者是这些问题对软件开发的影响。如果软件开发过程中的风险变为现实,就会增加项目成本、影响项目进度、打乱软件开发计划,甚至最终影响软件项目的实现。风险管理对于软件开发来讲,就是为了尽可能的降低风险发生概率。如果对软件开发中的风险管理...     

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     

Affordable ways to improve application development

If an important client suddenly required that you conform to a process standard, could you afford to do so? Could you afford not to? The 3P Process Improvement Strategy is the answer. Two cases illustrate its benefits. In one case, a CMM Level 1 organization underwent a CMM based assessment for Internal Process Improvement less than one year after working with elements of 3P. The certifying agency found it compliant in all but one key process area, and the certification cost the company less than $100000 (US). In a second case, a small firm won a major procurement and has been vocal in crediting the win to efforts associated with the 3P strategy. The strategy derives its name from its core components: policies, processes, and products. The 3P approach is primarily pragmatic: it supports the notion that compliance with an established standard should serve as a sanity check, not an end in itself. Using 3P, you start with business and technical self-assessments, which lead directly to the improvement of a single process (or, if you have the resources, many processes). Your plans need not be elaborate, but must be complete. 3P provides a six-step program to help you monitor your progress. Monitoring is key: if you get commitment from your boss, yourself, and your team to honest assessment, the improvement program will yield long term benefits     

InterNetNews server: inside an open-source project

What do you get when you give your source code away and encourage programmers around the world to make changes to it? Some Internet software development engineers believe you get a robust system with a large market share and development that is highly responsive to user needs. The team behind the InterNetNews Usenet server package is one such group of believers. INN provides programs to exchange Usenet messages with other servers and to deliver those messages to end users. The Internet Software Consortium oversees the INN and has been supporting its development under an open model. INN is a moderate-sized software project with more than 430 files containing nearly 150,000 lines in the uncompiled distribution. Programs are written mainly in C, Bourne shell, and Perl. The CVS revision control system manages all changes to files. The paper describes the logistics of InterNetNews     

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     

The power of process [software processes]

Some people in the software development community think “process” is a four letter word. They think software processes are rigid, restrictive, and inefficient. They hold that the best way to run a project is to hire the best people you can, give them all the resources they ask for, and turn them loose to do what they do best. Sure, they say, there will be some amount of unproductive work is (also known as “thrashing”). After all, developers will make mistakes. But they will also be able to quickly and efficiently correct these mistakes at a cost that is less overall than the cost of processes. This point of view has intuitive appeal. At the beginning of a project, a focus on process certainly does take time away from productive work. If that trend were to continue throughout the project, it wouldn't make sense to spend much time on process. Software industry experience, however, has found that for projects that don't pay attention to establishing effective processes early are forced to slap them together late, when slapping them together takes more time and does less good. The article points out the problems caused by inattention to process, explains what happens when a project thrashes, and discusses the use of process versus creativity     

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     

Software processes: live and let die

What characterizes the optimal process for a software project? The author presents a reengineering case study to demonstrate that the answer lies in a holistic approach - one that carefully considers interactions between the tasks, processes and people involved with the project     

Toward objective software process information: experiences from a case study

A critical problem in software development is the monitoring, control and improvement in the processes of software developers. Software processes are often not explicitly modeled, and manuals to support the development work contain abstract guidelines and procedures. Consequently, there are huge differences between ‘actual’ and ‘official’ processes: “the actual process is what you do, with all its omissions, mistakes, and oversights. The official process is what the book, i.e., a quality manual, says you are supposed to do” (Humphrey in A discipline for software engineering. Addison-Wesley, New York, 1995). Software developers lack support to identify, analyze and better understand their processes. Consequently, process improvements are often not based on an in-depth understanding of the ‘actual’ processes, but on organization-wide improvement programs or ad hoc initiatives of individual developers. In this paper, we show that, based on particular data from software development projects, the underlying software development processes can be extracted and that automatically more realistic process models can be constructed. This is called software process mining (Rubin et al. in Process mining framework for software processes. Software process dynamics and agility. Springer Berlin, Heidelberg, 2007). The goal of process mining is to better understand the development processes, to compare constructed process models with the ‘official’ guidelines and procedures in quality manuals and, subsequently, to improve development processes. This paper reports on process mining case studies in a large industrial company in The Netherlands. The subject of the process mining is a particular process: the change control board (CCB) process. The results of process mining are fed back to practice in order to subsequently improve the CCB process.     

A semi-automated filtering technique for software process tailoring using neural network

It is widely known that implementation of the software development process to fit a given environment is the key to develop software at the lowest cost and highest quality. In general, applying an off-the-shelf software development process or an organizational process to a specific project can cause a lot of overhead if no effort is made to customize the given generic processes. Even though the process tailoring activities are done before starting a project, they are not given high importance. These activities depend on several process engineers who have a lot of experience and knowledge about process tailoring. Because of this dependence on human experience, it takes a long time to have a tailored process fit the project. To decide whether a specific task should be part of a given project or not is very time-consuming. Therefore, we suggest a semi-automated process tailoring method, which uses the artificial-neural network-based learning theory to reduce this time. We have demonstrated the effectiveness of our process filtering technique with a case study using process tailoring historical data as learning data.