Introduction to Software Projects
Welcome to your study notes on Software Projects! In AS 1 Approaches to Systems Development, understanding how software is planned, managed, and delivered is just as important as knowing how to write code.
Think of creating a large piece of software like building a skyscraper. You would not just turn up on day one with bricks and start stacking them without a blueprint, a budget, or a schedule! In the same way, developing digital systems requires careful project management to avoid costly disasters.
Don't worry if project management terminology feels new or tricky at first. We will break down every concept step-by-step with real-world examples!
1. The Project Management Triangle (Triple Constraints)
Every software project must balance three fundamental constraints. Together, these form the Project Management Triangle (often called the Triple Constraint):
• Time: The schedule, milestones, and final deadline for completing the project.
• Cost: The financial budget, including staff salaries, hardware, software licenses, and operational expenses.
• Scope: The complete set of features, functions, and requirements that the software must deliver.
Sitting right at the heart of this triangle is Quality. If any one of the three sides moves, the other sides—and the overall quality—are directly affected.
The Balancing Act (Real-World Analogy)
Imagine you hire a builder to renovate a kitchen:
• If you decide to add luxury appliances and an extra island (increasing the Scope), it will take longer (increasing Time) and require more money (increasing Cost).
• If you suddenly demand the job be finished two weeks early (reducing Time), the builder must hire extra workers (increasing Cost) or cut corners (lowering Quality).
• If your budget is cut in half (reducing Cost), you must drop features (reducing Scope) or accept slower progress (increasing Time).
Quick Memory Aid: Remember T-C-S: Time, Cost, Scope. You cannot change one without nudging the others!
Key Takeaway: Project managers constantly balance Time, Cost, and Scope to maintain the desired Quality of the final digital product.
2. Key Roles in a Software Project Team
Software projects are team efforts. Each team member has specific responsibilities throughout the development lifecycle:
• Project Manager (PM): The leader responsible for planning, executing, and closing the project. The PM tracks progress against schedules, manages budgets, allocates resources, and resolves team conflicts.
• Systems Analyst: The investigator and communicator. The analyst investigates the existing system, gathers user requirements through interviews or questionnaires, and documents what the new system must do.
• Systems Designer: The architect. They take the analyst's requirements and design the technical solution, including user interface (UI) layouts, database structures, data flow diagrams, and system architecture.
• Programmer / Developer: The builder. Programmers write, debug, and maintain the actual source code based on the technical designs.
• Software Tester / Quality Assurance (QA): The checker. Testers systematically test the software against test plans to find bugs, security flaws, and usability issues before release.
• Client / End User: The customer or person who will actually use the software. They provide initial requirements, give feedback during development, and carry out acceptance testing.
Common Exam Mistake to Avoid
Do not confuse the Systems Analyst with the Programmer! The analyst figures out what the system needs to do, while the programmer writes the code to make it work.
Key Takeaway: Successful projects rely on clear division of labour, where everyone from the Project Manager to the End User understands their exact role.
3. Why Software Projects Succeed or Fail
You might be surprised to learn that many large-scale software projects fail or significantly exceed their budgets.
Common Causes of Project Failure
• Scope Creep: Continuously adding new features and requirements after the project has already started without adjusting time or budget.
• Poor Communication: Misunderstandings between developers and clients about how a feature should work.
• Unrealistic Deadlines and Budgets: Setting overly optimistic targets that team members cannot possibly meet.
• Lack of User Involvement: Building software without consulting the actual end users, resulting in a system that is difficult to use or does not solve their problem.
• Inadequate Testing: Rushing software to release with unspotted bugs, leading to crashes and system downtime.
Factors for Project Success
• Clear Objectives and Requirements: A well-defined specification agreed upon by all stakeholders from day one.
• Active Stakeholder Involvement: Regular meetings and user feedback throughout development.
• Effective Project Planning: Using monitoring tools to keep tasks on track and spot delays early.
• Skilled Leadership: An experienced Project Manager who manages risks and keeps team members motivated.
Did you know? The term "Scope Creep" comes from the way small, seemingly innocent feature requests slowly "creep" into a project until it becomes impossible to finish on time!
Key Takeaway: Projects succeed when requirements are crystal clear and users are involved, while poor communication and uncontrolled scope changes lead to failure.
4. Project Management Tools: Gantt Charts and Critical Path Analysis
Project managers use visual planning tools to schedule tasks, manage dependencies, and monitor overall progress.
Gantt Charts
A Gantt chart is a visual horizontal bar chart that represents a project schedule across a timeline.
• The horizontal axis represents time (days, weeks, or months).
• The vertical axis lists all the individual tasks / activities.
• Each task is shown as a horizontal bar; the length of the bar represents the task's duration.
• Dependencies show which tasks cannot begin until previous tasks finish (for example, coding cannot start before design is complete).
• Milestones are marked as specific points in time representing key achievements (e.g., "Prototype Approved").
Advantages of Gantt Charts:
• Simple and easy for non-technical stakeholders to understand.
• Shows the entire project schedule and task durations at a single glance.
• Helps track whether individual tasks are ahead or behind schedule.
Limitations of Gantt Charts:
• Can become cluttered and unreadable for extremely complex projects with hundreds of tasks.
• Does not automatically highlight which specific delays will push back the entire project completion date.
Critical Path Analysis (CPA) / Network Diagrams
Critical Path Analysis (CPA) is a project management tool that maps out all activities in a network diagram to identify the sequential path that takes the longest time to complete.
Key Concepts in CPA:
• Node / Event: A circle representing the start or finish of an activity.
• Earliest Start Time (EST): The earliest possible time an activity can begin without delaying previous tasks.
• Latest Finish Time (LFT): The latest possible time an activity can finish without delaying the entire project.
• Critical Path: The longest sequence of dependent activities from start to finish. Any delay to an activity on this path will delay the entire project completion date.
• Float Time (Slack): The amount of spare time an activity can be delayed without delaying the overall project.
The formula for calculating Total Float is:
\(\text{Total Float} = \text{LFT} - \text{Duration} - \text{EST}\)
Activities on the Critical Path have a Float of \(0\) (i.e., \(\text{Float} = 0\)) because \(\text{LFT} - \text{Duration} = \text{EST}\). There is zero flexibility for these tasks!
Gantt Chart vs Critical Path: Quick Comparison
• Gantt Chart: Best for visual timelines, progress tracking, and communicating with clients.
• CPA Network: Best for calculating exact project duration, finding task dependencies, and identifying zero-leeway critical tasks.
Key Takeaway: The Critical Path is the longest path through a project network and represents the shortest possible time in which the project can be completed.
5. Risk Management in Software Development
A risk is any unexpected event that can negatively impact a project's timeline, budget, or quality.
The Risk Management Process
Project Managers follow four structured steps to handle risks:
1. Risk Identification: Brainstorming and listing everything that could possibly go wrong (e.g., a lead developer resigns, hardware fails, or a software vendor goes out of business).
2. Risk Assessment / Analysis: Evaluating each risk based on two factors:
• Likelihood / Probability: How likely is it to happen? (Low, Medium, High)
• Impact / Severity: How bad will the damage be if it happens? (Low, Medium, High)
3. Risk Mitigation / Planning: Creating strategies to prevent the risk or reduce its impact (e.g., keeping regular offsite backups to mitigate hardware failure).
4. Risk Monitoring: Regularly reviewing the project to spot new risks and check if existing risk levels have changed.
Contingency Planning
A Contingency Plan (often called "Plan B") is a pre-prepared set of actions that the team will immediately execute if an identified risk actually occurs. For example, maintaining an emergency budget reserve or keeping a backup contractor on standby.
Key Takeaway: Effective risk management identifies and assesses potential hazards early, putting mitigation and contingency plans in place before problems happen.
Quick Chapter Summary
• The Triple Constraint: Time, Cost, and Scope balance together to determine overall Quality.
• Project Roles: Project Manager, Systems Analyst, Designer, Developer, Tester, and Client each play distinct parts.
• Project Success & Failure: Clear requirements and user involvement lead to success; scope creep and poor communication lead to failure.
• Gantt Charts: Visual bar charts showing tasks over a calendar timeline.
• Critical Path Analysis: Identifies the longest sequence of dependent activities where \(\text{Float} = 0\).
• Risk Management: Identify \(\rightarrow\) Assess (Likelihood \(\times\) Impact) \(\rightarrow\) Mitigate \(\rightarrow\) Monitor.