Software Engineering Basics: Essential Concepts
Software Engineering is the application of a systematic, disciplined, quantifiable approach to
the design, development, testing, and maintenance of software. It transforms complex
programming into a structured, reliable process.
1. The Software Development Life Cycle (SDLC)
The SDLC is a framework that describes the activities performed at each stage of a software
project, ensuring a structured and disciplined approach.
Phase Description Key Deliverable
Eliciting, analyzing, documenting, and
Software Requirements
1. Requirements validating the needs of the stakeholders
Specification (SRS)
(users, business).
Defining the overall architecture,
Software Design Document
2. Design components, interfaces, and data structure
(SDD)
of the system.
3. Writing the actual source code based on the
Functional Code/Prototype
Implementation design specifications.
Verifying and validating that the software
Test Reports/Validated
4. Testing meets the requirements and is free of
System
defects.
Making the finished and tested software
5. Deployment available to the end-users (e.g., release to Live System/Application
production).
Ongoing process of fixing bugs, adapting to
Updates, Patches, New
6. Maintenance new environments, and enhancing features
Versions
post-release.
2. Software Development Models
These models define the flow and sequence of the SDLC phases:
• Waterfall Model: A sequential, linear flow where each phase must be completed
before the next begins. Best for small, well-understood projects with stable
requirements.
• Agile Model: An iterative and incremental approach. Development is done in small
cycles (Sprints), focusing on flexibility, customer collaboration, and rapid delivery of
working software.
• V-Model: An extension of the Waterfall model that emphasizes testing. Testing
activities are planned in parallel with the corresponding development phases (e.g.,
System Testing aligns with Requirements).
• Spiral Model: Combines iteration and risk management. Development is done in
successive spirals, with risk assessment and planning occurring at each loop.
3. Core Software Design Principles
These principles guide the creation of high-quality, maintainable, and scalable code
structures.
A. Foundational Principles
• Modularity: Breaking down the system into distinct, independent, and
interchangeable components (modules).
o Cohesion: Measures how strongly related the internal elements of a module
are (High Cohesion is good).
o Coupling: Measures the degree of interdependence between different
modules (Low Coupling is good).
• Abstraction: Showing only essential information while hiding complex
implementation details.
• Information Hiding: Protecting the internal state and data of a module from external
components that do not need to know about it.
B. The SOLID Principles (Object-Oriented Design)
This acronym represents five key principles for building flexible and maintainable systems:
1. Single Responsibility Principle (SRP): A class/module should have only one reason to
change.
2. Open/Closed Principle (OCP): Software entities should be open for extension but
closed for modification.
3. Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base
types without altering the correctness of the program.
4. Interface Segregation Principle (ISP): Clients should not be forced to depend on
interfaces they do not use (prefer many small, specific interfaces over one large one).
5. Dependency Inversion Principle (DIP): High-level modules should not depend on low-
level modules; both should depend on abstractions (interfaces).
C. Other Design Mantras
• DRY (Don't Repeat Yourself): Avoid duplication of code or logic; centralize common
functionality.
• KISS (Keep It Simple, Stupid): Strive for the simplest possible solution to avoid
unnecessary complexity.
• YAGNI (You Aren't Gonna Need It): Only implement features that are currently
required; avoid over-engineering based on speculation.
4. Software Quality Assurance (SQA) and Testing
SQA is the process that ensures the software development process and the final product
meet the required quality standards.
• Verification: Checks if the software conforms to the specifications ("Are we building
the product right?").
• Validation: Checks if the software meets the user's needs and expectations ("Are we
building the right product?").
• Testing Types:
o Unit Testing: Testing individual components or functions in isolation.
o Integration Testing: Testing how different modules work together.
o System Testing: Testing the entire, integrated system against the specified
requirements.
o Acceptance Testing (UAT): Formal testing to confirm that the system satisfies
the user's acceptance criteria.
Software Engineering Basics: Architectural Patterns
Software architecture defines the fundamental structure of a software system, establishing
its organization, components, and how they interact. The choice of architecture is crucial as
it dictates the system's scalability, maintainability, and performance.
1. Monolithic Architecture
• Definition: The traditional approach where all functional components (e.g., UI,
business logic, data access) are packaged together as a single, unified unit.
• Structure: A single codebase, typically deployed as a single executable file or
application server instance.
• Pros:
o Simplicity: Easier to develop, test, and deploy initially.
o Shared Resources: All components can directly access shared memory and
resources.
• Cons:
o Scalability Issues: Must scale the entire application, even if only one part is
the bottleneck.
o Technology Lock-in: Difficult to adopt new technologies or programming
languages for specific features.
o Maintenance: Changes in one module require redeploying the entire
application, increasing risk.
2. Microservices Architecture
• Definition: A suite of small, independent services, each running in its own process
and communicating with lightweight mechanisms (usually HTTP/REST or message
queues).
• Structure: Each service is responsible for a specific business capability (e.g.,
Inventory Service, Payment Service).
• Pros:
o Scalability: Services can be scaled independently based on their load.
o Technology Diversity: Teams can use different programming languages or
databases best suited for each service.
o Resilience: Failure in one service usually doesn't bring down the entire
system.
o Faster Development Cycles: Smaller codebases are easier for teams to
manage and deploy frequently.
• Cons:
o Complexity: Managing and monitoring many independent services is
operationally complex.
o Distributed Transactions: Implementing transactions across multiple services
is challenging.
3. Layered (N-Tier) Architecture
• Definition: Organizes the system into horizontal layers, where each layer performs a
specific role and only communicates with the layers immediately above and below it.
• Common Layers (e.g., 3-Tier):
1. Presentation Layer (UI): Handles user interface and interactions.
2. Business/Application Layer (Logic): Contains the core business rules and
functions.
3. Data Access Layer (Persistence): Manages interactions with the database.
• Pros:
o Separation of Concerns: Changes in one layer (like the UI) generally don't
affect others.
o Testability: Each layer can be tested independently.
• Cons:
o Performance Overhead: Passing requests through multiple layers can add
latency.
o Rigidity: Can be difficult to modify the strict layer dependencies.
4. Client-Server Architecture
• Definition: A widely used distributed model where a central Server (resource
provider) provides services or resources to multiple independent Clients (resource
requestors).
• Structure: Clients send requests to the server, and the server processes the requests
and sends back responses.
• Pros:
o Centralized Control: Easier to manage data and security on a single server.
o Resource Sharing: Multiple clients can access the same data and services.
• Cons:
o Server Dependency: If the central server fails, the entire system stops
working for all clients.
o Scalability Limits: The server can become a bottleneck if too many clients
make simultaneous requests.
5. Architectural Drivers
The choice of architecture is driven by non-functional requirements (or ilities):
Driver Description Architectural Impact
How quickly the system Requires fast communication (Monolithic) or
Performance
responds to user requests. independent scaling (Microservices).
The ability of the system to
Favors decentralized patterns like
Scalability handle an increased load
Microservices.
(users, data).
How the system protects Requires clear boundaries and secure
Security data and functions from authentication/authorization across
unauthorized access. components.
Driver Description Architectural Impact
How easy it is to fix bugs,
Favors high Modularity and low Coupling
Maintainability make changes, and update
(Microservices/Layered).
the system.