Software Engineering: SDLC, Testing, Agile and Quality
Software engineering is the disciplined application of engineering principles, methods, and tools to build software that is useful, dependable, maintainable, secure, and economical to evolve.
It includes far more than writing code: teams must understand user needs, design solutions, manage risks, test carefully, deploy safely, and maintain the product after release.
1. Software-Engineering Fundamentals
Software engineering gives teams a repeatable way to turn an idea or problem into a maintained software product. It balances user value, technical quality, cost, time, security, and long-term change.
| Goal | How software engineering helps |
|---|---|
| User value | Helps teams understand real problems before building a solution. |
| Reliability | Uses design reviews, testing, monitoring, and disciplined change control to reduce defects. |
| Maintainability | Encourages modular design, documentation, readable code, and automated tests. |
| Security | Builds security considerations into requirements, design, implementation, testing, and deployment. |
| Team coordination | Provides shared plans, source control, standards, reviews, and communication practices. |
| Risk reduction | Identifies uncertainty early and validates assumptions through prototypes, feedback, and testing. |
2. Software Development Life Cycle (SDLC)
The Software Development Life Cycle describes the activities used to create, release, and improve software. In real projects, phases often overlap and repeat as new information becomes available.
| Phase | Main purpose | Typical outputs |
|---|---|---|
| Planning and feasibility | Define the problem, expected value, scope, budget, risks, and practicality. | Business case, feasibility assessment, initial roadmap, risk list |
| Requirements | Understand what stakeholders need and define success criteria. | User stories, use cases, requirements specification, acceptance criteria |
| Design | Choose architecture, data structures, interfaces, modules, and technical approach. | Architecture diagrams, database design, API contracts, prototypes |
| Implementation | Write, review, integrate, and document code. | Source code, code reviews, build artifacts, developer documentation |
| Testing | Evaluate behavior, quality attributes, and risk areas. | Test cases, automated tests, defect reports, test evidence |
| Deployment | Release software safely to users or production environments. | Release plan, deployment configuration, rollback plan, release notes |
| Maintenance and evolution | Fix defects, improve performance, adapt to changes, and add useful features. | Patches, enhancements, updated documentation, monitored releases |
Feedback can move work backward as well as forward. For example, a testing failure may reveal a design problem, and production feedback may create a new requirement.
3. Requirements Engineering
Requirements explain what a system must achieve and the conditions under which it must operate. A technically correct product can still fail if it solves the wrong problem or does not meet stakeholder expectations.
| Requirement type | Meaning | Online-library example |
|---|---|---|
| Functional requirement | Describes what the system must do. | A member can search books by title, author, or ISBN. |
| Non-functional requirement | Describes quality attributes, constraints, or operational conditions. | Under stated normal load, search results should appear within two seconds. |
| User requirement | A high-level statement from the user's viewpoint. | Members should be able to renew borrowed books online. |
| System requirement | A detailed requirement used by developers, testers, and operations teams. | The system shall send a confirmation after a successful renewal request. |
Requirements-engineering process
- Elicitation: gather needs through interviews, observation, workshops, documents, and prototypes.
- Analysis: identify conflicts, ambiguity, dependencies, assumptions, and priorities.
- Negotiation: agree on scope and trade-offs when stakeholder needs conflict.
- Specification: record agreed requirements in a specification, product backlog, or another shared format.
- Validation: check that requirements are complete, feasible, consistent, testable, and valuable.
- Management: track changes, decisions, versions, and traceability throughout the project.
4. Software Process Models
A software process model organizes development work. No model is universally best; suitability depends on requirement stability, risk, regulation, team experience, architecture, and the need for fast feedback.
| Approach | Main idea | Strength | Limitation |
|---|---|---|---|
| Waterfall | Development follows largely sequential stages with defined outputs. | Clear planning and documentation for stable, well-understood work. | Late changes can be expensive when feedback arrives after major work is complete. |
| Iterative and incremental | The product is improved in cycles and delivered in usable increments. | Early working software and frequent feedback. | Needs careful architecture to avoid accumulated technical debt. |
| Spiral | Each cycle emphasizes planning, risk analysis, engineering, and evaluation. | Useful for large, costly, high-risk projects. | Can be difficult and expensive to manage for small projects. |
| Agile delivery | Short feedback cycles, adaptive planning, and frequent delivery of useful work. | Supports learning and changing priorities. | Requires active collaboration, disciplined prioritization, and transparent communication. |
| DevOps practices | Development and operations collaborate on build, release, monitoring, and recovery. | Can improve delivery speed and operational feedback. | Requires automation, shared responsibility, and appropriate operational skills. |
Agile does not mean “no planning” or “no documentation.” It means producing documentation and plans that are useful for the product, the team, users, and future maintenance.
5. Software Design and Architecture
Design turns requirements into a practical technical blueprint. Good design makes the software easier to understand, test, modify, secure, and operate.
| Principle | Meaning |
|---|---|
| Abstraction | Focus on essential behavior while hiding unnecessary implementation detail. |
| Modularity | Divide the system into meaningful, manageable components. |
| Information hiding | Keep internal implementation details private behind stable interfaces. |
| Low coupling | Limit unnecessary dependencies between modules. |
| High cohesion | Keep closely related responsibilities together in the same module. |
| Separation of concerns | Separate interface logic, business rules, storage, security, and operational concerns. |
| Defence in depth | Use several complementary safeguards instead of relying on one control. |
Design levels
- Architectural design: defines major components and how they communicate.
- High-level design: defines modules, services, interfaces, data flows, and responsibility boundaries.
- Detailed design: defines algorithms, data structures, validation rules, error handling, and internal logic.
Design decisions should be documented at the level needed to explain why the decision was made and how the system should be changed safely later.
6. Testing and Quality Assurance
Software testing evaluates a product to find defects, verify requirements, and provide evidence about risk. Testing can reveal defects, but it cannot prove that a complex system contains no defects.
Testing levels
| Level | Focus | Example |
|---|---|---|
| Unit testing | A small unit such as a function, class, or component. | Verify a discount-calculation function for valid and invalid inputs. |
| Integration testing | Interactions between components or services. | Verify that an order service communicates correctly with a payment service. |
| System testing | The complete system against functional and quality requirements. | Test login, search, checkout, performance, security, and compatibility together. |
| Acceptance testing | Whether the delivered product satisfies agreed business or user needs. | Users validate that a completed workflow meets acceptance criteria. |
Testing approaches
| Approach | Focus |
|---|---|
| Black-box testing | Checks behavior against requirements without examining internal code. |
| White-box testing | Examines internal logic, branches, conditions, paths, and loops. |
| Regression testing | Checks that changes have not broken existing behavior. |
| Smoke testing | Performs a quick check of critical functionality after a build or deployment. |
| Performance testing | Measures responsiveness, scalability, resource use, and stability under stated workloads. |
| Security testing | Checks authentication, authorization, input handling, configuration, dependencies, and common attack resistance. |
Testing versus quality assurance
Testing evaluates the product. Software Quality Assurance (SQA) improves the process used to create that product. SQA includes standards, reviews, audits, training, defect prevention, process improvement, and quality planning.
7. Version Control, CI/CD, and Secure Delivery
Reliable delivery requires more than compiling code. Teams need controlled changes, repeatable builds, safe releases, operational feedback, and the ability to recover when something goes wrong.
| Practice | Purpose |
|---|---|
| Version control | Tracks source-code changes, supports collaboration, and preserves history. |
| Code review | Finds defects, shares knowledge, and checks maintainability and security concerns before merge. |
| Continuous integration | Frequently integrates changes and automatically builds and tests them. |
| Continuous delivery or deployment | Makes releases repeatable, reviewable, and safer through automation. |
| Configuration management | Controls versions of code, environments, dependencies, documents, builds, and releases. |
| Monitoring and observability | Uses logs, metrics, traces, and alerts to understand production behavior. |
| Rollback planning | Provides a safe response when a release introduces serious problems. |
Secure software practices
- Consider threats and privacy requirements during design, not only after coding.
- Validate input, enforce authorization on the server side, and handle errors safely.
- Keep dependencies updated and review known security issues.
- Store secrets outside source code and restrict access to production credentials.
- Use least privilege for people, services, databases, and cloud resources.
- Test security-relevant changes and monitor important production events.
8. Software Maintenance and Evolution
Software work continues after release. User needs, regulations, devices, browsers, operating systems, security threats, and third-party services all change over time.
| Type | Purpose |
|---|---|
| Corrective maintenance | Fixes defects and errors found after release. |
| Adaptive maintenance | Updates software for changed environments, platforms, APIs, regulations, or hardware. |
| Perfective maintenance | Improves usability, performance, features, or maintainability. |
| Preventive maintenance | Reduces future risk through refactoring, documentation, cleanup, dependency updates, and test improvement. |
A maintainable system has understandable code, reliable tests, current documentation, explicit ownership, and a safe way to deploy changes.
9. Project Management, Risk, and Metrics
Software project management coordinates people, scope, time, budget, quality, dependencies, and risk. A project can fail despite good code if stakeholders, priorities, or delivery expectations are not managed well.
Key management activities
- Scope management: define what is included and control uncontrolled feature growth.
- Estimation and scheduling: estimate effort, plan milestones, and revise forecasts when evidence changes.
- Risk management: identify risks, estimate likelihood and impact, assign owners, and prepare responses.
- Stakeholder communication: keep users, developers, testers, operations teams, and sponsors aligned.
- Configuration management: track versions of important project artifacts and release baselines.
Useful metrics
| Metric | Possible use | Caution |
|---|---|---|
| Defect trend | Shows whether defects are increasing, decreasing, or clustering in an area. | Raw counts do not automatically measure quality. |
| Lead time | Measures time from requesting work until delivery. | Interpret alongside scope and complexity. |
| Cycle time | Measures time from starting active work until completion. | Can be distorted when work is split inconsistently. |
| Test coverage | Indicates how much code or behavior tests exercise. | Does not prove that tests are meaningful. |
| Cyclomatic complexity | Estimates the number of independent decision paths in code. | Use as a review signal, not as the only quality measure. |
10. Quick Revision and Practice Questions
| Concept | Key point |
|---|---|
| SDLC | Activities used to plan, build, test, deploy, and evolve software. |
| Functional requirement | Describes what the system must do. |
| Non-functional requirement | Describes quality attributes or operational constraints. |
| Waterfall | Largely sequential approach suited to stable, well-understood work. |
| Agile | Uses short feedback cycles and adaptive planning. |
| Low coupling | Modules have limited unnecessary dependency on one another. |
| High cohesion | Related responsibilities remain together in one module. |
| Testing | Evaluates the product to find defects and assess risk. |
| SQA | Improves the development process and prevents defects. |
| CI/CD | Automates integration, testing, and reliable delivery practices. |
Practice questions
-
Is software engineering only about coding?
Answer: No. It includes requirements, design, testing, deployment, maintenance, documentation, security, teamwork, and management. -
What is the difference between functional and non-functional requirements?
Answer: Functional requirements describe what the system does; non-functional requirements describe qualities, constraints, or operating conditions. -
What is the difference between software testing and SQA?
Answer: Testing evaluates the product, while SQA improves the process used to create the product and prevent defects. -
Does Agile mean that documentation is unnecessary?
Answer: No. Agile values useful documentation and adaptive planning rather than excessive documentation with little value. -
Why is code coverage not proof that software is correct?
Answer: Coverage shows that code ran during tests; it does not prove that the tests checked correct behavior or covered all risks.