Back to Subject
Practice MCQ

Unit 5 - Notes

CSE320

Unit 5: Software Project Management & DevOps Practices

1. Project Management Basics

Software Project Management (SPM) is the art and science of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored, and controlled.

The 4 P’s of Management Spectrum

Effective software project management focuses on four items (The 4 P's):

  1. People: The most important asset. Includes recruiting, selecting, performance management, training, and team organization.
  2. Product: The software to be built. Objectives and scope must be established before planning can begin.
  3. Process: The framework activities and software engineering tasks required to build the product (e.g., Agile, Waterfall).
  4. Project: The complexity of the specific project, considering budget, schedule, and risks.

Key Activities in SPM

  • Scoping: Defining the boundaries of the software.
  • Planning: Estimating resources, costs, and schedules.
  • Staffing: Assigning roles and responsibilities.
  • Monitoring: Tracking progress against the plan.
  • Risk Management: Identifying and mitigating potential failures.

2. Project Planning & Monitoring

Project planning provides a roadmap for the software engineering team. Monitoring ensures the team stays on that road.

The Planning Process

  1. Scope Definition: What functions must the software perform? What are the constraints?
  2. Resources Estimation: Hardware, software, and human resources required.
  3. Project Estimation: Cost and effort estimation (using techniques like COCOMO or FP).
  4. Schedule Definition: Creating a timeline (Start/End dates).
  5. Risk Analysis: What could go wrong?

Work Breakdown Structure (WBS)

A hierarchical decomposition of the total scope of work to be carried out by the project team.

  • Level 1: Project Name.
  • Level 2: Major Phases (e.g., Requirements, Design).
  • Level 3: Specific Tasks (e.g., Database Design, UI Design).
  • Level 4: Work Packages (Assigning to specific individuals).

Project Monitoring and Control

  • Status Reporting: Regular updates (Daily stand-ups, weekly reports).
  • Earned Value Analysis (EVA): A quantitative technique to measure project performance and progress in an objective manner.
  • Variance Analysis: Comparing actual performance against planned performance (Schedule Variance and Cost Variance).

3. Cost Estimation Methods

Software cost estimation predicts the amount of effort and time required to build a software system.

A. Function Points (FP) Analysis

A technique to estimate the size of a software project based on the functionality provided to the user, rather than lines of code.

Five Information Domain Characteristics:

  1. External Inputs (EI): Data entering the system (e.g., login screen).
  2. External Outputs (EO): Data leaving the system (e.g., reports).
  3. External Inquiries (EQ): Immediate input/output response (e.g., search query).
  4. Internal Logical Files (ILF): Data stored within the system (e.g., database tables).
  5. External Interface Files (EIF): Data shared with other systems.

Calculation:

  1. Unadjusted Function Point (UFP): Sum of the weighted counts of the five characteristics (weights are Simple, Average, or Complex).
  2. Value Adjustment Factor (VAF): Based on 14 General System Characteristics (GSCs) such as performance, reusability, and ease of installation.
  3. Final Formula:

    (Where are the complexity adjustment values)

B. Use Case Points (UCP)

An estimation method used for projects that use the Unified Modeling Language (UML) and Use Cases.

Steps:

  1. Unadjusted Actor Weight (UAW): Classify actors (Simple API, System, or Human GUI) and sum weights.
  2. Unadjusted Use Case Weight (UUCW): Classify use cases by number of transactions (Simple, Average, Complex).
  3. Technical Complexity Factor (TCF): Technical requirements (distributed system, performance).
  4. Environmental Complexity Factor (ECF): Team capability (motivation, experience).
  5. Formula:

C. COCOMO (Constructive Cost Model) - Intro

Proposed by Barry Boehm, COCOMO is an empirical model derived from analyzing data from historical software projects. It estimates effort in Person-Months (PM) based on the size of the code (KLOC - Kilo Lines of Code).

Three Modes of Development:

  1. Organic: Small, simple projects, experienced teams, relaxed requirements.
  2. Semi-detached: Intermediate size and complexity, mixed team experience.
  3. Embedded: Tight constraints (hardware/software), complex, high reliability needed.

Three Levels of the Model:

  1. Basic COCOMO: Quick, rough estimate.
  2. Intermediate COCOMO: Adds "Cost Drivers" (15 attributes like reliability, capability, tool use) to refine the estimate.
  3. Detailed COCOMO: Estimates effort for each phase of the development lifecycle (Analysis, Design, Coding, Testing).

4. Scheduling Techniques

Scheduling involves allocating time segments to specific tasks and managing dependencies.

A. Gantt Charts

A bar chart that illustrates a project schedule.

  • X-axis: Time (dates).
  • Y-axis: Tasks/Activities.
  • Bars: Represent the duration of tasks.
  • Pros: Easy to visualize duration and progress.
  • Cons: Does not explicitly show dependencies (which task must finish before another begins) as clearly as network diagrams.

B. PERT (Program Evaluation and Review Technique)

A network-based scheduling technique used when activity durations are uncertain (probabilistic). It uses three time estimates for each task:

  1. Optimistic time (): Shortest time possible.
  2. Most likely time (): Realistic time.
  3. Pessimistic time (): Longest time (worst case).

Expected Time () Calculation:

C. CPM (Critical Path Method)

A deterministic network model used when activity durations are known with certainty.

  • Nodes: Represent events (start/end of tasks).
  • Edges (Arrows): Represent activities and duration.
  • Critical Path: The longest path through the network diagram. It determines the shortest possible time to complete the project.
  • Slack/Float: The amount of time a task can be delayed without delaying the project. Tasks on the Critical Path have Zero Slack.

5. Software Configuration Management (SCM)

SCM is the discipline of controlling the evolution of complex software systems. It manages change throughout the software lifecycle.

Why SCM?

  • Multiple people working on the same code.
  • Multiple versions released to customers.
  • Need for reversibility (undoing changes).

Core Elements of SCM

  1. SCM Directories/Repositories: The central storage for all project artifacts.
  2. Version Control: Managing changes to files over time (e.g., Git, SVN). Allows branching and merging.
  3. Change Control: A formal process to request, evaluate, approve, and implement changes (often managed by a Change Control Board - CCB).
  4. Configuration Auditing: Verifying that the software matches the requirements and that proper process was followed.
  5. Status Accounting: Reporting the status of components and changes (e.g., "What changes went into Release 2.0?").

Baselines

A specification or product that has been formally reviewed and agreed upon. It serves as the basis for further development and can be changed only through formal change control procedures (e.g., "Requirement Baseline," "Production Baseline").

6. Introduction to CI/CD Tools

CI/CD bridges the gap between development (Dev) and operation (Ops) by enforcing automation in building, testing, and deployment.

Concepts

  • Continuous Integration (CI): Developers frequently commit code to a shared repository. Each commit triggers an automated build and test sequence to detect errors early.
  • Continuous Delivery (CD): Automated release of code to a repository where it is ready for deployment.
  • Continuous Deployment (CD): Every change that passes all stages of the production pipeline is released to customers automatically.

GitHub Actions

GitHub Actions is a CI/CD platform that allows you to automate your build, test, and deployment pipeline directly within GitHub.

Key Components of GitHub Actions

  1. Workflows: A configurable automated process defined by a YAML file (.github/workflows/main.yml).
  2. Events: A specific activity that triggers a workflow (e.g., push, pull_request, or a scheduled time).
  3. Jobs: A set of steps in a workflow that execute on the same runner. By default, jobs run in parallel.
  4. Runners: A server that runs the workflow (e.g., Ubuntu Linux, Windows, macOS).
  5. Steps: Individual tasks within a job. Can be a shell script or an "Action" (a reusable piece of code).

Example: Basic GitHub CI/CD Workflow

This YAML configuration runs a test suite whenever code is pushed to the main branch.

YAML
name: Node.js CI

# Event: Trigger on push to 'main' branch
on:
  push:
    branches: [ main ]

jobs:
  build-and-test:
    # Runner: Use latest Ubuntu environment
    runs-on: ubuntu-latest

    steps:
    # Step 1: Check out the code from the repository
    - uses: actions/checkout@v3

    # Step 2: Set up Node.js environment
    - name: Use Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '16.x'

    # Step 3: Install dependencies
    - name: Install Dependencies
      run: npm install

    # Step 4: Run Tests
    - name: Run Tests
      run: npm test

Benefits of CI/CD with GitHub Actions

  • Automation: Reduces manual errors in deployment.
  • Speed: Faster feedback loops for developers.
  • Integration: Tightly integrated with the source code repository.
  • Scalability: Can handle complex workflows including Docker containerization and cloud deployments (AWS, Azure).