Project planning, estimation and maintenance notes — Unit 5

Software project management is an umbrella activity within software engineering. It begins before any technical activity is initiated and continues throughout the definition, development, and maintenance of computer software.

⇒1.1 The '4 P's' of Management

Effective software project management focuses on the four P's:

• People: The most important element. Requires organizing teams, managing communication, and motivating developers.
• Product: The software to be built. The objectives and scope must be established before planning begins.
• Process: The framework (e.g., Agile, Waterfall) chosen for development. The process provides the structure from which a comprehensive plan can be established.
• Project: All the work required to make the product a reality within the process framework. Involves planning, monitoring, and controlling.

The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule.

⇒2.1 Software Scope

The first activity in planning is determining the software scope. Scope is defined by answering:

• What is the context of the software to be built? (How does it fit into a larger system?)
• What are the information objectives?
• What functions and performance are required?

⇒2.2 Feasibility (Revisited)

Once scope is understood, the team must determine if it is feasible to build the software within the given constraints (technically and financially). If it is not feasible, the project should be stopped immediately before more money is wasted.

Software cost and effort estimation will never be an exact science. Too many variables—human, technical, environmental, and political—can affect the ultimate cost of software and effort applied to develop it.

⇒3.1 Estimation Approaches

• Expert Judgment: Relying on the experience of experts who have worked on similar projects. Highly subjective but often accurate.
• Analogous Estimation (Historical Data): Comparing the current project to past projects of similar size and complexity.
• Decomposition Techniques: Breaking the project down into smaller, easily estimable functions (Work Breakdown Structure).
• Algorithmic/Empirical Models: Using mathematical formulas based on historical data (e.g., COCOMO).

⇒4.1 Lines of Code (LOC) Estimation

Estimating the total number of lines of code the final product will have. Cost and effort are then calculated based on historical productivity (e.g., $10 per line, 300 lines per person-month).

• Pros: Easy to calculate once the project is finished.
• Cons: Extremely difficult to estimate before writing the code. Heavily dependent on the programming language (100 lines of Assembly != 100 lines of Python). Penalizes concise, elegant code.

⇒4.2 Function Point (FP) Estimation

Measures functionality delivered to the user, independent of the programming language used. It counts inputs, outputs, inquiries, internal files, and external interfaces, weighted by complexity.

• Pros: Language independent. Can be estimated directly from the requirements document.
• Cons: Requires subjective judgment to classify complexity. Hard to automate the counting process.

The Constructive Cost Model (COCOMO), developed by Barry Boehm, is the most widely used empirical model for software estimation. It uses mathematical formulas derived from the analysis of thousands of historical projects.

⇒5.1 The Three Project Modes

• Organic: Small, simple software projects developed by a small team with good experience and relaxed requirements (e.g., a simple payroll system).
• Semi-detached: Medium-sized projects with mixed team experience and rigid/semi-rigid requirements (e.g., a new database management system).
• Embedded: Very complex, strongly coupled to hardware and operating under strict constraints (e.g., flight control software).

⇒5.2 Basic COCOMO Formula

Effort (in Person-Months) = `a * (KLOC)^b`, where `KLOC` is thousands of lines of code, and `a` and `b` are constants depending on the project mode.

Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks.

⇒6.1 Work Breakdown Structure (WBS)

The first step in scheduling is creating a WBS. The overall project is broken down into major phases, which are broken down into tasks, and further into sub-tasks until they are small enough to be accurately estimated and assigned to a single person (typically taking no more than a few days).

⇒6.2 Task Dependencies

Before scheduling, the manager must understand task dependencies. Task B cannot start until Task A finishes. Task C and Task D can be worked on in parallel.

⇒7.1 Gantt Charts (Timeline Charts)

A bar chart that illustrates a project schedule. The Y-axis lists the tasks, and the X-axis represents time. Bars show the start date, duration, and end date of each task. It is excellent for showing when things will happen and tracking overall progress.

⇒7.2 PERT/CPM (Activity Networks)

Program Evaluation and Review Technique (PERT) and Critical Path Method (CPM) represent tasks as a network diagram (a directed graph).

• Nodes: Represent milestones (start/end of a task).
• Edges (Arrows): Represent the tasks themselves and their duration.
• Critical Path: The longest path through the network. It determines the shortest possible time to complete the entire project. If any task on the critical path is delayed, the entire project is delayed.

Risk management is a series of steps that help a software team to understand and manage uncertainty. A risk is a potential problem—it might happen, it might not.

⇒8.1 Types of Software Risks

• Project Risks: Threaten the project plan (schedule delays, budget overruns, staff turnover).
• Technical Risks: Threaten the quality and timeliness of the software (using new, unproven technology, complex architecture).
• Business Risks: Threaten the viability of the software (building a product no one wants, losing management support).

⇒8.2 The Risk Management Paradigm

Risk management involves four steps: Identify (what can go wrong), Analyze (probability and impact), Plan (mitigation strategies), and Monitor (watch for triggers).

⇒9.1 Risk Projection (Estimation)

For every identified risk, the manager estimates:

• Probability: The likelihood that the risk will actually occur (e.g., 20%).
• Impact: The consequences of the problems associated with the risk (e.g., Catastrophic, Critical, Marginal, Negligible).

Risks with high probability and catastrophic impact are prioritized.

⇒9.2 RMMM Plan

The Risk Mitigation, Monitoring, and Management (RMMM) plan is created for prioritized risks.

• Mitigation: Steps taken before the risk occurs to reduce the probability (e.g., paying above-market salaries to reduce staff turnover risk).
• Monitoring: Watching indicators to see if the risk is becoming more likely.
• Management (Contingency): The 'Plan B' if the risk actually occurs (e.g., hiring contractors if key staff leave).

Software changes continuously. SCM is the art of identifying, organizing, and controlling modifications to the software being built by a programming team.

⇒10.1 Baselines

A baseline is a milestone in software development that is marked by the delivery of one or more software configuration items (SCIs). Once a baseline is established, changes can be made only through formal change control procedures.

⇒10.2 Version Control

Version control systems (like Git or Subversion) are the primary tools of SCM. They track every change made to every file, allowing teams to:

• Collaborate without overwriting each other's code.
• Revert the entire project back to a previous working state if a catastrophic bug is introduced.
• Maintain multiple concurrent versions of the software (branches).

In large projects (especially in defense, aerospace, or medical fields), developers cannot simply commit code whenever they want. A formal Change Control process must be followed.

⇒11.1 The Process

• Change Request: A user or developer submits a formal request detailing the bug or new feature.
• Impact Analysis: The software engineering team analyzes the technical and financial impact of making the change.
• Change Control Board (CCB): A committee of stakeholders reviews the impact analysis and either approves or rejects the change.
• Implementation: If approved, developers check out the code, make the change, and test it.
• Audit & Release: The SQA team audits the change to ensure standards were met before the new baseline is released.

Software maintenance is the process of changing a system after it has been delivered. Historically, maintenance accounts for 60% to 80% of total software life-cycle costs.

⇒12.1 Why Maintenance is Expensive

• Original developers have often left the company; new developers must spend weeks understanding undocumented, 'spaghetti' code.
• As changes are continually made, the original architecture degrades, making each subsequent change harder and more error-prone (Software Entropy).

⇒12.2 Types of Maintenance

Maintenance activities are generally classified into four categories: Corrective, Adaptive, Perfective, and Preventive.

• Corrective Maintenance (~20%): Fixing bugs and errors discovered by users after the software is released.
• Adaptive Maintenance (~25%): Modifying the software to keep it usable in a changing environment (e.g., porting the app to a new version of Windows or Android, updating to a new database API).
• Perfective Maintenance (~50%): Adding new features or modifying existing features to satisfy new user requirements. This makes up the bulk of maintenance work.
• Preventive Maintenance (~5%): Refactoring or rewriting code to improve maintainability and prevent future problems (Software Reengineering), without changing external behavior.

When a legacy system becomes too expensive to maintain due to years of patches and architectural degradation, it must be reengineered.

⇒14.1 The Reengineering Process

• Inventory Analysis: Evaluating the portfolio of existing applications to decide what needs reengineering.
• Document Restructuring: Creating missing documentation for the legacy code to understand how it currently works.
• Reverse Engineering: Analyzing the source code to extract the underlying business rules and design models.
• Code Restructuring: Refactoring the spaghetti code into modern, modular structures in the same language.
• Data Restructuring: Normalizing and migrating the underlying legacy databases.
• Forward Engineering: Rebuilding the system using modern languages and frameworks based on the extracted models.

Traditional project management (Gantt charts, critical paths) relies on knowing exactly what the end product will be before starting. Agile project management embraces uncertainty.

⇒15.1 Story Points and Velocity

Instead of estimating tasks in 'hours' (which humans are notoriously bad at), Agile teams use Story Points—a relative measure of complexity, effort, and uncertainty (often using the Fibonacci sequence: 1, 2, 3, 5, 8, 13).

Velocity is the measure of how many Story Points a team completes in a single Sprint. By calculating the average velocity over a few sprints, a manager can highly accurately predict how many sprints it will take to complete the remaining backlog.

⇒15.2 Burndown Charts

A graph showing the amount of work remaining (Y-axis) versus time (X-axis). If the trend line hits zero before the end of the sprint, the team is ahead of schedule.

The organization of the people building the software heavily dictates the architecture of the software (Conway's Law).

⇒16.1 Common Paradigms

• Democratic Decentralized (Agile): No permanent leader. Decisions are made by consensus. Excellent for complex, innovative problems. Poor for massive, routine projects.
• Controlled Centralized (Waterfall): Top-down command structure. A senior engineer dictates design to junior programmers. Efficient for simple, well-understood problems.
• Controlled Decentralized: A project leader oversees sub-team leaders. Best for massive projects requiring hundreds of developers.

⇒16.2 Brooks's Law

'Adding manpower to a late software project makes it later.' When new people join a late project, the existing developers must stop working to train them, and the communication overhead increases exponentially.

EVA is an industry-standard method of measuring project performance and progress in an objective manner, integrating scope, schedule, and cost.

⇒17.1 Key Metrics

• Planned Value (PV): The budgeted cost of the work scheduled to be completed by a certain date.
• Actual Cost (AC): The actual money spent so far.
• Earned Value (EV): The budgeted cost of the work actually completed so far. (e.g., If the project budget is $100k, and you have finished 25$25k).

⇒17.2 Variances

• Schedule Variance (SV = EV - PV): If negative, you are behind schedule.
• Cost Variance (CV = EV - AC): If negative, you are over budget.

EVA prevents the illusion of progress (e.g., 'We spent 50% of the budget, so we must be 50% done').

Quality management involves defining the quality standards that apply to the project, deciding how they will be assessed, and ensuring that they are met.

⇒18.1 The Cost of Quality

Quality isn't free. The cost of quality is divided into:

• Prevention Costs: Training, formal reviews, planning, test automation tools (cheapest in the long run).
• Appraisal Costs: Executing tests, code inspections, equipment maintenance.
• Internal Failure Costs: Fixing bugs found before release (rework, retesting).
• External Failure Costs: Fixing bugs found after release (help desk support, lost sales, lawsuits, brand damage) — infinitely more expensive than prevention.

In modern software development, teams are rarely co-located in a single office.

⇒19.1 Challenges of Distributed Teams

• Communication Breakdown: Time zone differences drastically reduce the bandwidth of communication. An email query might take 24 hours to resolve instead of a 2-minute desk chat.
• Cultural Differences: Different understandings of hierarchy, quality, and directness in giving feedback.
• Knowledge Silos: The offshore team may only understand 'how' to write the code without understanding 'why' the business needs it.

⇒19.2 Mitigation Strategies

Heavy reliance on asynchronous communication tools (Jira, Confluence), strict adherence to detailed API documentation, overlapping working hours (golden hours), and frequent video conferencing.

The discipline of software engineering is constantly evolving due to new technologies.

⇒20.1 AI in Software Engineering

• Automated Code Generation: AI tools (like GitHub Copilot) assisting developers by auto-completing complex boilerplate, shifting the engineer's role from 'writing code' to 'reviewing and orchestrating AI output'.
• Predictive Bug Finding: Machine learning models analyzing code repositories to predict which modules are most likely to contain bugs based on historical commit data.

⇒20.2 Low-Code / No-Code Platforms

Enabling business analysts and subject matter experts to build complex applications using visual drag-and-drop interfaces, entirely bypassing traditional programming. This pushes the role of the traditional software engineer further down the stack to building and maintaining these platforms.