PROJECT CONTROL SYSTEMS
The purpose of controlling a project is to monitor the progress the activities against the plans, to ensure that the goals are being approached and, eventually, achieved. Another aspect of control is to detect, as soon as possible, when deviations from the plan occurring so that corrective action may be taken. In software engineering, as in any design-dominated discipline, it is especially important to plan realistically even conservatively-so as to minimize the need for corrective action. For example, while in a manufacturing -dominated discipline it may be justifiable to hire the minimum number of workers necessary and add more employees if production falls below the required level, it has been observed in software engineering that adding people to a project that is late can delay the project even further. This underscores the importance of not only planning, but also controlling, in software engineering. The deviations from the plan are detected, the more it is possible to cope with them.
Work Break Down Structures
Most project control techniques are based on breaking down the goal of the project into several intermediate goals. Each intermediate goal can in turn be broken down further. The process can be repeated until each goal is small enough to be well understood. We can then plan for each goal individually-its resources requirements, assignments of responsibility, scheduling, etc.
A semiformal way of breaking down the goal is called the work breakdown structure (WBS). In this technique, one builds a tree whose root is labeled by the major activity of the project such as build a compiler. Each node of the tree can be broken down into smaller components that are designated the children of the node. This work breakdown can be repeated until each led node in the tree is small enough to allow the manager to estimate its size, difficulty, and resource requirements. Figure 1 shows the work breakdown structure for a simple compiler development project.
The goal of a work breakdown structure is to identify all the activities that a project must undertake. The tasks can be broken down into as fine as level of details as is desired or necessary. For example, we might have shown the substructure of a node labeled design as consisting of the three different activities of designing the scanner, parser and code generator. The structure can be used, as a basis for estimating the amount of resources necessary for the project as a whole by estimating the resources required for each leaf mode.
The work breakdown structure is a simple tool that gives the manager a framework for breaking down large tasks into more manageable pieces. Once these manageable pieces have been identified, they can be used as units of work assignment. The structure can be refined and extended easily by labeling the nodes with appropriate information, such as the planned length of the activity, the name of the person responsible for the activity, and the starting and ending date of the activity. In this way, the structure can summarize the project plans.
The work breakdown structure can also be an input into the scheduling process, as we will see in the following figure. In breaking down the work, we are trying to decide which task need to be done. In scheduling, we decide the order in which to do these tasks…Each work item in the work breakdown structure is associated with an activity to perform that item. A schedule tries to order the activities to ensure their timely completion.
TOP
Timeline Charts (Example of Detailed Schedule) :
When creating software project schedule, the planner begins with a set of tasks. If automated tools are used, the work breakdown is input as a task network or task outline. Effort, duration, and start date are then input for each task. In addition, task may be assigned to specific individuals.
As a consequence of this input, a timeline chart, also called a Gantt Chart, is generated. A timeline chart can be developed for the entire project. Alternatively, separate charts can be developed for each project function or for each individual working on the project.
In the figure illustrate the format of a timeline chart. It depicts a part of a software project schedule that emphasizes the concept scoping task. For a new word-processing (WP) software product. All project tasks are listed in left hand column. The horizontal bars indicate the duration of each task. When multiple bars occur at the time on the calendar, task concurrency is implied. The diamonds indicate milestones.
Once the information necessary for the generation of a timeline chart has been input, the majority of software project scheduling tools produce project tables- a tabular listing of all project tasks, their planned and actual start and end dates, and a variety of related information. Used in conjunction with the timeline chart, project tables enable the project manager to track progress.
Work tasks Week1 Week2 Week3 Week4 Week5
1.
Identify needs and benefits
Meet with customers
Identify needs and project constraints
Establish product statement
Milestone : Product statement defined
2.
Defined desired output/Control/input
Scope keyboard functions
Scope voice input functions
Scope modes of interaction
Scope document diagnosis
Scope other WP functions
Document OCI
FTR:Review OCI with customer
Revise OCI as required
Milestone : OCI defined
3.
Define the function / behavior
Define keyboard functions
Define voice input functions
Describe spell / grammar check
Descrobe other WP function
FTR: Review OCI definition with customer
Revise as required
Milestone : OCI definition complete
4.
Isolation software elements
Milestone: software elements defined
5.
Research availability of existing soft.
Research text editing components
Research voice input components
Research file management component
Research spell / grammar check comp
Milestone: Reusable components iden
6.
Define technical feasibility
Evaluate voice input
Evaluate grammar checking
Milestone: Technical feasibility assess
7. Make quick estimate of size
8. Create a scope definition
Review scope document with customer
Revise document as required
MilestoneL Scope document complete. |