How to Manage Process of Software Projects

The generic phases that characterize the software process—definition, development, and support—are applicable to all software. The problem is to select the process model that is appropriate for the software to be engineered by a project team.  

• the linear sequential model

• the prototyping model

• the RAD model

• the incremental model

• the spiral model

• the WINWIN spiral model

• the component-based development model

• the concurrent development model

• the formal methods model

• the fourth generation techniques model

The project manager must decide which process model is most appropriate for

(1) the customers who have requested the product and the people who will do the work, 

(2) the characteristics of the product itself, and

(3) the project environment in which the software team works.

When a process model has been selected, the team then defines a preliminary project plan based on the set of common process framework activities. Once the preliminary plan is established, process decomposition begins. That is, a complete plan, reflecting the work tasks required to populate the framework activities must be created.

Melding the Product and the Process

Project planning begins with the melding of the product and the process. Each function to be engineered by the software team must pass through the set of framework activities that have been defined for a software organization. Assume that the organization has adopted the following set of framework activities :

• Customer communication—tasks required to establish effective requirements elicitation between developer and customer.

• Planning—tasks required to define resources, timelines, and other projectrelated information.

• Risk analysis—tasks required to assess both technical and management risks.

• Engineering—tasks required to build one or more representations of the application.

• Construction and release—tasks required to construct, test, install, and provide user support (e.g., documentation and training).

• Customer evaluation—tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering activity and implemented during the construction activity.

The team members who work on a product function will apply each of the framework activities to it. In essence, a matrix similar to the one shown in Figure 3.2 is created. Each major product function (the figure notes functions for the word-processing software discussed earlier) is listed in the left-hand column. Framework activities are listed in the top row. Software engineering work tasks (for each framework activity) would be entered in the following row.5 The job of the project manager (and other team members) is to estimate resource requirements for each matrix cell, start and end dates for the tasks associated with each cell, and work products to be produced as a consequence of each task. 


How to Manage Process of Software Projects

Process Decomposition

A software team should have a significant degree of flexibility in choosing the software engineering paradigm that is best for the project and the software engineering tasks that populate the process model once it is chosen. A relatively small project that is similar to past efforts might be best accomplished using the linear sequential approach. If very tight time constraints are imposed and the problem can be heavily compartmentalized, the RAD model is probably the right option. If the deadline is so tight that full functionality cannot reasonably be delivered, an incremental strategy might be best. Similarly, projects with other characteristics (e.g., uncertain requirements, breakthrough technology, difficult customers, significant reuse potential) will lead to the selection of other process models. 

Once the process model has been chosen, the common process framework (CPF) is adapted to it. In every case, the CPF —customer communication, planning, risk analysis, engineering, construction and release, customer evaluation—can be fitted to the paradigm. It will work for linear models, for iterative and incremental models, for evolutionary models, and even for concurrent or component assembly models. The CPF is invariant and serves as the basis for all software work performed by a software organization.

But actual work tasks do vary. Process decomposition commences when the project manager asks, “How do we accomplish this CPF activity?” For example, a small, relatively simple project might require the following work tasks for the customer communication activity:

1. Develop list of clarification issues.

2. Meet with customer to address clarification issues.

3. Jointly develop a statement of scope.

4. Review the statement of scope with all concerned.

5. Modify the statement of scope as required.

These events might occur over a period of less than 48 hours. They represent a process decomposition that is appropriate for the small, relatively simple project. Now, we consider a more complex project, which has a broader scope and more significant business impact. Such a project might require the following work tasks for the customer communication activity:

1. Review the customer request.

2. Plan and schedule a formal, facilitated meeting with the customer.

3. Conduct research to specify the proposed solution and existing approaches.

4. Prepare a “working document” and an agenda for the formal meeting.

5. Conduct the meeting.

6. Jointly develop mini-specs that reflect data, function, and behavioral features of the software.

7. Review each mini-spec for correctness, consistency, and lack of ambiguity.

8. Assemble the mini-specs into a scoping document.

9. Review the scoping document with all concerned.

10. Modify the scoping document as required.

Both projects perform the framework activity that we call “customer communication,” but the first project team performed half as many software engineering work tasks as the second.

Frequently Asked Questions

Ans: A software project manager is confronted with a dilemma at the very beginning of a software engineering project. Quantitative estimates and an organized plan are required, but solid information is unavailable. A detailed analysis of software requirements would provide necessary information for estimates, view more..
Ans: In a study published by the IEEE [CUR88], the engineering vice presidents of three major technology companies were asked the most important contributor to a successful software project. They answered in the following way: view more..
Ans: Effective software project management focuses on the four P’s: people, product, process, and project. The order is not arbitrary. The manager who forgets that software engineering work is an intensely human endeavor will never have success in project management view more..
Ans: The generic phases that characterize the software process—definition, development, and support—are applicable to all software. The problem is to select the process model that is appropriate for the software to be engineered by a project team.   view more..
Ans: In order to manage a successful software project, we must understand what can go wrong (so that problems can be avoided) and how to do it right. In an excellent paper on software projects, John Reel [REE99] defines ten signs that indicate that an information systems project is in jeopardy: view more..
Ans: In an excellent paper on software process and projects, Barry Boehm [BOE96] states: “you need an organizing principle that scales down to provide simple [project] plans for simple projects.” Boehm suggests an approach that addresses project objectives, milestones and schedules, responsibilities, management and technical approaches, and required resources view more..
Ans: The Airlie Council8 has developed a list of “critical software practices for performance-based management.” These practices are “consistently used by, and considered critical by, highly successful software projects and organizations whose ‘bottom line’ performance is consistently much better than industry averages” [AIR99]. view more..

Rating - 4/5