Software Engineering · Lesson 1 of 8 · Updated ·
Introduction to Software Engineering and the SDLC
Writing a 50-line program for yourself is easy. Building an app that 10 lakh people use, that 30 developers change every week, and that must keep working for 10 years — that needs engineering.
1. What is software engineering?
Software engineering is the systematic, disciplined and measurable way of building, running and maintaining software (IEEE definition). In plain words: plan first, build in steps, check quality at every step, and keep it working afterwards.
Software is not just code. It includes programs + documentation + data + configuration — the SRS, design documents, test cases and user manuals are all part of the product.
2. The software crisis
In the 1960s–70s, projects were regularly:
- late and over budget,
- full of bugs and hard to change,
- not what the customer actually wanted.
Programs had grown much bigger than the informal methods used to build them. Software engineering (the term was popularised at a NATO conference in 1968) was the answer: use processes, models and measurement like other engineering fields.
3. How software is different from hardware
| Hardware | Software |
|---|---|
| Manufactured | Developed (engineered) |
| Wears out with age | Doesn't wear out — but deteriorates as changes add bugs |
| Spare parts replace failed parts | No spare parts; a fix means changing the design |
| Cost mostly in production | Cost mostly in development and maintenance |
That last point surprises students: maintenance is often 60% or more of the total lifetime cost of software.
4. Qualities of good software
- Correctness — does what the requirements say.
- Reliability — works without failure for a long time.
- Efficiency — uses CPU, memory and network well.
- Usability — easy to learn and use.
- Maintainability — easy to fix and change.
- Portability — runs on different platforms.
- Security — protects data and resists attacks.
5. The Software Development Life Cycle (SDLC)
| Phase | Main question | Output |
|---|---|---|
| 1. Requirements (analysis) | What should the system do? | SRS document |
| 2. Design | How will we build it? | architecture, database, UI, module design |
| 3. Coding (implementation) | Build it | source code, unit tests |
| 4. Testing | Does it work as required? | test reports, fixed bugs |
| 5. Deployment | Release to users | live system, user manuals |
| 6. Maintenance | Fix and improve after release | patches, new versions |
A feasibility study usually comes before requirements: is the project technically, economically and operationally possible?
Example — a college attendance app. Requirements: teachers mark attendance from their phone; students see their percentage. Design: Android app + REST API + PostgreSQL. Coding: build screens and APIs. Testing: try 0, 1 and 100 students, no internet, etc. Deployment: publish to Play Store. Maintenance: add a "below 75%" alert next semester.
The SDLC phases are the same everywhere; process models (next lesson) decide the order and repetition of these phases.
Common mistakes
- Thinking software engineering = programming. Coding is only one phase.
- Saying software "wears out". It deteriorates because of changes, not age.
- Skipping requirements — the most expensive bugs are wrong requirements.
Quick recap
- Software engineering = systematic, disciplined, measurable development and maintenance.
- Software crisis: late, over-budget, buggy projects in the 1960s–70s.
- Software doesn't wear out; maintenance is the largest cost.
- SDLC: requirements → design → coding → testing → deployment → maintenance.