Back to Subject
Practice MCQ

Unit 1 - Notes

CSE320

Unit 1: Software Engineering Foundations & SDLC

1. Evolution and Impact of Software Engineering

Definition

Software Engineering is the systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software. It applies engineering principles to software creation to ensure reliability, efficiency, and maintainability.

The Evolution of Software

The history of software engineering is generally categorized into four eras:

  1. The Early Era (1950s – mid-1960s):
    • Characteristics: Batch orientation, limited distribution, custom software.
    • Methodology: "Code and Fix" (no formal design).
    • Hardware: Mainframes.
  2. The Second Era (Mid-1960s – late 1970s):
    • Characteristics: Multi-user, real-time systems, introduction of databases.
    • The Software Crisis: As hardware became powerful, software became complex, unmanageable, over budget, and unreliable. This led to the 1968 NATO conference where the term "Software Engineering" was coined.
  3. The Third Era (Mid-1970s – late 1980s):
    • Characteristics: Distributed systems, embedded intelligence, low-cost hardware.
    • Focus: Productivity and scalability.
  4. The Fourth Era (1990s – Present):
    • Characteristics: Powerful desktop systems, object-oriented technologies, expert systems, artificial intelligence, parallel computing, and cloud computing.

Impact of Software Engineering

  • Economic Impact: Software drives the global economy. Efficient engineering reduces development costs and time-to-market.
  • Reliability & Safety: Critical for safety-critical systems (medical devices, aviation, nuclear plants) where failure is not an option.
  • Scalability: Allows systems to grow from supporting ten users to millions (e.g., social media platforms).
  • Maintainability: Solves the legacy code problem, allowing systems to evolve without total rewrites.

2. Software Development Life Cycle (SDLC)

The SDLC is a framework defining tasks performed at each step in the software development process. It ensures the software is high quality and meets customer expectations.

Core Phases

  1. Requirement Gathering & Analysis: Stakeholders define "what" is needed.
  2. Feasibility Study: Assessing technical, operational, and economic viability.
  3. Design: Blueprinting the system (Architecture, UI, Database design). "How" it will be built.
  4. Implementation (Coding): Translating design into source code.
  5. Testing: Verifying that the code meets requirements and is bug-free.
  6. Deployment: Releasing the software to the production environment.
  7. Maintenance: Bug fixes, updates, and improvements after deployment.

3. Life Cycle Models

A. Waterfall Model (Classical/Linear Sequential)

The oldest model where each phase must be completed before the next begins.

  • Process: Requirements Design Implementation Verification Maintenance.
  • Pros: Simple, easy to manage, clear milestones.
  • Cons: Inflexible to changes; working software is not produced until late in the cycle; high risk if requirements are misunderstood.
  • Best For: Small projects with fixed, clear requirements.

B. Prototyping Model

A throwaway model is built to understand the requirements.

  • Process: Listen to customer Build Mock-up Customer Test Drive Refine.
  • Pros: Users see the system early; reduces risk of incorrect requirements.
  • Cons: Can lead to "scope creep"; the prototype code (often poor quality) might be reused in the final product mistakenly.
  • Best For: Projects where requirements are unclear or the UI is complex.

C. Spiral Model

Combines the iterative nature of prototyping with the controlled and systematic aspects of the Waterfall model. It focuses heavily on Risk Analysis.

  • Quadrants:
    1. Objective setting.
    2. Risk assessment and reduction.
    3. Development and validation.
    4. Planning the next iteration.
  • Pros: High amount of risk analysis; good for large and mission-critical projects.
  • Cons: Expensive; requires risk assessment expertise; complex to manage.

D. V-Model (Verification and Validation)

An extension of the Waterfall model where process steps are bent upwards after the coding phase to form a V shape. Each development phase has a corresponding testing phase.

  • Left Side (Verification): Requirements System Design Arch Design Module Design.
  • Right Side (Validation): Unit Testing Integration Testing System Testing Acceptance Testing.
  • Pros: Testing is planned early; higher quality than Waterfall.
  • Cons: Still rigid regarding requirements changes.

E. Agile & Scrum

Agile is a mindset described in the Agile Manifesto, valuing individuals and interactions over processes and tools, and responding to change over following a plan.

Scrum is the most popular Agile framework.

  • Sprints: Work is divided into time-boxed iterations (usually 2-4 weeks).
  • Roles:
    • Product Owner: Defines features (User Stories) and prioritizes the backlog.
    • Scrum Master: Facilitates the process, removes blockers.
    • Team: Cross-functional group that builds the software.
  • Artifacts: Product Backlog, Sprint Backlog, Increment.
  • Ceremonies: Sprint Planning, Daily Stand-up, Sprint Review, Sprint Retrospective.
  • Pros: Handles changing requirements well; frequent delivery of working software.

F. DevOps Lifecycle

DevOps is a cultural shift bridging Development (Dev) and Operations (Ops). It emphasizes automation and continuous monitoring.

  • Concept: Infinite loop of continuous improvement.
  • Phases: Plan Code Build Test Release Deploy Operate Monitor.
  • CI/CD (Continuous Integration/Continuous Deployment):
    • CI: Developers merge code to a shared repository frequently; automated builds/tests run.
    • CD: Automated release to production.
  • Pros: Faster time to market; higher stability; immediate feedback loops.

4. Requirements Engineering

The process of defining, documenting, and maintaining requirements.

Types of Requirements

1. Functional Requirements (FR)

Describes what the system should do. These are specific behaviors or functions.

  • Examples:
    • "The system shall allow users to log in using email and password."
    • "The system shall calculate sales tax based on the shipping address."
    • "The system shall generate a PDF invoice after purchase."

2. Non-Functional Requirements (NFR)

Describes how the system performs a certain function. These are quality attributes (constraints).

  • Categories (FURPS+):
    • Usability: Ease of learning, UI aesthetics.
    • Reliability: Availability (e.g., 99.9% uptime), disaster recovery.
    • Performance: Response time, throughput, resource usage.
    • Supportability: Maintainability, scalability, portability.
    • Security: Encryption, access controls.

Requirement Gathering (Elicitation) Techniques

  1. Interviews: One-on-one meetings with stakeholders (open-ended or structured).
  2. Surveys/Questionnaires: Good for gathering data from a large number of users.
  3. Observation: Watching users perform their jobs to understand workflows.
  4. Brainstorming: Group sessions to generate new ideas.
  5. JAD (Joint Application Development): Intensive workshops bringing users and developers together.
  6. Document Analysis: Reviewing existing manuals, forms, and reports.

Requirement Analysis

After gathering, requirements are analyzed to resolve conflicts, prioritize, and ensure they are feasible. Techniques include creating Use Case diagrams, Data Flow Diagrams (DFD), and State Transition Diagrams.

5. Software Requirements Specification (SRS)

The SRS is a formal document that acts as a contract between the client and the developer. It fully describes the expected behaviour of the system.

Purpose of SRS

  • Agreement: Establishes the basis for agreement between customer and supplier.
  • Reference: Reduces development effort by revealing omissions and misunderstandings early.
  • Validation: Provides a baseline for validation and verification (testing).

IEEE Standard 830 Structure

The standard template for an SRS includes:

  1. Introduction
    • Purpose
    • Scope
    • Definitions, acronyms, and abbreviations
    • References
    • Overview
  2. Overall Description
    • Product perspective (Interfaces)
    • Product functions
    • User characteristics
    • Constraints
    • Assumptions and dependencies
  3. Specific Requirements (The core technical section)
    • Functional Requirements
    • External Interface Requirements
    • Performance Requirements
    • Design Constraints
    • Software System Attributes (Security, Maintainability)

Characteristics of a Good SRS

To be effective, an SRS must be:

  1. Correct: Accurately reflects the client's needs.
  2. Unambiguous: Every requirement has only one interpretation.
  3. Complete: Nothing is left out; includes responses to all input classes.
  4. Consistent: No conflicts between requirements (e.g., logical or temporal conflicts).
  5. Ranked for Importance: Distinguishes between essential (must-have) and desirable (nice-to-have).
  6. Verifiable: Every requirement can be tested (e.g., avoid vague words like "user-friendly" or "fast"—instead use "response time < 2 seconds").
  7. Modifiable: Structure and style allow easy changes.
  8. Traceable: Origin of each requirement is clear (backward traceability) and facilitates referencing in future development steps (forward traceability).

SRS Validation

The process of ensuring the SRS is correct before design begins.

  • Reviews/Walkthroughs: Peer and stakeholder review.
  • Prototyping: Validating user interfaces and flows.
  • Model Validation: Checking logical consistency.
  • Requirement Testing: Designing test cases based on the SRS to ensure testability.