Figure 1: An example of timeline chart (detailed Scheduling)
Justification through an Example:
Using Bar charts (or) Gantt charts:
A bar chart, is perhaps the simplest form of formal management. The bar chart is used almost exclusively for scheduling purposes and therefore controls only the time dimension of projects.
Gantt chart (developed by Henry L. Gantt) are a project control technique that can be used for several purposes, including scheduling, budgeting and resources planning. A Gantt chart is a bar chart, with each bar representing an activity. The bars are drawn against time line. The length of each bar is proportional to the length of the time planned for the activity.
Let us draw a Gantt chart for the tasks identified in the WBS figure 1. We estimate the number of days required for each of the six tasks as follows: initial design, 45; scanner, 20; parser, 60; code generator, 180; integrating and testing, 90; and writing the manual, 90.Using this estimates, we can draw Gantt chart of figure for the compiler project.
A Gantt chart helps in scheduling the activities of a project, but it does not help in identifying them. One can begin with the activities identified in the work breakdown structure, as we did for the compiler example. During the scheduling activity, and also during implementation of the project, new activities may be identified that were not envisioned during the initial planning. The manager must then go back and revise the breakdown structure and the schedules to deal with these activities.
The Gantt chart in the figure is actually an enhanced version of standard Gantt charts. The white part of the bar shows the length of the time each task is estimated to take. The gray part shows the slack time, that is, the latest time by which a task must be finished. One way to view the slack time is that, if necessary, we can slide the while area over the gray area without forcing the start of the next activity to be delayed. For example, we have freedom to delay the start of building the scanner to as late as October 17, 1994 and still have it finished in time to avoid delaying the integration and testing activity.
This example shows that the Gantt chart can be used for resources allocation and staff planning. For example, from the figure, we can conclude that the same engineer can be assigned to do the scanner and the parser while another engineer is working on the code generator. Even so, the first engineer will have some slack time that we may plan to use to help the second engineer or to get a head start on the integration and testing activity.
Gantt charts can take different forms depending on their intended use. They are best for resource scheduling. For example, if we are trying to schedule the activities of six engineers, we might use Gantt chart in which each bar represents one of the engineers. In such a chart, the engineers are out resources and the chart shows the resources loading during the project. It can help, for example, in scheduling action time, or in ensuring that the right number of engineers will be available during each desired period. The following Figure shows an example. We could label appropriate sections of the bars to show how much time we expect each engineer to spend on each activity (e.g., design and building the scanner). Gantt charts are useful for resource planning and scheduling. While they show the tasks and their duration’s clearly, however, they do not show intertask plainly.
When a bar chart is used as a project control method, milestones or checkpoints usually are placed at the completion of each task (they may also be placed within tasks). They indicate the completion of a particular task and the basis for determining whether the task and the project are on schedule; when a checkpoint is reached, the task just completed and the entire project are reviewed and evaluated. Reviewers ask whether resources allocated have been properly utilized and whether the task has been satisfactorily completed. However, because the bar chart incorporates only the scheduling dimension of a project, it gives little indication of which tasks must be completed before others are begun, and project costs must be accumulated and evaluated using the other methods.
The same compiler project example can be explained via PERT as follows:
The chart shows that the path through the project that consists of the design, build code generator and integrating and testing activities is the critical path for the project. Any delay in any activity in this path will cause delay in the entire project. The manager will clearly want to monitor the activities on the critical path much more closely than the other activities.
Risks mitigation, monitoring and management
We came up with the following list of risks related to the software engineering project and a list of proactive prevention to that risk. It should be noted that risk can only be approximated but cannot be measured like other values
Risks before software is developed
Team members’ health and motivation is very important for the development of good software. It also accounts for that the team members are technically skilled to carry on with project. The members should be excited to learn and contribute as much as possible. We are going through lots of learning and regularly discussing the materials we have learned. Members have good understanding between the group. Each one appreciates other work and eager to help each other any time.
Priority of the work – In projects everybody should prioritize the work. If member are not going according to the schedule and not working according to priority then there will be lot of hindrance to the project. The seriousness and dedication of work is very important. Since we are graded for that we are very serious about it.
Lack of interest by customer team – During the development of the project it could happen that the customer might not cooperate with our development. To avoid that we are constantly discussing with the customer team to avoid confusion and to build better and user friendly product
thus it is justified that it is not possible to manage a project if only a macroscopic schedule is developed.