Software Engineering Essentials: Principles and Practices

1. Fundamentals and Professional Responsibility

Software Engineering is not just about writing code; it is an engineering discipline focused on cost-effective and reliable production.

  • Software Engineering vs. Computer Science: Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.
  • The Four Essential Attributes:
    • Maintainability: Software should be written so that it can evolve to meet the changing needs of customers.
    • Dependability and Security: Includes reliability, safety, and security. It should not cause physical or economic damage in the event of system failure.
    • Efficiency: Software should not make wasteful use of system resources (memory, processor cycles).
    • Acceptability: Must be understandable, usable, and compatible with other systems.

2. Software Process Models

A software process is a structured set of activities. Key models include:

  • The Waterfall Model:
    • Process: Requirements → Design → Implementation → Testing → Maintenance.
    • Pros/Cons: Highly disciplined but inflexible. A small change in requirements requires restarting the whole process.
    • Use Case: Critical systems (Medical, Aerospace) where safety and documentation are more important than speed.
  • Incremental Development:
    • Process: Develop an initial implementation, expose it to user comment, and evolve it through many versions.
    • Pros/Cons: Cheaper to change requirements and easier to get customer feedback. However, the system structure tends to degrade as new increments are added.
  • Agile Development (XP & Scrum):
    • Principles: Customer involvement, incremental delivery, people over process, and embracing change.
    • Extreme Programming (XP): Uses “User Stories” for requirements and “Pair Programming” for quality. It emphasizes Test-First Development, where you write the test before the code.

3. Requirements Engineering

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

  • Functional Requirements: Describe what the system should do (e.g., “A user shall be able to search the appointments schedule for all clinics.”).
  • Non-functional Requirements: Constraints on the services or functions offered by the system (speed, response time, data encryption).
    • Midterm Tip: If a requirement mentions “seconds,” “MB/GB,” or “Legal compliance,” it is non-functional.
  • The Requirements Engineering Process:
    1. Elicitation: Talking to stakeholders to discover requirements.
    2. Specification: Documenting them (User vs. System).
    3. Validation: Checking for realism and consistency.

4. System Modeling

UML (Unified Modeling Language) is the standard for these models.

  • Context Models: Used to show the operational context of a system—what is inside the system and what is outside (social/business context).
  • Use Case Diagrams: Identifies the actors (people or other systems) and the specific functions (use cases) they interact with.
  • Sequence Diagrams: Shows the sequence of interactions between objects during a particular use case.
  • State Diagrams: Shows how a system responds to internal and external events.
    • Midterm Tip: Practice the Microwave Oven or Insulin Pump state diagrams from your slides. Identify the “Stimulus” (input) and the “Transition” (the arrow).

5. Architectural Design

Architecture is the high-level structure of the system. Choosing the right pattern is critical for non-functional requirements like performance and security.

  • Layered Architecture: Organizes the system into layers (e.g., User Interface, Business Logic, Database). Supports incremental development and change.
  • Model-View-Controller (MVC):
    • Model: Manages the system data and state.
    • View: Manages how the data is presented to the user.
    • Controller: Manages user interaction and passes it to the Model/View.
  • Client-Server Architecture: Distributed system model which shows how data and processing is distributed across a range of components.

6. Object-Oriented Design & Implementation

  • Design Patterns: These are “templates” for solving recurring problems. You should recognize Observer (for broadcasting changes) and Singleton (ensuring only one instance of a class exists).
  • Configuration Management: Crucial because software is always changing. It involves:
    • Version Management: Keeping track of different versions of system components.
    • System Integration: Defining which versions of components are used to create each version of the system.
  • Open Source Development: Understand the difference between licenses like GNU (GPL) (must make source code public) and MIT/Apache (can stay private).

Practice Exam Simulation

Q1 (Scenario): You are building a flight control system for a new drone. Which process model do you choose and why?

  • Answer: Waterfall or a highly formal Plan-Driven model. Because it is a safety-critical system, we need complete specifications and rigorous validation before any hardware is produced.

Q2 (Modeling): In a Sequence Diagram, what does a dashed vertical line represent?

  • Answer: The “Lifeline” of an object, representing the time during which the object exists.

Q3 (Requirements): Change this User Requirement into a System Requirement: “The system should be fast.”

  • Answer: “The system shall respond to user search queries within 2.0 seconds under a load of 100 concurrent users.” (Note the measurable numbers).