Although the word ‘‘manager’’ may remind many of us of the manager in the ‘‘Dilbert’’ comic strip, management is important. Software project management is the important task of planning, directing, motivating, and coordinating a group of professionals to accomplish software development. Software project management uses many concepts from management in general, but it also has some concerns unique to software development. One such concern is project visibility.
The lack of visibility of the software product during software development makes it hard to manage. In many other fields, it is easy to see progress or lack of progress. Many software projects get stalled at 90 percent complete. Ask any programmer if that bug that he or she found is the last bug in the software, and the answer will almost always be an emphatic yes. Many of the techniques in software management are aimed at overcoming this lack of visibility.
Management Approaches
A basic issue in software project management is whether the process or the project is the essential feature being managed. In process oriented management, the software project management of the small tasks in the software life cycle is emphasized.
In project management, the team achieving the project is emphasized. This results in important differences in viewpoint.
In a process management approach, if the team does not follow the prescribed software life cycle, this would be a major difficulty. In a project management approach, success or failure is directly attributed to the team.
Team Approaches
Organizing a group of people into an efficient and effective team can be a difficult task. Letting a team develop its own paradigm can be risky. Choosing a team organization based on the project and the team members may help avoid disaster.
One aspect of a team is the amount of structure in the team. While some groups of programmers can work very independently, other groups need strong structure to make progress. The chief programmer team mentioned in the next section is an example of a strongly structured team. In a strongly structured team, small assignments are made to each member. These are often called ‘‘inch pebbles’’ because the assignments are small milestones. In a weakly structured team, the tasks are usually of longer duration and more open ended.
Some teams consist of people with similar skills. These teams often stay together through many projects. Other teams are composed of people with different expertise that are grouped into a team based on the need for specific skills for a project. This is often called a matrix organization.
Chief Programmer Teams
IBM developed the chief programmer team concept. It assigns specific roles to members of the team. The chief programmer is the best programmer and leads the team. Nonprogrammers are used on the team for documentation and clerical duties. Junior programmers are included to be mentored by the chief programmer.
Critical Practices
Most studies of software development have identified sets of practices that seem critical for success. The following 16 critical success practices come from them Software Project Managers Network
- Adopt continuous risk management.
- Estimate cost and schedule empirically.
- Use metrics to manage.
- Inspect requirements and design.
- Track earned value.
- Track defects against quality targets.
- Adopt life cycle configuration management.
- Manage and trace requirements.
- Ensure data and database interoperability.
- Use system-based software design.
- Define and control interfaces.
- Design twice, code once.
- Treat people as the most important resource.
- Assess reuse risks and costs.
- Manage testing as a continuous process.
- Compile and smoke test frequently.
Capability Maturity Model
The Software Engineering Institute has developed the Capability Maturity Models. The Software Engineering Capability Maturity Model (SE-CMM) is used to rate an organization’s software development process. An assessment of an organization’s practices, processes, and organization is used to classify an organization.
Personal Software Process
Watts Humphrey has developed the Personal Software Process to improve the skills of the individual software engineer. His approach has the individual maintain personal time logs to monitor and measure the individual’s skills. One result of this is measuring an individual’s productivity. The usual measure of productivity is lines of code produced per day (LOC/day). Additionally, errors are timed and recorded. This allows an individual to learn where errors are made and to assess different techniques for their effect on productivity and error rates. Additionally, the productivity can be used to evaluate the reasonableness of proposed schedules.
Error Tracking
One excellent management practice is error tracking, which is keeping track of the errors that have occurred and the inter-error times (the time between occurrences of the errors). This can be used to make decisions about when to release software. An additional effect of tracking and publicizing the error rate is to make the software developers aware of the significance of errors and error reduction. The effects of changes in the software process can be seen in the error data.
Additionally, making the errors and error detection visible encourages testers and developers to keep error reduction as a goal.
The error rate is the inverse of the inter-error time. That is, if errors occur every 2 days, then the instantaneous error rate is 0.5 errors/day. The current instantaneous error rate is a good estimate of the current error rate.
If the faults that cause errors are not removed when the errors are found, then the cumulative error rate (the sum of all the errors found divided by the total time) is a good estimate of future error rates. Usually, most errors are corrected (the faults removed), and thus the error rates should go down and the inter-error times should be increasing.
Plotting this data can show trends in the error rate (errors found per unit time). Fitting a straight line to the points is an effective way to display the trend. The trend can be used to estimate future error rates. When the trend crosses the x-axis, the estimate of the error rate is zero, or there are no more errors. If the x-axis is number of errors, the value of the x-intercept can be used as an estimate of the total number of errors in the software.
If the x-axis is the elapsed time of testing, the intercept is an estimate of the testing time necessary to remove all errors. The area under this latter line is an estimate of the number of errors originally in the software.
A straight line through the points would intersect the axis about 11. Since this implies that the error rate would go to zero at the eleventh error, an estimate of the total number of errors in this software would be 11 errors. Since seven errors have been found, this suggests that there may be four more errors in the software.
| Read More Topics |
| Software Development Life Cycle (SDLC) |
| Personal Team Process Model |
| Specialized process model |
| Software testing and quality |
| Delivery and Forwarding of IP Packets |
