Software Engineering is about building software the way other engineers build bridges or machines: with a process, a plan, measurements and quality checks. Most of what DevOps does today, continuous integration, automated testing, infrastructure as code, monitoring, is this subject’s lessons put into practice and automated. This article revisits the five units of the JNTUK course.
Unit 1: Introduction and process models
Why software engineering
Early projects were late, over budget and buggy, which the 1960s called the software crisis. Software engineering applies systematic, measurable methods to development, operation and maintenance. Software is developed, not manufactured, it does not wear out but it degrades through change, and most of its cost is in maintenance.
Process activities
Every process includes communication, planning, modelling, construction and deployment, or in simpler terms: specification, design and implementation, validation, and evolution.
Process models
| Model | Idea | Best when | Weakness |
|---|---|---|---|
| Waterfall (linear sequential) | Requirements, design, code, test, deploy, in order | Requirements are fixed and well understood | Late feedback; costly change |
| Incremental | Deliver the product in working slices | Early partial delivery is needed | Needs a good overall architecture |
| Prototyping | Build a quick mock-up to clarify requirements | Requirements are unclear | Prototype may be mistaken for the product |
| Spiral | Repeated cycles with explicit risk analysis | Large, risky projects | Complex, needs risk expertise |
| V-model | Each development phase paired with a test phase | Safety-critical work | Rigid |
| RAD (rapid application development) | Short cycles, components and reuse | Well-bounded business apps | Needs skilled teams |
Agile
The Agile Manifesto (2001) values individuals and interactions, working software, customer collaboration and responding to change over their formal counterparts. Scrum uses fixed sprints (1 to 4 weeks), roles (product owner, scrum master, team) and events (planning, daily stand-up, review, retrospective). Extreme Programming (XP) adds pair programming, test-driven development and continuous integration. Kanban limits work in progress and visualizes flow.
Today: most teams use Agile in sprints, and DevOps extends it to operations: build, test and deploy in one automated flow. The Capability Maturity Model (CMMI) from this unit is still used by outsourcing companies to describe process maturity.
Unit 2: Requirements engineering and analysis
Types of requirements
| Type | Meaning | Example |
|---|---|---|
| Functional | What the system does | “A user can reset a password by email” |
| Non-functional | How well it does it: performance, security, availability, usability | “Pages load in under 2 seconds” |
| Domain and constraints | Rules from the environment | “Must comply with local data-protection law” |
Requirements process
- Elicitation: interviews, workshops, observation, questionnaires, prototypes.
- Analysis and negotiation: find conflicts, gaps and priorities.
- Specification: write a Software Requirements Specification (SRS) that is clear, complete, consistent, verifiable and traceable.
- Validation: reviews and prototypes confirm it is what the customer wants.
- Management: control changes, as requirements always change.
Modelling
- Use cases and use-case diagrams show actors and their goals; user stories (“As a user, I want X so that Y”) are the Agile form.
- Data flow diagrams (DFD) show how data moves between processes and stores.
- Class, sequence, activity and state diagrams in UML describe structure and behaviour.
- Feasibility study: technical, economic, operational.
Today: an unclear requirement is the most expensive defect, because everything built on it is wrong. User stories and acceptance criteria in Jira are this unit, and non-functional requirements are now written as SLOs (for example, 99.9% availability).
Unit 3: Software design
Design principles
| Principle | Meaning |
|---|---|
| Abstraction | Show essentials, hide detail |
| Modularity | Split into independent parts |
| High cohesion | Each module does one thing well |
| Low coupling | Modules depend on each other as little as possible |
| Information hiding | Keep internals private behind an interface |
| Separation of concerns | Different responsibilities in different places |
Cohesion (inside a module) should be high and coupling (between modules) low. Structured design uses structure charts; object-oriented design uses the SOLID principles: single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion.
Architecture and patterns
An architectural style gives the overall shape.
| Style | Description |
|---|---|
| Layered | Presentation, business, data layers |
| Client-server | Clients request, servers respond |
| MVC | Model, view and controller separate data, display and input |
| Microservices | Many small independently deployable services |
| Event-driven | Components react to events, often via a message broker |
Design patterns are reusable solutions to common problems (the “Gang of Four”): creational (Singleton, Factory, Builder), structural (Adapter, Decorator, Facade) and behavioural (Observer, Strategy, Command). User interface design follows rules such as consistency, feedback and error prevention.
Today: the microservice split of products such as HCM (one main server plus smaller services) is an architectural choice from this unit, with the trade-off of more network calls and operational overhead. A message broker such as Kafka implements the event-driven style.
Unit 4: Testing and quality
Testing strategies
Testing finds defects; verification asks “are we building the product right?” and validation “are we building the right product?”.
| Level | Tests | Done by |
|---|---|---|
| Unit | A single function or class | Developers |
| Integration | Modules working together (top-down, bottom-up, big-bang) | Developers and testers |
| System | The whole product against the SRS | Test team |
| Acceptance | Does it meet the customer’s needs (alpha, beta) | Customer |
Techniques
| Technique | Idea |
|---|---|
| Black-box | Test inputs and outputs without seeing the code: equivalence partitioning, boundary value analysis, decision tables |
| White-box | Test the internal logic: statement, branch and path coverage; cyclomatic complexity V(G) = E − N + 2 counts independent paths |
| Regression | Re-run tests after a change to be sure nothing broke |
| Performance, load and stress | Speed and behaviour under heavy use |
| Security testing | Probing for vulnerabilities |
Test-driven development (TDD) writes the test first. A test case has inputs, steps and an expected result; a bug report has steps to reproduce, severity and priority.
Quality and metrics
Quality assurance builds quality into the process (reviews, inspections, audits, standards such as ISO 9001); quality control checks the product. Metrics include defect density, lines of code, cyclomatic complexity, coupling and cohesion. Reliability measures: MTTF, MTTR, MTBF, and availability = MTBF / (MTBF + MTTR).
Today: CI pipelines run unit and integration tests on every commit, SonarQube measures complexity, duplication and coverage, and load tests run before a release. The availability formula is the one behind “nines”: 99.9% means about 8.8 hours of downtime a year.
Unit 5: Project management, maintenance and risk
Estimation
| Technique | Idea |
|---|---|
| Lines of code / function points | Size measures; function points count inputs, outputs, inquiries, files and interfaces |
| COCOMO | Estimates effort from size: Effort = a (KLOC)b person-months, with organic, semi-detached and embedded modes |
| Expert judgement, analogy, planning poker (Agile) | Estimate by comparing with past work |
Scheduling and tracking
- Work breakdown structure (WBS) splits the project into tasks.
- Gantt charts show tasks over time; PERT and CPM find the critical path, the longest chain that decides project length.
- Earned value tracks progress against plan; Agile teams use burn-down charts and velocity.
Risk management
Identify risks, estimate probability and impact, plan mitigation and contingency, and monitor. Typical risks: unclear requirements, staff turnover, technology change, schedule pressure.
Configuration management and maintenance
Software configuration management (SCM) controls versions and changes: version control (Git), baselines, branching and merging, change control and build and release management.
Maintenance is the longest phase of a product’s life.
| Type | Purpose |
|---|---|
| Corrective | Fix defects |
| Adaptive | Adjust to a new environment (OS, cloud, law) |
| Perfective | Improve features and performance |
| Preventive | Refactor to reduce future problems |
Reengineering and reverse engineering modernise old systems, as in migrating an Angular 8 app to a new framework.
Today: Git is software configuration management, release pipelines are build and release management, and Terraform extends it to infrastructure (“infrastructure as code”). Jira and sprint boards are the modern WBS and tracking tools. The four maintenance types explain most of a DevOps team’s backlog: patches, upgrades and refactors.
One-minute recap
| Unit | Key idea | You meet it in |
|---|---|---|
| 1. Process models | Waterfall, incremental, spiral, Agile and Scrum | Sprints, Kanban, DevOps |
| 2. Requirements | Functional vs non-functional, SRS, use cases, user stories | Jira tickets, SLOs |
| 3. Design | Cohesion and coupling, SOLID, MVC, microservices, patterns | Architecture reviews, service boundaries |
| 4. Testing and quality | Unit to acceptance; black-box and white-box; coverage | CI pipelines, SonarQube, load tests |
| 5. Management and maintenance | COCOMO, critical path, risk, SCM, four maintenance types | Git, release pipelines, backlog grooming |
Next in Engineering Revisited: Automata & Compiler Design.
Written by Claude, Anthropic’s AI assistant, as part of Engineering Revisited, a quick refresher of the B.Tech subjects one at a time.