# Gemini ## Introduction to the Second Half of the Semester The lecture begins by establishing a new structure for the remainder of the course, from week 7 through to week 12. The previous lecturer, Phillip, has concluded his teaching, and a new lecturer, Andrew, will be leading the sessions. This transition marks a shift not only in the presenter but also in the format and focus of the course content. A key change is the division of the weekly two-hour lecture session. The first hour will be a traditional lecture, introducing a new topic. This portion of the session will be recorded and made available to all students, as it contains core examinable material. The second hour, however, will transform into an open, unrecorded consultation session. This non-compulsory time is designed to be a flexible and interactive workshop. During this second hour, student groups working on their major project can use the physical space to conduct their "sprint ceremonies," which are the structured meetings prescribed by the Scrum agile framework (such as sprint planning, daily stand-ups, or sprint reviews). Furthermore, students can directly engage with the lecturer, who will act in the capacity of a "client" to provide clarifications on project requirements. This provides a practical, hands-on opportunity for students to simulate a real-world client-developer interaction. The lecturer will also be available to assist with technical questions, although the ability to resolve them will depend on their complexity and the number of students seeking help. The structure for the final weeks is also outlined to manage student expectations. Week 11 is designated as a critical period, with the entire lecture session dedicated to consultation in preparation for major project deliverables due that Sunday. The specific details of these deliverables, which will include reports and a video, will be released in week 8. This advanced notice is intended to reassure students that if they are correctly following the Scrum methodology and executing their sprints, they will naturally be generating the necessary documentation and artifacts (like sprint backlogs, burndown charts, and meeting minutes) required for these submissions. Completing sprint 3 will also directly contribute to their final grade. This structure is explicitly designed to make the teaching staff more accessible and to provide direct, timely support for the group project. A crucial distinction is made regarding the content of the upcoming lectures. The topics to be covered—such as formal planning, software configuration management, ethics, and scaling agile frameworks—are of significant importance to a software engineer's professional knowledge. However, their primary assessment will be in the final exam, not directly within the group project. While some concepts might be tangentially relevant to the week 11 deliverables, the main purpose of these lectures is to broaden the students' theoretical understanding of software engineering beyond the specific application of Scrum in their project. This is a pedagogical choice to ensure students are exposed to a wider range of industry practices. ## The Role and Relevance of Formal Planning in Modern Software Development The lecture transitions to its core topic by addressing the place of formal planning methods in a world largely dominated by Agile methodologies like Scrum. It is a common misconception that formal, or "waterfall," methods are obsolete. The reality is more nuanced. While Agile is prevalent for the development work of individual teams, large-scale, complex projects often employ a hybrid approach. The overarching project management, involving massive budgets, long timelines, and coordination between many different departments (e.g., marketing, legal, hardware, software), may be structured using formal planning. Within this larger formal framework, individual software development teams can operate in an agile manner, using Scrum to build specific components of the system. Therefore, understanding formal planning is not merely an academic exercise; it provides insight into how a student's future work as a developer might fit into the larger ecosystem of a major enterprise project. The lecture will introduce tools and concepts that differ from the iterative, flexible nature of sprint planning. The goal is to equip students with the ability to analyze a project from a different perspective, one that emphasizes comprehensive upfront planning. This involves thinking about the entire project as a whole, rather than just the next sprint. The content will cover concepts that may feel familiar, such as identifying tasks, but will frame them within a more rigid and predictive structure. The key is for students to compare and contrast these formal methods with their current experience in Scrum, understanding the strengths and weaknesses of each approach and the contexts in which they are most appropriately applied. ## The Core Objectives of Project Scheduling A formal project schedule serves as a foundational document that orchestrates the entire development process. Unlike an agile backlog, which is an ordered list of features that can evolve, a formal schedule is a detailed plan that maps out the entire project from start to finish. It is considered a "living document," meaning it is not set in stone but is continuously updated to reflect the project's actual progress, delays, and changes. However, its initial creation is a comprehensive effort to predict the project's entire lifecycle. The primary purpose of creating such a schedule is to answer two fundamental questions that are critical to any business undertaking a software project: 1. **How long will it take to develop the system?** This question pertains to the project's timeline and is crucial for market timing, coordinating dependencies with other business units, and managing stakeholder expectations. 2. **How much will it cost?** This question relates to the project's budget, encompassing salaries, resources, and other overheads. The duration of the project is a primary driver of its cost. The lecture will focus on providing structured techniques to answer these two questions. This involves moving away from ad-hoc or purely intuition-based estimation towards formal, repeatable methods. The content has been streamlined to focus on a core, practical example that will be carried through the explanation, avoiding unnecessary theoretical detours to ensure a clear and focused learning path. ## Visualizing the Project Schedule: Gantt Charts vs. PERT Charts A formal project schedule is not just a list of dates; it is a rich document containing several key pieces of information. These include the duration of each task, the dependencies between tasks (i.e., which tasks must be completed before others can begin), the human and physical resources assigned to each task, and the major milestones and deliverables that signify progress. To communicate this complex information effectively, visual tools are used. Two primary methods for visualizing a project schedule are presented: the Gantt chart and the PERT chart. * **Gantt Chart:** This is a type of bar chart that plots tasks against a calendar timeline. Each task is represented by a horizontal bar, the length of which corresponds to the task's duration. The position of the bar on the timeline shows its start and end dates. Dependencies can be indicated with arrows linking the bars. While Gantt charts are very common in project management and provide an intuitive visual overview of "what happens when," they will not be the focus of assessment in this course. They are mentioned for context as they are a widely recognized tool. * **PERT Chart (Program Evaluation and Review Technique):** This is the tool that the course will focus on in detail. A PERT chart is a network diagram that excels at visualizing the dependencies and logical flow of tasks. It represents tasks as nodes (boxes or circles) and dependencies as arrows connecting them. Unlike a Gantt chart, which is primarily focused on the timeline, a PERT chart's main strength is in analyzing the project's structure to identify the **critical path**. The critical path is the sequence of tasks that determines the shortest possible duration for the entire project. Any delay in a task on the critical path will directly delay the project's completion. The lecture will systematically teach the process of constructing and interpreting a PERT chart, as this is a skill that will be assessed in tutorials and the final exam. The overarching goal is to demonstrate how to derive the appropriate values (like task durations and costs) needed to populate these charts and evaluate the project's health. ## A Structured Approach: The Five Steps to Creating a Project Schedule Creating a comprehensive and accurate project schedule is not a matter of guesswork. It follows a structured, multi-step process. The lecture outlines a five-step methodology that transforms a high-level project idea into a detailed, actionable plan, culminating in the creation of a PERT chart. This process provides a logical and repeatable framework for project planning. The five steps are: 1. **Identify all tasks:** This involves creating a comprehensive list of every single piece of work that needs to be done. This is formally known as creating a Work Breakdown Structure (WBS). 2. **Identify the interdependencies:** Once all tasks are listed, the relationships between them must be determined. Which tasks depend on the completion of others? This step builds the logical flow of the project. 3. **Estimate the effort and time for each task:** Each task must be assigned an estimated duration. This is one of the most challenging parts of planning, and the lecture will introduce formal techniques to make these estimates more reliable. 4. **Allocate resources to each task:** With tasks and durations defined, people and other resources (like specific hardware or software) can be assigned to carry out the work. 5. **Develop the project schedule:** This final step involves consolidating all the previous information into a formal schedule, visualized using a tool like a PERT chart. This final artifact shows the complete plan, including the timeline, dependencies, and critical path. Each of these steps will be explored in detail to build a complete mental model of the formal planning process. ### Step 1: Deconstructing the Project with a Work Breakdown Structure (WBS) #### The Concept of Decomposition The first and most fundamental step in planning any complex endeavor is to break it down into smaller, more manageable pieces. This process is known as decomposition, and its output is the Work Breakdown Structure (WBS). A WBS is a hierarchical list of all the tasks and subtasks required to complete a project. The challenge lies in ensuring this list is exhaustive, as any forgotten task will lead to inaccuracies in the schedule and budget. To create a WBS, project planners must first clearly identify the project's overall goals and key deliverables. These high-level objectives are then progressively broken down into smaller and smaller units of work until they reach a level of detail where a single person or small team can be assigned to them, and their duration can be reasonably estimated. This process is analogous to how, in Agile, a large feature (an epic) is broken down into smaller user stories. In formal planning, however, this decomposition is attempted for the *entire* project at the outset. #### Visualizing the WBS There is no single, rigid format for a WBS. It can be a simple indented list, where top-level items represent major phases (e.g., Requirements, Design, Implementation, Testing) and indented items represent the specific tasks within those phases. Alternatively, it can be represented as a graphical tree or organizational chart. For example, a "Software Development" project might be broken down into top-level tasks like "Requirements Evaluation," "Design," "Development," and "Testing." The "Design" task could then be further broken down into subtasks like "Functional Design," "Technical Design," and "User Interface Design." The key is that the WBS captures the "what" of the project—all the work that must be done—without yet worrying about the "when" (the schedule) or the "who" (the resources). This structured list forms the raw material for the rest of the planning process. Planners often draw upon historical data from similar past projects to ensure they have a comprehensive starting point for their WBS. #### A Related Tool: The Fishbone (Ishikawa) Diagram While not a direct method for creating a WBS, the Fishbone diagram (also known as an Ishikawa or cause-and-effect diagram) is introduced as a useful supplementary tool for thinking about tasks, particularly in the context of problem-solving or quality control. A Fishbone diagram helps to brainstorm the potential causes of a specific problem or effect. It organizes these potential causes into standard categories, such as People, Processes, Equipment, Management, Environment, and Materials. While its primary use is for root cause analysis, the thought process it encourages—systematically considering all factors that contribute to an outcome—can be adapted to help identify all the necessary tasks for a project. By thinking about what is needed in terms of people, processes, and equipment to achieve a certain project goal, a planner can uncover tasks that might otherwise be missed. It is a tool for structured brainstorming that promotes comprehensive thinking, which is essential for creating a complete WBS. ### Step 2: Identifying Task Interdependencies Once the WBS has provided a complete list of all tasks, the next logical step is to determine the relationships between them. It is rare for tasks to be completely independent; most rely on the completion of others. This step involves mapping out these relationships to create a logical sequence of work. #### Constrained vs. Unconstrained Tasks Tasks can be categorized based on their dependencies. * **Unconstrained Tasks:** These are tasks that can be started at any time, without waiting for any other task to be completed. For example, in a room renovation project, the task "Buy paint" is likely unconstrained. It doesn't depend on the walls being prepared first. * **Constrained Tasks:** These are tasks that have a dependency on one or more other tasks. The dependent task is called the **successor**, and the task it depends on is the **predecessor**. For example, the task "Remove wallpaper" is constrained; it cannot begin until the predecessor task "Remove decorations from wall" is complete. This relationship establishes a logical order: decorations must be removed first, then the wallpaper. Dependencies can arise from the nature of the work itself (a work product from one task is needed for the next) or from resource constraints (the same person or piece of equipment is needed for two different tasks, so they cannot be done simultaneously). #### Types of Dependencies The relationship between a predecessor and a successor task can take several forms. The most common types are: * **Finish-to-Start (FS):** This is the most intuitive and common dependency. The successor task cannot start until the predecessor task has finished. (e.g., You must finish removing the wallpaper before you can start painting the wall). * **Start-to-Start (SS):** The successor task cannot start until the predecessor task has started. The two tasks can then run in parallel. (e.g., The task "Start writing test cases" can begin as soon as the task "Start writing code" has begun). * **Finish-to-Finish (FF):** The successor task cannot finish until the predecessor task has finished. (e.g., The task "Final inspection of system" cannot finish until the task "Final documentation" is also finished). * **Start-to-Finish (SF):** This is the rarest type. The successor task cannot finish until the predecessor task has started. Understanding these different dependency types allows for a more accurate and realistic model of the project's workflow. For the purposes of this course, the Finish-to-Start dependency is the most important and frequently encountered. #### Creating the Task Network Diagram By representing each task from the WBS as a node (a circle or box) and each dependency as a directed arrow between nodes, we can create a **Task Network Diagram** (or Activity Network). This diagram is a graphical representation of the project's entire workflow. It clearly shows which tasks can be done in parallel and which must be done sequentially. The diagram typically begins with a single "Start" node and concludes with a single "End" node. Tasks with no predecessors are connected from the "Start" node, and tasks with no successors connect to the "End" node. This visual model is the skeleton of the PERT chart. At this stage, it shows the logical structure of the project but lacks any information about time or duration. It answers "what follows what," but not "how long will it take." ### Step 3: Estimating Task Duration and Effort With the logical structure of the project mapped out in the task network, the next critical step is to estimate how long each individual task will take. This is arguably the most difficult and error-prone part of project planning, as it involves predicting the future. The accuracy of the entire project schedule hinges on the quality of these individual task estimates. #### The Challenge of Estimation and Units of Measurement Estimating the time required for a software development task is notoriously difficult. It depends on the task's complexity, the developer's experience, the clarity of the requirements, and unforeseen technical hurdles. A junior developer might estimate a task will take five hours, only to find it takes much longer or shorter. This uncertainty is why experience is so valuable. Planners rely on historical data, expert judgment, and formal estimation techniques to improve accuracy. To standardize estimates, a common unit of effort is used, such as the **person-month**. A person-month represents the amount of work one person can complete working full-time for one month. For smaller tasks, units like person-weeks or person-days are used. This provides a consistent metric for effort that can then be translated into a duration based on how many people are assigned to the task. #### A Robust Method: Three-Point Estimation Relying on a single person's estimate is risky, as it may be overly optimistic or pessimistic. A more robust approach is **Three-Point Estimation**. This technique mitigates risk by considering a range of possible outcomes for each task. To perform a three-point estimate, a planner gathers three different values: * **Optimistic Time (O):** The best-case scenario. The shortest possible time the task could take if everything goes perfectly. * **Pessimistic Time (P):** The worst-case scenario. The longest time the task could take if significant problems are encountered. * **Most Likely Time (M):** The most realistic estimate. The time the task would probably take under normal circumstances. These three values can be gathered by consulting multiple experts, analyzing historical data, or having a single expert consider the full range of possibilities. #### Calculating the Expected Time Once the O, P, and M values are determined, they can be combined using a formula to calculate a single **Expected Time (E)** for the task. Two common formulas are: 1. **Triangular Distribution:** `E = (O + M + P) / 3`. This is a simple average of the three estimates. 2. **PERT Distribution:** `E = (O + 4M + P) / 6`. This is a weighted average. It gives four times more weight to the "Most Likely" estimate (M), reflecting the statistical reality that the most likely outcome is more probable than the extreme best- or worst-case scenarios. The PERT distribution is generally considered more realistic and is distinct from the PERT chart itself, despite sharing the name. By applying one of these formulas to every task in the WBS, we can generate a reliable set of duration estimates. These duration values are the numbers that will be added to our task network diagram, transforming it from a simple flow chart into a quantitative planning tool. ### Step 4: Allocating Resources After determining the tasks, their dependencies, and their estimated durations, the next step is to assign the necessary resources to perform the work. This primarily involves assigning people (developers, testers, designers) to tasks, but can also include allocating physical resources like servers, specific software licenses, or testing devices. A simple formula can be used to get a rough idea of the team size needed for the project: `Number of People = Total Effort / Project Duration`. For example, if the sum of all task efforts is 60 person-days and the desired project duration is 20 days, you would theoretically need a team of 3 people. This is a high-level calculation, and the actual allocation is more complex, as it must account for the fact that not all tasks can be done in parallel. The resource allocation step connects the abstract plan to the real-world team that will execute it. ### Step 5: Developing the Final Project Schedule - The PERT Chart This final step brings all the preceding work together to create the formal project schedule, visualized as a complete PERT chart. The PERT chart is the task network diagram enhanced with the time estimates and other calculated values that allow for in-depth analysis. #### Anatomy of a PERT Chart Node In a PERT chart, each task is represented by a node, which is typically a box divided into six sections. These sections hold key information about the task: 1. **Task Name/ID:** A unique identifier for the task. 2. **Duration (D):** The expected time for the task, calculated using a method like the PERT distribution. 3. **Earliest Start (ES):** The earliest possible time the task can begin, based on the completion of all its predecessor tasks. 4. **Earliest Finish (EF):** The earliest possible time the task can be completed. It is calculated as `EF = ES + D`. 5. **Latest Start (LS):** The latest possible time the task can begin without delaying the entire project. 6. **Latest Finish (LF):** The latest possible time the task can be completed without delaying the entire project. It is calculated as `LS = LF - D`. The values for ES and EF are calculated by performing a **forward pass** through the network, starting from the first task at time zero. The values for LS and LF are calculated by performing a **backward pass**, starting from the project's final completion time and working backward. #### The Concept of Float (or Slack) The difference between when a task *could* finish (Earliest Finish) and when it *must* finish (Latest Finish) reveals if there is any buffer time. This spare time is formally known as **Float** or **Slack**. It is calculated as `Slack = LF - EF` (or `LS - ES`). Float represents the amount of time a specific task can be delayed without affecting the project's overall completion date. For example, if three parallel tasks have durations of 1, 2, and 3 days, the task that takes 1 day has 2 days of float, and the task that takes 2 days has 1 day of float. They can be delayed by that amount of time without impacting the start of the next dependent task, which must wait for the 3-day task to finish anyway. #### The Critical Path: The Project's Longest Journey Some tasks will have a float of zero. This means their Earliest Start is the same as their Latest Start, and their Earliest Finish is the same as their Latest Finish. There is no buffer time for these tasks. These are called **critical activities**. The sequence of connected critical activities through the network forms the **Critical Path**. The critical path is the longest-duration path through the task network, and its total length determines the minimum possible time to complete the entire project. Any delay to any task on the critical path will result in a direct, day-for-day delay to the project's final delivery date. Identifying the critical path is a primary goal of PERT analysis because it tells project managers which tasks they must monitor most closely. #### From Diagram to Document: The Formal Schedule While the PERT chart is a powerful analytical tool, the final output for stakeholders is often a more traditional tabular schedule. This document lists each task, its dependencies, and its key dates (like its planned start and finish times). This schedule is derived directly from the information calculated in the PERT chart. It is this document that the project manager will use to track progress and update as the project unfolds. #### Modifying the Schedule: The Concept of "Crashing" Sometimes, the calculated project duration is too long to meet a business deadline. In this situation, a project manager may need to "crash" the schedule, which means finding ways to shorten the total duration. This is typically done by focusing on the critical path, as shortening non-critical tasks will not reduce the overall project time. Crashing can involve adding more resources to critical tasks (e.g., assigning more developers) to shorten their duration, or in some cases, re-evaluating and removing dependencies to allow more work to be done in parallel, though this can be risky. ## Monitoring and Controlling the Project: Earned Value Analysis (EVA) Creating the schedule is only the beginning. A project manager must continuously track the project's progress against this plan to ensure it stays on time and on budget. **Earned Value Analysis (EVA)** is a standardized technique used for this purpose. It provides a set of metrics to measure project performance and forecast future outcomes. #### The Purpose of EVA EVA's strength is that it integrates the project's scope, schedule, and cost into a unified framework. It moves beyond simply comparing planned cost to actual cost. For example, if you are halfway through a project's timeline and have spent half the budget, you might think you are on track. However, if you have only completed 25% of the actual work, you are actually far behind schedule and over budget. EVA provides the metrics to reveal this true status. The results of EVA are often expressed in terms of cost (dollars), time (days), or as a performance index (where a value of 1.0 means you are perfectly on track). #### The Three Foundational Metrics of EVA EVA is built upon three core data points that are collected at regular intervals (e.g., weekly or monthly): 1. **Planned Value (PV):** This is the budgeted cost for the work that was *scheduled* to be completed by a certain date. It represents the baseline plan. For a $12,000 project scheduled to take 12 months, the PV at the end of month 6 would be $6,000. 2. **Earned Value (EV):** This is the budgeted cost of the work that has been *actually* completed by that same date. It represents the real value of the work accomplished. If, at the end of month 6, only 4 months' worth of work has been completed, the EV would be $4,000. 3. **Actual Cost (AC):** This is the total amount of money that has *actually* been spent to complete the work so far. This includes all labor, overtime, and other expenses. #### Analyzing Performance: Schedule Variance By comparing these three values, a project manager can calculate key performance indicators. The lecture introduces **Schedule Variance (SV)**, which measures whether the project is ahead of or behind schedule in monetary terms. The formula is: **Schedule Variance (SV) = Earned Value (EV) - Planned Value (PV)** * If SV is positive (EV > PV), it means more work has been completed than was planned, so the project is **ahead of schedule**. * If SV is negative (EV < PV), it means less work has been completed than was planned, so the project is **behind schedule**. * If SV is zero (EV = PV), the project is **on schedule**. This, along with other EVA metrics like Cost Variance (CV = EV - AC), provides an objective, data-driven way to assess project health and make informed decisions to keep it on track.