Software Engineering

Overview: what this unit covers

Read this unit as the story of one project. First the team chooses a life-cycle model and agrees what to build, which is the SDLC and requirements part. Then it designs the system in modules, which is the design part. Then it builds and tests the system level by level, checks its quality against standards, and manages the whole effort with estimates, schedules, and risk plans. The examination rewards the ability to match a situation to a model, a defect to a testing level, and a number to an estimation formula, so practise those three kinds of judgement as you read.

SDLC models

The software development life cycle is the sequence of phases through which software passes: requirements, design, implementation, testing, deployment, and maintenance. A life-cycle model organises these phases and decides when each is revisited. The waterfall model runs the phases strictly in sequence, with each phase completed and reviewed before the next begins. Its strength is clarity and documentation, which suits small projects with stable, well-understood requirements. Its weakness is rigidity: returning to an earlier phase is expensive, and the customer sees working software only late, when changes are costly. The V-model extends the waterfall by pairing each development phase with a matching test phase: requirements pair with acceptance testing, system design with system testing, detailed design with integration testing, and coding with unit testing. Testing is therefore planned early even though it is executed late, which catches mismatches between a phase and its verification earlier than a plain waterfall does.

The incremental model delivers the system in pieces. A first increment provides core functionality, and later increments add features, so users get working software early and feedback shapes later increments. It suits projects where requirements are partly known and early delivery matters, but it needs a stable architecture from the start or later increments become hard to integrate. The spiral model is risk-driven: each loop around the spiral passes through planning, risk analysis, engineering, and evaluation, and the radius grows as the product grows. Risk analysis is its defining feature, so it suits large, high-risk, or unprecedented projects, at the cost of complexity and the need for risk expertise. Rapid application development, or RAD, compresses delivery with prototypes, reusable components, and close user involvement in short cycles, but it needs users who can commit time and a system that can be modularised. Prototyping builds a throwaway or evolutionary mock-up to clarify unclear requirements, especially user interfaces, before committing to full development; it reduces requirement risk but can mislead users into thinking the prototype is nearly the finished product.

Agile methods replace big upfront planning with short, adaptive iterations. The Agile Manifesto values individuals and interactions, working software, customer collaboration, and responding to change over processes, comprehensive documentation, contract negotiation, and following a plan. Scrum organises work into sprints, usually a few weeks long, with a product backlog of desired features, a sprint backlog for the current sprint, a daily stand-up meeting, a sprint review, and a retrospective. Its roles are the product owner, who owns priorities, the Scrum master, who protects the process and removes obstacles, and the development team, which delivers the increment. Extreme Programming, or XP, pushes good practices to extremes: pair programming, test-driven development, continuous integration, small releases, simple design, and refactoring. It suits small teams with changing requirements and an available customer, but it is harder to scale to very large or safety-critical systems. Selecting a model is a judgement question: stable requirements and a fixed contract favour waterfall or the V-model, unclear requirements favour prototyping or spiral, early delivery favours incremental or agile, and high risk favours spiral. A good answer names the model and the project feature that justifies it, not merely the model name.

Requirements engineering turns stakeholder needs into an agreed specification. Elicitation gathers needs through interviews, questionnaires, observation, workshops, and studying existing documents. Analysis resolves conflicts, checks feasibility, and prioritises. The result is written in a software requirements specification, or SRS, which should be correct, unambiguous, complete, consistent, verifiable, modifiable, and traceable. A requirement is verifiable if a test can decide whether it is met; a vague requirement such as fast response fails that test, while response within two seconds for a stated load passes it. Functional requirements state what the system must do, such as allowing a teacher to upload marks. Non-functional requirements state qualities and constraints, such as performance, security, usability, reliability, and portability. Confusing the two is a common error: a statement about speed or security is non-functional even when it describes an important behaviour.

Testing & quality

Design translates requirements into a structure that can be built. Two principles govern module design. Coupling measures how strongly modules depend on each other; low coupling is desired, because a change in one module then affects few others. The scale runs from content coupling, the worst, where one module reaches inside another, through common and control coupling, to stamp, data, and message coupling, the loosest, where modules communicate only through parameters or messages. Cohesion measures how closely the parts of one module belong together; high cohesion is desired. The scale runs from coincidental cohesion, the weakest, where parts are grouped arbitrarily, through logical, temporal, and procedural cohesion, to communicational, sequential, and functional cohesion, the strongest, where every part contributes to one well-defined task. A design with low coupling and high cohesion is easier to understand, test, and change, and the examination frequently asks which end of each scale is desirable.

Data flow diagrams describe movement of data, not control flow. A context diagram shows the whole system as one process with external entities and data flows. Lower levels decompose processes, showing data stores, flows, and transformations in more detail, while balancing requires that flows entering and leaving a decomposition match the parent diagram. The unified modelling language, or UML, describes object-oriented systems: a class diagram shows classes, attributes, operations, and relationships such as association, aggregation, and inheritance; a use case diagram shows actors and the goals they achieve with the system; a sequence diagram shows messages between objects over time; and a state diagram shows how one object changes state in response to events. A question that asks what a diagram shows is answered by naming its elements, not by describing the system in general.

Testing verifies that the software meets its specification and validates that it meets the user's real needs. Unit testing checks one module in isolation, often with drivers that call the module and stubs that stand in for modules it calls. Integration testing checks modules together, top-down using stubs, bottom-up using drivers, or with a sandwich approach that combines both. System testing checks the whole system against its requirements, including performance, security, and recovery testing. Acceptance testing is performed by or for the customer, with alpha testing at the developer site and beta testing at user sites. Regression testing re-runs earlier tests after a change to check that nothing that worked before has broken.

Black-box testing derives tests from the specification without looking at the code. Equivalence partitioning divides inputs into classes that should behave alike and tests one representative from each class, plus invalid classes. Boundary value analysis tests values at and just either side of input boundaries, because defects cluster at edges. White-box testing derives tests from the code structure. Statement coverage requires every statement to execute; branch coverage requires every branch outcome; path coverage requires every path, which is usually infeasible for loops. Basis-path testing uses cyclomatic complexity to find the number of independent paths that must be tested. For a flow graph with E edges, N nodes, and P connected components, cyclomatic complexity is V(G) = E - N + 2P. For a single program it also equals the number of predicate nodes plus one. A higher value means more decision logic, harder testing, and usually a module that should be split. Test-driven development reverses the usual order by writing a failing test first, then the smallest code that passes it.

Quality assurance is wider than testing: it is the planned set of activities that give confidence the product meets quality standards. Reviews and inspections find defects by reading, without executing the code; a formal inspection follows defined roles and checklists, while a walkthrough is a less formal peer review. The capability maturity model describes five levels: initial, where processes are ad hoc; repeatable, where basic project management is in place; defined, where processes are documented and standardised; managed, where processes are measured; and optimising, where improvement is continuous and feedback-driven. ISO 9000 is a family of quality-management standards centred on documented processes, customer focus, and continual improvement; it certifies the quality system, not the quality of any single product. Software quality assurance therefore combines process standards, reviews, testing, measurement, and defect tracking, rather than relying on testing alone at the end. How it is examined: expect a coupling or cohesion ordering question, a testing-level scenario, a boundary or equivalence case, and a cyclomatic complexity number.

Estimation & project management

Estimation begins with size. Lines of code, or LOC, counts source lines, but it is language-dependent, it penalises concise code, and it cannot be counted before the code exists. Function points measure size from the user's view, counting what the system does rather than how it is coded. Five function types are counted: external inputs, external outputs, external inquiries, internal logical files, and external interface files. Each is rated simple, average, or complex with a standard weight, and the weighted sum is the unadjusted function point count. Fourteen general system characteristics, such as data communications, performance, and reusability, are each rated from zero to five, and their sum adjusts the count: the complexity adjustment factor is 0.65 plus 0.01 times the total degree of influence, and adjusted function points equal unadjusted function points times that factor. Because function points are counted from requirements, they can be estimated far earlier than lines of code, and they allow comparison across languages, although the ratings still involve judgement.

COCOMO, the constructive cost model, converts size into effort and schedule. The basic model for an organic project, small and familiar with a small experienced team, uses effort in person-months as 2.4 times size in thousands of lines of code raised to the power 1.05, and development time in months as 2.5 times effort raised to the power 0.38. Semidetached and embedded projects use larger coefficients and exponents, reflecting greater complexity and tighter constraints. The intermediate model multiplies the basic effort by effort adjustment factors for product, hardware, personnel, and project attributes, such as required reliability and analyst capability. The advanced or detailed model applies those factors phase by phase. Average staffing is effort divided by development time, and COCOMO results are estimates with wide uncertainty, not promises; a computed figure should be reported with its assumptions, especially the project mode and the size figure.

Project management turns the estimate into a plan and keeps it on track. A work breakdown structure divides the project into manageable tasks. Scheduling uses networks of activities: the critical path method finds the longest path through the network, which fixes the shortest possible project duration, and any delay on the critical path delays the whole project. Activities off the critical path have slack, or float, which is the amount they can slip without delaying the project. PERT handles uncertainty with three estimates per activity: optimistic, most likely, and pessimistic time. The expected time is optimistic plus four times most likely plus pessimistic, all divided by six, and the variance is the square of pessimistic minus optimistic divided by six. A Gantt chart then displays tasks against calendar time, showing overlaps, milestones, and progress.

Risk management is a separate discipline, not an afterthought. Risk identification lists what could go wrong, from requirement change to staff loss to new technology. Risk analysis assesses probability and impact, often ranking risks in a table. Risk planning prepares responses: avoidance removes the risk, mitigation reduces probability or impact, transfer moves it to another party, and acceptance prepares a contingency plan. Risks are then monitored through the project, because a risk that was minor at the start can become critical later. Configuration management supports all of this by controlling versions of code, documents, and builds, so that a change is tracked, reviewed, and reversible, and the team always knows which version is the current baseline. How it is examined: expect a function-point sum with an adjustment factor, a COCOMO effort or schedule computation with the mode stated, a PERT expected-time calculation, and a critical-path or slack judgement from a small network.

SDLC models compared

Testing levels compared

Black-box versus white-box testing

CMM maturity levels