📘 CS504 – Software Engineering I (Short Notes: Lectures 1–45)

Lecture 1: Introduction to Software Engineering

Software = Program + Data + Documentation.

Importance: Used in business, science, embedded systems, games, education.

Difference from hardware: Software doesn’t wear out, but bugs exist.

Software Crisis: 1960s → Large software, late delivery, over-budget, unreliable.

IEEE Definition: Systematic, disciplined, quantifiable approach to development.

Well-engineered software: Reliable, maintainable, efficient, user-friendly, cost-effective.

Balancing act: Trade-offs among cost, reliability, efficiency, UI.

Law of Diminishing Returns: Quality improvement beyond a point = costly, less benefit.

Lecture 2: Introduction to Software Development

Activities:

Construction: Requirements, design, coding, testing.

Management: Planning, quality assurance, configuration mgmt.

Framework: Quality focus → Process → Methods → Tools.

Development Loop: Problem definition → Technical development → Integration → Status quo →

Repeat.

Phases: Vision → Definition → Development → Maintenance.

Maintenance cost often > development cost.

Lecture 3–5: Requirement Engineering

Definition: Process of defining system services & constraints (focus on what, not how).

Importance: 40–60% defects due to poor requirements.

Levels of Requirements:

Business (high-level goals).

User (tasks users must perform).

Functional (system functionality).

Non-functional (performance, security, constraints).

Risks: Insufficient user input, creeping requirements, ambiguity, gold plating, minimal specs.

Good Requirements: Complete, correct, feasible, necessary, prioritized, unambiguous, verifiable.

Documents: Requirement Statement (user) & Specification (functional).

Context Diagram: Shows boundary between system and external entities.

Lecture 6–7: Use Case Modeling & Source/Sink

Use Case Model: Actors + Use cases (system as black box).

Relations: <<uses>> and <<extends>>.

Elaborated Use Case: Name, actors, summary, pre/post conditions, normal/alternate flow.

Activity Diagram: Flow of use case.

Limitation: Non-functional reqs not covered.

Source/Sink Analysis:

Source: Input origin.

Sink: Where output is consumed.

Ensures requirements completeness.

Lecture 8–11: Modeling & Design

State Transition Diagrams: System states & events.

Process Models: Waterfall, Incremental, Spiral, Prototyping.

Prototyping: Quick mock-up to validate requirements.

GUI Design Principles: Consistency, feedback, simplicity, error handling.

Software Design: Converts requirements into solution. Must ensure modularity, cohesion, coupling.

Lecture 12–18: OOA/D & Case Study

Cohesion: Degree module elements belong together (High = good).

Coupling: Degree of interdependence (Low = good).

OO Analysis & Design: Objects, classes, encapsulation, inheritance, polymorphism.

UML Object Model Notations: Class diagrams, associations, generalization.

Coad Methodology: Deriving object model step-by-step.

Case Study: Connie’s Convenience Store → practical UML/object model application.

Lecture 19–21: Structure & Interaction Diagrams

Relationships: Generalization, aggregation, association, multiplicity, navigation.

Class Diagram: Shows static structure.

Interaction Diagrams:

Sequence Diagram → Time focus.

Collaboration Diagram → Structure focus.

Sequence Elements: Lifeline, messages, activations, loops/conditions.

Lecture 22–25: Architecture

Software Architecture = High-level structure, components, relations.

Views: Logical, Process, Development, Physical, Use-case.

Models:

Client-Server: Clients request, server responds.

Two-tier: Client (UI+logic), Server (DB).

Three-tier: UI + Logic + Data layers.

Layered: Separated into presentation, business, data, etc.

Pipes & Filters: Data passes through filters (e.g., compiler).

Repository: Central shared DB, modules interact.

Lecture 26–27: Design Patterns

Definition: Reusable solution to common design problem.

Types: Creational (Factory, Singleton), Structural (Adapter, Decorator), Behavioral (Observer, Strategy).

Observer Pattern: Subject notifies observers automatically → loose coupling.

Lecture 28–35: Coding Practices

Good Practices: Meaningful names, indentation, comments, modularity.

File Handling:

C++ → <fstream>, ifstream, ofstream.

Java → FileReader, BufferedReader.

Coding Style:

Classes → PascalCase, Variables → camelCase.

Consistent layout, avoid long lines.

Modularity: Improves clarity, testing, reuse.

Common Mistakes: Syntax, logic, runtime errors.

Portability: Use standard libs, avoid OS-dependent code.

Exception Handling: try-catch, throw, finally. Catch specific exceptions.

Lecture 36–40: Testing

Verification: Build product right.

Validation: Build right product.

Testing Types:

Black Box: Tests functionality without seeing code.

White Box: Tests internal logic.

Techniques:

Equivalence Partitioning: Divide inputs into valid/invalid sets.

Statement Coverage: Test every statement.

Branch Coverage: Test true/false outcomes.

Path Coverage: Test all possible paths.

Unit Testing: Tests smallest components independently.

Lecture 41–44: Quality & Debugging

Inspections: Manual review (design/code).

Testing: Executing code.

Debugging Process: Reproduce bug → Identify cause → Fix → Retest.

Bug Types: Syntax, logic, runtime, semantic.

Holistic Approach: All phases (requirements, design, coding, testing, maintenance) are linked and must
be managed together.

Lecture 45: Summary

Software engineering = Systematic, disciplined approach.

Covers requirements, design, coding, testing, maintenance.

Quality software = balance between cost, reliability, performance, UI.

Emphasis: Discipline, documentation, modularity, clarity, testing.