MANAGING AND LEADING SOFTWARE PROJECTS
AUTHOR: Richard E. (Dick) Fairley
Èñòî÷íèê:
Richard E. (Dick) Fairley Managing and leading software projects // a John Wiley & Sons, inc., publication. – 2009.
By definition, every project of every kind is an endeavor of limited duration that uses resources to achieve stated objectives. A project plan specifies, among other things, the duration of the project, the resources needed, and how the resources will be applied to achieve the stated objectives. Software requirements provide the objectives for the product to be developed or modified. The planning process is concerned with developing the various elements of a project plan and documenting the plan in a specified format.
Your software project management plan must be a written document; otherwise, various stakeholders in the project will have differing interpretations of how the project will be conducted, and there will be no documentation of plans for effort, cost, schedule, resources, and supporting activities. The project plan also provides a vehicle for trade studies and for negotiating trade-offs among cost, schedule, and requirements, both initially and as changes occur. Baseline control of the written project plan supports systematic updating of the plan and communication of changes.
In the best case, your planning process will begin with tailoring of your organization’s standard processes to fit the management, software development, and supporting processes of your project. In that case the information in this chapter can be used as a checklist against which you can compare your organization’s planning processes and document templates.
In the worst case, you will have to develop your project plan without any organizational structures or guidelines.
Project planning, like all elements of software development, is best accomplished in an iterative manner; details are added as understanding grows.
As depicted in the workflow model of Figure 1, inputs to planning include the customer’s requirements and constraints as well management directives and constraints. The system requirements, system design, and software requirements may also be available or they are developed during project initiation. As discussed, customer’s requirements include operational features, quality attributes, and design constraints for the envisioned product. Constraints imposed by the customer may include both product and process constraints.
A product constraint might require that the system be developed using a specified version of an operating system or that the new or modified system provide an SQL interface to an existing database. A process constraint might require that the system be delivered in a staged sequence of increasing capabilities or that the source code for the deliverable software plus the requirements and design documentation be delivered to an independent agent for final verification and validation.
Management directives may include a policy statement that all projects must produce design documentation and verify it for completeness, correctness, and consistency using peer reviews. A management constraint might limit your project resources to a staffing level of 10 software developers.
Some of your first tasks as project manager are to establish a pattern of ongoing communication with the designated customer representative (your primary point of contact), and to clarify with him/her/them the operational requirements, development constraints, and success criteria for the project.
Each operational requirement must be prioritized as Essential, Desirable, or Optional to facilitate achievement of a balance among requirements, schedule, and budget. Sufficient time and resources must be provided to implement all of the Essential requirements and as many of the Desirable requirements as desired by the customer.
Depending on the nature and scope of your project, clarifying the operational requirements and developing the system requirements, system architecture, and software requirements may be your task. Alternatively, you may delegate it to one or more members of your planning team, or they may be provided as the starting point for your planning process.
Your understanding of the operational requirements and development constraints will influence your choice of the development model to be used and the procedures to be followed.
- Considerations include:
An external customer (an acquirer) will typically specify the amount of money and the time available for the project, which may have to be negotiated to achieve a balance with the requirements. An internal customer may or may not provide money and/or resources for the project but will undoubtedly specify a schedule constraint for completion of the project, which may have to be negotiated. In any case, a contractual agreement in the form of a Statement of Work or a Memo of Understanding that contains items should be negotiated and accepted by you and your customer. Other planning activities include establishing an initial baseline of requirements, preparing estimates, and negotiating constraints to obtain a balance among requirements, cost, and schedule.
- At minimum, a plan for a software project, whether plan - driven or Agile, must include the following information:
As has been repeatedly emphasized, these elements of a project plan must be based on the development model to be used and scaled to the size and complexity of the project. Techniques for developing and documenting these elements of a project plan are presented in subsequent chapters.