Software Engineering Notes — BCA Sem 6

Software Engineering — Introduction

Why SE? 1968 NATO conference — software projects failing: over budget, late, buggy. Engineering discipline needed.

Software Crisis Problems:

Cost overruns → projects 3-10x over budget
Schedule delays → months/years late
Poor quality → bugs, crashes, security holes
Maintenance nightmare → 60-80% total cost

SE Definition (IEEE): Application of systematic, disciplined, quantifiable approach to development, operation, and maintenance of software.

---

1. SDLC Models

Waterfall Model

Requirements
    ↓
System Design
    ↓
Implementation (Coding)
    ↓
Testing
    ↓
Deployment
    ↓
Maintenance

Pros: Simple, clear phases, documentation good
Cons: Rigid, no changes, late customer feedback
Best for: Small projects, well-defined requirements

Incremental Model

Requirements → Core Module → Deliver Increment 1
              ↓
              More Features → Deliver Increment 2
              ↓
              More Features → Deliver Increment 3
              ↓
              Final Product

Each increment adds functionality
Customer gets working software early

RAD (Rapid Application Development)

Business Modeling → Data Modeling → Process Modeling
→ Application Generation → Testing & Turnover

Reusable components, fast prototyping
60-90 day projects
Requires skilled developers, small teams

Spiral Model

Quadrants per loop:
1. Planning (objectives, constraints)
2. Risk Analysis (identify, resolve risks)
3. Engineering (design, build, test)
4. Evaluation (customer review)

Risk-driven, iterative, large/complex projects
Barry Boehm, 1988

---

2. Agile — Scrum

Scrum Framework:
─────────────────────────────────────────────────────
Sprint (1-4 weeks, fixed)
─────────────────────────────────────────────────────
  Sprint Planning → Daily Standup → Sprint Review → Retrospective

Roles:
  Product Owner: Product backlog, priorities, stakeholders
  Scrum Master: Facilitator, removes blockers, coach
  Dev Team: 3-9 people, cross-functional, self-organizing

Artifacts:
  Product Backlog: All user stories, prioritized
  Sprint Backlog: Stories committed for this sprint
  Increment: Potentially shippable product each sprint

Ceremonies:
  Sprint Planning: What to build this sprint?
  Daily Standup: 15 min, 3 questions (yesterday/today/blockers)
  Sprint Review: Demo to stakeholders
  Sprint Retrospective: How to improve team process?

User Stories:

Format: "As a [type of user], I want [goal], so that [reason]"

Example: "As a BCA student, I want to search notes by subject,
          so that I can find relevant content quickly."

Acceptance Criteria (Given-When-Then):
  Given: I am on notes page
  When: I type "Data Structures" in search box
  Then: I see all notes with "Data Structures" in title/content

Story Points: 1, 2, 3, 5, 8, 13 (Fibonacci) — relative complexity
Velocity: avg story points per sprint → capacity planning

---

3. Requirements Engineering

Types of Requirements:

Functional (FR):
  What system does.
  "System shall allow user to login with email and password"
  "System shall send email notification on successful enrollment"

Non-Functional (NFR):
  How system performs.
  Performance: "Page load < 3 seconds on 4G"
  Security: "Passwords stored using bcrypt hashing"
  Availability: "System uptime > 99.5% per month"
  Usability: "Onboarding completed in < 5 minutes by new user"

SRS Document (IEEE 830) Sections:
  1. Introduction (purpose, scope, definitions)
  2. Overall Description (product perspective, users)
  3. Specific Requirements (FR, NFR)
  4. Appendices

---

4. UML Diagrams

Use Case Diagram

System: Notes Portal

Actors: Student, Teacher, Admin

Use Cases:
  Student: Login, Search Notes, Download PDF, Bookmark
  Teacher: Upload Notes, Create Quiz, View Analytics
  Admin: Manage Users, Approve Content

Relationships:
  <<include>>: Login included in Search (must be logged in)
  <<extend>>: Show Premium extends View Notes (optional)

Class Diagram Key Notation

┌──────────────────┐
│    «interface»   │
│   Downloadable   │
├──────────────────┤
│ + download(): void│
└──────────────────┘
         △ (implements)
         │
┌──────────────────┐       1      * ┌─────────────┐
│      Note        │─────────────── │   Category  │
├──────────────────┤ has-a          ├─────────────┤
│ -id: UUID        │               │ -name: String│
│ -title: String   │               └─────────────┘
│ -content: Text   │
│ -author: User    │
├──────────────────┤
│ +publish(): void │
│ +download(): void│
└──────────────────┘

Sequence Diagram Example

Student   :Browser   :API     :AuthService  :NoteService  :Database
   │          │         │            │              │           │
   │─login──►│         │            │              │           │
   │          │─POST /login─►       │              │           │
   │          │         │─verify──►│              │           │
   │          │         │    ◄─token─             │           │
   │          │◄─200 token──        │              │           │
   │          │         │            │              │           │
   │─search──►│         │            │              │           │
   │          │─GET /notes?q=DS────────────►        │           │
   │          │         │                    │─query DS────────►│
   │          │         │                    │◄────results──────│
   │          │◄─200 [notes]───────────────────────             │

---

5. Software Testing

V-Model (testing mirrors development):
Requirements ─────────────────── Acceptance Test
  System Design ─────────── System Test
    Architecture ─────── Integration Test
      Module Design ─── Unit Test
            Implementation ─┘

Testing Levels

Unit Testing:
  Test individual functions/methods
  Tools: JUnit (Java), pytest (Python), Jest (JS)
  Fast, isolated, mock dependencies

Integration Testing:
  Test combined components
  Top-down: high-level first, stub lower
  Bottom-up: low-level first, driver for higher

System Testing:
  Complete system against SRS requirements
  Functional, performance, security, usability

Acceptance Testing (UAT):
  Customer validates requirements met
  Alpha: in-house users, Beta: external users

Test Case Format

Test Case ID: TC-001
Test Name: Valid User Login
Preconditions: User account exists with email=alice@test.com
Test Steps:
  1. Navigate to /login
  2. Enter email: alice@test.com
  3. Enter password: correct123
  4. Click Login button
Expected Result: Redirect to dashboard, show "Welcome Alice"
Actual Result: [fill after execution]
Status: Pass / Fail

Black Box Techniques

Equivalence Partitioning:
  Age input (1-100): valid=[1-100], invalid=[<1, >100, non-numeric]
  Test one from each class: 50 (valid), 0, 101, "abc"

Boundary Value Analysis:
  Range 1-100: test 0, 1, 2, 99, 100, 101
  (boundaries most likely to have bugs)

Decision Table Testing:
  Conditions → Actions table
  Every combination of conditions tested

---

6. Software Metrics

LOC (Lines of Code): simple but imprecise
Function Points: functionality-based, language independent
Cyclomatic Complexity: V(G) = E - N + 2P
  E=edges, N=nodes, P=connected components
  V(G)=1 no branches, each if/while/case adds 1
  V(G) < 10: simple, V(G) > 20: too complex

Defect Density = Defects / KLOC (thousand lines)
Code Coverage = (lines tested / total lines) × 100%
MTBF (Mean Time Between Failures): reliability
MTTR (Mean Time To Repair): maintainability

---

Exam Important Questions

1. Waterfall vs Agile model — advantages, disadvantages, when to use
2. Scrum framework explain karo — roles, ceremonies, artifacts
3. SRS document mein kya hota hai? FR vs NFR examples
4. Use Case diagram draw karo — Library Management System
5. Black-box testing techniques — equivalence partitioning, BVA
6. V-Model explain karo — testing levels kaise relate hote hain
7. Cyclomatic complexity kya hai aur kaise calculate karte hain?
8. User story format aur acceptance criteria example

---

Viva Questions

Q: Technical debt kya hota hai? A: Jab quick/shortcut code likhte hain — future mein refactoring/fixes mein extra time lagata hai, jaise interest. Ward Cunningham ne term banaya. Regular refactoring se debt reduce karo — otherwise codebase unmaintainable ho jaata hai.

Q: Regression testing kyun zaroori hai? A: Nayi code changes existing functionality break na karein — verify karo. Har release ke pehle run karo. Automated regression suite time bachata hai. Continuous Integration mein automatically run hota hai.

Q: CMMI kya hai? A: Capability Maturity Model Integration — organization ki software process maturity measure karta hai. 5 levels: Initial → Managed → Defined → Quantitatively Managed → Optimizing. Level 3+ = established processes. Large orgs CMMI certification lete hain.