Modern software project management can be subdivided into the following activities: 1. Establishing a common process framework for a proj...
Modern software project management can be subdivided into the following activities:
1. Establishing a common process framework for a project.
2. Using the framework and historical metrics to develop effort and time estimates.
3. Establishing deliverables and milestones that will enable progress to be measured.
4. Defining checkpoints for risk management, quality assurance, and control.
5. Managing the changes that invariably occur as the project progresses.
6. Tracking, monitoring, and controlling progress.
1. Establishing a common process framework for a project.
2. Using the framework and historical metrics to develop effort and time estimates.
3. Establishing deliverables and milestones that will enable progress to be measured.
4. Defining checkpoints for risk management, quality assurance, and control.
5. Managing the changes that invariably occur as the project progresses.
6. Tracking, monitoring, and controlling progress.
The technical manager who is faced with an object-oriented project applies these six activities. But, because of the unique nature of object-oriented software, each of these management activities has a subtly different feel and must be approached using a somewhat different mind-set.
The Common Process Framework for OO
A common process framework defines an organization’s approach to software engineering. It identifies the paradigm that is applied to build and maintain software and the tasks, milestones, and deliverables that will be required. It establishes the degree of rigor with which different kinds of projects will be approached. The CPF is always adaptable so it can meet the individual needs of a project team. This is its single most important characteristic.
Object-oriented software engineering applies a process model that encourages iterative development. That is, OO software evolves through a number of cycles. The common process framework that is used to manage an OO project must be evolutionary in nature.
Ed Berard and Grady Booch among others suggest the use of a “recursive/parallel model” for object-oriented software development. In essence the recursive/parallel model works in the following way:
• Do enough analysis to isolate major problem classes and connections.
• Do a little design to determine whether the classes and connections can be implemented in a practical way.
• Extract reusable objects from a library to build a rough prototype.
• Conduct some tests to uncover errors in the prototype.
• Get customer feedback on the prototype.
• Modify the analysis model based on what you’ve learned from the prototype, from doing design, and from customer feedback.
• Refine the design to accommodate your changes.
• Code special objects (that are not available from the library).
• Assemble a new prototype using objects from the library and the new objects you’ve created.
• Conduct some tests to uncover errors in the prototype.
• Get customer feedback on the prototype.
This approach continues until the prototype evolves into a production application. The recursive/parallel model is quite similar to the spiral or evolutionary paradigm.
Progress occurs iteratively. What makes the recursive/parallel model different is (1) the recognition that analysis and design modeling for OO systems cannot be accomplished at an even level of abstraction and (2) analysis and design can be applied to independent system components concurrently. Berard describes the model in the following manner:
• Systematically decompose the problem into highly independent components.
• Reapply the decomposition process to each of the independent components
to decompose each further (the recursive part).
• Conduct this reapplication of decomposition concurrently on all components
(the parallel part).
• Continue this process until completion criteria are attained.
It’s important to note that this decomposition process is discontinued if the analyst/ designer recognizes that the component or subcomponent required is available in a reuse library.
To control the recursive/parallel process framework, the project manager must recognize that progress is planned and measured incrementally. That is, project tasks and the project schedule are tied to each of the “highly independent components,” and progress is measured for each of these components individually.
Each iteration of the recursive/parallel process requires planning, engineering (analysis, design, class extraction, prototyping, and testing), and evaluation activities . During planning, activities associated with each of the independent program components are planned and scheduled. (Note: With each iteration, the schedule is adjusted to accommodate changes associated with the preceding iteration.) During early stages of engineering, analysis and design occur iteratively. The intent is to isolate all important elements of the OO analysis and design models. As engineering work proceeds, incremental versions of the software are produced. During evaluation, reviews, customer evaluation, and testing are performed for each increment, with feedback affecting the next planning activity and subsequent increment.
OO Project Metrics and Estimation
Conventional software project estimation techniques require estimates of lines-ofcode (LOC) or function points (FP) as the primary driver for estimation. Because an overriding goal for OO projects should be reuse, LOC estimates make little sense. FP estimates can be used effectively because the information domain counts that are required are readily obtainable from the problem statement. FP analysis may provide value for estimating OO projects, but the FP measure does not provide enough granularity for the schedule and effort adjustments that are required as we iterate through the recursive/parallel paradigm.
Lorenz and Kidd suggest the following set of project metrics:
Number of scenario scripts. A scenario script is a detailed sequence of steps that describe the interaction between the user and the application. Each script is organized into triplets of the form
{initiator, action, participant}
where initiator is the object that requests some service (that initiates a message); action is the result of the request; and participant is the server object that satisfies the request. The number of scenario scripts is directly correlated to the size of the application and to the number of test cases that must be developed to exercise the system once it is constructed.
Number of key classes. Key classes are the “highly independent components” that are defined early in OOA. Because key classes are central to the problem domain, the number of such classes is an indication of the amount of effort required to develop the software and also an indication of the potential amount of reuse to be applied during system development.
Number of support classes. Support classes are required to implement the system but are not immediately related to the problem domain. Examples might be GUI classes, database access and manipulation classes, and computation classes. In addition, support classes can be developed for each of the key classes. Support classes are defined iteratively throughout the recursive/ parallel process.
The number of support classes is an indication of the amount of effort required to develop the software and also an indication of the potential amount of reuse to be applied during system development.
Average number of support classes per key class. In general, key classes are known early in the project. Support classes are defined throughout. If the average number of support classes per key class were known for a given problem domain, estimating (based on total number of classes) would be much simplified. Lorenz and Kidd suggest that applications with a GUI have between two and three times the number of support classes as key classes. Non-GUI applications have between one and two times the number of support classes as key classes.
Number of subsystems. A subsystem is an aggregation of classes that support a function that is visible to the end-user of a system. Once subsystems are identified, it is easier to lay out a reasonable schedule in which work on subsystems is partitioned among project staff.
An OO Estimating and Scheduling Approach
Software project estimation remains more art than science. However, this in no way precludes the use of a systematic approach. To develop reasonable estimates it is essential to develop multiple data points. That is, estimates should be derived using a number of different techniques. Effort and duration estimates used for conventional software development are applicable to the OO world, but the historical database for OO projects is relatively small for many organizations. Therefore, it is worthwhile to supplement conventional software cost estimation with an approach that has been designed explicitly for OO software. Lorenz and Kidd suggest the following approach:
1. Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications.
2. Using OOA , develop scenario scripts (use-cases) and determine a count. Recognize that the number of scenario scripts may change as the project progresses.
3. Using OOA, determine the number of key classes.
4. Categorize the type of interface for the application and develop a multiplierfor support classes:
Interface type Multiplier
No GUI 2.0
Text-based user interface 2.25
GUI 2.5
Complex GUI 3.0
Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes.
5. Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class.
6. Cross check the class-based estimate by multiplying the average number of work-units per scenario script.
Scheduling for object-oriented projects is complicated by the iterative nature of the process framework. Lorenz and Kidd suggest a set of metrics that may assist during project scheduling:
Number of major iterations. Thinking back to the spiral model , a major iteration would correspond to one 360ยบ traversal of the spiral. The recursive/parallel process model would spawn a number of mini-spirals (localized iterations) that occur as the major iteration progresses. Lorenz and Kidd suggest that iterations of between 2.5 and 4 months in length are easiest to track and manage.
Number of completed contracts. A contract is “a group of related public responsibilities that are provided by subsystems and classes to their clients” . A contract is an excellent milestone and at least one contract should be associated with each project iteration. A project manager can use completed contracts as a good indicator of progress on an OO project.
Tracking Progress for an OO Project
Although the recursive/parallel process model is the best framework for an OO project, task parallelism makes project tracking difficult. The project manager can have difficulty establishing meaningful milestones for an OO project because a number of different things are happening at once. In general, the following major milestones can be considered “completed” when the criteria noted have been met.
Technical milestone: OO analysis completed
• All classes and the class hierarchy have been defined and reviewed.
• Class attributes and operations associated with a class have been defined and reviewed.
• Class relationships have been established and reviewed.
• A behavioral model has been created and reviewed.
• Reusable classes have been noted.
Technical milestone: OO design completed
• The set of subsystems has been defined and reviewed.
• Classes are allocated to subsystems and reviewed.
• Task allocation has been established and reviewed.
• Responsibilities and collaborations have been identified.
• Attributes and operations have been designed and reviewed.
• The messaging model has been created and reviewed.
Technical milestone: OO programming completed
• Each new class has been implemented in code from the design model.
• Extracted classes (from a reuse library) have been implemented.
• Prototype or increment has been built.
Technical milestone: OO testing
• The correctness and completeness of OO analysis and design models has been reviewed.
• A class-responsibility-collaboration network has been developed and reviewed.
• Test cases are designed and class-level tests have been conducted for each class.
• Test cases are designed and cluster testing is completed and the classes are integrated.
• System level tests have been completed.
