The generic phases that characterize the software process—definition, development, and support—are applicable to all software. The problem ...
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.A wide array of software engineering paradigms were discussed:
• 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 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.
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 discussed earlier in this chapter—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.