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:
- Elicitation: Talking to stakeholders to discover requirements.
- Specification: Documenting them (User vs. System).
- 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).
