Now we're going to talk about what we should include in the project plan within the software development plan, SDP. We have to document the scope of the development ethic and how the project will be managed. The scope means what should be done within the project and what should not be done within the project. Notice that the SDP defines the project. We say that developing the SDP is a constraint optimization problem with incomplete data. We say that it's incomplete data because we have not yet started working on the project. We need inputs from different people in order to prepare the plan. We need the development manager to organize the project task, budget, etc. We also need some people with experience on a similar project so that that guy can tell us what are the designs that we can use for the project and also help estimate the project technical size. Then we also need some expert user or domain expert so that we can get our requirements from the application domain through the expert users or domain expert. In the project plan, we also have to specify the deliverables of the project. In the plan, you have to specify what should be delivered to who and when. Some of the deliverables, they can be client products, for example, executable code, user menu, etc. Some of the deliverables, they may be processed artifacts, for example, system requirements analysis, design specifications, or object design files or source code. Or some of them can be internal deliverables. For example, a source code libraries, make files, etc. Or some of the deliverables, they may be surfaces. For example, we may have to provide training to the client, provide installation service, customization, etc. You have to specify exactly what are the deliverables for the project in the plan. Deliverables will affect staffing and also team organization. Let's say if you have many deliverables, then obviously you need more people in your team to work on the project. Also in the project plan, you have to specify the development environment. Within the SDP, we have to specify the hardware and software development tools that we're going to use within the project. Notice that development tools, they are equals to development process. Development tools, they are just the tools we're going to use within the project. In order to be successful in a project, we still need some good processes so that everyone in the organization, they can follow the processes to develop the project. Tools are effective only if they make well-understood processes more efficient. When we choose a development tool, we have to evaluate, for example, the support of life cycle and also risk of adoption to both cost and schedule. If we are using some new tools, then we may have to spend some extra money in buying the tools. Also, we may have to provide extra training to the developers on how to use the tools. We also have to specify the work breakdown structure in the development plan. Within a project plan, we have to break down the project into tasks and subtasks using divide and conquer. Then, usually it's going to be in terms of a tree structure, which is something like this. Within the project, you have to specify what are the tasks that you have to perform. Within a task, there may be some further subtask, etc. You have to identify all the activities and tasks required to complete the project and also estimate resources required for each leaf node and then rolled up to get an estimate for the entire project. Then somehow, you can track the budgets and schedules of the project using this work breakdown structure. The work breakdown structure allows each task to be easily planned, it, easily assigned to individuals and teams, and also tracked to monitor progress and to know who is working on which task. Then also budgeted so that causes can be tracked, and they should be of the right granularity. If it's too small, then it's going to be hard to track. If it's too large, then it's going to be hard to control causes and measure progress because it's too general. Then in project plan, you have to also specify staffing and organization. You have to define the project organization and specify the roles and responsibilities within the project, and also the number of staff in each role and also teams. There should be one project member who have experience with a similar system and that member can help you estimate the size of the project and also help you design the software system. Notice that the team organizations should be modular to the limit communication and also complexity of the interaction. If you put too many people in a team, then eventually you will spent a lot of time in communication. Also, you should assign clear responsibilities to each team member. Also, form teams to have responsibility for the design and implementation of one or more subsystems. Also, identify a person in charge for each subsystem in the system. Also, identify a person in charge for each subsystem and the system. Because if there's something wrong with a particular subsystem, you can always talk to the person in charge. A key to success is by achieving the right level of communication. In your project plan, you also have to come up with your project schedule. Within a project schedule, you have to define a task ordering, the task estimates for each task, resource assignment, milestones, deliverables, and also critical path if we're talking about pie chart. Usually, there are three level of schedules to be maintained. The master schedule, which is an overview of the entire project, and also macro schedule for day-to-day project management, and micro schedule, which is for team management. In this course, we're going to talk about how to perform scheduling using Gantt chart, PERT chart, and burndown chart. We have already talked about how to use burndown chart to manage schedule when we talk about Scrum. Now we're going to talk about how to draw a Gantt chart and. PERT chart. This is an example of a Gantt chart. Within a Gantt chart, you have to specify all the task that you have to perform within the project and then also estimate the time that you need for each task. This is an example of a Gantt chart. From the Gantt chart, we can see the overall schedule for the entire project. We may also specify the schedule using PERT chart. Within a PERT chart, we still have to identify all the task that we're going to perform within the project and then give an ID for each task that we're going to perform with the new project. Then for each task, we have to estimate the duration of the task. Also, we have to indicate the task ordering. Then once we have all this information, then we can convert this information into a. PERT chart. A PERT chart is a graphical representation or project task laid out in the form of a critical path network. This is one example. Let's say we start with the start node then we perform task a, then we can go from node 1 to node 2. Then after we complete task B, then we go from node 2 to note 3. Then we're going to perform task C and D in parallel, and then once we finish task C, we go to node 4, and then once we finished task D we go to node 5. Then we're going to perform task E and F in parallel. Then after we finish task E and F, we're going to go to task G and also task H, and then we finish the project. Notice that we also need those dummy tasks in order to merge the parallel task back to demonstrate. Then we can identify the project duration using the critical path, which is the right one. We defined the critical path as the longest path from the start node to the end node. Since we are talking about the longest path, then we pick the path D instead of path C because it's longer. Also, we pick path F instead of path E because is longer. We are talking about the longest path that we have from the start node to the end node. From this path, somehow you can estimate the duration of the entire project. That's why we say that the overall schedule depends on the critical path. In your project plan, you also have to come up with all the estimates. We have to provide estimates of the project in terms of, for example, the size of the project or the effort that we have to spend on the project or the duration of the project, etc. Notice that estimating is based on experience, historical data, models, and also courage. That's why it's important that in order to reduce the risk in estimating, we need some people with experience on a similar system to tell us, for example, the size of the project, the duration of the project, how many people that we need in the project, etc. That's why I say here the risk can be reduced by trying to establish the project scope in advance. Then also use some metrics from past projects or some experienced people. Also, use divide and conquer to break down all the tasks into smaller ones before we estimate. There are many different types of metrics that we can collect for a software system. In this course, we're going to talk about productivity metrics. In particular, we're going to cover size-oriented metric and also function-oriented metric. If we are talking about size-oriented metric, we are talking about the size of the project. So we can estimate the size of the projecting terms of the lines of code that we have for the project. We can come up with these estimates based on data from past projects or based on people with experience on a similar project. Then once we can estimate the size of the project in terms of kilos lumbar lines of code, then we can use this KLOC to estimate, for example, productivity, cost, quality, and also documentation of the project. What is the problem with this approach? What is the problem with this approach? Notice that all this estimates, they are based on the size of the project in terms of the number of lines of code of the project. Notice that different people, they may use different number of lines of code for the same program, so that's the problem. It's difficult to come up with a single number because different people, they have different programming styles. This estimates are based on properties of the project software. For example, the number of user inputs that we have for a system, the number of outputs that we have for a system, the number of inquiries, the number of files that we have on the systems and also the number of external interfaces that we have on the system, et cetera. Then once we have the numbers, we're going to plug all these numbers into this equation and then we multiply with some weighting factors and then sum them up and then eventually, we will get some count-total. Then after that we get the count-total, we're going to plug it into this equation to get a function oriented metric. Some of you may ask, what is this F_i? This F_i is actually from a survey. You have to complete the survey and then calculate the average F_i. For example, you have to answer these questions. Does the system require reliable backup and recovery? If there's no influence, they say zero, if it's incidental, they say that it's five, et cetera. Then you have to answer all these questions and then give a rating for each of the question and then eventually average all the rating and then plug it into this equation in order to get the function-oriented metric. Then once you get this FP, you can estimate the productivity, the cost, quality and also documentation of the project. Now you can see that we tried to come up with all the estimates based on the functionalities provided by the software system. There are some other methods that we can use to come up with estimates. One is what we call the Delphi technique. We are not just going to get one single number. We're going to get three numbers from three different people and then average out the three numbers. We may also use per estimation. That means, we're going to ask each expert to provide a range of value, typically optimistic, most likely and also pessimistic. Then we're going to calculate some expected value and also standard deviation based on the range of values. Notice that standard deviation is a measure of schedule and budget risk. That means if the standard deviation is higher, then we're going to have higher risk within the project. Why? Because if we have higher deviation on the estimates, then that means we're going to have higher risk within the project. If you have studied statistic before, then you will know that the actual size will fall between or within one SD 68 percent of the time. Notice that it's essential to have experienced developer doing estimating, because they have experience on similar projects before. Also estimation should always be performed in more than one way and the results should be cross-checked. An incomplete and imprecise requirements hinder a correct cost estimation. Just because you don't know exactly what are the requirements, then it's going to be difficult to perform an estimation. In the project plan, you also have to specify, what are the metrics that we have to collect for the project. You have to identify what metrics to collect and how to collect them. If we are talking about project management, the metrics are usually related to size. For example, number of use cases, number of classes or the number of lines of code that we have for the project. We need to compare planned sizes with current sizes to determine the progress of the project and also stability of the project. In the project plan, we have to foresee and come up with all the risk that may happen in the project. That's why I say here, you have to foresee what can go wrong in the project and then estimate the likelihood of happening and also it's impact and also develop cost effective contingency plans. That means, what are the actions that you have to perform if the risk is going to happen. In doing this well is an important quality of a good manager. Also risk planning is related to preventive management so we try to foresee what's going to happen and then we try to avoid the risk from happening. Also, we have to come up with a time-phased budget within the project planned. In time-phased budget, we try to specify when the project budget is planned to be spent and also what is expected to be accomplished at each level of expenditure. Manpower will likely be the major cost because if we are talking about a software project, we will mainly need programmers to develop the project. But of course, there are also other causes. For example, the cost that you need for training, the cost that you need full purchasing software licenses, hardware components et cetera. It's a good idea to keep extra 10 to 15 percent as extra reserve, just in case something go wrong in the project, you still have some extra budget that you can spend for the project. Make sure that you track the spending. That means, comparing planned against actual money spent and also planned against actual completion regularly.
