Thursday, December 01, 2005
What is Architecture-centric Software Project Management?
Problem
One common scenario is that cost and schedule estimates of software projects are required for justifying the business feasiblity of a software project, at a very early stage in the project life cycle. The difficulty is that there is little knowledge of requirements and the final product then to derive at feasible estimates. Hence, these estimates are usually inaccurate based on "expert judgement" or ballpark guesses.
One common scenario is that cost and schedule estimates of software projects are required for justifying the business feasiblity of a software project, at a very early stage in the project life cycle. The difficulty is that there is little knowledge of requirements and the final product then to derive at feasible estimates. Hence, these estimates are usually inaccurate based on "expert judgement" or ballpark guesses.
Solution
Using architecture-centric software project planning (ACSPP), it provides some guidelines on arriving at more realistic estimates. Figure 1 below shows where ACSPP fits into the software development life cycle. Notice that functional and system requirements specification are performed first, which is required to derive the high-level design by the system architects. The high-level architecture then serves as input to ACSPP, and acts as the basis for project planning.
Using architecture-centric software project planning (ACSPP), it provides some guidelines on arriving at more realistic estimates. Figure 1 below shows where ACSPP fits into the software development life cycle. Notice that functional and system requirements specification are performed first, which is required to derive the high-level design by the system architects. The high-level architecture then serves as input to ACSPP, and acts as the basis for project planning.
Figure 1 - Software Development PhasesThe ACSPP approach is summarised in Figure 2 below; High-level architecture is being produced by the architects as the project manager is concurrenlty working on the top-down schedule estimates. The top-down schedule can be derived from the subsystems identified from the high-level design. This approach requires the project manager and the architects to work closely together to derive an architecture and schedule estimate that is both technically feasible and meets business needs. The outputs from these two activities serves as key inputs into later activities, which are discussed next.
Figure 2 - Architecture-centered Software Project PlanningHigh-level Design - The aim here is to derive the subsystems/modules and scope of work that is to be done, which serves as basis for project planning. Top-level design decision are done here to serve as basis for planning as well; examples are development languages and deployment platforms etc. It also aims to resolve primary technical feasibility issues up front in the project life cycle where a "go-no-go" decision can be made if it is not technically feasible. Proof-of-concepts can be performed here to determine technical feasibilities, based on the perceived level of technical risk involved.
Top-down Schedule - Concurrently, the project manager derives the top-down schedule based on the subsystems identified from the high-level architecture. Parametric estimation techniques like COCOMO and Function-point analysis can be used here. Additional inputs can be from historical data of similar projects. Estimates at this point are still sketchy and accuracy is subjected to availability of accurate historical data. However, these activities do provide useful outputs, in that they help the project manager not to forget any significant considerations when planning the project. Examples includes SCM related tasks, project management life cycle tasks, and considerations like experiences of developers and if there are precedent project of similiar nature.
Bottom-up Estimates - Once the high-level architecture is completed, a bottom-up estimate can be derived using the subsystems and modules identified from system breakdown analysis. The granularity of the breakdown will depend on various factors like time, precedentness of similiar systems, and technical risk involved. Outputs from top-down scheduling are included at this point; the work breakdown structure includes primary activities to produce the software product AND any supporting activities necessary for the production, examples like project management tasks, meetings, reviews, SCM tasks, end-user training, documentation etc.
Release Plans - Suitable for incremental life-cycles; release planning identifies, prioritises and communicates what feature sets are available in which release and by when. The release plan helps to communicate with marketing department and distribution/deployment staffs on the major milestones to watch out for. It also allows the project managers to plan for resources required at certain phases of the life cycle e.g. arranging for beta testers prior to full release. Features' release are prioritised, using the high-level architecture, top-down scheduling and any business constraints (e.g. date of trade shows, need to operationalised new system by certain date). This serves as inputs for later scheduling efforts so that the project schedule meets business's needs.
Project Schedule - Using the top-down schedule, bottom-up estimates and release plans as inputs, a preliminary project schedule can be worked out detailing which activities is to be performed by who, and by when. Other consideration like public holidays and availability of resources (developers, testers, testing platforms etc) are factored here for a complete schedule.
Software Development Plan - The SDP details the entire plan required to produce the desired software product. The project schedule is included in the SDP to detail the time, and cost elements of this planning process.
Conclusion
Bottom-up Estimates - Once the high-level architecture is completed, a bottom-up estimate can be derived using the subsystems and modules identified from system breakdown analysis. The granularity of the breakdown will depend on various factors like time, precedentness of similiar systems, and technical risk involved. Outputs from top-down scheduling are included at this point; the work breakdown structure includes primary activities to produce the software product AND any supporting activities necessary for the production, examples like project management tasks, meetings, reviews, SCM tasks, end-user training, documentation etc.
Release Plans - Suitable for incremental life-cycles; release planning identifies, prioritises and communicates what feature sets are available in which release and by when. The release plan helps to communicate with marketing department and distribution/deployment staffs on the major milestones to watch out for. It also allows the project managers to plan for resources required at certain phases of the life cycle e.g. arranging for beta testers prior to full release. Features' release are prioritised, using the high-level architecture, top-down scheduling and any business constraints (e.g. date of trade shows, need to operationalised new system by certain date). This serves as inputs for later scheduling efforts so that the project schedule meets business's needs.
Project Schedule - Using the top-down schedule, bottom-up estimates and release plans as inputs, a preliminary project schedule can be worked out detailing which activities is to be performed by who, and by when. Other consideration like public holidays and availability of resources (developers, testers, testing platforms etc) are factored here for a complete schedule.
Software Development Plan - The SDP details the entire plan required to produce the desired software product. The project schedule is included in the SDP to detail the time, and cost elements of this planning process.
Conclusion
ACSPP guides the project planning process and ensures that key considerations of business needs and technical issues are factored into the plan. This ensures a more realistic plan based on known information at the early stages of the projecdt life cycle.
In addition, the outputs aids in communicating to stakeholders issues like what feature sets are available by which milestone, and if major business requirements in terms of time, cost and features are met.
However, it is noted the significant planning overhead required. At least preliminary requirements and high-level design must be performed before a certain accuracy in estimation can be achieved.
In addition, the outputs aids in communicating to stakeholders issues like what feature sets are available by which milestone, and if major business requirements in terms of time, cost and features are met.
However, it is noted the significant planning overhead required. At least preliminary requirements and high-level design must be performed before a certain accuracy in estimation can be achieved.
Comments:
<< Home
Excellent post. ACSPP is greatly useful in making projects and will help in making our projects productive and progressive.
Thanks a lot for this impressive post. Keep it up!
Thanks a lot for this impressive post. Keep it up!
By utilizing software architecture when managing projects, practitioners experience better success completing projects on time and within budget, while effectively fulfilling the project's requirements. Great software then.
Post a Comment
<< Home
