Software Eng & PM

Building Bits
& Managing Chaos

Software Engineering is more than just coding; it's the disciplined application of engineering principles to software development. Project Management ensures that this development is organized, efficient, and meets its goals.

00 / Foundations

The Nature of Software

Software is unique among engineering artifacts. It is malleable, complex, and invisible. Unlike hardware, software doesn't "wear out," but it does deteriorate over time due to change.

Invisibility

You can't see the structure of software like you can a bridge. This makes it hard to visualize problems.

Complexity

Software systems have millions of moving parts (states), far more than any machine.

Malleability

Software is easy to change, which leads to the false belief that it is easy to change correctly.

Deterioration

As software is changed, its structure degrades (entropy increases) unless refactored.

Unique Nature of WebApps

Web applications are a specialized form of software with distinct characteristics that influence how they are engineered.

  • 01

    Network Intensiveness: They live on the network; latency and connectivity are critical factors.

  • 02

    Concurrency: Thousands of users may access the application closely or simultaneously.

  • 03

    Unpredictable Load: Traffic can spike from 100 to 100,000 users in minutes.

  • 04

    Availability: Users expect 24/7/365 uptime.

  • 05

    Data Driven: The primary function is often to present processing of complex data.

The Software Process

A process framework establishes the foundation for a complete software engineering process. It identifies a small number of framework activities that are applicable to all software projects.

Communication
Planning
Modeling
Construction
Deployment

The Generic Process Framework

SDLC (Software Development Life Cycle)

A structured process that enables the production of high-quality, low-cost software in the shortest possible production time.

1

Planning & Requirements

Gathering requirements from stakeholders. Answering "What do we want?" and "What is feasible?".

2

Defining (SRS)

Documenting requirements in a Software Requirement Specification (SRS). Getting approval.

3

Designing

Creating the system architecture. High-Level Design (HLD) and Low-Level Design (LLD).

4

Building (Coding)

The act of converting design into code.

5

Testing

Verifying that the software meets requirements and is bug-free.

6

Deployment

Releasing the software to the user (e.g., SIT, UAT environments).

7

Maintenance

Upgrading the software, fixing bugs, and responding to user feedback.

Software Engineering Practice

At its core, engineering is problem solving. George Polya's "How to Solve It" provides the essence of software engineering practice.

1. Understand the Problem

Communication and Analysis. Who connects? What is the unknown? What are the data/conditions?

2. Plan the Solution

Modeling and Design. Have you seen this before? Do you know a related problem? Draw a figure.

3. Carry Out the Plan

Code Generation. Write the code. Keep it clean. Check each step.

4. Examine the Result

Testing and QA. Can you check the result? Can you derive the result differently?

Software Myths

Beliefs about software and the process of building it can be traced to the earliest days of computing. Many are erroneous and harmful.

Management Myth

"We have standards and procedures, so we are good."

Reality: Standards are often unused or outdated. Developers don't follow them if they aren't practical.

Customer Myth

"A general statement of objectives is enough to start coding."

Reality: Ambiguous requirements are the root of most project failures. Detailed understanding is required.

Practitioner Myth

"Once we write the program and get it to work, our job is done."

Reality: 60-80% of effort is expended after the software is delivered to the customer.

01 / Process Models

The Generic Process Model

Regardless of the specific model chosen, all software development relies on a generic process framework consisting of five activities.

Communication
Planning
Modeling
Construction
Deployment

Process Assessment (CMMI)

The Capability Maturity Model Integration (CMMI) defines five levels of process maturity:

1. Initial Ad hoc, chaotic
2. Managed Project level
3. Defined Org standard
4. Measured Quantitative
5. Optimizing Continuous value

Prescriptive Process Models

These models advocate an orderly approach to software engineering. Use the tabs below to explore them.

Waterfall
Incremental
Evolutionary (Spiral)
Concurrent

The classic life cycle. Systematic, sequential approach. Good for well-defined requirements.

Communication

Project initiation, requirements gathering.

Planning

Estimating, scheduling, tracking.

Modeling

Analysis and Design.

Construction

Code and Test.

Deployment

Delivery, Support, Feedback.

Combines linear and parallel process flows. Delivers software in small but usable pieces (increments).

Increment 1
Core Product (Basic features)
Increment 2
Additional Features
Increment 3
Refinement & Extras

Iterative models designed to accommodate change. The Spiral Model is a risk-driven process generator.

COMMUNICATION PLANNING MODELING CONSTRUCTION Start
Communication: Establish requirements.
Planning: Risk analysis, scheduling.
Modeling: Design & Engineering.
Construction: Code, Test, Release.

Radius increases with cost/time. Angular dimension represents progress through phases.

A schema of States. Activities exist concurrently in different states. Transitions are triggered by events.

State none
Active under development
Review awaiting review
Final done

EVENT: [Review Required] → TRANSITION: [Under Development] to [Awaiting Review]

Specialized Process Models

Component-Based

Focuses on reusing existing components to assemble software. Increases efficiency.

Formal Methods

Mathematical specification and verification. Used for safety-critical systems (aerospace, medical).

AOSD

Aspect-Oriented. Focuses on modularizing cross-cutting concerns (logging, security).

The Unified Process (UP)

A use-case driven, architecture-centric, iterative and incremental software process.

Inception
Communication & Planning. Feasibility, scope, business case.
Elaboration
Planning & Modeling. Core architecture, risk resolution.
Construction
Construction. Code generation, testing, integration.
Transition
Deployment. Beta testing, user training, rollout.

Personal & Team Process

PSP (Personal)

Structured process for the individual. Emphasizes measurement (LOC, defects) and planning.

Goal: Personal Discipline

TSP (Team)

Building self-directed teams that plan and track their own work. Requires PSP training.

Goal: Team Productivity
02 / Requirements

Understanding Requirements

Requirements engineering is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

Elicitation Asking questions, gathering info.
Elaboration Creating models, refining details.
Negotiation Reconciling conflicts, priorities.
Specification Documentation (SRS).
Validation Reviewing for errors.
Management Tracking changes.

Requirement Modeling: Scenarios

Describing how the system is used from the user's perspective.

Use Cases

User SYSTEM Login View Dashboard

User Stories

"As a Student,
I want to download course materials,
so that I can study offline."
"As an Admin,
I want to ban users,
so that I can maintain safety."

Modeling Strategies

View the requirements from different angles to ensure completeness.

Flow-Oriented
Class-Based
Behavioral

Visualizing how data moves through the system (Data Flow Diagram - DFD).

User Input
Process Input
Database

Defining objects, attributes, and relationships (Class Diagram).

SoftwareEngineer
+ name: String
+ skills: List<String>
+ coffeeLevel: int
+ code()
+ debug()
+ deploy()

Modeling how the system reacts to external events (State Diagram).

Idle
→ Event: Click →
Processing
→ Event: Done →
Success
03 / Agility

Agile Development

Agility is about rapid response to change, effective communication, and delivering value. It's not just a process, but a philosophy.

The Agile Manifesto

Individuals & Interactions over processes and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to Change over following a plan

While there is value in the items on the right, we value the items on the left more.

Extreme Programming (XP)

The most widely used agile process, proposed by Kent Beck. It pushes good practices to the "extreme".

Communication Simplicity Feedback Courage Respect
Planning
Planning Game

Determine the scope of the next release by combining business priorities with technical estimates. Users write stories; developers estimate them.

Release
Small Releases

Put a simple system into production quickly, then release new versions on a very short cycle.

Design
Metaphor

Guide all development with a simple shared story of how the whole system works (e.g., "The system is like an assembly line").

Design
Simple Design

The system should be designed as simply as possible at any given moment. Extra complexity is removed immediately.

Coding
Pair Programming

Two programmers work together at one machine. One types (Driver), the other reviews and thinks strategically (Navigator).

Testing
Test-Driven Development

Write a failing automated test before writing any code. Then write just enough code to pass the test.

Coding
Refactoring

Restructure the system without changing its behavior to remove duplication, improve communication, and simplify.

Coding
Coding Standards

Programmers write code in accordance with rules emphasizing communication through code.

Team
Collective Ownership

Anyone can change any code anywhere in the system at any time.

Integration
Continuous Integration

Integrate and build the system many times a day, every time a task is completed.

Team
40-Hour Week

Work only as many hours as you can sustain. Tired programmers make more bugs.

Team
On-site Customer

Include a real, live user on the team, available full-time to answer questions.

Other Frameworks

Scrum

A framework within Agile.

  • Sprints: Short, time-boxed periods (usually 2 weeks) to complete set work.
  • Stand-ups: Daily short meetings to sync on progress and blockers.
  • Roles: Scrum Master, Product Owner, Development Team.

Kanban

Visualizing work.

  • Board: Columns representing states (To Do, Doing, Done).
  • WIP Limits: Limiting "Work In Progress" to improve flow.
  • Continuous Flow: No fixed time-boxes, focus on cycle time.
04 / Project Management

Project Management

Managing software projects involves estimation, scheduling, and risk management to ensure timely delivery.

Estimation Techniques

LOC

Lines of Code.

Direct measure. Easy to count but language-dependent and can encourage bloat.

FP

Function Points.

Indirect measure based on functionality (inputs, outputs, inquiries). Language independent.

COCOMO

Constructive Cost Model.

Empirical mathematical model. Effort = a(KLOC)^b * EAF.

Scheduling

PERT / CPM

Program Evaluation Review Technique & Critical Path Method.

1
2 CP
3

Identifying the longest path (Critical Path) determines project duration.

Gantt Chart

Timeline visualization.

Design
Dev
Test

Risk Management (RMMM)

Mitigation

Proactive planning to avoid the risk (e.g., training staff).

Monitoring

Tracking risk factors (e.g., watching staff turnover).

Management

Contingency plan if the risk occurs (e.g., hiring contractors).

PM Tools

J

JIRA / Linear

The industry standards for issue tracking and agile project management. Great for detailed sprint planning and backlog management.

T

Trello / Notion

More flexible, visual tools often used for smaller teams or documentation-heavy workflows (Notion).

05 / Construction

Constructing Code

G

Version Control (Git)

Managing code changes over time. Essential for collaboration.

# Initialize a repository $git init

# Stage changes $git add .

# Commit changes $git commit -m "feat: add user login"

# Push to remote $git push origin main

# Branching $git checkout -b feature/new-ui
06 / Delivery

CI/CD

Continuous Integration and Continuous Delivery/Deployment. Automating the bridge between coding and running in production.

The CI/CD Pipeline

CI
1. Source
  • Code Commit
  • Pull Request
  • Code Review
CI
2. Build
  • Linting
  • Compiling
  • Unit Tests
  • Docker Image
CD
3. Test
  • Integration Tests
  • E2E Tests
  • Security (SAST)
CD
4. Deploy
  • Staging (UAT)
  • Production
  • Monitoring
DevSecOps

Integrating security practices within the DevOps process.

Static Analysis SAST

Scanning source code for vulnerabilities (White Box).

Dynamic Analysis DAST

Scanning running application (Black Box).

06 / Delivery

Software Testing

Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user.

Verification vs Validation (V&V)

Verification

"Are we building the product right?"

Ensures the software meets specifications. Primarily static activities like Reviews, Walkthroughs, and Inspections.

Validation

"Are we building the right product?"

Ensures the software meets customer needs. Primarily dynamic activities like Execution and Testing.

Testing Strategies

W
White Box Testing

"Glass Box". Testing with full knowledge of internal logic and code structure.

  • Basis Path Testing: Ensuring every path is executed.
  • Control Structure: Condition, Data Flow, and Loop testing.
  • Focus: Logic, complexity, paths.
B
Black Box Testing

"Opaque Box". Testing based on requirements and functionality without seeing code.

  • Equivalence Partitioning: Valid/Invalid input classes.
  • Boundary Value Analysis: Testing edges (e.g., <, >, =).
  • Focus: Input/Output, interface, behavior.

Levels of Testing

Level 1
Unit Testing

Testing individual components in isolation. Heavy use of White Box techniques.

Level 2
Integration Testing

Testing the interface between components. Strategies: Big Bang (all at once) or Incremental (Top-down / Bottom-up).

Level 3
Validation Testing

Validating against requirements. Includes Alpha (at developer site) and Beta (at customer site) testing.

Level 4
System Testing

Testing the entire system in context. Includes Recovery, Security, Stress, and Performance testing.

Glossary

Key Definitions

Refactoring

Restructuring existing code without changing its external behavior.

Tech Debt

The implied cost of additional rework caused by choosing an easy solution now instead of a better approach that would take longer.

MVP

Minimum Viable Product. A product with just enough features to satisfy early customers.

Pull Request

A method of submitting contributions to a software project.

Sprint

A set period of time during which specific work has to be completed and made ready for review.

Backlog

A prioritized list of work for the development team.

06 / Knowledge Check

Knowledge Check

Verify your understanding of Software Engineering. Pass the exam with a perfect score to earn your completion certificate.